iverilog-devel

[Iverilog-devel] Time in VHDL

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

Hi,

I am looking for the best way to implement expressions related to time
in vhdlpp. Ideally, I would use SystemVerilog's time literals, so:

  wait for 10 ns;

is translated to:

  #10ns;

This ought to be trivial with the current ivl version. The only obstacle
I face now is to support constants, like:

  constant a : time := 10 ns;

The problem here is how to use them in SystemVerilog modules that may
have different time scales.

* First option
One solution that is easy for me to implement is to prepare an
Icarus-specific function that takes mantissa and exponent to describe a
time period:

  localparam a = $ivl_time(10, -9);

Then during elaboration the value would be adjusted according to the
time scale of scope where it is used.

* Second option
While the first approach satisfies my needs, there might be a solution
that you find more advantageous. It also does not introduce any
Icarus-specific functions.

Though it is not available at the moment, it should be fairly easy to
make localparam accept time literals, so the initial example becomes:

  localparam a = 10ns;

but the current implementation stores time as floating point numbers
adjusted to the time scale of the scope where a delay was defined [1].

In order to use a localparam value in a scope that uses a different time
scale, the absolute time value has to be preserved and adjusted during
elaboration (just like $ivl_time would do). To do so, I may either
introduce a new type (veritime?), or assume time values are saved in
femtoseconds.

Do you have any thoughts/preference?

Regards,
Orson

1. https://github.com/steveicarus/iverilog/blob/master/parse.y#L2782

Re: [Iverilog-devel] Time in VHDL

[Martin W. <mai...@ma...>]

Your second option is standard SystemVerilog, so that is the best way to go. 
For accuracy, you should probably store time constants as a mantissa + exponent.

Martin

Maciej Sumiński wrote:
> Hi,
>
> I am looking for the best way to implement expressions related to time
> in vhdlpp. Ideally, I would use SystemVerilog's time literals, so:
>
>    wait for 10 ns;
>
> is translated to:
>
>    #10ns;
>
> This ought to be trivial with the current ivl version. The only obstacle
> I face now is to support constants, like:
>
>    constant a : time := 10 ns;
>
> The problem here is how to use them in SystemVerilog modules that may
> have different time scales.
>
> * First option
> One solution that is easy for me to implement is to prepare an
> Icarus-specific function that takes mantissa and exponent to describe a
> time period:
>
>    localparam a = $ivl_time(10, -9);
>
> Then during elaboration the value would be adjusted according to the
> time scale of scope where it is used.
>
> * Second option
> While the first approach satisfies my needs, there might be a solution
> that you find more advantageous. It also does not introduce any
> Icarus-specific functions.
>
> Though it is not available at the moment, it should be fairly easy to
> make localparam accept time literals, so the initial example becomes:
>
>    localparam a = 10ns;
>
> but the current implementation stores time as floating point numbers
> adjusted to the time scale of the scope where a delay was defined [1].
>
> In order to use a localparam value in a scope that uses a different time
> scale, the absolute time value has to be preserved and adjusted during
> elaboration (just like $ivl_time would do). To do so, I may either
> introduce a new type (veritime?), or assume time values are saved in
> femtoseconds.
>
> Do you have any thoughts/preference?
>
> Regards,
> Orson
>
> 1. https://github.com/steveicarus/iverilog/blob/master/parse.y#L2782
>
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>
>
>
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>

Re: [Iverilog-devel] Time in VHDL

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

Hi,

I have managed to implement time and wait for/on/until statements in
vhdlpp [1] with tests [2].

I have chosen yet another way that seems much simpler. By default vhdlpp
analyzes time expressions used in the processed file and then stores the
required time precision in `timescale directive.

This approach does not solve the problem of different timescales in
modules. Therefore there is an additional option for iverilog & ivlpp to
override `timescale directives. This way all time expressions use the
same format and everything works as expected. I guess it might be useful
also for (System)Verilog simulations as well.

Regards,
Orson

