Category Archives: standards

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: ,,,

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: ,,,,