iverilog-devel — Conversations on matters of Icarus Verilog development

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

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

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

[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

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

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

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

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

[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

[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

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

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

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

[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] Assertion failure for system verilog structs

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

ni...@ly... (Niels Möller) wrote:
> running on a debian gnu/linux box, x86_64. First I got compilation
> failures with
>
>    ex.vl:1: assert: pform_struct_type.cc:83: failed assertion 0
>    Aborted
>
> Looking up that line, it seems non-packed structs are not yet supported
> (an error message saying so would be nicer than an assert...).

Rather belatedly, I've now added a proper error message for this.

Martin

Re: [Iverilog-devel] Icarus Verilog Snapshot 20150513

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

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


There is a .spec file in the .tar.gz file, so you can use rpmbuild
directly, like so:

  rpmbuild -ta iverilog-20150513.tar.gz

If you really only want to make a .src.rpm, you can:

  rpmbuild -ts iverilog-20150513.tar.g

If that doesn't work, let me know.

On 05/14/2015 09:09 AM, Lonnie L Gliem wrote:
> Will you make a source rpm for this in the same place? Or is there
> a simple way I can?
> 
> -----Original Message----- From: Stephen Williams
> [mailto:st...@ic...] Sent: Wednesday, May 13, 2015 12:36 PM 
> To: Discussions concerning Icarus Verilog development Subject:
> [Iverilog-devel] Icarus Verilog Snapshot 20150513
> 
> 
> I'm still thinking in terms of making a version 10 soon, but I've
> made a snapshot first, here:
> 
> ftp://ftp.icarus.com/pub/eda/verilog/snapshots/iverilog-20150513.tar.gz
>
>  This is simply a dump of what was at the head of the master
> branch. There are a few issues with the vhdl support, but in
> general this should give a good idea of what's going to be in the
> release.
> 
> Maybe the weekend of May 23/24 I may create a release branch?
> 
> 
> ----------------------------------------------------------------------------
>
> 
- --
> 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
> 

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

iEYEARECAAYFAlVU0PoACgkQrPt1Sc2b3imM5ACgj7z3M21F1mgUF8sy1ny3RBJy
EY4An0iKQY9o6i00yXZbv35LdUPAI5zP
=8ILj
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Icarus Verilog Snapshot 20150513

[Lonnie L G. <lg...@sr...>]

Will you make a source rpm for this in the same place? Or is there a simple
way I can? 

-----Original Message-----
From: Stephen Williams [mailto:st...@ic...] 
Sent: Wednesday, May 13, 2015 12:36 PM
To: Discussions concerning Icarus Verilog development
Subject: [Iverilog-devel] Icarus Verilog Snapshot 20150513

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


I'm still thinking in terms of making a version 10 soon, but I've made a
snapshot first, here:

ftp://ftp.icarus.com/pub/eda/verilog/snapshots/iverilog-20150513.tar.gz

This is simply a dump of what was at the head of the master branch.
There are a few issues with the vhdl support, but in general this should
give a good idea of what's going to be in the release.

Maybe the weekend of May 23/24 I may create a release branch?

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

iEYEARECAAYFAlVTi2MACgkQrPt1Sc2b3inuOwCbBoIrPsPFZJT2RXvEMZP/hGdg
/ToAniYOnGkt234tM9sKjy9DCLpgZwro
=Riyh
-----END PGP SIGNATURE-----

----------------------------------------------------------------------------
--
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] Icarus Verilog Snapshot 20150513

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

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


There is a problem in that bit of code where if the copy contructor
is called, the LineInfo may not work properly. That is one thing
that should be fixed. That can be done either by not implementing
the referenced copy constructor at all (to assure that it cannot
be called) or implement a LineInfo copy constructor.

I think Orson will need to look into it.

On 05/13/2015 04:30 PM, Cary R. wrote:
> Hi Larry,
> 
> I test on various systems and only the RHEL 5 system has this
> warning. It could be a bogus warning (e.g. the copy constructor is
> never actually called), but it would be nice if it was not there so
> we have a clean compile on the common systems.
> 
> Cary
> 
> 
> 
> On Wednesday, May 13, 2015 4:18 PM, Larry Doolittle 
> <ldo...@re...> wrote:
> 
> 
> Cary -
> 
> The oldest gcc I have readily available is 4.4.5, on Debian
> oldoldstable (Squeeze LTS).  It does not give the referenced
> warning.
> 
> - Larry
> 
> On Wed, May 13, 2015 at 10:16:32PM +0000, Cary R. wrote:
>> This is on Red Hat Enterprise 5 64-bit which has gcc-4.1.2. I am
>> using
> the normal  warning flags. Centos 5, etc. should give same
> environment.
>> 
>> On Wednesday, May 13, 2015 12:11 PM, Maciej Sumi?ski
> <mac...@ce... <mailto:mac...@ce...>> wrote:
>> Thank you for the information. Which compiler do you use or what
>> flags cause the warning to appear? I have tried gcc 4.9.2/5.1.0 &
>> clang 3.6.0 (all 64 bits) and none of them have displayed the
>> message.
>> 
>> 
>> On 05/13/2015 08:59 PM, Cary R. wrote:
>>> One thing I see when compiling under RHEL5 64-bit is I get the
> following warning:
>>> expression.cc: In copy constructor
> ‘ExpConditional::else_t::else_t(const ExpConditional::else_t&)’:
>>> expression.cc:313: warning: base class ‘class LineInfo’ should
>>> be
> explicitly initialized in the copy constructor
> 
> 
> 
> 
> ------------------------------------------------------------------------------
>
> 
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
> 


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

iEYEARECAAYFAlVUuRUACgkQrPt1Sc2b3im0iwCg4FeuPSxH3UNnIPS44KS3/5Sp
GFAAn1ctlD9KGxv273kix3da4DNxH4Ap
=jsFB
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Icarus Verilog Snapshot 20150513

[Larry D. <ldo...@re...>]

Cary -

The oldest gcc I have readily available is 4.4.5, on Debian oldoldstable
(Squeeze LTS).  It does not give the referenced warning.

 - Larry

On Wed, May 13, 2015 at 10:16:32PM +0000, Cary R. wrote:
> This is on Red Hat Enterprise 5 64-bit which has gcc-4.1.2. I am using the normal  warning flags. Centos 5, etc. should give same environment.
> 
>      On Wednesday, May 13, 2015 12:11 PM, Maciej Sumiński <mac...@ce...> wrote:
> Thank you for the information. Which compiler do you use or what flags
> cause the warning to appear? I have tried gcc 4.9.2/5.1.0 & clang 3.6.0
> (all 64 bits) and none of them have displayed the message.
> 
> 
> On 05/13/2015 08:59 PM, Cary R. wrote:
> > One thing I see when compiling under RHEL5 64-bit is I get the following warning:
> > expression.cc: In copy constructor ‘ExpConditional::else_t::else_t(const ExpConditional::else_t&)’:
> > expression.cc:313: warning: base class ‘class LineInfo’ should be explicitly initialized in the copy constructor

Re: [Iverilog-devel] Icarus Verilog Snapshot 20150513

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

Hi Larry,
I test on various systems and only the RHEL 5 system has this warning. It could be a bogus warning (e.g. the copy constructor is never actually called), but it would be nice if it was not there so we have a clean compile on the common systems.
Cary 


     On Wednesday, May 13, 2015 4:18 PM, Larry Doolittle <ldo...@re...> wrote:
   

 Cary -

The oldest gcc I have readily available is 4.4.5, on Debian oldoldstable
(Squeeze LTS).  It does not give the referenced warning.

 - Larry

On Wed, May 13, 2015 at 10:16:32PM +0000, Cary R. wrote:
> This is on Red Hat Enterprise 5 64-bit which has gcc-4.1.2. I am using the normal  warning flags. Centos 5, etc. should give same environment.
> 
>      On Wednesday, May 13, 2015 12:11 PM, Maciej Sumiński <mac...@ce...> wrote:
> Thank you for the information. Which compiler do you use or what flags
> cause the warning to appear? I have tried gcc 4.9.2/5.1.0 & clang 3.6.0
> (all 64 bits) and none of them have displayed the message.
> 
> 
> On 05/13/2015 08:59 PM, Cary R. wrote:
> > One thing I see when compiling under RHEL5 64-bit is I get the following warning:
> > expression.cc: In copy constructor ‘ExpConditional::else_t::else_t(const ExpConditional::else_t&)’:
> > expression.cc:313: warning: base class ‘class LineInfo’ should be explicitly initialized in the copy constructor


  

Re: [Iverilog-devel] Icarus Verilog Snapshot 20150513

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

Hi Steve,
You may want to double check that your machines has all the patches. For me I only get expected fails for devel, strinct and vlog95 which all exercise the development branch. I just pushed new expected results file that have the latest VHDL tests, but there were no failures, just passing tests that were not in the expected result files.
>From my perspective we have compile warnings that need to be addressed and a few bugs that really should be taken care of if possible before the release, but I do not see any unexpected test failures.
Cary 


     On Wednesday, May 13, 2015 12:52 PM, Stephen Williams <st...@ic...> wrote:
   

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

There are a few VHDL tests in the ivtest suite that fail. It's
possible that it's simply a matter of the ivtest not being updated
after I pulled a couple of your patches.

On 05/13/2015 11:44 AM, Maciej Sumi?ski wrote:
> On 05/13/2015 07:35 PM, Stephen Williams wrote:
>> 
>> I'm still thinking in terms of making a version 10 soon, but
>> I've made a snapshot first, here:
>> 
>> ftp://ftp.icarus.com/pub/eda/verilog/snapshots/iverilog-20150513.tar.gz
>>
>>
>> 
This is simply a dump of what was at the head of the master branch.
>> There are a few issues with the vhdl support, but in general
>> this should give a good idea of what's going to be in the
>> release.
> 
> Hi Steve,
> 
> What are the problems related to the VHDL support? Perhaps I could
> fix them before the new release. I have just run the test suite and
> there were no tests broken.
> 
> Regards, Orson
> 
>> Maybe the weekend of May 23/24 I may create a release branch?
>> 
>> 
>> ------------------------------------------------------------------------------
>>
>> 
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
> 


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

iEYEARECAAYFAlVTqzwACgkQrPt1Sc2b3il9KgCg5t7kuU7AI6cD0TVrEd7PCaX8
+McAnRGb9iWlwS4BXTqP0gGhGjo+7x/+
=sNp1
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
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] Icarus Verilog Snapshot 20150513

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

This is on Red Hat Enterprise 5 64-bit which has gcc-4.1.2. I am using the normal  warning flags. Centos 5, etc. should give same environment.
Cary 


     On Wednesday, May 13, 2015 12:11 PM, Maciej Sumiński <mac...@ce...> wrote:
   

 Hi Cary,

Thank you for the information. Which compiler do you use or what flags
cause the warning to appear? I have tried gcc 4.9.2/5.1.0 & clang 3.6.0
(all 64 bits) and none of them have displayed the message.

Regards,
Orson

On 05/13/2015 08:59 PM, Cary R. wrote:
> One thing I see when compiling under RHEL5 64-bit is I get the following warning:
> expression.cc: In copy constructor ‘ExpConditional::else_t::else_t(const ExpConditional::else_t&)’:
> expression.cc:313: warning: base class ‘class LineInfo’ should be explicitly initialized in the copy constructor
> Cary 
> 
> 
> 
>      On Wednesday, May 13, 2015 11:44 AM, Maciej Sumiński <mac...@ce...> wrote:
>    
> 
>  On 05/13/2015 07:35 PM, Stephen Williams wrote:
>>
>> I'm still thinking in terms of making a version 10 soon, but I've
>> made a snapshot first, here:
>>
>> ftp://ftp.icarus.com/pub/eda/verilog/snapshots/iverilog-20150513.tar.gz
>>
>> This is simply a dump of what was at the head of the master branch.
>> There are a few issues with the vhdl support, but in general this
>> should give a good idea of what's going to be in the release.
> 
> Hi Steve,
> 
> What are the problems related to the VHDL support? Perhaps I could fix
> them before the new release. I have just run the test suite and there
> were no tests broken.
> 
> Regards,
> Orson
> 
>> Maybe the weekend of May 23/24 I may create a release branch?
>>
>>
>> ------------------------------------------------------------------------------
>> 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
> 
> 
>  
> 
> 
> 
> ------------------------------------------------------------------------------
> 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] periodic updating of vcd file

