Renaming modules programatically

[iamkarthikbk]

I have a module hierarchy and I want to generate verilog with a postfix to the module names. is there a way to do this at compile time ?

Example:

(*synthesize*)
module mk_abc(Empty);

Say I compile this 3 times, I want the generated verilog to be mk_abc_1, mk_abc_2, mk_abc_3. Can I somehow specify what the post-fix should be ? Is there a way to do this at compile time ? Or what is the best way to get this done?

Note: these modules (and their sub-modules) use ifdefs. The values for these compile-time macros (ifdefs) can change every time I compile. that is, mk_abc_1, mk_abc_2, and mk_abc_3 can use three completely different set of values for the macros, but the names of the macros remain the same (they're the same module).

Thanks in advance.

[quark17]

The approach I've seen is to avoid using macros and pass the parameters as type or value arguments:

// Generic module
module mk_abc
  #(parameter Integer depth)
  (Ifc#(addr_width,data_width));
  ...
endmodule

// Synthesized instances
// with the parameter values in the name
(* synthesize *)
module mk_abc_2_8_16 (Ifc#(8,16));
  (* hide *)
  let _m <- mk_abc(2);
  return _m;
endmodule

If you must use macros, then I'm not aware of any options besides post-processing the Verilog. You can run your own scripts on the generated files, or BSC has a flag -verilog-filter for specifying a command that BSC will run on the generated Verilog for you. If your module name is distinct, a simple search and replace of the name might work; otherwise, the script could look for module declaration (to rename module declarations) and look for instantiations (if you need to rename submodule instantiations) -- I believe that submodule instantiations are preceded by a comment, so it may be simple to just look for the comment and not have to parse Verilog in general.

If you have a suggestion of a new feature that would help, you can suggest it. In theory, BSC could support a flag for specifying a prefix to add to generated module names, but I'd have to think about whether that's what we want to support or if there's a cleaner alternative. We'd also need to consider how it would interact with Bluetcl and BDW, where users might want to correlate generated module names in the design hierarchy in .ba files (and the Verilog) with definitions in the source files that have the non-prefixed names.

[iamkarthikbk]

post-processing the verilog occured to me, but what happens to functions/modules that were inlined and the compiler had already consumed the macros ?

Yes, passing the params as interface arguement seems best. I'm just trying to find a way in which I can get this done without having to rewrite most of my codebase.

[quark17]

I don't understand your concern about consumed macros. It sounded like you had a module like the following very simple example:

(* synthesize *)
module mk_abc (...);
   ...
   Reg#(Bit#(16)) rg <- mkReg( `INIT_VALUE );
   ...
endmodule

And you can compile it by providing a specific value for the macro:

bsc  -verilog  -D INIT_VALUE=1  ABC.bsv

This would generate a Verilog file mk_abc.v, containing a module that had 1 as the initial value for the register.

But you want to generate three different versions of this module:

bsc  -verilog  -D INIT_VALUE=1  ABC.bsv
bsc  -verilog  -D INIT_VALUE=2  ABC.bsv
bsc  -verilog  -D INIT_VALUE=3  ABC.bsv

but each time it will overwrite the existing mk_abc.v. What you want is a way to tell BSC to generate the module with a different name each time, generating the files mk_abc_1.v, mk_abc_2.v, and mk_abc_3.v. Each file contains a module that hardcodes a specific initial value (as indicated by the suffix in the name).

BSC does not support this, but you can use a script to rename the file and to edit the contents to change the module name:

bsc  -verilog  -D INIT_VALUE=1  ABC.bsv
change_modname.py  mk_abc  mk_abc_1

bsc  -verilog  -D INIT_VALUE=2  ABC.bsv
change_modname.py  mk_abc  mk_abc_2

bsc  -verilog  -D INIT_VALUE=3  ABC.bsv
change_modname.py  mk_abc  mk_abc_3

Each time you run BSC, it will generate a module that has consumed the macros, and the post-processing just renames the module and the file. If that is not the feature that you're asking for, please correct me.