Verification: SystemVerilog vs. Specman (e) - who's on top?

[thinkver]

difference between specman and systemverilog

Why do companies choose SystemVerilog over e (a.k.a Specman) when clearly there are very few who believe that SV is more effective than e and so many who think the opposite? Is SystemVerilog going to kick e out of the game? Is e really better than SV? Read here about the Battle of the Worlds

--
link doesn't work? go here - http://www.thinkverification.com

 

[jbeniston]

aop systemverilog

SV will win as it's not linked to just one Vendor and also addresses synthesis issues as well.

 

[ljxpjpjljx]

specman e

SC is the future trend !

 

[thinkver]

systemverilog aspect aop

I added a quick tutorial on how to perform method manipulations in e and SV.
SV and e are totally different languages. However, since env. developers often need to perform similar tasks regardless of the chosen language, it's interesting to compare code snippets that implement the same functionality.

click here

or go directly here -
http://thinkverification.com/index....thod-manipulation-in-e-and-systemverilog.html

Yaron
ThinkVerification.com

 

[anant]

systemverilog aop

both sc, e and sv all are good..depends on what type of design is being verified.

 

[thinkver]

advantage of systemverilog over specman

For simple designs I guess there is no significant difference between the various tools. Obviously any verification language will eventually get the job done.
But, for ultra complex designs where reuse and time-to-market are the name of the game, I think e will get you faster results than SV. This is from my own personal experience and from many others who've worked with both languages. I don't know about SystemC.

In that context, SystemVeriog is a lesser language than e, for mainly 2 reasons -
1) SV is an Object Oriented Programming language rather than Aspect Oriented Programming language (AOP). One can never exaggerate in the importance of AOP capabilities for verification if time-to-market is a major factor. AOP capabilities are a must as they give you the opportunity to verify corner cases quickly while keeping the main verification environment intact. Once again, this is extremely important if you want to achieve fast results.

2) SV is less mature than e, and lacks some inherent features that are the bread and butter of every verification engineer - advanced manipulation of arrays (regardless of its type), built-in class methods such as print(), deep-copy() and compare(), computed macros - just to name a few. Bottom line - in e you'll write less code for the same functionality and less code yields less bugs which means, once again, better reuse and faster time-to-market.

From the market standpoint I can see why SV could win the battle, and I guess it would be easier for a C++ programmer to learn SV than e. In the future SV will grow up and some day will probably resemble what e has been offering all along

 

[sarika_varshney]

Re: Verification: SystemVerilog vs. Specman (e) - who's on

Advantage of E:
It is simple AOP Smile

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.
also some more people views were :

"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.


see my reply at