During our recent SystemVerilog Assertions update webinar (http://www.cvcblr.com/blog/?p=802) one of the audience raised a question on how to check asynchronous events using SVA. Here comes a quick response with code. Also simulated using Aldec’s Riviera-PRO tool.
As you can see in the picture, no clock involved per-se, but use the start and end events themselves as clock for the SVA.
So, if you’ve more challenging requirements, do drop in at CVC and we will assist you resolve them!
Date: Thursday, October 31st, 2013
Time: 2:00 PM-3:00 PM IST – India time / 9:30 AM-10:30 AM CET (European time)
Host: Aldec, CVC’s valued EDA partner (www.aldec.com)
Presented by: Srinivasan Venkataramanan (http://www.linkedin.com/in/svenka3)
CVC (Contemporary Verification Consultants www.cvcblr.com) – Aldec’s Training Partner,
Assertions have been in use for over a decade for now, however, writing detailed, temporal expressions in plain SystemVerilog (SV) 2005 has been at times a demanding task for first time users. While it gets easier as users mature with SVA, the language has made it more straightforward to express complex temporals with recent additions to the standard.
With SV 2012 LRM becoming freely available to all users, the adoption is expected to grow much faster. This webinar will demonstrate some of the important LTL operators added to the SVA such as until, eventually, etc. Using real-life case studies, the presenter demonstrates how these new operators can significantly reduce complexity of SVA coding. Attendees will be taken through a small, real-life protocol and shown how to break down the requirements in an “edge-by-edge” approach to coding SVA. An Ethernet-like protocol case study will be used to demonstrate the value of assertions while building driver BFMs in UVM. This clearly highlights the benefit of adding assertions upfront in a project cycle by helping reduce the TB development time.
This is a FREE webinar, but registration is required. Choose your slot depending on your geography.
India/Asia/Europe: http://www.aldec.com/en/events/338
USA/Rest Of the World: http://www.aldec.com/en/events/339
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:
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 :-)
With SystemVerilog language gaining popularity among user, it is getting interesting to see user asking similar/repeating “patterns” of challenges in various forums. One of them is on constraint modeling when it becomes more than simple “a > 10” like stuff. Recently a VerifAcademy user asked:
in my testbench i have to make a random signal "[31:0] distortion". it must contain one (or, in other case, two) hot bit(s) (hot bit is "1", all others are "0"). So i have a problem with writing a constraint: i really don't want to write all possible combinations of these bits (if there are two of them, there will be 32! combinations, so...). Does anyone have solution for this problem?
A smart model is indeed available via 2 features of this vast language – System Verilog:
1. A handy system function to count the number of “ones”
2. Constraints can use functions in expressions.
Combining the above two, here is a full solution to the above problem along with a sample run from Questa 10.2
Hope you enjoy the concise solution. Do call us via +91-9620209226 or training@cvcblr.com for learning more about this wonderful language and its applicability for your verification projects.
As many of our customer learn during our regular VSV training sessions, System Verilog added `__FILE__ & `__LINE__ macros similar to C language. It is quite handy for debugging remotely developed code for a newcomer especially. Recently at an UVM forum a user asked how to get the relative path vs. absolute path from this macro. Consider the following code:
The SV LRM says;
22.13 `__FILE__ and `__LINE__
`__FILE__ expands to the name of the current input file, in the form of a string literal. This is the path by
which a tool opened the file,
So if you provide the absolute path name during compile command, you are bound to get the FULL PATH.
Questa when run with full path to the file as below:
produces the following output:
And you could get a pretty short output as below if you do a “magic” (Left as exercise to the interested reader :-) )
Enjoy System Verilog and have fun!
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:
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
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.
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:
etc. Here is a nice work-around for this:
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
