blinky example modified for "lp384" and "qn32" results in iverilog error: 'io_2_9_0' has already been declared in this scope

[ericfont]

blinky.sh runs fine when run on a fresh git checkout of master for "hx1k" & "tq144". However, the chip I have is 32-Pin QFN LP384, and so I tried to modify by changing those strings to "lp384" and "qn32" as (like YosysHQ/nextpnr@e5b4402) and changed the pins (like Image). I must be doing something simple wrong, but runing blinky.sh now results in an error at the last step when running iverilog:

blinky_chip.v:27: error: 'io_2_9_0' has already been declared in this scope.

(see log: blinky_terminal_output.txt and blinky_chip.v.txt which has on line 3:

module chip (input io_0_4_1, output io_2_9_0, output io_2_9_1, output io_5_9_0, output io_7_6_1, output io_6_9_0);

and on line 27:

reg io_2_9_0 = 0;

Probably something very simple I'm doing wrong. This error looks similar to #328

[KrystalDelusion]

iverilog is correct and that is invalid verilog. You're declaring the same signal first as an output and then as a reg. Inputs/outputs can take a type so what you want is output reg, and then if you need to assign an initial value use an always block. Looking at #328 this is probably the same underlying issue with how the code gets generated.

Can you share the changes you made for pin assignments?

[ericfont]

I shared the changes when I wrote "(like YosysHQ/nextpnr@e5b4402)" but here is a picture of that diff:

[ericfont]

For determining what pins to use, I downloaded https://www.latticesemi.com/view_document?document_id=49391 and looked at the "(SG32) 32-Pin QFN Ball Number" column, and for the LEDs picked PIO or DPIO pins starting from the bottom and going up (i.e. Ball Numbers 31, 32, 27, 26, 23 for leds 1 to 5), and for the clki picked the a GBIN pin (IOL_5A_GBIN6 aka Ball Number "8"), and put those Ball Numbers into blinky.pcf

[KrystalDelusion]

Oh, sorry I didn't realise that the linked commit was the code you were using. It looks like 68044cc fixed output wires (and potentially should have closed #328), but it doesn't address output registers. Looks like icebox_vlog.py is the source of the issue though.

[ericfont]

OK, well I guess the Yosys team has enough info from that diff I provided to reproduce the issue, so I'll let your team figure out how to fix it.

For the record I'm using the lastest nextpnr-git 0.7.r180.g0c458f1-1 autobuilt by Arch Linux Chaotic AUR and the latest icestrom-git r844.7fbf8c0-1, which should already have 68044cc

I also have an iCE40-HX1K-VQ100 chip (on a iCE40HX1K-EVB which uses this schematic) and just now tested reassigning blinky pins according to the blinky column in this spreadsheet iCE40PinoutHX1K.ods and according to this diff ericfont/nextpnr@5c374a7, which produces this blinky_chip.v blinky_chip.v.txt, but unfortunately, I get the same type of error (see log blinky_terminal_output_iCE40HX1K-EVB.txt) during the iverilog step:

blinky_chip.v:550: error: 'io_9_0_1' has already been declared in this scope. blinky_chip.v:3: : It was declared here as a net.

If there are any workarounds for when I wait for a fix to be added to the git (other than trying the proprietary iCE tools or ordering an iCEStick), or any ways I can help test, let me know.

[KrystalDelusion]

I don't think the generated vlog is actually needed for programming the board, so if the problem is just in the generated vlog, you should be able to call iceprog blinky.bin just fine.

[ericfont]

Yup...got blinky running on the Olimex iCE40HX1K-EVB!

Note for any random internet readers, that Olimex board doesn't have a flash programmer built in, but I programed it through a small cheap CJMCU FT232H USB-to-SPI bridge connected to the Olimex like https://gist.github.com/ericfont/1ed01a36e03a865dd15e567edb4c6c47 and while I couldn't quite get iceprog working I was able to use truncate -s 2M blinky.bin to first expand out the image size to the Olimex board's flash size and then run flashrom -p ft2232_spi:type=232H -w blinky.bin.