|
From: Maciej S. <mac...@ce...> - 2015-06-02 19:22:23
|
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
>
|