Missed a UVM field macro? Be ready for surprises – and a debug assistant!

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 first place).

A Debug assistant

Now as in our regular VSV training sessions (www.cvcblr.com/trainings) , we showcase the potential applications of post_randomize and one of the prominent ones is to “debug” the generated fields. See below code snippet:

With the above code added, here is what our friendly Questa has to show for us in simulation:

So clearly the hdr field does get randomly generated. It is only when a copy of the container class being created, it skips the “copy process”. And this has to do with the lack of macro. Focus on the missing/commented macro below:

Hope the above makes it self-explanatory – add the macro, you get copy/clone enabled for that specific field. So 2 lessons learnt today:

1. Use field macros consistently

2. More importantly, use post_randomize as your friendly, automated debug assistant for random generation!

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 @ http://bit.ly/11xsgO0

 TeamCVC

Pragmatic choice of ABV language - PSL still shines better than SVA

 

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, then our beloved co-author and guru of assertions, Ben Cohen provided assistance as below (unverified):

Do the same in PSL with FL/LTL style:

Now relate the PSL code back to user spec/requirement:

May be simple, but drives me crazy..

"Req" -> "Gnt" -> "Rel"

When granted, assert if it is going to Idle state before releasing the lock.

Won’t you agree that PSL with its FL/LTL style is lot closer to the spec than the erstwhile SVA-05 sequence based approach?

There is light at the end of tunnel:

1. PSL works well, nice and is usable in all flavors – Verilog, SV, VHDL, SystemC etc.

2. It costs nothing extra in tools – if you have paid for SV, it is very likely you got the PSL too

3. SV 2009 standard did add this LTL features into it, but yet to be supported by many vendors. So your chances of using it in live projects is weak. Of-course push your vendor for it though.

Bottomline – use what works today, PSL is alive & kicking and you’ve already paid for it in your tool. There is hardly any extra learning – if you know one temporal language, the syntax is very similar, so why not get pragmatic and use it!

Is your UVM simulation hanging? Need a debug help? Use display_objections()

  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 stick the following piece of debug code to a test:

 

Fork the above task along with your regular main_phase’s logic. When we run this in Questa for instance, here is what we get:

 

So the above indicates there are 3 folks opposing it with clear pointers to who they are. Now run further till you get the hang state, you should see:

 

The above transcript clearly indicates that the monitor is the culprit that has a raise objection that’s not dropped yet!

Good Luck and have fun with your SystemVerilog and UVM debug. Contact us via http://www.cvcblr.com/about_us if your team need hands-on problem solving level case studies such as above along with regular VSV, UVM training (http://www.cvcblr.com/trainings).

TeamCVC

www.cvcblr.com/blog

Technorati Tags: SystemVerilog,UVM,EDA,training

I know SystemVerilog, why bother me with UVM?

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 engineer with decent SV skills.

Consider a simple Deserializer design: call it S2P (Serial-2-Parallel converter). It captures the input serial stream from start-to-end and sends out as parallel data at its output every 8 clocks. A typical waveform would look as below:

Now, let’s say that you are SV aware to the extent that you can comfortably create a verification environment in say 1 or 2 hours for this simple design.

Now let’s try and do “verification” – add a negative test – i.e. create a scenario in which:

• There are ser_sop with NO ser_eop in between

See a sample screenshot below:

Remember, it is a negative test and hence you are NOT allowed to change any existing code. Can you achieve this in plain SystemVerilog without UVM?

If the answer is simple YES, we would love to hear your solution (add via comments here, below). No, don’t think of tricks like “force/release” etc. Attempt it as a pure SystemVerilog coding exercise.

The reality is – of-course we can, if we architect it upfront with factory and/or callback. That’s kind of what a framework such as UVM does for you. So UVM is nothing but 100% SystemVerilog, but wrapped in with a series of base-classes, built-in features that make your ‘verification” easy.

Join us for our upcoming UVM training session to know more on this challenge.

