iverilog-devel — Conversations on matters of Icarus Verilog development

Re: [Iverilog-devel] do while loop syntax.

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

I wasn’t specifying a –g I added –g2009 and it works. 

Thanks

Lonnie

 

 

From: Cary R. [mailto:cy...@ya...] 
Sent: Thursday, January 08, 2015 3:37 PM
To: Discussions concerning Icarus Verilog development
Subject: Re: [Iverilog-devel] do while loop syntax.

 

Are you telling Icarus to use SystemVerilog (e.g. -g2009, -g2012 or -g2005-sv)? The following example runs correctly (displays 0 to 9) using the latest code from git and the -g2009 flag:





module top;
  integer val;

  initial begin
    val = 0;
    do begin
      $display(val);
      val += 1;
    end while (val < 10);
  end
endmodule

 

Since SystemVerilog is not that complete in Icarus it is not enabled by default.

 

Cary

 

On Thursday, January 8, 2015 1:17 PM, Lonnie Gliem <lg...@sr...> wrote:

 

What is the do while syntax for iverilog. I have the loop below that
compiles fine in vcs but errors out in iverilog.

do begin
    @(posedge clk);
    err = $carte_accept(listening_sockfd);
end while (err == -1);

Here are the errors.

/home/dvl/installs/TRIAL_5.3_64/opt/srcci/comp/lib/macros/map_m/v/eth_command_accept.v:87:
syntax error
/home/dvl/installs/TRIAL_5.3_64/opt/srcci/comp/lib/macros/map_m/v/eth_command_accept.v:88:
error: malformed statement
/home/dvl/installs/TRIAL_5.3_64/opt/srcci/comp/lib/macros/map_m/v/eth_command_accept.v:95:
syntax error

Here is the version:

Icarus Verilog version 0.10.0 (devel) (s20140801-15-g4ea512c)

Thansk for the help
Lonnie


------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net <http://goparallel.sourceforge.net/> 
_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel

Re: [Iverilog-devel] do while loop syntax.

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

Are you telling Icarus to use SystemVerilog (e.g. -g2009, -g2012 or -g2005-sv)? The following example runs correctly (displays 0 to 9) using the latest code from git and the -g2009 flag:
module top;
  integer val;

  initial begin
    val = 0;
    do begin
      $display(val);
      val += 1;
    end while (val < 10);
  end
endmodule
Since SystemVerilog is not that complete in Icarus it is not enabled by default.

Cary
 

     On Thursday, January 8, 2015 1:17 PM, Lonnie Gliem <lg...@sr...> wrote:
   

 What is the do while syntax for iverilog. I have the loop below that
compiles fine in vcs but errors out in iverilog.

do begin
    @(posedge clk);
    err = $carte_accept(listening_sockfd);
end while (err == -1);

Here are the errors.

/home/dvl/installs/TRIAL_5.3_64/opt/srcci/comp/lib/macros/map_m/v/eth_command_accept.v:87:
syntax error
/home/dvl/installs/TRIAL_5.3_64/opt/srcci/comp/lib/macros/map_m/v/eth_command_accept.v:88:
error: malformed statement
/home/dvl/installs/TRIAL_5.3_64/opt/srcci/comp/lib/macros/map_m/v/eth_command_accept.v:95:
syntax error

Here is the version:

Icarus Verilog version 0.10.0 (devel) (s20140801-15-g4ea512c)

Thansk for the help
Lonnie


------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel


   

[Iverilog-devel] do while loop syntax.

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

What is the do while syntax for iverilog. I have the loop below that
compiles fine in vcs but errors out in iverilog.

do begin
	@(posedge clk);
	err = $carte_accept(listening_sockfd);
end while (err == -1);

Here are the errors.

/home/dvl/installs/TRIAL_5.3_64/opt/srcci/comp/lib/macros/map_m/v/eth_command_accept.v:87:
syntax error
/home/dvl/installs/TRIAL_5.3_64/opt/srcci/comp/lib/macros/map_m/v/eth_command_accept.v:88:
error: malformed statement
/home/dvl/installs/TRIAL_5.3_64/opt/srcci/comp/lib/macros/map_m/v/eth_command_accept.v:95:
syntax error

Here is the version:

Icarus Verilog version 0.10.0 (devel) (s20140801-15-g4ea512c)

Thansk for the help
Lonnie

Re: [Iverilog-devel] Is there any way to avoid this shift/reduce conflict?

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

FYI Steve does not allow us to check in code that has either shift/reduce or reduce/reduce errors.
The standard way to work around this is to flatten things into a single rule that can then match the text correctly (no shift or reduce just more processing), but that is not always possible. I looked at your example very quickly and it does look complicated. I normally have to spend some time thinking about how bison is working/parsing the text before I figure it out what needs to be done or realize it's not actually possible. I can look at this later when I have some time if you would like.

There are a few things in Verilog that require more than default bison supports (e.g. see br493).
Cary
 

     On Thursday, January 8, 2015 12:15 PM, Pete Johnson <pe...@be...> wrote:
   

 Martin,
Shift reduce conflicts are not all that uncommon. You get one with the standard if statement. Think of the following…
if (test)   if (another_test)     statement;  else     statement;
When parsing the else statement do you shift the else into the inner if expression or do you reduce the if and let the else go with the outer if. Shift reduce conflicts are resolved by shifting so the else goes with the inner if - regardless of indenting. 
Reduce/reduce conflicts are a problem though. You should never have any of those.
In your case will you get the correct behavior if the conflict resolves as a shift? 
Here is a link to the bison page on the subject along with how to use a pragma to suppress the warning.
http://www.gnu.org/software/bison/manual/html_node/Shift_002fReduce.html
-Pete



On Jan 8, 2015, at 11:33 AM, Martin Whitaker <mai...@ma...> wrote:
I'm trying to add support for SystemVerilog modports to the iverilog parser. 
The relevant snippet from parse.y looks like this:

modport_item
   : IDENTIFIER
       { pform_start_modport_item(@1, $1); }
     '(' modport_ports_list ')'
       { pform_end_modport_item(@1); }
   ;

modport_ports_list
   : modport_ports_declaration
   | modport_ports_list ',' modport_ports_declaration
   ;

modport_ports_declaration
   : attribute_list_opt port_direction modport_simple_port_list
       { pform_add_modport_ports(@2, $1, $2, $3); }
   | attribute_list_opt import_export modport_tf_port_list
       { ... }
   | attribute_list_opt K_clocking IDENTIFIER
       { ... }
   ;

modport_simple_port_list
   : IDENTIFIER
       { $$ = make_port_list($1, 0); }
   | '.' IDENTIFIER '(' expression ')'
       { $$ = make_port_list($2, $4); }
   | modport_simple_port_list ',' IDENTIFIER
       { $$ = make_port_list($1, $3, 0); }
   | modport_simple_port_list ',' '.' IDENTIFIER '(' expression ')'
       { $$ = make_port_list($1, $4, $6); }
   ;

which is giving me a shift/reduce conflict. The problem is the parser can't 
distinguish between a ',' that separates items in a modport_simple_port_list 
and one that separates items in a modport_ports_list.

I can't find a way to avoid the conflict with a single level of lookahead. Can 
anyone else?

------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel



------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel


   

Re: [Iverilog-devel] Is there any way to avoid this shift/reduce conflict?

[Pete J. <pe...@be...>]

Martin,

Shift reduce conflicts are not all that uncommon. You get one with the standard if statement. Think of the following…

if (test) 
  if (another_test)
     statement;
  else
     statement;

When parsing the else statement do you shift the else into the inner if expression or do you reduce the if and let the else go with the outer if. Shift reduce conflicts are resolved by shifting so the else goes with the inner if - regardless of indenting. 

