Thursday, December 27, 2012

I know SystemVerilog, why bother me with UVM?

If you are a verification engineer in ASIC/FPGA domain, chances are very little that you have not heard of SystemVerilog. For the last 6+ years it has been making positive impacts to design and verification teams across digital design space.

Given this fact, this is no surprise there are several young engineers who jumped on to the bandwagon and picked up the language to a certain level. Many successful engineers in this part of the world have taken CVC’s VSV course as a wise step towards the same.

However when it comes to the production use, plain System Verilog falls behind in certain key areas. Make no mistake, it is a powerful language and is becoming even more powerful with the upcoming 2012 update. See our blog for more on those updates: www.cvcblr.com/blog

Many users ask us – why do I need UVM on top of SystemVerilog. While there are ample number of marketing material available on the net for free on this, here is a humble, technical attempt to challenge a solid DV engineer with decent SV skills.

Consider a simple Deserializer design: call it S2P (Serial-2-Parallel converter). It captures the input serial stream from start-to-end and sends out as parallel data at its output every 8 clocks. A typical waveform would look as below:

s2p1

Now, let’s say that you are SV aware to the extent that you can comfortably create a verification environment in say 1 or 2 hours for this simple design.

Now let’s try and do “verification” – add a negative test – i.e. create a scenario in which:

  • There are ser_sop with NO ser_eop in between

See a sample screenshot below:

s2p2

Remember, it is a negative test and hence you are NOT allowed to change any existing code. Can you achieve this in plain SystemVerilog without UVM?

If the answer is simple YES, we would love to hear your solution (add via comments here, below). No, don’t think of tricks like “force/release” etc. Attempt it as a pure SystemVerilog coding exercise.

The reality is – of-course we can, if we architect it upfront with factory and/or callback. That’s kind of what a framework such as UVM does for you. So UVM is nothing but 100% SystemVerilog, but wrapped in with a series of base-classes, built-in features that make your ‘verification” easy.

Join us for our upcoming UVM training session to know more on this challenge.

Bottomline – UVM is made to make your verification task easier, though it achieves it through a myriad of base classes. Luckily, users need to bother with only about half-a-dozen of them or maybe 10. But that’s only if you are educated well on UVM and trained by experts. If not, chances are you will loose yourself in the UVM base-class maze trying to make a decent way-out! Choice is yours!

Technorati Tags: ,,

2 comments:

Unknown said...

Hi,

The above negative scenario we can deal with SV as well. Lets say i will give different IDs to my scenarios. Every packet comes with a ID from my generator to driver. My driver checks the ID before driving any value to the interface. For this particular case do not drive EOP after the SOP for the decided packet based on the ID. This may not be a best way to code but i think we can code this scenario. Plz correct me if i am wrong.

Srinivasan Venkataramanan said...

@Yogita - good to see your approach.

What you perhaps missed one important restriction we had setup:

----
Remember, it is a negative test and hence you are NOT allowed to change any existing code. Can you achieve this in plain SystemVerilog without UVM?
----


Without such restriction this can be done even in pure Verilog (or any procedural language to be fair) - provided we KNEW such a requirement exists in advance. i.e. at the time of writing low level driver_bfm if this was a requirement.

However in Verification the testcase requirements keep evolving much longer than the lower components. Remember the example quoted here is trivial/simple to keep things in context - imagine the number of such corner cases needed for Ethernet/PCIe etc. It is almost impossible to list all such cases BEFORE writing the BFM.

Also many a times one may use VIPs from 3rd parties, in which case your option is ruled out - as you can't edit the bfm code anyway.

This is where OOP concepts like Inheritance & Polymorphism comes very handy. Yes, these are SV features, but how to make use of them in real scenarios such as below is what UVM is all about - recall UVM is 100% SystemVerilog..

Now for those waiting for clues/hints - use uvm_factory

Cheers
Srini
www.cvcblr.com/blog