Home Articles Tips Debug Like The Pro's

Search

Debug Like The Pro's PDF Print E-mail
User Rating: / 0
PoorBest 
Thursday, 24 December 2009 15:56

You’ve developed a verification environment, hooked up the DUT, written a bunch of tests and alas! Simulations start to fail So just before you dive in, Think Verification’s tips department recommends the following:

 

Prepare a Quick Regression Suite: Yeah, you got your fancy random one test does it all test. That’s really wonderful, but more often than not, a set of directed tests, each stimulating a different area of your design may come in handy when you need a status real quick. As a matter of fact, we’ve published an entire article about creating the right mix of directed and random tests.


Print all useful information in a log-friendly style: I’ve seen many kinds of messages that people send out to log files. Some are good, some give useless information and some actually cause confusion. So a certain level of messaging uniformity across the elements of the environment can make a big difference when it comes to analyzing a log file and trying to figure out what the heck had happened there


Always start with one packet: First time you’re running your SVE (Simulation & Verification Environment), a single packet/transaction will usually catch most of the zero-order bugs. In fact, whenever my design or environment undergoes a major change, I go back to the 1-packet test, just to see that everything’s ok.


Save heavy ammo for later: Once again, the principle here is that debug takes time so if you have in advance a sense of what’s supposed to happen in a test, and what the expected behavior should be you’re saving yourself a lot of debug time. So try to enhance the complexity of your test scenarios gradually by releasing constraints as you go one step at a time.


Be creative: tkdiff or equivalent applications are sometimes not less a debug tool than anything else When a test fails unexpectedly you might want to try diffing your current file version with the last good one (dut or env for that matter). Double check yourself regularly, like someone once said - The question is not whether I am paranoid, but whether I am paranoid enough!

So debug efforts tend to quickly become bottlenecks, and to deal with that you’ve got to come up with as many debug tools and methods as you can before you instinctively bring on the heavy machinery “ the interactive debugger, the waveform viewer, the back-annotated source code, etc. I remember this one time I got called in to help out with a very complex generation issue: Hey Yaron, can you please come here for a minute and find out why this constraint here is never satisfied by the generator? I got the generation debugger already set up for you, the engineer said. Sure bro, I said, but just before we do that would you do me a favor and insert a syntax error in this file here? Are you out of your mind, Yaron? he frowned at me. Just do it, please, I said. You can probably guess the ending - wrong file was loaded

 

 
More articles :

» Prepare For Your Next Job Interview

Succeeding at job interviews requires practice. If you're applying for a verification job you'd better get yourself well prepared both mentally and technically. Nevertheless, a great deal of tension could be avoided if you knew in advance what sort...

» Coverage Driven Thoughts

In today’s short post what I’ll try to do is share with you some of the recent trends and ideas that deal with coverage. I won’t go into much technical detail today in order not to wear you (and myself) out, but really - if I want to be more...

» To Do List 2010

Introducing Philip Americus - a new guest blogger here on Think Verification. Phil is an ASIC veteran who's worked with every phase of ASIC design - from initial concept to tapeout, with an emphasis on verification, including management of both HW...

» Progressive Coverage

Progressive Coverage is a method of coverage collection that’s highly applicable in communication devices, but may as well be applied elsewhere. Now before I start to babble about my philosophy on coverage collection why don't I just give you an...

» To Randomize Or Not To Randomize

One of my former colleagues once revealed the fact that she had no less than 70 pairs of shoes. That’s right, seventy! She had been very good at her job and by no means had any plans to start her own shoe business so I asked myself why on earth...

Add comment


Security code
Refresh

Copyright © 2017 Think Verification - Tips & Insights on ASIC Verification. All Rights Reserved.
Joomla! is Free Software released under the GNU/GPL License.