iverilog-devel — Conversations on matters of Icarus Verilog development

Re: [Iverilog-devel] vvp runtime error

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

The iverilog flag Steve mentioned is -pfileline=1. This will help if the problem is in the procedural code, but does nothing for continuous assignments.
Cary 

     On Wednesday, January 28, 2015 1:10 PM, Stephen Williams <st...@ic...> wrote:
   

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


That is the runtime griping that a value assigned into it
(either by procedural assign or passing through the netlist)
is not the expected size or format. That is probably a code
generator problem. You may try turning on line-by-line debug
printing (the vvp code generator can do this for you, I forget
the exact command line flags.) and see what kind of assignment
does this to you.

On 01/28/2015 12:20 PM, Lonnie L Gliem wrote:
> -v: vvp_net_sig.cc:181: virtual void 
> vvp_fun_signal4_sa::recv_vec4(vvp_net_ptr_t, const vvp_vector4_t&, 
> void**): Assertion `bit.size() == bits4_.size()' failed.

- -- 
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com          But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlTJUA4ACgkQrPt1Sc2b3ik2uwCfT9kvffVfSC8IggIV7W6Vy9Zj
vi8AnRezNv21gcJ4h+6PZnvh2jHyudAp
=IB35
-----END PGP SIGNATURE-----

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


   

Re: [Iverilog-devel] vvp runtime error

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

Hi Lonnie,
It did appear multiple times. I believe the list software does not send you a copy, but if you look in the archives it is usually there.
The issue you are experiencing is that somehow a value is being put to a signal and the width of the value does not match the width of the signal. You may be able to get some information to narrow this down by printing the various state information before the assert() (e.g. the actual current and new bit values/size, etc.). That should allow you to then try to debug this down to a specific piece of Verilog code. This can often be fairly convoluted (e.g. a signal passed to a port with a specific type of driver, etc.), so it's not always easy to create a small/simple example.
I can help you off list if needed, but without the source code you are going to need to do most of the basic debug work.
Have you tried this with other version to see if this is just a problem in that snapshot?

These problems are often a bug in the code generated by the compiler for corner cases that are not handled correctly.
Cary
 

     On Wednesday, January 28, 2015 12:45 PM, Lonnie L Gliem <lg...@sr...> wrote:
   

 <!--#yiv0649106253 _filtered #yiv0649106253 {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;} _filtered #yiv0649106253 {font-family:Tahoma;panose-1:2 11 6 4 3 5 4 4 2 4;}#yiv0649106253 #yiv0649106253 p.yiv0649106253MsoNormal, #yiv0649106253 li.yiv0649106253MsoNormal, #yiv0649106253 div.yiv0649106253MsoNormal {margin:0in;margin-bottom:.0001pt;font-size:11.0pt;font-family:"Calibri", "sans-serif";}#yiv0649106253 a:link, #yiv0649106253 span.yiv0649106253MsoHyperlink {color:blue;text-decoration:underline;}#yiv0649106253 a:visited, #yiv0649106253 span.yiv0649106253MsoHyperlinkFollowed {color:purple;text-decoration:underline;}#yiv0649106253 span.yiv0649106253EmailStyle17 {font-family:"Calibri", "sans-serif";color:windowtext;}#yiv0649106253 span.yiv0649106253EmailStyle18 {font-family:"Calibri", "sans-serif";color:#1F497D;}#yiv0649106253 .yiv0649106253MsoChpDefault {font-size:10.0pt;} _filtered #yiv0649106253 {margin:1.0in 1.0in 1.0in 1.0in;}#yiv0649106253 div.yiv0649106253WordSection1 {}-->Hi Cary,I tried posting this to the iverilog devel list but I don’t think it’s working so thought I would try sending it direct to you. ThanksLonnie   From: Lonnie L Gliem [mailto:lg...@sr...] 
Sent: Wednesday, January 28, 2015 2:21 PM
To: 'ive...@li...'
Subject: vvp runtime error  Sorry if this is a multiple posting but I never saw the last one.I started getting a runtime error with 20150105 snapshot. Can someone tell me how to get more info on what it is blowing up on. Here is the error.   -v: vvp_net_sig.cc:181: virtual void vvp_fun_signal4_sa::recv_vec4(vvp_net_ptr_t, const vvp_vector4_t&, void**): Assertion `bit.size() == bits4_.size()' failed.      

   

Re: [Iverilog-devel] vvp runtime error

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

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


That is the runtime griping that a value assigned into it
(either by procedural assign or passing through the netlist)
is not the expected size or format. That is probably a code
generator problem. You may try turning on line-by-line debug
printing (the vvp code generator can do this for you, I forget
the exact command line flags.) and see what kind of assignment
does this to you.

