In one of the semiconductor conferences, Dr. Satya Gupta http://bit.ly/KlQpxr mentioned on a lighter note that the Semiconductor/VLSI needs to be promoted more among young Indian engineers and need to be made more “attractive”. (Guess it was Mentor’s U-2-U in 2010, anyone?) – few of the panelists and audience threw out ideas on how to do the same – via contests, TV shows etc. Taking it little more seriously and using social media we at CVC (www.cvcblr.com) believe our blogs/tweets & Facebook updates are doing exactly that.

Here is a “fairy tale” on how SystemVerilog MDAs work (or not work) with UVM field macros. Consider that we have a 3-D array (2 unpacked dimensions and 1 packed dimension) as shown below (“mda_3d” in s2p_xactn below):

While it sounds simple enough, the devil lies in “detail”. When you need to copy/clone/compare you need to ensure this mda_3d is included just like other fields. Huh? That’s what UVM supports via “field_macros” isn’t it? How about:

Oh my dear! Hold your breadth – this works for scalar types, and for 1-D arrays but NOT beyond . Since System Verilog supports “arbitrary” dimensions in MDAs (Multi-Dimensional Arrays), the UVM base class doesn’t provide macros beyond 1-D arrays. Bummer, so what’s next? Here is your helpline – the uvm_object::do_copy.

Here is a simple code snippet that augments the built-in automated “copy” routine to include user defined MDA such as our “mda_3d”.

With that – UVM has once again proven that while it is not obvious why it has so many hidden “gems” – they are all useful on a case-to-case basis. In Hindi we say “Har eak cheez zaroori hota hai”. As the popular AirTel advertisement goes (India specific, for International readers, see: AirTel commercial ad). In case you can related your facebook friends to UVM “features/functions/base classes” and wonder “How come I have so many friends” – as the ad says “Every friend is useful”

Happy UVM-ing.

TeamCVC

• ABV – Assertion Based Verification
• CRV – Constrained Random Verification
• CDV – Coverage Driven Verification

