rdaly525 / coreir

BSD 3-Clause "New" or "Revised" License
101 stars 24 forks source link

[feature request] adding prefix to coreir/commonlib/... verilog modules #990

Closed leonardt closed 3 years ago

leonardt commented 3 years ago

The desired use case is generating a design where all the relevant verilog modules have a specific prefix (this is used to distinguish the design components from others when integrated in a larger design with blocks from multiple sources). Right now we can use the namespace feature to insert a prefix before user defined modules, but we can't insert this prefix for coreir libraries (e.g. primitives, commonlib). Mechanically this should be easy enough to support in the backend, but how can we expose this as an option to the user? One simple option might be to have some metadata field (e.g. verilog prefix), then at the magma level we could insert these for all the non user namespace modules referenced.

rsetaluri commented 3 years ago

I think the best option is to have an unsafe output_name field on any CoreIR module (maybe instance too), which will override the default CoreIR name generation logic. Throwing a bunch of logic into name generation @ CoreIR level seems complicated and hard to get right. We could do logic at the higher levels (e.g. magma) to make sure that any output_name overrides are safe.

leonardt commented 3 years ago

A seemingly simple option: provide some option for verilog code generation for a prefix that goes before all modules (e.g. coreir --verilog_module_name_prefix=foo). Then, simply do a pass on all the verilogAST modules and insert the prefix. The main benefit here is that this should work for code that includes multiple namespaces (e.g. we may want to have separate namespaces to handle shared names, but at the end of the day we want everything to have a shared prefix for the above use case). This feels simpler than having to do a pass at the magma level to set output_name for all modules. Also, I'm not sure that would work for commonlib muxes for example, since in magma we reference them as instances of generators, to the actual generated module does not have a handle until rungenerators is invoked later on (so we'd need to do this logic at the coreir level not the magma level)

rsetaluri commented 3 years ago

A code-generation/verilogAST specific pass seems fine to me. I was concerned if it was a CoreIR pass/abstraction, it would be clunky but doing that in verilogAST seems reasonable.

rdaly525 commented 3 years ago

The verilogAST pass seems reasonable to me.