by Ajeetha Kumari, Srinivasan Venkataramanan, CVC Pvt. Ltd.
INTRODUCTION
SystemVerilog has become the most widely deployed Verification language over the last several years. Starting with the early Accellera release of 3.1a standard, the first IEEE 1800-2005 standard fueled the wide spread adoption in tools and user base. Since 2005 there is no look-back to this "all encompassing" standard that tries to satisfy and do more for RTL Designers and Verification engineers alike. The RTL designers benefit from the enhanced SV-Design constructs aimed at better modeling, lesser typing and new features. Many RTL designers also add simple assertions via SVA into their code as their RTL develops – they do themselves a big favor by doing so as this leads to less time to isolate a design (or environment at times) errors when a verification test fails later in the design flow. Adding SVA inline also assists engineers to formally document their assumptions about interface signals, corner cases etc. in an executable form. The verification engineers, arguably the more empowered ones with SystemVerilog's vast new features, simply cherish the ability to build high quality verification environments, stimulus, reference models etc. all by staying within a single language. SystemVerilog being built on Verilog's syntax significantly reduces the barrier between designers and Verification engineers thereby leading to more productive debug cycles as the designers are willing to look at "seemingly similar syntax".
Long term DV enthusiasts and pioneers have been used to certain advanced features in the adjacent languages such as PSL (IEEE 1850) and E (IEEE 1647) and once in a while miss those "handy ones" in SystemVerilog 2005 standard. The good thing about having a standard in IEEE is that it has a well defined process that allows looking for contributions, attracting donations from adjacent technologies and growing the language further. In this sense SystemVerilog is more like the English language, which has been adopting/including words from various other languages and by doing so becomes more and more prevalent in the spoken world. In that process there has been several significant upgrades done to SystemVerilog 2005 standard, one in 2009 (IEEE 1800-2009) and the standardization committee has approved another update, the IEEE 1800-2012 standard.
We at CVC have been working very closely with customers in deploying this wonderful standard that is destined to touch every electronics engineer in one way or the other since its early Accellera 3.1a version days. We have been educating customers on the new features as and when they become available both as a standard and ofcourse on the tools like Questa, Questa-Formal etc. In this endeavor we have experienced several user queries, issues and woes with current standard features and suggest the new features as soon as they get evolved.
In this article we list the top 5 features that would enhance current SV users to do their job much better. So whether you are a RTL designer or a die-hard verification engineer, sit-back, relax, and indulge in these evolving new standard features. The added benefit for Questa users is that most of this works today in Questa simulator, so read, enjoy and start using these features in your projects!
SOFT CONSTRAINTS
A well known aspect of constraint solving is the ability to classify hard vs. soft constraints. Let us take a lifestyle example for understanding the new "soft constraints"; consider the case of an inter-city travel. Let's say that we want to travel from City-1 to City-2 (Say Bangalore to Chennai); the source & destination are fixed and are nonnegotiable. But how we travel can be based on preference/ availability/cost etc. For instance one may have options of:
Now modeling the above scenario using a constraint specification language like the one in SystemVerilog, there are "constraints" as below;
class my_travel_c;
rand places_t src, dst;
rand int cost;
rand travel_mode_t travel_mode;
// Non-negotiable src and dest locations
constraint src_dst_h { src == BLR; dst == CHENNAI;}
// Nice to have low cost, but a "soft" constraint perhaps
constraint minimze_cost { cost < 2000;};
constraint travel_by {travel_mode inside {AIR, BUS,
TRAIN};}
endclass : my_travel_c
|
Now depending on various factors, the cost & travel-mode constraints may not be solvable. For instance if only AIR travel is desired, the cost constraint is likely to be violated. As an avid traveler you may not mind that violation and say YES it is fine! But how do you tell that to SystemVerilog? In the past one may go and turn-off the relevant/violating constraint via constraint_mode(0);
However that becomes tedious as before every randomize call you would need to do it (perhaps across testcases).
Welcome the all new SystemVerilog 2012 soft constraint.
Voila! With the addition of this "soft" keyword, the constraint solver (at right) inside Questa respects your constraint as long as possible. However when confronted by other, simultaneous hard constraints, the soft constraint "relaxes" itself automatically without user intervention leading to a practical solution. It is as-if the user has added an explicit constraint_mode(0) "on need basis".
For long time CRV (Constrained Random Verification) users, this feature has proven to be of great use with E language in the past to setup default values, payload lengths etc. A specific user test may add additional hard constraints that may provide a seemingly conflicting value to the variable being solved, but being "soft" the new style constraints adapt themselves well!
UNIQUE CONSTRAINTS
How do you generate a set of unique numbers in SV today? Say an array of unique, random valued integers? One usually needs to write a bunch of interacting constraints to get there. To give a background, consider a classical crossbar switch.
 |
While every CPU can talk to/access every memory, for every access uniqueness must be maintained in terms of one-to-one connection. This is usually referred to as "Uniqueness Constraint" (ref: http://www.wonko.info/ipt/iis/infosys/infosys5.htm). In SV 2012, with unique constraint feature one may code this very easily. Below is a screenshot of Questa with the output plotted.
MULTIPLE INHERITENCE
As some of our customers ask during our advanced SystemVerilog/UVM training sessions, SystemVerilog doesn't allow multiple-inheritance. Or to be precise "DID NOT have", now in SV-2012/2012 it does!
For those yet to get there – here is a quick recap:
Simple inheritance
Few derived classes
One can of-course "derive" from another "derived class" too, as-in:
This is used widely in good System Verilog code and in general any OOP code. UVM uses this a lot. However what was not allowed in older SystemVerilog (2005/2009) is:
Multiple inheritance, as in:
Come to think of it, UVM supports TLM ports and that requires multiple inheritance at the core: See the UML diagram for today's UVM TLM:
i.e. the class uvm_port_base extends (and implements) a standard TLM-INTERFACE class (call it uvm_tlm_if_base). It is also "hierarchical" and can do better with certain characteristics of a uvm_component such as "instance path", "parent" etc. The current UVM implementation "worksaround" the limitation of SV 2005/2009 by instantiating a local uvm_component instance as a member and provides "proxy" methods to mimic the effect of multiple inheritance.
So below is a sample code using multiple inheritance feature that is now added to 1800-2012 SystemVerilog standard. It does so by introducing few new keywords/ constructs:
- interface class
- class implements
In near future your UVM base class could be remodeled as below (not full code obviously):
And voila, the uvm_tlm_port_base implements if_base, port_comp…
LTL OPERATORS IN SEQUENCES & PROPERTIES
Assertions have been a critical piece of any verification project. They are orthogonal to the popular UVM framework and provide the much needed assistance in terms of checking the quality of design being verified through succinct expressions. SVA (SystemVerilog Assertions) support a pyramid style, layered architecture to capture complex temporal expressions in a composed fashion through sequences and properties. For example one could express an arbiter requirement as:
a_arb_latency : assert
property (req |=> ##[1:10]
grant); // assumes default
clocking
|
Now consider a simulation trace that ends prematurely – i.e. req is asserted and within next few clocks the test ends before the grant was asserted by the DUT. This scenario may or may not be acceptable depending on the intent of the test. In SV-2009, such an incomplete temporal shall be treated as "weak" and hence a tool like Questa shall provide you a warning and not an error. This is because the default strength of the temporal in a property is "weak". However one can make it a stringent requirement that the test should wait at least till the temporal finishes by using the new strong keyword around the consequent:
a_arb_latency : assert property(req |=> strong(##[1:10] grant) );
|
As shown below, this can help in quickly locating an environment/testcase issue by flagging the error. Without this added help, one would need to debug a possibly long log file to isolate the missing grant with the aid of waveforms, etc.
The concept of weak vs. strong temporal evaluations is well known in the formal world and in LTL domain. The power it brings to functional verification in terms of expressing various design behaviors is now fully available to SystemVerilog users! There are also a series of handy new LTL operators such as nexttime, always, until, until_with, eventually added to the SVA – they all have origins in the adjacent IEEE 1850 PSL standard and as noted in the introduction, SystemVerilog is open to more such donations making it a natural choice for every DV engineer (a la English as a common language for human communication).
GLOBAL CLOCKING
With the recent developments in formal verification (model-checking), tools like Questa Formal make it more compelling for the mainstream DV engineers to leverage on this great technology. These DV engineers hitherto have been writing assertions but primarily aimed at simulation. The possibility of running formal verification on their RTL blocks with the same assertions written for simulation is quite inviting to them as they can leverage the work done already and get additional verification for free! However one of the challenges in writing SVA code that is compatible across simulation and formal verification has been the identification of primary system clock. One needs to make the same information visible to both these technologies in-order to get similar verification setup. SV 2009 added the concept of global clocking to facilitate this. With this a user can designate a clock as global clock (per-module/ interface etc. or for the entire system as the case may be). The SVA code can then refer to this global clock via newly introduced system function $global_clock instead of a local clock name. This makes the SVA code portable across technologies.
Occasionally DV engineers want to verify the clock generation logic itself via assertions. Typically they look for issues like:
- Clock period violations
- Glitches
- Unknown values etc.
This has proven to be very useful especially in establishing Gate-Level Simulations where-in the run times are huge and any additional help in debug saves days if not weeks. The new global clocking feature extends the power of SVA in cases such as these as well.
CONCLUSION
SystemVerilog with all its advanced features is becoming more and more capable with every upgrade. Tools like Questa have started supporting the latest additions as well. As explained in this article, the latest updates cater to RTL designers, assertions enthusiasts, testcase writers and methodology developers. So whichever task you do with your next SystemVerilog project, make sure you do better with latest SystemVerilog features! We at CVC (www.cvcblr. com) work closely with Mentor via their QVP program to train your team on all these latest developments, so contact us for all your training needs on SystemVerilog and Verification in general.
ACKNOWLEDGEMENTS
We would like to thank Josef Derner, Mentor Graphics for providing us early access to Questa 10.2 so that we could try out some of the latest features in simulation. We also would like to sincerely thank Ben Cohen (www.systemverilog.us) for his pedantic review of this article.
REFERENCES
- SystemVerilog 1800-2012 LRM, http://standards.ieee.org/findstds/standard/1800-2012.html
- SystemVerilog Assertions 3rd edition, http://www.systemverilog.us/sva_info.html
ABOUT THE AUTHORS
Ajeetha Kumari is the founder & CEO of CVC Pvt. Ltd. (www.cvcblr.com). She has co-authored several books on the topic of functional verification including PSL, SVA & VMM. She has trained, mentored several engineers in India on these topics. She consults on key verification topics and is an active member of several online forums such as Verification Academy (www.verificationacademy.com).
Srinivasan Venkataramanan is currently the CTO at CVC Pvt. Ltd. and has more than 14 years of experience in ASIC design, synthesis and verification. He has worked at various semiconductor companies such as Philips, RealChip, Intel and also recently at Synopsys. He has presented at various conferences worldwide such as DesignCon (East), DVCon, VLSI Conference etc. He has trained several practicing engineers on SystemVerilog & UVM across the globe. He is currently the co-chair of IEEE-1647 E standard and is an active member of several committees on standards development.
Back to Top