1. https://github.com/steveicarus/iverilog/pull/70
2. https://github.com/orsonmmz/ivtest/tree/time_test

On 05/23/2015 12:26 AM, Martin Whitaker wrote:
> Your second option is standard SystemVerilog, so that is the best way to go. 
> For accuracy, you should probably store time constants as a mantissa + exponent.
> 
> Martin
> 
> Maciej Sumiński wrote:
>> Hi,
>>
>> I am looking for the best way to implement expressions related to time
>> in vhdlpp. Ideally, I would use SystemVerilog's time literals, so:
>>
>>    wait for 10 ns;
>>
>> is translated to:
>>
>>    #10ns;
>>
>> This ought to be trivial with the current ivl version. The only obstacle
>> I face now is to support constants, like:
>>
>>    constant a : time := 10 ns;
>>
>> The problem here is how to use them in SystemVerilog modules that may
>> have different time scales.
>>
>> * First option
>> One solution that is easy for me to implement is to prepare an
>> Icarus-specific function that takes mantissa and exponent to describe a
>> time period:
>>
>>    localparam a = $ivl_time(10, -9);
>>
>> Then during elaboration the value would be adjusted according to the
>> time scale of scope where it is used.
>>
>> * Second option
>> While the first approach satisfies my needs, there might be a solution
>> that you find more advantageous. It also does not introduce any
>> Icarus-specific functions.
>>
>> Though it is not available at the moment, it should be fairly easy to
>> make localparam accept time literals, so the initial example becomes:
>>
>>    localparam a = 10ns;
>>
>> but the current implementation stores time as floating point numbers
>> adjusted to the time scale of the scope where a delay was defined [1].
>>
>> In order to use a localparam value in a scope that uses a different time
>> scale, the absolute time value has to be preserved and adjusted during
>> elaboration (just like $ivl_time would do). To do so, I may either
>> introduce a new type (veritime?), or assume time values are saved in
>> femtoseconds.
>>
>> Do you have any thoughts/preference?
>>
>> Regards,
>> Orson
>>
>> 1. https://github.com/steveicarus/iverilog/blob/master/parse.y#L2782
>>
>>
>>
>> ------------------------------------------------------------------------------
>> One dashboard for servers and applications across Physical-Virtual-Cloud
>> Widest out-of-the-box monitoring support with 50+ applications
>> Performance metrics, stats and reports that give you Actionable Insights
>> Deep dive visibility with transaction tracing using APM Insight.
>> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>>
>>
>>
>> _______________________________________________
>> Iverilog-devel mailing list
>> Ive...@li...
>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>>
> 
> 
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud 
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
> 

Re: [Iverilog-devel] Time in VHDL

[Stephen W. <st...@ic...>]

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


Hmm... I haven't been paying attention, so forgive me while I try
to catch up.