[Joshua S. <kni...@gm...>]

gosh so sorry to bother this newsgroup with my noobness. I manually checked
the file size from the C code and realized that the file does flush
correct, but windows doesn't update its file sizes. Supposedly a feature of
NTFS
http://blogs.msdn.com/b/oldnewthing/archive/2011/12/26/10251026.aspx

So in my C# code when I checked to see whether the file size changed, I was
getting nothing.  Now I know that I just need to manually check the file
size instead of using the function I called in C# and I should be able to
check if anything has changed.

Thanks,


Josh

On Wed, May 13, 2015 at 3:16 PM, Joshua Street <kni...@gm...>
wrote:

> I don't think I need it to output every simulation time step. I just don't
> think it's flushing at all. The flush call returns true, but the file size
> hasn't changed. I am not at all sure what is going on. I will try to play
> with it a bit more. Otherwise, the only other solution I can think of is to
> just close the file handle and reopen it, which definitely is updating the
> vcd properly
>
> On Wed, May 13, 2015 at 2:52 PM, Cary R. <cy...@ya...> wrote:
>
>> Getting this back on the development list.
>>
>> Yes, VCD output is only output at the end of the simulation time step. It
>> is not done interactively as the values change otherwise you would have a
>> huge amount of excess data as values stabilize to their final value. I
>> would not call this from the scheduler, but if needed do it as a final step
>> when emitting VCD output for a given time step. I believe that is at the
>> end of the variable_cb_2() call back routine.
>>
>> Cary
>>
>>
>>
>>   On Wednesday, May 13, 2015 11:43 AM, Joshua Street <
>> kni...@gm...> wrote:
>>
>>
>> so I think I'm still confused as to how to call the vpi callback
>> functions from within schedule.cc.
>>
>> I thought that since these two functions were called in stop.cc that I
>> could also call these and have it immediately flush.
>>
>>  invoke_command_const("$fflush");
>>  invoke_command_const("$dumpflush");
>>
>> However, I think flush is the command I want. The only problem is that it
>> doesn't seem to execute flush immediately.
>>
>> I'm guessing from trying to read the source that a callback handler is
>> registered and that it is later called when vpiPostSim takes place.
>>
>>
>>
>>
>>
>>
>>
>

