Category Archives: Uncategorized

Which SystemVerilog LRM do you refer to?

As we get to the end of an eventful 2013 and look forward to a great 2014, TeamCVC is at Manipal, a beautiful coastal town in the West coast of India. Surrounded by Arabian sea coast on one side and Western Ghats on the other, this is the ideal place for a peaceful research center and it is no co-incidence that the famous Manipal University is housed here.

Coming to this town and conducting a 10-day boot-camp on SystemVerilog and UVM has been a pleasure so far as we have a young, talented, enthusiastic set of attendees. One thing that we continuously get asked during our VSV training sessions is – which SystemVerilog LRM to refer to? While the Google search reveals several PDFs, it gets quite confusing to a newcomer which one to pickup and refer to. In the past it used to be the due to “lack of reliable, legal reference” as the IEEE LRM was available at a cost. However the IEEE 1800-2012 LRM got released for free of cost, thanks to the IEEE GIT program. So go ahead and get a legal, personal copy of the SystemVerilog LRM for free from:

http://standards.ieee.org/getieee/1800/download/1800-2012.pdf

The added benefit of this updated LRM is that you also are ready embrace the latest features of this ever expanding language. As a tailpiece information, TeamCVC is delivering a half-day tutorial at IIT Mumbai as part of VLSI Design Conference 2014, so join us on Sunday, Jan 15th at IIT Mumbai if you want to get latest SV 2012 features explained with CVC’s renowned quality trainers!

Regards

TeamCVC

Catch-up with SVA 2009-2012 updates – free Webinar on Oct 31st

Simplified Assertion Adoption with SystemVerilog 2012 (EU/ASIA)

Date: Thursday, October 31st, 2013

Time: 2:00 PM-3:00 PM IST – India time / 9:30 AM-10:30 AM CET (European time)       

