Explore technologies for “Verification Closure” at DVCon BoF meeting, Tuesday Mar 1st 6.30 PM (PST)

Big picture – Verification Closure

Panel members: Cadence, NextOp, Breker & CVC

If you are attending DVCon starting tomorrow, here is a panel that you may not want to skip – yes UVM is hot and ready-to-go. How do we leverage that and get to faster Verification Closure – that’s precisely what we will be discussing in this “Birds-of-a-Feather” panel at DVCon www.dvcon.org on Tuesday Mar 1st, 6.30 PM US/Pacific time at Donner Ballroom, DoubleTree Hotel, San Jose.

Here is a summary of what to expect in this panel discussion:

UVM is great! Enables interoperable VIPs to be created, reused. In a typical SoC – several such UVM VIPs get integrated and 1 (or more) embedded processors (ARM-like) configure/control the flow. Individual sequences/virtual sequences at UVM level will do great for peripheral-alone testing.

Taking right from UVM SoC reference flow @ www.uvmworld.org, here is a sample SOC:

How about true “flow/scenario” testing? UVM’s virtual sequencer is “A possibility”. A pragmatic approach as outlined by an excellent article by my good friends @ Applied Micro, Pune (India) is here:

http://www.design-reuse.com/articles/22264/system-verilog-ovm-verification-reusability.html

 

 

The above approach requires lot of coding, synchronization and pretty much directed across transactions/interfaces. How do we randomize “across interfaces/peripherals” to mimic system-level flows/scenarios?

Even if we code up all Sequence libraries, virtual sequences and virtual sequencers – we got only the stimulus, what about complete “Verification Closure”?

On top, overlay Low Power features, requirements and annotate Power State table information – the number of different paths/arcs to be coded and tested is mind boggling – imagine coding them via virtual sequences/sequencer – do-able, but lot of work indeed!

Every DV team does this today in one-way or the-other. But what new technologies are available or becoming available to assist?

Come and listen to experts in this domain at “Birds-of-a-Feather” panel at DVCon www.dvcon.org on Tuesday Mar 1st, 6.30 PM US/Pacific time at Donner Ballroom, DoubleTree Hotel, San Jose.

Here are some key items that would be discussed: If you have more ideas/questions send them across to sevnka3@gmail.com or post as additional comments here at www.cvcblr.com/blog I will incorporate them as much as I can!

• Need truly inter-operable VIPs to start with – This is where UVM comes-in. We at CVC are at DVCOn UVM poster session.
• Need key “metrics” to define, drive and track the progress (Various sources including formal)
• How to focus on “critical, high quality” coverage targets?
• A coherent, high-level mechanism to capture the scenario models that aid in:
• generate stimulus
• capture scenario specific checks/criteria for success and
• Cover them across interfaces, temporal transaction coverage

Come and share your views, learn what your fellow DV folks do all at DVCon!

Feedback from customer on our SystemVerilog training

 

