CVCBLR's VoW blog - Verification on the Web!

  Over the past few years, the term “pre-silicon verification” has been quite popular and several technology advancements have helped in solving that puzzle. Some of the biggest contributors have been languages such as e /Specman and SystemVerilog with supporting technologies such as constrained-random verification (CRV), coverage-driven verification (CDV) and assertion-based verification (ABV). All these three technologies when used in unison addressed the challenge at the block or intellectual property (IP)level fairly well. Recently UVM has been developed as a framework to use these languages in the best possible manner to try and keep these technologies scalable to larger designs, such as system-on-chips (SoC). Thanks to the Accellera committee devoting time and effort, UVM is becoming quite popular and the de-facto IP verification approach. However with SoCs, there are several new challenges in the verification space that threaten to quickly outgrow the current prevalent t...

Recently a UVM user pondered over the following question: randomization NOT happening for seq_item variable if uvm_field_* is NOT enabled? ( http://goo.gl/TNSaz ) To appreciate the issue, consider the code snippet as below: Since both hdr and pkt_len are declared rand, one expects them to be randomized. Note that one of the `uvm_field_int is commented – to demo the issue. Now a recipient/consumer of this transaction does a copy/clone at destination. See a code snippet: So far so good, let’s see what happens in a typical Questa simulation: The above results of hdr being NOT generated occurs consistently for all seeds (See the forum post if needed). So a typical user suspects that the missing uvm_field_int macro does control the randomization – though not intuitive/true. This could consume quite a few debug cycles (recall that the macro above is commented for demo only, in actual work, as reported in that forum posting, user forgot to  add that at the ...

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

  As many of our readers would recall, CVC first became very visible to the industry with our early contribution to the assertion-based verification (ABV) via IEEE-1850 PSL (Property Specification Language). Back in 2004 we co-authored our first book on this wonderful language, first of its kind in the temporal assertion languages to become a standard ( See our timeline in Facebook for more ). Since then it has been a wonderful run of events in this world of functional verification for close to a decade by now. One of the significant features of PSL has been its simplicity and succinct means of expressing complex temporals through its “Foundation Language” (a.k.a LTL style) subset. We talk about this in detail in our PSL book ( http://www.systemverilog.us/psl_info.html ). Recently a user came up with a nice requirement at Forum in Verification Academy (See: http://bit.ly/14JTHlI) The spec goes as follows: The user attempted a simple SVA 2005 style, but got weird results...

  As we wrap up an excellent UVM training for a well informed audience for a local customer at the very beginning of 2013, here is a quick tip for those verification work-horses trying to debug various UVM phase related hangs in their simulations. To be honest, this was developed for another customer way back in the middle of 2012, but never got published, so we decided to do it in early 2013. This is part of our product line where-in we line up various solutions around UVM. The scenario that several customers face is that they have bunch of raise & drop objections, but somehow there is a mismatch of the “raise-to-drop” – i.e. some of the raised objections remained and never got dropped! While UVM comes with few handy plusargs - +UVM_PHASE_TRACE, +UVM_OBJECTION_TRACE etc. these don’t always point you to exact problem, atleast fast-enough. Here is a smarter approach: The uvm_objection base class provides a very nice debug routine named display_objections() . One may want to...

If you are a verification engineer in ASIC/FPGA domain, chances are very little that you have not heard of SystemVerilog. For the last 6+ years it has been making positive impacts to design and verification teams across digital design space. Given this fact, this is no surprise there are several young engineers who jumped on to the bandwagon and picked up the language to a certain level. Many successful engineers in this part of the world have taken CVC ’s VSV course as a wise step towards the same. However when it comes to the production use, plain System Verilog falls behind in certain key areas. Make no mistake, it is a powerful language and is becoming even more powerful with the upcoming 2012 update. See our blog for more on those updates: www.cvcblr.com/blog Many users ask us – why do I need UVM on top of SystemVerilog. While there are ample number of marketing material available on the net for free on this, here is a humble, technical attempt to challenge a solid DV engi...

As some of our customers ask during our advanced SystemVerilog/UVM training sessions, SystemVerilog doesn’t allow multiple-inheritance. Or to be precise “DID NOT have”, now in SV-2012/2013 it does! For those yet to get there – here is  a quick recap:     Simple inheritance                  Few derived classes             One can of-course “derive” from another “derived class” too, as-in:   This is used widely in good System Verilog code and in general any OOP code. UVM uses this a lot as many of you who have been fortunate to have attended our popular UVM training sessions ( http://www.cvcblr.com/trainings ) across the world (Yes, we have delivered across India, various cities, across the globe as in Europe, Asia etc.). However what was not allowed in older SystemVerilog (2005/2009) is: Multiple inheritance, as in:...