Re: [Iverilog-devel] Time in VHDL

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

On 06/01/2015 06:17 PM, Stephen Williams wrote:
> 
> Yeah. Ugh. Time scales.
> 
> What should happen (I think) is that during elaboration the compiler
> chooses from all the precisions a single global precision for the
> whole simulation.

That is true, the SV-2012 standard says exactly this in 3.14.3.

Then within each module scope the local time scale
> is used to convert times to the global precision. So 1ns should be
> 1ns anywhere in the design, and should be represented by the same
> numeric value.

I am not sure about this. Martin has checked the example with the 3
major simulators and got the same result (1001). I checked Modelsim and
Riviera-PRO and got identical output.

I could not find it described explicitly in the standard, but there are
fragments that make me think that time is just a real number that stores
count of time units, rounded to requested precision:
- table 21-8, entry for 't' input field
- reverse reasoning is explained in the second half of 22.7

I guess '#1ns' statement should introduce the same delay in every
module, but transferring time between modules is simply sending a number
without any units.

Perhaps that is why FPGA ICs are still limited to logic outputs and
noone has invented a technology to transfer time between chips.

Regards,
Orson

> Am I wrong about any of this?
> 
> On 06/01/2015 09:09 AM, Maciej Sumiński wrote:
>> On 06/01/2015 05:28 PM, Stephen Williams wrote: On 06/01/2015 08:16
>> AM, Maciej Sumiński wrote:
>>>>> All I need is to use the same timescale in simulated modules.
>>>>> For the moment there is no constraint coming from the modules
>>>>> I am trying to simulate, so even without introducing any
>>>>> changes regarding the timescale in vhdlpp I am still going to
>>>>> be content. Simply setting a sensible default timescale will
>>>>> work for me.
> 
>> If you only need your specific timescale to apply to your modules, 
>> then you should use a module specific timescale. The problem with 
>> the `resetall directive it that the consequences leak out of your 
>> modules to the rest of the design, and affect more than timescale. 
>> Writing your own `timescale directive also leaks out of your
>> modules into the design at a whole, in unpleasant ways. I think
>> that the timescale of VHDL code should not effect the timescale of
>> Verilog code, so you need to do something that has better scope
>> rules.
> 
>> It is perfectly OK, even expected, that modules have different 
>> timescales, it's just that the `timescale directive is horrible and
>> that is why SystemVerilog added the timescale module item. The
>> scoping rules for that timescale are rational.
> 
>> What it may come down to is that every module you generate has a
>> timescale module item.
> 
>>> That is true, but the problem for me appeared when trying to
>>> simulate modules with time-typed ports. The following file still
>>> has the same problem:
> 
>>> -------------------------------------- module mod(input time a); 
>>> timeunit 1ns; timeprecision 1ns; always @(a) begin #(a + 1ns)
>>> $display($time); end endmodule
> 
>>> module mod_test; timeunit 1ps; timeprecision 1ps; time a; mod
>>> dut(a); initial begin a = 1ns; end endmodule 
>>> --------------------------------------
> 
>>> The issue here seems to be caused by incompatibility between SV
>>> and VHDL standards. For modules with time-typed ports the only
>>> way to go is to use the same timescale for every module. The
>>> modules I am trying to simulate do not have imposed any
>>> timescale, therefore I am free to apply a default setting via a
>>> configuration file.
> 
>>> In the end I removed the commits that introduce any changes to 
>>> timescale. Initially I thought they may help, but now I agree
>>> they have become a great source of confusion and potential
>>> troubles. Instead I simply added a configuration file for the
>>> test to set the timescale, so it is the same way I am going to
>>> proceed with my project.
> 
>>> Regards, Orson
> 
>> Note, BTW, that there is a difference between timescale and
>> precision. Note also that there is not really a big performance
>> consequence for having too much precision in Icarus Verilog, due to
>> the way it operates its event queue.
> 
>>>
>>> ------------------------------------------------------------------------------
>>>
>>>
> _______________________________________________
>>> 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
>