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

Verilog Perl Netlist reader generate statements #857

Closed
veripoolbot opened this issue Dec 9, 2014 · 2 comments
Closed

Verilog Perl Netlist reader generate statements #857

veripoolbot opened this issue Dec 9, 2014 · 2 comments
Labels
wontfix This will not be worked on

Comments

@veripoolbot
Copy link
Collaborator


Author Name: Chris Hopkins
Original Redmine Issue: 857 from https://www.veripool.org
Original Date: 2014-12-09


It seems that although it is able to read generate statements it does not represent the generated hierarchy correctly. When it is a generate for on a module instantiation then a single module instance is generated
Using the example code from:
http://search.cpan.org/~wsnyder/Verilog-Perl-3.406/Netlist.pm

The following Verilog(snipped from a module that just instantiates this):

genvar i;
generate for (i=0; i<4; i++) begin : gen_block
test_sub test_sub_x (
  .clk          (clk        ),
  .rst_n        (rst_n      ),
                             
  .data_in      (data_mid   ),
  .data_out     (data_out[i*2+:2]),
                             
  .data_valid   (data_valid),
  .data_enable  (data_enable_1[i])
);
end
endgenerate

generates the following output:
  Module test                                 test
        input clk
        output data_enable
        input data_in
        output data_out
        input data_valid
        input rst_n
       Cell test_sub_x
        .clk(clk)
        .data_enable(data_enable_1[i])
        .data_in(data_mid)
        .data_out(data_out[i*2+:2])
        .data_valid(data_valid)
        .rst_n(rst_n)
     Module test_sub                           test.test_sub_x
          input clk
          output data_enable
          input data_in
          output data_out
          input data_valid
          input rst_n
         Cell test_sub_sub_0
          .inny(rst_n)
          .outy(rst_n_buf)
       Module test_sub_sub                     test.test_sub_x.test_sub_sub_0
            input inny
            output outy
       Cell u_test_sub
        .clk(clk)
        .data_enable(data_enable_0)
        .data_in(data_in)
        .data_out(data_mid)
        .data_valid(data_valid)
        .rst_n(rst_n)

When in fact this should generate either 4 cells each with a single submodule or a single cell with multiple submodules under it.

@veripoolbot
Copy link
Collaborator Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2014-12-09T14:22:21Z


Verilog-perl does not do elaboration, which would be what's needed to expand the for loop. See http://www.veripool.org/projects/verilog-perl/wiki/Manual-verilog-perl#Verilog_Perl__which_parser_package

You could argue that the non-elaborated cell should have gen_block in its name, as that is the proper scope for that cell. I doubt that is what you are looking for, but if it is please reopen the bug and I'll accept a patch with an enable flag that does that.

@veripoolbot
Copy link
Collaborator Author


Original Redmine Comment
Author Name: Chris Hopkins
Original Date: 2014-12-09T14:32:01Z


So the reason to use netlist is that I have been trying to use it as a tool to process connectivity. (Actually I've used Netlist for a long time so what the one I was most familiar with too) That is based on hierarchical path I scan through for a net object then I can scan through the hierarchy and work out everything that net(s) is connected to.
It seems to work well except for concatenates, bit selects and this issue. I can work around the others but not this. Time to learn verilator I guess.
Thanks

@veripoolbot veripoolbot added the wontfix This will not be worked on label Mar 14, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
wontfix This will not be worked on
Projects
None yet
Development

No branches or pull requests

1 participant