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

export as hierarchy (verilog modules) #70

Open
jordens opened this issue Jun 19, 2017 · 6 comments
Open

export as hierarchy (verilog modules) #70

jordens opened this issue Jun 19, 2017 · 6 comments

Comments

@jordens
Copy link
Member

jordens commented Jun 19, 2017

I'd like to be able to translate the migen Module hierarchy into the exported HDL hierarchy at least to some extent.

  • This would allow estimating resource usage at some useful granularity.
  • It would allow easier exporting and re-use of migen gateware in verilog/vhdl projects.
  • This would help with floor planning if one wants to do that.
  • Vivado at least seems to have some options that allow some synthesis to be hierarchy-constrained and therefore potentially scaling better.
  • I don't expect this to be able to map any of the metaprogramming and parametrization in migen to parametrization in verilog. That won't work. I am fine with exporting module parametrizations as separate and fully specialized modules.

Implementation idea:

  • Module would receive a list of ios
  • There would need to be some way to check/enforce/verify the interface, i.e. ensure that module inputs are not also assigned to from within a module and that internal Signals within a module are not accessed from the outside.
  • Some way to substitute a Module by an Instance.
  • build() would export specialized modules.
@whitequark
Copy link
Contributor

i.e. ensure that module inputs are not also assigned to from within a module and that internal Signals within a module are not accessed from the outside.

Right now I see the fact that I can manipulate signals without regard to module boundaries as a major feature of Migen (and I believe it's used in ARTIQ quite a bit, too). Do you suggest blanket prohibiting this, or just when exporting? In any case, splitting the Migen language into two like that seems troublesome...

@jordens
Copy link
Member Author

jordens commented Jun 19, 2017

No. This shouldn't touch existing code style or features at all. It's just an trade-off that one has to accept and deal with when exporting hierarchy. This will only give you the tools to do so.

@mithro
Copy link
Contributor

mithro commented Oct 8, 2017

@jordens Are you actively working on this at the moment or is this something you would just like to see in the future?

@jordens
Copy link
Member Author

jordens commented Oct 8, 2017

I would like to see it and don't have substantial progress.

@phire
Copy link

phire commented Dec 11, 2018

I think this can/should be done without requiring the user to specify a list of ios.

Just automatically infer them from how the module is used.

@whitequark
Copy link
Contributor

Triage: fixed in nMigen.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants