I’ve created and released a randomizable SystemVerilog reset transaction / transactor library. Not only is this library useful for those simply looking for a randomized mechanism for sending reset(s) to a device under test (DUT), it is also useful for those of you looking to see how to build a transaction based bus functional model / monitor in both a generic and VMM 1.1 style. The generic models are wrapped with their VMM counterparts and are tested using a VMM environment and signal layer.

Shows how to:

• build a modern randomized SystemVerilog verification component / transaction in a generic fashion
• integrate a generic transaction / component into the VMM
• write a VMM transaction / transactor driver / transactor monitor
• build a VMM environment and signal layer
• connect a DUT to a class based testbench using interfaces with modport, clocking blocks and virtual interfaces
• use SystemVerilog constraints to get a desired result
• implement functional coverage
• use VMM callbacks to collect functional coverage
• create (and run) tests in the VMM style (vmm_test) – by instantiating and constraining the environment

Can be used to:

• drive one (or more) active high or low reset(s)
• drive a sync/async assert/deassert reset
• drive reset for a specific or random range duration
• assert / deassert asynchronously randomly within the clock period
• monitor existing reset(s) for coverage
• can be driven with transactions or with direct method calls of the bfm methods

All of the SystemVerilog library source code including the code required to document and run the environment are available to download here:

http://www.intelligentdv.com/downloads/index.html#svreset

The library is fully documented with doxygen and that documentation is available here:

http://www.intelligentdv.com/documents/index.html#resetdox

The complete details of what the library includes are after the break.

Read the rest of this entry »

A minor filter release with a some bug fixes to the 2.5.0 release.

This release includes:

• bugfix: macros with `” aren’t properly handled (stringize issue) (#39)
• bugfix: protected keyword does not play well with multi-line enums and member variables (#45)
• bugfix: import package should be ignored (#40)
• feature: add support for SV Packages (#20)
• workaround: Does not handle nested OVM macros (doxygen issue) (#43)
• change: comments are no longer filtered from source (doxyfile delta change)
• change: added language switch for sv/svh extension — C++

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 (like this one) 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/

Your tickets in the tracker are what pushes the filter improvements.

-another fix

A new release of the syntax files set is now available. All of the syntax files have been updated to reflect recent changes to the SystemVerilog IEEE 1800 standard (up to the draft 1800-2009 release).

This includes syntax files for:
- Kate (KDE Linux Editor)
- Crimson (Windows Editor)
- SciTE (Windows Editor – with syntax color RTF copy support)
and
- GeSHi (PHP based Syntax Highlighter)

So what’s GeSHi? Awesomeness!

GeSHi is how I have color coded SystemVerilog code posted on my blog (using WordPress with the WP-Syntax plugin) — like here in this blog post.

And GeSHi is how I have color coded code posted in my WebSVN repository – like here in the SVtimers repository.

Yeah – GeSHi is pretty cool.
I’ve sent my syntax file to the GeSHi team – hopefully they’ll accept it in their release.

You can download this release here:

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

-Syntax-2009-d8

The scripts provided here at intelligentDV will document your SystemVerilog testbench code automatically.  But that documentation would be a lot more useful with the addition of doxygen styled comments. In this post I’ll show you what doxygen documents automatically and how to improve that documentation by adding comments with examples of both the input and output

Without any special comments doxygen will parse your code and generate documentation that will show you all of your:

• files
• classes
• programs
• interfaces
• modules
• macros (defines)
• functions
• tasks
• variables

Additionally – the tool will show you the class member variables, member functions, inheritance hierarchy and usage (collaboration).

Unfortunately the tool can’t document what each is.  For example: doxygen can ’see’ that you’ve written a classA that extends classB — but it can’t tell you what the classA is for or how to use it. This is where the addition of doxygen comments come in. You can augment the automatic documentation with comments that disccuss the details of how to use a given class or method, the intent of a variable, etc.

Every doxygen comment is essentially broken into a three parts:

1. the doxygen trigger comment – an augmented comment so that doxygen knows that it needs to parse the contents for markup (we use /** and ///< ); NOTE: the brief must be terminated with a period (.)
2. the brief comment – the title for the comment; this one is used in lists — for example, the brief class comment appears in th elist of classes alongside the class name
3. the full comment – this is where you put your full description and can include doxygen tags as well as any HTML tags

The typical doxygen comment – in JAVADOC style – looks like this:

/**
 * Brief Comment with a period to terminate.
 * Full comment:
 *  the full comment can continue on multiple lines
 * <em>use HTML tags</em>
 * @note And use doxygen tags
 *
 */

An important note worth reiterating – the brief comment can continue over multiple lines and must be terminated with the period ‘.’ or the brief comment won’t be so brief.

I recommend using the JAVADOC style of comment. In addition to doxygen a number of documentation tools also support this format. That, and it’s a good looking format for comments.

I recommend using HTML tags only when there isn’t a corresponding doxygen tag that accomplishes the same.

A starter guide from the doxygen folks is here:
http://www.doxygen.org/docblocks.html

And all of the available doxygen markup is found on the doyxgen site here:
http://www.doxygen.org/commands.html

But no need to look at that just yet – After the break I’ll give you some cut-n-paste code that should cover most of your needs for:

• file
• class
• function/task/module/interface/program/constraint/coveragegroup
• variable
• enum

I recommend to comment – at a minimum – all files, classes, public members of those classes (including variables, tasks, functions, constraints, and coveragegroups), and any frequently used define macros.
After the break I’ll provide examples.

Read the rest of this entry »

The OVM has been updated to 2.0.2. You can grab the latest release from ovmworld.org.

The biggest difference that I see (other than bugfixes) is the move to inline (in source) generated documentation using NaturalDocs. While I still prefer Doxygen, I’m a huge fan of comment generated documentation – it helps to ensure that the docs stay up-to-date with the code.

And look for a post from me soon(ish) comparing NaturalDocs to Doxygen to v2html for hardware verification documentation. They all have their merits.

And I still don’t get email notifications of new releases from the ovmworld site – which is why this post always lags the OVM release.

As usual – I have the updated OVM docs posted here:

http://www.intelligentdv.com/documents/index.html#ovmdox

If you find a bug in the doxygen, then please let me know.

Enjoy!