Category Archives: Assertions

Quick start on ABV for VHDL designers – OVL + VHDL + Modelsim

Recently an ABV early stage user/explorer realized it is little hard to get started with OVL-VHDL-Modelsim combination. It surprised us as  it would many others in the industry, having known how well folks at Mentor have been supporting OVL, VHDL etc.

As valuable QVP partner with Mentor, we at TeamCVC decided to make it easier for end users. When we dug further we did realize it is not out-of-the-box. Hence we created a quick start example and uploaded it to our website.

Feel free to grab it from here: 

It is certainly a quick example just to demo the flow. Will add more soon. Here is the README for the example:

CVC’s OVL VHDL Example with Modelsim

To compile and run OVL VHDL example in Questa/MTI follow this example

We’ve used ovl_one_hot on a DUMMY signal, just to demo the flow.

You need latest OVL 2.7 release. We’ve included a part of that in this tar ball

To run
cd run_dir
make ovl

Still we strongly suggest VHDL users to choose PSL. But in case you need OVL, this example could help. Feel free to grab it from here: 

Send us your comments via

Technorati Tags: ,,,,

VHDL + PSL action blocks – quick guide

For those VHDL folks exploring advanced verification techniques such as ABV (Assertion Based Verification), here is some trick for you all! A many of you would be aware VHDL 2008 standard incorporated IEEE 1850 PSL (VHDL flavor) in it and much before that EDA tools supported PSL + VHDL as a good combination. One of the earliest tutorials on PSL and most widely read one is available @ and was authored by our CEO Mrs. Ajeetha Kumari.

As it can be seen in the tutorial PSL makes ABV adoption really simple and effective and leads to immediate benefits to the design verification cycle. One of the not-so-uncommon requirements from user community of VJDL + PSL is the ability to refer to PSL events/status from within VHDL Testbench code. This could then be used for PASS/AIL detection, coverage etc. A nice trick in PSL is to use “endpoints”.  Now coming to specific syntax, there are2 variants – in Accellera version of PSL, endpoint was a keyword as shown in ode below. This feature works like charm in most of the EDA tools. However in IEEE 1850 version of PSL, this has been replaced with ended() method. We will focus on endpoint in this example, but do try the alternate if your tool already supports it.


Basic idea is to use the endpoint to detect end of  a desired sequence of temporal and that now becomes an implicit boolean inside the underlying HDL framework (VHDL in this case).

A broader scope would be to expand this capability to assert/cover etc. There is a proposal for it at; but NOT approved/implemented by tools yet. Start adding your view in that TWIKI page and push your vendor for supporting the same.


Technorati Tags: ,,,,

Asynchronous events and SVA – a quick primer

