( DAC 03 Item 10 ) ----------------------------------------------- [ 01/20/04 ]
Subject: Verisity Specman "e" vs. Synopsys Vera vs. System Verilog
UP IN THE AIR: Although Aart would like you to think that his System Verilog
is taking over the chip designer world by storm, the responses in this survey
are all over the map. Verisity Specman "e", Synopsys Vera, and Synopsys
System Verilog each have their own camps of fanatical supporters. Each side
gives viable arguements as to why their language will win and why the others
will fail. What's the truth here? You tell me. My hat is off, though, to
Verisity for finally making "e" an IEEE open standard language. Smart move.
Grep on "Specman" and you'll find a lot of their users here, too.
I'm currently a 75/25 VHDL/Verilog guy. I'm playing wait and see on
System Verilog.
DesignWare is too expensive. Should be bundled for free with DC license.
- Kevin Hubbard of Siemens
I like what I've see in System Verilog -- it really should be the next
HDL I use. Now if all the vendors come through with their promised
support, everyone wins.
- [ An Anon Engineer ]
We're interested in Vera.
- Damien Chardonnereau of Iroc Tech.
I believe that all should be a one common language. As the fight is
over, all should align to Verilog. This is the reason that we chose not
to use at this stage neither Specman nor the other verification languages
(but we do use Real Intent tools from Verix)
- Yuval Itkin of Metalink Ltd.
IBM RuleBase and FOCS.
- [ An Anon Engineer ]
Languages are often used to simlify tools implementation. For the long
term these may disappear and hidden by standard languages like C or C++
models.
- Ahmed Jerraya
Just starting to learn Vera. Haven't used it much but looks like it most
useful for verification purposes rather than design.
- [ An Anon Engineer ]
For functional verification, Verilog is inadequate and cumbersome.
Macro-expansion of Verilog using Perl, for instance, is a poor man's
alternative. Most people who claim to use just Verilog use the PLI to
connect to a C environment that they have written. The rest use
languages like Vera or Specman.
Specman is well suited for networking applications since the AE's can
actually set up a working environment for starters. The language is
somewhat awkward and buggy, but powerful. It is expensive. I haven't
used it in the last two years, though I used it for three years before
then.
Vera is new, cheap and versatile but requires more work to build a
working environment. Like Specman it has bugs, especially in the new
features it has "borrowed" from Specman. We have recently been looking
at the coverage features of Vera to make sure corner cases are tested
regularly.
Both Vera and Specman slow down simulation dramatically compared to plain
Verilog (especially without PLI hooks to C). They also complicate the
use of hardware accelerators. However they save on engineer time.
It takes a while for any new language to be stable enough to be good
enough for production use by a large group so I can't comment on the
newer languages.
- Viranjit Madan of Sun Microsystems
Any move away from a standard is just a ploy to grab market share and
will be counterproductive to the industry. The result will be poorer
quality tools and underserved customers.
- Luke Simonson of UCLA
In all honesty, I think whatever next generation RTL language got to be
based on Verilog. I think System Verilog has an edge.
- [ An Anon Engineer ]
Verilog/VHDL can never be replaced.
- [ An Anon Engineer ]
Everyone sounds like Verisity now. The whole world has PSL/Sugar
assertions, and several established tools have added constrained random
vector generation. Does Verisity have an edge? They say their
constrained random vectors are third generation. (I must admit, some
of their competitors schemes seemed poorly thought out.) Verisity's
functional coverage is almost certainly the best. Can they explain all
this to customers? In my experience Verisity sales pitches are often
not aimed well at the level of their customers, and are often burning
bush talks about paradigm shifts or mired in the details of Specman.
Let's face it though, this is not a simple tool to explain.
- John Weiland of Intrinsix
We purchased Specman 5 years ago and could not have done the chips we
have without it. At the time there was no good alternative because we
had no skill using C. I still think that it is the best alternative out
there unless you have a lot of C experience. E is not a difficult
language to learn and is easy to use, coming from a Verilog Only
perspective. Some of the concepts are difficult, but these have to be
learned no mater what HVL you use.
System Verilog looks good but lacks the power we need to do the size of
chips we do. If you need incremental upgrades to your environment this
could be a good choice in 2008 which is when it appears it will be fully
implemented by the Major simulators.
Can we say standards war? Specman's big downfall is its cost.
- Steven Jorgensen of Hewlett-Packard
We're big e users. At least this is a language designed to the need it's
intended to satisfy. It's also higher level than a "generic assembly
language". :-) Specman is one of the central engines of our
verification flow and we're pretty happy with it. It would be nice if it
were faster of course.
- Kevin Jones of Rambus
We have been using Specman for a couple of years, and are generally
pleased with it's capability. We do not use Vera or TestBuilder.
When we evaluated them a couple of years ago Specman was superior
in function, capability, and we got a great deal from Verisity.
- Al Scalise of Silicon Image, Inc.
Specman is an extremely well thought out tool. Their Aspect Oriented
Programming, where pretty much any struct's member list and their
properties/contents can be modified by overlaying one file. This
yields extremely well for test writing and quick hacks. It keeps the
golden classes working and untouched.
The e language is terse and intuitive and does a lot of things for you
automatically. Vera is more C++ like, does not have "when" based
inheritance, and AOP is still not released. The constraint resolver
inherently works well with the auto-gen functionality in Specman,
whereas it is a huge hurdle for the Vera constraint resolver, where
the auto-gen feature is missing and needs the user to write a new()
for everything. This leads to a lot of hand-holding and more code
to maintain, especially when you are generating hierarchies of classes.
Specman should take lesser man months to create a stable release of
environment and tests including coverage for a given project. It is
certainly lesser lines of code, to maintain. It instills a flow
which works well.
The major minus... the per license cost, especially when Vera is
bundled now with VCS simulator.
- [ An Anon Engineer ]
Verisity Specman:
Pros:
+ Easy protocol layering using sequences: I used this during our last
project where I had to drive a Ethernet over ATM scenario into an
UTOPIA interface. Compared to its complexity it is really simple to
generate the stimuli.
+ Constance in random pattern generation: even if a struct is extended by
adding or removing members all old members get the same 'random' value
if the same seed is used for generation.
+ The Verisity consultants: IMHO this is the most important point for
picking Specman as your tool of choice. Introducing a new tool is
always kind of problematic because it is difficult to consider
the emerging friction losses in a project plan. Verisity addresses
those points by offering something which is called an EPL (Early
project launch). For each new project a team of Verisity engineers
ramps up a testbench which fulfills the project's basic needs so that
newbies have a well-defined starting point. One doesn't need to start
from scratch with all the implied disappointments and set-backs.
Cons:
- The tool's resource consumption. It significantly uses memory and CPU.
- Debugging sequences. The built-in debugger isn't able to handle the
recently introduced sequence structs. It is very hard to debug anything
which is related to them.
I hope it helps a little for your DAC trip report.
- Martin Baumert of Infineon
We have been using Specman for 7 years now. Overall it's a powerful
verification tool, and we're happy with it. It has a strong generation
engine which we use heavily, self-checking, and coverage of which
we use some.
The stability/compatibility between Specman releases forced us to stick
to a release from three years ago for our chip spins. Specman
performance is also something that has to improve, and we're looking
for the new release to do that.
The reusability aspect is very important to us, and our e environment
has lent itself to reuse again and again. The e reuse methodology
is even more promising, and we decided to adopt the latest release
on our new chip. As a start, we'll be sending the whole verification
team to a reuse training.
- Doron Stein of Cisco Systems
Verisity offers a well thought out verification methodology.
Random Generation engine - This is neat technology where you constrain
fields in your environment so that the random generator chooses values
for those fields while obeying your constraints. Sounds easy right?
It works great but when it doesn't do what you want it to do, or when
you give contradicting constraints, it can be a bear to resolve. Granted
they have tried to give tools to debug these generation problems but it
is by far the worst and most time consuming part building a verification
environment. I've accumulated a few grey hairs fixing these.
Functional coverage - This is a great feature for which I haven't heard
of an equal out there (I'd like to hear of any.) Being able to gather
statistics of scenarios that the random generator has produced with
ability to do crosses and transition coverage gives much needed insight
into how well your environment is testing the design.
Reuse Methodology - Verisity came up with some reuse methodlogy manual
that would allow maximum reuse of verifications components. They also
provided additional features in the language that would allow this.
Extensive examples were provided which have been used by many that I
know as baselines for their verification environments. This has been
of much practical help.
Step through debugging environment - The ability to easily step through
a simulation and debug problems is very nice and has helped me find bugs
in my environment quickly.
The error messages from Specman can be quite obscure and could use some
work. Also, I have found it a pain in the neck to make Specman work in
environments that have C models, Denali models, verilog all together. I
don't know if there is a good solution to this but I can't help but
mention it.
BTW, Testbuilder users that I have talked to have complained a lot about
the number of core dumps they have had. I haven't had this problem with
Specman.
As with any tool, once I learnt the quirks, I have been able to build
testbenches pretty easily and found lots of bugs quickly.
- [ An Anon Engineer ]
I think there are too many languages and I am not going to jump to a
language that is proprietary and maybe disappearing. This is not good
news for "e". You can call it open or standard how much you want, in my
books it is not a standard until it is an IEEE standard. I think the
future looks bright for System Verilog if only Accellera will donate it
to the IEEE.
- Anders Nordstrom of Elliptic Semiconductor
Tempermentally, I'm very averse to committing to anything language that's
proprietary not an open standard. Although I like what e can do, I don't
like placing ourselves in a situation where one company can squeeze us
for more money in a year or two.
Being a Verilog user, I would really like to see System Verilog totally
take over, but I have my doubts about this happening. I don't see us
committing to System Verilog until it's very clear what is the
trajectory is.
- Tomoo Taguchi of Hewlett Packard
None of the vendors or presentations I went to had anything to say about
new developments targeted for VHDL users.
All the non-Synopsys/Cadence folks were party line non-committal about
System Verilog vs Verilog with PSL/Sugar. They all promised support of
what ever was out there as soon as it became available and stable. That
said, from the way the discussions went, it was clear that only Synopsys
had any say in what System Verilog was going to be like.
- [ An Anon Engineer ]
Verisity's Specman "e"? - IEEE Standardization of the 'e' language is a
great move and a risky move. The 'e' language is a great verification
language and opening it up could bring even more 'e'-players and more
'e'-credibility into the verification game. It is also a very risky move
on the part of Verisity. I have been shamelessly stealing VHDL features
to add to Verilog for years. Once 'e' becomes an open standard, I will
probably want to see 'e' features also added to System Verilog. I think
Verisity has a bright and talented team so I hope they know what they are
doing by making their language IEEE open and freely available.
Synopsys Superlog/System Verilog & Vera? This is the HDL future. This
is the best of Verilog, VHDL, Superlog, Vera, PSL, Direct-C compilation,
and more. I can hardly wait to use the new System Verilog features on
a real design.
- Clifford Cummings of Sunburst Design
|
|
