Previous month:
April 2012
Next month:
June 2012

UVM Drivers and Monitors

The UVM User guide recommends that an agent is composed of a driver, monitor, and sequencer (UVM 1.1a User Guide pg 35):

Uvm_users_guide_1.1.pdf (page 43 of 198)-2

But I am frequently amazed to find that there are a large number of verification engineers who insist that creating a monitor is often not useful. These engineers prefer to perform checking based directly on the stimulus generated in a test, sequence, or driver. Why should we waste time creating a monitor, they argue, when we have all the info we need right here in the driver?! 

For the record, you should, under almost every circumstance, create a monitor that can be run in a completely passive fashion when creating an agent for a DUT interface. This is because as your verification effort progresses from block to full chip, you will often want to reuse checkers. And in the full chip, a checker must frequently be passive - it is observing what is going on inside the DUT without having any direct control. If you construct your testbench using checkers based on stimulus, you will eventually have to rewrite those checkers if you hope to use them in a full chip environment. 

You were planning to reuse your checkers... right?

 

-----

Want more info on writing testbench stimulus? Check out this paper on scenarios and sequences from DVCon 2010.

 


Getting the Least Out of Your Verification Effort

It's quite common to read blog posts or industry newsletters giving you tips on how to succeed with your verification efforts. But all of these people are probably trying to sell you something. Don't let them do it! Follow these easy steps and you'll be amazed at how much less stressful your life becomes:

#1 - Wait until you're finished with your testbench before starting random regressions.

We all know that EDA and server vendors are always trying to steal your money by suggesting that you run more random regressions earlier in your verification cycle. Stick it to the man by waiting until your testbench is completely finished before wasting extra CPU cycles on those worthless random regressions. Remember - always hardcode your simulation seed in your run scripts to 1, and bonus points if you simply leave out random constraints so that anyone who foolishly tries to run a regression still sees all passing results. Ha!

Continue reading "Getting the Least Out of Your Verification Effort" »