Friday, July 2, 2010

SystemVerilog OVM’s apply_config_settings – why & were?

Arayik Babayan, a friend of mine from Armenia asked me what is the use of “apply_config_settings” in OVM. As you may be aware SystemVerilog is a flexible language that can be used for building highly configurable and scalable verification environments. OVM adds a great deal of capabilities on top of plain “system verilog” to make it lot easier to handle that task. One of them is the configuration interface mechanism – usually we use set_config* and get_config* stuff. Internally OVM’s build() takes care of “applying” these settings. automatically usually. What if you want to change few settings across the env after the build? That’s when you use this apply_config_settings explicitly – it internally calls the set_*local for modified settings and viola – you are ready to go!

That’s “advanced OVM” for this week!

 

Enjoy OVMing..

TeamCVC

www.cvcblr.com/blog

Tuesday, June 29, 2010

Dealing with SystemVerilog constraint solver failures – the Questa way

… Tuesday Technote on Solver Debug, Jijo PS, Srini TeamCVC www.cvcblr.com

Dealing with simple solver failure – looking for really “quick help”. It is a layered SystemVerilog code for a SAN Router. An inherited constraint in a testcase showed randomize() failure. Before you jump to conclusion on the simple nature of the problem – consider that this is the first time eevr I look at this design/env as the original author moved out of the company (sign of good times :-) ?) and am given to fix the code ASAP – in next 15 minutes that’s (sounds way too familiar, Huh?).

 

# Number of fware xactn 19
# ** Fatal: [Time 0 ns] Test cfg Solver failure
#    Time: 0 ns  Scope: san_rt_top.san_rt_test_pgm_0.b1.lp.a1 File: ../
rt_test_03.sv Line: 83
# ** Note: Data structure takes 9699728 bytes of memory
#          Process time 0.03 seconds
#          $finish    : ../test/san_rt_test_03.sv(83)
#    Time: 0 ns  Iteration: 2  Instance: /san_rt_top/san_rt_test_pgm_0

 

So what next? Consult our friendly Questa SolveDebug: add vsim –solvedebug and bang you go…

It does 2 things:

  1. It prints the minimal set of conflicting constraints,
  2. Creates a stand-alone test to reproduce the failure in a crisp testcase. See below:

 

Minimal set of constraints from user-code

# ../test/san_rt_test_03.sv(82): randomize() failed due to conflicts between the following constraints:
#     ../test/san_rt_test_03.sv(59): san_rt_test_cfg_0.cst_reasonable_fw_xactns_1 { (san_rt_test_cfg_0.no_of_fware_xactions > 32'h00001360); }
#     ../src/san_rt_fware_gen.sv(42): san_rt_test_cfg_0.cst_reasonable_fw_xactns { (san_rt_test_cfg_0.no_of_fware_xactions < 32'h00000032); }
# ** Fatal: [Time 0 ns] Test cfg Solver failure
#    Time: 0 ns  Scope: san_rt_top.san_rt_test_pgm_0.b1.lp.a1 File: ../test/san_rt_test_03.sv Line: 83
# ** Note: Data structure takes 9699728 bytes of memory
#          Process time 0.02 seconds
#          $finish    : ../test/san_rt_test_03.sv(83

Testcase being created by Questa (system verilog code, can be run standalone)

 

# ../test/san_rt_test_03.sv(82): randomize() failed; generating simplified testcase scenario...
# ----- begin testcase -----
# module top;
#
# class TFoo;
#     rand bit [15:0] \san_rt_test_cfg_0.no_of_fware_xactions ;
#     constraint all_constraints {
#         // ../src/san_rt_fware_gen.sv(42): san_rt_test_cfg_0.cst_reasonable_fw_xactns { (san_rt_test_cfg_0.no_of_fware_xactions < 32'h00000032); }
#         (\san_rt_test_cfg_0.no_of_fware_xactions  < 32'h00000032);
#         // ../test/san_rt_test_03.sv(62): san_rt_test_cfg_0.small_tst_cst { (san_rt_test_cfg_0.no_of_fware_xactions < 32'h000013ec); }
#         (\san_rt_test_cfg_0.no_of_fware_xactions  < 32'h000013ec);
#         // ../test/san_rt_test_03.sv(59): san_rt_test_cfg_0.cst_reasonable_fw_xactns_1 { (san_rt_test_cfg_0.no_of_fware_xactions > 32'h00001360); }
#         (\san_rt_test_cfg_0.no_of_fware_xactions  > 32'h00001360);
#     }
# endclass
#
# TFoo f = new;
# int status;
#
# initial begin
#     status = f.randomize();
#     $display(status);
# end
#
# endmodule
# ----- end testcase -----
#

 

Now that was easy to fix, simply override the test-specific constraint in the inherited test_cfg than “adding to it”. Glad I met my deadline for today!

 

Hats off Questa – wish it prints the vsim –solvefaildebug automatically on such failures to log file.

TeamCVC

www.cvcblr.com/blog

Monday, June 7, 2010

Pre-DAC round-up of Verification technologies

Given the business climate and local commitments, it is hard for me to be at DAC. But with keen focus on Verification it is kind of important for CVC (www.cvcblr.com) to share our thoughts on fresh ideas/technologies on Verification that are being demo-ed at DAC-2010 (www.dac.com). Leaving the BIG-3 out (I hope to blog about them prior to DAC on what we see as “updates” from them separately), here is a quick round-up of what we see as promising solutions that any DAC attendee in Verification domain might be interested. Feel free to comment via our blog @ www.cvcblr.com/blog – we would love to hear them!

NextOP

One of the most promising start-ups in the assertion based verification domain. They have been in stealth mode for a few years. Only recently quite a bit of information has been let out about their technology. It all started with an eval report from a real user and active follow-ups from then – see: http://www.cvcblr.com/blog/?p=147