As for using VHDL constants that are time values, is there a reason
you cannot translate them to SystemVerilog time literals? Those are
valid and correct no matter the `timescale setting for a given module.
That is why they were invented for SystemVerilog.

On 05/29/2015 09:34 AM, Maciej Sumiński wrote:
> Hi,
> 
> I have managed to implement time and wait for/on/until statements
> in vhdlpp [1] with tests [2].
> 
> I have chosen yet another way that seems much simpler. By default
> vhdlpp analyzes time expressions used in the processed file and
> then stores the required time precision in `timescale directive.
> 
> This approach does not solve the problem of different timescales
> in modules. Therefore there is an additional option for iverilog &
> ivlpp to override `timescale directives. This way all time
> expressions use the same format and everything works as expected. I
> guess it might be useful also for (System)Verilog simulations as
> well.
> 
> Regards, Orson
> 
> 1. https://github.com/steveicarus/iverilog/pull/70 2.
> https://github.com/orsonmmz/ivtest/tree/time_test
> 
> On 05/23/2015 12:26 AM, Martin Whitaker wrote:
>> Your second option is standard SystemVerilog, so that is the best
>> way to go. For accuracy, you should probably store time constants
>> as a mantissa + exponent.
>> 
>> Martin
>> 
>> Maciej Sumiński wrote:
>>> Hi,
>>> 
>>> I am looking for the best way to implement expressions related
>>> to time in vhdlpp. Ideally, I would use SystemVerilog's time
>>> literals, so:
>>> 
>>> wait for 10 ns;
>>> 
>>> is translated to:
>>> 
>>> #10ns;
>>> 
>>> This ought to be trivial with the current ivl version. The only
>>> obstacle I face now is to support constants, like:
>>> 
>>> constant a : time := 10 ns;
>>> 
>>> The problem here is how to use them in SystemVerilog modules
>>> that may have different time scales.
>>> 
>>> * First option One solution that is easy for me to implement is
>>> to prepare an Icarus-specific function that takes mantissa and
>>> exponent to describe a time period:
>>> 
>>> localparam a = $ivl_time(10, -9);
>>> 
>>> Then during elaboration the value would be adjusted according
>>> to the time scale of scope where it is used.
>>> 
>>> * Second option While the first approach satisfies my needs,
>>> there might be a solution that you find more advantageous. It
>>> also does not introduce any Icarus-specific functions.
>>> 
>>> Though it is not available at the moment, it should be fairly
>>> easy to make localparam accept time literals, so the initial
>>> example becomes:
>>> 
>>> localparam a = 10ns;
>>> 
>>> but the current implementation stores time as floating point
>>> numbers adjusted to the time scale of the scope where a delay
>>> was defined [1].
>>> 
>>> In order to use a localparam value in a scope that uses a
>>> different time scale, the absolute time value has to be
>>> preserved and adjusted during elaboration (just like $ivl_time
>>> would do). To do so, I may either introduce a new type
>>> (veritime?), or assume time values are saved in femtoseconds.
>>> 
>>> Do you have any thoughts/preference?
>>> 
>>> Regards, Orson
>>> 
>>> 1.
>>> https://github.com/steveicarus/iverilog/blob/master/parse.y#L2782



- --
>>> 
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

iEYEARECAAYFAlVow6sACgkQrPt1Sc2b3ikWogCfYFwBfnTzPUWCX/4hPlO3GlW1
Q0UAoL+2ZzWHQddV5MZaqJ+PBXdfMUD/
=aaVs
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Time in VHDL

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

Hi Steve,

Sorry, the message might have been a bit confusing. I use time literals,
I agree that is the right way to go. "wait for 10ns" simply becomes
"#10ns" and everything is clear.

Vhdlpp analyzes time literals used in a unit and stores the smallest
time unit in `timescale directive. To illustrate: if there are "wait for
30 ns" and "wait for 10 ps" statements, then the output is preceded with
"`timescale 1ps/1ps". I do not insist on merging this particular commit,
just thought it might be a better idea than using the default 1s/1s setting.

The main problem I had was caused by transferring time values via ports
between modules using different timescales. For example:
----------------------
`timescale 1ns/1ns
module mod(input time a);
  always @(a) begin
    #(a + 1ns) $display($time);
  end
endmodule

`timescale 1ps/1ps
module mod_test;
  time a;
  mod dut(a);
  initial begin
    a = 1ns;
  end
endmodule
----------------------
I would expect the code to display either "2" (ns) or "2000" (ps), but
the output is "1001". I checked it with another, very common simulator
and the result was the same.

