How can Verification IPs Help the SoC Testing Process?

Let’s assume that we are designing a new system on chip (SoC) which contains a processor and memory controller, as well as analog and digital peripherals like Ethernet, USB, 1-Wire and JTAG controllers.

Allow me to describe a typical verification process, and explain why I recommend the use of Verification IPs within the testing process.

The first step in the verification process is simulation which allows a verification engineer to find the most obvious bugs reasonably fast. It is the easiest, most flexible and inexpensive way of verifying a design project, especially at the block level. Another advantage of simulation is the ease of use of standardized methodologies for verifying integrated circuit designs, for example Universal Verification Methodology (UVM), which is becoming more commonly used today.

Unfortunately, due to limited computing power and the growing complexity of modern designs, simulation is not fast enough for long and complex tests.  It is mainly used to verify each component separately with a limited scope of tests. Simulation of the whole design would require a lot of time, even for simple test scenarios. However, design schedules can rarely be extended or prolonged, so engineers need to find a faster way to check the whole system on chip.

The obvious next step to allow faster verification of complex designs is hardware emulation. Using Aldec's HES-DVM and HES-7 boards, logic circuit designs up to 288 million ASIC gates can be emulated in hardware. Thanks to the support of co-emulation standards like the Standard Co-Emulation Modeling Interface (SCE-MI) and Transaction Level Modeling (TLM), engineers now have very powerful tools that allow them to verify designs with much higher speeds than simulation. Aldec provides a large base of SCE-MI based verification IPs like transactors, monitors and speed adapters which are very helpful for enabling hardware-based verification of complex designs. Let me explain what those are, and why using VIPs would simplify the testing process, improve design quality, and reduce time-to-market significantly.

One of the problems that we must face within hardware emulation is writing a testbench. Once a Device Under Test (DUT) is running inside an FPGA, we could write a synthesizable testbench and place it inside the FPGA. However this is probably not a good idea, as it would be very difficult and time consuming. In most cases it would be harder to write a good synthesizable testbench than the original design itself.

A much easier and more effective approach is co-emulation, which allows the connection of a non-synthesizable testbench that is running in a software simulator, to the DUT that is emulated in the FPGA hardware. In addition, co-emulation retains full design visibility thanks to the True RTL View debugging features built into HES-DVM. We can write complex testbenches with a high level of abstraction and test designs with speed of MHz, but we must be aware that communication between software (testbench) and hardware (DUT) is a bottleneck which can easily reduce speed. To avoid this pitfall, you should use proven VIPs called transactors to connect the testbench with the DUT implemented in a hardware emulator.

A transactor consists of two parts, hardware and software, which communicate at the transaction level. The software side allows the control of the hardware part, which writes and reads bus transfers to and from the DUT. The interface between hardware and software is optimized, so verification engineers don't have to worry about it and can focus on writing reliable tesbenches. Transactors also provide additional features like error injection and monitoring, which makes it easier to verify how the whole system manages faulty transfers.

Monitors are very similar to transactors, but they cannot drive a bus, only read transfers and translate them to higher-level messages, which are then passed to software. Transactors and monitors can be used in both simulation and hardware emulation.

Let’s get back to our SoC. After successful simulation of each component, we want to see how the whole system works. Simulating it would take too much time, so we are going to use hardware emulation instead. Fortunately, we don't have to avoid using UVM in emulation, because well-designed transactors can be used in the same way as in simulation.

Most Aldec transactors provide an additional UVM layer, which contains UVM AGENT and PROXY components. These translate UVM sequences into a transactor's API functions. Thanks to this layer, transactors can be easily connected to a UVM testbench during emulation. This makes the testing process much more efficient, as we can reuse UVM testbenches from simulation. What is more, verification engineers don't have to care about bus protocols, because these are handled by the transactors. They just have to ensure correct data and timing for each component and check results.

Considering our example SoC, a USB transactor is used to emulate a USB flash memory with a system image. An Ethernet transactor emulates a network device, and a 1-Wire transactor acts as an authorization unit to emulate a 1-Wire based “iButton” that is required to start the system. A JTAG transactor is used for collecting debug data from the whole system.

Our SoC can now boot up an operating system which is loaded through the USB transactor. We can also connect it with a software TCP/IP stack thanks to the Ethernet transactor. Additionally, transactors allow us to test how the SoC works with different speeds and interfaces such as a 100Mbit MII or 1000Mbit GMII interface for Ethernet. It is also possible to check how the SoC reacts to unexpected USB packets, Ethernet frames with errors, or unauthorized iButtons.

Positive verification with transactors takes us to a level where we can check how our system works with real data streams. This can be achieved with special VIPs called speed adapters that allow us to connect a DUT with real devices to run in-circuit emulation (ICE). The speed adapter contains only the hardware part, which is implemented in an FPGA along with the design. The speed adapter is responsible for synchronization between two clock domains, an emulation domain with stoppable clock and a real device domain with free running clock. Speed adapters are as transparent as possible, but sometimes they require some flowcontrol mechanism to satisfy protocol requirements of a given interface, when compensating for the speed difference between the two clock domains. Thus, developing a reliable speed adapter for a complex interface like USB or Ethernet might not be a trivial task. It is worthwhile considering the use of a proven VIP solution from a third party vendor. It is even better if VIPs come from the same source as the emulation hardware, as in case of Aldec’s HES-DVM and its comprehensive solutions.

With speed adapters, we can use a USB flash drive instead of a USB transactor. An Ethernet transactor can be replaced with network switch, and the DUT can be connected to an iButton holder, which allows us to use a real iButton for authorization. instead of a 1-Wire transactor that emulated it.

To connect these devices we can use an SoC Daughter Board that can be mated with Aldec’s HES-7 boards. It provides PHYs for commonly used interfaces and extends the functionality of HES-7 FPGA boards, enabling ICE use models. Speed adapters can co-exist with transactors in a single emulation build, so that we can still use a JTAG transactor to collect debug data.

Now we can run all tests with different devices to make sure that our system is working properly. If there is something wrong, we can still use the HES hardware debugger to find the problem. Furthermore, speed adapters do not require data from software, which means that they can speed up emulation. in comparison to a configuration with transactors.

Design verification has always been difficult and time consuming, but the growing complexity of modern designs makes it even harder. With verification IPs we can make the testing process much more efficient.

Transactors and monitors allow us to write high-level testbenches without going into the technical details of each interface. Moreover, we can easily use standardized verification methodologies like UVM,o that testbenches from simulation can be reused in emulation without modifications.

Finally, we are able to connect the design under verification with real devices through speed adapters and see how the design works in its destination environment. Thanks to off-the-shelf verification IPs, you can make the testing process easier and faster.

For additional information, please visit: https://www.aldec.com/en/solutions/hardware_emulation_solutions/verification_ip.