( ESNUG 313 Item 3 ) ---------------------------------------------- [3/10/99]
From: [ A Different Cisco Kid ]
Subject: "We Liked Verisity's Specman" But This Was Before "e" 3.0 Changes
John,
Please withold my name and email address.
I had a chance to use Specman for the first time on a project a few weeks
ago and I wanted to report my experiences with the tool. Our group had
evaluated both Vera and Specman as alternatives but decided on using
Specman based on:
- a strong endorsement from another group at Cisco that has been
successfully using the tool for over two years.
- the constraint-based vector generation features
- a good demo of the OO-based layering capabilities that addressed
the way we believed the environment should be partitioned
- Verisity support to help build our first project's environment
Our chip in question already had a suite of directed tests and some random
tests in Verilog, written over a year's time. The goal of our exercise
was to build a sophisticated random environment that could wring out some
more bugs. We hoped to re-use most of this work subsequent projects.
Circumstances beyond our control necessitated that the effort conclude in
five weeks.
Our experience with Specman have been very positive. With the AE's help,
we had the environment up in two weeks and, over the next two weeks, found
some serious bugs that the existing Verilog tests hadn't found.
The constraint generator is very powerful.
It allowed us to generate many different kinds of random traffic with
elegant and compact extensions to the core set of constraints. This is
one of the best parts of the tool.
The OO-derived approach allowed us to build a core set of modules that
can be used for other projects. The extensions and constraints to the
core modules were well isolated in device specific files and tuned
the behaviour of the environment to the use at hand.
As we became more familiar with the "e" language, we found a wealth of
well-thought out primitives that made the job of building the environment
much easier. In particular, the "list" primitive, with its many predefined
methods seemed a natural fit for building many stubs driving stimulus
as well as for monitors that checked correctness of the chip's behaviour.
The GUI-based debugger is well integrated with the tool and was both
powerful and easy to use. It allowed us to find the causes of failure,
either programming or RTL, very quickly because of the intuitive
representation of the data structures and thread tracing. Windows where
breakpoints are set or thread status examined show the actual source code
written with the appropriate sections highlighted.
I think you can deduce that we were rather pleased to find the tool better
in practice than in the "advertisements", a rare occurrence these days.
There are some drawbacks to using Specman, primarily the learning curve,
but they weren't such a big factor for our group:
the unique language -- it takes a while getting used to the
peculiarities of the syntax & naming conventions
selection of constructs -- we got a jumpstart on this issue because
the field engineer provided a lot of help while
our environment was being built.
In general the Verisity field support has been very quick in responding to
questions and having issues resolved. Verisity is alpha-testing a set of
methodology guidelines that layer over the normal documentation. It seems
to cover one of our areas of concern.
- [ A Different Cisco Kid ]
[ Editor's Note: Recently, a Synopsys/VERA salesman (VERA is Specman's
rival) told me that Verisity has fundamentally changed the Specman "e"
language such that "e" 3.0 is no longer backward compatable with its
pre-3.0 versions. The VERA salesman bragged that he was getting a good
number of angry Specman customers switching over to VERA because of this
lack of backward compatibility. Can any users out there confirm or deny
Verisity did this and, if yes, has it had as dramatic an impact as this
obviously biased Synopsys/VERA salesman is claiming? - John ]
|
|
