CURRENT FEATURE ARTICLES

Trans-Acting Lessons
Modeling and Transactors for the Simulation and Emulation World (Bryon Moyer)
Ten-Step Program
Sequence PowerArtist Identifies Ways to Reduce Power (Bryon Moyer)
Three Chords and the Truth
Aart de Geus and Synopsys go Quick to Four
(Kevin Morris)
Avoiding Failure Analysis Paralysis
Cadence Describes the DFM-Diagnostics Link
(Bryon Moyer)
Almost Instant Replay
Mentor Announces Codelink for Debugging Processor-Driven Tests (Bryon Moyer)
The Spirit of Standardization
IP Re-use Takes Center Stage (Kevin Morris)

JOURNAL WEBCASTS

NEW!! CHALK TALK Creating Secure Mobile Devices With Open Kernel Labs OKL4. In this Chalk Talk, Amelia Dalton delves into the world of software security and microkernels in mobile devices with Gernot Heiser and Rob McCammon of Open Kernel Labs. (Open Kernel Labs)

CHALK TALK Low Power Design With Xilinx and Linear Technology. Join Amelia Dalton as she chats with Mark Moran of Xilinx and Afshin Odabaee of Linear Technology about low power FPGA based designs. (Xilinx)

CHALK TALK Designing Embedded Systems With Linux and low cost FPGAs. Join Amelia Dalton as she chats with industry experts about simplifying embedded systems design with Linux running on low-cost programmable system-on-chip platforms. (Xilinx)

CHALK TALK Lowest Total System Cost With Xilinx
Spartan-3. Amelia Dalton chats with Mark Moran of Xilinx about reducing your overall system cost with Xilinx Spartan-3 family of FPGAs (Xilinx)

CHALK TALK Low Cost FPGA with Serdes Lattice ECP2M. Amelia Dalton talks with Bertrand Leigh of Lattice Semiconductor about low-cost FPGAs with multi-gigabit SerDes interface capability. (Lattice Semiconductor)

CHALK TALK Crossing the Gap between Algorithm and Hardware Implementation. Join Amelia Dalton as she learns how C++ and Catapult C Synthesis can accelerate the design, implementation, and verification of complex system-level algorithms. (Mentor Graphics)

[click here for more webcasts]

Trans-Acting Lessons
Modeling and Transactors for the Simulation and Emulation World
(Bryon Moyer)

It is not a notable occurrence for me to find myself confused at any given moment on any given topic. However, finding that I’m not the only one confused – well, that pretty much makes it a red-letter day. Within the world of SoC verification, there are numerous points of potential confusion, and I’m finding much satisfying solidarity with other folks trying to navigate the space.

Part of the problem arises from terminology and semantics. For succinctness’ sake, terms are given very specific meanings. The cognoscenti use such terms widely (sometimes in a demonstration of superior knowledge). We outsiders can get a sense of what the meaning is if the term was well-chosen but will probably be missing some specific implications. On top of that, some terms just become popular and commercially useful; everyone tries to attach themselves to such a term, whether accurate or not. After VMware went public, for example, suddenly anyone making software was doing virtualization, rendering the term virtually meaningless.

The realm we’ll delve into here is that of simulation and modeling. The technical challenge is that designers simulate at different stages of system implementation, and so may have either a very abstract or very specific representation – or something in between – of what is being simulated. In addition, simulation at an extremely detailed level can be excruciatingly slow, so, where possible, abstraction speeds things up.

Add to this the fact that a simulation environment will contain various components, and these components might have different levels of abstraction, and you can end up with a complicated scenario. Zooming out from the details, the big picture is usually split into two portions: there’s the logic you’re trying to simulate and test, often referred to as the “DUT”, or Device Under Test (imported from the test world where an actual device was being tested), and then there’s the testbench – which, continuing the analogy from the test world, would be equivalent to the tester. In other words, the tester/testbench provides a test scheme and access to and from the DUT; the DUT is plugged into the tester/testbench and is exercised. That much is pretty straightforward.
[more]