-
Notifications
You must be signed in to change notification settings - Fork 5
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
Instances within generate block #5
Comments
Thanks for reporting this! If you wanted to try to add the feature to 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 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! |
Sorry for the delay on this. I looked into using As you can see, If you want to try it out, I've bundled the
In terms of integration with the Since I've taken care of setting up the build flow for |
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"
] |
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. |
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.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.The text was updated successfully, but these errors were encountered: