I’m now sharing a collection of SystemVerilog timers that includes a simulation countdown timer and a watchdog timer.

If you find yourself forking off countdown timers in your BFMs – then you already have an idea of what this is.  I’ve encapsulated that common fork…join_any call as an egg-timer with start, stop, reset, and restart methods.

Instead of the confusing fork..join_any syntax (and having to remember to disable the fork!) you can simply instantiate an idv timer and start it.

An example:

idv_timer_sim timeout_timer = new(10us, 1); // constructs and forks off a 10us countdown timer
do_bfm_activity(...);
timeout_timer.stop(); // stops the timer

If the do_bfm_activity(…) takes more than 10us then the timerout_timer will alarm() and end the simulation with an error.

That’s much clearer than:

fork: bfm_timeout
   do_bfm_activity(...); // do the bfm task
   begin
      #10us; // fork off timeout time
      $display("Timer Expired!");
      $finish;
   end
join_any
disable bfm_timeout; // disable the fork

AND – you can extend the timer and redefine the alarm() behaviour to actually do some task; rather than do the default and stop the simulation with an error message.

The included watchdog timer is handy for situations where you expect a regular event within some time window.

More details:

• Countdown timer “idv_timer_sim”: a simulation countdown timer
  • This timer behaves like an ‘egg timer’ for simulation time. (We say simulation time to differentiate from a ‘wall time’ countdown timer.)
  • This timer can started, stopped, restarted (from stopped time), and reset to the initial time.
  • Use for any situation where you want your sim to stop (or do some activity) after a given amount of simulation time has expired.
  • Use to timeout on a hanging task call: start the timer, call the task, stop the timer; if the task call hangs then the timer alarm will sound.
  • Extend and redefine the alarm() method to define the timer expiration activity (the default is to end the simulation)
• Watchdog timer “idv_watchdog_sim”: a simulation watchdog timer
  • A watchdog timer is a special type of countdown timer that restarts itself on the occurance of a watched event.
  • Use to monitor a system heartbeat — if the duration between beats gets too long then timeout
  • Use to timeout a hanging bus — map an interface signal to an event; if it takes to long between events then the bus is hung
  • Like the timer – extend and redefine the alarm() method to define the timer expiration activity (the default is to end the simulation)
• VMM Implementation: individual extensions of both the timer and the watchdog for vmm (uses vmm_log objects for console messaging)
  • allows message instance name to be passed at timer construction – makes it clear which timer was triggered.

Download the timer release tarball from the timers page here:

http://intelligentdv.com/downloads/index.html#svtimers

Bugs and feature requests can be filed here:

http://bugs.intelligentdv.com/

Project: SVtimers

-Timer Expired!

IDV has just acquired a license for the Synopsys VCSi simulator!

The simulator is easy to use – and has a simple cli interface and a powerful GUI.  I’ve been using this simulator with great success at my day job for years.

Now that I have a simulator I’ve started developing source to share with the community, starting with a collection of SystemVerilog examples.

I learned SV by coding little snippets when I wanted to understand a concept; and now you can too!

The first example is a simple ‘Hello World’ program.  Really the first program is just a template for any other example.  It includes a pretty clean makefile (for VCS) and an empty canvas program block.

Usage:

If you use VCS at your work then you can use the makefile. You will likely have to assign the VCS variable to vcs (it is currently assigned to vcsi – the version of vcs that I am using here.)

I’d love to add Mentor’s Questa support to the makefile.  If you use Questa then please take a look and let me know what additions / changes would be required to run Questa in a batch mode. And – if you happen to work for mentor, and can get me a Questa license, then please drop me a line!

Runtime usage – the makefile has the following targets:

• make           — compile and run the example
• make run       — compile and run the example
• make gui       — compile and run the example using DVE
• make covreport — generate and view coverage report
• make cov       — generate coverage report
• make simv      — compile the example
• make tar       — create bz2 compressed tarball of this example (including log and dump)
• make clean     — delete all generated files (excluding log and dump)
• make cleanall  — delete all generated files (including log and dump)

The tar target is handy when you find a simulator issue that you need to share with your simulator vendor.

If you are writing an example that doesn’t include DPI-C code or RTL then no edits of the makefile should be required.

To make your own example:

• Edit the main.sv file to create your example code – and then just type make.
• Including additional testbench SV files:
  • just use the `include “yourfile.sv” in main.sv.
  • if the included files are in sub-dirs then edit the Makefile variable “INCDIR” to include your sub-dirs
  • if you include correctly the TBFILES should not have anything other than main.sv
• Including DPI-C C files:
  • set the CPPFILES variable with a space delimited list of the files
• Including RTL Verilog files:
• set the RTLFILES variable with a space delimited list of the files

You can download the examples as a tarball here:

http://intelligentdv.com/downloads/index.html#svexamples

If you have any issues please file a bug to the SVexamples project here:

http://bugs.intelligentdv.com

If you have any requests for examples you can file them there as well.

AND – if you have some examples that you’d like to share you can upload them through the bugtracker too!

-Hello, World

A new filter release – and this one has a significant new feature.  The filter now recognizes and groups interface, program, and module blocks.

An example of what this looks like is in the VMM documentation over here:

http://intelligentdv.com/documents/index.html#vmmdox

This release includes:

• bugfix: No support for parameterized interfaces (#29)
• feature: Added support for inline block comment
• feature: Changed macro parsing to convert the macro to doxygen-able code – this means that macros will display as valid C++ code (rather than the more familiar SV code); but also means that macro generated code is properly shown in the doxygen documentation (like the macro generated AVM classes in the OVM library)
• feature: Improved covergroup and constraint processing: now make them look like methods that return type covergroup (or constraint)
• bugfix: Fixed class extends template class
• bugfix: Fixed template angle bracket replacement algorithm (still not perfect, but better)
• bugfix: LRM apparently allows a space between the # and ( in a parameter port – fixed this
• feature: Added improved doxygen output for interfaces, modules, and programs (doxygen modules)
• feature: Added support for parameterized modules and interfaces – document as templatized methods
• cleanup: Combined module and interface parsing
• feature: Added layout xml file to change modules tab name (a doxygen 1.5.8+ feature)

You can pick up the release from the downloads page here:

http://intelligentdv.com/downloads/index.html#doxygentools

Or – you can grab it directly from the subversion repository with your svn client (or using the WebSVN site here).

TIP! These blog announcements often lag the actual release by several weeks…  so I recommend subscribing to the RSS feed for the Doxygen tags on the WebSVN site to keep up-to-date.

A Reminder: the doxygen filter is not a grammar — it, like the doxygen tool, is a lexical parser. So – you will find bugs.  And when you do – please file them to the bug tracker here:

http://intelligentdv.com/bugs/

-Better (not always the enemy of good)