Bottomline – UVM is made to make your verification task easier, though it achieves it through a myriad of base classes. Luckily, users need to bother with only about half-a-dozen of them or maybe 10. But that’s only if you are educated well on UVM and trained by experts. If not, chances are you will loose yourself in the UVM base-class maze trying to make a decent way-out! Choice is yours!

Technorati Tags: SystemVerilog,EDA,UVM

Did you miss multiple-inheritance in SystemVerilog?

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:

                                              

 

Now one may argue this is not all the time needed etc. If you need to get that interesting debate, a good starting point for you could be: http://en.wikipedia.org/wiki/Multiple_inheritance 

Come to think of it, UVM supports TLM ports and that requires multiple inheritance at the core: See the UML diagram for today’s UVM TLM:

 

 

i.e. the class uvm_port_base extends (and implements) a standard TLM-INTERFACE class (call it uvm_tlm_if_base). It is also “hierarchical” and can do better with certain characteristics of a uvm_component such as “instance path”, “parent” etc. The current UVM implementation “works-around” the limitation of SV 2005/2009 by instantiating a local uvm_component instance as a member and provides “proxy” methods to mimic the effect of multiple inheritance.

So below is a sample code using Multiple inheritance feature that is now added to P1800-2012 SystemVerilog standard. It does so by introducing few new keywords/constructs:

• interface class
• class implements

In near future your UVM base class could be remodeled as below (not full code obviously):

              

And voila, the uvm_tlm_port_base implements if_base, port_comp…

 

As we end 2012, start pushing your friendly EDA vendor for this new stuff as early as Q1-2013! Yes, we have this running at CVC with a popular, leading edge tool!

Happy New Year 2013 to all our readers. Equip yourself with all updates on SystemVerilog by signing up for our upcoming sessions at CVC, contact training@cvcblr.com for more!

 

Technorati Tags: SystemVerilog,EDA,inheitance,OOP,multiple inheritance

SV-DPI debug champion – your handy –dpiheader option

Ever played with SystemVerilog DPI (Direct Programming Interface)? Most of the verification engineers coming from EC/EE background, they have hard time debugging C code in general.

Things get complicated when you deal with multi-logic-valued system such as Verilog/SV (0,1,Z,X) and 2-state system such as C. See the standard data type matching slide we deliver during our popular VSV training: (http://www.cvcblr.com/trainings):

 

In case you can memorize the table above and use it each and every time when you touch DPI – perhaps you maynot need this post much. But for the 99.9% users who don’t or don’t want to do that, tools like Questa provide you a very handy option called -dpiheader Let’s see it in action: Consider a simple DPI import declaration as below:

 

Corresponding C-code looks like:

So far so good? For those who have “spotted” the bug, pat yourself and continue reading. Others – any issue so far? Let’s see what the simulation output from Questa looks like:

Now all your debug skills ON..go, chase and find that little:

If you go back to the basics – default argument data type for SV task is logic and is single bit in size. On SV side we had

output data)

On C/DPI side the corresponding mapping as per LRM is:

Whereas what we intended was to use a plain “int” for “data” – the example is kind of trivial to keep things simple and in perspective. Realize that in reality this can be fairly cumbersome mapping to memorize and/or remember.

Here is where the “debug champion” helps – your friendly –depheader option to vlog command.

When you run this, you get an output header file “sv_auto_hdrs_for_c.h”. It is best to include this to your C-code:

 

Now during “vsim” step, the Questa invokes C-compiler and it detects the type-mismatch in arguments on SV vs. C-side. On SV side we said “output data” – indicating it is a 4-state, 1-bit variable, while on C-side we declared it as “int”:

 

 

Now that’s by far a much better issue to debug than the simulation/runtime mismatch of values in C and SV side.

So next time you attempt to use SystemVerilog DPI make sure you read this blog and use the –dpiheader option with Questa. And if your team needs experts, hands-on training on SystemVerilog, contact us via: www.cvcblr.com/about_us

Technorati Tags: SystemVerilog,EDA,DPI,debug