Category Archives: ABV

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,


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 @