Host: Aldec, CVC’s valued EDA partner (www.aldec.com)
Presented by: Srinivasan Venkataramanan (http://www.linkedin.com/in/svenka3)

                       CVC (Contemporary Verification Consultants www.cvcblr.com) – Aldec’s Training Partner,

Assertions have been in use for over a decade for now, however, writing detailed, temporal expressions in plain SystemVerilog (SV) 2005 has been at times a demanding task for first time users. While it gets easier as users mature with SVA, the language has made it more straightforward to express complex temporals with recent additions to the standard.

With SV 2012 LRM becoming freely available to all users, the adoption is expected to grow much faster. This webinar will demonstrate some of the important LTL operators added to the SVA such as until, eventually, etc. Using real-life case studies, the presenter demonstrates how these new operators can significantly reduce complexity of SVA coding. Attendees will be taken through a small, real-life protocol and shown how to break down the requirements in an “edge-by-edge” approach to coding SVA. An Ethernet-like protocol case study will be used to demonstrate the value of assertions while building driver BFMs in UVM. This clearly highlights the benefit of adding assertions upfront in a project cycle by helping reduce the TB development time.

This is a FREE webinar, but registration is required. Choose your slot depending on your geography.

India/Asia/Europe: http://www.aldec.com/en/events/338

USA/Rest Of the World: http://www.aldec.com/en/events/339

Missed a UVM field macro? Be ready for surprises – and a debug assistant!

Recently a UVM user pondered over the following question:

randomization NOT happening for seq_item variable if uvm_field_* is NOT enabled?

(http://goo.gl/TNSaz)

To appreciate the issue, consider the code snippet as below:

uvm_dbg_1

Since both hdr and pkt_len are declared rand, one expects them to be randomized. Note that one of the `uvm_field_int is commented – to demo the issue.

Now a recipient/consumer of this transaction does a copy/clone at destination. See a code snippet:

uvm_dbg_3

So far so good, let’s see what happens in a typical Questa simulation:

uvm_dbg_4

The above results of hdr being NOT generated occurs consistently for all seeds (See the forum post if needed). So a typical user suspects that the missing uvm_field_int macro does control the randomization – though not intuitive/true. This could consume quite a few debug cycles (recall that the macro above is commented for demo only, in actual work, as reported in that forum posting, user forgot to  add that at the first place).

A Debug assistant

Now as in our regular VSV training sessions (www.cvcblr.com/trainings) , we showcase the potential applications of post_randomize and one of the prominent ones is to “debug” the generated fields. See below code snippet:

uvm_dbg_5

With the above code added, here is what our friendly Questa has to show for us in simulation:

uvm_dbg_2

So clearly the hdr field does get randomly generated. It is only when a copy of the container class being created, it skips the “copy process”. And this has to do with the lack of macro. Focus on the missing/commented macro below:

uvm_dbg_1

Hope the above makes it self-explanatory – add the macro, you get copy/clone enabled for that specific field. So 2 lessons learnt today:

1. Use field macros consistently

2. More importantly, use post_randomize as your friendly, automated debug assistant for random generation!

Pragmatic choice of ABV language – PSL still shines better than SVA

 

As many of our readers would recall, CVC first became very visible to the industry with our early contribution to the assertion-based verification (ABV) via IEEE-1850 PSL (Property Specification Language). Back in 2004 we co-authored our first book on this wonderful language, first of its kind in the temporal assertion languages to become a standard (See our timeline in Facebook for more). Since then it has been a wonderful run of events in this world of functional verification for close to a decade by now.

One of the significant features of PSL has been its simplicity and succinct means of expressing complex temporals through its “Foundation Language” (a.k.a LTL style) subset. We talk about this in detail in our PSL book (http://www.systemverilog.us/psl_info.html). Recently a user came up with a nice requirement at Forum in Verification Academy (See: http://bit.ly/14JTHlI)

The spec goes as follows:

PSL_in_SV_spec

The user attempted a simple SVA 2005 style, but got weird results, then our beloved co-author and guru of assertions, Ben Cohen provided assistance as below (unverified):

SVA05

Do the same in PSL with FL/LTL style:

PSL_in_SV

Now relate the PSL code back to user spec/requirement:

May be simple, but drives me crazy..

"Req" -> "Gnt" -> "Rel"

When granted, assert if it is going to Idle state before releasing the lock.

Won’t you agree that PSL with its FL/LTL style is lot closer to the spec than the erstwhile SVA-05 sequence based approach?

There is light at the end of tunnel:

1. PSL works well, nice and is usable in all flavors – Verilog, SV, VHDL, SystemC etc.

2. It costs nothing extra in tools – if you have paid for SV, it is very likely you got the PSL too

3. SV 2009 standard did add this LTL features into it, but yet to be supported by many vendors. So your chances of using it in live projects is weak. Of-course push your vendor for it though.

Bottomline – use what works today, PSL is alive & kicking and you’ve already paid for it in your tool. There is hardly any extra learning – if you know one temporal language, the syntax is very similar, so why not get pragmatic and use it!

DITL – applying it to power analysis on smartphones

 

For those uninitiated with the DITL, here is a quick 101 on DITL: – what do you do on a typical day? That’s your Day-in-The-Life

 

image

Now to relate it to our VoW blog (www.cvcblr.com/blog), here is how a DITL for verification could be nicely defined, thanks to Dave Fechser of LSI, read his excellent article on Design Specification Requirements with Verification in Mind at:http://bit.ly/J6Jswr

We at CVC follow this DITL model a lot during our training sessions especially for fresh graduates (See: http://goo.gl/aU8k2 for a PPT and download the contents from: http://www.cvcblr.com/trng_profiles/CVC_EIC_profile.pdf )

Earlier this week, Simon Segars, EVP & GM Processor and Physical IP Divisions (www.linkedin.com/pub/simon-segars/2/2a0/556) presented an excellent keynote at an invite-only, executive dinner event around the CDNLive India 2012 http://bit.ly/TxallC organized by Cadence. His theme was around the low power requirements in modern mobile devices (understandably, as the market needs this topic and who is in a better position than ARM can talk about this – being at the center of most of those smartphones!)

Simon shared some very interesting DITL (Day In The Life) of a typical smartphone with respect to its various features such as:

  • Making calls
  • Surfing Web
  • Taking pictures
  • Watching Video
  • Playing Angry Bird and other games
  • Listening to music

Now with lot of data mining and analysis

Simon showed a typical pattern that revealed 2 important data points:

  1. For a whopping 88% of the time in a day, the kind of applications that are run on a smartphone can be done using a processor with speed < 500 MHz
  2. For the remaining 12% the frequency needs to be > 500 MHz – these are the videos, gaming etc.

Agreed, your numbers may vary, but the fundamental point is – one could do lot of power saving if we have a big processor to serve the high-end apps and a LITTLE processor to attend to the regular, most-of-the-day work such as MP3 playback, phone calls etc.And this is precisely what ARM’s big.LITTLE architecture is all about – have dual cores with Cortex A-7 & Cortex A-15. Read more about it at our recent blog entry: http://www.cvcblr.com/blog/?p=585 

So whether you are doing RTL Design or Verification or analyzing performance data, try and see if this powerful DITL approach would help you – in many of our projects at CVC we use this approach extensively!

Are you a Debug Samurai? Debugging Timing violations – the dreaded $setup/$hold

image

Samurai is a hard hitting warrior with never-say-die attitude. So far as Debug is concerned, the verification engineers become Samurai especially when it comes to Gate Level Debug with timing violations. Here is a breather for those non-Samurais class of engineers coming to you from an advanced Debug integration in Mentor’s Questa debug platform!

If you have been through GLS (Gate Level Simulation) – you are sure of this topic; If you are a honest individual you would admit it is one of the most dreaded debug issues that you see in your DV life! When those timing violations appear here is what w do:

  1. Go over the library files to locate the $setp/$hold specifications,
  2. Occasional LRM reading to recall the arguments to those system tasks
  3. Decipher the specparam value (recall it could be a complex expression involving other specparam, parameters, `define – and last but not the least, any SDF overrides via LABEL)
  4. Now once you have this so called “static” information, the real fun starts – find the time at which clock changed, then the data changed, do the math and reason out why the violation is

By the time you get to the step-4 above you are exhausted (usually, unless you are a verification/Debug Samurai ).

Now it is not all that bad – especially if you are a young engineer willing to invest time and energy, at CVC’s EIC course (http://www.cvcblr.com/trainings teach this in detail. Here are 2 slides from our CFV course (http://www.cvcblr.com/trng_profiles/CVC_IN_CFV_profile.pdf):

image

 

And the next one:

image

 

During our deep-dive Verilog training today for a bunch of IIT graduates, this topic of “timing checks” came up and the young, new army (with potentially few Samurai class engineers too, hopefully) wanted to understand this in detail. Creating an example is easy part, debugging the failures and making sense of it in real project is the tougher part. Here is where Mentor’s Questa debug platform comes very handy. For many years, the messages from $setup/$hold checks are considered the BEST in Verilog (across simulators, to be fair). But what makes Questa more intuitive and easy to use is their “message viewing” automated internally and annotated in Waveform at the top; below is a series of screenshots with little text to explain!

Enjoy reading and even more – enjoy debugging. No more “dreaded debug of $setup/$hold” – hopefully!

First the DFF with timing checks:

image 

And here comes the waveform for a few setup/hold violations:

image

 

The plain vanilla log/transcript is below:

image

To be fair – the above is a great debug message provided by Verilog (and every tool does print the above, I suppose). It does tell you what time the clock and data changed and the setup/hold parameter value. So what’s the big deal in Questa? It is the “message integration” to the waveform Sir!

Here is the debug flow:

  • Double-click on the message in console window
  • It takes you the Waveform
  • Places the cursor on exactly the TIME at which this  error occurred (with reasonable zooming around)
  • At the top of Wave, you have the SAME message annotated (see below):

The annotated messages can be “navigated” just like any other signal value changes! Now with few girds added, you can quickly see that:

  • At 113 ns “d” changed
  • At 115 ns “posedge clk” occurred
  • SETUP time is “3 ns” – Voila! – there is that violation!

image

Similarly for the HOLD violation:

image

 

So if you are lucky – your debugger would do this integration and save you hours!

Met Vriendelijke Groeten (As the Dutch & German say):

TeamCVC

www.cvcblr.com/blog

CRV, CDV & ABV for VHDL users – all native

If you have been in the ASIC/FPGA industry for the past 5 years or so, it is highly unlikely that you haven’t heard of these buzz words:

  • 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

 PSL_VHDL_trace

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.

CRV_1

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

model_coverage_summary_9b

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

 

osvvm_logo

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

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:

new_1

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:

new_2

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;

new_3

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;

 

new_4

 

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

new_5

 

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:

new_6

 

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:

test_0

 

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

 

test_2

 

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:

test_4

 

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:

test_1

 

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:

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?

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?

 

Picture1

 

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.

Picture1

 

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