Mind the GAP – even in SystemVerilog macro definition

SystemVerilog enhances the TEXT-MACRO feature (a.k.a `define-s by many young engineers) of Verilog by a good length. Significant enhancements done are:

1. Added capability to extend the definition to multiple lines
2. Added macros with arguments;
3. Macro arguments can have default values too! (not fully supported by all tools though)

However there are few caveats – in general any text-macro usage in any computer language is hard to debug when it fails to compile. So be ready to be patient while debugging macro code.

Recently an online forum user asked a question on SystemVerilog macros. Here is what the user defined to start with:

To a bare eye, the above looks fine. However a  SV compiler would through an error at it. As per the LRM:

 

If formal arguments are used, the list of formal argument names shall be enclosed in parentheses following
the name of the macro. The left parenthesis shall follow the text macro name immediately, with no space in
between.

In other words – as it is with any Metro station sign, you should be careful with the GAP/spaces :-)

Notice that “extra space” after the macro name CHECK1 is now gone! This works in Questa 10.2.

So next time when you code your macros – mind the GAP :-)

TeamCVC

Technorati Tags: SystemVerilog,Verilog,EDA

SVA: default disable – a boon or a bane?

As the SVA usage expands/grows in the industry, so do the language syntax/features. One of the recent (2009) addition to System Verilog language was the ability to code “default disabling condition”.

It is very handy to have an “inferred” disabling condition for all assertions so that one can save on verbosity while typing – every assertion doesn’t have to repeat;

  a_without_default_disable : assert property (disable iff (!rst_n) my_prop);

vs.

a_with_default_disable : assert property (my_prop);

Obviously anything that helps to save some typing is a BOON.

However there are some special category of assertions that may get unintentionally disabled by this. For instance the “reset-checks” – assertions that check the reset value of various DUT outputs. For e.g.

• FIFO empty flag during reset
• serialout signal from a de-serializer design

We recently had a similar DUT being verified with SVA. In the below code, notice the “default disable” and the reset-check

As the callout/marking shows – there is a bug in DUT, the signal “serialout” is indeed HIGH during reset, yet the assertion doesn’t fire (Questa shows it as INACTIVE – meaning it is a vacuous success in this case).

So that begs the question of “is the default disable a boon or a BANE”?       

The answer is – you need a methodology and a plan while doing your assertions – categorize the assertions appropriately. Specifically group them as:

• Reset checks
• Functional checks
• Low Power checks

etc. Here is a nice work-around for this:

• Use an explicit “disable iff (1’b0)” for those special category assertions

 

Now Questa flags it nicely as below:

So do use the new SVA stuff on “default disable” – it is indeed a BOON. Just make sure you “think” before you code those special category of assertions.

This is part of our larger story of ABV methodology being rolled out as next generation verification training sessions at CVC. So do contact us via training@cvcblr.com  for more advanced, practical usage of this wonderful technology.

Good Luck

TeamCVC

Technorati Tags: SystemVerilog,SVA,ABV

Easier PLI integration with MPSim

Several engineers working and aspiring to work in the field of ASIC front-end design/verification tend to stay away from Verilog’s powerful PLI/VPI – some of them because they see it as old technology and many others – simply “FEAR” from it, thanks to its complex integration with the tools.

For those who believe it is old technology – think again, most of the cutting edge EDA innovations (in front end) happening around verification use Verilog’s PLI/VPI to talk to your underlying simulator. To quote a few examples:

1. NextOp/Atrenta’s BugScope 
2. Novas’s Verdi/Debussy
3. Axiom’s @Designer http://www.axiom-da.com (Debugger that can work with all standard Verilog simulators)
4. Trek from Brekersystems (www.brekersystems.com)
5. OnPoint from vennsa-da.com

Now for those who “fear” from VPI due to its integration challenges – to be fair – you’ve reasons to do so. However advanced functional verification solutions such as VCS, MPSim (http://www.axiom-da.com ) provide a convenient TABLE format to ease this task. All you need to do is to create the following table:

And use standard gcc to compile your C-code as below:

gcc -m32 -pipe -c -g ../pr_tscale.c -I$(ATHDLROOT)/tb/incl –DAXIOM

Now, invoke the atsim compiler with the tab-file as shown in below command:

atsim -c ../pr_tscale.v +tabfile+pr_tscale.tab +pliobj+../pr_tscale.o
./athdl_sv

 

For those trying it out at your end, notice the path to the *.o file should have “../” as the atsim compiled one-dir below (hidden dir).

Now if it was this simple, why would anyone FEAR  from it really? The answer is – that’s how the Verilog LRM defines it to be, see below if you have time and patience. Advanced verification platforms like MPSim will hide these details for you for your pleasure adn ease-of-use!

For those uninitiated with this fear, see how the Verilog LRM defines a data structure for this purpose below: (extract from standard vpi_user.h)

 

 

 

Now to use it in an end-user application such as the one found at: http://www.cvcblr.com/blog/?p=517 one needs to create a variable of this structure and fill in the integration details, see below:

If you managed to read up to this – then you are convinced that integration of VPI code isn’t for everyone – if not for tools like MPSim !

Good Luck!

TeamCVC 

Technorati Tags: Verilog,PLI,VPI,MPSim,EDA

Upgrade yourself to SystemVerilog 2012 – our SVA handbook, 3rd edition is published!

They say “innovation never stops” – it is true for the SystemVerilog language committee. And it is very true for our co-author Ben Cohen, who even at the retired age keeps updating himself on latest on SV, VMM, OVM, UVM and of-course SVA. Ben Cohen is the Accellera nominated representative for the SV-AC committee on IEEE dev team.

See TOC at: http://systemverilog.us/SVA3rdE_preface_toc.pdf

The cover of this book is a NASA photograph of Mars, taken by Curiosity. Just like how Mars is enormously big, the verification state space of most of the modern day designs are extremely large. While there have been several advances in the area of "stimulus" or "activation of potential design errors", the amount of checking being done during such activation (either via simulation or formal analysis) demands detailed, precise design specification. This is precisely where SVA fits in the design flow. Just like how the whole world awaits pictures & findings from Curiosity to learn more about Mars, SVA could be used by the design verification teams to learn about the functional quality of designs.

Here is what the forewords say:

Dennis Brophy Director of Strategic Business Development, Mentor Graphics.

 

In 2010, research showed use of SystemVerilog was up more than 233% over prior years with more than 7 out of 10 design and verification engineers using it. Even more telling was the use of the SystemVerilog Assertions (SVA) part of the standard. Research showed that assertions enjoyed the same high level of use with 7 out of 10 design and verification engineers adopting SVA.
Assertion based verification (ABV) methodologies has been found to address design and verification challenges and the market use reflects it. The assertions portion of the IEEE SystemVerilog standard has also been enhanced over these years to extend and improve what can be done with them based on the cumulative experiences of the design and verification community to date.

The third edition to the SystemVerilog Assertions Handbook comes at a time when the IEEE updates its popular SystemVerilog standard and at a time when the FPGA community is increasing its adoption of SystemVerilog assertions as well. Design and verification engineers will find the handbook useful not just as a resource to begin to adopt assertions, but to apply the latest additions and updates found in the IEEE standard to the ever pressing design and verification challenges.

 

 

Sven Beyer, Product Manager Design Verification, OneSpin Solutions

http://www.onespin-solutions.com/

The SystemVerilog standard itself has been very much alive with two updates in 2009 and now in 2012, enhancing many existing features and adding numerous new ones. So more and more engineers are exposed to SVA while at the same time, the standard quickly evolves, trying to address the growing needs of those engineers for more productivity. This definitely calls for a first class reference documentation – and this book, SystemVerilog Assertions Handbook, 3rd Edition by Ben Cohen, Srinivasan Venkataramanan, Ajeetha Kumari, and Lisa Piper, provides such a comprehensive reference manual that is suited for both SVA power users and novices. It introduces assertion methodologies and gives a clear idea on what assertions are good for,addressing both coverage and the complementary strengths of dynamic and formal verification. It carefully
lays out the numerous SVA language constructs one by one in a way that really gets across to the typical engineer, emphasizing the intended usage, adding telling examples, and listing the counter-intuitive pitfalls that may cost an engineer precious time in debugging. Therefore, this book is sure to find its place on the bookshelf of numerous engineers all over the world, and since it is the first comprehensive reference manual to also address the IEEE 1800-2012 standard, for example with its numerous enhancements to the checker construct, it is sure to remain on this shelf and be extensively used for quite some time.

 

Stuart Sutherland , SystemVerilog Training and Consulting Wizard
Sutherland HDL, Inc.
http://www.sutherland-hdl.com

The complexity of the design we need to verify requires that an assertions language has a robust set of features and capabilities. The SystemVerilog Assertions (SVA) language meets that rigorous requirement. The robustness of SVA also means that it can be challenging to learn to use SVA -- and to use it correctly. The SystemVerilog Assertions Handbook is an essential resource for overcoming that challenge. The book examines the use of SVA in the context of verifying true-to-life designs. Thorough explanations of each feature of SVA show the where and how to use SVA correctly, as well as point out pitfalls to avoid. At my company, we feel this book is so essential for understanding and properly using SVA, that we include a copy of the book as part of the standard training materials in all of our “SystemVerilog Assertions for Design and Verification Engineers” training workshops.

Cristian Amitroaie CEO, Amiq

.

The first benefit this book brings is a systematic and clearly organized perspective on SVA, from planning to terminology, from how assertions work and how to debug them, to coverage driven and formal verification using assertions. This includes the language clearly identified rules, and many tables and figures annotated with comments.

Second it offers many concrete examples. Examples are fresh air for engineers when diving into complex topics and this book has plenty, including the mapping between natural language and the corresponding SVA implementation.

Third, it contains guidelines on what to use and what to avoid, based on experience with both SVA and UVM. Knowing and following best practices are essential to engineers these days, when work pressure doesn't leave much time to carefully digest all the implications of the highly sophisticated means we use on a daily basis.

This is a book every engineer should keep handy!

Technorati Tags: SVA,Assertions,SystemVerilog Verilog EDA

Visualizing SystemVerilog event regions

One of the strengths of assertions in SystemVerilog is its well defined sampling semantics. Though it works out-of-the-box and is robust, many users don’t seem to understand it in depth. As we have been blogging on assertions – one needs to be very “pedantic”, i.e. detail oriented to be able to appreciate it, demonstrate it and understand it.

We at TeamCVC have been pioneering assertions as a focus area since our PSL book days (end of 2003, http://www.systemverilog.us/psl_info.html) and it has been almost a decade by now! We cover this in all our training sessions on assertions such as:

• SVA: http://www.cvcblr.com/trng_profiles/CVC_LG_SVA_profile.pdf
• PSL: http://www.cvcblr.com/trng_profiles/CVC_LG_PSL_profile.pdf

Even during our popular VSV course (http://www.cvcblr.com/trng_profiles/CVC_LG_VSV_profile.pdf) we touch upon this topic during the program block discussion. Below is an extract from our training/book on SVA (http://www.systemverilog.us/sva_info.html):

 

 

While the above slide goes well into the depth of this topic, often users ask us if they could “visualize it” inside waveform. Recently we did a SVA class for a VHDL customer who use Questa. Being part of QVP http://www.mentor.com/products/fv/partners/qvp we at CVC have access to Mentor’s latest technologies and this customer insisted that we use Questa during the labs. We enabled more debug sessions including their famous Questa ATV (Assertion Thread Viewer) feature. One of the nice examples our TeamCVC have created explains the events/time-regions nicely. See below for a screenshot:

 

It is almost the same as SystemVerilog LRM’s event Queue – brought inside the waveform, isn’t it! Here is a code snippet for the RTL regions such as “ACTIVE, INACTIVE & NBA” – this is same as in plain Verilog BTW:

 

Now recall that in testbench with System Verilog there is a program block that executes in REACTIVE region. And so are the assertion action-blocks. And within program block one can do blocking, #0 and NBA ssigns. So how does that get scheduled?

 

And relevant code-snippet for the REACTIVE assignments:

 

 

Putting the full waveform:

 

NOTE: the “time” doesn’t advance, it is only the DELTAs – Questa is powerful indeed in visualizing it, we will try and add other tool screenshots in near future if there is enough demand from you – our beloved readers!

Before we close, here is what a full, IDE (Integrated Development Environment) that Questa provides for this:

Hope you enjoyed this “flow of events” and the power of “visualizing” it – as much as we did. Drop your comments below!

Signing off with confidence, it is TeamCVC!

Technorati Tags: SVA,SystemVerilog Verilog EDA,Verilog,EDA,Questa,Debug

Verilog PLI/VPI – a sample tree walker + hierarchical print_timescale app!

Here is a nice Verilog VPI (Verilog Procedural Interface a.k.a PLI 2.0) app that we mentioned during our just concluded Verilog training at CVC.

This application just walks through the complete design hierarchy and spits out the Timescale information for each module. It is quite handy to find which module has the least timescale precision value (and hence controls the whole simulation) for e.g. when the design has been given as a compiled database or a protected one – simple grep/PERL kind of ideas maynot fit. This application will extract:

1. The module name
2. Its Time Scale value
3. Its TimePrecision value

Here is a PLI task named " $print_timescale " which if called on a top level module will print this information for the entire hierarchy.

The following Verilog code (which could be the top level of your design, or TB) shows how to use such a task.

 

 

Needless to say the hierarchy can be very deep and totally encrypted etc. It is all about tree traversal and printing the relevant portions of vpi_get as in:

Following is a code snippet from the VPI/PLI C-code:

 

Now wrap that inside a tree walker code that would walkdown your Verilog hierarchy (post elaboration) such as:

 

  

 

At each node, print the results.

 

Drop us a note in the comments below if you would like to see the complete VPI code listing!

 

Who said Verilog is simple – it can become very interesting with large designs with interesting challenges!

Now you see why CVC is in the best of Verification related technology when it comes to training engineers (freshers/experienced alike) – where else would engineers get to experiment and learn at their own pace all the way from UNIX, Verilog to SystemVerilog, Assertions, UVM and beyond? See http://www.cvcblr.com/trainings for more!

Technorati Tags: Verilog,EDA,PLI,VPI,hierarchy

Verilog subtleties - $monitor vs. $display vs. $strobe

Last week, our good friend Gaurav Jalan wrote a nice blog at: http://whatisverification.blogspot.in/2012/08/laws-and-verification.html 

He has adapted Murphy’s law into Verification as:

Applying to Verification (http://whatisverification.blogspot.in/2012/08/laws-and-verification.html )

Moore’s law – Amount of code to be verified doubles every 2 years.

Murphy’s law – Any code that isn’t verified will not work.

Now as I recap on last week’s Verilog session delivered to an excited IIT-KGP audience, I realized the same law is applicable to slides/PPT/training too :-) Especially be careful with any code snippet shown in the slides – they  could be wrong – unless verified otherwise!

Now back to the title of this blog entry – what are the differences bet’n Verilog’s $display, $monitor & $strobe?

1. Usual answer: $monitor is “continuous monitoring” – Yes, good

For many fresh graduates the detail stops there – but not for those “verilog hungry, pedantic folks”. Here are some more:

1. $monitor & $strobe execute at the POSTPONED region of your Simulator’s event Q – read more about it in LRM or attend our detailed simulation/SVA training (http://www.cvcblr.com/trainings) for more details on this event queues etc.

2. With $display you may get more than display for the same time, for the same signals being displayed – but with $monitor you are guaranteed to get only one at any time for the same display list. As the LRM puts it:

 

(With $monitor being in use) If two or more arguments change value at the same time, only one display
is produced that shows the new values.
Only one $monitor display list can be active at any one time

The above can be little misleading statement – infact that was the case with our UNVERIFIED PPT slide with some code snippet. Here is a fixed example with some traces:

Consider the test vector setup as:

 

 

Notice that at time 100 we have “b” being assigned twice – one with BLOCKING and another NBA. With $monitor - you get only one display as guaranteed by LRM. However if we try mimicking the same with always block as below:

 

Guess what – you get the display twice, see below:

 

 

Now a more equivalent mimic would be to use $strobe instead of $display as in:

 

 

Now with SystemVerilog there are few more you could expand this topic to including:

1. Use always_comb instead of always @ (*) in the code above – it is guaranteed to wakeup at time 0

2. In the context of SVA (System Verilog Assertions), in 2009 the LRM added “deferred assertions” to handle similar situations.See: http://verificationguild.com/modules.php?name=Forums&file=viewtopic&p=19966 and http://sv-verif.blogspot.in/2012/03/using-systemverilog-assertions-to-check.html

 

So that was good fun with “details” on what’s usually skipped as “simple stuff” during a Verilog training.  Below is full code incase you want to run, modify and experiment around:

Technorati Tags: Verilog,EDA,SVA