Open side-bar Menu
 Real Talk

Archive for September 6th, 2010

A Look at Transaction-Based Modeling

Monday, September 6th, 2010

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.

CST Webinar Series

Internet Business Systems © 2016 Internet Business Systems, Inc.
595 Millich Dr., Suite 216, Campbell, CA 95008
+1 (408)-337-6870 — Contact Us, or visit our other sites:
TechJobsCafe - Technical Jobs and Resumes EDACafe - Electronic Design Automation GISCafe - Geographical Information Services  MCADCafe - Mechanical Design and Engineering ShareCG - Share Computer Graphic (CG) Animation, 3D Art and 3D Models
  Privacy Policy