What is “special” about SystemVerilog’s new - constructor

During one of our recent VSV training sessions, a smart attendee asked few interesting questions about SystemVerilog’s new constructor. Questions like:

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

New to System Verilog - UVM? Wonder why it exits at time zero?

With UVM http://www.uvmworld.org/ adding a good framework around SystemVerilog, several ASIC design teams have taken the first step in adopting it in full form. Many are migrating from either OVM or VMM and many others are plain SystemVerilog and/or Verilog users.

 

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/JL9x30 

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

Do you care for better error messaging in SystemVerilog compiler?

With so much fever around SystemVerilog in the verification community, more and more junior engineers are picking up System Verilog. Infact several universities started teaching System Verilog as part of advanced VLSI degree. And with its availability in Desktop based simulators like FPGA design tool chain, more and more FPGA designers are looking at it, and adopting it rapidly.

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

Real number randomization in SystemVerilog

 

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