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

Introducing soft constraints in SystemVerilog 2012

A well known aspect of constraint solving is the ability to classify hard vs. soft constraints. A quick Google search on “soft constraints” would lead you to; http://www.constraintsolving.com/tutorials/soft-constraints-tutorial in case you are interested in theory.

Taking a practical example, given the holiday season around the corner many of us would like to travel, book tickets etc. Let’s say that we want to travel from City-1 to City-2 (Say Bangalore to Chennai); the source & destination are fixed and are non-negotiable. But how we travel can be based on preference/availability/cost etc. For instance one may have options of:

• Flight
• Bus
• Train
• Car

Now modeling the above scenario using a constraint specification language like the one in SystemVerilog, there are “constraints” as below;

class my_travel_c;

  rand places_t src, dst;

  rand int cost;

  rand travel_mode_t travel_mode;

  // Non-negotiable src and dest locations

  constraint src_dst_h { src == BLR; dst == CHENNAI;}

  constraint minimze_cost { cost < 2000;};

  constraint travel_preference {travel_mode inside {AIR, BUS, TRAIN};}

endclass : my_travel_c

Now depending on various factors the cost & travel-mode constraints may not be solvable. For instance if only AIR travel is desired, the cost constraint is likely to be violated. As an avid traveler you may not mind that violation and say YES it is fine! But how do you tell that to SystemVerilog? In the past one may go and turn-off the relevant/violating constraint via constraint_mode(0);

However that becomes tedious as before every randomize call you would need to do it (perhaps across testcases).

Welcome the all new System Verilog 2012 soft constraint:

Now if the solver can satisfy the SOFT it shall, and provide you the optimal cost and travel experience. However in case it can’t, the soft can be “ignored” and other HARD constraints shall be obliged!

Now that’s a pleasure luxury to have a set of “default” values while designing the environment and use “soft” constraints, let the tests/scenarios override the same as needed.

BTW – this has been a widely used feature in e – IEEE-1647 language (many engineers relate it to the tool Specman, most popular implementation of the e language). So much so that a new user migrating from Specman to SystemVerilog finds it often annoying not to have this “feature”. Now, thanks to Santa in 2012, come 2013 – you will have that in SV too! Now it is time to ask for your XMAS wish with Santa and your EDA vendor to get this implemented in your favorite simulator!

Have a pleasant journey, holidays and be ready to rock even more with all the more powerful SystemVerilog 2012 soon!

Technorati Tags: SystemVerilog,EDA

Bringing in uniqueness constraint to SystemVerilog – welcome P1800-2012

If you are involved in functional verification I am sure you have atleast heard of System Verilog as the IEEE standard. The first IEEE standard was released back in 2005 and went in for a revision during 2009. Now there is yet another major update – 2012, expected to be fully ratified by early 2013 (on time for DVCon 2013). Here is a nice blog on this: http://blogs.mentor.com/verificationhorizons/blog/tag/ben-cohen/

A major part of this new version is all about assertions/SVA. If you need a detailed list of changes and examples, with applications – look no further, get hold of our new SVA 3rd edition @ SVA book 3rd edition @Amazon

In this article I wanted to introduce another nice, tiny, handy feature – unique constraint in SV. To give a background, consider a classical crossbar switch:

 

While every CPU can talk to/access every memory, for every access uniqueness must be maintained in terms of one-to-one connection. This is usually referred to as “Uniqueness Constraint” (ref: http://www.wonko.info/ipt/iis/infosys/infosys5.htm). In SV 2012, with unique constraint feature one may code a transaction model for this as:

 

 

One could perhaps combine this with a foreach and make it more elegant etc. But the bottomline – the unique constraint is really handy at times!

Welcome SV 2012/2013 :-)

Now our training in VSV (http://www.cvcblr.com/trng_profiles/CVC_LG_VSV_profile.pdf) can cover this as a lab exercise – make sure you enroll in a session to learn more! See: http://www.cvcblr.com/trainings for more!

Technorati Tags: SystemVerilog,EDA

Help yourself & UVM community by sparing few minutes – Verilab’s UVM survey

 

UVM Runtime Phasing and Phase Jumping Survey

If you are well aware of UVM runtime phasing/phase jumping issues, quickly help yourself and the UVM community at large by filling out this survey:

• Verilab UVM Phasing Survey

Now for a background and for those who are “undecided” whether or not I have an issue with it, here is more information:

One of the significant updates done to OVM while bringing up UVM as the standard for verification methodology was the phasing. (For a detailed paper on user issues with OVM phasing approach, see: http://www.synopsys.com/community/snug/india/pages/abstracts.aspx?loc=india&locy=2011 and https://www.synopsys.com/news/pubs/snug/india2011/TA1.2_Intel_paper.pdf)

As with any standard development, there are differing view points coming from various experts, users etc. around the globe.India being the most vibrant Verification geography, it is very probable that many of the verification leads here face these problems day-in and day-out. So why not speak up and help us fix the UVM phasing the way YOU would like it?

Verilab, a premier verification consulting firm based in the US is conducting a survey to find out whether UVM users are currently taking advantage of runtime phasing and phase jumps, and if so, whether or not they would be impacted by certain changes the committee might propose.

So in case you are an active user of UVM, please spare a few minutes and take the survey at:

• Verilab UVM Phasing Survey

Technorati Tags: UVM,EDA,VIP

Is my SystemVerilog mailbox half-full or half-empty? An engineer’s hunger now served!

As we wrap up 2012 with yet another successful VSV course at CVC today’s  topic was IPC in System Verilog. As most of the attendees in this session are young engineers, they have a constant thirst for knowledge and demand more. We at CVC love that challenge. Based on last few sessions we created more smaller examples around threads, mailboxes for the engineers to play around with. Here are some of the meddling around experiments you may do with Mailboxes in SV.

To start with – the size of the mailbox – a.k.a the DEPTH of the FIFO: Here is how you configure the same (the formal argument is named as bound by LRM):

And we had some interesting discussion around the bound & num()  - similar to FIFO’s DEPTH and LEVEL:

To get the code part of it straight, here is what LRM has on these 2 methods:

function new (int bound = 0);

i.e. the constructor for mailbox has an argument that’s defaulted to 0 – be careful with it, this could lead to memory leaks from user code (See: http://www.cvcblr.com/blog/?p=29 )

The summary there – use sized mailbox always. This would fix the DEPTH of the FIFO or the Mailbox:

Now there is a method to get the “current level” of the Mailbox, with prototype:

 function int num ();

Here is a pictorial way to explain its usage:

 

                              

 

To look at some SystemVerilog code:

And to close this article with more pictures than usual – be careful with generic mailboxes – i.e. those with no explicit parameterization. Avoid them if you can, watch this space www.cvcblr.com/blog for an upcoming article on that.

Do more with SystemVerilog! And do call us via training@cvcblr.com in case you want to learn SystemVerilog the right way!

 

Technorati Tags: SystemVerilog,EDA,training