by Hemant Sharma and Hans van der Schoot; Mentor Graphics
The standard practice of developing RTL verification and validation platforms as separate flows, forgoes large opportunities to improve productivity and quality that could be gained through the sharing of modules and methods between the two. Bringing these two flows together would save an immense amount of duplicate effort and time while reducing the introduction of errors, because less code needs to be developed and maintained.
A unified flow for RTL verification and pre-silicon validation of hardware/software integration is accomplished by combining a mainstream, transaction-level verification methodology – the Universal Verification Methodology (UVM) – with a hardware-assisted simulation acceleration platform (also known as co-emulation). Necessary testbench modifications to enable this combination are generally nonintrusive and require no third-party class libraries; thus, verification components from customer environments are readily reusable for pure simulation environments, different designs using the same block, and different verification groups.
This common-source SystemVerilog/UVM acceleration platform offers substantial speed-up for functional verification in terms of simulation cycles per second. When subsequently leveraged for software validation, hardware-assisted simulation acceleration of 2 to 3 orders of magnitude (or more) makes it practical for software engineers to co-validate software against hardware far in advance of silicon. Pre-silicon validation boosts the efficiency of post-silicon validation through early detection of hardware/software integration issues.
A TWO TOP TESTBENCH ARCHITECTURE
Unlike a conventional verification environment that has both synthesizable and non-synthesizable components instantiated in a single testbench top, as shown in Figure-1, we create an acceleratable testbench that is partitioned into an HDL and an HVL top.
Figure-1. Traditional Simulation Testbench
As shown in Figure-2, HDL_TOP has all the synthesizable components instantiated in it. HVL_ TOP contains all the untimed behavioral components. Synthesized HDL_TOP runs on the hardware accelerator and HVL_TOP runs on the simulator.
Figure-2. Two-top Testbench for HW-assisted Acceleration
The HDL and HVL partitions of the model communicate at the transaction level. This communication is enabled by using a SystemVerilog virtual interface based method and/ or a core-proxy based method.
A virtual interface is a SystemVerilog variable that can hold a reference to a concrete SystemVerilog interface instance. The Mentor Graphics Veloce® emulation platform supports a synthesizable transactor interface that provides communication between the emulator and testbench. Transactor interfaces encapsulate synthesizable SystemVerilog tasks and functions. A driver calls a function or task using a reference to a synthesized SystemVerilog interface to access DUT pins and signals. Similarly, a monitor waits on a function call from a transactor interface. All accesses to DUT pins and signals are thus strictly confined to the HDL partition. All such functions and tasks are restricted to synthesizable data types.
A core-proxy is a C/C++ core model based on communication semantics between HDL and C, as defined by SCE-MI 2. A SystemVerilog API wrapper class connects a C-based proxy to the rest of the testbench. The proxy class maintains handles to components in the synthesizable transactors and uses DPI function calls or SCEMI pipes to communicate with these transactors. In this approach, C-based proxy class functions provide APIs that can be used by a SystemVerilog or SystemC driver to communicate with the DUT.
A conventional software validation platform usually involves an FPGA prototyping platform with a JTAG connection to a software debugger. Typically, a dedicated team is responsible for partitioning the system on chip (SoC) RTL for a specific hardware platform to meet capacity and peripheral constraints. As more and more SoCs have embedded processors, there is a growing requisite for hardware/software co-validation. Earlier access to complete RTL, maintaining system bus connectivity across submodules and protocol peripherals, is an essential step of the verification process.
Our approach for hardware/software co-validation is to leverage the verification testbench to access the same RTL as used by design verification engineers. A user can access the SoC system bus with either a UVM testbench or a C API embedded software model to access the complete RTL.
Figure-3 shows a virtual machine communicating with the Mentor Graphics Veloce emulator to validate software driver development using a proxy-based transactor. Such integration provides the complete SoC RTL in the hardware accelerator with full visibility.
THE UNIFIED FLOW
The partitioned domains are bridged using a SCEMI compliant, high-performance, transaction-level communication link between the hardware and software provided by the Mentor Graphics Veloce/TBX® solution. This allows the timed portions of the testbench and the DUT to be accelerated in the Veloce emulator without affecting the untimed UVM domain.
It is imperative that the entire environment —especially including the untimed UVM components and the timed transactors — is single source for both conventional simulation and the co-emulation flow. Thus, any model written for the emulator can also run in simulation alone, using a SystemVerilog compliant simulator. This eliminates the need to maintain separate models and environments. Transaction-level models that drive bus functional models maintain a transparent separation between the stimulus and the DUT pins. UVM layering concepts and transactionlevel communication techniques provide the ability to swap out UVM-based directed and pseudo-random stimulus scenarios and apply, instead, real application software developed for the DUT, without sacrificing debug capabilities.
Clock and reset transactors should be designed to take advantage of the variable clock delay feature of the Veloce/ TBX emulation platform. This enables the verification and validation teams to run their tests at various clock frequencies without recreating the RTL image for emulation.
The custom drivers and monitors are modeled using abstract classes and SystemVerilog interfaces.
Last but not least, in order to monitor system bus activity and inter-block communication for improved debug visibility, inline SystemVerilog assertions are inserted into the DUT. Assertions and assertion coverage are supported by Veloce/TBX for synthesis into the emulator with highly efficient transfer of potentially large amounts of coverage data out of the emulator into the testbench domain. The well-known benefits of assertion-based verification coupled with the high-performance of emulation considerably reduced the total turn-around time to detect and resolve bugs.
A typical SoC has a single processor managing multiple subsystems or multiple processors designated to perform specific tasks — all communicating via a system bus. A proxy-based transactor can provide a master and slave interface to the system bus. Such an implementation provides a single RTL image that can be used with a SystemC testbench or a UVM testbench.
Software teams usually have a system model available for early code development. SystemC has emerged as the language of choice for these models. Hence, it is important to have language interoperability of the transactor for portability between SystemC models on the one hand and SystemVerilog testbenches on the other hand. There are various hypervisor/virtual machines available to emulate the processor architecture. One such virtualization software package is QEMU, which can run in conjunction with the Mentor Veloce emulator. Software users can run their executable code in virtual machines that communicate with the RTL via a proxy based system bus transactor. As a result, the same RTL image is available for verification and validation with full visibility to debug.
Figure-3. SW driver-development with HW-assisted acceleration.
The co-emulation flow and resulting unified verification and validation platform has made it possible for SoC design verification and software validation teams to use the same RTL image for their respective test scenarios. Moreover, software validation teams can now have much earlier access to the RTL code than in previous projects of similar scope.
Recently deployed at multiple customer sites, this unified verification and validation flow has demonstrated a near seamless transition between RTL design verification and software/firmware validation. It significantly reduces the turn-around time for time consuming yet essential tasks, including debug and regressions. It takes advantage of very fast emulator performance to handle longer and more tests to cover more design requirements and uncover more design bugs. In essence this unified flow has eliminated the productivity and quality penalties associated with creating and maintaining different verification and validation platforms.
The single-source verification environment for both simulation and emulation provides test speed ups of at least an order of magnitude. This translates to tests that took nearly a week to run in simulation now completing in just over an hour on the co-emulation platform. With the speed of an emulator and a combination of directed tests as well as real-world scenarios, verification engineers will be able to validate the SoC more holistically.
Back to Top