iverilog-devel — Conversations on matters of Icarus Verilog development

Re: [Iverilog-devel] SystemVerilog functions via vhdlpp

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

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


Sounds good, send me a pull request when you feel ready.

On 03/22/2016 12:58 PM, Maciej Sumi?ski wrote:
> Hi Martin,
> 
> I see your point, I had overlooked the always block. I agree it has
> to be changed, and patches in the automatic_rebased branch should
> fix the problem.
> 
> Regards, Orson
> 
> On 03/22/2016 08:30 PM, Martin Whitaker wrote:
>> Hi Orson,
>> 
>> Maciej Sumi?ski wrote:
>>> I presume you talk about vhdl_string & vhdl_image_attr tests.
>>> The variables causing warnings are initialized inside a module
>>> scope. If I understand the standard correctly (6.21 @
>>> 1800-2012), it is not required to explicitly declare such
>>> variables as static, because it is illegal for them to be
>>> automatic (see an example on p.91 @ 1800-2012).
>> 
>> Yes, those are the tests I was talking about. Taking
>> vhdl_image_attr as an example, the relevant part of the vhdlpp
>> output is:
>> 
>> always begin : __scope_1 bit[32'd7:32'd0] var_char   = "o"; int
>> var_int   = 32'd10; real var_real   = 12.34; time var_time   =
>> 10ns; ...
>> 
>> These variables are declared inside a begin/end block, so
>> SystemVerilog permits them to be declared as static or automatic,
>> hence the rule about having an explicit static keyword applies.
>> The equivalent example on page 91 of 1800-2012 is
>> 
>> initial begin int svar2 = 2; // static/automatic needed to show
>> intent ...
>> 
>> To be sure I'm reading the standard correctly, I tried this
>> example
>> 
>> module test();
>> 
>> integer legal = 1;
>> 
>> initial begin: named_block integer illegal = 1; end
>> 
>> endmodule
>> 
>> on another simulator. It accepted the declaration of 'legal' and
>> warned that the declaration of 'illegal' required an explicit
>> 'static' keyword.
>> 
>>> Anyway, if you would rather vhdlpp emit lifetime for each
>>> variable, I pushed a fix to automatic_rebased branch [1] on
>>> github. It also contains patches to make Larry's use_func test
>>> case work and passes all the tests, so feel free to merge it.
>> 
>> I'll leave this for Steve.
>> 
>> Regards,
>> 
>> Martin
>> 
>> ------------------------------------------------------------------------------
>>
>> 
Transform Data into Opportunity.
>> Accelerate data analysis in your applications with Intel Data
>> Analytics Acceleration Library. Click to learn more. 
>> http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140 
>> _______________________________________________ Iverilog-devel
>> mailing list Ive...@li... 
>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>> 
> 
> 
> 
> ------------------------------------------------------------------------------
>
> 
Transform Data into Opportunity.
> Accelerate data analysis in your applications with Intel Data
> Analytics Acceleration Library. Click to learn more. 
> http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140
> 
> 
> 
> _______________________________________________ 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

iEYEARECAAYFAlbxqWkACgkQrPt1Sc2b3ing5ACfTHwD/TJB49cXB8lK047Qtg7W
go4AoNcAAoZogA7GuqcUEdaM2H2I/PCx
=MyTm
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] SystemVerilog functions via vhdlpp

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

Hi Martin,

I see your point, I had overlooked the always block. I agree it has to
be changed, and patches in the automatic_rebased branch should fix the
problem.

Regards,
Orson

