debug

A few tips to debug faster

Did you know ...

 

1. Divide the log handler to handle INFO, DEBUG1, DEBUG2, ERROR messages.

2. For each task/function, display the name and time of the task/function as a DEBUG2 message.

function void myClass :: findMyName; 

`LogMsg (DEBUG2, $sformatf (“%t [Xtr] findMyName started with array %s”, $time, arrayName));

endfunction

3. Whenever you write a DEBUG/INFO/ERROR message, try to include as many variable states as possible in the message.

`LogMsg (DEBUG, $sformatf (“Word not received axiWord = 0x%0h word = 0x%0h …”, axiWord, word));

4. Organize and structure your code, and make a clear demarcation between functions like :

//———————————————————————————–

//                               <Function Name1> {{{1

//————————————————————————————

function  <functionName1> ;

endfunction

//———————————————————————————–

//                               <Function Name2> {{{1

//————————————————————————————

function <functionName2>

endfunction

5. Use vim folding. To enable automatic folds, use {{{1 (for 1 level) like above example. When you hit zM, all open folds will close and you’ll get a clean version with only function names and all details will be tucked into the folds. It’s pretty neat because now you know where a function starts and ends and will save precious time later on.

6. Keep functions and tasks as external components in your class definition. This will help you identify the functions faster, and endclass will not run into multiple PgDn keystrokes away.

7. Use notations like _t (for tasks) _f (for functions) e_ (suffix for Enums) c_ (suffix for constraints) cp_ (suffix for coverpoint) cg_ (suffix for covergroups) a_ (assertions) p_ (property).

8. Keep a track on the hierarchy of classes and prepare a diagram that shows class inheritance structure.

9. Use typedef class <Name>  to forward reference a class object that you intend to use, but haven’t written a definition for.

10. Keep your enums separate in a package, and access them in other classes as :

myEnumPkg :: e_Name  myName;

myName =  myEnumPkg::Wordpress;

or

import myEnumPkg :: *; 

For import, see this before you start using them.

11. Write a perl/python script to parse log files for Errors, Assertions, Warnings. Do this early on and you’ll save a ton of time later.

 

 

Debugging/Dumping Assertions in Verdi

Did you know ...

Debugging assertions can be painfully long and exhausting. Well, there’s an easier way to do that using Synopsys Verdi ( coz, I just found out how).

I’ll leave it upto you to find out where vericom is. It’s usually under springsoft-verdi folder in the installation directory.

vericom -sv +ignorefileext+vhd -assert svaext -useius -syntaxerrormax 2000 -top -f <fileList>

Make sure that it contains the code for assertions as well. Once it compiles, you’ll find a new folder “worklib++” in the current directory.

verdi -nologo -sv -lib work -vtop “<module_name>=<top_name>.<module_name>”

Verdi will launch, load an FSDB waveform dump, and go to

Tools > Property Tools > Statistics.

statistics
This will open up a window and show how many assertions passed/failed. Right click on one of the “Fails” and “Add to Details“. Open up the hierarchy and right click to see “Analyze Property“. Then Verdi will start analyzing the properties in the Analyzer window and you’ll get to see the values of local variables used in your assertions.

TIP : You can add the assertions to your waveform, right-click it and select “Show Driver/Load Signals > Driver Signals” and it will pull out all the signals that affect the value of the assertion. You can also middle click the assertion and pull it into the source tab and Verdi will find the assertion in the source code. You can also see the current values of the variables beside the code by enabling Source > Active Annotation and Source > Parameter Annotation.

To dump assertions in ncsim, use fsdbDumpSVA ().