Mentor’s User-2-User conf is nearing – have your Qs answered through John Cooley!

If you haven’t registered yet, goto:

http://user2user.mentor.com/bangalore-india-2010.html 

With Wally Rhines speaking, you can’t afford to miss his power-packed keyonte. Also this year there is Mr. John Colley of www.deepchip.com presenting a session. Known for his open, user-focused comments on various tools, technologies & vendors (sometimes creating controversies too) this is one session that’s worth beating Bangalore traffic to be there!

BTW, John is also looking for good survey questions focused on Indian audience and issues concerning Indian users of Mentor tools. So do send them across via www.deepchip.com 

See you there at Mentor’s U2U on Dec 10th. Look for TeamCVC (www.cvcblr.com) in the crowd and we can chat!

TeamCVC,

www.cvcblr.com/blog

Increased user momentum at CDNLive India

Quick summary of what I liked at recent CDNLive India. Read live tweets @ www.twitter.com/cvcblr

First of all, the venue is FRESH – ITC Royal Gardenia hotel, a welcome change from regular Leela/Taj :-) Second, the first few sessions were JAM-packed with more than 25 customers standing (with all seats occupied). This was surprising as the audience beta the Bangalore traffic to be there at around 9.30 AM.

On the technical front, well let’s focus on what we know best – Front-end Design & Verification. Frankly – I was not alone who got totally confused about which “Verification” track to choose from. There was this

• “FED + Verification track”
• System Design & Verification track

I first though it was the FED that I should be in, as it contained one of my much awaited Nokia paper on Formal/ABV/IFV usage. But my good friend @CDN Maruthi Srinivas helped with clarification. His explanation:

First of all sorry for confusion, this year we had so many good papers on Verification and we had to fit as many as we can. We decided to move some of the Formal/ABV papers to FED track. The core Verification papers are on the Track-V

Now being @ the common session, John Bruggeman did an excellent job with his EDA360 talk. With so much being tweeted about it, honestly I got little saturated prior to his talk. But his talk truly rejuvenated the topic and his expressive demo revealed the vision well inside 3 slides. Kudos JohnB!

Next to see was TomAnderson’s Verification roadmap – strangely this was presented at Track-IV/FED. Luckily I was there in that track and as ever before, Cadence’s vision was great – especially linking the Conformal LP and Functional Verification/MDV is very thought provoking. The “Advanced Specman” was known to us at CVC http://www.cvcblr.com/blog/?p=173, but for many it was new there. And with similar capabilities being explored for SystemVerilog in the roadmap, there was enough for everyone to cheer about!

On the technical papers – a noted aspect that almost every attendee shared is – the quality and depth of these papers this time around was amazing. Be it the DFT Verif paper from TI (90 % of DFT logic bugs were caught by IFV flow), the TLM-e paper from ST-Micro and/or the Arch Model Verif with Specman by TI.

I personally enjoyed the Freescale paper on “Corner Case analysis with Formal”, to avoid repeating it, read more about it at: http://www.cvcblr.com/blog/?p=215 

Nokia’s Modem IP Verif paper was one of the best presented ones IMHO and Manish Goel did an excellent & upto-the point job of staying on target. There were enough audience questions in his session than many others and even another presenter from TI (He got the best paper award, didn’t get his name though) shared some of his views during those interactive discussions. This I felt was true “customer-2-customer” interaction happening live before a full room audience – something that the CDNLive team can be very happy about.

One of the best audience Q was raised during an Assertion paper (guess the TI one):

• “While IFV sounds great, user still needs to write those white-box assertions, is there any automation available”?

Though the presenter didn’t use this specific feature, the CDN rep/AE was quick to note that indeed IFV has the ability to extract certain classes of properties from RTL.

..and for those looking for more quality assertions, explore the partner technology of BugScope from NextOp: www.nextopsoftware.com

Realities of IP reuse, from Verification perspective

IP reuse, RTL/Design IP-reuse to be precise has been in effect for over a decade now, thanks to the time-tested RMM book, http://amzn.to/bI04yK and the extensive support of those rules/guidelines/policies by Lint tools such as SpyGlass, ALINT (from www.aldec.com), and recently Ascent (from www.realintent.com).

However while talking to a customer recently on their Printer SoC verification challenges, some interesting facts/stats emerged:

• Yes we reuse IPs, they are Si-proven, but…

New SoCs use these IPs in very different context leading to:

• Different configurations that were never used/tested/verified before
• Order of configuring these IPs can make-or-break the systems

The “ordering” was more interesting and in recently concluded CDNLive India, Deeapk from Freescale Noida presented an excellent paper on: “Corner Case Verification with IFV and assertions”. While much has been blogged about the recently concluded event CDNLive, this paper didn’t get enough mention – atleast not as much as it deserves IMHO. Deepak had 3 excellent case studies:

1. Order in which IPs get configured can make-or-break the SoC. Traditional Code cov can not locate it. His team wrote those assertions manually and used IFV to verify them
2. During Power Shutdwon if there is a pending interrupt to be serviced, after wake-up that interrupt was forgotten – a pretty tall order for traditional code-cov to catch it. True one could write a test – only if you had thought about it!
3. Clock control from PLL and other enables

