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
Are you an avid fan of CRV – Constraint Random Verification? Have you played enough with System Verilog constraints? Many of our customers having attended our regular VSV training (http://www.cvcblr.com/trainings) do become so! One of the nice features of SystemVerilog constraint mechanism is its “bi-directionality” – a key feature that makes the distribution fairly wide spread and makes the state space well covered.
The industry has learnt it over the last decade of CRV usage – bidirectional constraints are better than unidirectional ones (that was the default in previous generation solver inside popular tool like Specman – called PGen. Even Specman has moved to a more robust, bi-directional IGEN/Intelligen few years back).
In SV this bi-directionality is subtle. Consider the code below:
To an average SV engineer the above 2 constraints look “same” as the function is trivially doing a return job. However they are different for an avid SV user or a solid SV solver such as Questa from Mentor. As per LRM:
Random variables used as function arguments shall establish an implicit variable ordering.
Hence in case of “cst_ordered”, the variable “v1” is solved FIRST and then the “v2” – i.e. they are solved separately and not together (Which is what happens with ‘cst_bidir”).
So what’s the big deal? Consider “v1” is chosen to be “1” first, then the solver has NO solution for “v2” :-( leading to a constraint failure.
So, next time when you use a function in a constraint, remember/recall/read this blog :-)
Care for a proof? See what Questa’s solveverbose prints:
qverilog file.sv –R –solveverbose=2
Enjoy CRV, enjoy SystemVerilog. In case you want to delve deeper into SV, do call us via training@cvcblr.com
Over the past few years, the term “pre-silicon verification” has been quite popular and several technology advancements have helped in solving that puzzle. Some of the biggest contributors have been languages such as e/Specman and SystemVerilog with supporting technologies such as constrained-random verification (CRV), coverage-driven verification (CDV) and assertion-based verification (ABV). All these three technologies when used in unison addressed the challenge at the block or intellectual property (IP)level fairly well. Recently UVM has been developed as a framework to use these languages in the best possible manner to try and keep these technologies scalable to larger designs, such as system-on-chips (SoC). Thanks to the Accellera committee devoting time and effort, UVM is becoming quite popular and the de-facto IP verification approach.
However with SoCs, there are several new challenges in the verification space that threaten to quickly outgrow the current prevalent technologies such as CRV and UVM. One of the key pieces in an SoC is the embedded processor/CPU – either single or multiple of them. Witha transaction-based verification approach such as UVM, typically the CPU gets modeled as a BFM (bus functional model). Some customers term this as a “headless environment” indicating that the “head” of a SoC is indeed the CPU(s). In theory, both the CPU bus and the peripherals can be made to go through grinding transactions via their BFMs.
Figure-1: Sample headless SoC environment
While this certainly helps to get started, soon engineers find it difficult to scale things up with advanced UVM features such as the Virtual Sequencer, Virtual Sequences etc. Even with deep understanding of these, developing scenarios around them has not been an easy task. The length of such sequences/tests, their debug-ability and review-ability have started begging the question of “are we hitting the limits of UVM” - especially in the context of SoCs?
If you thought this is too premature of an assessment, hold-on: the trouble has just started. Anyone involved in an SoC design cycle would agree that the so called “headless environment” is just a start, and would most certainly want to run with the actual CPU RTL model(s) running C/assembly code running on the same.
Figure-2: SoC environment with actual CPU RTL running C/assembly code
This is a significant step in the pre-silicon verification process. The current UVM focus doesn’t really address this immediate need, thereby forcing users to create a separate flow with a C-based environment around the CPU and hand-coding many of the same scenarios that were earlier tested with “headless UVM” environment. Though the peripherals can still reuse their UVM BFMs, the “head” is now replaced with actual RTL and the co-ordination/synchronization among the peripherals needs to be managed manually – no less than a herculean task. We have heard customer saying “I’ve spent two months in re-creating concurrent traffic, a la the headless environment in the C-based setup”.
The hunt has been on for a higher level modeling of the system level scenarios that can then be run on either a headless or C-based environment – keeping much of the scenarios as-is. Here is where the graphs start to make lot of sense as human beings are well versed with the idea of mind maps (http://en.wikipedia.org/wiki/Mind_map) as a natural, intuitive way of thinking about simultaneous activities, interactions and flow of thoughts.
Breker has been the pioneer in this space by introducing a graph-based approach to functional verification. With graphs, users capture the IP level scenarios as nodes and arcs making it ideal to capture the typical day-in-the-life (DITL) for the IP. Many such IP-level graphs can then be quickly combined to form a SoC level scenario model such as the one below:
Figure-3: SoC level scenario model
With a graphical scenario model, TrekSoc (http://www.brekersystems.com/products/treksoc), the flagship SoC verification solution from Breker, can then be asked to either churn out transactions for a headless environment or embedded C-tests for the actual CPU based system with a flip of a switch.
Figure-4: Using scenario models with TrekSoC
This is clearly way beyond current UVM intended goals as UVM is created to solve the problem of VIP reuse and it serves its purpose very well.
Now, with C-tests being auto-generated, the possibilities are endless – they can be reused across the breadth of verification and validation in various platforms starting with simulation, through emulation/prototyping, and all the way up to post-silicon validation.
Bottom line: UVM is serving the very purpose it has been developed for – to create interoperable, reusable VIPs. However a full SoC verification is much more than a bunch of VIPs. It requires next abstraction level models such as the graph based scenario models. Such scenario models can then be compiled by TrekSoC to produce C-tests and/or UVM transactions.
Recently a UVM user pondered over the following question:
randomization NOT happening for seq_item variable if uvm_field_* is NOT enabled?
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).
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!
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
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!
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).
