toplevel parameters

[sjoerdtimmer]

The toplevel should be parameterized.

Currently, parameters defined through @MAIN.PARAM are added to main.v but not to toplevel.v

The usecase for this is inputs/outputs that have a parameterized width. These widths should propagate all the way up to the top.
This should happen for both localparams and parameters since the width could be calculated in a localparam.

A distinction could be made between localparams and parameters, since localparams cannot be overridden. They simply need to be copied to both toplevel.v and main.v. (Non-local) parameters should also be added to both toplevel.v and main.v but they should also be passed into the instantiation of main. The cleanest way to do that is probably through a `defparam assignment rather than composing the #() overrides in the instantiation line.

If parameter name extraction is undesireable, then -as an alternative- the @MAIN.PARAM section could be split in two sections: one for parameter and localparam declarations (which should operate like MAIN.IODECL does at this time), and one that is inserted in the #() clause of the main instantiation (similar to how PORTLIST is used, so you could call it e.g. PARAMLIST).

A workaround for this is to define a parameter in the @MAIN.IODECL which is replicated in the toplevel.v. However, the parameters are not passed to the main "thedesign" module but rather reinitialized to the same defaults. (This would cause errors if toplevel is not the top unit in the design but part of a larger project and then instantiated with a different parameter value.)

[ZipCPU]

Thank you!

While defparam may be the "cleanest" way, it is not a viable option. SV 2012 suggests deprecating defparam support, and many newer tools don't support it at all.

I'm currently leaning towards the approach of doing the same thing at the top level that I'm already doing for MAIN.IODECL and MAIN.PORTLIST: If these are TOP.IODECL and/or TOP.PORTLIST are undefined, they are just copied from their MAIN counterparts. This matches the use case where main is the top level simulatable model (in Verilator), and non-simulatable constructs are kept in the toplevel. In that case, you don't really want an option for the parameters to be overridden in main by the top level.

The "clean" way to do it, which would be to pass any top level parameters to main, would require a bit more knowledge of the Verilog language in the parser. While possible and doable, it's a bit more of a challenge.

Dan