Reduce/reduce conflicts are a problem though. You should never have any of those.

In your case will you get the correct behavior if the conflict resolves as a shift? 

Here is a link to the bison page on the subject along with how to use a pragma to suppress the warning.

http://www.gnu.org/software/bison/manual/html_node/Shift_002fReduce.html <http://www.gnu.org/software/bison/manual/html_node/Shift_002fReduce.html>

-Pete



> On Jan 8, 2015, at 11:33 AM, Martin Whitaker <mai...@ma...> wrote:
> 
> I'm trying to add support for SystemVerilog modports to the iverilog parser. 
> The relevant snippet from parse.y looks like this:
> 
> modport_item
>   : IDENTIFIER
>       { pform_start_modport_item(@1, $1); }
>     '(' modport_ports_list ')'
>       { pform_end_modport_item(@1); }
>   ;
> 
> modport_ports_list
>   : modport_ports_declaration
>   | modport_ports_list ',' modport_ports_declaration
>   ;
> 
> modport_ports_declaration
>   : attribute_list_opt port_direction modport_simple_port_list
>       { pform_add_modport_ports(@2, $1, $2, $3); }
>   | attribute_list_opt import_export modport_tf_port_list
>       { ... }
>   | attribute_list_opt K_clocking IDENTIFIER
>       { ... }
>   ;
> 
> modport_simple_port_list
>   : IDENTIFIER
>       { $$ = make_port_list($1, 0); }
>   | '.' IDENTIFIER '(' expression ')'
>       { $$ = make_port_list($2, $4); }
>   | modport_simple_port_list ',' IDENTIFIER
>       { $$ = make_port_list($1, $3, 0); }
>   | modport_simple_port_list ',' '.' IDENTIFIER '(' expression ')'
>       { $$ = make_port_list($1, $4, $6); }
>   ;
> 
> which is giving me a shift/reduce conflict. The problem is the parser can't 
> distinguish between a ',' that separates items in a modport_simple_port_list 
> and one that separates items in a modport_ports_list.
> 
> I can't find a way to avoid the conflict with a single level of lookahead. Can 
> anyone else?
> 
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming! The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel

[Iverilog-devel] Is there any way to avoid this shift/reduce conflict?

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

I'm trying to add support for SystemVerilog modports to the iverilog parser. 
The relevant snippet from parse.y looks like this:

modport_item
   : IDENTIFIER
       { pform_start_modport_item(@1, $1); }
     '(' modport_ports_list ')'
       { pform_end_modport_item(@1); }
   ;

modport_ports_list
   : modport_ports_declaration
   | modport_ports_list ',' modport_ports_declaration
   ;

modport_ports_declaration
   : attribute_list_opt port_direction modport_simple_port_list
       { pform_add_modport_ports(@2, $1, $2, $3); }
   | attribute_list_opt import_export modport_tf_port_list
       { ... }
   | attribute_list_opt K_clocking IDENTIFIER
       { ... }
   ;

modport_simple_port_list
   : IDENTIFIER
       { $$ = make_port_list($1, 0); }
   | '.' IDENTIFIER '(' expression ')'
       { $$ = make_port_list($2, $4); }
   | modport_simple_port_list ',' IDENTIFIER
       { $$ = make_port_list($1, $3, 0); }
   | modport_simple_port_list ',' '.' IDENTIFIER '(' expression ')'
       { $$ = make_port_list($1, $4, $6); }
   ;

which is giving me a shift/reduce conflict. The problem is the parser can't 
distinguish between a ',' that separates items in a modport_simple_port_list 
and one that separates items in a modport_ports_list.

I can't find a way to avoid the conflict with a single level of lookahead. Can 
anyone else?

Re: [Iverilog-devel] Subdividing the ivtest compiler regression test lists

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

Yes keep what we have for V0.8 in some manner in case we want to update the test results. The only reason we have kept it as an option is because it is the only branch that supports synthesis. I used to keep the V0.8 results in sync, but at the moment I do not have V0.8 compiled on any machines so it has been neglected for some time.
Cary
 

     On Monday, January 5, 2015 12:16 PM, Martin Whitaker <mai...@ma...> wrote:
   

 One enthusiastic yes, and no dissenting voices, so I've switched everything 
over. Shout if anything seems broken.

I've preserved the v0.8 exceptions (in regress-v0.8.list) in case anyone wants 
to resurrect them. Given that we haven't touched v0.8 in a long time, it 
doesn't seem worth expending much effort on this.

