Debugging Tips -

• Try raising the verbosity. Most CSIM tools have a -v command-line option that allows you to set the level of diagnostic messages to see.
  Example:

  csim -v 1000 testarch.sim

  ... this sets the verbosity to be 1000. Generally, the higher the verbosity, the more detailed the messages become. While supporting debugging by phone, the CSIM support team often asks for snapshots of the output from higher verbosities.

• Use Debugger - A debugger is useful for some kinds of debugging. It is particularly useful for diagnosing an endless loop, a crash or a segment fault. The debugger stops your program where the fault occurs. Not only does it show you where the failure is, but it also lets you view the values of all the variables interactively.

  To use the GNU debugger, compile with -g (this is the default with the CSIM setup file). Then invoke your simulation with:

  gdb sim.exe

  At the debugger prompt, type: run
  (If you need to place arguments on the command-line for your simulation, you must put them after the run command; not at the gdb command.)

  When your program crashes, or you stop it with control-C, the debugger shows you the line of your program that was running. Note the line number. You can use that with an editor to locate the place in your model.

  You may stop in the middle of a deeply nested subroutine call. You can view the calling stack (I.E. how you go there), by typing where at the debugger prompt. It will list the sequence of subroutines and there line-numbers which got you there. It also shows the values of their parameters.

  You can examine the values of any variables by typing print and then the variable name. Example:

  print xyz

  Note that you have to be in the proper scope to view local variables. (You have to be in the routine who owns the variable.) To see variables of routines on the calling stack (I.E. that got you there), type return to move back up the stack.

  Although gdb is a text-based debugger, there are also graphical debuggers, such as DDD, KDevelop, KDbG, and XEmacs, which are all based on gdb underneath. Also REXX. Also dbx seems to be useful when using the Sun Compiler. For the most part, they all support the same commands.

• Use -trace - When this option is placed on the CSIM build command-line, causes the preprocessor to insert a unique Debug xx printf between every line of your model-code in the intermediate out.c file. The result is a detailed execution history of every line of code executed as your simulation runs. This is a heavy-duty debugging option that is useful, for example, to isolate the exact sequence of lines of code executed within your model prior to a crash. It complements the power of a debugger, which may only show the line where a crash occurred, or in the unlikely event that debugger interaction alters a crash condition.

  It is often useful to redirect the simulator output into a log-file when using this option.

  sim.exe > log

  Then edit the log file with an editor.

• Use -include_marks - This option causes errors to be reported by their original source file-name and line-number. By default, C-code errors are reported from the C-compiler by their line-number in the intermediate out.c file. This option embeds trace-back information in out.c so the C-compilers and debuggers know the original source file (xx.sim) and original line numbers. Both compile-time and run-time errors are then reported relative to the original source files. [Presently, the line numbers are only approximate in this option. Soon to be fixed.]