Co‑Simulation for Zynq SoC Designs: Accelerating Hardware–Software Verification

Heterogeneous System‑on‑Chip (SoC) devices such as the Xilinx Zynq‑7000 and Zynq UltraScale+ MPSoC fuse a high‑performance processing system with cutting‑edge programmable logic. This integration lets designers build systems that balance CPU‑driven control with PL‑based, low‑latency pipelines—ideal for image processing, industrial automation, and real‑time signal processing.

The PS‑to‑PL connection is built on a suite of memory‑mapped Advanced eXtensible Interface (AXI) links that support both master and slave roles, enabling robust bidirectional communication between software running on the ARM cores and custom logic in the FPGA fabric.

Figure 1. Zynq Architecture Showing AXI Interconnect between the PS and PL (Source: Xilinx)

When the PS handles configuration or control, a general‑purpose AXI Master on the processor writes to registers inside PL IP cores, steering their behavior. For data‑intensive tasks—such as streaming video frames from PL to PS memory—high‑performance AXI interfaces are used, demanding more sophisticated software to set up DMA transfers and manage buffer coherency.

Verifying PS‑PL interactions is notoriously difficult. A 2015 Embedded Markets Survey highlighted debugging as a top design challenge and underscored the need for better verification tools. While bus‑functional models can provide an initial sanity check, they often lack the depth required to validate real software drivers and applications. Full functional models exist but can be prohibitively expensive.

Traditional verification splits the flow: each block is validated in isolation, and only after the first hardware arrives are the PS and PL stitched together. The software team typically checks that the Linux kernel carries the necessary drivers and device‑tree entries by running QEMU, an open‑source hypervisor that emulates the ARM architecture. Conversely, the logic team sequences commands that mimic software‑initiated transactions to confirm PL functionality.

Both approaches miss the true PS‑PL handshake, making subtle integration bugs hard to spot and costly to fix later in the cycle. While a development board can provide a stop‑gap, debugging on real hardware demands inserting instrumentation logic, regenerating the bitstream, and risking behavioral drift.

Co‑simulation of hardware and software offers a proactive solution: it enables concurrent verification before production boards exist, dramatically cutting debug time and cost. It also gives designers full visibility into register states and inter‑domain traffic, accelerating defect detection.

HW & SW Co‑simulation

Co‑simulation requires the logic simulator to communicate with a software emulation platform. Aldec’s Riviera‑PRO (2017.10) introduced a bridge that connects Riviera‑PRO to QEMU, allowing Linux‑based Zynq software to run inside the same simulation cycle as the HDL.

Figure 2. Bridging the HW and SW verification environments (Source: Aldec)

The bridge leverages SystemC Transaction‑Level Modelling (TLM) to expose AXI channels between QEMU and Riviera‑PRO, enabling two‑way data exchange. Engineers can then employ advanced debugging techniques such as HDL breakpoints, data‑flow tracing, and code‑coverage analysis within Riviera‑PRO, while the software side uses GDB to step through kernel and driver code in QEMU.

Because the same Linux kernel that will run on the target device is exercised in QEMU, developers confirm early that all necessary modules and configuration files are present, reducing late‑stage surprises.

PWM Example

To illustrate the workflow, consider a PWM IP core placed in PL and connected to the PS via a general‑purpose AXI interface. Software configures a register to set duty cycle between 0 % and 100 %, then triggers the core. Verifying the core in isolation misses the PS‑initiated control path; full co‑simulation ensures the pulse width is generated correctly when the Linux application runs.