Re: [Iverilog-devel] Time in VHDL

[Maciej S. <mac...@ce...>]

On 05/30/2015 09:05 PM, Martin Whitaker wrote:
> Cary R. wrote:
>> Hi Orson, We should look at the standard because this could be a bug in
>> Icarus, though I certainly understand how it could have been missed in
>> Icarus, the standard or other simulators. My analysis is that in the main
>> module since the time scale is 1ps we have a value of 1,000 in the a
>> variable. It is possible that time variables that are passed are not to be
>> scaled as the current behavior does or it could be that we are supposed to
>> scale the value using the caller and called routines time scale and
>> precision. Depending on how VHDL time variables work we could end up with a
>> difference because of the scaling that Verilog specifies.
>>
> The 'time' data type in Verilog (and SystemVerilog) is a simple integer data 
> type with no special semantics. If you pass a time value to a module with a 
> different time scale, you have to scale it yourself - the language does 
> nothing to help you.

I could not find it explicitly written in the standard, but I had the
same feeling after reading parts on `timescale (e.g. the very end of
22.7 point).

> I've verified that the big 3 simulators all give the same result as Icarus for 
> Orson's example.
> 
>> We absolutely cannot just start putting arbitrary time scales or precisions
>> on modules to make things work if they have already been given a timescale
>> directive since that changes how time values are scaled/rounded in the
>> module and that must work as specified by the standard (e.g. lets say you
>> have a raw delay of #1.1 in the called routine).

True, but I am not trying to force it in every case, but give an option
to do so.

> Maybe the solution to Orson's problem is for vhdlpp to issue a `resetall at 
> the start of each translated file and use the existing iverilog +timescale 
> option to set the required timescale. We might want to choose a smaller 
> default timescale in this case (e.g. 1ps/1ps rather than 1s/1s).

I am afraid there is no good solution to the problem due to the fact how
time values are handled in (System)Verilog.

Instead of using automatically matched timescale, I could use a constant
`timescale for every VHDL file, no matter what values are used inside.
Then it might be wrong for files that use e.g. seconds or femtoseconds.

If I understand correctly how `resetall and +timescale work, the effect
would be the same as if I forced a single timescale for every VHDL file
with default `timescale directive. It also means that problem would
persist for SV modules with their own timescales.

Perhaps I could write a VPI function to wrap time port names in order to
apply scaling. E.g. the problematic statement would be changed to:

  #($ivl_timescale(a) + 1ns) $display($time);

Still, SV modules with timescales defined are going to cause headache.

I realize the solution I proposed for merging is not very elegant (as is
the nature of any workaround), but I cannot find any other way to
ultimately solve the issue.

Regards,
Orson