All these are quality bugs, but hidden in the given module for more than 1 tapeout and used in customer designs. They get exposed only with modern use scenarios and hence is the stress on increased quality, hence the need for IFV.

While Deepak’s team has successfully demo-ed the 3 corner cases, arriving at them was by no means a small task. Also who knows, how many such hidden gems/bugs are out there yet to be caught?

So while IP reuse sounds old, the verification of them is by no means is a done-deal. Great for WE all – those love Verification as it presents a good challenge.

Now just before I close this entry, a quick preview of an emerging technology that is well poised to change this scenario for sure – by generating QUALITY white-box assertions automatically for YOUR designs:

Looking beyond the current tools, emerging technology such as BugScope from NextOp (www.nextopsoftware.com) can greatly assist in identifying such corners from your RTL design and current simulation runs. You just need to see a demo/webinar or read carefully their Whitepaper http://www.nextopsoftware.com/assertion-synthesis-assertion-based-verification-whitepaper.html to explore more.

Leveraging Social Media in VLSI/Semiconductor/EDA – the ecosystem way

As recent EDAC panel discussed the impact of Social Media in VLSI/EDA marketing (see: http://bit.ly/dzd3Ev) it is quite clear that one alone can’t make a difference, no matter how loud you shout – it is the collective ecosystem – of company-customers-partners that can make a win-win case in this new age marketing. Refer to Altera’s slide on that from http://bit.ly/dzd3Ev

Jim @ Altera says that it is the customer-to-customer interaction happening via Social Media that makes the bigger impact.

Given the post-recession ramp-up at many semiconductor houses, teams are very selective in investing/exploring/adopting new technologies and they are all looking for true success stories and real user views than just tool/feature updates.

Now looking at Karen @Synopsys’s views: it is the GEEK-2-Geek connection that she/Synopsys is bullish about to leverage on this new media.

While she quotes SNUG group @ linkedin.com, we found even more interesting stats with Verification specific groups such as VMM, OVM & all new UVM. The interesting fact about VMM linkedIn group is it is created and managed by partner (Ajeetha Kumari, http://www.linkedin.com/in/ajeetha) than the vendor.

VMM: http://www.linkedin.com/groups?home=&gid=147448 with some 780 members,

OVM: http://www.linkedin.com/groups?home=&gid=145498 with 1200+ members:

And the all new UVM: http://www.linkedin.com/groups?home=&gid=3092645 with 250+ members.

What really is important about this UVM group is it truly represents the ecosystem – with members from all EDA Vendors, partners and growing user base. See for yourself from the image below:

 

Another partner promoted group is SystemVerilog for Verification @ http://www.linkedin.com/groups?home=&gid=1924084

Among these groups the number of jobs being discussed truly reflects the close relevance of these to the real engineers out there and it is quite clear that all have enough to benefit from it.

So let’s embrace the new Social Media and look forward to exciting times ahead. If you want to learn more about how companies can benefit from this Social Media, do not miss the latest edition of Entrepreneur  magazine in India http://entrepreneurindia.in/ – it has cover story on Facebook founder.

And here are some of our local enthusiastic bloggers/tweeters – am sure I have missed several, feel free to submit them as comments, I will add them to this ever growing list!

http://www.twitter.com/cvcblr 

http://www.twitter.com/pradeep612

http://www.twitter.com/sricvc 

http://www.twitter.com/am_its 

http://www.twitter.com/testbench_in

http://www.twitter.com/punechips

SystemVerilog Assertions for VHDL

It is becoming more and more popular to find users writing SVA for VHDL too – though the VHDL-2008 has PSL inside it and most of the EDA tools (Aldec, Cadence, Mentor & Synopsys) have good support for PSL-VHDL.

Recently a customer asked:

"The SVA binding port mismatch error only when I bind an VHDL output port to a SVA input port. But, when i bind a Verilog output port to a SVA input port, it compiles without a problem ".

  While it does look like a tool-specific issue, in old VHDL, an output port can’t be read, need a buffer type for the same. When you bind a SVA to a VHDL output port, SVA tries to “read” it.

It is a subtle issue – though many tools have relaxed this “semantic” check on VHDL side. Also VHDL-2008 allows reading of output ports IIRC. Check with your EDA vendor if you see this issue, they ought to be supporting it already!

Cheers

TeamCVC

www.cvcblr.com

Productivity hint for SystemVerilog VMM/OVM/UVM users

Whichever methodology you use for Verification (if you don’t use, better start with UVM maybe) – some of the tasks & requirements are common. One of them is the ability to control certain simulation features across runs without needing to recompile. Classicial examples are:

• Dumping different scopes
• Changing Verbosity (for debug, regression runs etc.)
• Choosing tests
• Stopping after N-number of errors

It is the last one that one of our customers recently had an issue with, here is an extract from his email:

I need clarification regarding "vmm_log:stop_after_n_error".  Want to know
whether there is command line equivalent of the same.
I do not want to edit any of the source file but rather control from the command
line.  Does the language/methodology has in built construct for the same ?

Interestingly an OVM user also asked for it during our recent OVM training (www.cvcblr.com/trainings) at their site. In OVM it is “max_quit_count”. In both cases unfortunately it is not built-in. This means that one needs to add it in source-code – something that we discourage to do. Instead build it using Verilog’s $value$plusargs, code snippet:

if ($value$plusargs("vmm_stop_after_n_errors+%d", err_count)) begin
        log.stop_after_n_errors(err_count)

Guess that gives the idea, let me know if you are still stuck, send me
a working code/example, I will get that turned around quickly.

Regards

TeamCVC

www.cvcblr.com

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

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

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/ ):

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:

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”.

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

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

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.

 

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..

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"
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

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?
  • Good question, look at assertion coverage and more interestingly the methodology note recently added by our team @ VMMCentral (www.vmmcentral.org) on the concept of “totally vacuous” assertions. See: http://www.cvcblr.com/blog/?p=143 for more.
• 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!

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.

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:

 

 

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

 

Voila! You get:

 

Add with the signals involved:

 

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

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

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.

 

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:

Start seeing transactions in Waveform (FSDB)

 

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

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

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:

• Be it a fresh graduate (via our EIC: http://www.cvcblr.com/trng_profiles/CVC_EIC_profile.pdf, http://www.slideshare.net/svenka3/anubhuti-engineering-incubation-centre-eic)
• An experienced, mid-career engineer looking to re-skill, recently SystemVerilog being the runaway success (http://www.cvcblr.com/trng_profiles/CVC_VSV_WK_profile.pdf)
• Engineering managers, marketing execs who want 10,000 foot view of the VLSI ball game
• Sometimes, engineers from other domains (SW, Mechanical – yes we had one!!) willing to learn basics of Verilog.

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

Debug SystemVerilog code the right way with Verdi

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

Sreenath V, CVC Pvt. Ltd. www.cvcblr.com

One of the many challenges in taking over a block developed by others is the quick ability to grasp the big picture fast and then delve deep into some focus areas. Talking of SystemVerilog based Verification code base (say with a base class such as VMM) is even more challenging as many engineers still find it new. During recent reviews at customer sites we often find engineers asking questions like:

1. How do I quickly know the various transactors in my environment? Of-course one can go through UNIX find-grep route, but with modern verification base, there has to be a modern approach to this ever lasting challenge as well.

2. With several macros being used to reduce the verbosity in coding, the reading/deciphering the code by a novice engineers becomes more challenging. If tools don’t address this part, it is possible that the benefits of code shrink by these macros may get quickly lost with the time being spent by a new engineer trying to understand it in detail.

SpringSoft’s Verdi (tm) has solid support for SystemVerilog testbenches with a full fledged Testbench browser, macro expander etc. It also provides a nice transaction debug capabilities, more on that on a separate blog soon.

What is nice about Verdi is the ability to get a quick view of inheritance structure via its Testbench Browser. See below for an example (look at the Green eclipse area). It is very easy to note the transactors derived from a base class such as vmm_xactor.

 

On the second challenge, Verdi makes it very convenient to expand/collapse a macro.

1. Select the macro usage on the source window.

2. Press “Control-m” – expand macro; See below for a screenshot, l

3. The source window now has an expand/collapse icon (+/- symbol) to the left of the macro line.  (Green eclipse below)

4. When you expand, the “behind the scene” code gets colored on w white background quickly making it distinguished from rest of the code. ((Green rectangle below).

 

We recently had a customer asking for all VMM component code expanded, and it was merely a 15 minute job with this tiny little feature to get that done!

Happy debugging!

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.

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.

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:

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 :-)

SystemVerilog covergroup – bins and the value set matching

During our last week Verification with SystemVerilog class (VSV: http://www.cvcblr.com/trng_profiles/CVC_LG_VSV_profile.pdf ), an interesting question popped up during functional coverage session. As user defined bins are created for vectors in SystemVerilog, what if the value set range is not divisible by the specified number of bins (say in a fixed number of bins case)? 

Consider:

[cpp]

bit [4:0] vec_5bits;

covergroup cg;

  cp1 : coverpoint vec_5bits {

    bins four_buckets [4] = {[0:$]};

    bins five_buckets [5] = {[0:$]};

  bins fifty_buckets [50] = {[0:$]};

}

endgroup : cg

[/cpp]

Let’s analyze the above:

four_buckets –> simple, each contains 8 values, uniform

five_buckets –> 5 buckets, first 4 will have 6 values each, 5th bucket will contain all the remaining 8 values:

              [0,1,2,3,4,5], [6,7,8,9,10,11], [12..17], [18..23], [24,25,26,27,28,29,30,31]

fifty_bukcets –> first 32 bins will have 1 value each, remaining 18 shall remain empty!!

Questa prints a nice warning about the last case as below:

VSIM 1> run 990
# ** Warning: (vsim-8546) The number of values specified '32' is less than the size '50' of fixed-size array bin 'fifty_buckets' in Coverpoint 'cp_1' of Covergroup instance '\/top/spram_fcov_1/my_cg_0 '. The '18' empty bins will not contribute towards coverage.

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.

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.

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).

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!

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!

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.