Tang Nano 9K CRC error with -b tangnano9k

[stacksmith]

Flashing a Tang Nano 9K board with a yosys/nextpnr-himbaechel/gowin-pack:

Fails with a CRC error when specifying the board with a -b tangnano9k;

Succeeds with -c ft2232

I've localized the issue to openFPGALoader with yosys guys, see yosys issue 262

[trabucayre]

This looks weird. A board definition is for board based on gowin's FPGA only a different way to specificy the cable (here an ft2232). So using -b or -c do exactly the same thing. I have to look at these issues

[stacksmith]

That is truly odd!

[stacksmith]

Apologies, I was wrong. I think I accidentally did a git reset --hard and reloaded the bitstream in the repo, which always works -- as opposed to the one generated by yosys. At this point I think openFPGALoader has nothing to do with this, and the problem is somewhere in the yosys domain.

[trabucayre]

I have to check both, because openFPGALoader the checksum used to check is computed by openFPGALoader. I don't remember exactly if the one read is computed by the FPGA itself or come from the bitstream. And 9k variant is a bit specific because one line is larger than one FPGA's row and a padding is added, so the checksum is a bit more borring to compute

[trabucayre]

Maybe a regression with https://github.com/YosysHQ/apicula/commit/31dbe9939103d8122652ca695a338affa019775b ?

[stacksmith]

I am using openFPGALoader v0.12.1, by the way. Is that current?

[trabucayre]

Since this release nothing has changed for gowin's FPGA

[stacksmith]

It appears that something changed between v0.11.0 and v0.12.1 and makes the bitstream generated by a current yosys not flashable.

[trabucayre]

gowin's driver has received lot of modification during this period (with some regressions), so it's possible yes. Problem is to find which modification cause this issue. I have build a bitstream using gowin's tools: the line starting with 0x0A, and CRC computed by fsParser, matches. With apicula this is not true. I think there is two problem here (one for apicula and one for openFPGALoader).

[stacksmith]

Yes, it appears that some earlier combination of apycula and openFPGALoader worked, and some changes made after that are making it not work.

However, I have a bitstream that will trigger CRC errors in v0.12.1, which works fine (according to @yrabbit, and I will try to verify myself) with v0.11.0.

If that is a fact, something in openFPGALoader is currently a problem.

A less likely alternative is that current openFPGALoader is correct and yosys is not, but previous versions of both openFPGALoader and yosys were buggy in a way that made them work correctly. Because an old bitstream flashes with an old openFPGALoader!

[stacksmith]

OK, my assumptions were incorrect, as @yrabbit was configuring via sram and not flashing. That works with v0.12.1.

Flashing does not work.

[trabucayre]

This issue was related to apicula's crc computation and it now fixed by commit https://github.com/YosysHQ/apicula/commit/57fa1072dbd8013907a814606cceca1a847fd5c4. We can now close this issue.

[stacksmith]

Thank you