I am trying to workaround the problem by overriding all `timescale
directives with one passed to iverilog command. Perhaps it could be
useful for pure (System)Verilog simulations as well.

Regards,
Orson

On 05/29/2015 09:53 PM, Stephen Williams wrote:
> 
> Hmm... I haven't been paying attention, so forgive me while I try
> to catch up.
> 
> As for using VHDL constants that are time values, is there a reason
> you cannot translate them to SystemVerilog time literals? Those are
> valid and correct no matter the `timescale setting for a given module.
> That is why they were invented for SystemVerilog.
> 
> On 05/29/2015 09:34 AM, Maciej Sumiński wrote:
>> Hi,
> 
>> I have managed to implement time and wait for/on/until statements
>> in vhdlpp [1] with tests [2].
> 
>> I have chosen yet another way that seems much simpler. By default
>> vhdlpp analyzes time expressions used in the processed file and
>> then stores the required time precision in `timescale directive.
> 
>> This approach does not solve the problem of different timescales
>> in modules. Therefore there is an additional option for iverilog &
>> ivlpp to override `timescale directives. This way all time
>> expressions use the same format and everything works as expected. I
>> guess it might be useful also for (System)Verilog simulations as
>> well.
> 
>> Regards, Orson
> 
>> 1. https://github.com/steveicarus/iverilog/pull/70 2.
>> https://github.com/orsonmmz/ivtest/tree/time_test
> 
>> On 05/23/2015 12:26 AM, Martin Whitaker wrote:
>>> Your second option is standard SystemVerilog, so that is the best
>>> way to go. For accuracy, you should probably store time constants
>>> as a mantissa + exponent.
>>>
>>> Martin
>>>
>>> Maciej Sumiński wrote:
>>>> Hi,
>>>>
>>>> I am looking for the best way to implement expressions related
>>>> to time in vhdlpp. Ideally, I would use SystemVerilog's time
>>>> literals, so:
>>>>
>>>> wait for 10 ns;
>>>>
>>>> is translated to:
>>>>
>>>> #10ns;
>>>>
>>>> This ought to be trivial with the current ivl version. The only
>>>> obstacle I face now is to support constants, like:
>>>>
>>>> constant a : time := 10 ns;
>>>>
>>>> The problem here is how to use them in SystemVerilog modules
>>>> that may have different time scales.
>>>>
>>>> * First option One solution that is easy for me to implement is
>>>> to prepare an Icarus-specific function that takes mantissa and
>>>> exponent to describe a time period:
>>>>
>>>> localparam a = $ivl_time(10, -9);
>>>>
>>>> Then during elaboration the value would be adjusted according
>>>> to the time scale of scope where it is used.
>>>>
>>>> * Second option While the first approach satisfies my needs,
>>>> there might be a solution that you find more advantageous. It
>>>> also does not introduce any Icarus-specific functions.
>>>>
>>>> Though it is not available at the moment, it should be fairly
>>>> easy to make localparam accept time literals, so the initial
>>>> example becomes:
>>>>
>>>> localparam a = 10ns;
>>>>
>>>> but the current implementation stores time as floating point
>>>> numbers adjusted to the time scale of the scope where a delay
>>>> was defined [1].
>>>>
>>>> In order to use a localparam value in a scope that uses a
>>>> different time scale, the absolute time value has to be
>>>> preserved and adjusted during elaboration (just like $ivl_time
>>>> would do). To do so, I may either introduce a new type
>>>> (veritime?), or assume time values are saved in femtoseconds.
>>>>
>>>> Do you have any thoughts/preference?
>>>>
>>>> Regards, Orson
>>>>
>>>> 1.
>>>> https://github.com/steveicarus/iverilog/blob/master/parse.y#L2782
> 
> 
> 
> 

Re: [Iverilog-devel] Time in VHDL

[Cary R. <cy...@ya...>]

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.

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).
Cary
 


     On Saturday, May 30, 2015 9:46 AM, Maciej Sumiński <mac...@ce...> wrote:
   

 Hi Steve,

Sorry, the message might have been a bit confusing. I use time literals,
I agree that is the right way to go. "wait for 10ns" simply becomes
"#10ns" and everything is clear.

Vhdlpp analyzes time literals used in a unit and stores the smallest
time unit in `timescale directive. To illustrate: if there are "wait for
30 ns" and "wait for 10 ps" statements, then the output is preceded with
"`timescale 1ps/1ps". I do not insist on merging this particular commit,
just thought it might be a better idea than using the default 1s/1s setting.