Ben Cohen (www.systemverilog.us) recently had some good discussions about this technology based on our DVCon-2010 paper on SVA paper (contact us to get a copy: http://www.cvcblr.com/about_us) It did find some interesting bug via simulation run –> property extraction –> coverage hole –> bug! It is a little long route, but however it is an interesting approach. See details at:http://www.cvcblr.com/blog/?p=163

Make sure you visit their booth @DAC (NextOp exhibits at Booth #1442) to learn more. In a nutshell their technology is about analyzing existing RTL & testbench+testcase (via regression) and extract quality properties for your design – then it is upto the RTL designers to qualify whether these “properties” are assertions/coverage/don’t cares. Their promise is minimal noise, but your mileage may vary!

Vennsa’s OnPoint

If you ask anyone in EDA/Semiconductor industry about the “elephant in the room” problem in front-end VLSI, the answer is loud-n-clear DEBUG! Besides SpringSoft/Novas noone seemed to have the perseverance needed to sail through tough times trying to address that problem. (Remember Veritools, anyone BTW?) Now we have a genuine attempt to automate the debug – Vennsa’s OnPoint. Not much is known yet about it, but here is a picture (Copyright by Vennsa http://www.vennsa.com/ ):

onpoint_screenshot

This actually fits very nicely with our Unique workshop on “Debug” (see: www.cvcblr.com/trainings) – wherein we look at some of the common debug problems and demonstrate how little tricks with TCL, GUI/Markers etc. can save you hours if not days!

Look at some of our earlier Tweet’s  on OnPoint at www.twitter.com/sricvc to get some more info.

I’m sure we will hear more about it in coming weeks/months.

Jasper’s ActiveDesign

One of the most charismatic EDA tools that I’ve come across with so far – that’s if they really deliver on being the “Twitter of RTL Design” expectation that has been set of this. A picture is worth more than…here you go:

image

Read more about it at: http://www.cvcblr.com/blog/?p=144

Zocalo-tech

Do you care to approach your ABV adoption more methodically? Quoting Harry Foster, all time ABV promoter: (from his invited tutorial entited: “Assertion-Based Verification: Industry Myths to Realities”,

……”what differentiates a successful team from an unsuccessful team is process and adoption of new verification methods. Unsuccessful teams tend to approach development in an ad hoc fashion, while successful teams employ a more mature level of methodology that is systematic”. ……

Now Zocalo is one vendor trying to address that “methodology” aspect of ABV – via their Bird-dog primarily. We looked at their Zazz-OVL and even during today’s SVA training locally (http://www.cvcblr.com/trng_profiles/CVC_LG_SVA_profile.pdf) we were discussing how complex some of the OVL choices could be and I mentioned ZazzOVL – as the Dutch puts it, it is “jammer” (pronounce it as “yammer”, see: http://forum.wordreference.com/showthread.php?t=359560) that we didn’t have the tool handy to show off the value (during the lab session I mean). So make no mistake – their ZazzOVL is very very handy indeed – if you are adding OVLs that’s.

Coming back to their offerings – Bird-dog is a very interesting approach, very much for those assertion enthusiasts who look for “where is the maximum ROI of adding assertions”. Their Visual-SVA is like a “temporal GUI/editor” for complex SVA coding, not my personal cup-of-tea, but I do see value for some there. However generating “traces” for assertions within Visual-SVA is certainly a good attempt. Let’s see how they fair in real life usage! Visit Zocalo Tech Booth # 1509

The all new UVM (a la erstwhile OVM)

Sure you have heard of that – UVM, a sincere effort from Accellera to arrive at a “Universal” methodology from those seemingly competing OVM & VMM. Unless you want to risk your company not paying off your DAC bills, you wouldn’t want to miss that UVM booth :-) Honestly – I believe every one is looking forward to that. As the Accellera PR puts it:

Accellera's DAC breakfast, sponsored by Cadence, Mentor and Synopsys, will feature a standards update with an overview of how the Universal Verification Methodology (UVM) standard supports verification tool interoperability and gives IP and EDA users more choices, and a panel on "UVM: Charting the New Territory." This event continues the celebration of Accellera's 10 years of standards excellence.

For the first time, all 3 major vendors “sponsor” one event promoting ONE methodology – a great news indeed for the users. BTW, there is Aldec catching up on the SystemVerilog support with Riviera-Pro product line. Ask them for VMM/OVM/UVM support updates at: http://www.aldec.com/registration/dac

Agnisys's OVM/UVM management kits

A young EDA company based in Noida, India with solid EDA background (Anupam). They have iDesignSpec & iVerifySpec as products - one is for Register automation and another for overall Verification management. The REG automation has been a long awaited/wished for stuff, almost 8 years back we at Intel used Perl+DOC (Table) for something similar - glad to see a much more finished end product now. It can emit VMM-RAL, OVM and soon perhaps the UVM code too.

Sapient-Inc's IC management

Another  young EDA company, according to the founder - Subash, a long time chip designer/manager:

I started Sapient-IC from the pain and frustration of managing IC products. The die size grows, schedule slips, VP yells at everybody. This is what I want address. Analytics for decision makers, comparative analysis for design choices to financial analysis.

Breker’s Trek

A not-so-young EDA company (compared to the likes of NextOp/Zocalo etc.) with some interesting success stories with NVidia, STMicro. Their Trek is certainly a refreshing approach to testcase writing – especially for SoC Verification. See: http://www.cvcblr.com/blog/?p=148 for more details.

RealIntent’s Ascent

So much has been told, written about Linters – yet its adoption has been hampered heavily by the amount of “noise” it creates. Realintent’s Ascent claims to be less on that – and that is their primary seeling point. Not sure how they achieve that – given the natural side-effect of trying “find faults” with any given code.

SpringSoft

Check with them what’s up with their Certess/Certitude – it is an innovative approach for sure – mutation based TB qualification. As much as we have heard locally, there have been success and also some additional “noise”.

Monday, May 24, 2010

NextOp's assertion synthesis and our recent FIFO experience

NextOp's assertion synthesis and our recent FIFO experience

Based on DVCon 2010 paper on SystemVerilog Assertions - 2009 (see www.cvcblr.com --> Publications) we recently got our FIFO model run through NextOp's BugScope tool. It produced some interesting stuff. The main one I liked is

pop |-> full;

This is an eye opener property - as this should never be the case! But BugScope indeed indicated that we are missing this - either as assert or cover. Obviously this is not a good assert, so when we analyzed deep, it turned out to be a "valid coverage" based on the RTL written. Details at:

http://verificationguild.com/modules.php?name=Forums&file=viewtopic&p=18073#18073

So essentially we did have a coverage hole - when that hole is analyzed, we get a design error/bug! What an interesting go-around way of detecting bugs - who cares, as long the bug detection is automatic, it is good!

Ajeetha,

http://www.cvcblr.com/blog/?p=163

Monday, May 17, 2010

Welcome the next generation Verification Methodology – UVM

For all those System Verilog geeks, lovers, followers here is a sigh of BIG relief – at last we have a UNIVERSAL Verification Methodology that all the 3 major EDA vendors would openly support (and hopefully promote as well). As we speak, UVM-EA (Early Adaptor) release is now available. Take a look at it from Accellera site.

CVC (www.cvcblr.com) has been constantly following this release and are about to release our fresh trainings on this UVM. After all it is based on OVM 2.0.* on which we had successful trainings delivered to several customers locally. The most recent one just over the last weekend! (Yeah, we do have weekend classes as well).

So, what are you waiting for? Go ahead and ask for our upcoming UVM class via training@cvcblr.com or call us via +91-9620209226

Talk to you soon on UVM!

CVC Team

www.cvcblr.com

Saturday, April 24, 2010

A glimpse of our DVAudit – what goes on @CVC’s TDG

Many have asked us the following:

  • Is CVC a training company? I see: www.cvcblr.com/trainings
  • Do you work on “live” projects?
  • What is your TDG really doing?

and more. Usually these questions are more from students/RCGs (Recent College Graduates) than the experienced lot – as the experienced lot is well networked with CVC founders (www.linkedin.com/in/svenka3, www.linkedin.com/in/ajeetha) and can hence know about us well.

Our honest answer to such questions is “all of the above” :-) That’s YES, we ARE proud to be a training company www.cvcblr.com/trainings – simply b’cos we know why we are doing that. We work on “live” projects – we constantly upgrade to next generation technology, the most recent being the SystemVerilog VMM/OVM, Low power etc.

What makes us really different and keeps us constantly innovating is the thirst for “doing better”. This is the core of our PDG – Product Division Group (yet to be formally announced on our website), we look for ways to enhance the productivity. For instance when there is a customer deliverable for a Verification code, “Team CVC” spends quality time together to do thorough reviews, code walk through, custom lints etc. Here is our latest, weekend edition on un-moderated, live-from-the board glimpse of our DVAudit review done on a customer deliverable.

DVAudit

 

For the experienced lot reading this entry (BTW, thanks for getting so far :-)), this is such a common part of your tech-life. For those uninitiated, this is how industry works - “writing piece of code” is just A part – there is lot more to it in making it customer ready/production ready.

Now what’s innovative about the above “glimpse” – if you read it carefully you can observe that we are creating a thorough check-list of “executable” process for Design-Verification Audit. It is something CVC has been doing it for its corporate customers behind the scene for many years. Now it is slowly taking shape as part of our PDG – stay tuned for more..

Wednesday, March 17, 2010

A modern approach to SoC level verification

 

           Verifying SoC is fun and tedious. Especially with several buzz words around the corner, it is quite easy to get lost in maze of buzz-words and miss the goal. At the end one may feel that the plain old wisdom of whiteboard based testcase review/plan is/was lot more controllable & observable. We did that back in 2000 @ Realchip communications and yes it worked really well. But with shrinking times and mounting complexity is that really fast enough? Before I hear constrained-random, blink for a while – how much random do you want your end-to-end data flow in-and-out of ASIC/SoC to be?

We at CVC (www.cvcblr.com) take pride in partnering with all major EDA vendors (http://www.cvcblr.com/partners) – big & small to look for best possible solution for different problems than suggesting “one-size-fit-all” like solution.

Here is a relevant thread @Vguild: http://www.verificationguild.com/modules.php?name=Forums&file=viewtopic&p=17615#17615

I am due to start work on an ASIC, and am wondering about a suitable verification strategy. The ASIC consists of a data path, with continuous data input from ADCs and continuous output to DACs, and a couple of embedded processors utilising external flash and SRAM.

So the interfaces to the ASIC are pretty much:
(1) parallel data bus in
(2) parallel data bus out
(3) external memory interface for CPUs

And here is our own experience/view of some emerging approach to this problem – we don’t claim to have solved it completely, but seem to be making good progress towards a methodical and controllable (yet scalable) manner.

 

Hi Siskin,
Good question/topic. While the value of OVM/VMM is very profound at block levels, their usage at SoC level wherein end-to-end data flow is being checked is not very well reported (yet) in literature. Needless to say they are far better than inventing your own. Especially if you have block-to-system reuse of these VIP components they definitely come very handy. The virtual sequences/multi-stream scenarios do assist but IMHO they come with heavy workouts. Instead what we promote to our customers here and have been proto-typing with at CVC is the solution from Breker, it is called Trek. It can work on top of any existing TB - Verilog/VHDL/TCL/VMM/OVM you name it.
Idea is to reuse the block level components to do what they do best and build tests at a higher level - in this case using graphs, nodes etc. I tend to like this as I used to like Petri nets during my post-graduation days (though didn't followup on my interest afterwards).
My first impression was to use Trek simply as a testcase creation engine but slowly I'm getting convinced it is useful as "checker" as well - especially the end-to-end checks.
You are absolutely right - use assertions in IP interface levels and use some sort of higher level stimulus. Where I see Trek useful in SoC verification is the ability to describe your "flow of data through SoC" as a graph and let the tool generate tests for you. I even jokingly say one can use a palmtop/PDA to draw these graphs during travel, convert them to Trek graph (somehow, didn't chase that dream yet) and have tests ready while I'm on travel - flight/train/bus whatever be it! On a serious note, this is quite similar to how we used to discuss our testplans on a whiteboard during our Realchip (a communication startup in 2000-2001) days, now becoming "executable" Smile
See ST's usage of Trek @
http://www10.edacafe.com/nbc/articles/view_article.php?articleid=787856
Feel free to contact me offline if you need further assistance on Trek. We have our 2nd successful project finishing on using Trek, though these are small/medium scale ones.
My 2 cents!
Srini
www.cvcblr.com
_________________
Srinivasan Venkataramanan
Chief Technology Officer, CVC www.cvcblr.com
A Pragmatic Approach to VMM Adoption
SystemVerilog Assertions Handbook
Using PSL/SUGAR 2nd Edition.
Contributor: The functional verification of electronic systems

Saturday, March 13, 2010

NextOp’s Assertion Synthesis – expanding ABV applications?

 

In case you missed it, read a user report on NextOp’s technology at: http://www.deepchip.com/items/0484-01.html 

In next couple of blog entries, I will share my reading, reflections on this detailed report.

To start with, this technology seems to address some of the “points to ponder” being discussed at: http://www.cvcblr.com/blog/?p=146 

As there is no whitepaper/material available on this technology I base my reflections solely on the ESNUG report. First thing that strikes me is, it seems to suggest in identifying “what assertions to write”. But then it takes a radically different approach to this problem atleast from what has been attempted so far by other EDA vendors. The single most difference is it takes the RTL + Testbench as guide to create assertions/properties. From the report:

 BugScope
takes in our RTL design and testbench as inputs and generates properties,
(which we then categorize as assertions or coverages) that help identify
bugs and coverage holes during simulation. In contrast, Mentor's 0-in
assertion synthesis does not use our testbench;



This is certainly new idea, though I’m little sceptical about the value of late-in-the-cycle assertions.



The next interetsing inference I have on this report is the “coverage property” generation:



When we began our BugScope eval, we only cared about assertion properties
it generated -- we didn't initially see any value of BugScope's coverage
properties.


From what I read in that report, its USP seems to be the “coverage holes” that it can identify. In which case it may be adding more work for the whole project than reducing it – true it helps with better quality, but folks like nuSym will go crazy to have more to cover, but again it is too early to comment in detail. The example given in that report looks little strange as that case maybe due to insufficient run-time of testcase, weak random generation, over-constrained stimulus etc. Also nowadays with RAL (VMM-RAL, www.vmmcentral.org) like automation, all registers can be captured in more controlled fashion from spec. So atleast I fail to see value with the example provided in the report. But since the user says he is using it in production for 2 years or so, there must be credit to this “niche technology”.



Perhaps NextOp is expanding the traditional ABV applications to include “verification closure requirements” by identifying what is not covered yet. That will be interesting application of ABV!



More on this report later.

ABV – points to ponder on its slow adoption

Efforts have been ongoing to make ABV (Assertion Based Verification) more and more deployed for several years via OVL, PSL, SVA etc. Though the concept of assertions is not really new to the industry, widespread usage of it has not been as much as it was expected atleast by the EDA vendors, promoters (to which I consider CVC www.cvcblr,com included).

Prior to PSL/SVA days, 0-in came up with idea of assertion identification, checker library etc. It did catch up with early adaptors but suffered from proprietary solution and inherent limitations of any auto-generated code. This was followed by other EDA vendors developing “auto-generated assertions” for designs – there was some good traction for few quarters and then the initial enthusiasm faded away as the SNR (Signal-to-Noise-Ration) was way too much perhaps.

The development of OVL and other vendor specific assertion libraries looked promising, but IMHO this was not marketed well enough. Also they all fell short of good old 0-in checker elements when it comes to ease of use, verbosity etc. We dealt on this very topic in good detail in our rceent SVA handbook 2nd edition (www.systemverilog.us/sva_info.html) and also touched upon this in our DVCOn 2010 paper (See www.cvcblr.com for downloads page, code, paper + slides are available on request).

  As we at CVC have been walking through these developments in the industry we continue to have debate on what is preventing it from being more widely used. We have several items identified, a non-exhaustive list is below:

  • Who will add these tiny little monsters to start with? Is it RTL designers or Verification engineers?
    • The answer seems to be both.
  • There is a myth that RTL folks don’t want to learn new language – be it SVA/PSL etc.
    • I call it a myth b’cos atleast in this part of the world, the young engineers are always open to new languages, technologies to keep them ahead in technology and beat recession!
    • True, the full PSL/SVA is more than what average RTL guy can consume – but then the kind of properties that RTL folks would write are also simple and don’t require full language capabilities.
    • We at CVC have carefully extracted what RTL designers would require to become productive with ABV – we offer it as 1-day (or even half-a-day if really needed) workshop on “ABV for RTL designers”, see: www.cvcblr.com/trainings or contact us via training@cvcblr.com for details
  • The checker libraries are very handy for RTL folks, but as I said earlier many are not even aware of its potentials. Need more marketing..
    • Some complain about the verbosity especially those who have used 0-in or OVA (inlined) in the past (See AMD’s presentation to Accellera OVL-TC www.accellera.org few years back)
      • Recently released SVA-2009 LRM does address this well with inherited clocks, default clock etc. See www.systemverilog.us for more
      • Also look at checker..endchecker construct in SVA-2009
    • Many users may indeed benefit from a simple “drag-n-drop” style such as the one being developed by ZazzOVL (www.zocalo-tech.com) We at CVC have done initial eval and results look very promising. True, they have some way to go before satisfying every possible user, but good first step I must say!
  • In My design, what assertions can I add?
    • This seems to be much more prevelant question than the myth I mention earlier. There is good element of truth in this concern – only with experience does one get to “identify” quality assertions.
    • There are tools emerging in this space such as NextOp’s Assertion synthesis @:http://www.deepchip.com/items/0484-01.html and Zocalo’s “Zazz bird dog” (www.zocalo-tech.com)
  • How do I know whether my assertions themselves are correct?
    • See: http://www.cvcblr.com/blog/?p=132 for a lively discussion on this topic with Jasper’s ActiveDesign seemingly addressing this well along with other EDA vendors too.
    • Also tools like VCS, Verdi etc. allow assertion evaluation based on a given DUMP file – say VPD, FSDB etc. This is yet another useful feature that’s least marketed – if any. Do look in the tool doc or contact your vendor for more on this, or send us an email via: info@cvcblr.com for more on this.
  • How do I know my assertions really fired?
  • How many assertions are enough for my design?
    • Excellent/Best question perhaps, so NO ANSWER :-)
    • More pragmatically though, there is some research going on at IIT-Kharagpur on this topic, see: http://www.smdp.iitkgp.ernet.in/publications.htm
    • 0-in addressed this with MSD – Minimum Sequential Distance, look in their doc for more
    • VCS adds a stats on “assertion density” – some indications atleast
    • If you are a Masters graduate or PhD – excellent topic to work on!

Twitter of RTL design – welcome to Behavioral Indexing!

Srinivasan Venkataramanan, CVC Pvt. Ltd. www.cvcblr.com

Ajeetha Kumari, CVC Pvt. Ltd. www.cvcblr.com

If you haven’t heard of Twitter you perhaps are living in an internet vacuum J On a positive note, the reach and impact of SNS (Social Networking Sites) into our internet life is hard to ignore – whether it is Twitter, Facebook, LinkedIn etc. To me, a successful SNS tries to capture “what is in going on in your mind right now”? A similar approach can be applied to RTL design – when a designer makes an assumption about the latency of output or the FIFO size etc., it hardly gets captured in a repeatable, executable format. True, at the end of a design phase documentation is written (usually) that attempts to capture these. However it gets too late by then to be “active comments”.

From a language perspective SystemVerilog allows assertions & functional coverage (covergroup) inline with RTL code that can help to some extent. However they are only the “specification” part. A lot more “information” gets lost during such translation such as

· “show me a proof/witness/waveform” for such an occurrence

· Can we optimize the latency to say 5

· What-if I change the FIFO size to 32 here etc.

Jasper’s recently announced ActiveDesign technology has a significant component for this “design process”. It is called “Behavioral Indexing”, you “index” the behavior with facts, assumptions, traces, bugs etc. all in a comprehensive database along with your RTL. So when a designer (or another designer who inherits, reviews the code) looks at the code again (via the ActiveDesign database of-course) he/she can get not only the assumptions (that would be similar to SVA) but also real traces, potential issues of changes to FIFO size etc. In a generic sense the indexing captures the designers state of mind “at that point in time” as a snapshot and keeps it reproducible throughout the lifetime of the RTL code! A good thinking indeed, this is why I like to call it the “Twitter of RTL design”.

There is more to Behavioral Indexing than this, will talk about it next time around, so stay tuned!

Wednesday, March 10, 2010

Introducing “totally vacuous” assertion attempts

See our interesting Blog post at: http://www.vmmcentral.org/vmartialarts/?p=1130 

On the topic of adding SystemVerilog “bind files” – a new tool that is shaping up can help automate even that part – see ZazzOVL (www.zocalo-tech.com). Though as of now it works only for OVL, technically speaking it is very easy to extend it for user specified assertion libraries/modules/MIPs etc.

Sunday, March 7, 2010

Identifying transactions faster with Verdi

Further to our previous blog entry on Verdi’s advanced Transaction debug features (ref: http://www.cvcblr.com/blog/?p=130 ), here are some more tricks that can help debug automation even further.

 

Very often designers find that there are certain unique characteristics/attributes that differentiate transactions. For instance Transaction kind being ERROR/SPLIT/RETRY etc. Wouldn’t it be nice if on a 50,000 clock cycle simulation dump one can:

  • Quickly identify the “information” from “raw data” of signal toggles? (see: http://www.cvcblr.com/blog/?p=130)
  • On top of previous item, classify the transactions based on user specified “attributes/fields” such as ERROR/SPLIT/RETRY

This is very handy trick with Verdi. Select Message –> Filter/Colorify as in screenshot below:

 

verdi_how_2_color

 

Once you are there, define the attributes in the dialog/pane as shown below:

verdi_how_2_color_2

 

Voila! You get:

verdi_colour

 

Add with the signals involved:

verdi_colour_show

 

Now, that’s true “debug automation” and “raising debug abstraction level” in pragmatic sense!

Tuesday, March 2, 2010

Smart application of vmm_log::disable_types()

Srinivasan Venkataramanan, CVC Pvt. Ltd.

Ever wonder why typical SystemVerilog base classes are bulky and seem to make life complicated against simple things like $display? The devil lies in detail – true simple $display is the easiest to use, but think about the code you are writing to have longer life and reuse – then you slowly start realizing the need. Sometimes you need to get bitten by the downside of not using amethodology to start appreciating the need for methodology.

See: http://www.vmmcentral.org/vmartialarts/?p=1098 for a smart usage of vmm_log::disable_types() method. Many folks have asked me why the VMM_LOG is so bloated (in their view), the above is just a sample, see more @ http://www.vmmcentral.org/vmartialarts/?p=259

Monday, March 1, 2010

Look ma “No RTL, TB, only PSL/SVA – yet I can validate my spec”

It is one of those most commonly asked questions in any assertions training/engagement – assertions describe design behavior, but how can I validate my assertions even before my RTL and/or TB is ready? This is useful for few reasons:

1. Users new to writing assertions using PSL/SVA are expected to make mistakes in assertions initially. So it will be good to get some quick waveforms and validate the assertions in stand alone fashion.

2. While the spec is vague, it creates a mechanism to develop/solidify the spec itself

Typically during the advanced sequences/SEREs section of our PSL (http://www.cvcblr.com/trng_profiles/CVC_LG_PSL_profile.pdf) trainings or SystemVerilog Assertions trainings (http://www.cvcblr.com/trng_profiles/CVC_LG_SVA_profile.pdf) this question invariably comes up.

In principle this is a sweet spot for formal tools (Model checkers) – though not all of them openly promote this nice “hidden gem”. I had first hand experience of doing it via some scripts inside Synopsys not too long ago. But not every user is made aware of this “non-productized” feature.

 

Here is what Jasper had to say on this:

The idea you have mentioned about visualizing assertions in SVA/PSL without DUT/TB has been around within Jasper, for a long while. At that time, one of our customers is trying to train more people within their company to write PSL, and many of the engineers found it easy to write "incorrect PSL", and would like us to provide a tool to help them understand whether the PSL they have written captures the intended behaviors.

I also heard atleast one another EDA vendor confirming its tool being able to easily do this. I will add that name if I get clearance :-)

So as my co-author Ben Cohen (www.systemverilog.us) always insists – YES one can (and perhaps should, for a class of designs/specs) use assertions in SystemVerilog (SVA) and/or PSL during the micro-architecture specification stage itself.

Welcome to the new world of possibilities – true this capability has been around for few years, but I haven’t seen many fully exploiting it yet.

 

Friday, February 26, 2010

Transaction Level Debug with SystemVerilog/VMM and Verdi

In our regular SystemVerilog, VMM trainings (www.cvcblr.com/trainings) we demonstrate the power of callbacks to go beyond the obvious usage – specifically a case study to demonstrate transaction level debug. While this topic has been around for very long time (IIRC, Cadence/DAI first provided it via SignalScan), its real application in day-to-day debug has not been as popular as it should probably be.

Some reasons for the slow progress in debug are due to the tool limitations, some due to user unawareness etc. Today we had this session again at CVC and users really liked it a lot. We decided to open up this stuff as there is more interest and share it with larger community.

We also got Verdi (tm) working on this design with simple addition of $fsdbLog – one doesn’t require extra virtual-interface anymore! Hurray! The Debug champion has once again provided a very useful feature for SystemVerilog, class based environments to be debugged effectively. See some of the screenshots below. A much more lively demo can be seen at:

http://www.slideshare.net/svenka3/transaction-level-debug-with-systemverilog-vmm-verdi

Add simple code for  $fsdbLog – similar syntax as $display:

image

Start seeing transactions in Waveform (FSDB)

image

 

Verdi also presents a transaction browser in TEXTUAL form as shown below:

image

But to be honest – one needs to see the demo with action, try:

http://www.slideshare.net/svenka3/transaction-level-debug-with-systemverilog-vmm-verdi 

for a PPS style. I’m also uploading a Video capture soon. Hopefully it goes through, then it will be lot more fun. If you wish to see it live on your designs, call us via info@cvcblr.com or www.cvcblr.com

Thursday, February 25, 2010

Potential research areas on ABV – for a Masters thesis

As part of our BUDS internship program (http://www.cvcblr.com/downloads/BUDs_CVC_Acad.pdf) we work with some of the leading edge educational institutions in India (and one in the USA, BTW). One of our current inters is working on Assertions Based Verification using OVL. In less than a month he has picked up so much so that he says he has learnt more than what he had done (practically) in last semester – it is about that self satisfaction that we consider as our success.

During a recent review at his college, his guide, a very respectable professor in this domain (He is the DEAN of M.Tech VLSI there) has given a very constructive criticism saying:

OVL is fine, but can you add some research work beyond what is obvious/common use to your thesis?

We at CVC felt very happy about that comment – as it reflects on the reviewer’s thirst for highest standards and research inclination and keep us more motivated to go beyond the obvious. So we than him greatly for his inputs via this blog.

Today during a review session we agreed on some of the research topics in this domain, feel free to add anymore if you come across. Even if the present intern can’t take all, a future one can build on this work!

  1. Assertion Density –> How many assertions are enough for my design? Look for some research work @ IIT-KGP (http://www.smdp.iitkgp.ernet.in/publications.htm). Also tools like 0-in, VCS etc. present some code level metrics to assist in this space. But more needs to be done. Say assign a “weight” to each OVL element, classify them as per their complexity etc.
  2. Clock Domain Crossing (CDC) Verification using Assertions
  3. Low Power Verification using Assertions
  4. Assertion candidate identification on a given RTL – such as the emerging Zazz bird dog (tm)  (http://zocalo-tech.com/products.php)
  5. Assertion Visualization without any TB/RTL. A seemingly close to it technology is available from Jasper (www.jasper-da.com) via their recently announced ActiveDesign (tm) product.

I encourage others to add more topics as comments to this entry so that the academia can focus on next generation challenges!

Why CVC’s trainings are so special

As in any business, there are always lead players and those who try to “mimic” them. We see our trainings also the same way – let’s admit there are few players in this game in our region. However what sets us apart from the rest? Few:

1. First of all we serve the whole industry at large:

Such a wide coverage of audience is very rare if any, even across globe. Again note that many may promise, it is important to deliver and that too with passion and from real experts, who can be named, identified than those typical “interact with industry experts” kind of statements!

As one of our testimonials (http://www.cvcblr.com/testimonials) go:

"...have been practicing for many years just what they teach now. A giant step in the right direction to introduce a quality VLSI design and verification in India!"

Sunil Kakkar, Chief Architect - SKAK INC.

2. We believe in what we do – yes we do NOT cover the whole VLSI flow – every wonder why? Espeically given that other training institutes here do claim that as a BIG deal? Recently an Aldec engineer (Purushottham) here said this:

I wonder why anyone would want to “specialize” on the whole VLSI flow, a typical ASIC/VLSI engineer works for several years on a specific role – either front-end or back-end, and not on both.

At CVC, our belief is that we should create employable talent pool than just some diploma, certificate holders. We infact receive several such resumes for our TDG division from other institutes, recently we had one – someone who is teaching Verilog at an institute, when asked to write some code and add “comments” used “ \\ Verilog comment “. Nothing against any specific individual or org, but just to reflect the state of what we saw.

Indeed I’m grateful to such experiences – that made us to realize the need for our EIC – an incubation center than just a training institute.

It is our genuine interest to place all our trainees – be it freshers or experienced ones – either through our industry contacts/existing customers or internally for our consulting projects. But we have very high levels of quality requirements to be placed – right from code indentation, linting, synthesis to verification. Unless the design, coding, tool usage everything measures upto our quality standards we just can’t hire folks into our TDG – we make that explicit every time we get a chance and NOT at the end alone!

So – to summarize, we BELIEVE in what we do, so if you are looking for a successful career and are willing to put in sincere efforts on your own, come and contact us training@cvcblr.com

 

Thanks for reading!

www.cvcblr.com/blog

Monday, February 22, 2010

Early validation of RTL – with no Testbench!

 

Srinivasan Venkataramanan, CVC Pvt. Ltd.

Looks like Jasper DA (www.jasper-da.com) is on a mission to drive simulation a pass√© J On a more serious note, their recently announced ActiveDesign (TM) technology sounds pretty interesting for early RTL validation. Before I hear that “Aha..that’s my favourite LINTing”, hold on.. this is much more than that – one can see real waveforms– no testbench is ready yet, but the tool can create quality waveforms for you!

Sounds too good to be true, well their demo indeed shows a very representative real life design – AHB-lite to AXI bridge with 4 AHB-lite masters.

clip_image002

I had a chat with the ActiveDesign team recently to understand what goes “behind-the-scene” (Norris Ip, Holly Stump & Saptarshi all from Jasper). My main doubt on this “early RTL validation” was whether it can work for custom protocols and whether user needs to provide some assertions to get this working. These questions are relevant because we at CVC have prototyped similar stuff for standard protocols via our SVA/PSL based MIPs (Monitor IPs) and some commercially available tool features from other EDA vendors – it involves few hacks and scripting, but doable – if put in some hard work. It requires either an advanced SVA/PSL aware simulator or a model checker/formal tool.

Coming back to Jasper, the short & sweet answer is:

“No, user doesn’t have to create any assertions for getting this. The tool analyzes the RTL code and , based on a few user-interactions with the GUI, waveforms are created". And yes it does work for any design not just for standard protocols” As a side note the tool can create SVA code for the “behaviors/recipes” – more on it later.

The technology is built around Jasper’s popular and proven Visualize (TM) and recently announced “Behavioral Indexing (TM)”. More on the “behavioral indexing” in one of my next entries.

For now, if you are developing a fresh RTL and want to validate it without having to wait for RTL to finish, TB to be ready etc. look at ActiveDesign. Of-course I also highly recommend running LINT before you do that, though Jasper doesn’t have that in this platform. You may want to try some of the new linters such as Aldec’s ALINT, see: http://www.cvcblr.com/blog/?p=99 for a fresh look at Linters.

Sunday, February 21, 2010

Signs of maturity in EDA tool built-in examples

During a recent look at ActiveDesign product from Jasper (http://www.jasper-da.com/products/ActiveDesign.htm), I was pleasantly surprised to see a high quality design being used as the case study. Usually such early product demos contain tightly canned examples, showing only the relevant tool features and much less on the actual design. Here is a refresher – we get a very representative real life design – AHB-lite to AXI bridge with 4 AHB-lite masters, a refreshing change in EDA space.

See below for a screenshot of the demo design:

AHB-lite-to-AXI

Tool demos are not on dummy designs, becoming more and more realistic indeed!

On a similar note, Breker’s Trek (www.brekersystems.com) has $TREK_HOME/examples that are complete SoC level test synthesis – not just “Hello World”, “foo-bar” anymore! Other interesting designs include a Cache controller model, CPU etc.

Similar is the SoC kit initiative from Cadence (www.cadence.com/products/fv/iv_kit) – this one tops the list of all EDA demos I’ve seen in years on Verification – they started back in late 2007 and have been growing in strength over years. During CDNLive 09 @ Bangalore, CDN showed their roadmap for these kits and clear indications are that these will be extended to ESL platforms too.

Sure all vendors ship more and more examples with their tools nowadays, this also means they employ/engage with real verification engineers besides R&D, support engineers, good for the job market, hopefully :-)

Sunday, February 7, 2010

Debug SystemVerilog macros with VCS-DVE

Srinivasan Venkataramanan, CVC Pvt. Ltd.

Rashmi Talanki, Sasken

John Paul Hirudayasamy, Synopsys

An extract from a little lengthier post @ http://www.vmmcentral.org/vmartialarts/?p=922 – focus here only on Debug side on this post:

One of the powerful features of SystemVerilog is the ability to create TEXT macros (those `define s) with arguments – they can create fairly complex code in jiffy. Take a look at VMM source code if you need examples.

In a recent customer engagement, we had to dig deep into VMM atomic Generator code that gets created by the one liner macros!

During the coding work, the customer opened up vmm.sv and got trapped in the multitude of `define vmm_atomic_gen_* macros with all those nice looking “ \ “ at the end – thanks to SV’s style of creating macros with arguments. Though powerful, it is not the easiest one to read and decipher – again for a first time SV/VMM user.

Now comes the rescue in terms of well proven DVE – the VCS’s robust GUI front end. Its macro expansion feature that works as cleanly as it can get is at times hard to locate. But with our toolsmiths ready for assistance at CVC, it took hardly a few clicks to reveal the magic behind the `vmm_atomic_gen(icu_xfer). Here is a first look at the atomic gen code inside DVE.

clip_image002

Once the desired text macro is selected, DVE has a “CSM – Context Sensitive Menu” to expand the macro with arguments. It is “Show √† Macro”, as seen below in the screenshot.

clip_image004

With a quick bang go on DVE – the Macros expander popped up revealing the nicely expanded, with all class name argument substituted source code for the actual atomic_generator that gets created by the one liner macro. Along with clearly visible were the facade class name and the actual callback task with clear argument list (something that’s not obvious by looking at standard vmm.sv).

clip_image006

Now, what’s more – in DVE, you can bind such “nice feature” to a convenient hot-key if you like (say if you intend to use this feature often). Here is the trick:

Add the following to your $HOME/.synopsys_dve_usersetup.tcl

gui_set_hotkey -menu "Scope->Show->Macro" -hot_key "F6"

Now when you select a macro and type “F6” – the macro expands, no rocket science, but a cool convenient feature indeed!

The DVE’s macro expansion feature that makes debugging a real fun!

Wednesday, January 20, 2010

Renewed interest/investment in code linting! Good for the industry

As some of us have seen over last decade, approximately 5 years ago industry was upbeat about code/RTL linting with almost every EDA vendor offering products in this space. Some of them were start-ups acquired by big vendors (like LEDA.fr to Synopsys). At the end the Linting market proved too small for the 3 biggies and their focus on that technology got sidelined. In all, one company survived this wave well and that’s Atrenta – its SpyGlass product increased leaps and bounds both in its capabilities and installed base. Today SpyGlass is an undisputed leader in Linting and has enjoyed monopoly for more than 5 years, well done Atrenta!

Come recession, silently few smaller EDA vendors started investing on this niche segment and now we have ALINT from Aldec and Ascent from RealIntent. I’m personally thrilled to see more players on this technology – though the $$ may not be too high, the potential user base is large and investment is not all that HIGH as in a SystemVerilog simulator for instance.

From a user view though, Linting is a must have step in flow as recognized by experts like Adam Kronlik in a book: Functional Verification of Electronic Systems, Chapter 8 HDL Lint: http://www.iec.org/pubs/pub.asp?pid=13&bsi=3&cat=cont 

(BTW, I have a chapter on the same book, Chapter 14).

Few notes on 2 modern linters here:

Ascent from RealIntent: (http://www.realintent.com/real-intent-products/ascent).

One of the traditional challenges of a Linter has been the “heavy noise” it creates. Recent Linters *claim* to do better there – especially Ascent.

Other interesting features in this linter are:

  • Opportunities to improve simulation performance
  • Operations with hidden or expensive implementation costs

True, your mileage may vary, but good thoughts indeed!

As we read more on the Datasheet of Ascent one gets a feeling that it combines a traditional Modelchecker inside it as well – as their PBV & ABV features talk about. I’m not sure if that’s a good thing from a pricing standpoint as the linters are usually far cheaper than model checkers. But a good try by RealIntent indeed!

 

ALINT from Aldec (www.aldec.com)

Fairly young in the market (~2 years??), it has solid STARC policy inside it. What really interests me in this is their full blown API for user defined checks – yes every other vendor claims/has it in some manner, but I have not seen this level of detailed support and even better – their flexibility and response time in enhancing the API as needed.

It will be interesting to see how they survive over say next 5 years! Maybe it signals some impact to the erstwhile King of Linting – SpyGlass!

Sunday, January 17, 2010

SystemVerilog Interfaces – learn more about it for free! Register Now for this Webinar

CVC is pleased to announce online Webinar on "SystemVerilog Interfaces" along with Aldec as our partner. With ever growing interest in the true power of SystemVerilog here is your opportunity to get started with SystemVerilog in good style with no additional cost - it is a FREE Webinar and is scheduled in 3 different times to suit various timezones across the globe - ASIA, Europe & USA.Register online NOW to book your seat!

ASIA - India 9.30-10.30 AM,China: 12.00 to 13.00

Europe - 15.00 to 16.00 CET

USA - 9.00 - 10.00 AM, PST

Click here for an abstract of the Webinar. It will be presented by Srinivasan Venkataramanan from CVC and Jaroslaw K, from Aldec.