What is transaction-based acceleration, what benefits are users seeing, and where does it fit into the verification cycle? That's the topic of a paper that will be given at CDNLive! Silicon Valley Oct. 26, and as such I thought some background might be helpful. Much of the following information comes from a recent conversation with Raj Mathur, senior product manager at Cadence.
- In a previous blog, I wrote about the difference between simulation acceleration and emulation:In acceleration, the design is typically running on the hardware while a simulation testbench runs on the workstation. If the testbench interface is transaction-based, the result is transaction-based acceleration.
- In emulation, the entire design and verification environment is generally running on the hardware. In addition to the hardware in the emulation box, portions of the design or the testbench may also be running on external target hardware through in-circuit emulation.
(Things are not always so simple in real life. The Cadence Palladium XP Verification Computing Platform, for instance, is both an accelerator and an emulator, and it allows a "hybrid" mode that can combine acceleration with in-circuit emulation).
Acceleration speeds up a simulator, and should provide most or all of the benefits of simulation. However, acceleration has traditionally used a signal-level interface between the software testbench and the accelerated DUT. This involves bit-level communication and can result in a severe bottleneck due to the communication channel or the testbench itself.
Coming Up to Transactions
With transaction-based acceleration, that interface is brought from a signal level up to a transaction or "message" level. This greatly reduces communication channel overhead. As a result, Raj said, transaction-based acceleration may run 50X, 100X, or 1000X faster than software simulation, depending on the testbench.
Several recent examples have been documented. In one, Hitachi achieved a 100X simulation speedup using transaction-based acceleration. In another example, Hitachi achieved a 10,000X performance boost using transaction-based acceleration and high-level synthesis. In a third example Sigma Designs, a media processor SoC company, processed one standard definition (SD) video frame in 1.9 seconds using transaction-based acceleration compared to 15 minutes in simulation.
As shown below, the transaction-based communication between the workstation and the hardware is handled with the Accellera Standard Co-Emulation Modeling Interface (SCE-MI 2.0) standard. A "proxy" model on the software side converts transactions to messages and then passes them to a communications channel interface. In general, no state-specific information is transmitted. The communications channel(s) buffer and transfer messages to and from the proxy model and bus functional model (BFM). These communications channels are formed using SCE-MI. The BFM receives messages from the communications channel and converts them to appropriate state changes on the signal-level interface. You can learn more about this in a recent whitepaper called "De-Mystifying SCE-MI transactors for simulation acceleration."
Cadence offers verification intellectual property (VIP) transactors that supply proxies and BFMs for common protocols such as PCI Express and USB. In the Cadence environment, you can run a mixed signal-level and transaction-based acceleration. This is useful when some parts of the verification environment are still signal-based, but not so much as to seriously slow the overall communications.
So where does acceleration fit into the verification cycle? At the start of the RTL verification process, little or nothing has been synthesized, and users typically run software simulation only. Next, when some portions of the design are synthesized, or if behavioral constructs can be supported in the hardware, they can be moved into the accelerator/emulator.
This is when acceleration comes into the picture. Users often start with signal-level acceleration and then move into transaction-based acceleration to attain speeds approaching those of emulation. To make this work, the tool chain must provide a smooth transition from simulation to acceleration and emulation. In addition, the availability of VIP can greatly ease adoption.
Finally, when the entire design and the testbench are synthesized, emulation can commence, along with its blazing fast speeds and capability to run on target hardware. Transaction-based acceleration is not only a convenient stepping-stone between pure software simulation and pure hardware emulation, but it also increases virtual accessibility for software developers who need to validate their software program or algorithms earlier in the design and verification phase.
Transaction-Based Acceleration at CDNLive!
The CDNLive! paper, scheduled for the System Realization track at 1:35 p.m., is titled "Transaction Based Acceleration: Strong Ammunition in any Verification Arsenal." Varun Gupta from Cadence is a co-author. The on-line abstract says the following:
Hardware acceleration of the existing testbench not only allows the discovery of deep bugs by enabling any simulator to be accelerated while maintaining metric-driven verification methods and use models, but also serves as a unique bridge between simulation and in-circuit emulation. This early-phase acceleration, which enables gradual movement of behavioral design blocks into the synthesizable domain, allows smoother transition into and faster bringup of in-circuit emulation, improving overall productivity and time to market.
Separately from CDNLive!, a recent blog interview shows how a customer, Silicon Hive, used transaction-based acceleration to speed its verification process. This is a technology that is quickly gaining attention.