Stephen Williams wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> This is AWESOME! We've been needing this for a while, and finally
> one of us has gotten around to it. Good job!
>
> On 12/22/2014 01:46 PM, Martin Whitaker wrote:
>> I suggested this a while ago, but have now got round to trying it.
>> Rather than have a single regress.list, I've split it into a number
>> of separate lists:
>>
>> regress-vlg.list      - tests that should work with any standard
>> Verilog (1364-2005) simulator regress-sv.list      - tests that
>> should work with any standard SystemVerilog (1800-2012) simulator
>> regress-vhdl.list    - tests that should work with any standard
>> VHDL simulator regress-vams.list    - tests that should work with
>> any standard Verilog-AMS simulator regress-ivl1.list    - tests
>> that use Icarus Verilog extensions or known deviations from the
>> standard, excluding those in regress-ivl2.list regress-ivl2.list
>> - tests that rely on lossless expressions or on the default vvp
>> unformatted real number display regress-synth.list    - tests that
>> exercise the Icarus Verilog synthesis functionality
>> regress-v0.9.list    - test exceptions for v0.9 regress-v0.10.list
>> - test exceptions for v0.10 regress-vlog95.list  - test exceptions
>> for the vlog95 target
>>
>> (I may not have put all the tests in their proper categories, but I
>> think it's mostly right).
>>
>> The main aim of this change is to reduce the effort needed to
>> maintain the lists when adding tests that aren't supported by older
>> versions of Icarus or by the vlog95 target. The scripts only load
>> the test lists that are appropriate to the compiler version and
>> target being exercised.
>>
>> I've taken this opportunity to sort the main lists into
>> alphabetic/numeric order and to make the tabulation more consistent
>> (and hopefully more readable).
>>
>> I've pushed these new lists, plus two modified scripts,
>> new_vvp_reg.pl and new_vlog95_reg.pl, to the ivtest master branch.
>> The original regress.list and perl scripts are still there,
>> unmodified.
>>
>> Take a look and let me know what you think.
>>
>> Martin
>>
>> P.S. I haven't created a test exception list for v0.8 - do we still
>> want/need to support this?
>>
>> ------------------------------------------------------------------------------
>>
>>
> Dive into the World of Parallel Programming! The Go Parallel Website,
>> sponsored by Intel and developed in partnership with Slashdot
>> Media, is your hub for all things parallel software development,
>> from weekly thought leadership blogs to news, videos, case studies,
>> tutorials and more. Take a look and join the conversation now.
>> http://goparallel.sourceforge.net
>> _______________________________________________ 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
>
> iEYEARECAAYFAlSZ5a0ACgkQrPt1Sc2b3iku3QCglETwkn/e8GCS54aDClFGacrO
> wKoAn165nq8Bnxr0lUFKMt6UuUloCb6h
> =Dz+J
> -----END PGP SIGNATURE-----
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming! The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>


------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel


   

Re: [Iverilog-devel] Subdividing the ivtest compiler regression test lists

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

One enthusiastic yes, and no dissenting voices, so I've switched everything 
over. Shout if anything seems broken.

I've preserved the v0.8 exceptions (in regress-v0.8.list) in case anyone wants 
to resurrect them. Given that we haven't touched v0.8 in a long time, it 
doesn't seem worth expending much effort on this.

Stephen Williams wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> This is AWESOME! We've been needing this for a while, and finally
> one of us has gotten around to it. Good job!
>
> On 12/22/2014 01:46 PM, Martin Whitaker wrote:
>> I suggested this a while ago, but have now got round to trying it.
>> Rather than have a single regress.list, I've split it into a number
>> of separate lists:
>>
>> regress-vlg.list      - tests that should work with any standard
>> Verilog (1364-2005) simulator regress-sv.list       - tests that
>> should work with any standard SystemVerilog (1800-2012) simulator
>> regress-vhdl.list     - tests that should work with any standard
>> VHDL simulator regress-vams.list     - tests that should work with
>> any standard Verilog-AMS simulator regress-ivl1.list     - tests
>> that use Icarus Verilog extensions or known deviations from the
>> standard, excluding those in regress-ivl2.list regress-ivl2.list
>> - tests that rely on lossless expressions or on the default vvp
>> unformatted real number display regress-synth.list    - tests that
>> exercise the Icarus Verilog synthesis functionality
>> regress-v0.9.list     - test exceptions for v0.9 regress-v0.10.list
>> - test exceptions for v0.10 regress-vlog95.list   - test exceptions
>> for the vlog95 target
>>
>> (I may not have put all the tests in their proper categories, but I
>> think it's mostly right).
>>
>> The main aim of this change is to reduce the effort needed to
>> maintain the lists when adding tests that aren't supported by older
>> versions of Icarus or by the vlog95 target. The scripts only load
>> the test lists that are appropriate to the compiler version and
>> target being exercised.
>>
>> I've taken this opportunity to sort the main lists into
>> alphabetic/numeric order and to make the tabulation more consistent
>> (and hopefully more readable).
>>
>> I've pushed these new lists, plus two modified scripts,
>> new_vvp_reg.pl and new_vlog95_reg.pl, to the ivtest master branch.
>> The original regress.list and perl scripts are still there,
>> unmodified.
>>
>> Take a look and let me know what you think.
>>
>> Martin
>>
>> P.S. I haven't created a test exception list for v0.8 - do we still
>> want/need to support this?
>>
>> ------------------------------------------------------------------------------
>>
>>
> Dive into the World of Parallel Programming! The Go Parallel Website,
>> sponsored by Intel and developed in partnership with Slashdot
>> Media, is your hub for all things parallel software development,
>> from weekly thought leadership blogs to news, videos, case studies,
>> tutorials and more. Take a look and join the conversation now.
>> http://goparallel.sourceforge.net
>> _______________________________________________ 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
>
> iEYEARECAAYFAlSZ5a0ACgkQrPt1Sc2b3iku3QCglETwkn/e8GCS54aDClFGacrO
> wKoAn165nq8Bnxr0lUFKMt6UuUloCb6h
> =Dz+J
> -----END PGP SIGNATURE-----
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming! The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>

Re: [Iverilog-devel] Subdividing the ivtest compiler regression test lists

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

I have not looked at the actual implementation/changes, but it all sounds like a good idea.
I guess the next big thing as far as the test suite goes is to make it thread aware. I remember someone had pieces of that implemented, but as I remember we actually need something that is a bit more flexible. I believe what we want is a master controller that keeps things in order and then create N threads to do the actual testing where N = the number of processors. The controller is responsible for issuing the threads and caching the results of threads that finish before threads that are still processing earlier tests. This would allow the results file to be generated in a deterministic manner.
I can elaborate more whenever/if someone else wants to take the on.
Cary
 

     On Tuesday, December 23, 2014 1:59 PM, Stephen Williams <st...@ic...> wrote:
   

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


This is AWESOME! We've been needing this for a while, and finally
one of us has gotten around to it. Good job!

On 12/22/2014 01:46 PM, Martin Whitaker wrote:
> I suggested this a while ago, but have now got round to trying it.
> Rather than have a single regress.list, I've split it into a number
> of separate lists:
> 
> regress-vlg.list      - tests that should work with any standard 
> Verilog (1364-2005) simulator regress-sv.list      - tests that
> should work with any standard SystemVerilog (1800-2012) simulator 
> regress-vhdl.list    - tests that should work with any standard 
> VHDL simulator regress-vams.list    - tests that should work with
> any standard Verilog-AMS simulator regress-ivl1.list    - tests
> that use Icarus Verilog extensions or known deviations from the
> standard, excluding those in regress-ivl2.list regress-ivl2.list
> - tests that rely on lossless expressions or on the default vvp
> unformatted real number display regress-synth.list    - tests that
> exercise the Icarus Verilog synthesis functionality 
> regress-v0.9.list    - test exceptions for v0.9 regress-v0.10.list
> - test exceptions for v0.10 regress-vlog95.list  - test exceptions
> for the vlog95 target
> 
> (I may not have put all the tests in their proper categories, but I
> think it's mostly right).
> 
> The main aim of this change is to reduce the effort needed to
> maintain the lists when adding tests that aren't supported by older
> versions of Icarus or by the vlog95 target. The scripts only load
> the test lists that are appropriate to the compiler version and
> target being exercised.
> 
> I've taken this opportunity to sort the main lists into
> alphabetic/numeric order and to make the tabulation more consistent
> (and hopefully more readable).
> 
> I've pushed these new lists, plus two modified scripts,
> new_vvp_reg.pl and new_vlog95_reg.pl, to the ivtest master branch.
> The original regress.list and perl scripts are still there,
> unmodified.
> 
> Take a look and let me know what you think.
> 
> Martin
> 
> P.S. I haven't created a test exception list for v0.8 - do we still
> want/need to support this?
> 
> ------------------------------------------------------------------------------
>
> 
Dive into the World of Parallel Programming! The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot
> Media, is your hub for all things parallel software development,
> from weekly thought leadership blogs to news, videos, case studies,
> tutorials and more. Take a look and join the conversation now.
> http://goparallel.sourceforge.net 
> _______________________________________________ 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

iEYEARECAAYFAlSZ5a0ACgkQrPt1Sc2b3iku3QCglETwkn/e8GCS54aDClFGacrO
wKoAn165nq8Bnxr0lUFKMt6UuUloCb6h
=Dz+J
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel


   

Re: [Iverilog-devel] Subdividing the ivtest compiler regression test lists

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

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


This is AWESOME! We've been needing this for a while, and finally
one of us has gotten around to it. Good job!

On 12/22/2014 01:46 PM, Martin Whitaker wrote:
> I suggested this a while ago, but have now got round to trying it.
> Rather than have a single regress.list, I've split it into a number
> of separate lists:
> 
> regress-vlg.list      - tests that should work with any standard 
> Verilog (1364-2005) simulator regress-sv.list       - tests that
> should work with any standard SystemVerilog (1800-2012) simulator 
> regress-vhdl.list     - tests that should work with any standard 
> VHDL simulator regress-vams.list     - tests that should work with
> any standard Verilog-AMS simulator regress-ivl1.list     - tests
> that use Icarus Verilog extensions or known deviations from the
> standard, excluding those in regress-ivl2.list regress-ivl2.list
> - tests that rely on lossless expressions or on the default vvp
> unformatted real number display regress-synth.list    - tests that
> exercise the Icarus Verilog synthesis functionality 
> regress-v0.9.list     - test exceptions for v0.9 regress-v0.10.list
> - test exceptions for v0.10 regress-vlog95.list   - test exceptions
> for the vlog95 target
> 
> (I may not have put all the tests in their proper categories, but I
> think it's mostly right).
> 
> The main aim of this change is to reduce the effort needed to
> maintain the lists when adding tests that aren't supported by older
> versions of Icarus or by the vlog95 target. The scripts only load
> the test lists that are appropriate to the compiler version and
> target being exercised.
> 
> I've taken this opportunity to sort the main lists into
> alphabetic/numeric order and to make the tabulation more consistent
> (and hopefully more readable).
> 
> I've pushed these new lists, plus two modified scripts,
> new_vvp_reg.pl and new_vlog95_reg.pl, to the ivtest master branch.
> The original regress.list and perl scripts are still there,
> unmodified.
> 
> Take a look and let me know what you think.
> 
> Martin
> 
> P.S. I haven't created a test exception list for v0.8 - do we still
> want/need to support this?
> 
> ------------------------------------------------------------------------------
>
> 
Dive into the World of Parallel Programming! The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot
> Media, is your hub for all things parallel software development,
> from weekly thought leadership blogs to news, videos, case studies,
> tutorials and more. Take a look and join the conversation now.
> http://goparallel.sourceforge.net 
> _______________________________________________ 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

iEYEARECAAYFAlSZ5a0ACgkQrPt1Sc2b3iku3QCglETwkn/e8GCS54aDClFGacrO
wKoAn165nq8Bnxr0lUFKMt6UuUloCb6h
=Dz+J
-----END PGP SIGNATURE-----

[Iverilog-devel] Subdividing the ivtest compiler regression test lists

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

I suggested this a while ago, but have now got round to trying it. Rather than 
have a single regress.list, I've split it into a number of separate lists:

   regress-vlg.list      - tests that should work with any standard
                           Verilog (1364-2005) simulator
   regress-sv.list       - tests that should work with any standard
                           SystemVerilog (1800-2012) simulator
   regress-vhdl.list     - tests that should work with any standard
                           VHDL simulator
   regress-vams.list     - tests that should work with any standard
                           Verilog-AMS simulator
   regress-ivl1.list     - tests that use Icarus Verilog extensions
                           or known deviations from the standard,
                           excluding those in regress-ivl2.list
   regress-ivl2.list     - tests that rely on lossless expressions
                           or on the default vvp unformatted real
                           number display
   regress-synth.list    - tests that exercise the Icarus Verilog
                           synthesis functionality
   regress-v0.9.list     - test exceptions for v0.9
   regress-v0.10.list    - test exceptions for v0.10
   regress-vlog95.list   - test exceptions for the vlog95 target

(I may not have put all the tests in their proper categories, but I think it's 
mostly right).

The main aim of this change is to reduce the effort needed to maintain the 
lists when adding tests that aren't supported by older versions of Icarus or 
by the vlog95 target. The scripts only load the test lists that are 
appropriate to the compiler version and target being exercised.

I've taken this opportunity to sort the main lists into alphabetic/numeric 
order and to make the tabulation more consistent (and hopefully more readable).

I've pushed these new lists, plus two modified scripts, new_vvp_reg.pl and 
new_vlog95_reg.pl, to the ivtest master branch. The original regress.list and 
perl scripts are still there, unmodified.

Take a look and let me know what you think.

Martin

P.S. I haven't created a test exception list for v0.8 - do we still want/need 
to support this?

Re: [Iverilog-devel] Icarus Verilog documentation vs. Wikia

[Guilherme B. T. <gui...@gm...>]

Hello Stephen,

Just a few ideas...
Have you considered using a documentation generator instead?

I started using the GitHub Wiki for Qucs [1]. I works fine to draft and 
aggregate general information. What I miss is a notification system 
about changes. It is a Git repo, but I don't want to pull each time to 
see what was changed.

I am now considering Sphinx (Python based) as a documentation generator 
to create static HTML pages (also PDF) for our online-help manuals 
(preview in [2]). Marcos from KiCad is currently evaluating other 
generators [3].

Your Wiki content can easily converted to reStructuredText (pandoc). You 
can pick or personalize a Sphinx template. The generated HTML looks 
great and you can put them anywhere you like (Google Pages, GitHub pages).
A really nice host is Read The Docs, which can fetch the changes 
directly from your repo and publish the HTML pages.
If you set it up with GitHub (not sure with Bitbucket) it even allows 
one to edit/preview the sources on the browser (almost like a Wiki).

Regards, Guilherme

[1] https://github.com/Qucs/qucs/wiki
[2] http://guitorri.github.io/qucs-help.github.io/html-en/index.html
[3] https://github.com/ciampix/kicad-doc/blob/master/doc/kicad-doc-doc.adoc



On 12/19/14, 10:44 PM, Stephen Williams wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> The Icarus Verilog documentation is on the Wikia.com web site. I went
> there today without being logged in, and I was amazed: tons of ads,
> every one of them a video!
>
> No.
>
> Bad impression.
>
> So I'm considering moving the documentation to a less yucky place.
> My first thought is to move it to the iverilog.icarus.com site,
> which is a "Google Sites" site. At least there if there are ads,
> the revenue would go to me;-) I'm familiar with it, and know it would
> be safe there. The down side, granting permissions for editing
> would be a more explicit thing, instead of the current default
> of granting permissions.
>
> Another option is to use the github wiki feature. I am almost
> completely unfamiliar with its abilities, but I'm otherwise
> pleased with github, so I'd consider it in the running. Do others
> have experience with the github Wiki? Thoughts?
>
> Any other thoughts we should consider?
>
> - -- 
> 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
>
> iEYEARECAAYFAlSUnDsACgkQrPt1Sc2b3ik6owCfYnjKMIOpTeZiIf0y3n5BeMEE
> KYQAn0XLNhmnijiNOS1OjKJLHnASG00C
> =Px3R
> -----END PGP SIGNATURE-----
>
>

Re: [Iverilog-devel] Icarus Verilog documentation vs. Wikia

[Pete J. <pe...@be...>]

Steve,

I have a server at a hosting site (got.net <http://got.net/>) running VmWare ESXi. If you want I could configure a virtual machine for you and you could run anything you want as long as there is not a lot of traffic. I have run it for about five years and it is pretty stable.

Let me know if that is of interest.

Thanks,

-Pete


> On Dec 19, 2014, at 1:44 PM, Stephen Williams <st...@ic...> wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> The Icarus Verilog documentation is on the Wikia.com web site. I went
> there today without being logged in, and I was amazed: tons of ads,
> every one of them a video!
> 
> No.
> 
> Bad impression.
> 
> So I'm considering moving the documentation to a less yucky place.
> My first thought is to move it to the iverilog.icarus.com site,
> which is a "Google Sites" site. At least there if there are ads,
> the revenue would go to me;-) I'm familiar with it, and know it would
> be safe there. The down side, granting permissions for editing
> would be a more explicit thing, instead of the current default
> of granting permissions.
> 
> Another option is to use the github wiki feature. I am almost
> completely unfamiliar with its abilities, but I'm otherwise
> pleased with github, so I'd consider it in the running. Do others
> have experience with the github Wiki? Thoughts?
> 
> Any other thoughts we should consider?
> 
> - -- 
> 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
> 
> iEYEARECAAYFAlSUnDsACgkQrPt1Sc2b3ik6owCfYnjKMIOpTeZiIf0y3n5BeMEE
> KYQAn0XLNhmnijiNOS1OjKJLHnASG00C
> =Px3R
> -----END PGP SIGNATURE-----
> 
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel

[Iverilog-devel] Icarus Verilog documentation vs. Wikia

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

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


The Icarus Verilog documentation is on the Wikia.com web site. I went
there today without being logged in, and I was amazed: tons of ads,
every one of them a video!

No.

Bad impression.

So I'm considering moving the documentation to a less yucky place.
My first thought is to move it to the iverilog.icarus.com site,
which is a "Google Sites" site. At least there if there are ads,
the revenue would go to me;-) I'm familiar with it, and know it would
be safe there. The down side, granting permissions for editing
would be a more explicit thing, instead of the current default
of granting permissions.

Another option is to use the github wiki feature. I am almost
completely unfamiliar with its abilities, but I'm otherwise
pleased with github, so I'd consider it in the running. Do others
have experience with the github Wiki? Thoughts?

Any other thoughts we should consider?

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

iEYEARECAAYFAlSUnDsACgkQrPt1Sc2b3ik6owCfYnjKMIOpTeZiIf0y3n5BeMEE
KYQAn0XLNhmnijiNOS1OjKJLHnASG00C
=Px3R
-----END PGP SIGNATURE-----

[Iverilog-devel] Unpacked arrays extension

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi Steve,

I have prepared a set of patches to extend the functionality related
to unpacked arrays [1] along with tests [2]. If I have not missed
anything, now I should be able to continue my work on vhdlpp.

Casting between dynamic arrays and vectors currently is realized with
Icarus-specific VPI functions ($ivl_darray_metho$[from/to]_vec).
Ideally, it should be done using type casting, as it was proposed
earlier, but I would rather implement it a bit later.

I had some doubts if it is enough to simply add a case statement to
support dynamic arrays of logic type [3]. The output vvp code uses
%store/dar/vec4 and %load/dar/vec4, so I assume it should be fine.

Regards,
Orson

1. https://github.com/steveicarus/iverilog/pull/50
2. https://github.com/orsonmmz/ivtest/tree/darray_test
3.
https://github.com/orsonmmz/iverilog/commit/aed69f2c6bc3e8c6b9289e5cfde824fd1b3653b9
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJUk/xcAAoJEBRwGu1hpbJ1zy4H/i15Tn4s7AvPbAk7wIov6fG3
UKLfnqHPt7WCk+RyOwiXdHEkDE512q6n7YaDsLt+Merar/u7A3UBRCAYbRMZbmvF
GNymbf/Bv9xasur64B6SYKZ08pdQzlJR4W9dLVt8zBU9wIcVLAEM0Zi4TlUjagwG
qJRO3clHdxdu6Juirbux7PJQ4Dj6d+fT6sqS3bav3+pCriSkwhQMEreGM6EWnuen
lqnjtI8MYkrUPEwWmoJSgAGStUYXtmQFtojpIe7XjGLkfJoGb680YmWeppk+X0MP
b3nuJJJHUNLp72jV6r2mIttTOUvaz3m9UxAcJQz0e+ojkZQAR92s88Z4SJ5C0tM=
=hYcm
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] patch proposal for vhdlpp

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

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

On 12/17/2014 03:19 AM, Fabrizio Ferrandi wrote:
> So having or not having such lines is the same. So, I've created a
> patch that should fix the problem. The fix is lazy w.r.t. the
> package textio. A better solution is to parse or to exploit
> pre-compiled standard libraries. So the first question is: do you
> plan to add a support for pre-compiled standard packages?

Your patch is applied to git master.

To answer your question, my intent was to handle many of the
standard libraries internally. You noticed this in the code that
you patched. Types and other declarations can be efficiently
compiled into the compiler itself. For many of the more basic
types, this is the only reasonable way to do it and I suspect
that most VHDL compilers work the same way.

For many standard functions, there are straight forward translations
to Verilog analogs, so the Icarus Verilog runtime is leveraged,
and for others, it is easy enough to make the compiler generate
references to system tasks to implement the library functions.

So that is where we are heading with the standard libraries.

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

iEYEARECAAYFAlSTAK4ACgkQrPt1Sc2b3im2QQCg1cftPCti/I9KlW+YrVNYmBac
2iIAoOl9L5WzH461qey8sfqtdM3eHRNP
=D5E1
-----END PGP SIGNATURE-----

[Iverilog-devel] patch proposal for vhdlpp

[Fabrizio F. <fab...@po...>]

Dears,

we are willing to use icarus compiler to simulate VHDL code 
automatically generated by our framework. Details of our framework could 
be found at panda.dei.polim.it or at http://www.ohwr.org/projects/panda.
Our framework synthesizes HLD starting from ANSI C code exploiting the 
GCC intermediate representation. We already exploit Icarus as Verilog 
simulator and we are interested in the VHDL support you are developing.
Currently, VHDL is needed only in case the source C code has floating 
point operations. Later, we will generate a full VHDL synthesizable 
description. The VHDL cores are generated exploiting the FloPoCo library 
(http://flopoco.gforge.inria.fr/).
Checking the VHDL code we generate we have few things not supported by 
Icarus.

The first one is related to the library standard usage. The floating 
point cores we generated have always this header:

library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_arith.all;
use ieee.std_logic_unsigned.all;
library std;
use std.textio.all;
library work;

The lines that drives crazy icarus/vhdlpp is the references to library 
standard. According to the standard we have that:
Every design unit [...] is assumed to contain the following implicit 
context items [...]:
library STD, WORK; use STD.STANDARD.all;

So having or not having such lines is the same. So, I've created a patch 
that should fix the problem.
The fix is lazy w.r.t. the package textio. A better solution is to parse 
or to exploit pre-compiled standard libraries.
So the first question is: do you plan to add a support for pre-compiled 
standard packages?

Another blocking thing we have with the VHDL code not supported is the 
use of with ... select statements.
Is there someone that is working to add this type of statements. In case 
no one is working on this type of statement we may try to add its support.

Thanks,

Fabrizio

-- 
-------------------------------------------------------------------
  Name:                  Fabrizio Ferrandi
  Department:            Dipartimento di Elettronica Informazione
                         e Bioingegneria
  Organization:          Politecnico di Milano
  Address:               Piazza Leonardo Da Vinci, 32
  z.i.p./City:           I-20133 Milano
  Country:               Italy
  Phone:                 +39 02 2399 3479
  Fax:                   +39 02 2399 3411
  E-mail:                fab...@po...
  www:                   http://www.deib.polimi.it/people/ferrandi
-------------------------------------------------------------------

Re: [Iverilog-devel] pass -v to vvp in the #! header line

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

I've pushed this change to the master branch, including an update to the 
iverilog man page. I've also updated the Wiki.

Cary R. wrote:
> We need to make sure it is documented correctly (i.e. the two methods can produce different results).
> Cary
>
>
>       On Sunday, December 14, 2014 12:53 PM, Martin Whitaker <mai...@ma...> wrote:
>
>
>   This seems reasonable to me. Unless anybody argues against it, I'll apply the
> patch.
>
> boe...@ph... (Stephan Böttcher) wrote:
>>
>> Cary,
>>
>> "Cary R." <cy...@ya...> writes:
>>
>>> This looks reasonable, but it doesn't work for all use cases (e.g. vvp
>>> <output_file>). We could modify vvp to look at the #! line to make
>>> sure the flag is found.
>>
>> I don't think you want that flag to be found in all cases.  This is only
>> for the case when you run the <outputfile> directly, and get the same
>> verbosity as iverilog used.
>>
>> If you run the simulation as vvp <output_file>, you can add the -v flag
>> at that occasion
>>
>>      vvp -v <output_file>
>>
>> If you run the outputfile as
>>
>>      ./<output_file> -v
>>
>> it does not work, since it translates to
>>
>>      /usr/local/bin/vvp <output_file> -v
>>
>> and in that position, the -v flag is ignored.
>>
>> man vvp(1):
>>
>>> EXTENDED ARGUMENTS
>>>          The  vvp options described above must come before the design file name.
>>>          After the design file name, however, there may be any number of unspec‐
>>>          ified  arguments.  These  arguments  are not interpreted by vvp but are
>>>          instead passed on to the executed design, and  are  available  via  the
>>>          $test$plusargs and $value$plusargs system functions.
>>
>> I had the following Makefile rules:
>>
>>> VERILOG=/usr/local/bin/iverilog
>>> VERILOGFLAGS = -v -Wall -Wno-timescale -DSIMULATION $($*_FLAGS)
>>> %.vvp:
>>>            $(VERILOG) $(VERILOGFLAGS) -o $@ $(filter %.v, $^)
>>> vcd/%.lxt: %.vvp
>>>            $< -lxt2 | tee $*.log
>>
>> To run vvp -v, I had to do
>>
>>> VERILOG=/usr/local/bin/iverilog
>>> VVP=$(subst iverilog,vvp,$(VERILOG)) -v
>>> VERILOGFLAGS = -v -Wall -Wno-timescale -DSIMULATION $($*_FLAGS)
>>> %.vvp: %.v
>>>            $(VERILOG) $(VERILOGFLAGS) -o $@ $(filter %.v,$^)
>>> vcd/%.lxt: %.vvp
>>>            $(VVP) -v $< -lxt2 | tee $*.log
>>
>> With the patch, the nice old rules default to pass -v to vvp.
>>
>> This came up, because I want to run
>>
>>        make VERILOG=/usr/local/test/bin/iverilog vcd/<FILE>.lxt
>>
>> and make sure the Makefile picks the correct vvp executable, and compare
>> the execution times reported by -v.
>>
>> Stephan
>>
>>> This is probably better than adding a different construct to the
>>> output file to pass the information and this patch works for one use
>>> case until vvp is modified so I don;t have an objection to it being
>>> added.
>>>
>>> FYI I run this as vvp <output_file> not as <output_file> or the
>>> slightly safer ./<output_file> since the later two make an assumption
>>> that <output_file> is a vvp simulation file which may not always be
>>> 100% true and in an extreme case could be used for nefarious reasons.
>>> I'm not a complete security nut so I do have . in my path, but it is
>>> last so <output_file> would find any other system executable instead
>>> of the vvp file I just generated if there was a name collision.
>>>
>>> Cary
>>>
>>> On Sunday, December 7, 2014 12:42 PM, "boe...@ph..."
>>> <boe...@ph...> wrote:
>>>
>>> Resent with subscribed From address ...
>>>
>>> Steven, Cary, Martin, ...
>>>
>>> please consider this patch to pass the -v flag from iverilog to vvp.
>>>
>>> Cheers, Stephan
>>>
>>> diff --git a/main.cc b/main.cc
>>> index 21d7232..b98c4d8 100644
>>> --- a/main.cc
>>> +++ b/main.cc
>>> @@ -859,6 +859,7 @@ int main(int argc, char*argv[])
>>> # if defined(HAVE_TIMES)
>>> times_flag = true;
>>> # endif
>>> + flags["VVP_EXTRA_ARG"] = strdup(" -v");
>>> break;
>>> case 'V':
>>> version_flag = true;
>>> diff --git a/tgt-vvp/vvp.c b/tgt-vvp/vvp.c
>>> index 55920f3..7cc180a 100644
>>> --- a/tgt-vvp/vvp.c
>>> +++ b/tgt-vvp/vvp.c
>>> @@ -59,7 +59,10 @@ __inline__ static void draw_execute_header
>>> (ivl_design_t des)
>>> {
>>> const char*cp = ivl_design_flag(des, "VVP_EXECUTABLE");
>>> if (cp) {
>>> - fprintf(vvp_out, "#! %s\n", cp);
>>> + const char *verbose_flag = ivl_design_flag(des, "VVP_EXTRA_ARG");
>>> + if (!verbose_flag)
>>> + verbose_flag = "";
>>> + fprintf(vvp_out, "#! %s%s\n", cp, verbose_flag);
>>> #if !defined(__MINGW32__)
>>> fchmod(fileno(vvp_out), 0755);
>>> #endif
>>
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>
>
>
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>

Re: [Iverilog-devel] pass -v to vvp in the #! header line

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

We need to make sure it is documented correctly (i.e. the two methods can produce different results).
Cary
 

     On Sunday, December 14, 2014 12:53 PM, Martin Whitaker <mai...@ma...> wrote:
   

 This seems reasonable to me. Unless anybody argues against it, I'll apply the 
patch.

boe...@ph... (Stephan Böttcher) wrote:
>
> Cary,
>
> "Cary R." <cy...@ya...> writes:
>
>> This looks reasonable, but it doesn't work for all use cases (e.g. vvp
>> <output_file>). We could modify vvp to look at the #! line to make
>> sure the flag is found.
>
> I don't think you want that flag to be found in all cases.  This is only
> for the case when you run the <outputfile> directly, and get the same
> verbosity as iverilog used.
>
> If you run the simulation as vvp <output_file>, you can add the -v flag
> at that occasion
>
>    vvp -v <output_file>
>
> If you run the outputfile as
>
>    ./<output_file> -v
>
> it does not work, since it translates to
>
>    /usr/local/bin/vvp <output_file> -v
>
> and in that position, the -v flag is ignored.
>
> man vvp(1):
>
>> EXTENDED ARGUMENTS
>>        The  vvp options described above must come before the design file name.
>>        After the design file name, however, there may be any number of unspec‐
>>        ified  arguments.  These  arguments  are not interpreted by vvp but are
>>        instead passed on to the executed design, and  are  available  via  the
>>        $test$plusargs and $value$plusargs system functions.
>
> I had the following Makefile rules:
>
>> VERILOG=/usr/local/bin/iverilog
>> VERILOGFLAGS = -v -Wall -Wno-timescale -DSIMULATION $($*_FLAGS)
>> %.vvp:
>>          $(VERILOG) $(VERILOGFLAGS) -o $@ $(filter %.v, $^)
>> vcd/%.lxt: %.vvp
>>          $< -lxt2 | tee $*.log
>
> To run vvp -v, I had to do
>
>> VERILOG=/usr/local/bin/iverilog
>> VVP=$(subst iverilog,vvp,$(VERILOG)) -v
>> VERILOGFLAGS = -v -Wall -Wno-timescale -DSIMULATION $($*_FLAGS)
>> %.vvp: %.v
>>          $(VERILOG) $(VERILOGFLAGS) -o $@ $(filter %.v,$^)
>> vcd/%.lxt: %.vvp
>>          $(VVP) -v $< -lxt2 | tee $*.log
>
> With the patch, the nice old rules default to pass -v to vvp.
>
> This came up, because I want to run
>
>      make VERILOG=/usr/local/test/bin/iverilog vcd/<FILE>.lxt
>
> and make sure the Makefile picks the correct vvp executable, and compare
> the execution times reported by -v.
>
> Stephan
>
>> This is probably better than adding a different construct to the
>> output file to pass the information and this patch works for one use
>> case until vvp is modified so I don;t have an objection to it being
>> added.
>>
>> FYI I run this as vvp <output_file> not as <output_file> or the
>> slightly safer ./<output_file> since the later two make an assumption
>> that <output_file> is a vvp simulation file which may not always be
>> 100% true and in an extreme case could be used for nefarious reasons.
>> I'm not a complete security nut so I do have . in my path, but it is
>> last so <output_file> would find any other system executable instead
>> of the vvp file I just generated if there was a name collision.
>>
>> Cary
>>
>> On Sunday, December 7, 2014 12:42 PM, "boe...@ph..."
>> <boe...@ph...> wrote:
>>
>> Resent with subscribed From address ...
>>
>> Steven, Cary, Martin, ...
>>
>> please consider this patch to pass the -v flag from iverilog to vvp.
>>
>> Cheers, Stephan
>>
>> diff --git a/main.cc b/main.cc
>> index 21d7232..b98c4d8 100644
>> --- a/main.cc
>> +++ b/main.cc
>> @@ -859,6 +859,7 @@ int main(int argc, char*argv[])
>> # if defined(HAVE_TIMES)
>> times_flag = true;
>> # endif
>> + flags["VVP_EXTRA_ARG"] = strdup(" -v");
>> break;
>> case 'V':
>> version_flag = true;
>> diff --git a/tgt-vvp/vvp.c b/tgt-vvp/vvp.c
>> index 55920f3..7cc180a 100644
>> --- a/tgt-vvp/vvp.c
>> +++ b/tgt-vvp/vvp.c
>> @@ -59,7 +59,10 @@ __inline__ static void draw_execute_header
>> (ivl_design_t des)
>> {
>> const char*cp = ivl_design_flag(des, "VVP_EXECUTABLE");
>> if (cp) {
>> - fprintf(vvp_out, "#! %s\n", cp);
>> + const char *verbose_flag = ivl_design_flag(des, "VVP_EXTRA_ARG");
>> + if (!verbose_flag)
>> + verbose_flag = "";
>> + fprintf(vvp_out, "#! %s%s\n", cp, verbose_flag);
>> #if !defined(__MINGW32__)
>> fchmod(fileno(vvp_out), 0755);
>> #endif
>


------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel


   

Re: [Iverilog-devel] pass -v to vvp in the #! header line

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

This seems reasonable to me. Unless anybody argues against it, I'll apply the 
patch.

boe...@ph... (Stephan Böttcher) wrote:
>
> Cary,
>
> "Cary R." <cy...@ya...> writes:
>
>> This looks reasonable, but it doesn't work for all use cases (e.g. vvp
>> <output_file>). We could modify vvp to look at the #! line to make
>> sure the flag is found.
>
> I don't think you want that flag to be found in all cases.  This is only
> for the case when you run the <outputfile> directly, and get the same
> verbosity as iverilog used.
>
> If you run the simulation as vvp <output_file>, you can add the -v flag
> at that occasion
>
>    vvp -v <output_file>
>
> If you run the outputfile as
>
>    ./<output_file> -v
>
> it does not work, since it translates to
>
>    /usr/local/bin/vvp <output_file> -v
>
> and in that position, the -v flag is ignored.
>
> man vvp(1):
>
>> EXTENDED ARGUMENTS
>>         The  vvp options described above must come before the design file name.
>>         After the design file name, however, there may be any number of unspec‐
>>         ified  arguments.  These  arguments  are not interpreted by vvp but are
>>         instead passed on to the executed design, and  are  available  via  the
>>         $test$plusargs and $value$plusargs system functions.
>
> I had the following Makefile rules:
>
>> VERILOG=/usr/local/bin/iverilog
>> VERILOGFLAGS = -v -Wall -Wno-timescale -DSIMULATION $($*_FLAGS)
>> %.vvp:
>>          $(VERILOG) $(VERILOGFLAGS) -o $@ $(filter %.v, $^)
>> vcd/%.lxt: %.vvp
>>          $< -lxt2 | tee $*.log
>
> To run vvp -v, I had to do
>
>> VERILOG=/usr/local/bin/iverilog
>> VVP=$(subst iverilog,vvp,$(VERILOG)) -v
>> VERILOGFLAGS = -v -Wall -Wno-timescale -DSIMULATION $($*_FLAGS)
>> %.vvp: %.v
>>          $(VERILOG) $(VERILOGFLAGS) -o $@ $(filter %.v,$^)
>> vcd/%.lxt: %.vvp
>>          $(VVP) -v $< -lxt2 | tee $*.log
>
> With the patch, the nice old rules default to pass -v to vvp.
>
> This came up, because I want to run
>
>       make VERILOG=/usr/local/test/bin/iverilog vcd/<FILE>.lxt
>
> and make sure the Makefile picks the correct vvp executable, and compare
> the execution times reported by -v.
>
> Stephan
>
>> This is probably better than adding a different construct to the
>> output file to pass the information and this patch works for one use
>> case until vvp is modified so I don;t have an objection to it being
>> added.
>>
>> FYI I run this as vvp <output_file> not as <output_file> or the
>> slightly safer ./<output_file> since the later two make an assumption
>> that <output_file> is a vvp simulation file which may not always be
>> 100% true and in an extreme case could be used for nefarious reasons.
>> I'm not a complete security nut so I do have . in my path, but it is
>> last so <output_file> would find any other system executable instead
>> of the vvp file I just generated if there was a name collision.
>>
>> Cary
>>
>> On Sunday, December 7, 2014 12:42 PM, "boe...@ph..."
>> <boe...@ph...> wrote:
>>
>> Resent with subscribed From address ...
>>
>> Steven, Cary, Martin, ...
>>
>> please consider this patch to pass the -v flag from iverilog to vvp.
>>
>> Cheers, Stephan
>>
>> diff --git a/main.cc b/main.cc
>> index 21d7232..b98c4d8 100644
>> --- a/main.cc
>> +++ b/main.cc
>> @@ -859,6 +859,7 @@ int main(int argc, char*argv[])
>> # if defined(HAVE_TIMES)
>> times_flag = true;
>> # endif
>> + flags["VVP_EXTRA_ARG"] = strdup(" -v");
>> break;
>> case 'V':
>> version_flag = true;
>> diff --git a/tgt-vvp/vvp.c b/tgt-vvp/vvp.c
>> index 55920f3..7cc180a 100644
>> --- a/tgt-vvp/vvp.c
>> +++ b/tgt-vvp/vvp.c
>> @@ -59,7 +59,10 @@ __inline__ static void draw_execute_header
>> (ivl_design_t des)
>> {
>> const char*cp = ivl_design_flag(des, "VVP_EXECUTABLE");
>> if (cp) {
>> - fprintf(vvp_out, "#! %s\n", cp);
>> + const char *verbose_flag = ivl_design_flag(des, "VVP_EXTRA_ARG");
>> + if (!verbose_flag)
>> + verbose_flag = "";
>> + fprintf(vvp_out, "#! %s%s\n", cp, verbose_flag);
>> #if !defined(__MINGW32__)
>> fchmod(fileno(vvp_out), 0755);
>> #endif
>

Re: [Iverilog-devel] vec4-stack merge

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

I have pushed patches that fix the 32-bit issues found in the test suite. I also needed to update a gold file in the test suite (br_gh13a).
Cary
 

     On Wednesday, December 10, 2014 11:33 AM, Cary R. <cy...@ya...> wrote:
   

 As was likely expected the vec4-stack changes broke compiling with valgrind support. I will work on that and look for memory leaks in the new code later.
A critical issues is that 32-bit support is broken, some tests are failing and one (pr1625912) is locking up in an infinite loop. I will look at fixing this as soon as I have some free time. Hopefully later today or tomorrow.

Cary 

     On Tuesday, December 9, 2014 6:03 PM, Cary R. <cy...@ya...> wrote:
   

 No example, but a patch has been pushed that fixes the problems in the non-blocking assignment to array words. There were a few cases where it was more than just extra code being generated since the error state was being partially lost. I didn't generate actual tests for testing this, but checked many combinations to verify that the generated code looked correct. The errors were related to having both a variable array index and variable part select offset (indexed part select). There are still a few cases where some extra flag code is begin generated, but it should be fully functional now.

There is still extra flag code being generated for a blocking constant part select assignment to an array word, but all the combinations appear to be generating correct code.
Cary 

     On Tuesday, December 9, 2014 8:30 AM, Stephen Williams <st...@ic...> wrote:
   

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

On 12/08/2014 09:41 PM, Cary R. wrote:
> It also looks like the compiler generated code for array accesses
> may be doing more work than is required. It is using flag 4 to
> indicate an undefined index (a predicate flag for the stores), but
> I'm not sure what all the flag 8 control is for since I couldn't
> find where it was actually used.

There are surely going to be cases where the code generator is
not writing optimal code. Now that the vec4-stack code is the
main line, many more eyes is catching stuff like this.

Concrete examples would help.

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

iEYEARECAAYFAlSHI3cACgkQrPt1Sc2b3ilGwQCgt8Cs5ExMCO2HwBokZ8xKg5+t
e80Ani3472JuhhhV+PCxgA+cP+wU05tR
=c7fG
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel


    

    

   

Re: [Iverilog-devel] vec4-stack merge

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

As was likely expected the vec4-stack changes broke compiling with valgrind support. I will work on that and look for memory leaks in the new code later.
A critical issues is that 32-bit support is broken, some tests are failing and one (pr1625912) is locking up in an infinite loop. I will look at fixing this as soon as I have some free time. Hopefully later today or tomorrow.

Cary 

     On Tuesday, December 9, 2014 6:03 PM, Cary R. <cy...@ya...> wrote:
   

 No example, but a patch has been pushed that fixes the problems in the non-blocking assignment to array words. There were a few cases where it was more than just extra code being generated since the error state was being partially lost. I didn't generate actual tests for testing this, but checked many combinations to verify that the generated code looked correct. The errors were related to having both a variable array index and variable part select offset (indexed part select). There are still a few cases where some extra flag code is begin generated, but it should be fully functional now.

There is still extra flag code being generated for a blocking constant part select assignment to an array word, but all the combinations appear to be generating correct code.
Cary 

     On Tuesday, December 9, 2014 8:30 AM, Stephen Williams <st...@ic...> wrote:
   

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

On 12/08/2014 09:41 PM, Cary R. wrote:
> It also looks like the compiler generated code for array accesses
> may be doing more work than is required. It is using flag 4 to
> indicate an undefined index (a predicate flag for the stores), but
> I'm not sure what all the flag 8 control is for since I couldn't
> find where it was actually used.

There are surely going to be cases where the code generator is
not writing optimal code. Now that the vec4-stack code is the
main line, many more eyes is catching stuff like this.

Concrete examples would help.

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

iEYEARECAAYFAlSHI3cACgkQrPt1Sc2b3ilGwQCgt8Cs5ExMCO2HwBokZ8xKg5+t
e80Ani3472JuhhhV+PCxgA+cP+wU05tR
=c7fG
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel


    

   

Re: [Iverilog-devel] vec4-stack merge

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

No example, but a patch has been pushed that fixes the problems in the non-blocking assignment to array words. There were a few cases where it was more than just extra code being generated since the error state was being partially lost. I didn't generate actual tests for testing this, but checked many combinations to verify that the generated code looked correct. The errors were related to having both a variable array index and variable part select offset (indexed part select). There are still a few cases where some extra flag code is begin generated, but it should be fully functional now.

There is still extra flag code being generated for a blocking constant part select assignment to an array word, but all the combinations appear to be generating correct code.
Cary 

     On Tuesday, December 9, 2014 8:30 AM, Stephen Williams <st...@ic...> wrote:
   

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

On 12/08/2014 09:41 PM, Cary R. wrote:
> It also looks like the compiler generated code for array accesses
> may be doing more work than is required. It is using flag 4 to
> indicate an undefined index (a predicate flag for the stores), but
> I'm not sure what all the flag 8 control is for since I couldn't
> find where it was actually used.

There are surely going to be cases where the code generator is
not writing optimal code. Now that the vec4-stack code is the
main line, many more eyes is catching stuff like this.

Concrete examples would help.

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

iEYEARECAAYFAlSHI3cACgkQrPt1Sc2b3ilGwQCgt8Cs5ExMCO2HwBokZ8xKg5+t
e80Ani3472JuhhhV+PCxgA+cP+wU05tR
=c7fG
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel


   

Re: [Iverilog-devel] vec4-stack merge

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

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

On 12/08/2014 09:41 PM, Cary R. wrote:
> It also looks like the compiler generated code for array accesses
> may be doing more work than is required. It is using flag 4 to
> indicate an undefined index (a predicate flag for the stores), but
> I'm not sure what all the flag 8 control is for since I couldn't
> find where it was actually used.

There are surely going to be cases where the code generator is
not writing optimal code. Now that the vec4-stack code is the
main line, many more eyes is catching stuff like this.

Concrete examples would help.

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

iEYEARECAAYFAlSHI3cACgkQrPt1Sc2b3ilGwQCgt8Cs5ExMCO2HwBokZ8xKg5+t
e80Ani3472JuhhhV+PCxgA+cP+wU05tR
=c7fG
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] vec4-stack merge

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

After spending a number of hours reworking all the examples in the vvp/examples directory to run under the new stack based version of vvp (yes even the completely outdated memory.vvp file). I will say there needs to be some significant updates to the documentation/comments. I spent a significant amount of time looking at vthread.cc trying to understand the new commands I needed to use and how they operate.
It also looks like the compiler generated code for array accesses may be doing more work than is required. It is using flag 4 to indicate an undefined index (a predicate flag for the stores), but I'm not sure what all the flag 8 control is for since I couldn't find where it was actually used. This was found while rewriting memory.vvp. I'm guessing there is or was a good reason for this (possibly as a jump flag), but I missed it in my first pass over the new commands.
Cary 

     On Monday, December 8, 2014 4:06 PM, Cary R. <cy...@ya...> wrote:
   

 I would assume that this special object would remove the requirement for the stacks as far as the system tasks/functions were concerned since you cannot know for sure that a value calculated before the call is acceptable or not. You also have to deal with the sensitivity issue, but yes evaluating the function on demand is what I was proposing (i.e. the special object just pops a single value off the stack after executing the anonymous function). This all implies that function call/return overhead will be critical. we are specifically talking about br681, but the same idea could likely be used for br772, br605 and br495. Some of these need the sensitivity list others just need anonymous function support.
What we are discussing here is the high level part of the expression rework. Most of the actual work I have done on this in the past was focused at the lower level implementation so there's no duplication of effort if we implement this using the existing infrastructure. 

I will note that this is complicated by br495 where we need to be able to traverse the expression in some manner to see if it matches during SDF back annotation (i.e. the condition expression is part of the match criteria). Maybe just keeping a string representation is enough for now.

Cary
 

     On Monday, December 8, 2014 3:38 PM, Stephen Williams <st...@ic...> wrote:
   

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

On 12/08/2014 03:23 PM, Cary R. wrote:
> For example: $strobe(a+1); should push an expression (pointer?) a+1
> onto the vec4 stack that when used is evaluated and the calculated
> value is returned.

True, but this never worked for the pre-stacked method either.

Off the cuff, I propose that we make a special object that is
a thread that calculates the value by running the function, and
wrap that expression thread into a VPI expression object. Thus,
there is no stack extension, in fact the existing instruction
set is used to evaluate the function on demand.

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

iEYEARECAAYFAlSGNmUACgkQrPt1Sc2b3inVpACeK9QOnT0TS6AOwxFnxSUeKMDM
EUcAn3s6Kghmt9mMDpb1x4GJgTFO+2z5
=DsWC
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel