Writing testbenches when using an emulator

romi · Senior Joined: Feb 28, 2004 Posts: 88 Location: Minnesota

We have always written our testbenches using the sythesizable subset of Verilog and VHDL because we could easily then run the testbench on a simulator (NCSIM) or an emulator (Cobalt/Palladium).

We lose the advantages of high-level modeling when doing this. An alternative would be to maintain two totally different testbenches, one for each environment. This obviously requires considerably more resources. It seems like we are able to do everyhing we want to with the sythesizable subset and I'm questioning whether it's worth it to maintain two very different testbenches.

I'm looking for responses about what others have done faced with a similar situation of needing to use both a simulator and emulator to find all bugs and what features we are really missing out on by not modelling at a high-level. Maintainability? Performance? Coverage feedback?

Thanks.

alain · Junior Joined: Jan 11, 2004 Posts: 5

Hi,

I was recently visiting a customer (I can't give names obviously) that has a very nice setup: they use high-level C++ transactors to send packets in and out of their networking chip. It gives them very impressive speed in simulation, and just plain fast when switching to emulation.

The trend is to stay away from Verilog for testbench, especially the RTL subset. Go with C++: that will work through the PLI with all your existing simulators, and will pay for itself when switching to emulation. For instance, TestBenchPlus from Zaiq (one of our partners) gives you a nice layer that abstracts the simulation engine (Verilog or emulation) so you don't have to worry about any of these details, you just write your high-level transactions, go really fast and cover all the testcases you care about. Switching between simulation and emulation is literally changing a switch in the GUI.

With that methodology, you can actually run your simulations faster than if you were using in-circuit emulation (meaning connected to real hardware through bridges and what not). Plus you don't have to worry about side-effects of interfacing to slowed down hardware, so everything behaves as if running "at-speed". That's a big win to actually create interesting corner cases for instance.

Alain.

alexg · Senior Joined: Jan 07, 2004 Posts: 586 Location: Ottawa

z · Senior Joined: Jan 09, 2004 Posts: 92

miket

alain · Junior Joined: Jan 11, 2004 Posts: 5

postgenerate · Senior Joined: Jan 18, 2004 Posts: 31 Location: Phoenix

If your writing a testbench in SystemC, or one of those other proprietary short term HVL tools Smile

, then you are probably already thinking in terms of objects and transactions. That's half the battle right there. In fact if you think in terms of transactions between the testbench and the DUV you get 2 benefits even without emulation:

The next step to get to acceleration with an emulator is easy. If you planned up front, all you need to do is ensure that the last transactor, the one talking to the DUV is in synthesizable RTL. Bite the bullet and invest a bit more time in a SCE-MI approach and reap benefits of plug-and-play-ability long into the future.

Sure, you may need to give up some functional coverage in the DUV. (not totally if you choose an emulator that handles some degree of assertions in the emulator). But lets think about that. How much of your functional coverage is really coverage of the DUV fields itself? I maintain very little. Typically my functional coverage goals were obtained when 80% of the coverage scenarios could be achieved by covering items in the testbench itself.

Tom West
contact at: www.openverificationfoundation.org

rpluth · Newbie Joined: Jul 07, 2004 Posts: 1

I'm coming into this thread a little late, but since someone pointed out our
(Verisity's) solution I thought I'd respond with the salient engineering points
(and try to avoid sounding like a blatantly mindless advocate Rolling Eyes

).

As has been pointed out in this thread there is a maintenance downside to having
both a high-level testbench and a separate emulation testbench. It's certainly
possible to maintain a single verification environment that will work in both
simulated and accelerated/emulated modes. SystemC transactors can work in both
worlds, but only if connected to low-level HDL BFMs/monitors. With the
synthesizable subset of Verilog, it leaves you with a not very sophisticated
language to write these units in -- and that limits your ability to do what you
need to with this approach, which is to keep the interface between the hardware
and software at the transaction (or batches of transaction) level, the
performance-based necessity of which others have pointed out.

That's what you miss out on with the Verilog approach, but you also lose constructs
for coverage and assertions, so the best solution is one that addresses all these
concerns in one unified environment that can be used in simulation and
acceleration. That's been our goal with eCelerator (and continuing now with
SpeXtreme) -- maximizing reuse and efficiency, minimizing wasted effort and
one-off development for acceleration.

Finally, in-circuit emulation is an important methodology and putting the DUT in
the system and proving it with real stimulus can be an important project milestone,
but it has limitations; it's difficult to hit corner cases, not to mention covering
them (knowing when they're hit). Before that point, it's a more efficient use of
time to use a high-level, constrained-random, coverage-driven approach. And more
and more, engineers with emulators are looking to leverage their investment
earlier in the design cycle, by using them as a fast replacement for what they use
simulation for.

Ron Pluth

johns · Newbie Joined: Jul 13, 2004 Posts: 1

'Z's (posting of Jun 5, 2004), in response to 'alain' and 'alexg' makes some very good points.

The key to fast transaction based verification is to have the transactor itself locally managing the busy, cycle locked activity between itself and the DUT while communicating to it from the testbench using a high speed transaction oriented link. In an emulated environment this becomes especially important to retain verification performance.

But I would also concur with 'alain's comments that SystemC and other HVLs can be ideal languages for generating high level, untimed, abstract transactions that trigger activity within transactors.

postgenerate · Senior Joined: Jan 18, 2004 Posts: 31 Location: Phoenix

Hi Romi,

I'm with you and Alexg. I believe that Verilog is the best language to write the emulator-side transactors. On the other hand I am investigating a better solution.

I have studied eCelerator in great detail and without going into this topic, lets just say I still believe Verilog is the best solution.

One promising idea that I am starting to investigate now is this C++ synthesis tool called SPARK from this link:

http://mesl.ucsd.edu/spark/

Spark is open source tool that produces VHDL RTL output. Oh well, I can live with VHDL in a mixed language simulator or I'll re-synthesis to Verilog.

I have also investigated the old Cynaps tool now marketed by Forte Design Systems. This looked promising, but the Forte guys did not have time to pursue something that was part of there target use model.

Then there is the just announced Agility compiler from Celoxica. I would like to investigate this.

My bets are on SPARK.

tom west
www.openverificationfoundation.org