Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issue handling replications in new parser #1205

Closed
veripoolbot opened this issue Sep 11, 2017 · 3 comments
Closed

Issue handling replications in new parser #1205

veripoolbot opened this issue Sep 11, 2017 · 3 comments

Comments

@veripoolbot
Copy link
Collaborator


Author Name: Leon Medpum
Original Redmine Issue: 1205 from https://www.veripool.org


Git version: 5f176d4

We have some verilog that looks like this:

module submod1 (
     input [3:0] net1
);
endmodule

module top ();
     wire neta;

     submod1 submod1
     (.net1 ({neta,
              {3{1'b0}} })
     );
endmodule

When trying to link this verilog, I get the error:

%Error: top1.sv:10: Unexpected length in size of integer constant: "{3{1'b0}}".

I checked IEEE.1364-2005 and this seems to be legal syntax as per section 5.1.14

I can make it work if I convert this to the following, but I don't have the ability to actually modify our netlist.

module submod1 (
     input [3:0] net1
);
endmodule

module top ();
     wire neta;

     submod1 submod1
     (.net1 ({neta,
              3'b0 })
     );
endmodule

It links fine.

@veripoolbot
Copy link
Collaborator Author


Original Redmine Comment
Author Name: Stefan Tauner (@stefanct)
Original Date: 2017-09-12T16:20:45Z


Leon Medpum wrote:

Git version: 5f176d4

We have some verilog that looks like this:
[...]

When trying to link this verilog, I get the error:

%Error: top1.sv:10: Unexpected length in size of integer constant: "{3{1'b0}}".

I checked IEEE.1364-2005 and this seems to be legal syntax as per section 5.1.14

I can make it work if I convert this to the following, but I don't have the ability to actually modify our netlist.
[...]

It links fine.

Yes, replications are not supported with the pinselects option at the moment and I am not planning to implement them within the parser.
The best option I see at the moment is to ignore them and copy them over as is so that it can be handled by user code if need be. The following patch accomplishes that.

@wilson: I have noticed another bug though, specifically when handling nested concatenations. The golden sample in @t/35_sigparser_ps.out:1150@ is most likely not what we want. There the contents of @{someotherbus[2],someotherbus[2]}@ are kinda duplicated. It is returned by the pinselects function as

{'netname' => '{someotherbus[2],someotherbus[2]}'},
{'lsb' => 2,'msb' => 2,'netname' => 'someotherbus'},
{'lsb' => 2,'msb' => 2,'netname' => 'someotherbus'}

Instead of the two individual components only:

{'lsb' => 2,'msb' => 2,'netname' => 'someotherbus'},
{'lsb' => 2,'msb' => 2,'netname' => 'someotherbus'}

I have fixed both issues in the following branch on github: https://github.com/uastw-embsys/Verilog-Perl/compare/replications_concats

KR, Stefan

@veripoolbot
Copy link
Collaborator Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2017-09-12T23:42:55Z


Leon, thanks for the report, and Stefan for the patch.

Pushed to git towards 3.443.

@veripoolbot
Copy link
Collaborator Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2017-09-21T22:49:04Z


Fixed in 3.444.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant