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!

A new release to the SV simulation timers is now available!

This release includes

• fix for potential race condition on restart [#37]
• fix for issue with timescale in the tests [#36]
• proper use of ID for OVM console log reporting

You can see the doxygen documentation for this release here:

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

Note that the doxygen documentation for the SV Timers includes comments on how to use the timers in base, OVM, and VMM forms.

And you can download the release here:

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

If you find any bugs please file them to the bug tracker here:

http://intelligentdv.com/bugs/

-DinDinDing!

A minor new filter release.  This release includes full comments in the test.sv files. These comments will be used in forthcoming post about how to use doxygen with JavaDoc comments to document your SystemVerilog source code. The release also includes a fix for the parsing of the `timescale directive.

The next release looks like it will include a provided patch for an alternate way to handle module documentation.

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/

-minor

If you thought that timescale didn’t matter in SystemVerilog – think again!
And truth be told – I thought that timescale was obviated with SystemVerilog’s new features – and I’m having to think again!

So I had thought that we had finally rid ourselves of the `timescale albatross with SystemVerilog.

If you don’t remember the (old) issue here’s a refresher:
`timescale is a compiler directive used to configure the units and precision of a # delay in Verilog. The syntax is something like this:

`timescale 1ns / 10ps

which means that the time unit of a delay is 1ns and the precision is 10ps (or two decimals of precision in ns  as x.xx ns).
Since a delay in Verilog doesn’t have units it relies on the timescale to determine how long the delay will last in simulation.
No problem, right?

Here’s the issue: a `timescale directive has file scope and is “sticky” – once a `timescale is found while compiling everything in that file and following files has that timeunit and timeprecision value until the next `timescale is encountered.

And that was the issue – if you didn’t include a `timescale in your file then you relied on compilation order to get your timescale.  If the compilation order changed or the upstream file changed it’s unit then all of a sudden your delays were wrong.

Introducing SystemVerilog:
SystemVerilog solved this problem in two ways:

1. delays now have units!  So I no longer rely on the timescale time unit to determine how long my delay is.  Instead of #1;  I now say #1ns.
2. introduction of timeunit and timeprecision keywords – these allow the specification of a timescale within the declaration body of a module, interface, or package; no longer do we rely on a `timescale compiler directive.

Unfortunately the problem wasn’t solved…
While delays can be specified for units – effectively obviating the need for a timescale – there’s a (minor) catch.
If a delay is specified that is more precise than a previously declared timescale then it is rounded to match the timescale precision.
Example:

`timescale 1ns / 100ps
...
#1.75ns  // rounded to 1.8ns

But that’s a minor hiccup – compared to this:
The LRM doesn’t explicitly define what happens when the timeunits aren’t aligned. It seems that when a time (or realtime) typed variable is passed from one timescale domain to another the units are CHANGED to the destination timescale.
This is crazy.  If I define a realtime variable in a package with a timescale and then pass that variable to a function that is *defined* in another package (or file) timescale the time *units* are changed to match the destination timescale!
What does that mean?
It means that if I have 1.75ns in a 1ns/1ps timescale and pass it to a class declared in a 1ms/1us timescale that the time will be changed to 1.75ms.

An example follows – after the break.

(more…)

It looks like Synopsys has (quietly) released a version of VCS (C-2009-06) that supports OVM.

This is great news for the verification engineer!  This means that:

1. VCS users can finally take a look at OVM in earnest and make a ‘hands on’ comparison (beyond the marketing slides).
2. OVM users that are ‘stuck’ with ‘only’ 2 EDA vendors now have a 3rd option for a simulator
3. AND – it means that there’s potential for the big 3 EDA vendors to unite on a single verification methodology.

To run an example simply replace the run_questa script with a run_vcs script that looks like this:

vcs -sverilog -R -f compile_questa_sv.f

Easy!  (With one minor caviat – some of the compile_quest_sv.f files include Questa specific options that you’ll need to remove.)

For the (few) examples that I’ve tried vcs has output the result that I would have expected.
If you find an example that doesn’t work I’d bet that both Synopsys and the OVM World folks would be interested in hearing about it.

Oh – and an aside – no funny business (ahem! `ifdef INCA ahem!) was required to run the examples.  So VCS appears to have taken a big leap forward in its implementation of the SV standard.  Good job Synopsys!

-VCyeS