Re: [Iverilog-devel] Icarus Verilog Snapshot 20150513

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

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


That looks like a real problem. I'm surprised that copy
contructors are being called at all, but given that they
are, there is a real need for the LineInfo class to handle
that. There is a bug somewhere.

On 05/13/2015 11:59 AM, Cary R. wrote:
> One thing I see when compiling under RHEL5 64-bit is I get the
> following warning:
> 
> expression.cc: In copy constructor
> ‘ExpConditional::else_t::else_t(const ExpConditional::else_t&)’: 
> expression.cc:313: warning: base class ‘class LineInfo’ should be 
> explicitly initialized in the copy constructor


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

iEYEARECAAYFAlVTrO8ACgkQrPt1Sc2b3ik6iQCgzqkaDpR9xxRQB78U8xkpZONc
N8MAn2/j2L597iAKLbshu7hYtXVEsd1v
=ZDLm
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] periodic updating of vcd file

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

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

On 05/13/2015 11:52 AM, Cary R. wrote:
> I believe that is at the end of the variable_cb_2() call back
> routine.

If desperate, you could put a fflush() in here, but I will not
accept a patch that does this unconditionally. If you enabled
it with a +vcd-sync or some such plusarg, that is something I
would accept.

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

iEYEARECAAYFAlVTq7IACgkQrPt1Sc2b3ikjTACg3ECM8d9FXEgXFYIZn1aOQvto
IsoAoLoMMmD+R4trLeNJ0tI0X9/sfwto
=LBqY
-----END PGP SIGNATURE-----