While many ASIC teams have started using these in mainstream, FPGA users are still catching up with theses. One of the primary reasons has been that many FPGA designers use VHDL for RTL and Testench traditionally. (Though there are some high end Verilog users too, let’s talk about them in a separate blog. Meanwhile those folks can see how to adopt System Verilog for FPGAs from: http://slidesha.re/KtLlFu )

While these modern verification technologies are language independent, there is an impression in the industry that they are provided only via SystemVerilog and is thus restricted for Verilog/SV users. Some VHDL RTL teams have been forced to migrate to SystemVerilog just for this purpose – frankly speaking, a die-hard VHDL fan wouldn’t like it and also for teams using VHDL for long it is way too hard to do this migration in short timeframe. More important question is – do I need to migrate to adopt these technologies? – The answer is technically NO. VHDL has been very strong in “adaptability” to various requirements and stood strong amidst tough competition. Its rich features such as overloading, encapsulation (via packages), configurations, data structures etc. have been exploited by various applications such as: modeling, RTL design, testbenches etc.

Assertion Based Verification in VHDL

Recently temporal assertions capability has been added to native VHDL from IEEE 1850-PSL and hence the new VHDL 2009 standard has full fledged temporal expressiveness natively. See a PSL tutorial @ http://www.project-veripage.com/psl_tutorial_1.php

Constrained Random Verification

Given the complexity of designs being done using VHDL and FPGAs it is becoming increasingly difficult to rely just on directed stimulus. Constrained random generation allows exploring newer paths in every simulation run.

VHDL with its package capability allows building constrained random generation feature natively into the language without much hassle. Recently released OS-VMM infact provides it off-the-shelf. See: http://osvvm.org/archives/category/randomization

Coverage Driven Verification

Coverage as a metric to measure verification progress has been around for decades in verification. Code coverage has been widely used by RTL teams. Recently Assertions via PSL-VHDL provide temporal coverage and can be very handy to capture functional coverage of control oriented features. For data oriented features, coverpoint, cross etc. can be created in VHDL via packages. And OS-VMM does exactly that for all VHDL users. See: http://osvvm.org/archives/339

In summary – all the modern verification technologies are now available to VHDL users natively – without any additional cost (of a mixed language simulator for instance). The OS-VVM is a great starting point for coverage & constraints and PSL-VHDL provides all the temporal capabilities. Start doing better verification in VHDL with: http://www.osvvm.org

1. Is it similar to other functions in Verilog/SV?

2. Is it virtual?

3. What is the return type of the same?

4. How does inheritance work for new ?

So here is a blog entry that delves into the “details”.

First of all – it is a function – so it can only have non-time consuming stuff (BTW, a task can be invoked via fork..join_none from within a function).

It is NOT a virtual function. It is illegal to declare it “virtual”.

On the return “type” – it is different from other functions – it is very “adaptive in nature” – i.e. it returns what the LHS requires. i.e. it returns an object of the type of the handle that appears on the LHS. Hence there is NO return type declared for this special function.

Things get very interesting/special when a new class is derived from a base class. With any other System Verilog function/task, you have 3 options while doing inheritance:

1. Override base class behavior
2. Add//append to base class behavior
3. Prepend to base class behavior

For those who are familiar with E, IEEE 1647 language, it is equivalent to

1. is only (override)
2. is also (append)
3. is first (prepend)

However when it comes to this special new function – it always an “append behavior” (“is also” – as in E/Specman): Let’s look at some code & results;

Consider the code below:

Since only a derived object is constructed and there is no call to super.new explicitly one might expect only the message from derived class’s new.

But see what Questa (www.mentor.com/questa) does:

So that’s one “special” behavior of new. i.e. whether or not you call the base class’s constructor – it always gets called implicitly.

To prove this point and to see if we can play some “tricks” with it, here is a small variant code below;

In the above code we just added an argument called “id” to the base class constructor. In the derived we decided to “forget” about it. If it was a “virtual” function, as per the semantics, this would be illegal – i.e. the function prototype/signature must remain same across inheritance. However the re-definition of new in derived class is just fine. However, there is still an error: recall that the base’s new is always called – now the “id” argument is NOT provided for the implicit call to new. So what does our friendly compiler Questa say for this? See below;

So the error message is clear enough as to how it can be fixed. Below is a possible fix:

Now, as a last experiment for this blog, why do we claim only is also is allowed for new ? What if I try other way? See the result below:

Here is what LRM IEEE 1800-2009 has to say for this:

When using the super within new, super.new shall be the first statement executed in the constructor. This
is because the superclass shall be initialized before the current class and, if the user code does not provide an
initialization, the compiler shall insert a call to super.new automatically.

So hopefully you are convinced that the simple looking function new  is indeed “special” function in SystemVerilog.

Happy new-ing

TeamCVC

www.cvcblr.com/blog

One of the significant changes in latest UVM (1.1 onwards) is the so called “phasing” – it is a feature motivated from VMM users and more HW related requirement overlaid on top of more SW centric OVM-like phasing. Refer to a detailed paper on this topic from Intel + CVC @ SNUG India 2011 via: http://bit.ly/JL9×30 

A direct impact of this new phasing in UVM 1.1 is that a smooth running test in OVM/plain SystemVerilog is likely terminate “prematurely” in UVM. This is typical when a first time user adds a UVM test as below:

While everything seems normal as in OVM, here is a sample run.log from this test:

The new phasing seems to be in effect :

• – the reset_phase is kicking and takes its sweet 100 ns of simulation time.
• Sequence starts off
• But hold on.. why on earth is it exiting? Aren’t you supposed to run/execute that sequence for me?

The crux of this has to with the so called run time semantics of “task based phases” in UVM base class library. For those interested, here is a snippet of that documentation:

// Task: main_phase
//
// The <main_phase> phase implementation method.
//
// This task returning or not does not indicate the end
// or persistence of this phase.

And at implementation level, here is what a relevant piece of UVM base class code that does it for you:

Now you say Aha! That explains why my test::main_phase didn’t wait for “seq.start” to finish.

Now you may ask why and more interestingly is it a BUG in UVM? Not really, this is intended, read more of UVM code/doc:

//

// Task: main_phase
//
// The <main_phase> phase implementation method.
//
// This task returning or not does not indicate the end
// or persistence of this phase.

It is necessary to raise an objection
// using ~phase.raise_objection()~ to cause the phase to persist.
// Once all components have dropped their respective objection
// using ~phase.drop_objection()~, or if no components raises an
// objection, the phase is ended.
//

Now that you understand why it happens, here is the fix for it:

Happy UVM-ing. Do call us for quick ramp-up of yourself/your team, we have some great training sessions on the same at: http://www.cvcblr.com/trainings 

TeamCVC

www.cvcblr.com/blog

Clearly SystemVerilog with its all gun blazing features are useful for FPGA community at large, our CTO Srini presented this at FPGA Camp in Bangalore few years ago: http://www.slideshare.net/mobile/fpgacentral/upgrading-to-system-verilog-for-fpga-designs-srinivasan-venkataramanan-cvc 

Since then we have trained several FPGA teams on using:

• SystemVerilog for Design (SVD: http://www.cvcblr.com/trng_profiles/CVC_LG_SVD_profile.pdf)
• SystemVerilog Assertions: (SVA: http://www.cvcblr.com/trng_profiles/CVC_LG_SVA_profile.pdf)
• VSV: (http://www.cvcblr.com/trng_profiles/CVC_LG_VSV_profile.pdf)

One of the things we have learnt throughout this journey with FPGA folks is that they care a lot for usability of EDA tools and they are much more demanding than their ASIC Design counterparts on features like:

• IDE – Integrated Design/Development Environment
• Clear cut error messages from the compiler/tool
• Pin point the source file-line easily

While SystemVerilog in its early years was used primarily by ASIC teams the above features were not that critical. But now with 5 EDA vendors supporting SystemVerilog + UVM + SVA, customers are at good position to demand what they need! BTW –who are the 5 EDA vendors?

• Synopsys (www.synopsys.com)
• Mentor (www.mentor.com)
• Cadence (www.cadence.com)
• Aldec (www.aldec.com)
• Axiom (www.axiom-da.com)

And CVC (www.cvcblr.com) is partner with all of them and is uniquely positioned in the world to provide EDA vendor neutral training sessions. Infact recently we have enabled majority of our training labs (See the full list at: http://www.cvcblr.com/trainings)  to run on all these 5 tools.

Coming back to the use model requirements, here is a screenshot of how Riviera-Pro from Aldec points a common code error in SystemVerilog. Consider the following piece of code: Can you spot what’s wrong?

Of-course with the “dotted” eclipse, most of you should (if not, we strongly suggest you attend our VSV course ASAP: http://www.cvcblr.com/trng_profiles/CVC_LG_VSV_profile.pdf)

here is a screenshot of how Riviera-Pro from Aldec (www.aldec.com) points a common code error in SystemVerilog.

So – hold no more, even if you are a plain Desktop user with limited budget, SystemVerilog is at your reach!

TeamCVC

www.cvcblr.com/blog

Folks working on AMS (Analog & Mixed Signal) Design-Verification often require real numbers for things like Signal-to-Noise-Ratio (SNR). With so much buzz around SystemVerilog and its clear strengths on Constrained Random Verification support, engineers wonder how they could leverage it for “real randomization”.

Unfortunately SystemVerilog doesn’t directly support “rand real” declaration (weird reasons given by EDA developers, while a google on “random float number” reveals quite a few hits). However recall that SystemVerilog is built on top of Verilog and Verilog has some beautiful twin-functions for real <—> bits:

$bitstoreal

$realtobits

Here is a neat trick to use them for a signal-to-noise ratio random generation (Problem originally reported at: http://verificationguild.com/modules.php?name=Forums&file=viewtopic&t=4413)

Notes:

1. We have used new SystemVerilog 2009 syntax for “extern” constraint – nice one indeed to be in line with extern tasks/functions.

2. Also the %p –> Very handy one indeed

3. Used the post_randomize() for one of its best use models – display what got generated automatically. We teach this in our VSV training (http://www.cvcblr.com/trng_profiles/CVC_LG_VSV_profile.pdf) and every customer appreciates that use-case for post_randomize.

In case you want to learn SystemVerilog and jump onto this bandwagon before it is too late, join our training seesions – weekdays, part-time or weekend, see: http://www.cvcblr.com/trainings for details.

Enjoy SystemVerilog & AMS

TeamCVC

www.cvcblr.com/blog

In OVM/UVM (http://www.cvcblr.com/trng_profiles/Do-it-Right-UVM.pdf) I am little confused about the way components are hooked-up hierarchically. Consider the code below:

In the above constructor ,sometimes I am writing parent =null and some times only parent ,and then passing in super.new();, blindly i am doing this ,but i am not understanding why i am making parent=null and sometime leaving this as parent . what will be the effect of making so. kindly help me.

Answer/Explanation:

As an enhancement to Verilog, System Verilog allows “default values” for function/task (methods) arguments. By doing so it allows the caller of these methods to have the flexibility in number of arguments – a.k.a variable arguments to a function (though not overloading as in VHDL). So in the example above, the new has 2 arguments, both having default values.

If we had: (NOTE: the 2nd argument has NO default value)

then the caller of this function must pass atleast 1 argument.

Summary: if a default value is provided in the function declaration, then while calling the function, that argument becomes “optional”.

Now what is the impact of this in OVM context? Actually quite a bit – it is about the “TB hierarchy” – a.k.a print_topology in OVM/UVM. See few screenshots from Aldec’s Riviera-Pro (http://www.aldec.com/en/products/functional_verification/riviera-pro) 2011.02 version below:

Consider a simple OVM based env with:

env –> agent –> monitor

If monitor is constructed with “parent” set to “this” (i.e. the agent), then we get:

If monitor is constructed with “parent” set to “null” then we get:

It gets little murkier with OVM’s factory playing an interim layer with create – but that’s left as an exercise for the readers

We at CVC feel proud to support customers even long after their short training stay with us, see our list of training sessions at: http://www.cvcblr.com/trainings

Happy SV-ing

TeamCVC

http://in.linkedin.com/in/cvcblr

I am trying to check that one of the my inverse clk is reverse of sys_clk:

I have written assertions , but when I am seeing this its checking only on falling edge of sys clk !
Please advise
property me;
@(clk)
clk |-> ~clk_inverse;
endproperty
inverse_pp: assert property (me)
else
$error ("inverse clk is not inverse as expected", $time);

Here comes the “deferred assertions” to your rescue – a new feature in SVA 2009 LRM.

ap_check_inv_clk : assert #0 (clk == !inv_clk);

Can be used both inside a procedural block (such as always_comb) or outisde (as a concurrent statement).

Try and let us know if it worked for you – BTW, don’t forget to turn SV 2009 flag ON to your SV tool to compile the above!

As our CEO posted some code snippet to start with  -we thought we will assist our junior engineers to ponder around the same and explore more on this topic.

class base_pkt;
  bit b1;
  virtual function void display;
    $display ("base_pkt: b1: %b", this.b1);
  endfunction : display
endclass : base_pkt
class extended_pkt extends base_pkt;
  bit b2;
  virtual function void display;
    $display ("extended_pkt: b1: %b b2: %b", this.b1, this.b2);
  endfunction : display
  virtual function void ext_fn;
    $display ("EXT Function");
  endfunction : ext_fn
endclass : extended_pkt
class container_c;
  base_pkt b_p_0;
  function new;
    this.b_p_0 = new;
  endfunction : new
endclass : container_c
program test;
  container_c c_0;
  extended_pkt e_p_0;
  initial begin : b1
    c_0 = new;
    e_p_0 = new;
    c_0.b_p_0.display;
    c_0.b_p_0 = e_p_0;
    c_0.b_p_0.display;
    $finish;
  end : b1
endprogram : test

Some of the advanced questions from http://verificationguild.com/modules.php?name=Forums&file=viewtopic&t=4410

• can main access the methods and properties in the base_packet
• can main access the new methods and properties in the extended_packet class as it is or any casting would be needed
• assume one of the method in base_packet has a method that is virtual, what would happen if this method was called in the main method using the base class handle

Now – it is your turn to solve them based on above code starting point and ask more here in comments. We will try and help you with answers if you need!

Good Luck

TeamCVC

www.cvcblr.com/blog

Here is a recent posting that TeamCVC did on Facebook group (http://www.facebook.com/groups/199014503449605/) , thought it is worth sharing it widely. Bottomline – if you are interested in VLSI, there is nothing that stops you from doing it for free even at college level!

When you say "tools" – a full ASIC platform for free is not realistic, unless it is academic – in which case look at Alliance: http://sourceforge.net/projects/alliancecad/

Though some of the tools in Alliance are industry ready, usually students in India have better tools at their disposal (just that they don’t know about it). For instance:

Modelsim Student edition http://model.com/content/modelsim-pe-student-edition-hdl-simulation

Riviera-Pro student edition: http://www.aldec.com/en/products/university_programs

These tools will run on Windows and or Linux. One can install Cygwin (www.cygwin.com) and get Linux-like experience on Windows itself (to be ready for industry).

After you solve the tools puzzle, then comes "what to do with tools" – there are tons of projects you can contribute such as OVL http://www.eda.org/ovl/pages/main_examples.html

So once you decide to work on VLSI, there are ample opportunities to pick up. If you need further assistance feel free to visit us www.cvcblr.com

Good Luck