On 03/22/2016 08:30 PM, Martin Whitaker wrote:
> Hi Orson,
> 
> Maciej Sumiński wrote:
>> I presume you talk about vhdl_string & vhdl_image_attr tests. The
>> variables causing warnings are initialized inside a module scope. If I
>> understand the standard correctly (6.21 @ 1800-2012), it is not required
>> to explicitly declare such variables as static, because it is illegal
>> for them to be automatic (see an example on p.91 @ 1800-2012).
> 
> Yes, those are the tests I was talking about. Taking vhdl_image_attr as an example, the relevant 
> part of the vhdlpp output is:
> 
>    always begin : __scope_1
>      bit[32'd7:32'd0] var_char   = "o";
>      int var_int   = 32'd10;
>      real var_real   = 12.34;
>      time var_time   = 10ns;
>      ...
> 
> These variables are declared inside a begin/end block, so SystemVerilog permits them to be declared 
> as static or automatic, hence the rule about having an explicit static keyword applies. The 
> equivalent example on page 91 of 1800-2012 is
> 
>    initial begin
>      int svar2 = 2; // static/automatic needed to show intent
>      ...
> 
> To be sure I'm reading the standard correctly, I tried this example
> 
>    module test();
> 
>    integer legal = 1;
> 
>    initial begin: named_block
>      integer illegal = 1;
>    end
> 
>    endmodule
> 
> on another simulator. It accepted the declaration of 'legal' and warned that the declaration of 
> 'illegal' required an explicit 'static' keyword.
> 
>> Anyway, if you would rather vhdlpp emit lifetime for each variable, I
>> pushed a fix to automatic_rebased branch [1] on github. It also contains
>> patches to make Larry's use_func test case work and passes all the
>> tests, so feel free to merge it.
> 
> I'll leave this for Steve.
> 
> Regards,
> 
> Martin
> 
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
> 

Re: [Iverilog-devel] SystemVerilog functions via vhdlpp

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

Hi Orson,

Maciej Sumiński wrote:
> I presume you talk about vhdl_string & vhdl_image_attr tests. The
> variables causing warnings are initialized inside a module scope. If I
> understand the standard correctly (6.21 @ 1800-2012), it is not required
> to explicitly declare such variables as static, because it is illegal
> for them to be automatic (see an example on p.91 @ 1800-2012).

Yes, those are the tests I was talking about. Taking vhdl_image_attr as an example, the relevant 
part of the vhdlpp output is:

   always begin : __scope_1
     bit[32'd7:32'd0] var_char   = "o";
     int var_int   = 32'd10;
     real var_real   = 12.34;
     time var_time   = 10ns;
     ...

These variables are declared inside a begin/end block, so SystemVerilog permits them to be declared 
as static or automatic, hence the rule about having an explicit static keyword applies. The 
equivalent example on page 91 of 1800-2012 is

   initial begin
     int svar2 = 2; // static/automatic needed to show intent
     ...

To be sure I'm reading the standard correctly, I tried this example

   module test();

   integer legal = 1;

   initial begin: named_block
     integer illegal = 1;
   end

   endmodule

on another simulator. It accepted the declaration of 'legal' and warned that the declaration of 
'illegal' required an explicit 'static' keyword.

> Anyway, if you would rather vhdlpp emit lifetime for each variable, I
> pushed a fix to automatic_rebased branch [1] on github. It also contains
> patches to make Larry's use_func test case work and passes all the
> tests, so feel free to merge it.

I'll leave this for Steve.

Regards,

Martin

Re: [Iverilog-devel] SystemVerilog functions via vhdlpp

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

On 03/19/2016 10:33 PM, Martin Whitaker wrote:
> Martin Whitaker wrote:
[snip]
> @Orson - two of the VHDL tests now fail. To fix them, vhdlpp needs to explicitly declare variables 
> inside blocks as static when the declaration includes an initialisation expression.

Hi Martin,

I presume you talk about vhdl_string & vhdl_image_attr tests. The
variables causing warnings are initialized inside a module scope. If I
understand the standard correctly (6.21 @ 1800-2012), it is not required
to explicitly declare such variables as static, because it is illegal
for them to be automatic (see an example on p.91 @ 1800-2012).

Anyway, if you would rather vhdlpp emit lifetime for each variable, I
pushed a fix to automatic_rebased branch [1] on github. It also contains
patches to make Larry's use_func test case work and passes all the
tests, so feel free to merge it.

Regards,
Orson

1. https://github.com/orsonmmz/iverilog/tree/automatic_rebased

[Iverilog-devel] VCD files comparator

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

Hi,

I had to compare HDL simulation results generated by a few simulators,
but unfortunately I could not find a piece of software that would handle
the files I got.

The main problem was the difference in handling buses: sometimes
reg[7:0] is saved as 8 single variables, sometimes as a 8-bit wide bus
(not to mention weirdness when handling multidimensional arrays).
Variable matching is usually done by lexical comparison, so it does not
work in such cases. As it has turned out, it was easier to write a new
comparator from scratch, rather than fix an existing one.

If you need something that resolves a similar problem, I encourage you
to take vcdiff [1] for a test drive. As it is still in testing phase,
please let me know if you find any issues.

