Thanks for letting me know about the issue.
You need to be using the current version of the doxygen binary (1.62).
If moving to the current version doesn’t solve your issue then please file a bug.

-Sean

Doxygen-2.6.1.r133.tar.gz
VMMdocs-1.6.2.r40.tar.gz

and doxygen version 1.4.7 on Centos.

I have tried to download your Doxygen filters (I think your work is great and I appreciate it quite a bit) for SV and the VMM scripts. Then I tried to run them on my downloaded versions of VMM 1.0.1, 1.1 and 1.2 from vmm-central.org.

Everything went fine on 1.0.1, but some warnings were reported on 1.1 and errors were reported on 1.2. I didn’t want to file a bug, since I don’t have an overview of what is already filed. I can send you the log files via mail or file a bug – let me know what you want me to do.

Regards, JacobSA

This is similar to the convention that I’ve taken. But rather than pass values as ‘time’ I pass them as either ‘int’ or ‘real’ depending on what I need. I normalize on a per method basis – and comment that method accordingly.

BUT – the SystemVerilog gotcha is a new one! Since I can now apply the units on assignment it’s important to know that the units are applied on assignment in the current timescape and NOT stored with the value.

It sure would be nice if the units were stored independently – such that the time could be passed between timescale domains without any unexpected corruption.

-Sean

And is the DVT plugin open source?
It looks like you offer an older release of DVT for a free and the current release for a fee.

-Sean

The issue about communicating time information across module
boundaries is independent of `timescale versus timeunit. I responded
to this issue a while back:

Communicating time values across multiple timescale domains has been a
‘gotcha’ in Verilog since day one. Timescales only apply to scaling of
literal time values, not values of variables or passed arguments.

Therefore, you should always use a literal time value in any
expression involving time to a normalized time unit – 1ns, for example.

–file with timescale/timeunit X

time tv;

tv = 10ns / 1ns; // 10 – regardless of the current timescale

delay_task(tv); // wait 10 ns
delay_task(100ms/1ns); // wait 100ms
————————–

– file with timescale/timeunit Y

task delay_task(time t);
#(1ns * t); // will scale to the correct time delay endtask

Even if the language were enhanced to provide ‘raw’ simulation time
conversion function, both the call site and the callee would have to
perform the conversion and agree that the timeout argument was in ‘raw’
time units. That’s no different in terms of complexity/typing than
agreeing on 1ns, but the latter is already supported in SV.

-Sandeep.