YosysHQ / icestorm

Project IceStorm - Lattice iCE40 FPGAs Bitstream Documentation (Reverse Engineered)
ISC License
963 stars 224 forks source link

iceblox_vlog does not(?) generate verilog that is compatible with Icarus Verilog #328

Open X-Illuminati opened 2 months ago

X-Illuminati commented 2 months ago

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:

1)

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;
...

2)

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).


[1] https://stackoverflow.com/questions/43765545/verliog-modelsim-error-2388-already-declared-in-this-scope