Menu
▾
▴
iverilog-devel — Conversations on matters of Icarus Verilog development
You can subscribe to this list here.
| 2008 |
Jan
(98) |
Feb
(33) |
Mar
(60) |
Apr
(126) |
May
(186) |
Jun
(65) |
Jul
(19) |
Aug
(95) |
Sep
(86) |
Oct
(81) |
Nov
(46) |
Dec
(87) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2009 |
Jan
(47) |
Feb
(79) |
Mar
(138) |
Apr
(44) |
May
(113) |
Jun
(133) |
Jul
(59) |
Aug
(84) |
Sep
(87) |
Oct
(65) |
Nov
(51) |
Dec
(141) |
| 2010 |
Jan
(63) |
Feb
(22) |
Mar
(28) |
Apr
(41) |
May
(59) |
Jun
(18) |
Jul
(7) |
Aug
(11) |
Sep
(85) |
Oct
(28) |
Nov
(51) |
Dec
(16) |
| 2011 |
Jan
(29) |
Feb
(35) |
Mar
(65) |
Apr
(106) |
May
(58) |
Jun
(8) |
Jul
(34) |
Aug
(52) |
Sep
(15) |
Oct
(32) |
Nov
(81) |
Dec
(69) |
| 2012 |
Jan
(50) |
Feb
(18) |
Mar
(47) |
Apr
(21) |
May
(12) |
Jun
(27) |
Jul
(4) |
Aug
(31) |
Sep
(15) |
Oct
(31) |
Nov
(2) |
Dec
(13) |
| 2013 |
Jan
(6) |
Feb
(1) |
Mar
(4) |
Apr
(7) |
May
(30) |
Jun
(7) |
Jul
(53) |
Aug
(60) |
Sep
(30) |
Oct
(38) |
Nov
(20) |
Dec
(12) |
| 2014 |
Jan
(8) |
Feb
(21) |
Mar
(15) |
Apr
(13) |
May
(1) |
Jun
(5) |
Jul
(23) |
Aug
(57) |
Sep
(7) |
Oct
(9) |
Nov
(32) |
Dec
(45) |
| 2015 |
Jan
(35) |
Feb
(16) |
Mar
(29) |
Apr
(20) |
May
(55) |
Jun
(37) |
Jul
(5) |
Aug
(25) |
Sep
(2) |
Oct
(3) |
Nov
(6) |
Dec
(8) |
| 2016 |
Jan
(23) |
Feb
(15) |
Mar
(39) |
Apr
(9) |
May
(4) |
Jun
(11) |
Jul
(5) |
Aug
(1) |
Sep
(1) |
Oct
(3) |
Nov
(12) |
Dec
(1) |
| 2017 |
Jan
(1) |
Feb
(4) |
Mar
(7) |
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(4) |
Oct
(13) |
Nov
(6) |
Dec
(4) |
| 2018 |
Jan
(26) |
Feb
(4) |
Mar
(5) |
Apr
(6) |
May
(1) |
Jun
(2) |
Jul
(9) |
Aug
|
Sep
(1) |
Oct
(5) |
Nov
|
Dec
(1) |
| 2019 |
Jan
(8) |
Feb
|
Mar
(6) |
Apr
|
May
|
Jun
(6) |
Jul
|
Aug
(40) |
Sep
(7) |
Oct
(23) |
Nov
(16) |
Dec
(8) |
| 2020 |
Jan
(3) |
Feb
(15) |
Mar
|
Apr
|
May
(27) |
Jun
(7) |
Jul
(2) |
Aug
(9) |
Sep
(32) |
Oct
(23) |
Nov
(6) |
Dec
(3) |
| 2021 |
Jan
(10) |
Feb
(1) |
Mar
(4) |
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
(3) |
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2023 |
Jan
(2) |
Feb
|
Mar
(4) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Stephen W. <st...@ic...> - 2019-10-09 16:38:55
|
Here's a question. There is this: priority case (foo) 1: stmt1; 2: stmt2; default: stmt_default; endcase The priority case "shall issue a violation report if no case_item matches." The default: statement makes it so that every possible value of foo has a case item, if the "default" case is considered a case item, and by the BNF, it is indeed a case_item. But the "default:" makes the "priority" moot. So should this print a violation message or not? (I'm thinking, it should not, but a compile time warning may make sense. But I can see logic for the other course too.) -- Steve Williams "The woods are lovely, dark and deep. st...@ic... 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." |
|
From: Cary R. <cy...@ya...> - 2019-09-30 03:24:11
|
I have pushed a fix that should prevent the sensitivity calculation for always_comb from going into an infinite loop when it contains a recursive function call.
Cary
On Sunday, September 29, 2019, 5:59:11 PM PDT, Cary R. via Iverilog-devel <ive...@li...> wrote:
Hi Martin,
What is the always_comb problem? Is it the sensitivity calculation for recursive functions? I'll test something like that and if it gets stuck in an inf loop I'll look at fixing it.
Cary
On Friday, September 27, 2019, 3:22:23 PM PDT, Martin Whitaker <ic...@ma...> wrote:
Recursive functions have been supported for a long time. See
https://github.com/steveicarus/ivtest/blob/master/ivltests/recursive_func.v
Trying to compile the sha_mainloop.sv file from that GitHub project shows
it is the always_comb construct that is causing the problem. Change it to
an always @*, and the module compiles without error.
fuyong wrote:
> Hi,
>
> We have download a design from Github. This design can run correctly in
> VCS. But iVeriog compile hang.
>
> https://github.com/unixb0y/SystemVerilogSHA256
>
> Guess it is the following function (recursive function as it call itself)
> cause the issue:
>
> function automatic [31:0] W;
> input [6:0] x;
> input [6:0] y;
> if(^x === 1'bX) W = 32'h777;
> else W = (x<16) ? padded[((PADDED_SIZE-1-y*512)-x*32) -: 32] :
> rho1(W(x-2, y)) + W(x-7, y) + rho0(W(x-15, y)) + W(x-16, y);
> endfunction
>
> Any suggestions on how to change the code for workaround? Or enhancement in
> iVerilog :-) ?
>
> Thanks,
> Yong
>
>
>
>
>
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>
_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel
_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel
|
|
From: Cary R. <cy...@ya...> - 2019-09-30 00:58:47
|
Hi Martin,
What is the always_comb problem? Is it the sensitivity calculation for recursive functions? I'll test something like that and if it gets stuck in an inf loop I'll look at fixing it.
Cary
On Friday, September 27, 2019, 3:22:23 PM PDT, Martin Whitaker <ic...@ma...> wrote:
Recursive functions have been supported for a long time. See
https://github.com/steveicarus/ivtest/blob/master/ivltests/recursive_func.v
Trying to compile the sha_mainloop.sv file from that GitHub project shows
it is the always_comb construct that is causing the problem. Change it to
an always @*, and the module compiles without error.
fuyong wrote:
> Hi,
>
> We have download a design from Github. This design can run correctly in
> VCS. But iVeriog compile hang.
>
> https://github.com/unixb0y/SystemVerilogSHA256
>
> Guess it is the following function (recursive function as it call itself)
> cause the issue:
>
> function automatic [31:0] W;
> input [6:0] x;
> input [6:0] y;
> if(^x === 1'bX) W = 32'h777;
> else W = (x<16) ? padded[((PADDED_SIZE-1-y*512)-x*32) -: 32] :
> rho1(W(x-2, y)) + W(x-7, y) + rho0(W(x-15, y)) + W(x-16, y);
> endfunction
>
> Any suggestions on how to change the code for workaround? Or enhancement in
> iVerilog :-) ?
>
> Thanks,
> Yong
>
>
>
>
>
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>
_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel
|
|
From: Martin W. <ic...@ma...> - 2019-09-27 22:22:04
|
Recursive functions have been supported for a long time. See https://github.com/steveicarus/ivtest/blob/master/ivltests/recursive_func.v Trying to compile the sha_mainloop.sv file from that GitHub project shows it is the always_comb construct that is causing the problem. Change it to an always @*, and the module compiles without error. fuyong wrote: > Hi, > > We have download a design from Github. This design can run correctly in > VCS. But iVeriog compile hang. > > https://github.com/unixb0y/SystemVerilogSHA256 > > Guess it is the following function (recursive function as it call itself) > cause the issue: > > function automatic [31:0] W; > input [6:0] x; > input [6:0] y; > if(^x === 1'bX) W = 32'h777; > else W = (x<16) ? padded[((PADDED_SIZE-1-y*512)-x*32) -: 32] : > rho1(W(x-2, y)) + W(x-7, y) + rho0(W(x-15, y)) + W(x-16, y); > endfunction > > Any suggestions on how to change the code for workaround? Or enhancement in > iVerilog :-) ? > > Thanks, > Yong > > > > > > _______________________________________________ > Iverilog-devel mailing list > Ive...@li... > https://lists.sourceforge.net/lists/listinfo/iverilog-devel > |
|
From: fuyong <fuy...@gm...> - 2019-09-27 08:16:14
|
Hi, We have download a design from Github. This design can run correctly in VCS. But iVeriog compile hang. https://github.com/unixb0y/SystemVerilogSHA256 Guess it is the following function (recursive function as it call itself) cause the issue: function automatic [31:0] W; input [6:0] x; input [6:0] y; if(^x === 1'bX) W = 32'h777; else W = (x<16) ? padded[((PADDED_SIZE-1-y*512)-x*32) -: 32] : rho1(W(x-2, y)) + W(x-7, y) + rho0(W(x-15, y)) + W(x-16, y); endfunction Any suggestions on how to change the code for workaround? Or enhancement in iVerilog :-) ? Thanks, Yong |
|
From: Martin W. <ic...@ma...> - 2019-09-12 07:31:18
|
Yes, the SV timeunit should be fully supported. The warning is there more for users of the `timescale directive. Because that applies across file boundaries, behaviour can depend on the order in which files are compiled if not all files have an explicit timescale. Note that in your example, importing the package does not import the timescale. Galen Seitz wrote: > Hi, > > Is SystemVerilog timeunit supported? I see that there are > some timeunit tests in regress-sv.list. > > I have timeunit inside a package which I am importing into > a module, but I get a related warning. This is the first > time I have attempted to use timeunit, so there's a good > chance I'm doing something wrong. > > package my_globals; > timeunit 1ns/1ns; > ... > endpackage > > module flags > import my_globals::*; > #(parameter I_WIDTH = 18) > ( > input clock, > input reset, > input fsm_out_t fsm_out, > input [I_WIDTH-1:0] instr, > input carry, > input zero, > output logic carry_flag, > output logic ie_flag, > output logic zero_flag > ); > ... > endmodule > > [galens@toto]$ iverilog -Wall -g2012 my_globals.sv flags.sv -o /dev/null > warning: Some design elements have no explicit time unit and/or > : time precision. This may cause confusing timing results. > : Affected design elements are: > : -- module flags declared here: flags.sv:3 > > > Also on the subject of SystemVerilog, support for case...inside would > really be useful. Of course from my perspective, any support for more of > the synthesizable constructs would be welcome. > > > thanks, > galen > |
|
From: Galen S. <ga...@se...> - 2019-09-10 00:25:43
|
Hi,
Is SystemVerilog timeunit supported? I see that there are
some timeunit tests in regress-sv.list.
I have timeunit inside a package which I am importing into
a module, but I get a related warning. This is the first
time I have attempted to use timeunit, so there's a good
chance I'm doing something wrong.
package my_globals;
timeunit 1ns/1ns;
...
endpackage
module flags
import my_globals::*;
#(parameter I_WIDTH = 18)
(
input clock,
input reset,
input fsm_out_t fsm_out,
input [I_WIDTH-1:0] instr,
input carry,
input zero,
output logic carry_flag,
output logic ie_flag,
output logic zero_flag
);
...
endmodule
[galens@toto]$ iverilog -Wall -g2012 my_globals.sv flags.sv -o /dev/null
warning: Some design elements have no explicit time unit and/or
: time precision. This may cause confusing timing results.
: Affected design elements are:
: -- module flags declared here: flags.sv:3
Also on the subject of SystemVerilog, support for case...inside would
really be useful. Of course from my perspective, any support for more of
the synthesizable constructs would be welcome.
thanks,
galen
--
Galen Seitz
ga...@se...
|
|
From: Stefan D. <Dr...@ri...> - 2019-09-04 09:11:09
|
Thank you Martin, this fixed the issues for me. Meanwhile Xilinx also responded to the bug report about the issue with the comma instead of dot in the generated SDF file. Its not going to be fixed in the upcoming release, but its on their radar and then hopefully the fixed in the release after that. Best, Stefan -----Original Message----- From: Stefan Droege via Iverilog-devel [mailto:ive...@li...] Sent: maandag 26 augustus 2019 09:21 To: Discussions concerning Icarus Verilog development <ive...@li...> Cc: Stefan Droege <Dr...@ri...> Subject: Re: [Iverilog-devel] Make iverilog accept (but ignore) unsupported SDF constructs. Thank you Martin! I'll check it out. -----Original Message----- From: Martin Whitaker [mailto:ic...@ma...] Sent: zaterdag 24 augustus 2019 01:35 To: ive...@li... Subject: Re: [Iverilog-devel] Make iverilog accept (but ignore) unsupported SDF constructs. I've added support for the PATHPULSE, PATHPULSEPERCENT, and PERIOD constructs in the master branch. They are now accepted but silently ignored (like most other SDF timing checks). Stefan Droege via Iverilog-devel wrote: > Hmm you're right that doesn’t meet the spec. I assume line 14 should read > `(PATHPULSEPERCENT (30.0))` > instead. > > I'll try and see whether this is an issue with locale settings, as my locale uses `,` as decimal separator. Interestingly all other values in the sdf file use `.` as decimal separator. In any case I think its worth that I mention this to Xilinx support because if the decimal spearator depends on the locale it should at least be consistent throughout the file. > > Martin, do you think you could add the support for these constructs and test it with the snippet after manually fixing the `30,0` to be a `30.0` until I hear back from Xilinx? > > > -----Original Message----- > From: Martin Whitaker [mailto:ic...@ma...] > Sent: zaterdag 17 augustus 2019 14:26 > To: ive...@li... > Subject: Re: [Iverilog-devel] Make iverilog accept (but ignore) unsupported SDF constructs. > > It shouldn't be hard to add support for those keywords in the SDF > parser, but the syntax used for the PATHPULSEPERCENT delay > specification in your example doesn't match what I find in the SDF 3.0 > spec. The spec. says > > deltype ::= ... > ||= ( PATHPULSEPERCENT input_output_path? value value? ) > ... > > value ::= ( NUMBER? ) > ||= (triple?) > > NUMBER is a single number. triple is three numbers separated by colons. So what does two numbers separated by a comma mean? > > Stefan Droege via Iverilog-devel wrote: >> Hi everyone, >> >> I was trying to run a post-synthesis simulation using iverilog with a netlist generated by Xilinx Vivado. >> >> I ran into a problem that iverilog complains about the SDF file containing invalid syntax, as some of the keywords are not implemented in iverilogs sdf parser. The problematic constructs for my case are `PATHPULSEPERCENT` within the `DELAY` construct and `PERIOD` within the `TIMINGCHECK` construct. See the end of the email for a snippet of the sdf file. >> >> >> >> I checked the IEEE1497-2001 standard and the problematic constructs >> are valid as far as I can see (so no Xilinx specific weirdness here) >> >> >> >> I dont really need the functionality offered by these constructs, but it would be nice if iverilog could still accept the file as valid and simulate only with the supported subset, maybe printing a warning about what was ignored. >> >> >> >> The problematic sdf code: >> >> >> >> (DELAYFILE >> >> (SDFVERSION "3.0" ) >> >> (DESIGN "top") >> >> (DATE "Tue Aug 13 18:03:42 2019") >> >> (VENDOR "XILINX") >> >> (PROGRAM "Vivado") >> >> (VERSION "2019.1") >> >> (DIVIDER /) >> >> (TIMESCALE 1ps) >> >> (CELL >> >> (CELLTYPE "BUFGCE") >> >> (INSTANCE clk_IBUF_BUFG_inst) >> >> (DELAY >> >> (PATHPULSEPERCENT (30,0)) >> >> (ABSOLUTE >> >> (IOPATH I O (40.0:47.0:47.0) (40.0:47.0:47.0)) >> >> ) >> >> ) >> >> (TIMINGCHECK >> >> (SETUPHOLD (posedge CE) (posedge I) (84.0:275.0:275.0) >> (0.0:0.0:0.0)) >> >> (SETUPHOLD (negedge CE) (posedge I) (84.0:275.0:275.0) >> (0.0:0.0:0.0)) >> >> (PERIOD (posedge I) (1499.0:1499.0:1499.0)) >> >> (PERIOD (negedge I) (1499.0:1499.0:1499.0)) >> >> (WIDTH (negedge CE) (550.0:550.0:550.0)) >> >> (WIDTH (posedge CE) (550.0:550.0:550.0)) >> >> ) >> >> ) >> >> ) >> >> >> >> >> >> Kind Regards, Stefan >> >> >> >> >> >> >> _______________________________________________ >> Iverilog-devel mailing list >> Ive...@li... >> https://lists.sourceforge.net/lists/listinfo/iverilog-devel >> > > > > _______________________________________________ > Iverilog-devel mailing list > Ive...@li... > https://lists.sourceforge.net/lists/listinfo/iverilog-devel > > > > > > _______________________________________________ > Iverilog-devel mailing list > Ive...@li... > https://lists.sourceforge.net/lists/listinfo/iverilog-devel > _______________________________________________ Iverilog-devel mailing list Ive...@li... https://lists.sourceforge.net/lists/listinfo/iverilog-devel |
|
From: Cary R. <cy...@ya...> - 2019-08-27 02:49:54
|
Surprisingly, Steve is the odd man out being the only one who primarily works as a programmer. Both Martin and I are are primarily chip designers. There are multiple ways to contribute. You could start just documenting what is implemented and get us good release notes for V10 and what has been added to development which will eventually become V11. If you want to help with the code then what is your experience in C++? There are many other ways to help if we know your background and what interests you.
Cary
On Monday, August 26, 2019, 12:02:28 AM PDT, Hagen SANKOWSKI <hs...@no...> wrote:
Hello Martin.
Quoting Martin Whitaker <ic...@ma...>:
>> What's about the support for SystemVerilog?
>> Are there some planes to support SystemVerilog?
>
> There is already support for some SystemVerilog features.
> Unfortunately there's no definitive list of what is or isn't
> supported, but you can look in the test suite to get an idea:
>
> https://github.com/steveicarus/ivtest/blob/master/regress-sv.list
>
> Cary intends to complete the support for always_comb et al., but I'm
> not aware of any plans to add support for more features.
Thanks to point me to the test suite..
Indeed it is a good resource for investigation. I like to support the
effort to widen the list of supported SystemVerilog features up to
IEEE 1800-2017 (which is IMHO a good stable language feature set).
Unfortunately I am VLSI chip designer, not a programmer..
Let's see, what I can do so far.
Regards,
Hagen Sankowski
--
"They who can give up essential liberty to obtain a little temporary
safety, deserve neither liberty nor safety." Benjamin Franklin (1775)
_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel
|
|
From: Stefan D. <Dr...@ri...> - 2019-08-26 08:55:31
|
Thank you Martin! I'll check it out. -----Original Message----- From: Martin Whitaker [mailto:ic...@ma...] Sent: zaterdag 24 augustus 2019 01:35 To: ive...@li... Subject: Re: [Iverilog-devel] Make iverilog accept (but ignore) unsupported SDF constructs. I've added support for the PATHPULSE, PATHPULSEPERCENT, and PERIOD constructs in the master branch. They are now accepted but silently ignored (like most other SDF timing checks). Stefan Droege via Iverilog-devel wrote: > Hmm you're right that doesn’t meet the spec. I assume line 14 should read > `(PATHPULSEPERCENT (30.0))` > instead. > > I'll try and see whether this is an issue with locale settings, as my locale uses `,` as decimal separator. Interestingly all other values in the sdf file use `.` as decimal separator. In any case I think its worth that I mention this to Xilinx support because if the decimal spearator depends on the locale it should at least be consistent throughout the file. > > Martin, do you think you could add the support for these constructs and test it with the snippet after manually fixing the `30,0` to be a `30.0` until I hear back from Xilinx? > > > -----Original Message----- > From: Martin Whitaker [mailto:ic...@ma...] > Sent: zaterdag 17 augustus 2019 14:26 > To: ive...@li... > Subject: Re: [Iverilog-devel] Make iverilog accept (but ignore) unsupported SDF constructs. > > It shouldn't be hard to add support for those keywords in the SDF > parser, but the syntax used for the PATHPULSEPERCENT delay > specification in your example doesn't match what I find in the SDF 3.0 > spec. The spec. says > > deltype ::= ... > ||= ( PATHPULSEPERCENT input_output_path? value value? ) > ... > > value ::= ( NUMBER? ) > ||= (triple?) > > NUMBER is a single number. triple is three numbers separated by colons. So what does two numbers separated by a comma mean? > > Stefan Droege via Iverilog-devel wrote: >> Hi everyone, >> >> I was trying to run a post-synthesis simulation using iverilog with a netlist generated by Xilinx Vivado. >> >> I ran into a problem that iverilog complains about the SDF file containing invalid syntax, as some of the keywords are not implemented in iverilogs sdf parser. The problematic constructs for my case are `PATHPULSEPERCENT` within the `DELAY` construct and `PERIOD` within the `TIMINGCHECK` construct. See the end of the email for a snippet of the sdf file. >> >> >> >> I checked the IEEE1497-2001 standard and the problematic constructs >> are valid as far as I can see (so no Xilinx specific weirdness here) >> >> >> >> I dont really need the functionality offered by these constructs, but it would be nice if iverilog could still accept the file as valid and simulate only with the supported subset, maybe printing a warning about what was ignored. >> >> >> >> The problematic sdf code: >> >> >> >> (DELAYFILE >> >> (SDFVERSION "3.0" ) >> >> (DESIGN "top") >> >> (DATE "Tue Aug 13 18:03:42 2019") >> >> (VENDOR "XILINX") >> >> (PROGRAM "Vivado") >> >> (VERSION "2019.1") >> >> (DIVIDER /) >> >> (TIMESCALE 1ps) >> >> (CELL >> >> (CELLTYPE "BUFGCE") >> >> (INSTANCE clk_IBUF_BUFG_inst) >> >> (DELAY >> >> (PATHPULSEPERCENT (30,0)) >> >> (ABSOLUTE >> >> (IOPATH I O (40.0:47.0:47.0) (40.0:47.0:47.0)) >> >> ) >> >> ) >> >> (TIMINGCHECK >> >> (SETUPHOLD (posedge CE) (posedge I) (84.0:275.0:275.0) >> (0.0:0.0:0.0)) >> >> (SETUPHOLD (negedge CE) (posedge I) (84.0:275.0:275.0) >> (0.0:0.0:0.0)) >> >> (PERIOD (posedge I) (1499.0:1499.0:1499.0)) >> >> (PERIOD (negedge I) (1499.0:1499.0:1499.0)) >> >> (WIDTH (negedge CE) (550.0:550.0:550.0)) >> >> (WIDTH (posedge CE) (550.0:550.0:550.0)) >> >> ) >> >> ) >> >> ) >> >> >> >> >> >> Kind Regards, Stefan >> >> >> >> >> >> >> _______________________________________________ >> Iverilog-devel mailing list >> Ive...@li... >> https://lists.sourceforge.net/lists/listinfo/iverilog-devel >> > > > > _______________________________________________ > Iverilog-devel mailing list > Ive...@li... > https://lists.sourceforge.net/lists/listinfo/iverilog-devel > > > > > > _______________________________________________ > Iverilog-devel mailing list > Ive...@li... > https://lists.sourceforge.net/lists/listinfo/iverilog-devel > _______________________________________________ Iverilog-devel mailing list Ive...@li... https://lists.sourceforge.net/lists/listinfo/iverilog-devel |
|
From: Hagen S. <hs...@no...> - 2019-08-26 07:02:10
|
Hello Martin. Quoting Martin Whitaker <ic...@ma...>: >> What's about the support for SystemVerilog? >> Are there some planes to support SystemVerilog? > > There is already support for some SystemVerilog features. > Unfortunately there's no definitive list of what is or isn't > supported, but you can look in the test suite to get an idea: > > https://github.com/steveicarus/ivtest/blob/master/regress-sv.list > > Cary intends to complete the support for always_comb et al., but I'm > not aware of any plans to add support for more features. Thanks to point me to the test suite.. Indeed it is a good resource for investigation. I like to support the effort to widen the list of supported SystemVerilog features up to IEEE 1800-2017 (which is IMHO a good stable language feature set). Unfortunately I am VLSI chip designer, not a programmer.. Let's see, what I can do so far. Regards, Hagen Sankowski -- "They who can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Benjamin Franklin (1775) |
|
From: Martin W. <ic...@ma...> - 2019-08-24 08:32:17
|
Hagen SANKOWSKI wrote: > Hello. > > I am wondering how far Icarus Verilog is from supporting SystemVerilog.. > > During the last years I worked for different clients and faced the emerging > power of SystemVerilog Designs. > More than one-and-a-half decade Icarus Verilog was great to support me > during all the design tasks in Verilog. Now I like to go one step further > and deliver Open Source SystemVerilog Cores also. > > So: > What's about the support for SystemVerilog? > Are there some planes to support SystemVerilog? There is already support for some SystemVerilog features. Unfortunately there's no definitive list of what is or isn't supported, but you can look in the test suite to get an idea: https://github.com/steveicarus/ivtest/blob/master/regress-sv.list Cary intends to complete the support for always_comb et al., but I'm not aware of any plans to add support for more features. |
|
From: Martin W. <ic...@ma...> - 2019-08-23 23:35:37
|
I've added support for the PATHPULSE, PATHPULSEPERCENT, and PERIOD constructs in the master branch. They are now accepted but silently ignored (like most other SDF timing checks). Stefan Droege via Iverilog-devel wrote: > Hmm you're right that doesn’t meet the spec. I assume line 14 should read > `(PATHPULSEPERCENT (30.0))` > instead. > > I'll try and see whether this is an issue with locale settings, as my locale uses `,` as decimal separator. Interestingly all other values in the sdf file use `.` as decimal separator. In any case I think its worth that I mention this to Xilinx support because if the decimal spearator depends on the locale it should at least be consistent throughout the file. > > Martin, do you think you could add the support for these constructs and test it with the snippet after manually fixing the `30,0` to be a `30.0` until I hear back from Xilinx? > > > -----Original Message----- > From: Martin Whitaker [mailto:ic...@ma...] > Sent: zaterdag 17 augustus 2019 14:26 > To: ive...@li... > Subject: Re: [Iverilog-devel] Make iverilog accept (but ignore) unsupported SDF constructs. > > It shouldn't be hard to add support for those keywords in the SDF parser, but the syntax used for the PATHPULSEPERCENT delay specification in your example doesn't match what I find in the SDF 3.0 spec. The spec. says > > deltype ::= ... > ||= ( PATHPULSEPERCENT input_output_path? value value? ) > ... > > value ::= ( NUMBER? ) > ||= (triple?) > > NUMBER is a single number. triple is three numbers separated by colons. So what does two numbers separated by a comma mean? > > Stefan Droege via Iverilog-devel wrote: >> Hi everyone, >> >> I was trying to run a post-synthesis simulation using iverilog with a netlist generated by Xilinx Vivado. >> >> I ran into a problem that iverilog complains about the SDF file containing invalid syntax, as some of the keywords are not implemented in iverilogs sdf parser. The problematic constructs for my case are `PATHPULSEPERCENT` within the `DELAY` construct and `PERIOD` within the `TIMINGCHECK` construct. See the end of the email for a snippet of the sdf file. >> >> >> >> I checked the IEEE1497-2001 standard and the problematic constructs >> are valid as far as I can see (so no Xilinx specific weirdness here) >> >> >> >> I dont really need the functionality offered by these constructs, but it would be nice if iverilog could still accept the file as valid and simulate only with the supported subset, maybe printing a warning about what was ignored. >> >> >> >> The problematic sdf code: >> >> >> >> (DELAYFILE >> >> (SDFVERSION "3.0" ) >> >> (DESIGN "top") >> >> (DATE "Tue Aug 13 18:03:42 2019") >> >> (VENDOR "XILINX") >> >> (PROGRAM "Vivado") >> >> (VERSION "2019.1") >> >> (DIVIDER /) >> >> (TIMESCALE 1ps) >> >> (CELL >> >> (CELLTYPE "BUFGCE") >> >> (INSTANCE clk_IBUF_BUFG_inst) >> >> (DELAY >> >> (PATHPULSEPERCENT (30,0)) >> >> (ABSOLUTE >> >> (IOPATH I O (40.0:47.0:47.0) (40.0:47.0:47.0)) >> >> ) >> >> ) >> >> (TIMINGCHECK >> >> (SETUPHOLD (posedge CE) (posedge I) (84.0:275.0:275.0) >> (0.0:0.0:0.0)) >> >> (SETUPHOLD (negedge CE) (posedge I) (84.0:275.0:275.0) >> (0.0:0.0:0.0)) >> >> (PERIOD (posedge I) (1499.0:1499.0:1499.0)) >> >> (PERIOD (negedge I) (1499.0:1499.0:1499.0)) >> >> (WIDTH (negedge CE) (550.0:550.0:550.0)) >> >> (WIDTH (posedge CE) (550.0:550.0:550.0)) >> >> ) >> >> ) >> >> ) >> >> >> >> >> >> Kind Regards, Stefan >> >> >> >> >> >> >> _______________________________________________ >> Iverilog-devel mailing list >> Ive...@li... >> https://lists.sourceforge.net/lists/listinfo/iverilog-devel >> > > > > _______________________________________________ > Iverilog-devel mailing list > Ive...@li... > https://lists.sourceforge.net/lists/listinfo/iverilog-devel > > > > > > _______________________________________________ > Iverilog-devel mailing list > Ive...@li... > https://lists.sourceforge.net/lists/listinfo/iverilog-devel > |
|
From: Stefan D. <Dr...@ri...> - 2019-08-19 10:13:47
|
Just for reference: I have posted about the decimal separator issue in the Xilinx forum here: https://forums.xilinx.com/t5/Timing-Analysis/Bug-Invalid-decimal-separator-in-SDF-file-generated-bys-Vivado/m-p/1009354/highlight/true#M17545 -----Original Message----- From: Stefan Droege via Iverilog-devel [mailto:ive...@li...] Sent: maandag 19 augustus 2019 10:48 To: Discussions concerning Icarus Verilog development <ive...@li...> Cc: Stefan Droege <Dr...@ri...> Subject: Re: [Iverilog-devel] Make iverilog accept (but ignore) unsupported SDF constructs. Hmm you're right that doesn’t meet the spec. I assume line 14 should read `(PATHPULSEPERCENT (30.0))` instead. I'll try and see whether this is an issue with locale settings, as my locale uses `,` as decimal separator. Interestingly all other values in the sdf file use `.` as decimal separator. In any case I think its worth that I mention this to Xilinx support because if the decimal spearator depends on the locale it should at least be consistent throughout the file. Martin, do you think you could add the support for these constructs and test it with the snippet after manually fixing the `30,0` to be a `30.0` until I hear back from Xilinx? -----Original Message----- From: Martin Whitaker [mailto:ic...@ma...] Sent: zaterdag 17 augustus 2019 14:26 To: ive...@li... Subject: Re: [Iverilog-devel] Make iverilog accept (but ignore) unsupported SDF constructs. It shouldn't be hard to add support for those keywords in the SDF parser, but the syntax used for the PATHPULSEPERCENT delay specification in your example doesn't match what I find in the SDF 3.0 spec. The spec. says deltype ::= ... ||= ( PATHPULSEPERCENT input_output_path? value value? ) ... value ::= ( NUMBER? ) ||= (triple?) NUMBER is a single number. triple is three numbers separated by colons. So what does two numbers separated by a comma mean? Stefan Droege via Iverilog-devel wrote: > Hi everyone, > > I was trying to run a post-synthesis simulation using iverilog with a netlist generated by Xilinx Vivado. > > I ran into a problem that iverilog complains about the SDF file containing invalid syntax, as some of the keywords are not implemented in iverilogs sdf parser. The problematic constructs for my case are `PATHPULSEPERCENT` within the `DELAY` construct and `PERIOD` within the `TIMINGCHECK` construct. See the end of the email for a snippet of the sdf file. > > > > I checked the IEEE1497-2001 standard and the problematic constructs > are valid as far as I can see (so no Xilinx specific weirdness here) > > > > I dont really need the functionality offered by these constructs, but it would be nice if iverilog could still accept the file as valid and simulate only with the supported subset, maybe printing a warning about what was ignored. > > > > The problematic sdf code: > > > > (DELAYFILE > > (SDFVERSION "3.0" ) > > (DESIGN "top") > > (DATE "Tue Aug 13 18:03:42 2019") > > (VENDOR "XILINX") > > (PROGRAM "Vivado") > > (VERSION "2019.1") > > (DIVIDER /) > > (TIMESCALE 1ps) > > (CELL > > (CELLTYPE "BUFGCE") > > (INSTANCE clk_IBUF_BUFG_inst) > > (DELAY > > (PATHPULSEPERCENT (30,0)) > > (ABSOLUTE > > (IOPATH I O (40.0:47.0:47.0) (40.0:47.0:47.0)) > > ) > > ) > > (TIMINGCHECK > > (SETUPHOLD (posedge CE) (posedge I) (84.0:275.0:275.0) > (0.0:0.0:0.0)) > > (SETUPHOLD (negedge CE) (posedge I) (84.0:275.0:275.0) > (0.0:0.0:0.0)) > > (PERIOD (posedge I) (1499.0:1499.0:1499.0)) > > (PERIOD (negedge I) (1499.0:1499.0:1499.0)) > > (WIDTH (negedge CE) (550.0:550.0:550.0)) > > (WIDTH (posedge CE) (550.0:550.0:550.0)) > > ) > > ) > > ) > > > > > > Kind Regards, Stefan > > > > > > > _______________________________________________ > Iverilog-devel mailing list > Ive...@li... > https://lists.sourceforge.net/lists/listinfo/iverilog-devel > _______________________________________________ Iverilog-devel mailing list Ive...@li... https://lists.sourceforge.net/lists/listinfo/iverilog-devel |
|
From: Stefan D. <Dr...@ri...> - 2019-08-19 09:21:58
|
Hmm you're right that doesn’t meet the spec. I assume line 14 should read
`(PATHPULSEPERCENT (30.0))`
instead.
I'll try and see whether this is an issue with locale settings, as my locale uses `,` as decimal separator. Interestingly all other values in the sdf file use `.` as decimal separator. In any case I think its worth that I mention this to Xilinx support because if the decimal spearator depends on the locale it should at least be consistent throughout the file.
Martin, do you think you could add the support for these constructs and test it with the snippet after manually fixing the `30,0` to be a `30.0` until I hear back from Xilinx?
-----Original Message-----
From: Martin Whitaker [mailto:ic...@ma...]
Sent: zaterdag 17 augustus 2019 14:26
To: ive...@li...
Subject: Re: [Iverilog-devel] Make iverilog accept (but ignore) unsupported SDF constructs.
It shouldn't be hard to add support for those keywords in the SDF parser, but the syntax used for the PATHPULSEPERCENT delay specification in your example doesn't match what I find in the SDF 3.0 spec. The spec. says
deltype ::= ...
||= ( PATHPULSEPERCENT input_output_path? value value? )
...
value ::= ( NUMBER? )
||= (triple?)
NUMBER is a single number. triple is three numbers separated by colons. So what does two numbers separated by a comma mean?
Stefan Droege via Iverilog-devel wrote:
> Hi everyone,
>
> I was trying to run a post-synthesis simulation using iverilog with a netlist generated by Xilinx Vivado.
>
> I ran into a problem that iverilog complains about the SDF file containing invalid syntax, as some of the keywords are not implemented in iverilogs sdf parser. The problematic constructs for my case are `PATHPULSEPERCENT` within the `DELAY` construct and `PERIOD` within the `TIMINGCHECK` construct. See the end of the email for a snippet of the sdf file.
>
>
>
> I checked the IEEE1497-2001 standard and the problematic constructs
> are valid as far as I can see (so no Xilinx specific weirdness here)
>
>
>
> I dont really need the functionality offered by these constructs, but it would be nice if iverilog could still accept the file as valid and simulate only with the supported subset, maybe printing a warning about what was ignored.
>
>
>
> The problematic sdf code:
>
>
>
> (DELAYFILE
>
> (SDFVERSION "3.0" )
>
> (DESIGN "top")
>
> (DATE "Tue Aug 13 18:03:42 2019")
>
> (VENDOR "XILINX")
>
> (PROGRAM "Vivado")
>
> (VERSION "2019.1")
>
> (DIVIDER /)
>
> (TIMESCALE 1ps)
>
> (CELL
>
> (CELLTYPE "BUFGCE")
>
> (INSTANCE clk_IBUF_BUFG_inst)
>
> (DELAY
>
> (PATHPULSEPERCENT (30,0))
>
> (ABSOLUTE
>
> (IOPATH I O (40.0:47.0:47.0) (40.0:47.0:47.0))
>
> )
>
> )
>
> (TIMINGCHECK
>
> (SETUPHOLD (posedge CE) (posedge I) (84.0:275.0:275.0)
> (0.0:0.0:0.0))
>
> (SETUPHOLD (negedge CE) (posedge I) (84.0:275.0:275.0)
> (0.0:0.0:0.0))
>
> (PERIOD (posedge I) (1499.0:1499.0:1499.0))
>
> (PERIOD (negedge I) (1499.0:1499.0:1499.0))
>
> (WIDTH (negedge CE) (550.0:550.0:550.0))
>
> (WIDTH (posedge CE) (550.0:550.0:550.0))
>
> )
>
> )
>
> )
>
>
>
>
>
> Kind Regards, Stefan
>
>
>
>
>
>
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>
_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel
|
|
From: Hagen S. <hs...@no...> - 2019-08-19 07:50:42
|
Hello. I am wondering how far Icarus Verilog is from supporting SystemVerilog.. During the last years I worked for different clients and faced the emerging power of SystemVerilog Designs. More than one-and-a-half decade Icarus Verilog was great to support me during all the design tasks in Verilog. Now I like to go one step further and deliver Open Source SystemVerilog Cores also. So: What's about the support for SystemVerilog? Are there some planes to support SystemVerilog? Best Regards, Hagen. -- "They who can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Benjamin Franklin (1775) |
|
From: Cary R. <cy...@ya...> - 2019-08-17 22:38:36
|
The download links on SourceForge should now point to the 10.3 tar file. I found the place where I needed to set that.
Cary
On Saturday, August 17, 2019, 10:28:16 AM PDT, Cary R. via Iverilog-devel <ive...@li...> wrote:
I thought that this automatically updated, but it has been a while and I may be remembering wrong or things could have changed. I will look around and see if I can find a way to manually update this.
Is someone going to write release notes on the wiki? I looked around and it looks like 0.9.7 was the last one we announced fully and had release notes so we are a bit delinquent in the 10 series :).
Cary
On Saturday, August 17, 2019, 3:57:38 AM PDT, Martin Whitaker <ic...@ma...> wrote:
The SourceForge "Download latest version" button still serves up 10.0.
Cary R. via Iverilog-devel wrote:
>
> No problems compiling/testing on Centos 7, and the last two most recent Ubuntu LTS releases. I tagged the test suite with a v10_3 tag and put the tar file on SourceForge.
> Cary
> On Thursday, August 15, 2019, 9:15:58 AM PDT, Stephen Williams <st...@ic...> wrote:
>
> As promised, I have made up a 10.3 release of the stable branch of
> Icarus Verilog. Specifically, I've made up the main source tarball
> which can be downloaded from here:
>
> ftp://ftp.icarus.com/pub/eda/verilog/v10/verilog-10.3.tar.gz
>
> There is also a SRPM file in the same directory, and a binary rpm for
> openSUSE 15.1 that I built as a test of the packaging.
>
> From here, there are lots of places that the release needs to
> propagate, many of which I am not even aware of, so go ahead and test
> it out and pass it around.
>
>
>
>
>
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>
_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel
_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel
|
|
From: Cary R. <cy...@ya...> - 2019-08-17 17:27:53
|
I thought that this automatically updated, but it has been a while and I may be remembering wrong or things could have changed. I will look around and see if I can find a way to manually update this.
Is someone going to write release notes on the wiki? I looked around and it looks like 0.9.7 was the last one we announced fully and had release notes so we are a bit delinquent in the 10 series :).
Cary
On Saturday, August 17, 2019, 3:57:38 AM PDT, Martin Whitaker <ic...@ma...> wrote:
The SourceForge "Download latest version" button still serves up 10.0.
Cary R. via Iverilog-devel wrote:
>
> No problems compiling/testing on Centos 7, and the last two most recent Ubuntu LTS releases. I tagged the test suite with a v10_3 tag and put the tar file on SourceForge.
> Cary
> On Thursday, August 15, 2019, 9:15:58 AM PDT, Stephen Williams <st...@ic...> wrote:
>
> As promised, I have made up a 10.3 release of the stable branch of
> Icarus Verilog. Specifically, I've made up the main source tarball
> which can be downloaded from here:
>
> ftp://ftp.icarus.com/pub/eda/verilog/v10/verilog-10.3.tar.gz
>
> There is also a SRPM file in the same directory, and a binary rpm for
> openSUSE 15.1 that I built as a test of the packaging.
>
> From here, there are lots of places that the release needs to
> propagate, many of which I am not even aware of, so go ahead and test
> it out and pass it around.
>
>
>
>
>
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>
_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel
|
|
From: Martin W. <ic...@ma...> - 2019-08-17 12:26:05
|
It shouldn't be hard to add support for those keywords in the SDF parser,
but the syntax used for the PATHPULSEPERCENT delay specification in your
example doesn't match what I find in the SDF 3.0 spec. The spec. says
deltype ::= ...
||= ( PATHPULSEPERCENT input_output_path? value value? )
...
value ::= ( NUMBER? )
||= (triple?)
NUMBER is a single number. triple is three numbers separated by colons. So
what does two numbers separated by a comma mean?
Stefan Droege via Iverilog-devel wrote:
> Hi everyone,
>
> I was trying to run a post-synthesis simulation using iverilog with a netlist generated by Xilinx Vivado.
>
> I ran into a problem that iverilog complains about the SDF file containing invalid syntax, as some of the keywords are not implemented in iverilogs sdf parser. The problematic constructs for my case are `PATHPULSEPERCENT` within the `DELAY` construct and `PERIOD` within the `TIMINGCHECK` construct. See the end of the email for a snippet of the sdf file.
>
>
>
> I checked the IEEE1497-2001 standard and the problematic constructs are valid as far as I can see (so no Xilinx specific weirdness here)
>
>
>
> I dont really need the functionality offered by these constructs, but it would be nice if iverilog could still accept the file as valid and simulate only with the supported subset, maybe printing a warning about what was ignored.
>
>
>
> The problematic sdf code:
>
>
>
> (DELAYFILE
>
> (SDFVERSION "3.0" )
>
> (DESIGN "top")
>
> (DATE "Tue Aug 13 18:03:42 2019")
>
> (VENDOR "XILINX")
>
> (PROGRAM "Vivado")
>
> (VERSION "2019.1")
>
> (DIVIDER /)
>
> (TIMESCALE 1ps)
>
> (CELL
>
> (CELLTYPE "BUFGCE")
>
> (INSTANCE clk_IBUF_BUFG_inst)
>
> (DELAY
>
> (PATHPULSEPERCENT (30,0))
>
> (ABSOLUTE
>
> (IOPATH I O (40.0:47.0:47.0) (40.0:47.0:47.0))
>
> )
>
> )
>
> (TIMINGCHECK
>
> (SETUPHOLD (posedge CE) (posedge I) (84.0:275.0:275.0) (0.0:0.0:0.0))
>
> (SETUPHOLD (negedge CE) (posedge I) (84.0:275.0:275.0) (0.0:0.0:0.0))
>
> (PERIOD (posedge I) (1499.0:1499.0:1499.0))
>
> (PERIOD (negedge I) (1499.0:1499.0:1499.0))
>
> (WIDTH (negedge CE) (550.0:550.0:550.0))
>
> (WIDTH (posedge CE) (550.0:550.0:550.0))
>
> )
>
> )
>
> )
>
>
>
>
>
> Kind Regards, Stefan
>
>
>
>
>
>
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>
|
|
From: Hagen S. <hs...@no...> - 2019-08-17 11:01:54
|
Hello. I am wondering how far Icarus Verilog is from supporting SystemVerilog.. During the last years I worked for different clients and saw the emerging power of SystemVerilog Designs. More than one-and-a-half decade Icarus Verilog was great to support me during all the design tasks in Verilog. Now I like to go one step further and deliver Open Source SystemVerilog Cores also. So: What's about the support for SystemVerilog? Are there some planes to support SystemVerilog? Best Regards, Hagen. -- "They who can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Benjamin Franklin (1775) |
|
From: Hagen S. <hs...@no...> - 2019-08-17 11:01:46
|
Hello. I am wondering how far Icarus Verilog is from supporting SystemVerilog.. During the last years I worked for different clients and faced the emerging power of SystemVerilog Designs. More than one-and-a-half decade Icarus Verilog was great to support me during all the design tasks in Verilog. Now I like to go one step further and deliver Open Source SystemVerilog Cores also. So: What's about the support for SystemVerilog? Are there some planes to support SystemVerilog? Best Regards, Hagen. -- "They who can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Benjamin Franklin (1775) |
|
From: Martin W. <ic...@ma...> - 2019-08-17 10:57:08
|
The SourceForge "Download latest version" button still serves up 10.0. Cary R. via Iverilog-devel wrote: > > No problems compiling/testing on Centos 7, and the last two most recent Ubuntu LTS releases. I tagged the test suite with a v10_3 tag and put the tar file on SourceForge. > Cary > On Thursday, August 15, 2019, 9:15:58 AM PDT, Stephen Williams <st...@ic...> wrote: > > As promised, I have made up a 10.3 release of the stable branch of > Icarus Verilog. Specifically, I've made up the main source tarball > which can be downloaded from here: > > ftp://ftp.icarus.com/pub/eda/verilog/v10/verilog-10.3.tar.gz > > There is also a SRPM file in the same directory, and a binary rpm for > openSUSE 15.1 that I built as a test of the packaging. > > From here, there are lots of places that the release needs to > propagate, many of which I am not even aware of, so go ahead and test > it out and pass it around. > > > > > > _______________________________________________ > Iverilog-devel mailing list > Ive...@li... > https://lists.sourceforge.net/lists/listinfo/iverilog-devel > |
|
From: Cary R. <cy...@ya...> - 2019-08-17 06:15:52
|
No problems compiling/testing on Centos 7, and the last two most recent Ubuntu LTS releases. I tagged the test suite with a v10_3 tag and put the tar file on SourceForge.
Cary
On Thursday, August 15, 2019, 9:15:58 AM PDT, Stephen Williams <st...@ic...> wrote:
As promised, I have made up a 10.3 release of the stable branch of
Icarus Verilog. Specifically, I've made up the main source tarball
which can be downloaded from here:
ftp://ftp.icarus.com/pub/eda/verilog/v10/verilog-10.3.tar.gz
There is also a SRPM file in the same directory, and a binary rpm for
openSUSE 15.1 that I built as a test of the packaging.
>From here, there are lots of places that the release needs to
propagate, many of which I am not even aware of, so go ahead and test
it out and pass it around.
--
Steve Williams "The woods are lovely, dark and deep.
st...@ic... 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."
_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel
|
|
From: Martin W. <ic...@ma...> - 2019-08-16 08:03:52
|
Galen Seitz wrote: > Hi, > > Is there an interest in segfaults due to bad code? Yes, we always try to fix faults like that. Best to report them in the bug tracker on SourceForge or on GitHub, to avoid your report being overlooked or forgotten. |
|
From: Galen S. <ga...@se...> - 2019-08-15 20:17:56
|
Hi,
Is there an interest in segfaults due to bad code?
[galens@toto lm8]$ iverilog -Wall '-g2012' foo.sv
foo.sv:7: warning: @* found no sensitivities so it will never trigger.
sh: line 1: 12448 Done /usr/local/lib/ivl/ivlpp -L -Wredef-chg -F"/tmp/ivrlg23071f291" -f"/tmp/ivrlg3071f291" -p"/tmp/ivrli3071f291"
12449 Segmentation fault (core dumped) | /usr/local/lib/ivl/ivl -C"/tmp/ivrlh3071f291" -C"/usr/local/lib/ivl/vvp.conf" -- -
[galens@toto lm8]$ iverilog -V
Icarus Verilog version 11.0 (devel) (v10_2-78-gb7b22660)
[galens@toto lm8]$ cat foo.sv
module foo
(
input a,
output logic y
);
always_comb begin
`ifdef NO_SEGFAULT
y = a;
`else
y = 1'b0;
`endif
end
endmodule
thanks,
galen
--
Galen Seitz
ga...@se...
|
31 messages has been excluded from this view by a project administrator.
