-
Notifications
You must be signed in to change notification settings - Fork 234
Description
When trying the blinky example from nextpnr, I encounter the following error:
icebox_vlog blinky.asc > blinky_chip.v
iverilog -o blinky_tb blinky_chip.v blinky_tb.v
blinky_chip.v:5: error: 'io_0_8_1' has already been declared in this scope.
blinky_chip.v:3: : It was declared here as a net.
blinky_chip.v:505: error: 'io_13_9_1' has already been declared in this scope.
blinky_chip.v:3: : It was declared here as a net.
blinky_chip.v:553: error: 'io_13_11_0' has already been declared in this scope.
blinky_chip.v:3: : It was declared here as a net.
blinky_chip.v:567: error: 'io_13_12_1' has already been declared in this scope.
blinky_chip.v:3: : It was declared here as a net.
blinky_chip.v:598: error: 'io_13_11_1' has already been declared in this scope.
blinky_chip.v:3: : It was declared here as a net.
blinky_chip.v:612: error: 'io_13_12_0' has already been declared in this scope.
blinky_chip.v:3: : It was declared here as a net.
I'm far from an expert on Verilog, but it seems this is due to a mixture of old and new style declarations[1]:
module chip (input io_0_8_1, output io_13_9_1, output io_13_11_0, output io_13_12_1, output io_13_11_1, output io_13_12_0);
wire io_0_8_1;
...If the keyword wire is to be used in the body of the module, it should not be declared as an input or output in the module prototype. Vice-versa, if the new input/output keywords are to be used in the module prototype, the signal should not be re-declared in the module body.
Either of these two options works with iverilog:
module chip (input wire io_0_8_1, output wire io_13_9_1, output wire io_13_11_0, output reg io_13_12_1=0, output wire io_13_11_1, output wire io_13_12_0);
//wire io_0_8_1;
...module chip (io_0_8_1, io_13_9_1, io_13_11_0, io_13_12_1, io_13_11_1, io_13_12_0);
input wire io_0_8_1;
...I presume that the first is the preferred form, but the second may be better for backwards compatibility with other tools that only implement Verilog-1995.
It is possible that, in the past, iverilog was more tolerant of this.
I am currently running iverilog v12.0 stable (the packaged version for Ubuntu 23.10).