Re: [Iverilog-devel] Time in VHDL

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

You are pointing out a problem with VERILOG and not VHDL vs. Verilog.
In Verilog, time values do not cross module boundaries through ports.
Doing so will get you the headaches that you see. Fixing it will
involve extending the verilog language.

If we want to fix it (and I don't know if we do) then the way to do
that is to create a new extension type (i.e. $precise_time) that
converts assignments in from the local time units to run-time
precision, and read outs from simulation precision to local time
units. Or you can hand code that behavior with system tasks.

My point is that I think you've done what you can. You can't go
mussing with the time units of other modules so you are stuck.
Just don't pass times through ports unless you manually convert
them to the run-time precision, and host the consumer of that time
does the same.

On 06/02/2015 12:22 PM, Maciej Sumiński wrote:
> On 06/01/2015 09:57 PM, Stephen Williams wrote:
>> 
>> How 'bout this...
>> 
>> Define a command line flag for VHDL compilation that sets the
>> default VHDL precision. Let Verilog/SystemVerilog get its
>> precision by its own means. The vhdlpp generated modules all have
>> the default  VHDL time precision, and enforces this by
>> timeprecision and timeunits module items. These are supposed to
>> override Verilog `time* directives within the scope of the module
>> at hand.
>> 
>> The Verilog semantics for precision are that the elaborator
>> finds the highest precision needed and uses that as the global
>> precision. All time literals are scaled from units to precision
>> by the compiler.
>> 
>> These semantics should just work. I'm still not understanding
>> what the problem is.
> 
> It might be not only the problem of precision (actually I think 
> precision does not cause any issues here), but the time units used
> in modules.
> 
> I am far from calling myself a SystemVerilog expert, so I may need
> some guidance. What do you think about the following example?
> 
> ------------------------------------ orson@pc ~/workspace $ cat
> time3.v module mod(input time a); timeunit 1ns; timeprecision 1ps;
> 
> always @(a) begin // this should happen after 2ns #(a + 1ns)
> $display("this message should appear first (time=%t)", $time()); 
> end endmodule
> 
> module mod_test; timeunit 1ps; timeprecision 1ps;
> 
> time a; mod dut(a);
> 
> initial begin a <= 1ns; // this should happen after 100ns #(100ns)
> $display("this message should appear second (time=%t)", $time()); 
> end endmodule
> 
> orson@pc ~/workspace $ iverilog -g2005-sv time3.v orson@pc
> ~/workspace $ vvp a.out this message should appear second (time=
> 100000) this message should appear first (time=
> 1001000) ------------------------------------
> 
> I would expect different behaviour, even though timeprecision is
> the same in both modules. I see it this way: 1. The first line time
> value (100000) is simply 100ns expressed in ps, no magic here. 2.
> "a <= 1ns" converts 1ns to time units, so it becames an integer
> equal 1000 (time units, picoseconds in this case). 3. mod receives
> 1000 and scales it using its own units, here it becomes 1000 ns.
> This step I consider problematic, but apparently it is correct 
> according to SV standard. 4. Second line is displayed after 1001
> ns, using the requested precision, hence 1001000 ps.
> 
> As I mentioned previously, I removed all commits that influenced
> time scale and I am completely fine with it, as suggested method
> with +timescale parameter works for me.
> 
> If there is such will request, I may implement one of the proposed 
> solutions, but my gut feeling tells me it will not change much in
> this matter, unless every module uses the same time unit.
> 
> Regards, Orson
> 
>> On 06/01/2015 12:11 PM, Martin Whitaker wrote:
>>> Cary R. wrote:
>>>> I have not looked at your pull request, but from what I am 
>>>> reading you may have added code that addresses one of our
>>>> older feature requests on SourceForge so please look at them.
>>>> I think `resetall may be a bit heavy handed since it will
>>>> change the timescale, etc. that future modules/files will
>>>> see. It seems like the more localized SV additions would be
>>>> best for setting the scale and precision for only the
>>>> translated modules.
>> 
>>> Well, if future files depend on what's gone before, they're 
>>> fundamentally broken, as nothing guarantees the order in which 
>>> files are read.
>> 
>>> But to summarise what I wrote yesterday:
>> 
>>> - VHDL has a global time resolution that applies to the entire
>>>  elaborated design - by default this is 1fs - the VHDL
>>> standard allows for the user to override the default - all
>>> simulators I've looked at support this via a configuration file
>>> or command line option
>> 
>>> I think we need to do the same.
>> 
>>> If people don't like `resetall, then I propose the following 
>>> alternative:
>> 
>>> - as an Icarus extension, allow the special value 'vhdl' to be
>>> used in SV timeunit and timeprecision declarations - set the
>>> default units and precision for vhdl to 1fs - allow the
>>> +timescale option to override these defaults
>> 
>>> We could use 'default' rather than 'vhdl' and use the existing 
>>> default timescale values, but then I'd want to change the
>>> initial defaults.
>> 
>>> Martin
>> 
>>> ------------------------------------------------------------------------------
>>
>>
>>
>>> 
_______________________________________________
>>> Iverilog-devel mailing list
>>> Ive...@li... 
>>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>> 
>> 
>> 
>> 
>> ------------------------------------------------------------------------------
>>
>> 
_______________________________________________
>> Iverilog-devel mailing list Ive...@li... 
>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>> 
> 
> 
> 
> 
> ------------------------------------------------------------------------------
>
> 
> 
> 
> _______________________________________________ Iverilog-devel
> mailing list Ive...@li... 
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
> 

- -- 
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlVuGRgACgkQrPt1Sc2b3ill/wCeNgWEG5/Zh95QGmUBFxdFt0YC
dHAAniw5dF6MGAoVBzllEUyeV4MdpLy2
=RY8l
-----END PGP SIGNATURE-----