For your reference, course details at:
For your reference, course details at:
ASIC Design-Verification lead (DVL-08-01)
Job code: DVL-08-01
Exp: 4-8 years
Note: there are also individual contributor roles. Summary of skills needed:
- Advanced verification methodologies, preferably SystemVerilog – including testbench development
- (G)DDR2/3 verification experience
- Good problem solving, teamwork
Send CV to email@example.com
As an ASIC Verification engineer at high end semiconductor design house, verify the design and
implementation of the industry’s leading Graphics and Video
Processors. Specific areas include 2D and 3D graphics, mpeg, video,
audio, high-speed IO interfaces and bus protocols, and memory
subsystem design. In this position, you will be responsible for
verification of the ASIC design – architecture and micro-architecture
- and it may include pre-silicon, emulation, and post-silicon
activities. You are expected to understand the design and
implementation, define the verification scope, develop the
verification infrastructure and verify the correctness of the design.
You will be working with architects, designers, pre and post silicon
verification teams to accomplish your tasks.
Exposure to design and verification tools (VCS or equivalent
simulation tools, debug tools like Debussy)
Good debugging and problem solving skills. Scripting knowledge
Expertise in SystemVerilog or similar HVL
C/C++ programming language experience desirable
Experience in architecting test bench environments for unit and system
Experience in verification using random stimulus along with functional
coverage and assertion-based verification methodologies
Good communication skills and ability & desire to work as a team
player are a must
BS / MS with 8+ years of experience
Many have asked us the following:
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 Development 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..
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.
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 @
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!
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
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.
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:
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 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!
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:
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!
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