Versal ACAP Simulation Challenges

The electronics industry is all about optimization, and always has been. For example, you might think of system on chip (SoC) as a relatively recent term, coined this century. However, many regard the silicon that appeared in digital watches in the 1970s as constituting a system on a chip,  as it reportedly contained the equivalent of over 40 logic ICs.

Personal computing in the 1980s and cell phones in the 1990s fueled further optimization, cramming more and more design logic into a single chip. Under today’s definitions, a SoC is considered to include at least one processor, some memory, and I/O.

Also worthy of note is that field programmable gate array (FPGA) technology is older than you might think. That technology, if not necessarily the term, dates back to 1984 (the same year Aldec was established).

In 2012, industry saw its first SoC FPGA; an SoC (with a hard processor core) alongside traditional FPGA fabric, since when devices have been getting increasingly complex. For instance, AMD’s Versal Adaptive Compute Acceleration Platform (ACAP) SoC FPGA, announced in 2022, builds on the capabilities and performance of the company’s popular Zynq 7000 and MPSoC families.

As with those families, the new device’s architecture includes many domain-specific IPs. Also, it introduces a programmable network on chip (NoC) and three dedicated groups of engines: scalar engines, adaptable engines, and AI engines (AIE - a combination or AI/ML and signal processing chipsets for functions and workloads that need vector processing, domain-specific parallel processing, and high compute efficiency). It is an impressive device, and large too when you consider that one of the devices in the Premium series (the V1902) has 8.4 million look-up tables (LUTs) and 18.5 million system logic cells.

As mentioned, our industry is all about optimization. Just because we have target with plenty of space for software to run and for functionality to be described at the register transfer level (RTL) does not mean our designs should not be optimized for performance and power. They also need to be thoroughly verified.

As we have written about in the past, verifying a device through simulation before targeting physical hardware is highly recommended. It greatly reduces the risk of bugs making their way into a production device. It also enables software and hardware engineers to work together (in a continuous integration fashion) before physical hardware is available.

By using different types of simulation and appropriate design sources, models, and tools all of Versal ACAP’s block types can be verified. See Figure 1.

Figure 1. Different types of simulation are required for Versal ACAP.

For hardware developers, the RTL can be simulated (with cycle accuracy) in the traditional way, whereas software developers can use Quick Emulator (QEMU - the open source, cross-platform, ‘virtual’ system emulator) to run their software ahead of hardware being available.

In a co-simulation environment, RTL simulation and QEMU emulation can run together, and be used for verifying Versal ACAP’s AIE and its NoC, for example. Moreover, this is a very flexible approach, and made even more so thanks to the availability of block models from AMD. For each block a cycle accurate (or worst-case cycle approximate) version is available as well as a model more tailored for speed. Designers can therefore choose models with the level of detail or speed performance characteristics that best meet their simulation requirements.

Understandably, for system simulation the simulated hardware and emulated software need to interact. Aldec enjoys a close working relationship with AMD/Xilinx and, working together, we devised a Remote Port Bridge connection to sit between QEMU and our mixed simulation environment Riviera-PRO.

The bridge runs on Unix sockets or TCP so, for example, when a QEMU transaction comes in it serializes when it reaches the hard blocks, is transferred to the SystemC side, is converted into a TLM payload, and is then further injected into the RTL ports.

Figure 2 – Developed in collaboration with AMD, the Remote Port Bridge is a protocol and framework that uses shared memory to communicate transactions and synchronize time between devices or simulation environments. Note: though only one bridge is shown, multiple are supported.

In this way it is possible to simulate the entire Versal ACAP SoC, including the communications between all parts; all without physical hardware to hand, as the following video shows.

The glue that holds the co-simulation together is very much AMD’s Vitis development environment. It integrates all of the domains and has a linker that generates the complete hardware emulation setup.

If you would like to learn more, we recommend you watch our Versal ACAP Simulation Challenges Webinar, from which blog has drawn a few key points. A recording of the webinar is available here https://www.aldec.com/en/support/resources/multimedia/webinars/2232