It constantly amazes me at how much FGPA companies like Xilinx have done to bring ARM-based CPUs into a programmable SoC along with FPGA glue logic. Xilinx offers the Zynq 7000 and Zynq UltraScale+ SoCs to systems designers as a way to quickly get their ideas into the marketplace. A side effect of all this programability and flexibility to design a system is the classic challenge of how to debug the HW and SW system before committing to a prototype or production.
You could use a traditional, sequential development flow where hardware designers code their RTL and verify using testbenches, simulation and BFM (Bus Functional Models). The software engineers would separately write applications and verify SW. Once the hardware is stable enough, then you could start to think about how the hardware and software integration should take place. A sequential development flow is going to take more time because of the number of iterations required, so this provides an impetus for a better approach.
The major point of a recent webinar from Aldec was to show a new co-simulation methodology that enables early communication between the hardware and software simulation environments. Here’s how co-simulation connects together the SW and HW worlds:
All of your programmable logic is modeled in RTL on the right-hand side within the HDL simulator named Riviera-PRO from Aldec. Your processor is emulated with the Open Source QEMU (Quick EMUlator) that supports the popular A9 and A53 series of ARM processors. Connecting the processing system with the programmable logic for co-simulation is the Aldec QEMU Bridge. Some of the benefits for using this co-simulation idea are:
- HW and SW integration takes place quite early
- Improved visibility during debug of HW in Riviera-Pro
- Break points
- Use of Data Flow / Code Coverage
- Waveform inspection
- Improved visibility during debug of SW in QEMU
- Using the GDB debugger with both driver and kernel models
- Setting break points
Related blog – Aldec Swings for the Fences
The requirements for running this type of co-simulation include using a Linux computer with Riviera-Pro 2016.10 or later, the Xilinx QEMU, Xilinx Vivado, SystemC, a co-simulation license, Zynq Linux distribution and a device tree. Here’s a more detailed view of the co-simulation and how it works:
Our webinar presenter Adam Taylor showed how you use QEMU to actually boot Linux and then configure a pulse width, viewing the hardware waveform results in Riviera-Pro:
A hardware break point was set to demonstrate how co-simulation could be interrupted when a particular RTL line was reached:
Software break points were also set using GDB. All of these features showed how to validate and debug what is happening between a hardware and software system. They even showed how you could use evaluation boards like the TySOM series of boards after your co-simulation work had validated the system. There are a slew of daughter boards with TySOM to fit the specific SoC, memory and interfaces that your system dictates.
Powerful and programmable SoCs from Xilinx that contain ARM cores along with FPGA fabric can be designed quickly and validated early by using a co-simulation approach from Aldec that connects their Riviera-Pro simulator to the QEMU emulator for Zynq processors. Co-simulation helps you uncover HW/SW bugs quicker and earlier in the development cycle.
View the entire 45 minute archived webinar here online.Share this post via: