Category Archives: Aldec

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:

vmm_rpro

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

vmm_ver2  

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 www.aldec.com

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:

vmm_ver3

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.

Regards

TeamCVC

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:

uc1

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:

 uc7

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:

uc3

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:

uc5

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:

uc2

Sample output from Riviera-PRO is below:

uc8

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

TeamCVC

Technorati Tags: ,,,

Asynchronous events and SVA – a quick primer

During our recent SystemVerilog Assertions update webinar (http://www.cvcblr.com/blog/?p=802) one of the audience raised a question on how to check asynchronous events using SVA. Here comes a quick response with code. Also simulated using Aldec’s Riviera-PRO tool.

sva_async

 

As you can see in the picture, no clock involved per-se, but use the start and end events themselves as clock for the SVA.

So, if you’ve more challenging requirements, do drop in at CVC and we will assist you resolve them!

TeamCVC

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

I am sure you have heard this phrase before – “A sledgehammer to crack a nut”; the below picture describes it all!

Would you use a HUGE hammer to crack a small, tiny nut?

hammer_cracks_nut

(If you are further interested in this phrase read: http://www.phrases.org.uk/meanings/sledgehammer-to-crack-a-nut.html).

I recently had a small design error introduced in a piece of  RTL as below: It is an interrupt masking logic, code snippet as below:

ALINT_open

Note the use of “ANDing” logic – simply, AND- mask with data to produce result.The subtlety in Verilog/System Verilog is that you have 2 seemingly similar operators for doing AND operation;

  1. The logical AND: &&
  2. The bitwise AND: &

Given the “loose” data type checking, assignment rules etc. one can get away by using either one of the above many-a-times. In the above case the user used:

result = data && mask;

With result being a vector the above is a “logical/design error” but usually a Verilog compiler would let this go through (as it is not an error as per LRM).

Now one can “verify” this by writing a testbench, simulate, look at waveform and debug. Depending on luck and the expertise of the engineer, it could take some 30-minutes to few hours. But as a Verification power-house CVC suggests to rethink – use the right tool/technology for the right class of design errors. These are things that are very easy for a static verification technology such as HDL-Linting to flag in less than a minute.

For instance, let’s try the above code with a popular Linter – ALINT from Aldec (http://www.aldec.com/products/alint/).

ALINT has nice rule sets pre-packaged for various policies such as STARC (http://www.starc.jp/index-e.html). It produces the following:

ALINT_STARC_rules

This will trigger 2 rules:
–  rule about logic operation having a vector operand
–  rule about bit width mismatch in the assignment – LHS vs RHS.

ALINT: Warning: test.v : (4, 1): Module “top”. “STARC_VLOG.2.1.4.5″ Logical operator has vector argument(s). Use bit-wise operators for multi-bit arguments and logical operators only for 1-bit arguments. Level: Recommendation 1.
ALINT: Warning: test.v : (4, 1): Module “top”. “STARC_VLOG.2.10.3.4″ Assignment source bit width “1” is less than destination bit width “8”. Upper bits of the right-hand side will be filled with zeroes. Match bit widths exactly to improve the readability of the description. Level: Recommendation 2.

Now from a business perspective too – this is a far better option for your management – usually LINT tools are far cost efficient than full blown SystemVerilog simulator(s) such as Aldec’s Riviera-Pro http://www.aldec.com/Riviera

So next time when you receive a RTL code to verify, do yourself a favor by running a quick Lint run before looking for “hard bugs” that demand popular, powerful techniques such as Constrained-random, coverage-driven, UVM based etc.

BTW – CVC offers training sessions (http://www.cvcblr.com/trainings) on Aldec’s ALINT and HDL-Lint in general. Contact us (http://www.cvcblr.com/about_us) to see how we can help your teams!

Happy Verification ahead!