Embedded Technology
Hardware in the loop A
Radek Nawrot discusses hardware/software co- simulation challenges for System-on-Chip FPGAs and explains how a virtual platform bridge technology can shorten development times for projects requiring independent verification
s most readers will be aware, firmware – in the form of a Field Programmable Gate Array (FPGA), for instance – lends itself extremely well to applications that require one, more or all of the following: the parallel processing of data; determinacy (and in this respect some safety-critical applications demand that software not be used); flexibility though in-field upgrades; and lower commercial viability volumes compared to Application- Specific Integrated Circuits (ASICs). Moreover, perhaps the most significant development in the evolution of the FPGA was the introduction of devices with embedded processor cores. It marked the dawn of the System-on-Chip (SOC) FPGA. Compared to having separate FPGA and processor deployments in an embedded system, a SOC FPGA is a more integrated and smaller solution. There are power advantages too, plus you can have higher bandwidth communications between the Processing System (PS) and Programmable Logic (PL) parts of the device. However, the traditional problems associated with developing and verifying software code and firmware (using a Hardware Description Language, HDL) remain. Verification is a particular challenge, as waiting until the prototype powers up (and software and hardware interact for the first time) is not a viable option. That is far too late in the product development lifecycle and when problems are found, which they almost certainly will, project delays result.
Think Zynq Complex hardware/software interactions within SoC FPGA devices, such as the Xilnx Zynq 7000 for instance, require more advanced verification tools. Through co-simulation, the PS and PL parts of a design can be exercised concurrently, allowing hardware and software engineers to work together and correct design bugs early in the verification process.
For example, consider a Pulse Width Modulator (PWM) function within a design intended to reside in a Xilinx’ Zinq 7000. This device is available with a single or dual core ARM Cortex-A9. In the PL portion of the device, configurable logic blocks (CLBs)
www.cieonline.co.uk
too. Its debugging capabilities allow us to set break points, trace code, view waveforms and look at the PLM’s Finite State Machine (FSM). That’s all good and well, but how do we control the PWM if that is done in software?
For the PS part of the SoC we can use Xilinx’ Quick Emulator (QEMU), a free, open source and functionally accurate virtual emulator. But is there now a
and software interactions. Accordingly, hardware and software engineers can work together at an earlier stage of development. Additionally, with domains being co-simulated, the debugging capabilities of Riviera-PRO can interact with the complete design; all before putting the Zynq device onto a PCB. Software tools can be used to debug the corresponding code.
All changing Until recently, coding for FPGAs was wholly the responsibility of hardware engineers. With the dawn of the SOC FPGA, software developers are – in addition to coding for the PS side of the device – developing code for parts of the PL side. In addition to appropriate development and verification tools there is also a need for an integrated work flow; even for those engineers with feet in both the hardware and software domains. Figure 1 shows a high-level
representation of the workflow. In the PS domain, the open- source QEMU is the Virtual Platform. It mimics the ARM core processor environment and allows us to run software that communicates with the Zynq device’s internal bus; the AXI. On the PL side, we have the Register Transfer Level (RTL, a subset of the HDL) simulation tool. Code that will interact with the PS side of the device, via the AXI, can be exercised using a Testbench. The VP Bridge shown on the diagram is, in our case, QEMU Bridge. The bridge is synthesizable which is why it is shown a second time on the diagram; with TLM Emulation Proxy on one side and AXI BFM (Bus Functional Model) on the other.
Once the PS and PL design elements – and their interactions – have been verified, the SoC FPGA can then be targeted.
Summary
Figure 1: Above, how the QEMU Bridge can facilitate co-simultation if the ‘independent route’ is taken for hardware verification
include look-up tables, flip-flops and cascade adders.
For performance purposes, the PWM would best be implemented in PL but have its duty cycle controlled by code running in the PS portion of the device. For hardware simulation we could use Xilinx’ own FPGA development tools. However, as many system developers prefer - and some industry sectors demand - the ‘independent’ verification of hardware, tools like Aldec’s Rivera-PRO would be ideal
problem? In going down the independent route for hardware simulation we need a bridge between the PS and PL parts of the device. Here, we can use QEMU Bridge. It connects Riviera-PRO and QEMU, and converts Transaction Level Model (TLM) transactions, written is SystemC, to Advanced Extensible Interface (AXI) instructions and vice versa; providing a fast interface for co-simulation. A major benefit is an accelerated verification process for complex hardware
Co-simulation has always enabled hardware and software engineers to work together to locate and remove bugs at an earlier stage in a project’s lifecycle, thus saving both development time and costs, and this remains true for projects targeting SOC FPGAs. However, one need not be tied to using the chip vendor’s design and verification tools; and there’s an argument for validation activities to be independent anyway. In our article we explained how QEMU Bridge helps link an RTL simulator (for verifying the PL side of the SOC FPGA) with QEMU, the open-source machine emulator for dry-running the code that will run on the PS side of the device.
www.aldec.com Components in Electronics March 2018 15
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46 |
Page 47 |
Page 48
