( ESNUG 304 Item 7 ) --------------------------------------------- [11/12/98]
Subject: ( ESNUG 302 #9 303 #3 ) Experiences Testing With C, VERA, & Specman
> I have two questions of which answers would help us in evaluating the
> tool. First, what is your detailed lesson you learn from using VERA in
> your environment. Any caveat and pitfall of the tool contrary to mktg
> claim ? How does VERA stack up against Specman ?
>
> Second, does anyone have a similar environment as ours and use VERA as
> a cosimulator between C and Verilog sides successfully ? If yes, is
> there any catch ? How are its RPC (Remote Procedural Call) and IPC ?
> Please keep me anonymous because we're looking into a possible purchase
> of VERA.
>
> - [ Curious Minds ]
From: Tom Symons <tsymons@level1.com>
John,
I am a new user to VERA, having just adopted the tool earlier this year.
I have worked with both Verilog and VHDL, but I now prefer using VERA
over either HDL for test bench design.
In my view, a testbench is much more a software function than it is a
hardware function. I believe that is one reason why you see so many
projects using C to implement at least part of their testbench. But C
has no concept of hardware, and this makes it an awkward choice for test
benches. VERA solves this problem by giving you the software-like feel
and functionality that you're looking for with C, while still leaving
the easy HDL-like interface to hardware that C lacks.
The first thing you need to realize about VERA and cosimulation is
that VERA itself may eliminate the need to use C code in your test
bench. VERA is different than C or C++, but it does provide the same
functionality and the same ease of high-level coding. However, if you
require C code anyway (to simulate a driver, use existing code, etc.),
then VERA can help you by providing an easy link between the two
languages.
Once you make this shift to viewing a testbench as a software function,
and you have a hardware-aware tool that shares this view, then you
slowly start to see new ways that you can approach your verification.
There are not really any features in VERA that reach out and knock your
socks off at first glance, but when you take them all together, and you
realize that your test benches are becoming both more sophisticated and
easier to follow, then you'll find that it is very difficult to go
back to using HDL or C to implement your testbench.
One simple example might help you get a feel for this:
Our device was required to support both big and little-endian host CPUs.
This required that our testbench support both modes as well. In
particular, we wanted all our tests to run (and self-check) in either
mode - we didn't want to have to write separate tests. We started out
by conditionally coding memory accesses by testing a mode flag, or by
just coding it in the default mode and figuring we'd come back to add
the other mode later. Both approaches would mean lots of work and lots
of debug. Note that our testbench included test generation,
self-checking code as well as simulation of the host CPU. If you've done
this before, you'll know that it can be a real annoying problem.
Then we realized that we could make the endian mode transparent to the
testbench by using an object-oriented approach. We were definitely in
the software realm here. We created an 'object' that represented host
memory. We allocated the memory in this object and defined all memory
access functions (methods) within it. We then 'inherited' two memory
objects from this base object, one for big-endian access and one for
little-endian access. The testbench code could then be written to
access memory via the base object, which was instantiated as one of the
two inherited types, depending on which memory mode was desired. So we
just had to test each of the objects, and then access all memory without
worrying about which mode we were using.
So an annoying, error-prone problem was easily eliminated. And our
approach was straight-forward and easy to understand. Now, you can be
clever and do something similar without object oriented programming
(OOP) methods, but the end result will probably just look like something
trying to mimic OOP. I think it's much easier (not to mention more
readable) to just use the OOP constructs directly.
Then, moving on to the co-simulation arena, we made new versions of the
memory objects that allocated the host memory in C, versus having them
allocated in VERA. This allowed the memory to be easily accessed by
either C or VERA code - while still maintaining our endian transparent
access from VERA.
Our co-simulation environment consists of a host driver for a PCI device
running in a VHDL simulation. We have only just begun this stage of our
verification, but we have got both C and VERA communicating with each other.
We are using a C library format where VERA can make a call to any C routine,
but C cannot call back to VERA. This was adequate for our purposes, and
seemed a little easier to set up. You can get C callbacks if you want, but
this requires that the C code run in a separate process that communicates
with VERA over sockets.
We hired an intern to help us out with this co-simulation setup, and he
was able to get it up and running fairly quickly. I didn't do it
myself, but the goods news was that I didn't have to. There is some
tedium required to setup the cross-language calls, but they were
relatively straightforward once we understood the process.
The writer also asked about Specman. We evaluated both tools, and
selected VERA largely on price. The capabilities of the tools appear
fairly similar, but we feel that the VERA language overall is cleaner
and its OOP constructs are more complete. But Specman probably does do
a better job with the overall random generation environment.
VERA is not without it's shortcomings (the debugger in particular is
rather weak), but overall we find it to be a worthwhile tool. I really
would hate to have to write a testbench now in just HDL or C.
- Tom Symons
Level One Communications
|
|