On 01/28/2015 12:20 PM, Lonnie L Gliem wrote:
> -v: vvp_net_sig.cc:181: virtual void 
> vvp_fun_signal4_sa::recv_vec4(vvp_net_ptr_t, const vvp_vector4_t&, 
> void**): Assertion `bit.size() == bits4_.size()' failed.

- -- 
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlTJUA4ACgkQrPt1Sc2b3ik2uwCfT9kvffVfSC8IggIV7W6Vy9Zj
vi8AnRezNv21gcJ4h+6PZnvh2jHyudAp
=IB35
-----END PGP SIGNATURE-----

[Iverilog-devel] vvp runtime error

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

Sorry if this is a multiple posting but I never saw the last one.

I started getting a runtime error with 20150105 snapshot. Can someone tell
me how to get more info on what it is blowing up on. Here is the error. 

 

-v: vvp_net_sig.cc:181: virtual void
vvp_fun_signal4_sa::recv_vec4(vvp_net_ptr_t, const vvp_vector4_t&, void**):
Assertion `bit.size() == bits4_.size()' failed.

 

 

 

[Iverilog-devel] vvp runtime error

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

I started getting a runtime error with 20150105 snapshot. Can someone tell
me how to get more info on what it is blowing up on. Here is the error. 

 

-v: vvp_net_sig.cc:181: virtual void
vvp_fun_signal4_sa::recv_vec4(vvp_net_ptr_t, const vvp_vector4_t&, void**):
Assertion `bit.size() == bits4_.size()' failed.

 

 

Thanks

Lonnie

[Iverilog-devel] Error at runtime

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

I am getting a runtime error and was wondering if there is anyway I can
get somemore info on what it is vlowing up on. 

Here is the error:
-v: vvp_net_sig.cc:181: virtual void
vvp_fun_signal4_sa::recv_vec4(vvp_net_ptr_t, const vvp_vector4_t&,
void**): Assertion `bit.size() == bits4_.size()' failed.

Thanks
Lonnie

[Iverilog-devel] Dynamic arrays

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

Just to let everyone know I am working on a number of issues related to dynamic arrays and currently two tests are failing because of compiler checks I just pushed to git. I hope to get the functionality implemented to get these working fairly soon.
Here is a list of know issues with dynamic arrays:
The sign information is being lost in the compiler and everything is coming out unsigned. This is a compiler bug.

Four-state types are not supported at all and this is now reported in the compiler. This is what is causing the two tests to fail. The compiler was previously silently converting these to two-state variables.
They only support the SystemVerilog 2-state atomic types (8, 16, 32 and 64 bits). Other two-state sizes are now reported as not supported by the compiler. They were previously silently converted to an 8-bit unsigned value.

There is an issue when using the VPI to access words from the dynamic array where once you use the VPI to access an element if the variable is updated to contain a different array (e.g. new[4], delete, new[5]) the original iterator array is still used. This is a only a problem when the size of the subsequent dynamic array is larger. For example, a 4 element array that is replaced with a 5 element array will fail because the iterator code only has four entries for the 5 element array and will crash vvp when trying to access the fifth element.
We need to add VPI support for typespecs so that we can determine the array type. This is needed for compiletf routines when we want to restrict the input parameter to a particular type of dynamic array (e.g. vector vs real, etc.).

If there are other issues you know about please let me know and I will work to clean these up.
I will likely implement these in the order given since that matches our typical priority. The VPI issues are particularly complex and may take significantly longer than the others and may just be put on hold until I or someone else has a large enough block of free time to take them on.

Cary

[Iverilog-devel] Minor update

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

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

As I know Cary is currently working reworking the dynamic array
routines, so to avoid disruption I propose a minor update [1] that
allows to use non 8 multiple width vectors with dynamic arrays.

Taking the opportunity, I would like to express my gratitude to Cary
for fixes in dynamic arrays <-> vectors conversion code.

