rdaly525 / linker

Repo for the coreir linker paper
0 stars 0 forks source link

Magma is main, verilog is linked #6

Open rdaly525 opened 6 years ago

rdaly525 commented 6 years ago

I think if we got this example fleshed out with a parameterized verilog module, most other examples could be straightforward.

Lenny, could you provide an example of how this is currently done in Magma?

Proposed path (ROSS TODO) I think there should be a non-magma/python specific way to get the declarations of the verilog modules as a function of the parameters. What this means is that I should be able to pass in some collateral into yosys which is basically a list of modules with parameter arguments. Yosys should then be able to output the materialized module declarations. This is equivalent to 'running the typegen'.

Separately, magma should be able to compile to coreir, and then coreir linker will pass yosys the unresolved parameters and yosys should be able to 'run the generators' for the unresolved symbols. The Linker will then be able to merge all the resolved symbols back into coreir for a final compiled coreir circuit.

leonardt commented 6 years ago

Can you clarify what you want an example of? If you mean an example of using a templated verilog file, see the second cell in this notebook: https://github.com/phanrahan/magma/blob/master/notebooks/tutorial/Verilog.ipynb

We could add a similar interface which is DeclareFromCoreIRVerilogGenerator('generator_name', **params) which returns a magma circuit declaration with the matching ports/types. Then this could be compiled to CoreIR just in terms of the declaration which I think should just work.

The DeclareFromCoreIRVerilogGenerator could pass the generator reference and parameters to a coreir tool to get the coreir declaration for the generated module, which we could then parse using pycoreir to generate a magma declaration.

rdaly525 commented 6 years ago

Yeah, that was what I meant.

Since ideally magma does not need to know that library was from verilog, maybe something more generic like "DeclareFromExtern" or something along those lines. Ideally you just have to write one import function that will work independent of what langauge the libraries were written in.

leonardt commented 6 years ago

Yea that makes sense, I like the notion of an extern. The most explicit/verbose name would be DeclareFromExternGenerator, can brainstorm with a more concise name but I'll go with that for now.