 | Lauro Rizzatti General Manager of EVE-USA |
A rather new methodology for system-on-chip (SoC) project teams is transaction-based modeling, a way to verify at the transaction level that a design will work as intended with standard interfaces, such as PCIe, and SystemVerilog-based testbenches.
This methodology enables project teams to synthesize the processing-intensive protocols of a transaction-based verification environment into an emulation box, along with the design under test (DUT). They can then accelerate large portions of the testbench with the DUT at in-circuit emulation (ICE) speeds. Increasingly, this is done concurrently with directed and constrained random tests. The adoption of this methodology has been accelerated by the advent of high-level synthesis from providers such as Bluespec, Forte Design Systems and EVE.
Today’s emulators look and act nothing like previous generations. They are fast, allowing the project teams to simulate a design at high clock frequencies, and more affordable than ever. For an emulator to be a complete solution, however, it must be able to effectively interact with designs without slowing them down. This is where transaction-level modeling can help by providing checkers, monitors and data generators with throughput the DUT requires.
Benefits of transaction-level modeling include speed and performance to handle bandwidth and latency. For example, the latest generation emulators can stream data from a design and back at up to five million transactions per second.
Reuse is another benefit because emulation can separate protocol implementation from testbench generation in a way that testbenches can be assembled from building blocks.
Various languages can be used to build transaction-based testbenches, including C, C++, SystemC or SystemVerilog with the Standard Co-Emulation Modeling Interface (SCE-MI) from Accellera. Testbenches drive the data to register transfer level (RTL) design blocks.
Project teams most frequently buy off-the-shelf transactors for common protocols and design their own for a unique interface or application. Typically, a custom transactor for an interface is a Bus Functional Model (BFM) or Finite State Machine (FSM) written in Verilog register transfer level (RTL) code or behavioral SystemVerilog using a transactor compiler. More often, project teams have a similar piece of code that can be converted into a transactor.
Project teams have reported numerous benefits of this emerging methodology, especially because they can develop tests faster than directed tests. Moreover, they don’t need the in-depth knowledge of the SoC or protocol. And, testbenches can be reused when the target standard is used in another design.
Pay a visit to any project team anywhere in the world and you’ll find that they implement a whole host of verification and test methodologies on an SoC design. More and more, transaction-based modeling is gaining widespread acceptance on even the most complex of designs, shortening time to market and easing the project team’s anxiety.