Category Archives: New Technology

Any new technology on Functional Verification goes under this category

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

Is your RTL Linter makes you find needle in the haystack? Here is a smarter approach!


Static design verification through thorough RTL analysis started several years ago, with early stage ones simply being “linters” and the later, advanced ones combining some of formal techniques as well. One of the most common complaints by RTL teams while using linters is the SNR – Signal-2-Noise Ratio of the endless set of errors/warnings from the tool. So much so that we have heard of customers giving up on linters, primarily those freebies/bundled with simulator ones. While it is true that some of the reported ones are indeed serious issues, the ROI (Return On Investment) of having RTL designers navigating through the ocean of messages is too little in many cases.

OTOH there are clear set of issues that a good LINTer can spot for you quite easily, for instance see:

Sledgehammer to crack a nut? – Use right tools for right class of design errors/bugs: 

Essentially it comes to the art of “Finding the needles in the haystack” and in a timely manner:


Don’t loose your heart, there is a silver lining with modern day linters/static analysis tools. We TeamCVC covered the rise of new age linters back in 2010; Recently Ascent from RealIntent showed the below case study that proves this very point:


In the following table you will see the results of the analysis of Ascent IIV on 130K gates of RTL logic that was done by NEC in Japan.

Table 1.  Ascent IIV Intent Checks and Failures Report for a 130K Gate Block.
The tool generated 31,186 intent checks that were analyzed by its various engines and 2,999 failures were produced in total.  The hierarchical reporting of the tool characterized these failures into several categories.  It determined that by fixing the Primary Errors (purple column in the table) this would eliminate the duplicate, secondary and many structural errors.  In this benchmark, 181 primary errors were identified.  This represents a dramatic contraction of almost 95% of the total failures from the tool.  You can read further comments by NEC here.

So next time when you hear of the Linter’s SNR issue, do recollect this “smart categorization” and push for it in your solution or move/upgrade to better ones. you should however check on local support team for such new age products though as these tools do require some hand-holding especially in the initial stages of adoption.

Good Luck,


Technorati Tags: ,

Invitation to contribute to next generation Verification standard – join the eWG

To all the ASIC Verification enthusiasts interested in pushing the limits beyond existing languages and methodologies, here is your chance to contribute and be part of the change. As many would be aware, IEEE 1647 standard defines Functional Verification language e.

For over a decade e language has provided many advanced features for verification engineers that have recently been adopted to other languages such as SystemVerilog as well. The most recent one being “soft constraints” – see:  And as more customers demand more features, the working group on e language has been busy adding new proposals. In our last group meeting we agreed on having four working sub-groups.

These are:-
1)      Temporal Working Group
2)      Messaging Working Group
3)      Types and Operators Working Group
4)      General Working Group
So this is a general request/invitation for group leaders and for other members of the group to help drive them on. Each group will be responsible for going through the donated documentation for each new/modified feature, and for getting it into a state where it can be integrated into the standard, which will be done in conjunction with the editor. Working Groups can meet independently of the main group, reporting progress back or discussing issues where necessary.

So get started with your innovation beyond your current job/employer and grab the chance to influence wider community. Join us @ eWG:



Co-chair, IEEE 1647 Working group

Technorati Tags: ,,,,

Quick start on ABV for VHDL designers – OVL + VHDL + Modelsim

Recently an ABV early stage user/explorer realized it is little hard to get started with OVL-VHDL-Modelsim combination. It surprised us as  it would many others in the industry, having known how well folks at Mentor have been supporting OVL, VHDL etc.

As valuable QVP partner with Mentor, we at TeamCVC decided to make it easier for end users. When we dug further we did realize it is not out-of-the-box. Hence we created a quick start example and uploaded it to our website.

Feel free to grab it from here: 

It is certainly a quick example just to demo the flow. Will add more soon. Here is the README for the example:

CVC’s OVL VHDL Example with Modelsim

To compile and run OVL VHDL example in Questa/MTI follow this example

We’ve used ovl_one_hot on a DUMMY signal, just to demo the flow.

You need latest OVL 2.7 release. We’ve included a part of that in this tar ball

To run
cd run_dir
make ovl

Still we strongly suggest VHDL users to choose PSL. But in case you need OVL, this example could help. Feel free to grab it from here: 

Send us your comments via

Technorati Tags: ,,,,

VHDL + PSL action blocks – quick guide

For those VHDL folks exploring advanced verification techniques such as ABV (Assertion Based Verification), here is some trick for you all! A many of you would be aware VHDL 2008 standard incorporated IEEE 1850 PSL (VHDL flavor) in it and much before that EDA tools supported PSL + VHDL as a good combination. One of the earliest tutorials on PSL and most widely read one is available @ and was authored by our CEO Mrs. Ajeetha Kumari.

As it can be seen in the tutorial PSL makes ABV adoption really simple and effective and leads to immediate benefits to the design verification cycle. One of the not-so-uncommon requirements from user community of VJDL + PSL is the ability to refer to PSL events/status from within VHDL Testbench code. This could then be used for PASS/AIL detection, coverage etc. A nice trick in PSL is to use “endpoints”.  Now coming to specific syntax, there are2 variants – in Accellera version of PSL, endpoint was a keyword as shown in ode below. This feature works like charm in most of the EDA tools. However in IEEE 1850 version of PSL, this has been replaced with ended() method. We will focus on endpoint in this example, but do try the alternate if your tool already supports it.


Basic idea is to use the endpoint to detect end of  a desired sequence of temporal and that now becomes an implicit boolean inside the underlying HDL framework (VHDL in this case).

A broader scope would be to expand this capability to assert/cover etc. There is a proposal for it at; but NOT approved/implemented by tools yet. Start adding your view in that TWIKI page and push your vendor for supporting the same.


Technorati Tags: ,,,,

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.


DAC 2013 notes: Giraffes are everywhere, Verific inside story

As I recount on my recent DAC at Austin experince, one thing that surprised me was the number of Giraffes (sure, images/toys, wish the real ones..but I was at DAC and not a zoo/safari) in the exhibit floor.


Yes, am talking about the Verific’s mascot here. It was one of the tallest standing booths so not many could miss it. My friend Sashi Oblisetty led me to them after our early breakfast meeting that morning at DAC. I met with Michiel Ligthart, Verific’s president and chief operating officer. He is a tall man, a Netherlander/Dutch (Graag, ik kan een klien beetje Nederlands spreken .. –  Glad, I can speak a little bit Dutch language, thanks to my early days of work at Philips, Eindhoven). It was a pleasant surprise to see how many customers Verific has to-date, from their facebook page I found:

That’s impressive indeed. No wonder I found several small Giraffes on other vendors’ booth tables. It reminded me of the popular "Intel inside" campaign, perhaps Verific should do similar "Verific Inside" campaign in EDA world :-) Or should we call it "Giraffes are everywhere" (For those avid travellers, see:

I also met Ahbijit Chakraborty, their India GM (based out of Kolkata/Calcutta) and we agreed to follow-up on some of our DVAudit ideas post-DAC. If you wonder what DVAudit is, here is a brief on what I presented at Cadence theater at DAC floor, drop us a note via if you need more details.

Truly an engaging crew at Verific booth, we at TeamCVC do look forward to their PERL based parser front end to build custom utilities for our customers.


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.

Did you miss multiple-inheritance in SystemVerilog?

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/2013 it does!

For those yet to get there – here is  a quick recap:

    Simple inheritance                  Few derived classes

 inh1        inh2


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 as many of you who have been fortunate to have attended our popular UVM training sessions ( across the world (Yes, we have delivered across India, various cities, across the globe as in Europe, Asia etc.).

However what was not allowed in older SystemVerilog (2005/2009) is:

Multiple inheritance, as in:



Now one may argue this is not all the time needed etc. If you need to get that interesting debate, a good starting point for you could be: 

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 “works-around” 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 P1800-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):

inh_tlm2               inh_tlm3

And voila, the uvm_tlm_port_base implements if_base, port_comp



As we end 2012, start pushing your friendly EDA vendor for this new stuff as early as Q1-2013! Yes, we have this running at CVC with a popular, leading edge tool!

Happy New Year 2013 to all our readers. Equip yourself with all updates on SystemVerilog by signing up for our upcoming sessions at CVC, contact for more!


Introducing soft constraints in SystemVerilog 2012

A well known aspect of constraint solving is the ability to classify hard vs. soft constraints. A quick Google search on “soft constraints” would lead you to; in case you are interested in theory.

Taking a practical example, given the holiday season around the corner many of us would like to travel, book tickets etc. 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 non-negotiable. But how we travel can be based on preference/availability/cost etc. For instance one may have options of:

  • Flight
  • Bus
  • Train
  • Car

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;}

  constraint minimze_cost { cost < 2000;};

  constraint travel_preference {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 System Verilog 2012 soft constraint:


Now if the solver can satisfy the SOFT it shall, and provide you the optimal cost and travel experience. However in case it can’t, the soft can be “ignored” and other HARD constraints shall be obliged!

Now that’s a pleasure luxury to have a set of “default” values while designing the environment and use “soft” constraints, let the tests/scenarios override the same as needed.

BTW – this has been a widely used feature in e – IEEE-1647 language (many engineers relate it to the tool Specman, most popular implementation of the e language). So much so that a new user migrating from Specman to SystemVerilog finds it often annoying not to have this “feature”. Now, thanks to Santa in 2012, come 2013 – you will have that in SV too! Now it is time to ask for your XMAS wish with Santa and your EDA vendor to get this implemented in your favorite simulator!

Have a pleasant journey, holidays and be ready to rock even more with all the more powerful SystemVerilog 2012 soon!

Technorati Tags: ,