CVCBLR's VoW blog - Verification on the Web!

During our recent SystemVerilog Assertions update webinar ( http://www.cvcblr.com/blog/?p=802 ) 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! TeamCVC BuzzNet Tags: Verilog , SystemVerilog , SVA , ABV , Aldec , EDA

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 ( http://www.cvcblr.com/trng_profiles/CVC_LG_SVA_profile.pdf) 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 simp...

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

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