For new testbench, VERA, Specman/E, or Systemverilog?

system verilog vs specman

I think we all know Systemverilog is here to stay, since it's a convergence HDL language (Design and Verification, as opposed to Verification only), unlike E or VERA.

But I've never used VERA or E. And as the old saying goes, "Jack of all trades == master of none!" In other words, a specialized verification language E/VERA will perform verification better than a general-purpose language like Systemverilog.

For testbench and verification, can someone tell me what advantages VERA and E have, compared to Systemverilog? Is there anything (testbench/verification wise) Systemverilog does better than VERA or E?

specman testbench

Hi,
No I don't think there are much differences in these languages from Verification perspective.
If you see from past even you can do the verification using Verilog as well.
Now the question is where SystemVerilog is ahead , & it is thats why all 3 major eda vendors are supporting SV. its a IEEE standard. U dont need to buy spearte simulator as woith E or Vera.
Vera is specific to Synopsys and E is to cadence so the cost factor is the major factor.
So in near future we may see SystemVerilog only.
So just work with any language u get opportunity to work with
-Manmohan

vera vs systemverilog

i think that one of the advantages of SV would be that you have both the design and the verification codes integrated together...no need for external files!

also, the adoption of constrained-random testbenches, functional coverage and assertions is perfectly coherent with the use of SV

Read this interesting article to know more please:

**broken link removed**

specman vs system verilog

Hi,

boardlanguage said:

But I've never used VERA or E. And as the old saying goes, "Jack of all trades == master of none!" In other words, a specialized verification language E/VERA will perform verification better than a general-purpose language like Systemverilog.

Click to expand...

You are correct. However one can "live" with some limitations if the broader goal of "everyone can debug everything" is achieved - to me that's the single most advantage of SystemVerilog.

For testbench and verification, can someone tell me what advantages VERA and E have, compared to Systemverilog?

Click to expand...

Well a detailed list will be overwhelming and meaningless. The goal of "doing verification" is doable with any of these, and for any new projects I see more and more SV being used.

One of the fundamental differences bet'n E and SV is AOP vs. OOP. There are some good papers on this topic, look at cdnusers.org. Also see:

**broken link removed**

Is there anything (testbench/verification wise) Systemverilog does better than VERA or E?

Click to expand...

Eae of use, single look and feel - does not create a barrier for Designers to debug TB and vice versa.

Cheers
Ajeetha, CVC
www.noveldv.com

I agree to Ajeetha on the fact that verification is doable using any language, you can live with limitations and also the fact that main difference is the AOP(E) and OOP(SV) language.

But let me guide you thru one main advantage of E and also some advantage of SV , You need to think what will suit you.

Advantage of E:
It is simple AOP

what is that ? OK , here it comes , it is allowing you keep your imaginations unlimited for future. Something like ,The AOP features of e mean flexibility is built into your verification designs by default. Incase your code has to be reused in future by chance, your re-users/modifiers can make your verification design useful to them. OOP on the other hand is only flexible if you make it flexible. OOP is flexible only by design not default- you cannot design all of the things your re-users/modifiers may wish to do from your code, because you are not oracle and will not add hooks, callbacks, publicly accessible types, virtual methods, etc everywhere for future any not-anticipated change or request.

The inbuilt flexibility of OOP is inheritance. Good for marketing, but actually not good. There are Non-virtual methods ,private and protected member variables that you want to replace with your new class type. The default inbuilt flexibility of OOP relies on the code writer has to think ahead of making their code virtual and accessible.


Advantage of SV :

1.People can a feel of their old language verilog : But that too very less part of SV for verification.
2.No linking of simulator to specman : But That is just one time.
debugging may be easy for design folks : Do they really debug verification stuff , do all of them get into verification and constructs like classes.
3.Can put SVA between RTL code : This one scores over E/specman, But E also has temporal expressions . This helps verification engineers to shift their load to RTLers for writing the assertions(verification folks have to still define them)



If you have the choice to choose the best for you , choose E , as in bigger environements and codes coming and going to all places you may find E more handy as for code maintenance and reusing existing code AOP is almost indispensable. By using AOP extensions, users can methodically update an existing environment with concerns that were missed in the initial planning, or are the result of changes that occur later on in the project. This sort of "after-the-fact" manipulation can be difficult in a standard OOP environment and/or if you only hold yourself to strict OOP practices. In the context of reusing existing Verification IP, AOP allows you to configure, control and add functionality to the existing VIP without touching the base code set - hence the reference to "safety" above since you don't have to muck with proven code. This can become critical when sharing IP across multiple projects or groups.
With AOP , You will be allowed to write tests that need a tweak in the environment for a special case but which can spoil other cases.

I am not sure if these things are supported in SV nowadays with VCS.Please ask for dynamic AOP / advice from Synopsys folks.

Think on this !!!

Sarika Varshney

I can comment on Vera & System Verilog because I have use Vera and will migrate to System Verilog soon. System Verilog is a superset of Vera and is supported by all the major verilog simulators, so you're getting it for free. Whereas, Vera is proprietary and you need buy the license for it. The interface between your SV testbench and the verilog RTL will be much simpler also because verilog and SV code can coexist. Synopsys has alread stopped adding any major feature changes to Vera and I strongly believe they will begin to phase out Vera in a few years.

Switch Vera to SV is painful for a company, is it a simple way to do?

woolive said:

Switch Vera to SV is painful for a company, is it a simple way to do?

Click to expand...

There are some scripts around to automate some part of Vera-2-SV migration. ALso with VCS one can use "Vera-SV" interop layer to start with.

HTH
TeamCVC

Re: system verilog vs specman

boardlanguage said:

I think we all know Systemverilog is here to stay, since it's a convergence HDL language (Design and Verification, as opposed to Verification only), unlike E or VERA.

But I've never used VERA or E. And as the old saying goes, "Jack of all trades == master of none!" In other words, a specialized verification language E/VERA will perform verification better than a general-purpose language like Systemverilog.

For testbench and verification, can someone tell me what advantages VERA and E have, compared to Systemverilog? Is there anything (testbench/verification wise) Systemverilog does better than VERA or E?

Click to expand...

Hi ,
Almost all the languages are same... the only difference is the abstraction level...
which is more in case of VERA,SPECMAN E compared to SV