The main problem I had was caused by transferring time values via ports
between modules using different timescales. For example:
----------------------
`timescale 1ns/1ns
module mod(input time a);
  always @(a) begin
    #(a + 1ns) $display($time);
  end
endmodule

`timescale 1ps/1ps
module mod_test;
  time a;
  mod dut(a);
  initial begin
    a = 1ns;
  end
endmodule
----------------------
I would expect the code to display either "2" (ns) or "2000" (ps), but
the output is "1001". I checked it with another, very common simulator
and the result was the same.

I am trying to workaround the problem by overriding all `timescale
directives with one passed to iverilog command. Perhaps it could be
useful for pure (System)Verilog simulations as well.

Regards,
Orson

On 05/29/2015 09:53 PM, Stephen Williams wrote:
> 
> Hmm... I haven't been paying attention, so forgive me while I try
> to catch up.
> 
> As for using VHDL constants that are time values, is there a reason
> you cannot translate them to SystemVerilog time literals? Those are
> valid and correct no matter the `timescale setting for a given module.
> That is why they were invented for SystemVerilog.
> 
> On 05/29/2015 09:34 AM, Maciej Sumiński wrote:
>> Hi,
> 
>> I have managed to implement time and wait for/on/until statements
>> in vhdlpp [1] with tests [2].
> 
>> I have chosen yet another way that seems much simpler. By default
>> vhdlpp analyzes time expressions used in the processed file and
>> then stores the required time precision in `timescale directive.
> 
>> This approach does not solve the problem of different timescales
>> in modules. Therefore there is an additional option for iverilog &
>> ivlpp to override `timescale directives. This way all time
>> expressions use the same format and everything works as expected. I
>> guess it might be useful also for (System)Verilog simulations as
>> well.
> 
>> Regards, Orson
> 
>> 1. https://github.com/steveicarus/iverilog/pull/70 2.
>> https://github.com/orsonmmz/ivtest/tree/time_test
> 
>> On 05/23/2015 12:26 AM, Martin Whitaker wrote:
>>> Your second option is standard SystemVerilog, so that is the best
>>> way to go. For accuracy, you should probably store time constants
>>> as a mantissa + exponent.
>>>
>>> Martin
>>>
>>> Maciej Sumiński wrote:
>>>> Hi,
>>>>
>>>> I am looking for the best way to implement expressions related
>>>> to time in vhdlpp. Ideally, I would use SystemVerilog's time
>>>> literals, so:
>>>>
>>>> wait for 10 ns;
>>>>
>>>> is translated to:
>>>>
>>>> #10ns;
>>>>
>>>> This ought to be trivial with the current ivl version. The only
>>>> obstacle I face now is to support constants, like:
>>>>
>>>> constant a : time := 10 ns;
>>>>
>>>> The problem here is how to use them in SystemVerilog modules
>>>> that may have different time scales.
>>>>
>>>> * First option One solution that is easy for me to implement is
>>>> to prepare an Icarus-specific function that takes mantissa and
>>>> exponent to describe a time period:
>>>>
>>>> localparam a = $ivl_time(10, -9);
>>>>
>>>> Then during elaboration the value would be adjusted according
>>>> to the time scale of scope where it is used.
>>>>
>>>> * Second option While the first approach satisfies my needs,
>>>> there might be a solution that you find more advantageous. It
>>>> also does not introduce any Icarus-specific functions.
>>>>
>>>> Though it is not available at the moment, it should be fairly
>>>> easy to make localparam accept time literals, so the initial
>>>> example becomes:
>>>>
>>>> localparam a = 10ns;
>>>>
>>>> but the current implementation stores time as floating point
>>>> numbers adjusted to the time scale of the scope where a delay
>>>> was defined [1].
>>>>
>>>> In order to use a localparam value in a scope that uses a
>>>> different time scale, the absolute time value has to be
>>>> preserved and adjusted during elaboration (just like $ivl_time
>>>> would do). To do so, I may either introduce a new type
>>>> (veritime?), or assume time values are saved in femtoseconds.
>>>>
>>>> Do you have any thoughts/preference?
>>>>
>>>> Regards, Orson
>>>>
>>>> 1.
>>>> https://github.com/steveicarus/iverilog/blob/master/parse.y#L2782
> 
> 
> 
> 