During our recent SystemVerilog Assertions update webinar ( one of the audience raised a question on how to check asynchronous events using SVA. Here comes a quick response with code. Also simulated using Aldec’s Riviera-PRO tool.



As you can see in the picture, no clock involved per-se, but use the start and end events themselves as clock for the SVA.

So, if you’ve more challenging requirements, do drop in at CVC and we will assist you resolve them!


Raise a few eyebrows with SVA’s $rose

Assertions have always been our passion at CVC. The huge marketing buzz around UVM has some impact on how SVA was adopted and talked about at customer sites over last few years. Now that UVM is stable and getting well adopted, users are realizing that assertions play a key role in a UVM env as high quality checkers that can find bugs close to the source of occurrence. Specifically we see more user queries on SVA and training requests on SVA has been on the raise off-late.

In one of our recent, part-time SVA training session ( we had a nice discussion on $rose with a set of enthusiastic attendees. Here is our favorite saying on Assertions:

"Things look bright when SVA syntax is discussed. it gets better when we start discussions"

One of the nice features in SVA in the ability to detect rising edge with $rose. It is quite simple to understand when applied on single bit signal. For non-startes, it is simply a change from 0 to 1. That’s true for a single bit. What about vectors? In the below code, consider “addr” signal as 4-bit vector (logic [3:0] addr;)

If you thought it is 0 to 1 as in decimal, you are straightaway in for a surprise. If you suspect it is “bitwise” ORing of all bits – you are over-thinking on this. Consider the trace below along with SVA result (with Cadence’s IUS & nice Simvision GUI)



Consider an example of 4-bit vector  and few transitions.


That’s the change of LSB from 0 to 1 is really $rose.

Now consider the below transitions:


i.e. not every other bit counts here – only the change in LSB is considered. Did that raise an “eyebrow”?

Now consider an ascending order of “addr” values: (0 –>1 –> 2 -> 3 –> 4..)


Note that every alternate transition causes the $rose to be true, indicated by the “failed” notification in Simivision above – recall the system verilog assertion as:

$rose (addr) |-> 1’b0; // flag a failure, make it visible

Make no mistake, the $rose doesn’t work on “strictly ascending” consider few more traces below:


Now to raise few more eyebrows, consider the below trace with “descending” series of addr values:


So while a simplistic view of “0 to 1” is “ascending/increment”, the $rose is different when it is applied on a vector, even “descending/decrementing” transitions trigger $rose.

Now to summarize: $rose –> EVEN to ODD change :-)

Want to learn more SVA tricks, drop us a note via to know about our next SVA training session in Bangalore.

Signing off,


DAC 2013 notes: Giraffes are everywhere, Verific inside story

As I recount on my recent DAC at Austin experince, one thing that surprised me was the number of Giraffes (sure, images/toys, wish the real ones..but I was at DAC and not a zoo/safari) in the exhibit floor.


Yes, am talking about the Verific’s mascot here. It was one of the tallest standing booths so not many could miss it. My friend Sashi Oblisetty led me to them after our early breakfast meeting that morning at DAC. I met with Michiel Ligthart, Verific’s president and chief operating officer. He is a tall man, a Netherlander/Dutch (Graag, ik kan een klien beetje Nederlands spreken .. –  Glad, I can speak a little bit Dutch language, thanks to my early days of work at Philips, Eindhoven). It was a pleasant surprise to see how many customers Verific has to-date, from their facebook page I found:

That’s impressive indeed. No wonder I found several small Giraffes on other vendors’ booth tables. It reminded me of the popular "Intel inside" campaign, perhaps Verific should do similar "Verific Inside" campaign in EDA world :-) Or should we call it "Giraffes are everywhere" (For those avid travellers, see:

I also met Ahbijit Chakraborty, their India GM (based out of Kolkata/Calcutta) and we agreed to follow-up on some of our DVAudit ideas post-DAC. If you wonder what DVAudit is, here is a brief on what I presented at Cadence theater at DAC floor, drop us a note via if you need more details.

Truly an engaging crew at Verific booth, we at TeamCVC do look forward to their PERL based parser front end to build custom utilities for our customers.


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);


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  for more advanced, practical usage of this wonderful technology.

Good Luck


Technorati Tags: ,,

Simple assertion can save hours of debug time

Recently a user sought to assign a 4-state array (declared as logic) from the DUT side to a 2-state, bit typed array on TB side. Quite normal and intelligent choice of datatype – as all the TB components at higher level should work on abstract models. However there are 2 important notes – one on the “syntax/semantic” and other on real functional aspect.

Focusing on the functional aspect first (as the semantic would be caught by the compiler anyway), what if the DUT signal contained X/Z on the 4-state array value?




When you assign it to the 2-state array counterpart on the TB side – there is information loss and potentially wrong data :-(



Here is where a simple assertion could save hours of debug time for you. Recall that SV has a handy system-function to detect unknown values. One could write a simple assertion using that function at the DUT-TB boundary. See the full code below, with the assertion part highlighted:


With the SVA included, here is a transcript – Thank GOD, I used assertions :-)


So next time you move data from DUT-2-TB, consider this simple trick.

For those wondering what’s the compile time issue in dealing with 4-state vs. 2-state, read VerifAcademy forum @


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:

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


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


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!

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, and it has been almost a decade by now! We cover this in all our training sessions on assertions such as:

Even during our popular VSV course ( we touch upon this topic during the program block discussion. Below is an extract from our training/book on SVA (




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 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!

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

Last week, our good friend Gaurav Jalan wrote a nice blog at: 

He has adapted Murphy’s law into Verification as:

Applying to Verification ( )

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 ( 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: and


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: ,,