Invalid bitstream is generated which does nothing, all pins tristated

[hansfbaier]

Suddenly I was not able to generate a working bitstream anymore, for a unknown reasons. On one day rerunning the toolchain fixed it, but today, I was not able to generate one working bitstream with many runs.

[hansfbaier]

$ shasum xc7k325tffg*
49721eca58b0bba8704467aeef1fd647ed1f6d2d  xc7k325tffg676-1.bba
641c69e90f06b4df67ba3be68a5effafca7ee7c2  xc7k325tffg676-1.bin
$ shasum picosoc.*
f50b84e7a5832a8543625cfb65f3610b46f55f9d  picosoc.bit
f95a94a515cd11b1aaecbdbd5d1070629a619d4d  picosoc.fasm
da39a3ee5e6b4b0d3255bfef95601890afd80709  picosoc.frames
7010c3b80abb013b694b816755de696b16b67fc1  picosoc.json

[jrrk2]

Have you regenerated your .bin file since nextpnr was compiled (or any shared library was updated) this can affect the operation of mmap()

[hansfbaier]

Yes I have tried that too, didn't work. I'll try again

[jrrk2]

The next thing is to use fasm2bels to load the project into Vivado for DRC checking.

[hansfbaier]

@jrrk2 I am out of luck here, because I don't have a license for the 325T.

[jrrk2]

If you send me your results from fasm2bels I can load it into Vivado and let you know the DRC results

[hansfbaier]

@jrrk2 It's a Heisenbug! It doesn't want to be investigated by you. But I suppose the flashing seems to be somewhat unreliable. I built the database again, both .bba and .bin. Then flashed first, using openocd. Everything dark, LEDs not even tristated. Then turned the board off, turned on again, then flashed using openFPGALoader, then it worked :-] I attached the working file for @kdunn926, please try that one. picosoc.zip

[jrrk2]

Perhaps your JTAG clock rate on openocd is too high for reliable operation.

[hansfbaier]

Actually the working/not working .fasm files are identical: sha256sum working/picosoc.fasm notworking/picosoc.fasm

$ sha256sum working/* notworking/*
6795e531276830ed5a3c33db2b049ee2210c67aa2560b00a69cf57017297d9e3  working/picosoc.bit
91023edf6c8624a92db552328eb464ed10beae5bea4950f50c8bdccdc5f93696  working/picosoc.fasm
191210672ff10e307d322e4e270b9c570ddc4153b718684eb6d15f3fecc83e60  working/picosoc.frames
34e2be520cb3bf527359954c6df69ce38a6d9c270faeab146a409fd302d7b3e5  notworking/picosoc.bit
91023edf6c8624a92db552328eb464ed10beae5bea4950f50c8bdccdc5f93696  notworking/picosoc.fasm
191210672ff10e307d322e4e270b9c570ddc4153b718684eb6d15f3fecc83e60  notworking/picosoc.frames

Interestingly enough, the bitstreams are different.

[hansfbaier]

@jrrk2

That's what I thought too, and ran it with 1/10 the clock rate. Still the same result. Also the blinky worked with the same setup.

[jrrk2]

I think the bitstream has a header that is discarded with some sort of header that can vary.

[hansfbaier]

00000000   00 09 0F F0  0F F0 0F F0  0F F0 00 00  01 61 00 27  70 69 63 6F  73 6F 63 2E  66 72 61 6D  65 73 3B 47  65 6E 65 72  61 74 6F 72  3D 78 63 37  66 72 61 6D  65 73 32 62  69 74 00 62  .............a.'picosoc.frames;Generator=xc7frames2bit.b
00000038   00 11 78 63  37 6B 33 32  35 74 66 66  67 36 37 36  2D 31 00 63  00 0B 32 30  32 32 2F 30  32 2F 31 31  00 64 00 09  31 31 3A 32  38 3A 30 37  00 65 00 AE  9D 9C FF FF  FF FF FF FF  ..xc7k325tffg676-1.c..2022/02/11.d..11:28:07.e..........

Yes the build time is in the header. That explains it. I wasted hours on this today, sigh... But all is well that ends well. Thanks Jonathan!

[hansfbaier]

@kdunn926 It seems to be the order in which I plug in the devices. If I

1. plug in the USB2UART
2. turn on the Kintex board power
3. plug in the FT2232

then it seems to work. I tried again, and it seems to work, reproducibly so. If I don't plug in the USB2UART, it won't work. Strange.

[hansfbaier]

Closing this ticket as invalid. Had nothing to do with bitstream generation.