Open chaufe opened 1 year ago
My take on this is that it is quite useful (and common) to have illegal default values in cases that don't really have a sensible default, since Verilog requires a default value as opposed to VHDL where leaving a generic unassigned is a sign that the user needs to set this.
I don't agree with Yosys default behaviours here, but I also know it won't be fixed. (I filed a bug report about this about seven years ago). However, there is a way around this by setting verilog_defaults -add -defer
. Edalize does this for all yosys backends and SiliconCompiler does something similar too. OpenLANE doesn't unfortunately and I haven't found a sensible way to add your own tcl hooks to the process.
So, ideally, I would have this fixed in either Yosys or OpenLANE, but I don't really expect anything to happen there so until there is a proper Edalize backend for this flow that can replace OpenLANE, I think the most realistic approach is to add a valid default value as you propose.
(I still don't like it though! 😠)
Yosys reports a warning on a out-of-bound range select in serv_rf_ram.v.
Openlane checkes for that warning and converts it into an error.
(Other synthesis solutions also error out on this out-of-bound range select.)
The error is caused by the parameter "width" that defaults to "0", thereby creating a div-by-zero when computing the default parameter "depth", as well as creating the mentioned out-of-bound range select.
A simple fix would be changing the default of "width" to "2".
\cc @dhaentz1