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...> - 2020-09-22 21:10:59
|
Found it. Never mind. On Tue, Sep 22, 2020 at 2:07 PM Stephen Williams <st...@ic...> wrote: > > Do you remember where it is? > > On Sat, Sep 19, 2020 at 11:05 PM Cary R. via Iverilog-devel > <ive...@li...> wrote: > > > > Sounds good. Make sure you fix the shift-reduce issue in vvp/parse.y. We probably should have done it some time ago, but it certainly should be done for the actual release. I think it should be fixed before you branch because we don't need this in the new devel or release branch. > > > > Cary > > > > On Saturday, September 19, 2020, 9:55:03 AM PDT, Stephen Williams <st...@ic...> wrote: > > > > > > OK, I'm going to start working on a version 11 release. I'm going to > > review the current state and collect any other opinions, then the plan > > wil be to make a branch and shortly after, a release candidate. > > > > On Mon, Aug 24, 2020 at 7:17 PM Cary R. via Iverilog-devel > > <ive...@li...> wrote: > > > > > > Hi Steve, > > > > > > My development machine is in a wonky state so I have not been able to work on Icarus for a week or so. I'm also busy at work for the next few weeks so it could be a while before I can do much more. Given that and I have much of the queue and darray functionality working better I would say lets go for it. > > > > > > There is one thing that needs to be fixed before we release. Some time ago a contributor made a change to the VVP file format and left in backwards compatibility. This resulted in a shift-reduce warning in VVP. We should update this to only support the new format and remove the shift-reduce issue. I think everything else should be good to go. > > > > > > Cary > > > > > > On Monday, August 24, 2020, 8:55:26 AM PDT, Stephen Williams <st...@ic...> wrote: > > > > > > > > > Cary, > > > > > > How are we doing on this? Still on track for a v11 release in the near future? > > > > > > On Tue, Aug 4, 2020 at 2:01 PM Cary R. via Iverilog-devel > > > <ive...@li...> wrote: > > > > > > > > I'm making good progress on my queue work. I'm taking some time to refactor what I have done so far and then will finish up. See what I committed last night for an example of the refactoring. Hopefully in the next week or so. > > > > > > > > The other thing that I would like to have dealt with before we release V11 is addressing the longest static prefix issue in the always_* sensitivity calculation. If one of you could look at this we could get V11 out sooner. I have a failing test and I think there is a github report as well. I can provide help as needed. > > > > > > > > We should also review all tickets regarding bugs to make sure we have things as clean as possible for V11. > > > > > > > > Cary > > > > On Tuesday, August 4, 2020, 12:57:13 AM PDT, Martin Whitaker <ic...@ma...> wrote: > > > > > > > > > > > > I say go for it as soon as Cary finishes tidying up his work on queues. > > > > As 10.3 doesn't build with GCC 10 or bison 3.7, we really need to get a > > > > release out. > > > > > > > > On 04/08/2020 01:54, Stephen Williams wrote: > > > > > So, Cary, Martin? Thoughts on a release 11? I believe Cary has > > > > > something he wants to sneak into a release. What's the schule for > > > > > that? > > > > > > > > > > On Thu, Jul 30, 2020 at 11:05 AM Stephen Williams <st...@ic...> wrote: > > > > >> > > > > >> You make a very good point. This is being discussed, and we're > > > > >> thinking sooner rather than later. > > > > >> > > > > >> On Thu, Jul 30, 2020 at 11:03 AM Jean THOMAS <pu...@gi...> wrote: > > > > >>> > > > > >>> Hi everyone, > > > > >>> > > > > >>> Lots of changes have happened in iverilog since its last release. In > > > > >>> most Linux distros only the latest release is available, which is a year > > > > >>> old now. When can we expect a new release for iverilog? > > > > >>> > > > > >>> Cheers, > > > > >>> Jean > > > > >>> > > > > >>> > > > > >>> _______________________________________________ > > > > >>> Iverilog-devel mailing list > > > > >>> Ive...@li... > > > > >>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel > > > > >> > > > > >> > > > > >> > > > > >> -- > > > > >> 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 > > > > > > > > > _______________________________________________ > > > > Iverilog-devel mailing list > > > > Ive...@li... > > > > https://lists.sourceforge.net/lists/listinfo/iverilog-devel > > > > > > > > > > > > -- > > > 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 > > > _______________________________________________ > > > Iverilog-devel mailing list > > > Ive...@li... > > > https://lists.sourceforge.net/lists/listinfo/iverilog-devel > > > > > > > > -- > > 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 > > _______________________________________________ > > Iverilog-devel mailing list > > Ive...@li... > > https://lists.sourceforge.net/lists/listinfo/iverilog-devel > > > > -- > 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." -- 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: Stephen W. <st...@ic...> - 2020-09-22 21:08:06
|
Do you remember where it is? On Sat, Sep 19, 2020 at 11:05 PM Cary R. via Iverilog-devel <ive...@li...> wrote: > > Sounds good. Make sure you fix the shift-reduce issue in vvp/parse.y. We probably should have done it some time ago, but it certainly should be done for the actual release. I think it should be fixed before you branch because we don't need this in the new devel or release branch. > > Cary > > On Saturday, September 19, 2020, 9:55:03 AM PDT, Stephen Williams <st...@ic...> wrote: > > > OK, I'm going to start working on a version 11 release. I'm going to > review the current state and collect any other opinions, then the plan > wil be to make a branch and shortly after, a release candidate. > > On Mon, Aug 24, 2020 at 7:17 PM Cary R. via Iverilog-devel > <ive...@li...> wrote: > > > > Hi Steve, > > > > My development machine is in a wonky state so I have not been able to work on Icarus for a week or so. I'm also busy at work for the next few weeks so it could be a while before I can do much more. Given that and I have much of the queue and darray functionality working better I would say lets go for it. > > > > There is one thing that needs to be fixed before we release. Some time ago a contributor made a change to the VVP file format and left in backwards compatibility. This resulted in a shift-reduce warning in VVP. We should update this to only support the new format and remove the shift-reduce issue. I think everything else should be good to go. > > > > Cary > > > > On Monday, August 24, 2020, 8:55:26 AM PDT, Stephen Williams <st...@ic...> wrote: > > > > > > Cary, > > > > How are we doing on this? Still on track for a v11 release in the near future? > > > > On Tue, Aug 4, 2020 at 2:01 PM Cary R. via Iverilog-devel > > <ive...@li...> wrote: > > > > > > I'm making good progress on my queue work. I'm taking some time to refactor what I have done so far and then will finish up. See what I committed last night for an example of the refactoring. Hopefully in the next week or so. > > > > > > The other thing that I would like to have dealt with before we release V11 is addressing the longest static prefix issue in the always_* sensitivity calculation. If one of you could look at this we could get V11 out sooner. I have a failing test and I think there is a github report as well. I can provide help as needed. > > > > > > We should also review all tickets regarding bugs to make sure we have things as clean as possible for V11. > > > > > > Cary > > > On Tuesday, August 4, 2020, 12:57:13 AM PDT, Martin Whitaker <ic...@ma...> wrote: > > > > > > > > > I say go for it as soon as Cary finishes tidying up his work on queues. > > > As 10.3 doesn't build with GCC 10 or bison 3.7, we really need to get a > > > release out. > > > > > > On 04/08/2020 01:54, Stephen Williams wrote: > > > > So, Cary, Martin? Thoughts on a release 11? I believe Cary has > > > > something he wants to sneak into a release. What's the schule for > > > > that? > > > > > > > > On Thu, Jul 30, 2020 at 11:05 AM Stephen Williams <st...@ic...> wrote: > > > >> > > > >> You make a very good point. This is being discussed, and we're > > > >> thinking sooner rather than later. > > > >> > > > >> On Thu, Jul 30, 2020 at 11:03 AM Jean THOMAS <pu...@gi...> wrote: > > > >>> > > > >>> Hi everyone, > > > >>> > > > >>> Lots of changes have happened in iverilog since its last release. In > > > >>> most Linux distros only the latest release is available, which is a year > > > >>> old now. When can we expect a new release for iverilog? > > > >>> > > > >>> Cheers, > > > >>> Jean > > > >>> > > > >>> > > > >>> _______________________________________________ > > > >>> Iverilog-devel mailing list > > > >>> Ive...@li... > > > >>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel > > > >> > > > >> > > > >> > > > >> -- > > > >> 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 > > > > > > _______________________________________________ > > > Iverilog-devel mailing list > > > Ive...@li... > > > https://lists.sourceforge.net/lists/listinfo/iverilog-devel > > > > > > > > -- > > 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 > > _______________________________________________ > > Iverilog-devel mailing list > > Ive...@li... > > https://lists.sourceforge.net/lists/listinfo/iverilog-devel > > > > -- > 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 > _______________________________________________ > Iverilog-devel mailing list > Ive...@li... > https://lists.sourceforge.net/lists/listinfo/iverilog-devel -- 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: Martin W. <ic...@ma...> - 2020-09-21 16:49:13
|
It does if you use ANSI C style formal argument lists, but not if you
use traditional Verilog style. So rewriting Kevin's code as
function integer execOp(
input integer left,
input integer right,
input binOp op);
begin
execOp = op == ADD ? left + right : left * right;
end
endfunction
allows it to compile.
On 21/09/2020 16:26, Stephen Williams wrote:
> Icarus Verilog does support enum arguments to functions.
> See pull371b.v in the ivtest test suite.
>
> On Sat, Sep 19, 2020 at 11:18 PM Cary R. via Iverilog-devel
> <ive...@li...> wrote:
>>
>> I believe Icarus does not currently support using enums as function arguments.
>>
>> Cary
>> On Saturday, September 19, 2020, 8:55:30 AM PDT, Kevin Simonson <kvn...@ho...> wrote:
>>
>>
>> I'm still very much interested in finding out whether or not it's possible for a Verilog function to have a boolean value as input, but while I was waiting for input on that I decided to rewrite a version of my Verilog code to use an (enum) instead of a (boolean). Much to my amazement, it appears that I can't use an (enum) as an input to a function either! I wrote the following code:
>>
>> module useBin ();
>>
>> typedef enum { ADD, MULTIPLY } binOp;
>>
>> function integer execOp;
>> input integer left;
>> input integer right;
>> input binOp op;
>> begin
>> execOp = op == ADD ? left + right : left * right;
>> end
>> endfunction
>>
>> endmodule
>>
>> When I ran Icarus to simulate it I got:
>>
>> D:\Hf\Verilog\Unpacked\Common>ive useBin
>> \Icarus\bin\iverilog -g2009 -o useBin.out useBin.sv
>> useBin.sv:8: syntax error
>> useBin.sv:5: error: Syntax error defining function.
>>
>> D:\Hf\Verilog\Unpacked\Common>
>>
>> I can kind of understand why a (boolean) might cause a problem when used as a function input, but why in the world would it be illegal to use an (enum) like my (binOp) as a function input?
>> _______________________________________________
>> 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: Stephen W. <st...@ic...> - 2020-09-21 15:27:08
|
Icarus Verilog does support enum arguments to functions.
See pull371b.v in the ivtest test suite.
On Sat, Sep 19, 2020 at 11:18 PM Cary R. via Iverilog-devel
<ive...@li...> wrote:
>
> I believe Icarus does not currently support using enums as function arguments.
>
> Cary
> On Saturday, September 19, 2020, 8:55:30 AM PDT, Kevin Simonson <kvn...@ho...> wrote:
>
>
> I'm still very much interested in finding out whether or not it's possible for a Verilog function to have a boolean value as input, but while I was waiting for input on that I decided to rewrite a version of my Verilog code to use an (enum) instead of a (boolean). Much to my amazement, it appears that I can't use an (enum) as an input to a function either! I wrote the following code:
>
> module useBin ();
>
> typedef enum { ADD, MULTIPLY } binOp;
>
> function integer execOp;
> input integer left;
> input integer right;
> input binOp op;
> begin
> execOp = op == ADD ? left + right : left * right;
> end
> endfunction
>
> endmodule
>
> When I ran Icarus to simulate it I got:
>
> D:\Hf\Verilog\Unpacked\Common>ive useBin
> \Icarus\bin\iverilog -g2009 -o useBin.out useBin.sv
> useBin.sv:8: syntax error
> useBin.sv:5: error: Syntax error defining function.
>
> D:\Hf\Verilog\Unpacked\Common>
>
> I can kind of understand why a (boolean) might cause a problem when used as a function input, but why in the world would it be illegal to use an (enum) like my (binOp) as a function input?
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
--
Steve Williams "The woods are lovely, dark and deep.
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...> - 2020-09-20 06:18:09
|
I believe Icarus does not currently support using enums as function arguments.
Cary
On Saturday, September 19, 2020, 8:55:30 AM PDT, Kevin Simonson <kvn...@ho...> wrote:
#yiv8414253916 P {margin-top:0;margin-bottom:0;}I'm still very much interested in finding out whether or not it's possible for a Verilog function to have a boolean value as input, but while I was waiting for input on that I decided to rewrite a version of my Verilog code to use an (enum) instead of a (boolean). Much to my amazement, it appears that I can't use an (enum) as an input to a function either! I wrote the following code:
module useBin ();
typedef enum { ADD, MULTIPLY } binOp;
function integer execOp; input integer left; input integer right; input binOp op; begin execOp = op == ADD ? left + right : left * right; endendfunction
endmodule
When I ran Icarus to simulate it I got:
D:\Hf\Verilog\Unpacked\Common>ive useBin\Icarus\bin\iverilog -g2009 -o useBin.out useBin.svuseBin.sv:8: syntax erroruseBin.sv:5: error: Syntax error defining function.
D:\Hf\Verilog\Unpacked\Common>
I can kind of understand why a (boolean) might cause a problem when used as a function input, but why in the world would it be illegal to use an (enum) like my (binOp) as a function input?_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel
|
|
From: Cary R. <cy...@ya...> - 2020-09-20 06:14:33
|
Parameters may not have been updated to support structures and you are also missing the parameter assignment. I'm fairly certain we do not currently support parameter arrays.
Cary
On Saturday, September 19, 2020, 8:55:38 AM PDT, Kevin Simonson <kvn...@ho...> wrote:
#yiv5304625299 P {margin-top:0;margin-bottom:0;}I've written a piece of code with inputs (left) and (right) and output (result), each of which operand is a single bit, which returns a logical one in (result) if (left) has the same value as (right), and returns a logical zero otherwise. My code is:
module ModGc ( result, left, right);output result;input left, right;
typedef enum { L_NOT, L_NAND, L_NOR } GateType;
typedef struct packed{ GateType gateTp; integer out; integer inLow; integer inHigh;} LogGate;
localparam integer nmGates = 4;localparam integer poolSize = 6;localparam LogGate specs [ nmGates:1]wire pool [ poolSize:1];genvar ix;
initialbegin specs[ 1].gateTp = L_NOR ; specs[ 1].out = 4; specs[ 1].inLow = 2; specs[ 1].inHigh = 3; specs[ 2].gateTp = L_NOT ; specs[ 2].out = 5; specs[ 2].inLow = 4; specs[ 2].inHigh = 0; specs[ 3].gateTp = L_NAND; specs[ 3].out = 6; specs[ 3].inLow = 2; specs[ 3].inHigh = 3; specs[ 4].gateTp = L_NOR ; specs[ 4].out = 1; specs[ 4].inLow = 5; specs[ 4].inHigh = 6;end assign pool[ 2] = left;assign pool[ 3] = right;for (ix = 1; ix <= nmGates; ix = ix + 1) case (specs[ ix].gateTp) L_NOT : not ntx( pool[ specs[ ix].out], pool[ specs[ ix].inLow]); L_NAND : nand nax( pool[ specs[ ix].out], pool[ specs[ ix].inLow], pool[ specs[ ix].inHigh]); L_NOR : nor nox( pool[ specs[ ix].out], pool[ specs[ ix].inLow], pool[ specs[ ix].inHigh]); endcaseassign result = pool[ 1];
endmodule
I'm fully aware that there's a much simpler way to design an Equals circuit than this; again this is a simplification of a problem I'm having in more complex code. Anyhow, I run the Icarus simulator on this and get:
D:\Hf\Verilog\Unpacked\Common>\Icarus\bin\iverilog -g2009 -o ModGc.out ModGc.svModGc.sv:16: sorry: cannot currently create a parameter of type 'LogGate' which was defined at: ModGc.sv:7.ModGc.sv:16: syntax errorModGc.sv:16: error: syntax error localparam list.
D:\Hf\Verilog\Unpacked\Common>
Can anyone tell me why the simulator is balking at line 16, where local parameter (specs) is declared? Any information anyone can give me on these compilation errors would be greatly appreciated._______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel
|
|
From: Cary R. <cy...@ya...> - 2020-09-20 06:05:44
|
Sounds good. Make sure you fix the shift-reduce issue in vvp/parse.y. We probably should have done it some time ago, but it certainly should be done for the actual release. I think it should be fixed before you branch because we don't need this in the new devel or release branch.
Cary
On Saturday, September 19, 2020, 9:55:03 AM PDT, Stephen Williams <st...@ic...> wrote:
OK, I'm going to start working on a version 11 release. I'm going to
review the current state and collect any other opinions, then the plan
wil be to make a branch and shortly after, a release candidate.
On Mon, Aug 24, 2020 at 7:17 PM Cary R. via Iverilog-devel
<ive...@li...> wrote:
>
> Hi Steve,
>
> My development machine is in a wonky state so I have not been able to work on Icarus for a week or so. I'm also busy at work for the next few weeks so it could be a while before I can do much more. Given that and I have much of the queue and darray functionality working better I would say lets go for it.
>
> There is one thing that needs to be fixed before we release. Some time ago a contributor made a change to the VVP file format and left in backwards compatibility. This resulted in a shift-reduce warning in VVP. We should update this to only support the new format and remove the shift-reduce issue. I think everything else should be good to go.
>
> Cary
>
> On Monday, August 24, 2020, 8:55:26 AM PDT, Stephen Williams <st...@ic...> wrote:
>
>
> Cary,
>
> How are we doing on this? Still on track for a v11 release in the near future?
>
> On Tue, Aug 4, 2020 at 2:01 PM Cary R. via Iverilog-devel
> <ive...@li...> wrote:
> >
> > I'm making good progress on my queue work. I'm taking some time to refactor what I have done so far and then will finish up. See what I committed last night for an example of the refactoring. Hopefully in the next week or so.
> >
> > The other thing that I would like to have dealt with before we release V11 is addressing the longest static prefix issue in the always_* sensitivity calculation. If one of you could look at this we could get V11 out sooner. I have a failing test and I think there is a github report as well. I can provide help as needed.
> >
> > We should also review all tickets regarding bugs to make sure we have things as clean as possible for V11.
> >
> > Cary
> > On Tuesday, August 4, 2020, 12:57:13 AM PDT, Martin Whitaker <ic...@ma...> wrote:
> >
> >
> > I say go for it as soon as Cary finishes tidying up his work on queues.
> > As 10.3 doesn't build with GCC 10 or bison 3.7, we really need to get a
> > release out.
> >
> > On 04/08/2020 01:54, Stephen Williams wrote:
> > > So, Cary, Martin? Thoughts on a release 11? I believe Cary has
> > > something he wants to sneak into a release. What's the schule for
> > > that?
> > >
> > > On Thu, Jul 30, 2020 at 11:05 AM Stephen Williams <st...@ic...> wrote:
> > >>
> > >> You make a very good point. This is being discussed, and we're
> > >> thinking sooner rather than later.
> > >>
> > >> On Thu, Jul 30, 2020 at 11:03 AM Jean THOMAS <pu...@gi...> wrote:
> > >>>
> > >>> Hi everyone,
> > >>>
> > >>> Lots of changes have happened in iverilog since its last release. In
> > >>> most Linux distros only the latest release is available, which is a year
> > >>> old now. When can we expect a new release for iverilog?
> > >>>
> > >>> Cheers,
> > >>> Jean
> > >>>
> > >>>
> > >>> _______________________________________________
> > >>> Iverilog-devel mailing list
> > >>> Ive...@li...
> > >>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
> > >>
> > >>
> > >>
> > >> --
> > >> 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
>
> > _______________________________________________
> > Iverilog-devel mailing list
> > Ive...@li...
> > https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>
>
>
> --
> 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
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
--
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: Cary R. <cy...@ya...> - 2020-09-20 06:00:07
|
I would suggest using the SystemVerilog bit type since it is two state. I will also suggest you look at some of the online training. This is a fundamental language question and not something specific to Icarus development. You can also download the standard to know what is and is not supported in SystemVerilog.
Also keep in mind that Icarus still has significant limitations and sometimes just reports missing functionality as a syntax error. That's what happens when it has not been added to the parser.
Cary
On Saturday, September 19, 2020, 1:37:50 PM PDT, Stephen Williams <st...@ic...> wrote:
There are so many ways to do this. If you literally want to pass in
the enumeration value "true" and "false", then yeah, create an
enumeration. But you can also use a basic single-bit value.
On Sat, Sep 19, 2020 at 9:25 AM Evan Lavelle <sa2...@cy...> wrote:
>
> Verilog has no boolean type, so out of luck...
>
>
>
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
--
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: Cary R. <cy...@ya...> - 2020-09-20 05:48:00
|
There is no convention for the compiler output file suffix. We often use no suffix. If you really want a suffix to indicate the file type .vvp should work.
Cary
On Saturday, September 19, 2020, 2:03:48 PM PDT, Stephen Williams <st...@ic...> wrote:
The most common suffixes are .sv, or plain .v.
On Sat, Sep 19, 2020 at 8:55 AM Kevin Simonson <kvn...@ho...> wrote:
>
> When I try to execute the Icarus tool on a System Verilog file I execute something like this:
>
> \Icarus\bin\iverilog -g2009 -o example.(file-suffix) example.sv
>
> What do people typically use for (file-suffix)?
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
--
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: Stephen W. <st...@ic...> - 2020-09-19 21:03:12
|
The most common suffixes are .sv, or plain .v. On Sat, Sep 19, 2020 at 8:55 AM Kevin Simonson <kvn...@ho...> wrote: > > When I try to execute the Icarus tool on a System Verilog file I execute something like this: > > \Icarus\bin\iverilog -g2009 -o example.(file-suffix) example.sv > > What do people typically use for (file-suffix)? > _______________________________________________ > Iverilog-devel mailing list > Ive...@li... > https://lists.sourceforge.net/lists/listinfo/iverilog-devel -- 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: Stephen W. <st...@ic...> - 2020-09-19 20:37:14
|
There are so many ways to do this. If you literally want to pass in the enumeration value "true" and "false", then yeah, create an enumeration. But you can also use a basic single-bit value. On Sat, Sep 19, 2020 at 9:25 AM Evan Lavelle <sa2...@cy...> wrote: > > Verilog has no boolean type, so out of luck... > > > > _______________________________________________ > Iverilog-devel mailing list > Ive...@li... > https://lists.sourceforge.net/lists/listinfo/iverilog-devel -- 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: Stephen W. <st...@ic...> - 2020-09-19 16:54:31
|
OK, I'm going to start working on a version 11 release. I'm going to review the current state and collect any other opinions, then the plan wil be to make a branch and shortly after, a release candidate. On Mon, Aug 24, 2020 at 7:17 PM Cary R. via Iverilog-devel <ive...@li...> wrote: > > Hi Steve, > > My development machine is in a wonky state so I have not been able to work on Icarus for a week or so. I'm also busy at work for the next few weeks so it could be a while before I can do much more. Given that and I have much of the queue and darray functionality working better I would say lets go for it. > > There is one thing that needs to be fixed before we release. Some time ago a contributor made a change to the VVP file format and left in backwards compatibility. This resulted in a shift-reduce warning in VVP. We should update this to only support the new format and remove the shift-reduce issue. I think everything else should be good to go. > > Cary > > On Monday, August 24, 2020, 8:55:26 AM PDT, Stephen Williams <st...@ic...> wrote: > > > Cary, > > How are we doing on this? Still on track for a v11 release in the near future? > > On Tue, Aug 4, 2020 at 2:01 PM Cary R. via Iverilog-devel > <ive...@li...> wrote: > > > > I'm making good progress on my queue work. I'm taking some time to refactor what I have done so far and then will finish up. See what I committed last night for an example of the refactoring. Hopefully in the next week or so. > > > > The other thing that I would like to have dealt with before we release V11 is addressing the longest static prefix issue in the always_* sensitivity calculation. If one of you could look at this we could get V11 out sooner. I have a failing test and I think there is a github report as well. I can provide help as needed. > > > > We should also review all tickets regarding bugs to make sure we have things as clean as possible for V11. > > > > Cary > > On Tuesday, August 4, 2020, 12:57:13 AM PDT, Martin Whitaker <ic...@ma...> wrote: > > > > > > I say go for it as soon as Cary finishes tidying up his work on queues. > > As 10.3 doesn't build with GCC 10 or bison 3.7, we really need to get a > > release out. > > > > On 04/08/2020 01:54, Stephen Williams wrote: > > > So, Cary, Martin? Thoughts on a release 11? I believe Cary has > > > something he wants to sneak into a release. What's the schule for > > > that? > > > > > > On Thu, Jul 30, 2020 at 11:05 AM Stephen Williams <st...@ic...> wrote: > > >> > > >> You make a very good point. This is being discussed, and we're > > >> thinking sooner rather than later. > > >> > > >> On Thu, Jul 30, 2020 at 11:03 AM Jean THOMAS <pu...@gi...> wrote: > > >>> > > >>> Hi everyone, > > >>> > > >>> Lots of changes have happened in iverilog since its last release. In > > >>> most Linux distros only the latest release is available, which is a year > > >>> old now. When can we expect a new release for iverilog? > > >>> > > >>> Cheers, > > >>> Jean > > >>> > > >>> > > >>> _______________________________________________ > > >>> Iverilog-devel mailing list > > >>> Ive...@li... > > >>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel > > >> > > >> > > >> > > >> -- > > >> 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 > > > _______________________________________________ > > Iverilog-devel mailing list > > Ive...@li... > > https://lists.sourceforge.net/lists/listinfo/iverilog-devel > > > > -- > 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 > _______________________________________________ > Iverilog-devel mailing list > Ive...@li... > https://lists.sourceforge.net/lists/listinfo/iverilog-devel -- 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: Evan L. <sa2...@cy...> - 2020-09-19 16:25:00
|
Verilog has no boolean type, so out of luck... |
|
From: Kevin S. <kvn...@ho...> - 2020-09-03 23:30:20
|
When I try to execute the Icarus tool on a System Verilog file I execute something like this: \Icarus\bin\iverilog -g2009 -o example.(file-suffix) example.sv What do people typically use for (file-suffix)? |
|
From: Kevin S. <kvn...@ho...> - 2020-09-03 19:01:37
|
I'm still very much interested in finding out whether or not it's possible for a Verilog function to have a boolean value as input, but while I was waiting for input on that I decided to rewrite a version of my Verilog code to use an (enum) instead of a (boolean). Much to my amazement, it appears that I can't use an (enum) as an input to a function either! I wrote the following code:
module useBin ();
typedef enum { ADD, MULTIPLY } binOp;
function integer execOp;
input integer left;
input integer right;
input binOp op;
begin
execOp = op == ADD ? left + right : left * right;
end
endfunction
endmodule
When I ran Icarus to simulate it I got:
D:\Hf\Verilog\Unpacked\Common>ive useBin
\Icarus\bin\iverilog -g2009 -o useBin.out useBin.sv
useBin.sv:8: syntax error
useBin.sv:5: error: Syntax error defining function.
D:\Hf\Verilog\Unpacked\Common>
I can kind of understand why a (boolean) might cause a problem when used as a function input, but why in the world would it be illegal to use an (enum) like my (binOp) as a function input?
|
|
From: Kevin S. <kvn...@ho...> - 2020-09-03 18:56:12
|
I've written a piece of code with inputs (left) and (right) and output (result), each of which operand is a single bit, which returns a logical one in (result) if (left) has the same value as (right), and returns a logical zero otherwise. My code is:
module ModGc ( result, left, right);
output result;
input left, right;
typedef enum { L_NOT, L_NAND, L_NOR } GateType;
typedef struct packed
{ GateType gateTp;
integer out;
integer inLow;
integer inHigh;
} LogGate;
localparam integer nmGates = 4;
localparam integer poolSize = 6;
localparam LogGate specs [ nmGates:1]
wire pool [ poolSize:1];
genvar ix;
initial
begin
specs[ 1].gateTp = L_NOR ; specs[ 1].out = 4; specs[ 1].inLow = 2; specs[ 1].inHigh = 3;
specs[ 2].gateTp = L_NOT ; specs[ 2].out = 5; specs[ 2].inLow = 4; specs[ 2].inHigh = 0;
specs[ 3].gateTp = L_NAND; specs[ 3].out = 6; specs[ 3].inLow = 2; specs[ 3].inHigh = 3;
specs[ 4].gateTp = L_NOR ; specs[ 4].out = 1; specs[ 4].inLow = 5; specs[ 4].inHigh = 6;
end
assign pool[ 2] = left;
assign pool[ 3] = right;
for (ix = 1; ix <= nmGates; ix = ix + 1)
case (specs[ ix].gateTp)
L_NOT
: not ntx( pool[ specs[ ix].out], pool[ specs[ ix].inLow]);
L_NAND
: nand nax( pool[ specs[ ix].out], pool[ specs[ ix].inLow], pool[ specs[ ix].inHigh]);
L_NOR
: nor nox( pool[ specs[ ix].out], pool[ specs[ ix].inLow], pool[ specs[ ix].inHigh]);
endcase
assign result = pool[ 1];
endmodule
I'm fully aware that there's a much simpler way to design an Equals circuit than this; again this is a simplification of a problem I'm having in more complex code. Anyhow, I run the Icarus simulator on this and get:
D:\Hf\Verilog\Unpacked\Common>\Icarus\bin\iverilog -g2009 -o ModGc.out ModGc.sv
ModGc.sv:16: sorry: cannot currently create a parameter of type 'LogGate' which was defined at: ModGc.sv:7.
ModGc.sv:16: syntax error
ModGc.sv:16: error: syntax error localparam list.
D:\Hf\Verilog\Unpacked\Common>
Can anyone tell me why the simulator is balking at line 16, where local parameter (specs) is declared? Any information anyone can give me on these compilation errors would be greatly appreciated.
|
|
From: Kevin S. <kvn...@ho...> - 2020-09-03 18:51:37
|
I've got a Verilog function that I'd like to behave slightly differently depending on the value of a boolean argument, an argument whose value can be either (true) or (false). I tried:
module sid ();
function integer execOp;
input integer left;
input integer right;
input boolean add;
begin
execOp = add ? left + right : left * right;
end
endfunction
endmodule
Then when I use Icarus to simulate it I get:
D:\Hf\Verilog\Unpacked\Common>\Icarus\bin\iverilog -g2009 -o sid.out sid.sv
sid.sv:6: syntax error
sid.sv:3: error: Syntax error defining function.
D:\Hf\Verilog\Unpacked\Common>
Line 6 is the line where I declare variable (add). Is there a way to pass a boolean argument to a function, or am I going to have to declare an (enum) that has values (true) and (false)?
|
|
From: Cary R. <cy...@ya...> - 2020-08-25 02:17:22
|
Hi Steve,
My development machine is in a wonky state so I have not been able to work on Icarus for a week or so. I'm also busy at work for the next few weeks so it could be a while before I can do much more. Given that and I have much of the queue and darray functionality working better I would say lets go for it.
There is one thing that needs to be fixed before we release. Some time ago a contributor made a change to the VVP file format and left in backwards compatibility. This resulted in a shift-reduce warning in VVP. We should update this to only support the new format and remove the shift-reduce issue. I think everything else should be good to go.
Cary
On Monday, August 24, 2020, 8:55:26 AM PDT, Stephen Williams <st...@ic...> wrote:
Cary,
How are we doing on this? Still on track for a v11 release in the near future?
On Tue, Aug 4, 2020 at 2:01 PM Cary R. via Iverilog-devel
<ive...@li...> wrote:
>
> I'm making good progress on my queue work. I'm taking some time to refactor what I have done so far and then will finish up. See what I committed last night for an example of the refactoring. Hopefully in the next week or so.
>
> The other thing that I would like to have dealt with before we release V11 is addressing the longest static prefix issue in the always_* sensitivity calculation. If one of you could look at this we could get V11 out sooner. I have a failing test and I think there is a github report as well. I can provide help as needed.
>
> We should also review all tickets regarding bugs to make sure we have things as clean as possible for V11.
>
> Cary
> On Tuesday, August 4, 2020, 12:57:13 AM PDT, Martin Whitaker <ic...@ma...> wrote:
>
>
> I say go for it as soon as Cary finishes tidying up his work on queues.
> As 10.3 doesn't build with GCC 10 or bison 3.7, we really need to get a
> release out.
>
> On 04/08/2020 01:54, Stephen Williams wrote:
> > So, Cary, Martin? Thoughts on a release 11? I believe Cary has
> > something he wants to sneak into a release. What's the schule for
> > that?
> >
> > On Thu, Jul 30, 2020 at 11:05 AM Stephen Williams <st...@ic...> wrote:
> >>
> >> You make a very good point. This is being discussed, and we're
> >> thinking sooner rather than later.
> >>
> >> On Thu, Jul 30, 2020 at 11:03 AM Jean THOMAS <pu...@gi...> wrote:
> >>>
> >>> Hi everyone,
> >>>
> >>> Lots of changes have happened in iverilog since its last release. In
> >>> most Linux distros only the latest release is available, which is a year
> >>> old now. When can we expect a new release for iverilog?
> >>>
> >>> Cheers,
> >>> Jean
> >>>
> >>>
> >>> _______________________________________________
> >>> Iverilog-devel mailing list
> >>> Ive...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
> >>
> >>
> >>
> >> --
> >> 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
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
--
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: Kevin C. <iv...@gr...> - 2020-08-24 22:31:08
|
Just FYI... -------- Forwarded Message -------- From: ICCAD <ne...@mp...> *WOSET 2020 Third Workshop on Open-Source EDA Technology* Co-located with ICCAD 2020, November 5. WOSET will now be a virtual workshop and may expand to more than a single day to accommodate time zones. There will be no registration cost to attend! The WOSET workshop aims to galvanize the open-source EDA movement. The workshop will bring together EDA researchers who are committed to open-source principles to share their experiences and coordinate efforts towards developing a reliable, fully open-source EDA flow. The workshop will feature presentations and posters that overview existing or under-development open-source tools, designs and technology libraries. A live demo session for tools in advanced state will be planned. The workshop will feature a panel on the present status and future challenges in open-source EDA, and how to coordinate efforts and ensure quality and interoperability across open-source tools. A cash award will be given for a Best Tool Award. Submissions (2-4 pages): Overview of an existing or under-development open-source EDA tool. Overview of support infrastructure (e.g. EDA databases and design benchmarks). Open-source cloud-based EDA tools Position statements (e.g. critical gaps, blockers/obstacles) Prizes: WOSET will award $850 in prizes to the top open-source contributions. *Important dates:* Sept 6th 2020: submission due date. Sept 15th 2020: notification due date. Submission Information: https://woset2020.hotcrp.com/ <https://click.icptrack.com/icp/relay.php?r=35110239&msgid=1930300&act=2D89&c=575804&destination=https%3A%2F%2Fwoset2020.hotcrp.com%2F&cf=29315&v=a05a9e6222d963c960eaa8eb5fce02b7d90c8745dd46c8fa4642de7da0073c32> Please submit 2-4 page (US Letter) papers using the IEEE Conference Template For inquiries, please contact Matthew Guthaus (mr...@uc... <mailto:mr...@uc...>) or Jose Renau (re...@uc... <mailto:re...@uc...>). This message was sent from ICCAD to cam...@gm.... It was sent from: ne...@mp..., MP Associates, Inc., 1721 Boxelder St., Ste. 107, Louisville, Colorado 80027. You can modify/update your subscription via the link below. Manage Your Subscription <https://app.icontact.com/icp/mmail-mprofile.php?r=35110239&l=29315&s=2D89&m=1930300&c=575804> |
|
From: Stephen W. <st...@ic...> - 2020-08-24 15:54:49
|
Cary, How are we doing on this? Still on track for a v11 release in the near future? On Tue, Aug 4, 2020 at 2:01 PM Cary R. via Iverilog-devel <ive...@li...> wrote: > > I'm making good progress on my queue work. I'm taking some time to refactor what I have done so far and then will finish up. See what I committed last night for an example of the refactoring. Hopefully in the next week or so. > > The other thing that I would like to have dealt with before we release V11 is addressing the longest static prefix issue in the always_* sensitivity calculation. If one of you could look at this we could get V11 out sooner. I have a failing test and I think there is a github report as well. I can provide help as needed. > > We should also review all tickets regarding bugs to make sure we have things as clean as possible for V11. > > Cary > On Tuesday, August 4, 2020, 12:57:13 AM PDT, Martin Whitaker <ic...@ma...> wrote: > > > I say go for it as soon as Cary finishes tidying up his work on queues. > As 10.3 doesn't build with GCC 10 or bison 3.7, we really need to get a > release out. > > On 04/08/2020 01:54, Stephen Williams wrote: > > So, Cary, Martin? Thoughts on a release 11? I believe Cary has > > something he wants to sneak into a release. What's the schule for > > that? > > > > On Thu, Jul 30, 2020 at 11:05 AM Stephen Williams <st...@ic...> wrote: > >> > >> You make a very good point. This is being discussed, and we're > >> thinking sooner rather than later. > >> > >> On Thu, Jul 30, 2020 at 11:03 AM Jean THOMAS <pu...@gi...> wrote: > >>> > >>> Hi everyone, > >>> > >>> Lots of changes have happened in iverilog since its last release. In > >>> most Linux distros only the latest release is available, which is a year > >>> old now. When can we expect a new release for iverilog? > >>> > >>> Cheers, > >>> Jean > >>> > >>> > >>> _______________________________________________ > >>> Iverilog-devel mailing list > >>> Ive...@li... > >>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel > >> > >> > >> > >> -- > >> 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 > _______________________________________________ > Iverilog-devel mailing list > Ive...@li... > https://lists.sourceforge.net/lists/listinfo/iverilog-devel -- 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: Kevin C. <iv...@gr...> - 2020-08-22 04:57:05
|
Here's some stuff for AMS - http://cameron-eda.com/2020/06/03/rolling-your-own-ams-simulator/ If you are on the VHDL committee reflector, I posted something there last week on doing multi-type resolution on nets for handling power (which could be done in Icarus too), pasted below. If you move the multi-type driver/receiver resolution stuff into C++ as a language independent thing you can use it for cosim - I used DPI in SV for AMS at Synopsys because the VCS crew will do nothing to support analog. Kev. On 2/21/2020 9:48 AM, Bryan Murdock wrote: > I did a little internet searching to try to find out the current state > of VHDL (mixed-language) support in iverilog is. It sounds like there > is interest and some work going on. I'm interested in helping out > with that. Any pointers on where I can start? > > Bryan > https://msd.llc/ > > > _______________________________________________ > Iverilog-devel mailing list > Ive...@li... > https://lists.sourceforge.net/lists/listinfo/iverilog-devel > ----------------------------- (Recapping from the call) Modeling analog using discrete techniques is not particularly difficult. Most analog simulators are actually an event driven framework using PWL signals which are discrete (just in the derivatives). The major differences between an analog simulator and a (classical) digital simulator are: 1. Models interact during evaluation (requiring the matrix solvers). 2. Wires carry potential and flow rather than potential or flow. Potential and flow form a discipline as described in the Verilog-AMS LRM (3.6.2 Disciplines) https://accellera.org/images/downloads/standards/v-ams/VAMS-LRM-2-4.pdf If you want to do power calculations in a simulator you need to have both potential and flow on wires, and resolve the natures independently (current and voltage for electrical), whatever drives a voltage needs to be a sink for (unbalanced) current on the net, and power is the multiple. Combining analog and digital behavior on a net in Verilog-AMS meant resolving drivers from opposite ends of the type spectrum, but with VHDL and newer SV you can have "real number" drivers and receivers. Resolving logic and real-number drivers is 90% the same job as doing a full AMS resolution - 1. Convert drivers to a common level (losslessly). 2. Resolve at the common level 3. Distribute resolved value (possibly with lossy down conversion) to receivers. In a purely digital context that's the sort of thing you want to do in a level shifter between power domains, i.e. a logic value in -> Voltage in the shifter (a lossless resolution), and Voltage goes to logic on the output (a lossy resolution). All that is just done in the Voltage nature, so can work in existing simulators fairly easily. Power-domain designation is done through discipline sub-classing. A secondary problem (not addressed in Verilog-AMS) is handling Xs, for that you want to slice the nature into 3 parts - value, certainty and strength. The resolution process above only applies to the value dimension, and the certainty aspect is just passed through the level shifter model. If the certainty value is defined separately in the driver type it is easy to handle automatically, where burying it in (say) a 0/1/X/Z enum makes life very hard (http://cameron-eda.com/2020/06/16/unnecessary-problems-x-propagation/). The discipline annotation in Verilog-AMS was designed to work orthogonally to the type system and in a way that can be back-annotated so that existing code would still work without it. Driver conversion in an AMS context sometimes requires state to be saved so conversions were done with modules rather than functions, the selection of the module was determined by using a sub-classing system for the natures and a set of rules (7.5 in the LRM above). In VHDL you could consider drivers as implicit signals attached to a net, and something you can wait on (tidier than Verilog-AMS). Having worked in mixed-signal simulation for many years, it has become apparent that there is quite a lot of similarity in the math used for things like "Fast-SPICE", and what you do to evaluate neural networks. The analog subset of VHDL is somewhat poorer than Verilog-AMS, and VHDL lacks the automatic boundary handling, however it is probably sufficient for defining neural network behavior for AI applications. Drivers in and out of such a description would match the real-number modeling mentioned above. That might make VHDL the right language for doing neural-network synthesis. Neural networks and data-flow descriptions are the level above RTL, and having no clocks in the specification makes simulation a lot faster for functional verification, but synthesis can be to synchronous logic (correct by construction). The upshot of that is doing the work to enable power modeling in VHDL, would probably give you the ability to do some interesting things in synthesis for low-power analog/AI applications that are currently not served by SystemVerilog, with the possibility of displacing the RTL methodology further down the line. Kev. ------------------------------------------------------------------------ To unsubscribe from the VHDL-200X list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=VHDL-200X&A=1 |
|
From: Cary R. <cy...@ya...> - 2020-08-11 05:13:47
|
No replies so I have turned in a change with some changes relative to what I wrote previously. File/line information is not enabled by default. When it is enabled, tracing is now no longer enabled by default. This allows -pfileline=1 to be used to turn on the file/line information for the queue warning messages without having all the tracing information being displayed. To turn on tracing use the trace on command from the vvp interactive prompt.
Cary
On Sunday, August 9, 2020, 11:34:51 AM PDT, Cary R. via Iverilog-devel <ive...@li...> wrote:
A long time ago I added support for tracking procedural code lines by emitting information when various commands are executed. The default is when these file/line opcodes are seen in the compiler output they enable this functionality in vvp. To get better error messages in the opcodes I would like to enable emitting the file/line opcode by default and still allow them to be disabled if users are looking for maximum performance and can live with the file/line information missing in the procedural commands warning/error messages. Basically I would switch it to -pfileline=1 as the default and -pfileline=0 can be used to disable emitting the file/line opcodes. I will then update VVP to not automatically emit the per line information, but it will be available for the warning/error messages. If the user wants to emit the per line information they will do this using the control functionality already built into vvp.
The summary is emit file/line opcodes by default in the compiler output, but do not emit the individual file/line information in vvp by default.
Are there any objections?
I personally think it is really bad to emit procedural error messages without corresponding file/line information. I believe I can also add this information to the corresponding assertions to make our debug work easier when things go wrong in the procedural code.
Cary
_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel
|
|
From: Cary R. <cy...@ya...> - 2020-08-09 18:34:23
|
A long time ago I added support for tracking procedural code lines by emitting information when various commands are executed. The default is when these file/line opcodes are seen in the compiler output they enable this functionality in vvp. To get better error messages in the opcodes I would like to enable emitting the file/line opcode by default and still allow them to be disabled if users are looking for maximum performance and can live with the file/line information missing in the procedural commands warning/error messages. Basically I would switch it to -pfileline=1 as the default and -pfileline=0 can be used to disable emitting the file/line opcodes. I will then update VVP to not automatically emit the per line information, but it will be available for the warning/error messages. If the user wants to emit the per line information they will do this using the control functionality already built into vvp. The summary is emit file/line opcodes by default in the compiler output, but do not emit the individual file/line information in vvp by default. Are there any objections? I personally think it is really bad to emit procedural error messages without corresponding file/line information. I believe I can also add this information to the corresponding assertions to make our debug work easier when things go wrong in the procedural code. Cary |
|
From: Cary R. <cy...@ya...> - 2020-08-04 21:01:39
|
I'm making good progress on my queue work. I'm taking some time to refactor what I have done so far and then will finish up. See what I committed last night for an example of the refactoring. Hopefully in the next week or so.
The other thing that I would like to have dealt with before we release V11 is addressing the longest static prefix issue in the always_* sensitivity calculation. If one of you could look at this we could get V11 out sooner. I have a failing test and I think there is a github report as well. I can provide help as needed.
We should also review all tickets regarding bugs to make sure we have things as clean as possible for V11.
Cary
On Tuesday, August 4, 2020, 12:57:13 AM PDT, Martin Whitaker <ic...@ma...> wrote:
I say go for it as soon as Cary finishes tidying up his work on queues.
As 10.3 doesn't build with GCC 10 or bison 3.7, we really need to get a
release out.
On 04/08/2020 01:54, Stephen Williams wrote:
> So, Cary, Martin? Thoughts on a release 11? I believe Cary has
> something he wants to sneak into a release. What's the schule for
> that?
>
> On Thu, Jul 30, 2020 at 11:05 AM Stephen Williams <st...@ic...> wrote:
>>
>> You make a very good point. This is being discussed, and we're
>> thinking sooner rather than later.
>>
>> On Thu, Jul 30, 2020 at 11:03 AM Jean THOMAS <pu...@gi...> wrote:
>>>
>>> Hi everyone,
>>>
>>> Lots of changes have happened in iverilog since its last release. In
>>> most Linux distros only the latest release is available, which is a year
>>> old now. When can we expect a new release for iverilog?
>>>
>>> Cheers,
>>> Jean
>>>
>>>
>>> _______________________________________________
>>> Iverilog-devel mailing list
>>> Ive...@li...
>>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>>
>>
>>
>> --
>> 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...> - 2020-08-04 07:56:33
|
I say go for it as soon as Cary finishes tidying up his work on queues. As 10.3 doesn't build with GCC 10 or bison 3.7, we really need to get a release out. On 04/08/2020 01:54, Stephen Williams wrote: > So, Cary, Martin? Thoughts on a release 11? I believe Cary has > something he wants to sneak into a release. What's the schule for > that? > > On Thu, Jul 30, 2020 at 11:05 AM Stephen Williams <st...@ic...> wrote: >> >> You make a very good point. This is being discussed, and we're >> thinking sooner rather than later. >> >> On Thu, Jul 30, 2020 at 11:03 AM Jean THOMAS <pu...@gi...> wrote: >>> >>> Hi everyone, >>> >>> Lots of changes have happened in iverilog since its last release. In >>> most Linux distros only the latest release is available, which is a year >>> old now. When can we expect a new release for iverilog? >>> >>> Cheers, >>> Jean >>> >>> >>> _______________________________________________ >>> Iverilog-devel mailing list >>> Ive...@li... >>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel >> >> >> >> -- >> 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." > > > |
31 messages has been excluded from this view by a project administrator.
