Instances within generate block

[pistoletpierre]

It seems that generate blocks are ignored in svinst/pysvinst. If you save the SV code as top.sv and the Python code as test.py, then python test.py will prove the concept. There are 16 instances described in top.sv, but only one identified by pysvinst.

// top.sv
module top (
  input logic i_clk,
  output logic [15:0] o_clks
);

  genvar i;
  generate 
    for (i=0; i < 16; i++) begin : generate_test
      my_module my_module_inst (
        .i_clk(i_clk),
        .o_clk(o_clks[i])
      );
    end : generate_test
  endgenerate

endmodule

# test.py
defs = svinst.get_defs("top.sv")
print("len(defs):", len(defs))
print("len(defs[0].insts):", len(defs[0].insts))
print("defs[0].insts[0]:", defs[0].insts[0])
# result:
"""
len(defs): 1
len(defs[0].insts): 1
defs[0].insts[0]: ModInst("my_module", "my_module_inst")
"""

It might be a little tricky to add such functionality but I don't think it would necessitate a full elaboration of the design. All that would be needed is to keep track of elab-time constants (defines/parameters/localparams/literal constants/etc...) in order to interpret a generate block's behavior accordingly. The only two constructs that would steer a generate block that I can think of are if/else (something is either instantiated or it isn't) and for loops (something is instantiated N times).

I haven't looked at the Rust code in svinst so I don't know how difficult it would be to add this functionality, but what's your guess? I'm no Rust aficionado but I'm happy to help if you reckon it ought to be within the scope of this project.

[sgherbst]

Thanks for reporting this! If you wanted to try to add the feature to svinst, you could look into adding a new pattern to the analyze_defs function in svinst/src/main.rs: https://github.com/sgherbst/svinst/blob/432069dd23370db7aa7c7ec57e3b5213b16b1791/src/main.rs#L172 Typically I first run svinst --full-tree myfile.sv so that I can see what the syntax tree looks like, and then try to figure out a pattern to capture it. That said, I think it would be a lot of work because the syntax tree produced by svparser, which is the library underpinning svinst, is very low-level and does not do any abstraction.

For awhile, I have been interested to try adding slang as an alternative backend to do this sort of higher-level processing. If you're interested to explore that route, I think it could open up a lot of possibilities. (It would still be useful to keep the svparser-based option, though, because it has better support of SystemVerilog features that I use for analog/mixed-signal modeling.)

Unfortunately, I don't have bandwidth to look into this issue for the next few weeks. But if you want to work on it in the meantime, I'm happy to keep the discussion going on this thread. Thanks again for the feedback!

[sgherbst]

Sorry for the delay on this. I looked into using slang to do elaboration, and it seems promising. Running slang top.sv --ast-json - produces this JSON output. (here's top.sv)

As you can see, slang elaborates the design, so there are multiple instances of my_module with different values of the parameter i. There is a lot of extra information, too, but I think you could extract just what you need for your application.

If you want to try it out, I've bundled the slang binary with a development version of pysvinst (and will include it in subsequent releases), which you can get like this:

pip install svinst==0.1.7.dev15

In terms of integration with the svinst Python interface, I have already set up get_defs to use slang if you set tool='slang' (the default is 'sv-parser'). You can get a Python dictionary containing the slang output by calling get_syntax_tree with tool='slang' (these features are currently on the slang branch of pysvinst, and will be merged to master soon).

Since I've taken care of setting up the build flow for slang, it should be possible to develop the rest of this feature entirely Python (i.e., no Rust, C++, etc. necessary). Does that still interest you?

[pistoletpierre]

This is great. I'll try stress-testing it with a larger design that uses more SV language features and see what else needs to be added. For the time being, check this out:

// top.sv
module top (
  input logic i_clk,
  output logic [15:0] o_clks
);

  my_module3 my_module3_inst (
    .i_clk(i_clk),
    .o_clk(o_clks[15])
  );

  genvar i;
  generate
    for (i=0; i < 2; i++) begin : generate_test
      my_module my_module_inst (
        .i_clk(i_clk),
        .o_clk(o_clks[i])
      );
    end : generate_test
    for (i=0; i < 2; i++) begin : generate_test2
      my_module2 my_module2_inst (
        .i_clk(i_clk),
        .o_clk(o_clks[i])
      );
    end : generate_test2
  endgenerate

endmodule

module my_module2 (
  input  logic i_clk,
  output logic o_clk
);
endmodule

module my_module3 (
  input  logic i_clk,
  output logic o_clk
);
  my_module my_module_inst (
    .i_clk(i_clk),
    .o_clk(o_clk)
  );
endmodule

module my_module (
  input  logic i_clk,
  output logic o_clk
);

my_module2 my_module2_inst (
  .i_clk(i_clk),
  .o_clk(o_clk)
);

endmodule

#test.py
import svinst
import json

def get_instances(ast_item, parent_hierarchy=""):
    result = []
    if ast_item["kind"] == "Root":
        for i, member in enumerate(ast_item["members"]):
            result += get_instances(member, parent_hierarchy)
    elif ast_item["kind"] == "CompilationUnit":   return result
    elif ast_item["kind"] == "Port":              return result
    elif ast_item["kind"] == "Net":               return result
    elif ast_item["kind"] == "Variable":          return result
    elif ast_item["kind"] == "Genvar":            return result
    elif ast_item["kind"] == "GenerateBlockArray":
        parent_hierarchy += f'.{ast_item["name"]}'
        for i, member in enumerate(ast_item["members"]):
            result += get_instances(member, parent_hierarchy=f'{parent_hierarchy}')
    elif ast_item["kind"] == "GenerateBlock":
        for i, member in enumerate(ast_item["members"]):
            if i == 0:
                if member["kind"] != "Parameter": # Setting a trap in case my assumption of this aspect of the ast dict structure isn't always the case
                    raise Exception(f"First member of GenerateBlock is not a parameter: revisit elif GenerateBlock clause.")
                current_param_val = f'{member["value"]}'
            else:
                result += get_instances(member, parent_hierarchy=f'{parent_hierarchy}[{current_param_val}]')
    elif ast_item["kind"] == "Instance":
        parent_hierarchy = f'{parent_hierarchy}.{ast_item["name"]}'
        result += [parent_hierarchy]
        result += get_instances(ast_item['body'], parent_hierarchy=f'{parent_hierarchy}')
    elif ast_item["kind"] == "InstanceBody":
        for i, body_item in enumerate(ast_item["members"]):
            result += get_instances(body_item, parent_hierarchy=f'{parent_hierarchy}')
    else:
        raise Exception(f"Unknown ast_item kind: {ast_item['kind']}")
    return result

ast = svinst.get_syntax_tree("top.sv", tool='slang')
insts = get_instances(ast)
print(json.dumps(insts, indent=4))

# Output of test.py
[
    ".top",
    ".top.my_module3_inst",
    ".top.my_module3_inst.my_module_inst",
    ".top.my_module3_inst.my_module_inst.my_module2_inst",
    ".top.generate_test[0].my_module_inst",
    ".top.generate_test[0].my_module_inst.my_module2_inst",
    ".top.generate_test[1].my_module_inst",
    ".top.generate_test[1].my_module_inst.my_module2_inst",
    ".top.generate_test2[0].my_module2_inst",
    ".top.generate_test2[1].my_module2_inst"
]

[sgherbst]

Awesome, great job! Feel free to create a pull request for this feature when it is to your liking. I'm happy to help with any integration issues that arise.