Mind the GAP – even in SystemVerilog macro definition

SystemVerilog enhances the TEXT-MACRO feature (a.k.a `define-s by many young engineers) of Verilog by a good length. Significant enhancements done are:

1. Added capability to extend the definition to multiple lines
2. Added macros with arguments;
3. Macro arguments can have default values too! (not fully supported by all tools though)

However there are few caveats – in general any text-macro usage in any computer language is hard to debug when it fails to compile. So be ready to be patient while debugging macro code.

Recently an online forum user asked a question on SystemVerilog macros. Here is what the user defined to start with:

To a bare eye, the above looks fine. However a  SV compiler would through an error at it. As per the LRM:

 

If formal arguments are used, the list of formal argument names shall be enclosed in parentheses following
the name of the macro. The left parenthesis shall follow the text macro name immediately, with no space in
between.

In other words – as it is with any Metro station sign, you should be careful with the GAP/spaces :-)

Notice that “extra space” after the macro name CHECK1 is now gone! This works in Questa 10.2.

So next time when you code your macros – mind the GAP :-)

TeamCVC

Technorati Tags: SystemVerilog,Verilog,EDA

SV solver puzzle part II – “guidance” vs. “dictation”

 

With one of our recent blog entries on SystemVerilog constraint solver (http://www.cvcblr.com/blog/?p=725) becoming so popular, several readers have contacted us via email to know little more about the puzzle. Specifically they wanted to understand how the solver ordering of variables is determined. Consider the same example as in that previous blog entry:

As noted in the previous blog, this creates an “implicit ordering” of variables – i.e. ‘v1” is solved BEFORE “v2”. A smart engineer (Muthurasu Sivaramakrishnan) asked this:

• Nice one. However, why cant we use Solve.. Before constraint in this scenario?

The answer is a little involved with yet-another subtlety in the language, and hence this new entry:

This reader’s question boils down to whether the above constraint “cst_ordered” is same as the following;

constraint cst_guidance {solve v1 before v2;}

First intuition says YES, but the answer unfortunately is NO. In SV there are 2 kinds of solver ordering - an ordering constraint is more of a "guidance on probability" and does NOT change the solution space. Hence it can't lead to a failure from a success or vice-versa. This is what happens with a solve..before – i.e. it is simply a “guidance” or suggestion to the solver.

However the ordering that gets enforced via function call is more STRICT/DICTATIVE in nature. It enforces the order by further "subdividing" the solution space and in a sense invokes the solver twice. In Questa you can actually see this in action via -solveverbose - you will see 2 "Working Set" prints for function based constraint:

1. First the solver gets “dictated” to solve “v1” INDEPENDENTLY. In a random choice, say it picked a value “1”

2. Now the solver takes up the next variable to be solved in THAT order, i.e. “v2” – you see in Questa the “Working Set’ print with details (note: randomize is called only once per iteration in user code)

 

So this leads to a constraint solver failure. Whereas a mere “guidance” shown by a solve..before would have solved both the variables TOGETHER, leading to a successful solving operation.

Bottomline: The function call “strictly enforces” the solve order, while the “solve..before” is more of a “guidance/suggestion”.

To learn more about this and other advanced SystemVerilog topics, join our training via www.cvcblr.com/trainings

Good Luck

TeamCVC 

Technorati Tags: SystemVerilog,EDA,Constraints,Questa

SVA: default disable – a boon or a bane?

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

As the callout/marking shows – there is a bug in DUT, the signal “serialout” is indeed HIGH during reset, yet the assertion doesn’t fire (Questa shows it as INACTIVE – meaning it is a vacuous success in this case).

So that begs the question of “is the default disable a boon or a BANE”?       

The answer is – you need a methodology and a plan while doing your assertions – categorize the assertions appropriately. Specifically group them as:

• Reset checks
• Functional checks
• Low Power checks

etc. Here is a nice work-around for this:

• Use an explicit “disable iff (1’b0)” for those special category assertions

 

Now Questa flags it nicely as below:

So do use the new SVA stuff on “default disable” – it is indeed a BOON. Just make sure you “think” before you code those special category of assertions.

This is part of our larger story of ABV methodology being rolled out as next generation verification training sessions at CVC. So do contact us via training@cvcblr.com  for more advanced, practical usage of this wonderful technology.

Good Luck

TeamCVC

Technorati Tags: SystemVerilog,SVA,ABV

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