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

Feature request: ability to control arguments to Generators #675

Open
shareefj opened this issue Mar 7, 2024 · 2 comments
Open

Feature request: ability to control arguments to Generators #675

shareefj opened this issue Mar 7, 2024 · 2 comments

Comments

@shareefj
Copy link
Contributor

shareefj commented Mar 7, 2024

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:

CAPI=2:
name: ::example

generate:
  verilog_netlist:
    generator: migen-verilog
    parameters:
      other:
        - stuff
        - here
      params:
        - name: n_channel
          type: int
          value: 2

filesets:
  generators:
    depend:
      - nq:utils:generators

targets:
  default: &default
    filesets:
      - generators
    generate:
      - verilog_netlist

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.

@olofk
Copy link
Owner

olofk commented Mar 7, 2024

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.

@WisniewskiP
Copy link

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.

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

3 participants