Category Archives: UVM

SystemVerilog Soft constraints usage in `uvm_do_with macro

Recently we were asked a good & interesting question:

  • How do I use “soft constraint” in the macro `uvm_do_with? What would be the syntax?

I say this is a good & interesting b’cos of 2 things:

1. The SV LRM doesn’t give an explicit example for this (it is fine, not that it should, LRM is not a textbook)

2. The use case should be considered (This specific user had a good need – for automatic coverage closure – or ACC).

Now quickly jumping to solution, based on our SystemVerilog 2012 tutorial that our CEO Ajeetha delivered at IIT Mumbai earlier in 2014 (, here is a code snippet:


For those who need a quick background on what are soft constraints, see: 

Now with 3 major EDA vendors supporting this syntax, you should leverage on this more!

Test Specification Language – the past, present and the future

At DVCon-14, leading EDA vendor MENT has taken the initiative to propose a Test Specification Standard (see: ). Given that SV & UVM are well established and deep into their development, stability and adoption phase, the innovation has to come at next level of abstraction. Over the last decade, we at CVC have been working with customers (semiconductor design houses) and EDA partners in defining, evangelizing and deploying multitude of technologies and languages such as OVL, e/Specman, eRM, PSL, SVA, SV, VMM, OVM, AVM, UVM etc. While most of them address the key aspects of “how verification shall be effectively carried out”, the next level of “What defines my verification space” has been left for adjacent technologies. Now with this new initiative we are starting to see this problem being addressed. Here is a quick summary of various attempts that have been made to address this problem so far. Hopefully the new Accellera committee will look at most (if not all, and maybe more) of the predecessors to define the future language for “Test Specification”.

1. Mentor’s inFact has a graph based language ( and a nice GUI around it.


2. Breker Trek ( – one of the first EDA companies to promote Graph based verification. Breker strongly advocates use of Graphs for stimulus-coverage-checking – all 3 in one “scenario model”. To keep things true and open to our readers, CVC has been an official representative for Breker in India for few years by now.


3. Vayavya labs ( has a SOCX-Specifier that captures the scenarios and spits out SystemVerilog classes (a la UVM).


4. Cadence’s vPlan (extension to e) – one of the earliest solutions in this space, has been in production use for many years at customer projects. Basically captures the plan-2-test-2-results flow in a XL form and/or vPlan file (ASCII) format. Allows teams to collaborate in a geographically distributed team by providing a common dashboard of the verification status.


5. SNPS VMMPlanner – It also has a proprietary extension to SV known as HVP – Hierarchical Verification Plan.


6. CVC’s Assertion Driven Test Synthesis ( As part of CVC’s Verification consulting engagements, we use an internal, time-tested approach to define the scenarios in an extended SVA-like syntax. The “test intent” is captured via SVA-like syntax and then our services team converts that to tests+checkers+scoreboard+coverage as per customer need on their chosen language & methodology. Contact srini <> for more. 

7. Bluespec’s BSV – not really a test specification language, rather a rule-based specification language built on top of SystemVerilog syntax. Not sure if they eye this new language development as a good opportunity to donate their language, but we at CVC believe this will be a good anecdote to learn from.

8. SV’s own randsequence – a less known, less powerful feature of SystemVerilog called “randsequence” supports BNF style productions to specify the test-flow. Not very popular, though a detailed look by the proposed committee is worth, as we feel.

Maybe there are few more solutions around that we haven’t captured here, please do send the details to me via email (srini<>, we will consider adding them here soon.

Now to conclude/wrap-up this (long) post, here are some abbreviations for this next generation language – surely a lot more names can be considered, a starting list:

. TSL – Test Specification Language

. VSL – Verification Space/Specification Language

. GSL – Graph/Goal Specification Language

SystemVerilog-VMM to UVM migration – first step

In one of our recently concluded UVM training sessions at CVC a customer asked how easy is it to migrate an existing proven code base running with VMM to UVM. Since this is a very common situation, we at CVC have put together a detailed set of case studies and a half-a-day workshop on this topic. As a starting point we ask few simple questions to the customer on their code base so that we can provide an estimated effort involved in the migration. Invariably we start asking “Which VMM version do you run?” – and many are actually unaware :-( Here is a tiny piece of code that would get the answer right from your simulation:


A small VMM-built-in utility class is provided as part of VMM named vmm_version. It has few interesting methods, First one being:


The first one displays the major-minor versions such as 1.11 and vendor name. Typically EDA vendors customize these opensource libraries to add debug features and at times to fix incompatibilities across implementations. For instance when VMM was first released in opensource TeamCVC made it working on all EDA tools, fixing any Synopsys specific features in the VMM base class code. Then we donated it back to the community and other vendors did more changes. If you are interested in running it with Aldec’s Riviera-PRO feel free to contact us or directly

The other function that prints more information along with the “configurations  used to generate the VMM base code” is:     vmm_ver1

A sample output of the above from Aldec’s tool is below:


So in case you are migrating from VMM (or OVM) to UVM, call us for hints, case studies, or even better join our workshop on this topic.



Technorati Tags: ,,,

SystemVerilog UVM comparer – hidden gem in show_max

Recently a customer sought a help on how does the UVM’s built-in scoreboard mechanism works, specifically in_order and algorithmic comparators. While he was able to use them well in his design, it when things fail – i.e. he potentially found a design bug he needed additional assistance in debug. By default the UVM framework provides compare() routine for transaction/uvm_sequence_item. However unlike its predecessor HVLs such as the “E” language (IEEE 1647) or the OpenVera, System Verilog does not have the compare routine built-in to the language itself (for classes). Hence UVM adds it via base class and more. So when we have a transaction model such as:


Now by virtue of inheritance, a handy method my_xactn::compare is available.  So one can use it to compare 2 objects of this type as shown below:


Note: in the above code snippet the return value of compare is unused, in actual code of-course you should assert it/throw an `uvm_error etc.

Now, when we simulate this with Aldec’s Riviera-PRO here is what we see:


But now the user asked 2 good questions:

  • How does it know what to compare?
  • Why is printing only 1 mismatch and not all?

The answer to the first question above is the `uvm_field_int macro. In the transaction model one should add:


The UVM_ALL_ON flag in the macro instructs the code to consider each field for all built-in routines/methods like copy/clone/compare etc. We also suggest adding the post_randomize for ease of debug.

Now moving onto the 2nd question that the user asked: “Why does it print only 1 mismatch”?” – the built-in uvm_comparer has a field show_max that controls how many mismatches to show/display and its default value is 1. One could change it and set it to its maximum using SystemVerilog’s bit-fill operator ‘1. Now when we pass the modified comparator object to the compare() routine we will see al mismatches:


Sample output from Riviera-PRO is below:


Hope you find this hidden-gem nside uvm_comparator useful in your debug cycles. Have fund and contact us via in case you’ve a tough debug problem to crack.


Technorati Tags: ,,,

Pinning down SystemVerilog program block

One of the verification related constructs in the vast SystemVerilog language is the program construct. It is also one of the most debated features as to whether it is needed or not. Sure it is very well supported by all EDA tools, and heavily promoted by Synopsys with their VMM to start with. OVM (from Mentor & Cadence) didn’t advocate it though and in fact they discourage it. With UVM – it is a 50-50 – if you like it, use it, else don’t bother.

From a technical perspective we at CVC like the fact that we now have a clear TB-2-DUT separation. We do teach this during our regular VSV training sessions (

Here comes a 2-minute run-down on this nice feature. Let’s look at some code:



Line 6: #10 DUT ‘reads” a signal named “sig_1”.

Line 14: #10 TB “drives” the same signal “sig_1” (They are connected, not shown above)

Consider that the above “write” and “read” to the signal were done on “module” scope – this is potential “race” – as 2 different simulators can schedule these 2 initial blocks in arbitrary order. Such a race will be painful to debug, hard to migrate, harder to maintain etc. So how does bringing in program help here? Assuming you are familiar with System Verilog event scheduling mechanism (we cover this in detail during our SVA training – one would recall that there is a region named “REACTIVE” region that executes AFTER the “design” region/assignments. The program block code executes in this reactive region thereby avoiding the races by language! One could visualize this by running the code above in any SV tool. Here is a snapshot with Mentor’s Questa 10.2:



As you can see in the log/transcript, the “DUT” gets done first and then comes the TB/program block – all in same time-stamp though.

Now that being guaranteed to be consistent across EDA tools, users have one-less thing to worry about in their Verification journey.

Do send your comments via



UVM-ML is here: Funcntional Verification is heterogeneous in nature – notes from DAC 2013

As part of my recent DAC 2013 minutes, here are some of the musings from customer experiences around DAC this year (and some from projects we have been doing in 2012-13 here).

While there is a large set of customers exploring SystemVerilog in its full capacity and with UVM, make no mistake – not many will throw away what has been done previously and that was precisely my talking point at DAC 2013 theater presentation earlier this June.

Below are some of the slides I presented to get you started:

And it is in this context the recently announced UVM-ML initiative from Accellera becomes very relevant to every verification team. It is still very much open and all of you can contribute to developing this to be useful to the verification community at large. You can learn more about this UVM-ML from this Cadence blog:

See you soon at UVM-ML conference calls/discussions.


Out-of-the-box UVM experience with modern day EDA tools

It surprises me often how many young engineers (read “fresh graduates/Recent College Graduates”) struggle when it comes to the UNIX/GCC/Makefiles etc. I still recall our old IIT days when we did Yahoo/Altavista (Google wasn’t around back in 1996) search to resolve most of such issues and of-course use some common sense. 

Coming to the recent experience, as we were preparing for our recent demo at SNUG India 2013 DCE booth, I asked some of our young team members to run few UVM tests. When it came to the 11th hour preparations I got several error reports from these young engineers with various errors related to gcc/PATH etc. In our regular UVM training sessions the Makefiles exist so not much challenge in this regard. But when you ask these folks to create Makefile on their own to run UVM, things start getting interesting. A recent error message showed to me was:


recompiling module apb_subsystem_top
All of 30 modules done 

g++ -w -pipe -O -I/home/student/tools/eda/synopsys/vcs-mx_VE-2011.03-SP1-2/include \

-c /home/student/tools/uvm-1.1c/src/dpi/
/home/student/tools/uvm-1.1c/src/dpi/uvm_hdl.c: In function ‘int uvm_hdl_set_vlog(char*, \
t_vpi_vecval*, PLI_INT32)’:
/home/student/tools/uvm-1.1c/src/dpi/uvm_hdl.c:235: error: ‘vpi_release_handle’ was \
not declared in this scope

make[1]: *** [uvm_dpi.o] Error 1


A quick check with them revealed they were NOT really behind any custom UVM base library/version, any recent one would do. That led us to a much simpler fix – use the out-of-the-box UVM that gets shipped along with the modern day  EDA tools. For the starters, here are the 3 most popular tools and their options to run UVM out-of-the-box:

Cadence: IUS

irun -uvm -f file_list_with_your_src_files

The -uvm option will take care of all the include-dir and the DPI stuff needed to get UVM base-lib visible and usable for your code.

Synopsys: VCS

  vcs -ntb_opts uvm -f file_list_with_your_src_files 

The option -ntb_opts uvm takes care of the UVM base class for you! BTW, NTB stands for “Native TestBench” in VCS lingo.

Mentor: Questa

qverilog -f file_list_with_your_src_files

If you are wondering who takes of the “UVM” here – your most friendly EDA simulator does that “automatically” for you – the moment it “detects” uvm_pkg in your code. 

Sure you will need to learn how to use “customized UVM-lib” at times, but the above can well be a good start. Please note that the version of UVM could be different in different tools and even among different versions of the same tool (say IUS), but assuming you are just a beginner these details shouldn’t matter much to you to start with.

Good Luck with your UVM voyage!



Smart constraint modeling in SystemVerilog

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 for learning more about this wonderful language and its applicability for your verification projects.



Technorati Tags: ,

SystemVerilog 2009 macro `__FILE__ – absolute or relative path?

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!


Technorati Tags: ,

Dare to think beyond UVM for SoC verification


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 ( 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 (, 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.