Yosys error: Signal `\o_par' with invalid width range -1

[gregdavill]

When Synthesising to an ECP5 the yosys pass fails to parse with this error:

15. Executing Verilog-2005 frontend: /home/greg/projects/DiVA-firmware/hw/serv/rtl/shift_reg.v
Parsing Verilog input from `/home/greg/projects/DiVA-firmware/hw/serv/rtl/shift_reg.v' to AST representation.
Generating RTLIL representation for module `\shift_reg'.
/home/greg/projects/DiVA-firmware/hw/serv/rtl/shift_reg.v:10: ERROR: Signal `\o_par' with invalid width range -1!

I don't know if I want to call this a yosys error. It seems to be doing the right thing, even if these default values are always overwritten with correct values in your design.

Did you see this error when targeting the ice40? or ulx3s?

This can be fixed by providing a default LEN > 0.

diff --git a/rtl/shift_reg.v b/rtl/shift_reg.v
index 64b5ed7..5c4d644 100644
--- a/rtl/shift_reg.v
+++ b/rtl/shift_reg.v
@@ -1,5 +1,5 @@
 module shift_reg
-  #(parameter LEN = 0,
+  #(parameter LEN = 2,
     parameter INIT = 0)
   (
    input wire           clk,

[olofk]

The root problem is the weird Yosys behavior of evaluating modules with the default values of parameters. This prevents using an illegal value to indicate that the parent module must set a valid value. In my experience this is q pretty common design pattern in verilog since (unlike VHDL) you can't omit the default value to indicate that the parent has to set it.

In Edalize I work around this by applying verilog_defaults -push before the read_verilog calls and verilog_defaults -pop. From what I understand there are no drawbacks of doing this but allows illegal default values.

Ideally I would see a change in behavior of yosys since this will continue to pop up, but in this instance I could set a default value. But perhaps the better solution would be to do the verilog_default thing in migen's (which I guess you use) yosys interface to not get into the same issue with other 3rd party verilog designs

[gregdavill]

Thanks for your insight into this. I can see why having values of 0 is useful, and changing this in only one place does seem counter productive, and goes against the other instances.

Yes, LiteX generates a top.ys file that includes all the read_verilog calls. I'll investigate using the verilog_defaults option.

[gregdavill]

The addition of verilog_defaults -push/-pop and verilog_defaults -add -defer has been added to the yosys scripts in Litex for ECP5.

Thanks!