CVCBLR's VoW blog - Verification on the Web!

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

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

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

Srinivasan Venkataramanan, CVC Pvt. Ltd. Ajeetha Kumari, CVC Pvt. Ltd. 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 dur...

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.

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

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

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