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

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.

TeamCVC

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!

TeamCVC 

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 

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

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

TeamCVC

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.

randomization NOT happening for seq_item variable if uvm_field_* is NOT enabled?

(http://goo.gl/TNSaz)

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).

A Debug assistant

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!

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

 TeamCVC

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!