( ESNUG 488 Item 5 ) -------------------------------------------- [03/01/11]
Subject: (ESNUG 487 #4) Vera dying, but Specman "e" is quite alive and well!
> New projects are coming up. Our verification people are trying to decide
> between Cadence Specman "e" vs. Synopsys System Verilog + Vera (VCS NTB).
>
> Q 1.) Which functional verification language would you choose
> (and why) for your NEW projects?
>
> Q 2.) Should we migrate our legacy Specman "e" over to SV? Is it
> worth the expense?
>
> Our old timers know Specman "e" quite well. They know its tricks. Our
> younger engineers think "e" is dying; that System Verilog is the future.
>
> Both agree this is a Cadence vs. Synopsys proxy battle because VCS NTB is
> just as proprietary to Synopsys as Specman "e" is to Cadence; the false
> so-called "open standards" arguments for both don't sway us.
>
> - [ A Sputnik Moment ]
From: Darren Galpin <darren.galpin=user domain=infineon got calm>
Hi, John,
Why not ask Synopsys for their e-solution? It's an open secret that
SNPS supports "e". Then you could then use Synopsys System Verilog and
Synopsys "e" to keep both sets of engineers happy.
The other thing to consider is that the code base for a System Verilog
testbench will be at least 30% or so bigger for the same type of testbench
that you would do in "e" -- and as the number of testbench bugs correlates
to the number of lines of code you have, you'll have 30% more testbench
bugs to fix as well.
And even with System Verilog, the different vendors support different
sub-sets of it, so a testbench written for one vendor won't necessarily
work, or work as intended, on anothers.
- Darren Galpin
Infineon Technologies UK Ltd. Bristol, UK
---- ---- ---- ---- ---- ---- ----
From: [ The Emperor's New Clothes ]
Hi, John,
Unfortunately my company does not allow public comment on tools we use so
please keep me anonymous.
We use Specman "e" and did an extensive evaluation of System Verilog to
decide whether to switch between projects. We came to the conclusion
that using System Verilog was not as productive as using Specman "e".
The biggest items we pointed to were:
- Aspect Oriented Language: Allows implementation of the primary
requirement leaving the exceptions for late and in different files.
There is more here than just this, but it is harder for me to describe.
- Mixed Compiled Interpreted mode: This was more useful than we thought.
This allows for our testbench binary to only contain the testbench
and not all of the code needed to implement each test, which can be
loaded after the binary and manipulate structures. This is particularly
useful when combined with the Aspect Oriented portions of the Language.
- Soft Constraints: Allows default behavior to be specified and then
modified or ignored later. (See Previous two bullets.)
- Virtual Fields Operator: Allows with a single character to declare
that a field should not be packed.
- Packing and Printing: This applies to data structures that have large
variation in content and size based on content of the data structure.
For structures like this we estimated that System Verilog would need
3X to 4X the number of lines.
- Random Generator: While the additional power and complexity is may
be a mixed bag for some users, the maturity, particularly around
debugging results is a big bonus.
- "defined as computed" Macros: this allows the extension of the
language without having to wait for the vendor or the standard.
We also discovered that there are a number of misconceptions about System
Verilog that appeared to have gone unchallenged:
- System Verilog is a so-called "Open Language": OK the language is
open, but the implementation is not. Teams trying to switch SV
simulators in the middle a project, or trying to integrate VIP
developed by a group using a SV different simulator, are in for
a rude awakening. We expect this to settle down over the next few
years, but that each time a standard is released that there will be
an extended period where the use of new features will cause
incompatibility between Synopsys/Mentor/Cadence SV simulators.
- System Verilog UVM is supposedly the "first re-use methodology"
(Specman "e" and Vera do not have re-use methodology): Parts of
UVM are heavily based on the eRM developed for Specman "e" which
pre-dates the System Verilog standard no less OVM/UVM. It is
our opinion that it will be easier to integrate System Verilog VIP
into the more powerful Specman "e" Language then the other way around.
- Specman "e" is supposedly a dead language: Many of the core people
from Verisity are still developing technology for Cadence, and in
fact appear to running the show in the simulation group. The CDNS
roadmap of new technologies still show implementations in Specman "e"
first and then transitions to System Verilog if the standard support
it. We do not have to wait for the next version of the standard.
I believe that for teams that have been using Verilog successfully to verify
their ASICs that System Verilog will be a great addition to their tool set.
If a user is currently using Specman "e", Vera, C++, or SystemC to implement
advanced verification methodologies like Coverage Driven Verification, then
I do not think that System Verilog is the best choice from a productivity
standpoint. I think this will be a more interesting question after a couple
more versions of the System Verilog standard, if some of the baggage in the
first standard can be cast off.
- [ The Emperor's New Clothes ]
---- ---- ---- ---- ---- ---- ----
From: [ Been There, Done That ]
Hi John,
Please Make Me Anon.
Switching should only be justified in term of effort (cost) and not just
because young engineers whine that a language is dying.
As a VLSI manager I would make the following judgment:
1) If I want to switch to Synopsys VCS, go with System Verilog as
it is well integrated there.
2) If I want to go with Cadence IUS, go with Specman as you have
made an investment and you have knowledge base of older engineers.
Older and more experience engineers are the ones who will build the correct
verification infrastructure and pay attention to what verification needs to
find and know how to do it.
There is no large difference between the capabilities of the languages.
I would say it is like Pascal vs C. I know that Synopsys System Verilog is
NOT really portable to other simulators as they use some proprietary stuff.
We use Specman "e" and we think it is here to stay due to the large
installed base and investment people have made.
Cadence also continues to make Verification IP available in "e" which makes
it compelling to use.
From meeting with Cadence I got the feeling that they continue to invest
in Specman. It is well integrated to the Cadence environment.
- [ Been There, Done That ]
---- ---- ---- ---- ---- ---- ----
From: [ Return of the Jedi ]
Hi, John,
Pls keep my name/company anonymous for now.
I'm a senior verification engineer. I've been working with "e" for around
10 years now. Here is my view:
1. "E" is not dying. It's alive and kicking, and used all across the
board at my company (and I mean hundreds or more of users...).
2. Few groups at my company were forced to move from eTB to SVTB due
to internal reasons; and they curse the day they did that...
3. Without getting into the OOP vs AOP mythic discussion (nor to money
considerations...) - here is my view:
- "e" is a very natural language for HW verification. SV is
constantly tryng to "be like e". Why settle for a "wannabee"?
- Specman's debugging/generation/coverage gathering/easy to use
is by far better than System Verilog's.
- One of the strongest arguments for introducing SV was to have
"a single lenguage for design and verification". SV behavioral
code is as close to SV it is as to "e". I can't imagine a
SV designer writing SVTB.
- "e" has ~10 years of success stories. SVTB doesn't...
4. Having an "e" TB allows you to use several features for advanced
verification such as Vmanager, Eplanner, IMC (new) & some others
are that still not released, but from what I saw are really a
leap ahead in verification productivity...
A nice intellectual exercise is to observe the UVM effort by Accellera.
What is UVM's main effort? UVM's main effort is adding tons of new SV
code so SV can get closer to e/eRM capabilities...many concepts in UVM
are an inherent part of the e language, while for SV they have to add a
lot of new code to imitate that...
- [ Return of the Jedi ]
---- ---- ---- ---- ---- ---- ----
From: Dmitry Sokolik <dmitry=user domain=verification-art got calm>
Hi John,
For my opinion there are more than enough reasons to choose the E language
(if you have a privilege to choose).
- In System Verilog in order to answer all requirements of a verification
language we have to use different approaches such as callbacks,
factories, macros and others. In the E language all these are not
required. The language includes all the required functionality in a
natural manner. The use of these additional approaches implies that
your System Verilog code will be significantly more lines than E code
with the same functionality. More code -> more programming errors.
- Use of macros in System Verilog makes the debug process more difficult
and non effective.
- Tools for the E language are more mature. I was very impressed by the
new Cast technology that Cadence presented in the last conference. For
example, one of the beautiful things that it allows is stepping in and
out backward in time while debugging.
- And definitely, E is not dying. The E language is more suitable for
verification. Three lines in an E test, that extend a struct and add
a constraint on one of the fields are converted to ... how many lines
of code in system verilog? (Check and see how many!)
In any case I suggest that you use UVM for your project. (UVM_e if you are
staying with E.)
- Dmitry Sokolik
Verification-Art.com Israel
---- ---- ---- ---- ---- ---- ----
From: [ Back To The Future ]
Hi John,
Keep me anon please. Company policy. :(
I'd like to add my 2 cents.
I've been doing functional verification for ~15 years, out of them ~10
in Specman/E, in various companies, from very large (like current) to
small start ups, as both staff member and contractor. For last ~7 years
I am leading verification in projects of various sizes.
I personally did not do a project in System Verilog (so some can readily
dismiss my opinion like that of an old Soviet book critique: "I didn't
read the book, but I strongly condemn it" :). However, I am familiar
with the SV language, as well as with many people who did projects with it.
So, my answers are:
Q1. Lang for new projects? Ans. E. See below for some points on it.
Q2. Migrate E --> SV or vice verse SV --> E? Ans. it depends on many
factors such as :
- What language is the majority of your project?
- What language your developers know better and prefer?
- Complexity of legacy code and schedule of the project?
(There may just be no time to change.) Fortunately,
both Cadence and Synopsys support multi-language.
- All this is under assumption that price is the about the same.
If not, big $$$ may trump all other technical reasons. :(
I believe E is considerably superior than SV for verification purposes.
This has been the subject of many language holy-wars, so I just list some
points that are most important to me.
1. E is more complete and higher level language. This means:
- fewer lines of more readable code for given task.
- More developed and standard methodologies, so it's easier
for new people to ramp-up. With SV, a company can develop
a good library and methodology, but the more custom it is,
the harder it is for your new people -- and to your people
when they look for a new job. ;-)
2. In verification, unlike "normal" SW, your product is being mostly used
during development. When it's 100% ready, the chip is done and
(barring reuse for the next one) your code is not needed anymore. In
this perspective, the flexible nature of Aspect Oriented Programming
is better than more rigid (even if more clean) pure Object Oriented.
3. E has both a compiled and interpreted mode; no need to recompile
everything if test changes.
4. Good debugger and object browser in E. I heard SV doesn't have them.
I can't believe it, so I am not sure about this one. :)
5. Flexibility, as manifested in macros. E macros are impressive for
any language.
Generally, every pain probably has it's answer. But it takes time. SV
is ~7-10 years behind E in development. At some point, the difference will
become asymptotical. But I think we are not yet there.
It was long 2 cents.
- [ Back To The Future ]
---- ---- ---- ---- ---- ---- ----
From: Cristian Amitroaie <cristian=user domain=amiq.ro>
Hi John,
I am a longtime verification manager and user of both languages. My work
requires to keep up to date with all verification approaches.
Verification is about getting the work done and finding most of the bugs in
the shortest time. Can you compare two approaches from this perspective?
Think performance, think debugging, think delivering coverage and checks.
The toolset features and maturity have an impact on engineers' efficiency
(think plain text logs vs. structured analysis, cryptical error messages
vs. detailed explanations and guidelines for a fix). Think also what are
the capabilities you'll miss and what are the capabilities you'll get if
you make the switch.
We live in a world of domain specific languages. A language for a domain
must have the right abstraction and the right means to simplify the tasks
of its domain. Think of tasks and match them with the language. Compare.
How easy is to learn and use the language? What are the productivity
gains that the language encourages? Think means for reuse, OOP and other
patterns or programming "tricks".
I don't really look at Vera anymore. Vera is a language merged into the
System Verilog standard. Some more Vera features might get into the SV
standard. I will wait for it. In this sense, switching from "e" to Vera
sounds a bit strange. I would rather wait for System Verilog to get
more mature.
Functional verification as we know it today starts with the "e" language.
Some even say that the "e" language is the only verification language and
System Verilog is a the result of a mix of many concerns. I've heard it
from both design and verification engineers.
The "e" language was designed with a focus on verification. This can be
seen from simple examples to more subtle aspects like generation flow, AOP,
when-inheritance and language extensibility.
Also the "e" language is easier to learn then System Verilog. SV is quite
huge and hard to digest due to its over permissive unfocused nature.
And on top of that, as if the language is not enough, methodologies in
System Verilog seem to abuse preprocessing.
Last, but not least, if it works, don't break it. Unless you get a big
advantage to compensate re-work.
- Cristian Amitroaie
AMIQ Consulting Bucharest, Romania
---- ---- ---- ---- ---- ---- ----
From: Srinivasan Venkataramanan <cto=user domain=cvcblr got calm>
Hi, John,
If the user has CDNS licenses, it makes perfect sense to continue with E.
I know of few large semiconductor companies here in Bangalore doing exactly
that for two main reasons:
1. They bought CDN for a long time (got a good deal in licensing)
2. Their timelines are too short to experiment with new tools.
But if the above two are not the constraints/requirements for this
customer, he/she may want to experiment with new blocks in SV.
I see that advanced technologies are being added to Specman "e" that
continue to solve verification problems of growing complexity.
- Srinivasan Venkataramanan
CVC Pvt. Ltd. Bangalore, India
---- ---- ---- ---- ---- ---- ----
From: Tim Pylant <tpylant=user domain=cadence got calm>
Hello John,
Let me start with some background. I am a long time AE with Cadence (since
1992) and was one of the first AEs to start working with System Verlog at
Cadence (started with SV31a in 2005 I believe). I enjoy working with the
SV language and have extensive knowledge of most of its constructs (was a
reviewer of Chris Spear's book).
Last year I was asked to start working with the Specman "e" language in
order to support one of our large customers. I found it fairly easy to
learn since many of its constructs and its methodology is similar to SV
and UVM. After a few months I realized that "e" was *a lot easier* to use
than System Verilog especially because of the AOP (Aspect Oriented
Programming) that is duplicated within UVM but requires quite a bit more
coding in order to utilize. I firmly believe that most users that hold a
fair and unbiased review of both languages would choose "e" for verification
given they wanted to use a UVM type methodology.
As a side comment, I am not sure why the person posting the question was so
specific about using VCS Vera NTB. I hope they truly didn't mean to refer
to Vera since that is truly a dead language whereas Specman and "e" are
firmly alive and kicking and still being used successfully across the globe.
Perhaps this person is still reading articles from 2005 where Cadence still
wasn't known for SV and Synopsys was transitioning from Vera to SV via
their NTB product.
In summary, I would recommend "e" for anyone interested in adopting a UVM
methodology. However, if they have to go with SV, they should look at all
three SV vendors and not assume that Synopsys has the best or only solution.
- Tim Pylant
Cadence Design Systems, Inc. Austin, TX
---- ---- ---- ---- ---- ---- ----
From: Darren Galpin <darren.galpin=user domain=infineon got calm>
Hi, John,
A second reply, now with my hat as chair of the IEEE 1647 group, rather
than as an "e" user.
The "e" language isn't dying, many users use it instead of System Verilog,
and with a new revision of the "e" language standard imminent. This new
standard includes:
1. Define-As-Computed Macros. This capability allows the definition
of a new language construct using an action block to build the
replacement code. It is included in the new revision requirements
due to a direct user request.
2. Interface Ports. The intent here is to support ports of standard
Transaction Level Model (TLM) interfaces -- originally developed by
OSCI as part of SystemC.
3. Named Checks. Every check statement can be uniquely tagged with a
name. This allows coverage to be collected automatically on checks,
and coverage can be extended by constraints based on the name.
4. Named Constraints. Every constraint can be uniquely tagged w/ a name,
which allows individual constraints to be overridden by other
higher-level constraints, or perhaps switched off if certain behavior
is not desired.
5. Parameterized Types. This allows template types in which you can
define generic structs and units that are parameterized by type. They
can be instantiated later by giving specific types as actual parameters.
6. Real Data Type. Support for real numbers.
7. Type Constraints. These restrict the declared type of a field to
one of its kind, or as subtypes for a given context.
Once this revision is published, we would welcome submissions of ideas on
how we could move the "e" language forward and improve it for another
future version. The IEEE1647 group is individual based and is open to
all participants.
- Darren Galpin, Chair
IEEE 1647 Working Group
---- ---- ---- ---- ---- ---- ----
From: Dave Rich <dave_rich=user domain=mentor got calm>
Hi John,
There is a 3rd option to the general question: Use IEEE Std 1800 System
Verilog (one word) that runs interoperably on at least 4 commercially
available simulators. The "open-standard" claim holds true if both users
and vendors want it to. At Mentor, we help develop and then follow the
standard as best we can. However, there are big users out there that
want us to match extensions and even bugs of other simulators. We'll
sometimes do that under a switch, but then it's the user's decision to
go outside the standard.
Proof of the "open-standard" claim is in the upcoming release of UVM
methodology, which is probably a more important consideration for
interoperability. The UVM was developed in concert with many vendors
and users so that at its release, it works everywhere.
- Dave Rich
Mentor Graphics Corp. Wilsonville, OR
---- ---- ---- ---- ---- ---- ----
From: Don Monroe <dmonroe=user domain=chipwrights got calm>
Hi, John,
Definitely use System Verilog WITHOUT Vera/NTB but WITH VMM or UVM.
I believe Vera will be deprecated in the future (not even sure it's
still being bug fixed). By not using Vera/NTB you don't have the
Cadence/Synopsys proxy battle since both simulators will support UVM.
- Don Monroe
Chipwrights, Inc. Bedford, MA
---- ---- ---- ---- ---- ---- ----
From: Cliff Cummings <cliffc=user domain=sunburst-design got calm>
Hi, John,
This does not have to be a Cadence -vs- Synopsys decision.
It is indeed an Specman "e" -vs- System Verilog decision.
Specman "e" is a great language. I have found that power Specman "e" users
tend to stay with Specman "e" until new licenses are needed, then they make
the transition to System Verilog.
I would not be looking to go from Specman "e" to Vera (VCS NTB). Going from
Specman "e" to Vera-NTB is like going from one dying breed to another dying
breed. I would be looking to move to an open standard in the form of System
Verilog with UVM. Then you just need to choose your favorite System Verilog
vendor and you can get UVM for free.
UVM is a true open verification class library (freely down-loadable) and
supposedly supported by all the major System Verilog tool vendors.
The Specman "e" power-users will miss their Aspect-Oriented when-inheritance
capabilities, but much of that capability is taken up through the built-in
factory classes in UVM. Specman "e" largely ties you to Cadence tools.
Vera-NTB largely ties you to Synopsys tools. UVM is the future and can be
used across all the major tools. With System Verilog you will get both a
simulation license and a free open verification class. No need to buy
separate verification language and simulation licenses.
Sputnik has raised a second reason to question the methodology, that is
training new verification engineers. At some point, Sputnik will be going
to a System Verilog solution, so it might be time to train the entire team
up on the new methodology as opposed to training the newbies on "e" and
re-train the whole group on System Verilog later.
- Cliff Cummings
Sunburst Design, Inc.
Editor's Note: In the interests of full disclosure Cliff Cummings is
a famous System Verilog trainer & involved in SV standards. - John
Join
Index
Next->Item
|
|