It seems that finally I have unwinded the stack of dependencies for
VHDL subprograms taking advantage of unbounded vectors, so now I am
back to vhdlpp development. For the moment, there is only a small
change that allows to use array size attributes ('range, 'left,
'right) in subprograms.

Both mentioned features are covered with tests [2]. Have a nice weekend!

Regards,
Orson

1. https://github.com/steveicarus/iverilog/pull/51
2. https://github.com/orsonmmz/ivtest/tree/vhdl_range_func_test
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJUuVHDAAoJEBRwGu1hpbJ1LMcH/A55vi28ZsO0SU6ajI0DwDDt
7jhMFxR2LBcIUPvVFs/lrLRQ35GV9okciKP0rdB56olI0ZLFbSnQ0Cg4VT7dYSQd
rPOOQoK7d/ruwP0qi8zZ0m1dOMqtY2aPG+LM51tkpdCFqGyF48mFqbJhFKKD1fXF
zU5HvfA/xcV+9fNyNylc8MwnhDfFP09ea8xET3/h1phJCp6UfYJjjX7tueumV3Ed
gLAu4Lm268VrkYCEmlI1GM/kuvJZhezRJ1gbUvHMAno3eaZ01BZop5F6OD2qMgNO
f4/oX2ZBLX2ObtxrvCnDFDHAMYS39d6/VOCCEr+s3zwkvqnbB83ZhQNSnHY8kvw=
=+osP
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Unpacked arrays extension

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

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


Oh Geez I forgot I'm sorry I'll take care of it today sorry!

On 01/12/2015 02:58 AM, Maciej Sumiński wrote:
> Hi,
> 
> Just a gentle reminder about a branch that really would love to be 
> merged to the master. It might have been forgotten due to the 
> Christmas preparations rush.
> 
> The branch is rebased [1] and passes the current test suite. If
> there are any issues - please let me know and I will fix them.
> 
> Regards, Orson
> 
> 1. https://github.com/orsonmmz/iverilog/tree/darray
> 
> On 12/19/2014 11:22 AM, Maciej Sumiński wrote:
>> Hi Steve,
> 
>> I have prepared a set of patches to extend the functionality 
>> related to unpacked arrays [1] along with tests [2]. If I have
>> not missed anything, now I should be able to continue my work on
>>  vhdlpp.
> 
>> Casting between dynamic arrays and vectors currently is realized
>>  with Icarus-specific VPI functions 
>> ($ivl_darray_metho$[from/to]_vec). Ideally, it should be done 
>> using type casting, as it was proposed earlier, but I would
>> rather implement it a bit later.
> 
>> I had some doubts if it is enough to simply add a case statement
>> to support dynamic arrays of logic type [3]. The output vvp code
>> uses %store/dar/vec4 and %load/dar/vec4, so I assume it should be
>> fine.
> 
>> Regards, Orson
> 
>> 1. https://github.com/steveicarus/iverilog/pull/50 2. 
>> https://github.com/orsonmmz/ivtest/tree/darray_test 3. 
>> https://github.com/orsonmmz/iverilog/commit/aed69f2c6bc3e8c6b9289e5cfde824fd1b3653b9
>
>> 
- -- 
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlSz8xMACgkQrPt1Sc2b3ikllwCeM5iMGvi/KdZBs6msb99ylE0V
dSsAn0ooJwPrS6w0n7XYZFzBw/yuKT26
=r7SG
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Unpacked arrays extension

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

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

Hi,

Just a gentle reminder about a branch that really would love to be
merged to the master. It might have been forgotten due to the
Christmas preparations rush.

The branch is rebased [1] and passes the current test suite. If there
are any issues - please let me know and I will fix them.

Regards,
Orson

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

On 12/19/2014 11:22 AM, Maciej Sumiński wrote:
> Hi Steve,
> 
> I have prepared a set of patches to extend the functionality 
> related to unpacked arrays [1] along with tests [2]. If I have not 
> missed anything, now I should be able to continue my work on 
> vhdlpp.
> 
> Casting between dynamic arrays and vectors currently is realized 
> with Icarus-specific VPI functions 
> ($ivl_darray_metho$[from/to]_vec). Ideally, it should be done
> using type casting, as it was proposed earlier, but I would rather 
> implement it a bit later.
> 
> I had some doubts if it is enough to simply add a case statement to
> support dynamic arrays of logic type [3]. The output vvp code uses
> %store/dar/vec4 and %load/dar/vec4, so I assume it should be fine.
> 
> Regards, Orson
> 
> 1. https://github.com/steveicarus/iverilog/pull/50 2. 
> https://github.com/orsonmmz/ivtest/tree/darray_test 3. 
> https://github.com/orsonmmz/iverilog/commit/aed69f2c6bc3e8c6b9289e5cfde824fd1b3653b9
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJUs6i0AAoJEBRwGu1hpbJ1gogH/iE3RutsEfMsf9Fa44ULUiOQ
yhagDLSKpzkcPljKf2/l58yzHwOidckLw/iz5ZXmzYmFJfLdNHCU1z6ixBbylcRt
bBD2nXRuuzH/P+A6OwaM31/PUUAYKVgJQLU8HUe4T9aNMiRM5cTyLf5xrtGJ01AR
jQitTePs+9XjUTVMncWnCVqMZ06eBIL5zkDxX8nAgrTfcybEqHc+yU4cfdVuhHzu
c8h56NpvHBuaAcKNEVZKcMTC8mugH+he3Cc0zXeyM9pNlFT+dvQJvXwXlegmL4oU
Mx1pZR/kI4jUEj7uFv6yKjX1iMicKPgLg0FZJArp4IUxeaeKeChBROZHVemGnLM=
=qmve
-----END PGP SIGNATURE-----

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

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

We started adding parts of SystemVerilog in V0.10 (development from git or snapshots). It is fairly trivial to compile Icarus from source. Instructions are here: Installation Guide

|   |
|   |  |   |   |   |   |   |
| Installation GuideIcarus may be installed from source code or from pre-packaged binary distributions. Icarus is developed for Unix-like environments but can also be comp... |
|  |
| View on iverilog.wikia.com | Preview by Yahoo |
|  |
|   |

 

     On Friday, January 9, 2015 12:57 PM, Lonnie L Gliem <lg...@sr...> wrote:
   

 #yiv1803080946 #yiv1803080946 -- _filtered #yiv1803080946 {font-family:Helvetica;panose-1:2 11 6 4 2 2 2 2 2 4;} _filtered #yiv1803080946 {font-family:Helvetica;panose-1:2 11 6 4 2 2 2 2 2 4;} _filtered #yiv1803080946 {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;} _filtered #yiv1803080946 {font-family:Tahoma;panose-1:2 11 6 4 3 5 4 4 2 4;}#yiv1803080946 #yiv1803080946 p.yiv1803080946MsoNormal, #yiv1803080946 li.yiv1803080946MsoNormal, #yiv1803080946 div.yiv1803080946MsoNormal {margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv1803080946 a:link, #yiv1803080946 span.yiv1803080946MsoHyperlink {color:blue;text-decoration:underline;}#yiv1803080946 a:visited, #yiv1803080946 span.yiv1803080946MsoHyperlinkFollowed {color:purple;text-decoration:underline;}#yiv1803080946 span.yiv1803080946EmailStyle17 {color:#1F497D;}#yiv1803080946 .yiv1803080946MsoChpDefault {font-size:10.0pt;} _filtered #yiv1803080946 {margin:1.0in 1.0in 1.0in 1.0in;}#yiv1803080946 div.yiv1803080946WordSection1 {}#yiv1803080946 What is the earliest version of iverilog that has –g2009 support I tried it with .9.6 on centos and it only has g2005? Is that the latest version on centos?  That’s what I see on centos 6.5.  Lonnie  From: Cary R. [mailto:cy...@ya...] 
Sent: Thursday, January 08, 2015 3:37 PM
To: Discussions concerning Icarus Verilog development
Subject: Re: [Iverilog-devel] do while loop syntax.  Are you telling Icarus to use SystemVerilog (e.g. -g2009, -g2012 or -g2005-sv)? The following example runs correctly (displays 0 to 9) using the latest code from git and the -g2009 flag:

module top;
  integer val;

  initial begin
    val = 0;
    do begin
      $display(val);
      val += 1;
    end while (val < 10);
  end
endmodule  Since SystemVerilog is not that complete in Icarus it is not enabled by default.  Cary  On Thursday, January 8, 2015 1:17 PM, Lonnie Gliem <lg...@sr...> wrote:  What is the do while syntax for iverilog. I have the loop below that
compiles fine in vcs but errors out in iverilog.

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

Here are the errors.

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

Here is the version:

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

Thansk for the help
Lonnie


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



   

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

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

And some comments explaining why you had to resort to all this would also be helpful. Not a full treatise, but something more than just the code would be appreciated.
 

     On Friday, January 9, 2015 12:33 PM, Martin Whitaker <mai...@ma...> wrote:
   

 Stephen Williams wrote:
> This problem has been solved in the parser for module ports.

OK, that's basically what I had in mind when I said I could solve this by 
building my own mini state machine and parser within the modport_ports_list 
rule (and what Niels suggested as well). It's a bit more complicated than the 
module ports case, because you have modport expressions, task/function 
import/export, and clocking declarations thrown into the mix. It's ugly, but 
it works.

For anyone interested, the solution looks like this:

modport_ports_list
  : modport_port_declaration
  | modport_ports_list ',' modport_port_declaration
  | modport_ports_list ',' modport_simple_port
      { if (last_modport_port != MODPORT_SIMPLE)
              yyerror(@3, "syntax error");
      }
  | modport_ports_list ',' modport_tf_port
      { if (last_modport_port != MODPORT_TF)
              yyerror(@3, "syntax error");
      }
  | modport_ports_list ',' IDENTIFIER
      { if (last_modport_port == MODPORT_CLOCKING)
              yyerror(@3, "syntax error");
      }
  | modport_ports_list ','
      { yyerror(@2, "error: NULL port declarations are not allowed"); }
  ;

modport_port_declaration
  : attribute_list_opt port_direction IDENTIFIER
      { last_modport_port = MODPORT_SIMPLE;
      }
  | attribute_list_opt port_direction modport_simple_port
      { last_modport_port = MODPORT_SIMPLE;
      }
  | attribute_list_opt import_export IDENTIFIER
      { last_modport_port = MODPORT_TF;
      }
  | attribute_list_opt import_export modport_tf_port
      { last_modport_port = MODPORT_TF;
      }
  | attribute_list_opt K_clocking IDENTIFIER
      { last_modport_port = MODPORT_CLOCKING;
      }
  ;

modport_simple_port
  : '.' IDENTIFIER '(' expression ')'
  ;

modport_tf_port
  : K_task IDENTIFIER
  | K_task IDENTIFIER '(' tf_port_list_opt ')'
  | K_function data_type_or_implicit_or_void IDENTIFIER
  | K_function data_type_or_implicit_or_void IDENTIFIER '(' tf_port_list_opt ')'
  ;

(and yes, I'll be putting in better error messages).

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


   

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

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

What is the earliest version of iverilog that has –g2009 support I tried it with .9.6 on centos and it only has g2005? Is that the latest version on centos?  That’s what I see on centos 6.5.

 

Lonnie

 

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

 

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





module top;
  integer val;

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

 

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

 

Cary

 

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

 

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

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

Here are the errors.

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

Here is the version:

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

Thansk for the help
Lonnie


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

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

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

Stephen Williams wrote:
> This problem has been solved in the parser for module ports.

OK, that's basically what I had in mind when I said I could solve this by 
building my own mini state machine and parser within the modport_ports_list 
rule (and what Niels suggested as well). It's a bit more complicated than the 
module ports case, because you have modport expressions, task/function 
import/export, and clocking declarations thrown into the mix. It's ugly, but 
it works.

For anyone interested, the solution looks like this:

modport_ports_list
   : modport_port_declaration
   | modport_ports_list ',' modport_port_declaration
   | modport_ports_list ',' modport_simple_port
       { if (last_modport_port != MODPORT_SIMPLE)
               yyerror(@3, "syntax error");
       }
   | modport_ports_list ',' modport_tf_port
       { if (last_modport_port != MODPORT_TF)
               yyerror(@3, "syntax error");
       }
   | modport_ports_list ',' IDENTIFIER
       { if (last_modport_port == MODPORT_CLOCKING)
               yyerror(@3, "syntax error");
       }
   | modport_ports_list ','
       { yyerror(@2, "error: NULL port declarations are not allowed"); }
   ;

modport_port_declaration
   : attribute_list_opt port_direction IDENTIFIER
       { last_modport_port = MODPORT_SIMPLE;
       }
   | attribute_list_opt port_direction modport_simple_port
       { last_modport_port = MODPORT_SIMPLE;
       }
   | attribute_list_opt import_export IDENTIFIER
       { last_modport_port = MODPORT_TF;
       }
   | attribute_list_opt import_export modport_tf_port
       { last_modport_port = MODPORT_TF;
       }
   | attribute_list_opt K_clocking IDENTIFIER
       { last_modport_port = MODPORT_CLOCKING;
       }
   ;

modport_simple_port
   : '.' IDENTIFIER '(' expression ')'
   ;

modport_tf_port
   : K_task IDENTIFIER
   | K_task IDENTIFIER '(' tf_port_list_opt ')'
   | K_function data_type_or_implicit_or_void IDENTIFIER
   | K_function data_type_or_implicit_or_void IDENTIFIER '(' tf_port_list_opt ')'
   ;

(and yes, I'll be putting in better error messages).

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

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

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


This problem has been solved in the parser for module ports.
Could your problem be the context where you are using the modport_item?

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


- -- 
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlSwBkMACgkQrPt1Sc2b3ikydwCgmi49m6UKM9btXVtU/EwIaeuN
caQAn1W4CCkfaZEutSDPotfUcq4tLddt
=b7NG
-----END PGP SIGNATURE-----

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

[<ni...@ly...>]

Evan Lavelle <sa2...@cy...> writes:

> Ok - thanks for the example - my 'modports_port_list' example parse 
> should therefore look like this:
>
> input a, b, c, output d, e, f
>
> this can always be parsed with one token of look-ahead as long as the 
> lexer can distinguish between 'port_direction' and IDENTIFIER (it needs 
> to do this when it reaches 'output', not ','). This begs the question of 
> why it can't, which is what (2) in my last post was about.

I hope I understand this correctly. I think the grammar fragment given
wants to parse

   input a, b, c, output d, e, f

as

  (input (a , b , c)) , (output (d , e , f))

where I use parentheses to mark sequences of tokens corresponding to a
non-terminal. Outer parentheses correspond to modport_ports_declaration,
and the inner to modport_simple_port_list. And that's why it needs to
make a decision when examining each comma.

I think the sane solution is to reorganize the grammar so that this
example is parsed as a single comma-separated list with no nesting,

  (input a), (b), (c), (output d), (e), (f)

and sort out the relations between elements in some other way. I don't
understand the semantics, but hopefully, that should be no more
difficult than letting the port_direction propagate to later elements in
the list where the port_direction is omitted.

Maybe something like

  simple_port
      : IDENTIFIER
      | '.' IDENTIFIER '(' expression ')'
      ;
  directed_port
      : attribute_list_opt port_direction simple_port
      ;

  modport_ports_list
      : directed_port
      | modport_ports_list ',' directed_port
      | modport_ports_list ',' simple_port
        { ... derive port direction (and attributes?) from preceding port ... }
      ;
      
Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.

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

[Evan L. <sa2...@cy...>]

On 09/01/2015 02:15, Pete Johnson wrote:

> modport master (input a, b, output c, d);

Ok - thanks for the example - my 'modports_port_list' example parse 
should therefore look like this:

input a, b, c, output d, e, f

this can always be parsed with one token of look-ahead as long as the 
lexer can distinguish between 'port_direction' and IDENTIFIER (it needs 
to do this when it reaches 'output', not ','). This begs the question of 
why it can't, which is what (2) in my last post was about.

-Evan

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

[Evan L. <sa2...@cy...>]

On 09/01/2015 02:26, Jonathan David wrote:
> Sv keywords are never identifiers unless escaped.

Yes, but...

>> in a, b, c, out d, e, f;  // with a ';'?

(actually 'input a, b, c, output d, e, f')

how does the parser know? It's normally trivial, but that doesn't seem 
to be the case here.

-Evan

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

[Iztok J. <izt...@gm...>]

I do not know if this helps. Verilator already implements interfaces. I
have no idea what kind of parser they use, if the source code does not
help, the author might help with the discussion.

Regards,
Iztok Jeras

On Fri, Jan 9, 2015 at 9:19 AM, Niels Möller <ni...@ly...> wrote:

> Pete Johnson <pe...@be...> writes:
>
> > What you suggest is not how the mod port syntax works. It uses the
> > keywords “input” and “output”, not “in” and “out”. Here is an example
> > from the standard
> >
> > interface i2;
> > wire a, b, c, d;
> > modport master (input a, b, output c, d);
> >
> > modport slave (output a, b, input c, d);
> >
> > endinterface
>
> Thanks for the example. That makes it a lot easier to follow the
> discussion for those of us not familiar with system verilog.
>
> One question: Is the grouping of a,b and c,d essential, or is "(input a,
> b, output c, d)" just a shorthand for "(input a, input b, output c,
> output d)"?
>
> In the latter case, it would make sense to me to make it a single list
> of entries where the port_direction is optional, and then have some
> semantic rules (i.e., not really part of the grammar) which (i)
> remembers the most recent port_direction and applies it to following
> entries, and (ii) generates a syntax error in case the first entry is
> missing a port_direction. (Not sure if part (ii) is easy to express in
> the grammar, if it is, then that's preferable of course).
>
> Regards,
> /Niels
>
> --
> Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
> Internet email is subject to wholesale government surveillance.
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming! The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is
> your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>

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

[<ni...@ly...>]

Pete Johnson <pe...@be...> writes:

> What you suggest is not how the mod port syntax works. It uses the
> keywords “input” and “output”, not “in” and “out”. Here is an example
> from the standard
>
> interface i2;
> wire a, b, c, d;
> modport master (input a, b, output c, d);
>
> modport slave (output a, b, input c, d);
>
> endinterface

Thanks for the example. That makes it a lot easier to follow the
discussion for those of us not familiar with system verilog.

One question: Is the grouping of a,b and c,d essential, or is "(input a,
b, output c, d)" just a shorthand for "(input a, input b, output c,
output d)"?

In the latter case, it would make sense to me to make it a single list
of entries where the port_direction is optional, and then have some
semantic rules (i.e., not really part of the grammar) which (i)
remembers the most recent port_direction and applies it to following
entries, and (ii) generates a syntax error in case the first entry is
missing a port_direction. (Not sure if part (ii) is easy to express in
the grammar, if it is, then that's preferable of course).

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.

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

[Jonathan D. <jb_...@ya...>]

Sv keywords are never identifiers unless escaped.  

Sent from Yahoo Mail on Android

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

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

Evan,

What you suggest is not how the mod port syntax works. It uses the keywords “input” and “output”, not “in” and “out”. Here is an example from the standard

interface i2;
wire a, b, c, d;
modport master (input a, b, output c, d);

modport slave (output a, b, input c, d);

endinterface


Martin never told us what the non-terminal “port_direction” matches from parse.y in the icarus source it looks like it can be the keywords “input”, “output”, “inout” or “ref”.

So, my guess is that the issue arises when the parser has parsed the identifier “b” and is now staring at a comma. Should it shift the comma and continue with the modport_simple_port_list non-terminal or should it reduce that and start a new mod port_ports_declaration.

It is possible that Martin could use the GLR algorithm with bison rather than the default LR(1) algorithm. This would resolve the issue by essentially allowing more than one lookahead token. See http://www.gnu.org/software/bison/manual/html_node/Simple-GLR-Parsers.html <http://www.gnu.org/software/bison/manual/html_node/Simple-GLR-Parsers.html> for details on this.

Otherwise you would need to have some semantic tie-in to the lexor. You would basically clue it in to the fact that you are parsing a modport and if it sees a comma followed by input, output, inout, or ref to have it conveniently return a new type of token which is not a comma, but something which explicitly indicates to the parser that the  modport_simple_port_list is ending and needs to be reduced.

-Pete

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

[Evan L. <sa2...@cy...>]

With no knowledge whatever of SV, I imagine the problem is that a 
modport_ports_list might look like this:

in a, b, c, out d, e, f;   // with a ';'?

and it's not immediately obvious to the parser if 'out' is a 
port_direction, or an IDENTIFIER - is that right?

If so, you've got 2 options:

1 - find out whether 'out' is followed by a comma, which is presumably 
why you mention lookahead. At first sight, I'd be inclined to handle 
this by instead re-factoring a port list as something like this:

port_list
   : first_port
   | port_list ',' IDENTIFIER

first_port : port_direction IDENTIFIER ;

2 - add a terminal for PORT_IDENTIFIER, which is identical to 
IDENTIFIER, but doesn't allow the presumably-reserved 'in', 'out', etc. 
This will just work anyway if you've got your ordering correct in the 
lex file - ie. you match on 'in'/'out'/etc before matching identifiers. 
Having said that, I have a very vague recollection that lexing in Icarus 
is table-based in some way, so you may not be able to do this. If so, 
you could have a regex for PORT_IDENTIFIER which excludes the 
directions. Or something like that... :)

BTW, I agree that you should never allow *any* conflicts in your grammars.

-Evan

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

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

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

I've already tried flattening the modport_ports_list and 
modport_ports_declaration rules into a single rule. This doesn't fix the 
problem. Maybe I'm being dense, but I can't see a way to flatten the nested 
lists into a single rule.

The only way I can think of to fix this is to build my own mini state machine 
and parser within the modport_ports_list rule.

Cary R. wrote:
> FYI Steve does not allow us to check in code that has either shift/reduce or reduce/reduce errors.
> The standard way to work around this is to flatten things into a single rule that can then match the text correctly (no shift or reduce just more processing), but that is not always possible. I looked at your example very quickly and it does look complicated. I normally have to spend some time thinking about how bison is working/parsing the text before I figure it out what needs to be done or realize it's not actually possible. I can look at this later when I have some time if you would like.
>
> There are a few things in Verilog that require more than default bison supports (e.g. see br493).
> Cary
>
>
>       On Thursday, January 8, 2015 12:15 PM, Pete Johnson <pe...@be...> wrote:
>
>
>   Martin,
> Shift reduce conflicts are not all that uncommon. You get one with the standard if statement. Think of the following…
> if (test)   if (another_test)     statement;  else     statement;
> When parsing the else statement do you shift the else into the inner if expression or do you reduce the if and let the else go with the outer if. Shift reduce conflicts are resolved by shifting so the else goes with the inner if - regardless of indenting.
> Reduce/reduce conflicts are a problem though. You should never have any of those.
> In your case will you get the correct behavior if the conflict resolves as a shift?
> Here is a link to the bison page on the subject along with how to use a pragma to suppress the warning.
> http://www.gnu.org/software/bison/manual/html_node/Shift_002fReduce.html
> -Pete
>
>
>
> On Jan 8, 2015, at 11:33 AM, Martin Whitaker <mai...@ma...> wrote:
> I'm trying to add support for SystemVerilog modports to the iverilog parser.
> The relevant snippet from parse.y looks like this:
>
> modport_item
>     : IDENTIFIER
>         { pform_start_modport_item(@1, $1); }
>       '(' modport_ports_list ')'
>         { pform_end_modport_item(@1); }
>     ;
>
> modport_ports_list
>     : modport_ports_declaration
>     | modport_ports_list ',' modport_ports_declaration
>     ;
>
> modport_ports_declaration
>     : attribute_list_opt port_direction modport_simple_port_list
>         { pform_add_modport_ports(@2, $1, $2, $3); }
>     | attribute_list_opt import_export modport_tf_port_list
>         { ... }
>     | attribute_list_opt K_clocking IDENTIFIER
>         { ... }
>     ;
>
> modport_simple_port_list
>     : IDENTIFIER
>         { $$ = make_port_list($1, 0); }
>     | '.' IDENTIFIER '(' expression ')'
>         { $$ = make_port_list($2, $4); }
>     | modport_simple_port_list ',' IDENTIFIER
>         { $$ = make_port_list($1, $3, 0); }
>     | modport_simple_port_list ',' '.' IDENTIFIER '(' expression ')'
>         { $$ = make_port_list($1, $4, $6); }
>     ;
>
> which is giving me a shift/reduce conflict. The problem is the parser can't
> distinguish between a ',' that separates items in a modport_simple_port_list
> and one that separates items in a modport_ports_list.
>
> I can't find a way to avoid the conflict with a single level of lookahead. Can
> anyone else?
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming! The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming! The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming! The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net
>
>
>
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>

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

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

Thanks for the reply Pete. The problem here is that ',' may either be a 
separator or terminator for the inner list, and you only know which by looking 
at the next syntax element. So, unlike the dangling else case, you can't 
always resolve the conflict in a fixed way.

Pete Johnson wrote:
> Martin,
>
> Shift reduce conflicts are not all that uncommon. You get one with the standard if statement. Think of the following…
>
> if (test)
>    if (another_test)
>       statement;
>    else
>       statement;
>
> When parsing the else statement do you shift the else into the inner if expression or do you reduce the if and let the else go with the outer if. Shift reduce conflicts are resolved by shifting so the else goes with the inner if - regardless of indenting.
>
> Reduce/reduce conflicts are a problem though. You should never have any of those.
>
> In your case will you get the correct behavior if the conflict resolves as a shift?
>
> Here is a link to the bison page on the subject along with how to use a pragma to suppress the warning.
>
> http://www.gnu.org/software/bison/manual/html_node/Shift_002fReduce.html <http://www.gnu.org/software/bison/manual/html_node/Shift_002fReduce.html>
>
> -Pete
>
>
>
>> On Jan 8, 2015, at 11:33 AM, Martin Whitaker <mai...@ma...> wrote:
>>
>> I'm trying to add support for SystemVerilog modports to the iverilog parser.
>> The relevant snippet from parse.y looks like this:
>>
>> modport_item
>>    : IDENTIFIER
>>        { pform_start_modport_item(@1, $1); }
>>      '(' modport_ports_list ')'
>>        { pform_end_modport_item(@1); }
>>    ;
>>
>> modport_ports_list
>>    : modport_ports_declaration
>>    | modport_ports_list ',' modport_ports_declaration
>>    ;
>>
>> modport_ports_declaration
>>    : attribute_list_opt port_direction modport_simple_port_list
>>        { pform_add_modport_ports(@2, $1, $2, $3); }
>>    | attribute_list_opt import_export modport_tf_port_list
>>        { ... }
>>    | attribute_list_opt K_clocking IDENTIFIER
>>        { ... }
>>    ;
>>
>> modport_simple_port_list
>>    : IDENTIFIER
>>        { $$ = make_port_list($1, 0); }
>>    | '.' IDENTIFIER '(' expression ')'
>>        { $$ = make_port_list($2, $4); }
>>    | modport_simple_port_list ',' IDENTIFIER
>>        { $$ = make_port_list($1, $3, 0); }
>>    | modport_simple_port_list ',' '.' IDENTIFIER '(' expression ')'
>>        { $$ = make_port_list($1, $4, $6); }
>>    ;
>>
>> which is giving me a shift/reduce conflict. The problem is the parser can't
>> distinguish between a ',' that separates items in a modport_simple_port_list
>> and one that separates items in a modport_ports_list.
>>
>> I can't find a way to avoid the conflict with a single level of lookahead. Can
>> anyone else?
>>
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming! The Go Parallel Website,
>> sponsored by Intel and developed in partnership with Slashdot Media, is your
>> hub for all things parallel software development, from weekly thought
>> leadership blogs to news, videos, case studies, tutorials and more. Take a
>> look and join the conversation now. http://goparallel.sourceforge.net
>> _______________________________________________
>> Iverilog-devel mailing list
>> Ive...@li...
>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>
>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming! The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net
>
>
>
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>