------------------------------------------------------------------------------

_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel


  

Re: [Iverilog-devel] Time in VHDL

[Martin W. <mai...@ma...>]

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'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).

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).

Martin

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

Re: [Iverilog-devel] Time in VHDL

[Martin W. <mai...@ma...>]

Maciej Sumiński wrote:
> 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.

The difference is that by using `resetall and +timescale, the user can 
override the default if it is wrong for their design. A quick glance indicates 
this is what other simulators do for VHDL designs.

With a default time scale/precision of 1ps/1ps, a 64-bit time value can 
represent a delay range of 1ps to 2500 hours, which is likely to cover most 
users needs.

The other simulators I've looked at all default to a precision of 1fs for VHDL 
designs.

> It also means that problem would
> persist for SV modules with their own timescales.

Yes, but native SV modules would expect time variables to contain scaled 
times, because SV doesn't support anything else. If a user is doing mixed-mode 
simulation, they have to take this into account.

Martin

Re: [Iverilog-devel] Time in VHDL

[Stephen W. <st...@ic...>]

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


System Verilog also allows for per-module timescales. Instead of
using a compiler directive (which has awful scoping rules) there
are the timescale and related keywords that can be included as
module items. Perhaps this is what is needed?

On 05/30/2015 12: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'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).
> 
> 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).
> 
> Martin
> 
> ------------------------------------------------------------------------------
>
> 
_______________________________________________
> 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

iEYEARECAAYFAlVrNI0ACgkQrPt1Sc2b3inhowCeJrfVR9Jgt8v/S9yfRHP4ivGl
y9AAoMmACgeOR7v578zGL52x1r7+Ou24
=hu6d
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Time in VHDL

[Martin W. <mai...@ma...>]

Stephen Williams wrote:
> System Verilog also allows for per-module timescales. Instead of
> using a compiler directive (which has awful scoping rules) there
> are the timescale and related keywords that can be included as
> module items. Perhaps this is what is needed?

Doesn't really help. The SV per-module timescales don't let you do anything 
you can't do with `timescale - they just have better scoping rules (allowing 
`timescale to persist beyond a compilation unit was just insane).

VHDL doesn't have any concept of timescale and has a default time resolution 
of 1fs. So to mimic VHDL behaviour, all the translated code should have a 
timescale of 1fs/1fs. This would allow time values to be freely passed between 
modules in the translated code.

However, with that timescale, the largest time that can be represented in 64 
bits is ~2.5 hours. To get round this (and to avoid slowdown due to 
unnecessary precision), the VHDL standard allows a different time resolution 
to be specified when a model is elaborated. Other simulators support this via 
a configuration file or command line option. Hence my suggestion to use 
`resetall at the start of each translated compilation unit and use the 
existing iverilog +timescale option to set the default timescale.

Martin

Re: [Iverilog-devel] Time in VHDL

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

On 05/31/2015 09:09 PM, Martin Whitaker wrote:
[..]
> However, with that timescale, the largest time that can be represented in 64 
> bits is ~2.5 hours. To get round this (and to avoid slowdown due to 
> unnecessary precision), the VHDL standard allows a different time resolution 
> to be specified when a model is elaborated. Other simulators support this via 
> a configuration file or command line option. Hence my suggestion to use 
> `resetall at the start of each translated compilation unit and use the 
> existing iverilog +timescale option to set the default timescale.
> 
> Martin

Ok, I think this actually fulfills my needs. Thank you for the
suggestion and explanation.

Steve, what is your opinion? Shall I remove the option to specify
timescale as a iverilog parameter [1] and replace matching timescale for
VHDL files [2] with default `resetall directive?

Regards,
Orson

1.
https://github.com/orsonmmz/iverilog/commit/06864ebd3fbc38f4e2daffcc2d20092c73066da3
2.
https://github.com/orsonmmz/iverilog/commit/250253baf085bf6426eca6b73c03ca78ed584f5e

Re: [Iverilog-devel] Time in VHDL

[Cary R. <cy...@ya...>]

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. You can then translate the time variables using the local module time scale and the calling module time scale. Depending on the scope of the translation routine (VPI call) the parent of the current scope my not be the calling parent. You first have to find the current module and then the calling module (i.e. iterate up the scope chain looking for a module scope). There should be example code in the "vpi" directory somewhere of this type of search.

 



     On Monday, June 1, 2015 12:56 AM, Maciej Sumiński <mac...@ce...> wrote:
   

 On 05/31/2015 09:09 PM, Martin Whitaker wrote:
[..]
> However, with that timescale, the largest time that can be represented in 64 
> bits is ~2.5 hours. To get round this (and to avoid slowdown due to 
> unnecessary precision), the VHDL standard allows a different time resolution 
> to be specified when a model is elaborated. Other simulators support this via 
> a configuration file or command line option. Hence my suggestion to use 
> `resetall at the start of each translated compilation unit and use the 
> existing iverilog +timescale option to set the default timescale.
> 
> Martin

Ok, I think this actually fulfills my needs. Thank you for the
suggestion and explanation.

Steve, what is your opinion? Shall I remove the option to specify
timescale as a iverilog parameter [1] and replace matching timescale for
VHDL files [2] with default `resetall directive?

Regards,
Orson

1.
https://github.com/orsonmmz/iverilog/commit/06864ebd3fbc38f4e2daffcc2d20092c73066da3
2.
https://github.com/orsonmmz/iverilog/commit/250253baf085bf6426eca6b73c03ca78ed584f5e

------------------------------------------------------------------------------

_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel


  

Re: [Iverilog-devel] Time in VHDL

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

Hi Cary,

On 06/01/2015 04:52 PM, 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 have just checked it, but apparently the idea I have implemented had
been rejected previously [1], so I believe I need to retract the
corresponding patch.

> 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. You can then translate the time variables using the local module time scale and the calling module time scale. Depending on the scope of the translation routine (VPI call) the parent of the current scope my not be the calling parent. You first have to find the current module and then the calling module (i.e. iterate up the scope chain looking for a module scope). There should be example code in the "vpi" directory somewhere of this type of search.

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.

We just need to decide which changes related to timescale handling are
welcome and I am going to remove the rest.

Regards,
Orson

>      On Monday, June 1, 2015 12:56 AM, Maciej Sumiński <mac...@ce...> wrote:
>    
> 
>  On 05/31/2015 09:09 PM, Martin Whitaker wrote:
> [..]
>> However, with that timescale, the largest time that can be represented in 64 
>> bits is ~2.5 hours. To get round this (and to avoid slowdown due to 
>> unnecessary precision), the VHDL standard allows a different time resolution 
>> to be specified when a model is elaborated. Other simulators support this via 
>> a configuration file or command line option. Hence my suggestion to use 
>> `resetall at the start of each translated compilation unit and use the 
>> existing iverilog +timescale option to set the default timescale.
>>
>> Martin
> 
> Ok, I think this actually fulfills my needs. Thank you for the
> suggestion and explanation.
> 
> Steve, what is your opinion? Shall I remove the option to specify
> timescale as a iverilog parameter [1] and replace matching timescale for
> VHDL files [2] with default `resetall directive?
> 
> Regards,
> Orson
> 
> 1.
> https://github.com/orsonmmz/iverilog/commit/06864ebd3fbc38f4e2daffcc2d20092c73066da3
> 2.
> https://github.com/orsonmmz/iverilog/commit/250253baf085bf6426eca6b73c03ca78ed584f5e
> 
> ------------------------------------------------------------------------------
> 
> _______________________________________________
> 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
> 

Re: [Iverilog-devel] Time in VHDL

[Stephen W. <st...@ic...>]

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

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.

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.

- -- 
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

iEYEARECAAYFAlVsehwACgkQrPt1Sc2b3ilIfwCghJ+EHg+uDOLHwBABZ+4ONwZi
PTUAnjvLxnCPYptkz3TjoHvwSFPCjPEP
=bB9o
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Time in VHDL

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

On 06/01/2015 05:28 PM, Stephen Williams wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 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.
> 
> - -- 
> 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
> 
> iEYEARECAAYFAlVsehwACgkQrPt1Sc2b3ilIfwCghJ+EHg+uDOLHwBABZ+4ONwZi
> PTUAnjvLxnCPYptkz3TjoHvwSFPCjPEP
> =bB9o
> -----END PGP SIGNATURE-----
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
> 

Re: [Iverilog-devel] Time in VHDL

[Stephen W. <st...@ic...>]

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


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. 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.

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
> 

- -- 
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

iEYEARECAAYFAlVshbEACgkQrPt1Sc2b3imgrACgiI/PZcK7XDkCAU8+LYoFSVqQ
fCoAn1OE4Gpn32q1lW8GpvPGrCMteQ0i
=bi2S
-----END PGP SIGNATURE-----

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
> 

Re: [Iverilog-devel] Time in VHDL

[Martin W. <mai...@ma...>]

Maciej Sumiński wrote:
> 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
>
Small correction. 'time' is just an unsigned integer number (at least 64 bits 
in standard Verilog, exactly 64 bits in SystemVerilog). 'realtime' is just a 
real number.

> 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.
>
Exactly right.

Martin

Re: [Iverilog-devel] Time in VHDL

[Martin W. <mai...@ma...>]

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

Re: [Iverilog-devel] Time in VHDL

[Stephen W. <st...@ic...>]

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


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.

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
> 


- -- 
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

iEYEARECAAYFAlVsuRMACgkQrPt1Sc2b3imxhACeK57IA566tilSJp0Iq1dUbb0k
erMAoM6DDuzq9lp+jbmwSqLsfeO6k93k
=7cGW
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Time in VHDL

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

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
> 

Re: [Iverilog-devel] Time in VHDL

[Stephen W. <st...@ic...>]

-----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-----

Re: [Iverilog-devel] Time in VHDL

[Martin W. <mai...@ma...>]

Stephen Williams wrote:
> 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.
>
The SystemVerilog committee has already done this for you. See section 23.3.3 
of 1800-2012:

"Values of all data types on variables and nets can be passed through ports. 
This is accomplished by allowing both sides of a port connection to have 
assignment-compatible data types and by allowing continuous assignments to 
variables."

So it is now legal to declare:

   module m(input time t);

You can also declare:

   module m(ref time t);

which lets you share a common variable.

Martin

Re: [Iverilog-devel] Time in VHDL

[Stephen W. <st...@ic...>]

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


That shares the literal bits that are the time value, but it
does not account for the semantics of time. If it did, it would
scale time values to local units as they cross module boundaries.
That is the crux of the problem that Orson is facing.

On 06/05/2015 12:24 PM, Martin Whitaker wrote:
> Stephen Williams wrote:
>> 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.
>> 
> The SystemVerilog committee has already done this for you. See
> section 23.3.3 of 1800-2012:
> 
> "Values of all data types on variables and nets can be passed
> through ports. This is accomplished by allowing both sides of a
> port connection to have assignment-compatible data types and by
> allowing continuous assignments to variables."
> 
> So it is now legal to declare:
> 
> module m(input time t);
> 
> You can also declare:
> 
> module m(ref time t);
> 
> which lets you share a common variable.
> 
> Martin
> 
> ------------------------------------------------------------------------------
>
> 
_______________________________________________
> 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

iEYEARECAAYFAlVx/Q8ACgkQrPt1Sc2b3inIcACcC/7OfbA8m0H6rwnTEfM9373C
wK8AnR6I3Ykl3pdzG8a/6OaodNWXMELG
=fUjY
-----END PGP SIGNATURE-----