Recently TeamCVC (http://in.linkedin.com/in/cvcblr) conducted a 4-day SystemVerilog workshop at Kochi, South India. Some musings at:

http://www.cvcblr.com/blog/?p=259 

And today we received a cool note from customer voluntarily:

Vinayaraj T R, Project Engineer @Cochin:

I have attended your training on System Verilog for Verification conducted last week at Kochi.  The session was very much helpful for me and even being a fresher I was able to understand the concepts and gain a lot of knowledge from it. I am very sure that it will help me a lot through out my career.

It would be helpful if you could share the lab tutorials of that training.

Thank you once again.

Regards,

Vinayaraj T R,

Vinayaraj is certainly not alone. It is this customer satisfaction that gives us the “passion” to do more!

Until another customer success story, it is sign-off from Bangalore, TeamCVC

Find deeply buried functional bugs with Graph based solver

 

Are you an expert Verification engineer using upto date languages & methodologies available such as Specman/E, SystemVerilog, VMM, OVM, UVM etc.? Are you looking for even more technologies to find “deeply buried functional bugs” in a language agnostic manner, yet be able to reuse the underlying TB code? Read what Dave Whipp, a veteran HW Verification engineer found working over the last few years:

http://verificationguild.com/modules.php?name=Forums&file=viewtopic&t=4172 

Specifically:

There is a pressing need for testing tools that are language-agnostic – and such tools are indeed emerging. The shadow of the SystemVerilog steamroller is lifting.
One such tool, that I have been using successfully over the past few years, is Breker’s Trek. Trek randomly generates directed tests using a constrained random walk of a graph (constructed by verification engineers) that describes how an environment interacts with the DUT. This is a step back from the purist approach of SAT-based constraint solvers, but it does provide an effective platform for exploring deep sequences of interactions. It would be good to see panel discussions of SAT-solving Vs graph walking as methodologies for finding deep bugs.

See a snapshot of how a graph based solver can explore constraints that maybe “temporal” and across several transaction hierarchies:

 

 

There is lot more to Trek than this, but this ability itself is beyond today’s existing SAT based solvers. Now combine that with the STRONG and UNIQUE block-to-SoC auto test generation – a new paradigm in verification is rolling out..

See www.brekersystems.com for more. And CVC (www.cvcblr.com) is your partner in India to bring this advanced technology close to you, call us if you want to learn more.

Happy testing!

SystemVerilog Assertions’ field-day at Port city of Cochin!

 

TeamCVC (http://in.linkedin.com/in/cvcblr) is at Cochin, a famous port-city in South India (http://en.wikipedia.org/wiki/Kochi) this week on a “Mission SystemVerilog” at a customer site. It is a 4-day program covering:

• SystemVerilog basics for RTL designers (http://www.cvcblr.com/trng_profiles/CVC_LG_SVD_profile.pdf) 
• System Verilog Assertions (http://www.cvcblr.com/trng_profiles/CVC_LG_SVA_profile.pdf)
• SystemVerilog for Verification engineers (VSV: http://www.cvcblr.com/trng_profiles/CVC_LG_VSV_profile.pdf)

The audience is a mix of young, enthusiastic engineers in their early-to-mid career – all very keen to hone their skills on SystemVerilog. Our CTO, Srini (http://in.linkedin.com/in/svenka3) chose to customize the training in a timely manner to get the audience involved and interactive. During Day-2, it was a true “field-day of SystemVerilog Assertions”. Especially when it came to Sequence repetition operators, it was fun all across the room. Needless to say CVC’s SystemVerilog Assertions labs are very well laid out with concrete examples to demonstrate the various sequence operators. However with assertions the fun really lies when you “slightly” change the sequence and/or the trace. Here are some screenshots from this “field-day”.

One of the sequences that we experimented is to demonstrate the difference bet’n non-consecutive [= N] & GOTO [-> N] operator.

One of their smart engineers asked/wanted to change the ##1 to ##0. This is to explain the “endpoint” of a sequence/property as in:

  a |=> b [-> 2] ##1 c;

 

Lucky that we had access to Riviera-Pro running on our laptop, on-the-fly we could tweak the code/trace and demo it live:

 

The fun gets only more when there are multiple threads & multiple attempts. Here is how Riviera-Pro nicely shows it up on Waveform – like a real “THREAD”.

TechnoFun with System Verilog – I turned rand_mode OFF, yet get constraint violation? Crazy Friday evening phenomenon, maybe?

Ravi Teja , ASIC Design-Verification Engineer @ www.cvcblr.com &

  TeamCVC (Nikhil, Satish, Srini et al.)

SystemVerilog is a massive language with several surprises under its belt. Every time you encounter some unexpected result, the first reaction is “Oh! I know System Verilog, this is incorrect behavior of the tool”. Voila! EDA developers get paid *really well* and read the LRM thoroughly before committing their code in. This is not to say that there are no bugs in EDA tools (“bug free EDA tool” is more or less an OXYMORON). But with System Verilog tools becoming more and more stable and advanced, it is very likely the case that you fall under the famous John Cooley’s signature (www.deepchip.com):

 

So was our recent experience with Aldec’s Riviera-Pro simulator with SystemVerilog constraints. 

Let the code speak for itself:

class xactn;
   rand int var1;
   rand int var2;
   constraint c_var1 { var1 inside {[1:10]};}
   constraint c_var2 { var2 inside {[1:10]};}
endclass:xactn

Now var1 & var2 are non-state variables. Whenever I randomize an object of this class, the solver should obey the constraints – no ground breaking stuff, is it? Consider turning the non-state variables to “inactive” state. SystemVerilog supports rand_mode(0/1) for this, a quick explanation for the same is below:

 

Now the real fun starts when you delve into corner cases (a la “the devil lies in the detail”). Even though the rand variable is turned inactive, its value MUST be within the values as demanded by the constraints – in other words the “constraints” are still ACTIVE. This has obvious but overlooked results when used with a rand_mode(ON/OFF). The results after randomization are tabulated below:

So why is the 2nd & 3rd case don’t result in random values for var2, var1 respectively? Isn’t that a bug in the EDA tool? Shouldn’t we be calling their support@aldec.com staff? Hold on.. Let’s believe the tool, after all – some of the best minds in comp-science write these geeky solvers, they must have had something in their mind while writing this piece of code inside :-)

A little bit of RTFM (Read The Fine Manual) reveals the “hidden” secrets of “Art of Debug” with Riviera-Pro. It supports a rc_verbose flag which, when set to a magic value of “2” throws out messages to the log file.

set rc_verbose 2

# RCKERNEL: Error: ../src/test.sv(1): The condition 'c_var1()&&c_var2()&&rc_ext_constraint' is overconstrained.

# KERNEL: 1 (0,0) Var1 =           0 , Var2 =           0

# RCKERNEL: Error: ../src/test.sv(1): The condition 'c_var1()&&c_var2()&&rc_ext_constraint' is overconstrained.

# KERNEL: 2 (0,1) Var1 =           0 , Var2 =           0

# RCKERNEL: Error: ../src/test.sv(1): The condition 'c_var1()&&c_var2()&&rc_ext_constraint' is overconstrained.

# KERNEL: 3 (1,0) Var1 =           0 , Var2 =           0

# KERNEL: 4 (1,1) Var1 =           3 , Var2 =           9

# KERNEL: 5 (0,0) Var1 =           3 , Var2 =           9

# KERNEL: 6 (0,1) Var1 =           3 , Var2 =           4

So the first 3 randomize() calls were failing – important that you handle the return value from object.randomize() (Guideline-1).

First three cases gave a constraint violation. We observed that for cases 1,2,3 atleast one of the constraints is not fulfilled.Hence the randomize method returns zero. What? I turned the rand_mode to OFF, yet it tries randomizing and failing? Crazy Friday Phenomenon Huh?

 

Oh Dear, wait..let’s peel the onion and see why..

This is because each call to randomize involves two steps:
1)solve
    In this step all the constraints are solved (as they are still active). The solver must keep the values of var1 and var2 
between 1 to 10. Their default values are however 0. (i.e var1=0 & var2=0) . This violates the constraints, hence the solver failed.
2)assign
If the solver passed (i.e no constraint violation) and rand_mode is ON then the randomized value is assigned to the variables

Now in case 2 & 3 wherein only one of the variables is set to rand_mode(OFF), the AND operation means that – since the solver ahs failed, no assignment of potential random value to the other variable is performed, hence retaining the value 0f “0”.

Now, the constraint debugger with Riviera-Pro is good to start with, wish it had pin-pointed it to the exact constraint that caused the violation, instead of combining both into single equation as:

# RCKERNEL: Error: ../src/test.sv(1): The condition 'c_var1()&&c_var2()&&rc_ext_constraint' is overconstrained.

Oh, let’s leave some room for improvement :-)

Now, as a closing remark and 2nd coding guideline – if you are changing the rand_mode, see if you can isolate related constraint on that variable and make constraint_mode(OFF) as well. Once again as John Colley puts it:

 

From a fresh grad to VLSI Design engineer – Meet Mr. Kaleem, Sasken

 

They say the best appreciation one can get is through one’s customers’ voice – we at CVC (www.cvcblr.com) take every individual trainee as serious as our corporate customers. That has been our reason behind success on both Corporate & individual levels. Here is yet another success story, this time from Md. Kaleem, ASIC Design-Verification Engineer @ Sasken. Kaleem got trained by TeamCVC and also was consulting for us for 2 projects after the training, through which he gained real practical knowledge that has helped him sail through the tough job climate. Kaleem went through our EIC (http://www.cvcblr.com/trng_profiles/CVC_EIC_profile.pdf) and then worked on OVM http://www.cvcblr.com/trng_profiles/CVC_DR_OVM_profile.pdf projects before moving on to even better job prospects.

Here is what he wrote to us over this weekend! Good luck Kaleem and keep in touch!

Mohammed Kaleemulla (http://in.linkedin.com/pub/mohammed-kaleemulla/23/186/b98)

Sent: Sunday, January 16, 2011 12:23 PM

Hi,

Sir This is Kaleem here,i have got a job in Sasken for the post of design verification engineer,I thank CVC for giving me all the support required for developing  the technical and knowledge-able skills, without which I wouldn't have  reached here and I hope we will have a reciprocate communication.

Regards
Kaleem

SystemVerilog constraints – distribution & using FCOV to visualize the effect

– Satish U, ASIC Design & Verification engineer @ CVC (www.cvcblr.com)

Every day at work is learning something new. More so when you are asked to work deep into advanced technologies such as SystemVerilog. In a recent project I was asked to delve deep into the constraints portion of SystemVerilog and solve few customer problems in modeling real life traffic pattern generation using SystemVerilog constraints. As part of it, I came up with an interesting to way to visualize the distribution through SystemVerilog covergroup/coverpoint. Though it is little round-about and may not be the best way to “verify” distribution, the technical lead at CVC quickly grasped the value and encouraged to explore more and develop a blog on the same. It is this “cultivating ideas” that makes working at CVC (www.cvcblr.com) a perfect blend of learning & fun (and don’t miss it – very aggressive timelines too).

 

                  A New way to check the distribution

  By definition the distribution within randc must be uniform. Let’s formulate this statement and validate the same. To find the distribution of lets say randc within a particular range N (N is the number of values in the range). Now let us assume M is the number of times an object is randomized.

Each value has a probability of 1/N.
 

• Case1: IF M = 1*N - If M= N then the values should be unique without any repetition.
• Case2: If M = 2*N - each value should be generated 2 times.
• Case3: M = K*N. Hence the number of times each value shall be generated is equal to K.
  

The N & M determine the “stimulus” side of verification. How do you “check” the distribution? An automated & robust method would be to use a queue and check the contents of the queue to see if they are unique, Infact one of our interns (Suhas: http://in.linkedin.com/pub/suhas-reddy/15/b02/49) is doing this as a mini-project at CVC (www.cvcblr.com) as part of our popular BUDS internship (http://www.cvcblr.com/downloads/BUDs_CVC_Acad.pdf).

However I proposed another interesting way to do this: Declare X as a cover point within a covergroup , so by default we will have N bins created for the N number of values (else one could use the auto_bin_max if care to). Other choice would be to use an array bin as shown below.

To demonstrate with an example:

`define N 4

`define K 1
`define M `K ** `N

`define seed_value 100

package pkg;
class xactn;
  randc bit [(`N-1):0] a;

  covergroup cg;
   A_cp      : coverpoint  a { bins a[] =  {[0:15]};}
  endgroup:cg
   function void post_randomize;
     cg.sample();
   endfunction

lets assume a 4 bit vector a, So we can have 16 possible values (N = 16).

We used Aldec’s (www.aldec.com) Riviera-Pro:      

Here is how Riviera visualizes it in its coverage report.

 

• Case1: for M = N if all the bins are hit once it means that i have uniform distribution.
• Case2: M = 2 * N - each bin should be hit 2 times.
• Case3: Now lets take the constant 2 as K. the equation becomes M = K*N. Hence the number of times each bin is hit will
     be equal to K.
  

We used this method to analyze various constraints and distributions. More about it in part-2 of this blog. Stay tuned to VoW blog!