Regards,
Orson

1. https://github.com/orsonmmz/vcdiff

Re: [Iverilog-devel] SystemVerilog functions via vhdlpp

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

Martin Whitaker wrote:
> I have a fix for variable initialisation in automatic functions (and tasks), which I will push once
> I've fixed some of the other issues.

I have pushed the fixes for these issues. Also included are:

   - if you select a SystemVerilog generation, variable initialisation
     specified as part of the declaration is now performed before any
     initial/always process is started (as required by the SystemVerilog
     standard)
   - default subroutine lifetimes are supported (in module/program/
     interface/package/class declarations)
   - tasks and functions can be explicitly declared as static
   - variables can be explicitly declared as static or automatic,
     although the compiler currently throws an error if the declaration
     is different to the default value
   - a warning is generated if static variables in tasks/functions/blocks
     are initialised in their declaration but not explicitly declared as
     static (IEEE1800 actually requires this to be an error, but I've
     made it a warning for now).

Do we want to backport these changes to v10? Currently v10 silently fails to run the variable 
initialisation in many cases.

@Orson - two of the VHDL tests now fail. To fix them, vhdlpp needs to explicitly declare variables 
inside blocks as static when the declaration includes an initialisation expression.

Re: [Iverilog-devel] SystemVerilog functions via vhdlpp

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

That sounds like a good explanation to me. I'm hoping very soon that work gets back to a more normal schedule so I an start to think about Icarus again.

Cary





On Tuesday, March 15, 2016 12:56 PM, Martin Whitaker <mai...@ma...> wrote:
Cary R. wrote:
> That vlog95 support could be for a few reasons. It used to work that way, I expected it to be
> supported since it is in the standard so added the appropriate support to match named blocks or
> something I don't remember. I'm not exactly sure which it was, but given the code/comments I
> would expect the first option since the comments are fairly explicit about how this should work
> for SV tasks/functions.

It appears that the compiler generates the initialisation code for tasks, but not for functions. 
There's a test in the test suite that checks the behaviour for tasks, which is no doubt why you 
supported this in the vlog95 target.


Martin

Re: [Iverilog-devel] SystemVerilog functions via vhdlpp

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

Maciej Sumiński wrote:
> Hi,
>
> Martin, thank you for the explanations. You are right, VHDL subprograms
> are automatic by default.
>
> Larry, there is a branch [1] that produces code in the way you have
> suggested. I believe the semantics is correct here.
>
> I had tried simply adding 'automatic' keyword to the function
> declaration, but it did not help. I am going to include the branch in
> the next pull request.

I have a fix for variable initialisation in automatic functions (and tasks), which I will push once 
I've fixed some of the other issues.

Martin

Re: [Iverilog-devel] SystemVerilog functions via vhdlpp

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

Cary R. wrote:
> That vlog95 support could be for a few reasons. It used to work that way, I expected it to be
> supported since it is in the standard so added the appropriate support to match named blocks or
> something I don't remember. I'm not exactly sure which it was, but given the code/comments I
> would expect the first option since the comments are fairly explicit about how this should work
> for SV tasks/functions.

It appears that the compiler generates the initialisation code for tasks, but not for functions. 
There's a test in the test suite that checks the behaviour for tasks, which is no doubt why you 
supported this in the vlog95 target.

Martin

Re: [Iverilog-devel] SystemVerilog functions via vhdlpp

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

Hi,

Martin, thank you for the explanations. You are right, VHDL subprograms
are automatic by default.

Larry, there is a branch [1] that produces code in the way you have
suggested. I believe the semantics is correct here.

I had tried simply adding 'automatic' keyword to the function
declaration, but it did not help. I am going to include the branch in
the next pull request.

Regards,
Orson

1. https://github.com/orsonmmz/iverilog/tree/automatic

