Open shareefj opened 8 months ago
I have thought about that too. Some generators could definitely benefit from being easily parameterized outside of the .core file. There also happens to be some other places that could benefit from the same mechanism as well.
One idea I have had for many years but never gotten around to implement is support for variables in core files. This is kind of an extension of use flags. The idea would be that you could have something like
generate:
verilog_netlist:
generator: migen-verilog
parameters:
other:
- stuff
- here
params:
- name: {{ n_channel }}
type: int
value: 2
and define that with, I don't know, fusesoc run --var n_channel=2 ...
or something like that.
As a side note, did you know that you can specify generator parameters directly in the targets? You can check e.g. here for the syntax.
this feature would be great for our use case too. at this moment I have jinja template for a core and a script that processes it to put parameters in place. then I run fusesoc to build.
I came across a use case today that I hadn't thought about before and is probably particular to our use case. We're using a Generator to convert Migen modules to Verilog and then add them as dependencies. I have a simple Python generator that takes, among other things, a list of parameters to use in the Migen instantiation.
So for example, imagine you have a configurable Migen module that takes
n_channel
as an instantiation argument. This is passed to the generator via a core file that looks like:What we'd like to do is enable parameterisation of these arguments from the command line and I started looking at how I could use FuseSoC parameters to do this. I ended up modifying FuseSoC to pass the parameters defined in the core file down to the generator (by modifying arguments passed to Ttptttg and paths in between), and then realised after all of that that the overriding of parameters on the command line only get passed to the Edalize backend and aren't available inside of FuseSoC.
At least that was my understanding after a quick hack.
So is that correct and if so, can you think of any other way of overriding inputs to generators?
Addendum: In my example, I ended up creating a new parameter type that was named
param
(not at all confusing) and inside my generator, I was passing in all core file parameters and extracting the matching one. But it was getting the default value rather than the command line overridden one.