( ESNUG 296 Item 1 ) ---------------------------------------------- [7/23/98]

Subject: ( ESNUG 295 #12 )  A User's Comparison Of VERA vs. SpecMan

> Systems Science and Verisity are two companies providing integrated VLSI
> verification environments that work seamlessly with most Verilog (& VHDL)
> simulators and even some emulation systems.  Systems Science sells their
> VERA language and tools built on it, while Verisity sells a tool called
> SpecMan using their "e" language.
>
> Like me, I presume that many of you have looked at one or both (& possibly
> other offerings) in some detail, and I'd like to trade notes.  Any takers?
> Can we do it here on ESNUG?
>
>   - Paul Tobin
>     Fusion MicroMedia


From: Rudolf Usselmann <rudi@logic1.com>

John,

I haven't used SpecMAN, nor do I know any insides in to SpecMAN.  I have
used VERA for over two years now and found it very helpful in my work.
Both of my clients (very large companies) who use VERA did evaluate
SpecMAN and choose VERA instead.  Both projects where in networking
applications and had a headend/master with multiple clients.  My
responsibility both times was to verify a chipset by architecting an
environment from scratch and implementing it.

I am not associated in any way with System Science (the makers of
VERA) nor am I being compensated by them (or anyone else) in any way
for writing this.  I just like VERA and hope it will continue to grow.

I am open to compare specific features of SpecMAN and VERA if theres an
SpecMAN expert out there who is willing to have a friendly comparison.


At first, VERA appears a bit exotic, since it looks more like C/C++.
However, even without C/C++ knowledge many of the team members where
able to pick up the language very quickly.

VERA integrates in to verilog as one black box (single module) that
interfaces to the rest of the system. At first this might appear as a
draw back, but later on everyone seemed to appreciate to have one
central point for all exchanges between VERA and the rest of the
system. Besides this module level interface, VERA also allows the user
to attach to any signal in the design by specifying the full verilog
path to the signal.

One of the strong points of VERA, is the way you specify the interface
to your design.  Each interface has its own clock domain, and can
consist of module level pins or any arbitrary signal within the verilog
design and environment. Each signal in an interface is driven and
sampled in respect to the interface clock, unless it is declared as an
asynchronous signal, at which point it can be sampled and driven at any
time. The individual interfaces can be bound together to create larger
interfaces containing numerous clock domains. This is done by creating
port definitions (virtual interfaces).

Tasks that communicate with the design can be written without having a
specific interface in mind. They can be written to adhere to a port
definition, and the actual interface to which they supposed to attach,
can be specified when the task is called. A good example for this is
when one wants to verify a multi port networking medium, and has a task
that lets say generates packets. When calling the task one can choose
the interface (those the port) on which to generate traffic. I have
found this a very powerful and useful feature, reducing code complexity
and making the architecture of your testbench alot simpler.
On each signal a Value Change Alert (VCA) can be setup to monitor
unwanted changes.

VERA supports object oriented architecture. Users can create classes
containing data structures, and tasks that are unique to them. Classes
can be expanded and derivative classes may be created. A 'new' method is
provided for initialization of classes. There is no 'destruct' method,
as VERA does automatic garbage collection.

Except for the interface part, VERAs syntax looks like a mix between
verilog and C++.  The code structure is like C, no always or assign
statements. State machines or continues assignments can created by
VERAs very nice implementation of fork/join.  The thing that makes VERAs
fork/join so effective, IMHO, is that you can specify when to join:
immediately without waiting for any of the statements to finish, when
any of the statements finish or when all statements finish.
In addition to all the standard language constructs, VERA has a very
powerful expect statement, that allows a signal to be sampled within a
window, and generate an error if the expected action did not occur
within the specified time frame. It takes only one line of code to do
the above expect!

All tasks in VERA are re-entrant, and as mentioned before, can be
written to communicate with the rest of the system by using specific or
virtual signals. When virtual signals are used, the task is bound to an
interface when it is called.

Another feature in VERA is string manipulation. I have read that VERA
is capable of pretty powerful string operations, but have never used
these features yet. This feature was added recently.

VERA supports a variety of synchronization primitives. They are all
very straight forward and easy to use. One of the most useful features
I found, are mailboxes. Mailboxes allow different tasks in the system
to synchronize to each other and exchange information.

A new feature in the latest VERA release is the ability to communicate
between several independent simulation using VERAs socket interface.
This is essential for very large distributed simulations. One could
simulate one chip on system a and another chip on system b, and send
information back and forth between the two simulations at a much higher
speed that simulating both chips on one system, if feasible at all.
The sockets can also be used to communicate to C programs running in
parallel to your hdl simulation.

Last but not least, there is the VERA debugger.  With time, System
Science made the debugger to be a very helpful tool.  It looks similar
to some of the C debuggers I have seen on Suns.  It has a source code
window where you can monitor the execution of the current context. It
allows you to view and modify variables and set additional breakpoints.
It still lacks the possibility to view a class and all of its members
or an array.  But it is still a helpful tool if you are stuck.

    - Rudolf Usselmann, Consultant
      Logic One, Inc.



 Sign up for the DeepChip newsletter.
Email
 Read what EDA tool users really think.


Feedback About Wiretaps ESNUGs SIGN UP! Downloads Trip Reports Advertise

"Relax. This is a discussion. Anything said here is just one engineer's opinion. Email in your dissenting letter and it'll be published, too."
This Web Site Is Modified Every 2-3 Days
Copyright 1991-2024 John Cooley.  All Rights Reserved.
| Contact John Cooley | Webmaster | Legal | Feedback Form |

   !!!     "It's not a BUG,
  /o o\  /  it's a FEATURE!"
 (  >  )
  \ - / 
  _] [_     (jcooley 1991)