On 03/14/2016 09:47 PM, Larry Doolittle wrote:
> Martin -
> 
> Thanks for looking into this.  I'm not much of a SystemVerilog
> standards guru.
> 
> On Mon, Mar 14, 2016 at 08:16:41PM +0000, Martin Whitaker wrote:
>> Extracting the rounded_down_power_of_two function from the output of vhdlpp and converting to a 
>> simple SystemVerilog test case gives:
>>
>>    module test();
>>
>>    function int rounded_down_power_of_two(input int value);
>>      int n = 32'd0;
>>      int temp = value;
>>      while (temp > 32'd1) begin
>>        temp = temp / 32'd2;
>>        n = n + 32'd1;
>>      end
>>      return n;
>>    endfunction
>>
>>    localparam value = rounded_down_power_of_two(34);
>>
>>    initial begin
>>      $display("%d", value);
>>    end
>>
>>    endmodule
>>
>> This is illegal, because [...]
> 
> Does the following version look better?  It does print "5".
> And Maciej, does it seem like it correctly captures the semantics
> of the original VHDL?
> 
> module test();
> 
> function int rounded_down_power_of_two(input int value);
>   int n; 
>   int temp; 
>   n = 32'd0;
>   temp = value;
>   while (temp > 32'd1) begin
>     temp = temp / 32'd2;
>     n = n + 32'd1;
>   end
>   return n;
> endfunction
> 
> localparam value = rounded_down_power_of_two(34);
> 
> initial begin
>   $display("%d", value);
> end
> 
> endmodule
> 
> It would be easier for vhdlpp to emit
>   int n; n = 32'd0;
>   int temp; temp = value;
> but that is not accepted by iverilog -g2005-sv.
> 
>    - Larry
> 
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
> 

Re: [Iverilog-devel] Standards Committees

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

Yes, I work for an IEEE-SA member company.

Cary





On Monday, March 14, 2016 12:15 AM, Kevin Cameron <iv...@gr...> wrote:

Does anybody on this reflector belong to an IEEE-SA member company?

Kev.


------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140

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

Re: [Iverilog-devel] SystemVerilog functions via vhdlpp

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

That vlog95 support could be for a few reasons. It used to work that way, I expected it to be supported since it is in the standard so added the appropriate support to match named blocks or something I don't remember. I'm not exactly sure which it was, but given the code/comments I would expect the first option since the comments are fairly explicit about how this should work for SV tasks/functions.

Cary



On Monday, March 14, 2016 2:48 PM, Martin Whitaker <mai...@ma...> wrote:



Larry Doolittle wrote:
> Friends -
>
> Just for fun, I added an additional test to this sample code.
>
> module test();
> function int rounded_down_power_of_two(input int value);
>   int n = 32'd0;
>   int temp;
>   //n = 32'd0;
>   temp = value;
>   while (temp > 32'd1) begin
>     temp = temp / 32'd2;
>     n = n + 32'd1;
>   end
>   return n;
> endfunction
> localparam value5 = rounded_down_power_of_two(34);
> localparam value3 = rounded_down_power_of_two(8);
> initial $display("%d %d", value5, value3);
> endmodule
>
> If n were considered static, I might expect this to print
>           5           8
> but in fact n seems to be initialized on every invocation
> (elaboration?) of rounded_down_power_of_two(), so it prints
>           5           3
> Martin, does this fit your understanding of how SystemVerilog
> is supposed to work?

Yes, because these are constant function calls, and there's a special rule for that:

"Constant function calls are evaluated at elaboration time. Their execution has no effect on the 
initial values of the variables used either at simulation time or among multiple invocations of a 
function at elaboration time. In each of these cases, the variables are initialized as they would be 
for normal simulation."

If you try

   $display("%d", rounded_down_power_of_two(34));
   $display("%d", rounded_down_power_of_two(8));

you will get

   5
   8

Having said that, I've just tried changing the initial value of n to 1, and it has no effect. The 
compiler doesn't seem to be generating the initialisation code. This is a bit of a surprise, as I 
was looking at the vlog95 target code generator at the weekend, and it has code to handle this case.


Martin


------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel

Re: [Iverilog-devel] SystemVerilog functions via vhdlpp

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

Larry Doolittle wrote:
> Friends -
>
> Just for fun, I added an additional test to this sample code.
>
> module test();
> function int rounded_down_power_of_two(input int value);
>   int n = 32'd0;
>   int temp;
>   //n = 32'd0;
>   temp = value;
>   while (temp > 32'd1) begin
>     temp = temp / 32'd2;
>     n = n + 32'd1;
>   end
>   return n;
> endfunction
> localparam value5 = rounded_down_power_of_two(34);
> localparam value3 = rounded_down_power_of_two(8);
> initial $display("%d %d", value5, value3);
> endmodule
>
> If n were considered static, I might expect this to print
>           5           8
> but in fact n seems to be initialized on every invocation
> (elaboration?) of rounded_down_power_of_two(), so it prints
>           5           3
> Martin, does this fit your understanding of how SystemVerilog
> is supposed to work?

Yes, because these are constant function calls, and there's a special rule for that:

"Constant function calls are evaluated at elaboration time. Their execution has no effect on the 
initial values of the variables used either at simulation time or among multiple invocations of a 
function at elaboration time. In each of these cases, the variables are initialized as they would be 
for normal simulation."

If you try

   $display("%d", rounded_down_power_of_two(34));
   $display("%d", rounded_down_power_of_two(8));

you will get

   5
   8

Having said that, I've just tried changing the initial value of n to 1, and it has no effect. The 
compiler doesn't seem to be generating the initialisation code. This is a bit of a surprise, as I 
was looking at the vlog95 target code generator at the weekend, and it has code to handle this case.

Martin

Re: [Iverilog-devel] SystemVerilog functions via vhdlpp

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

Larry Doolittle wrote:
> Martin -
>
> Thanks for looking into this.  I'm not much of a SystemVerilog
> standards guru.

Nor am I really - I mostly use traditional Verilog.

...
> Does the following version look better?  It does print "5".
> And Maciej, does it seem like it correctly captures the semantics
> of the original VHDL?
...
> function int rounded_down_power_of_two(input int value);
>   int n;
>   int temp;
>   n = 32'd0;
>   temp = value;
>   while (temp > 32'd1) begin
>     temp = temp / 32'd2;
>     n = n + 32'd1;
>   end
>   return n;
> endfunction
...

I think that's fine for this example. I'm not familiar with VHDL, but I'd guess it doesn't make 
variables static by default, so if a function contains any form of delay, vhdlpp should declare the 
emitted function to be automatic.

> It would be easier for vhdlpp to emit
>   int n; n = 32'd0;
>   int temp; temp = value;
> but that is not accepted by iverilog -g2005-sv.

Yes, SystemVerilog is like C - you can't mix declarations and statements.

Martin

Re: [Iverilog-devel] SystemVerilog functions via vhdlpp

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

Friends -

Just for fun, I added an additional test to this sample code.

module test();
function int rounded_down_power_of_two(input int value);
  int n = 32'd0;
  int temp;
  //n = 32'd0;
  temp = value;
  while (temp > 32'd1) begin
    temp = temp / 32'd2;
    n = n + 32'd1;
  end
  return n;
endfunction
localparam value5 = rounded_down_power_of_two(34);
localparam value3 = rounded_down_power_of_two(8);
initial $display("%d %d", value5, value3);
endmodule

If n were considered static, I might expect this to print
          5           8
but in fact n seems to be initialized on every invocation
(elaboration?) of rounded_down_power_of_two(), so it prints
          5           3
Martin, does this fit your understanding of how SystemVerilog
is supposed to work?

   - Larry

Re: [Iverilog-devel] SystemVerilog functions via vhdlpp

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

Martin -

Thanks for looking into this.  I'm not much of a SystemVerilog
standards guru.

On Mon, Mar 14, 2016 at 08:16:41PM +0000, Martin Whitaker wrote:
> Extracting the rounded_down_power_of_two function from the output of vhdlpp and converting to a 
> simple SystemVerilog test case gives:
> 
>    module test();
> 
>    function int rounded_down_power_of_two(input int value);
>      int n = 32'd0;
>      int temp = value;
>      while (temp > 32'd1) begin
>        temp = temp / 32'd2;
>        n = n + 32'd1;
>      end
>      return n;
>    endfunction
> 
>    localparam value = rounded_down_power_of_two(34);
> 
>    initial begin
>      $display("%d", value);
>    end
> 
>    endmodule
> 
> This is illegal, because [...]

Does the following version look better?  It does print "5".
And Maciej, does it seem like it correctly captures the semantics
of the original VHDL?

module test();

function int rounded_down_power_of_two(input int value);
  int n; 
  int temp; 
  n = 32'd0;
  temp = value;
  while (temp > 32'd1) begin
    temp = temp / 32'd2;
    n = n + 32'd1;
  end
  return n;
endfunction

localparam value = rounded_down_power_of_two(34);

initial begin
  $display("%d", value);
end

endmodule

It would be easier for vhdlpp to emit
  int n; n = 32'd0;
  int temp; temp = value;
but that is not accepted by iverilog -g2005-sv.

   - Larry

Re: [Iverilog-devel] SystemVerilog functions via vhdlpp

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

Hello Larry,

Extracting the rounded_down_power_of_two function from the output of vhdlpp and converting to a 
simple SystemVerilog test case gives:

   module test();

   function int rounded_down_power_of_two(input int value);
     int n = 32'd0;
     int temp = value;
     while (temp > 32'd1) begin
       temp = temp / 32'd2;
       n = n + 32'd1;
     end
     return n;
   endfunction

   localparam value = rounded_down_power_of_two(34);

   initial begin
     $display("%d", value);
   end

   endmodule

This is illegal, because the standard says:

"Variables declared in a static task, function, or procedural block default to a static lifetime and 
a local scope. However, an explicit static keyword shall be required when an initialization value is 
specified as part of a static variable’s declaration to indicate the user’s intent of executing that 
initialization only once at the beginning of simulation."

(at least the 2012 standard does - I haven't checked earlier versions).

It appears Icarus silently accepts static initialisation, and doesn't currently support 
static/automatic overrides on variable declarations.

Declaring the function as automatic should work round this problem, but it appears this is broken too.

Martin

P.S. I think there is another issue with the converted function - vhdlpp has output unsigned literal 
values, whereas I think they should be signed values.

Larry Doolittle wrote:
> Friends -
>
> See attached test case for VHDL functions, which fails because the
> width of bit_counter comes out as 1, not 4.  I'd like to thank
> Maciej for huge strides towards making this work!  This has turned
> into a SystemVerilog question.  With all the recent changes in
> iverilog git master, I thought I should check if the problem is
> still present.  It is.
>
> It's a pretty small tar file, 3122 bytes spread across 7 files.
> If you bypass the use of next_highest_power_of_two() in use_func.vhd,
> you get
> $ make
> iverilog -Wall -Wno-timescale -g2005-sv -civhdl.cfg  -o use_func_tb use_func_tb.v use_func.vhd
> vvp -n use_func_tb  | awk -f testcode.awk
>           3 PASS
> But with the buggy next_highest_power_of_two() call in place,
> out-of-the-tarball, you get
> $ make
> iverilog -Wall -Wno-timescale -g2005-sv -civhdl.cfg  -o use_func_tb use_func_tb.v use_func.vhd
> vvp -n use_func_tb  | awk -f testcode.awk
>          20 FAIL
> make: *** [use_func_check] Error 1
>
> Back on 28 Jan 2016, when I discussed this with Maciej,
> he discovered that if you change the following line:
>   int \temp =  \value ;
> to
>   int \temp ; \temp = \value ;
> in the generated code, function next_highest_power_of_two(), then it
> works correctly.  The question is if Icarus' SystemVerilog processing
> should be fixed, or ivlpp should stop emitting broken SystemVerilog.
>
>   - Larry
>
>
>
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140
>
>
>
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>

[Iverilog-devel] Standards Committees

[Kevin C. <iv...@gr...>]

Does anybody on this reflector belong to an IEEE-SA member company?

Kev.

[Iverilog-devel] SystemVerilog functions via vhdlpp

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

Friends -

See attached test case for VHDL functions, which fails because the
width of bit_counter comes out as 1, not 4.  I'd like to thank
Maciej for huge strides towards making this work!  This has turned
into a SystemVerilog question.  With all the recent changes in
iverilog git master, I thought I should check if the problem is
still present.  It is.

It's a pretty small tar file, 3122 bytes spread across 7 files.
If you bypass the use of next_highest_power_of_two() in use_func.vhd, 
you get
$ make
iverilog -Wall -Wno-timescale -g2005-sv -civhdl.cfg  -o use_func_tb use_func_tb.v use_func.vhd
vvp -n use_func_tb  | awk -f testcode.awk
          3 PASS
But with the buggy next_highest_power_of_two() call in place,
out-of-the-tarball, you get
$ make
iverilog -Wall -Wno-timescale -g2005-sv -civhdl.cfg  -o use_func_tb use_func_tb.v use_func.vhd
vvp -n use_func_tb  | awk -f testcode.awk
         20 FAIL
make: *** [use_func_check] Error 1

Back on 28 Jan 2016, when I discussed this with Maciej,
he discovered that if you change the following line:
  int \temp =  \value ;
to
  int \temp ; \temp = \value ;
in the generated code, function next_highest_power_of_two(), then it
works correctly.  The question is if Icarus' SystemVerilog processing
should be fixed, or ivlpp should stop emitting broken SystemVerilog.

  - Larry

Re: [Iverilog-devel] SystemVerilog functions via vhdlpp

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

Friends -

On Sun, Mar 13, 2016 at 04:03:33PM -0700, Larry Doolittle wrote:
> The question is if Icarus' SystemVerilog processing
> should be fixed, or ivlpp should stop emitting broken SystemVerilog.
                      ^^^^^
s/ivlpp/vhdlpp/  of course.

  - Larry

Re: [Iverilog-devel] A few more fixes

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

I think we should strive to be compile clean on older version of gcc/clang, specifically the stable Ubuntu releases, etc. To me something that compiles without a bunch of warnings is an indication of the care and thought put into the code (i.e. if the developers were willing to put in the effort to get a clean compile they are likely thorough enough to have thought full and tested code). Maybe this i just a personal bias, but my vote is for clean code.
Cary
 

    On Saturday, March 12, 2016 3:48 PM, Martin Whitaker <mai...@ma...> wrote:
 

 Maciej Sumiński wrote:
> I am sorry for not mentioning it, but vhdl_multidim_array test is
> expected to fail at the moment. It relies on a ivl feature that is not
> available yet. Should I disable it?
>
I think it's OK to leave it in. I've updated the expected results to show it failing.

The new/changed VHDL tests exposed a few issues in the vlog95 regression tests. I've fixed the 
majority of these, and updated regress-vlog95.list to reflect everything I couldn't fix.

There are still quite a few failures in the v10 regression tests as a result of the VHDL test 
changes. I've run out of time to look at these.

Martin


------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140
_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel


  

Re: [Iverilog-devel] A few more fixes

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

Maciej Sumiński wrote:
> I am sorry for not mentioning it, but vhdl_multidim_array test is
> expected to fail at the moment. It relies on a ivl feature that is not
> available yet. Should I disable it?
>
I think it's OK to leave it in. I've updated the expected results to show it failing.

The new/changed VHDL tests exposed a few issues in the vlog95 regression tests. I've fixed the 
majority of these, and updated regress-vlog95.list to reflect everything I couldn't fix.

There are still quite a few failures in the v10 regression tests as a result of the VHDL test 
changes. I've run out of time to look at these.

Martin

Re: [Iverilog-devel] A few more fixes

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

I am sorry for not mentioning it, but vhdl_multidim_array test is
expected to fail at the moment. It relies on a ivl feature that is not
available yet. Should I disable it?

Regards,
Orson

On 03/10/2016 08:28 PM, Martin Whitaker wrote:
> Thanks Orson. It is indeed a problem with older versons of gcc. Before pushing your patch, I'd like 
> to ask if the other developers think it is worth pandering to this. The issue arises when you have 
> something like:
> 
> class c {
>    public:
>      void set_i(int i);
>      int i();
>    ...
> }
> 
> Older versions of GCC (< 5.0) complain that the local variable 'i' in 'set_i' shadows the function 
> 'i'. Newer versions permit it.
> 
> There are a couple of remaining warnings of this nature in vvp (not of Orson's making).
> 
> Martin
> 
> P.S. When I run the test suite, the vhdl_multidim_array test is failing. Is this expected?
> 
> Maciej Sumiński wrote:
>> Thank you Martin. I do not get these warnings with gcc 5.3.0, it seems
>> that only older versions care about the problem. Please see the attached
>> patch.
>>
>> Regards,
>> Orson
>>
>> On 03/08/2016 09:56 PM, Martin Whitaker wrote:
>>> This pull has also introduced a number of shadow warnings, e.g.
>>>
>>> g++ -I. -I.. -I../../source/vhdlpp -I../../source/vhdlpp/.. -I../../source/vhdlpp/../libmisc
>>> -DHAVE_CONFIG_H -Wall -Wextra -Wshadow   -g -O2 -MD -c ../../source/vhdlpp/main.cc -o main.o
>>> In file included from ../../source/vhdlpp/std_funcs.h:23:0,
>>>                    from ../../source/vhdlpp/main.cc:79:
>>> ../../source/vhdlpp/subprogram.h: In constructor
>>> 'SubprogramStdHeader::SubprogramStdHeader(perm_string, std::list<InterfacePort*>*, const VType*)':
>>> ../../source/vhdlpp/subprogram.h:150:40: warning: declaration of 'name' shadows a member of 'this'
>>> [-Wshadow]
>>>                  const VType*return_type) :
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Transform Data into Opportunity.
>>> Accelerate data analysis in your applications with
>>> Intel Data Analytics Acceleration Library.
>>> Click to learn more.
>>> http://makebettercode.com/inteldaal-eval
>>> _______________________________________________
>>> Iverilog-devel mailing list
>>> Ive...@li...
>>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Transform Data into Opportunity.
>> Accelerate data analysis in your applications with
>> Intel Data Analytics Acceleration Library.
>> Click to learn more.
>> http://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140
>>
>>
>>
>> _______________________________________________
>> Iverilog-devel mailing list
>> Ive...@li...
>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>>
> 
> 
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
> 

Re: [Iverilog-devel] A few more fixes

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

Thanks Orson. It is indeed a problem with older versons of gcc. Before pushing your patch, I'd like 
to ask if the other developers think it is worth pandering to this. The issue arises when you have 
something like:

class c {
   public:
     void set_i(int i);
     int i();
   ...
}

Older versions of GCC (< 5.0) complain that the local variable 'i' in 'set_i' shadows the function 
'i'. Newer versions permit it.

There are a couple of remaining warnings of this nature in vvp (not of Orson's making).

Martin

P.S. When I run the test suite, the vhdl_multidim_array test is failing. Is this expected?

Maciej Sumiński wrote:
> Thank you Martin. I do not get these warnings with gcc 5.3.0, it seems
> that only older versions care about the problem. Please see the attached
> patch.
>
> Regards,
> Orson
>
> On 03/08/2016 09:56 PM, Martin Whitaker wrote:
>> This pull has also introduced a number of shadow warnings, e.g.
>>
>> g++ -I. -I.. -I../../source/vhdlpp -I../../source/vhdlpp/.. -I../../source/vhdlpp/../libmisc
>> -DHAVE_CONFIG_H -Wall -Wextra -Wshadow   -g -O2 -MD -c ../../source/vhdlpp/main.cc -o main.o
>> In file included from ../../source/vhdlpp/std_funcs.h:23:0,
>>                    from ../../source/vhdlpp/main.cc:79:
>> ../../source/vhdlpp/subprogram.h: In constructor
>> 'SubprogramStdHeader::SubprogramStdHeader(perm_string, std::list<InterfacePort*>*, const VType*)':
>> ../../source/vhdlpp/subprogram.h:150:40: warning: declaration of 'name' shadows a member of 'this'
>> [-Wshadow]
>>                  const VType*return_type) :
>>
>>
>> ------------------------------------------------------------------------------
>> Transform Data into Opportunity.
>> Accelerate data analysis in your applications with
>> Intel Data Analytics Acceleration Library.
>> Click to learn more.
>> http://makebettercode.com/inteldaal-eval
>> _______________________________________________
>> Iverilog-devel mailing list
>> Ive...@li...
>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>>
>
>
>
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140
>
>
>
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>

Re: [Iverilog-devel] A few more fixes

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

Thank you Martin. I do not get these warnings with gcc 5.3.0, it seems
that only older versions care about the problem. Please see the attached
patch.

Regards,
Orson

On 03/08/2016 09:56 PM, Martin Whitaker wrote:
> This pull has also introduced a number of shadow warnings, e.g.
> 
> g++ -I. -I.. -I../../source/vhdlpp -I../../source/vhdlpp/.. -I../../source/vhdlpp/../libmisc 
> -DHAVE_CONFIG_H -Wall -Wextra -Wshadow   -g -O2 -MD -c ../../source/vhdlpp/main.cc -o main.o
> In file included from ../../source/vhdlpp/std_funcs.h:23:0,
>                   from ../../source/vhdlpp/main.cc:79:
> ../../source/vhdlpp/subprogram.h: In constructor 
> 'SubprogramStdHeader::SubprogramStdHeader(perm_string, std::list<InterfacePort*>*, const VType*)':
> ../../source/vhdlpp/subprogram.h:150:40: warning: declaration of 'name' shadows a member of 'this' 
> [-Wshadow]
>                 const VType*return_type) :
> 
> 
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://makebettercode.com/inteldaal-eval
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>