I’ve been using Vivado to generate the bin/bitstream file, and it seems like it only works if I use serial mode (set_property BITSTREAM.CONFIG.SPI_BUSWIDTH 1). I’ve tried using quad mode by setting this value to 4, but the device would never boot.
Is there a hardware reason why quad mode doesn’t work? Or any other config bitstream constraint needed to get it to work?
I posted some crud about suffering with this on the Digilent forum for a little Cmod A7 board. Maybe there are some secrets that you can use. My second post on the thread has the secret.
Unfortunately I did try those 3 constraint settings but my Alchitry Au+ did not seem to boot.
I don’t think it is possible to get it to boot in QSPI mode with the current flash chip. The chip requires you to enable quad mode first by sending the command EQIO (0x38). I don’t think you can get the FPGA to do that on its own.
This flash chip was chosen as it was the only one I could find that has a really fast erase time. Most are around 10-60 seconds but this one is 50ms. This makes a pretty big difference when writing a new config to it and QSPI is used to do the write as well.
You can shorten the boot time by setting
set_property BITSTREAM.CONFIG.CONFIGRATE 66 [current_design]
set_property BITSTREAM.CONFIG.SPI_BUSWIDTH 2 [current_design]
For reference, here’s what Alchitry Labs currently adds to the constraint file.
set_property BITSTREAM.GENERAL.COMPRESS TRUE [current_design]
set_property BITSTREAM.CONFIG.CONFIGRATE 66 [current_design]
set_property CONFIG_VOLTAGE 3.3 [current_design]
set_property CFGBVS VCCO [current_design]
set_property BITSTREAM.CONFIG.SPI_32BIT_ADDR NO [current_design]
set_property BITSTREAM.CONFIG.SPI_BUSWIDTH 2 [current_design]
set_property BITSTREAM.CONFIG.SPI_FALL_EDGE YES [current_design]
I just changed this to use 2x and 66MHz.
EDIT: I only just now realized there’s a version of the flash chip that boots with QSPI enabled…
I just bought a full reel of the SST26VF032BT-104I/MF but I’m going to see if I can return them and switch to the SST26VF032BAT-104I/MF to enable QSPI loading on the V2 boards.
I just got a few “A” versions to try out and slapped one on a prototype Au V2. Can confirm SPI_BUSWIDTH = 4 now works as expected.
I’m planning to make this the default for the Au and Pt. The Cu can use the non-A versions I already bought as it doesn’t even connect to the other two pins anyways.
will be possible to use SPI_BUSWIDTH = 1 with “A” version of FLASH? I ask due to compatibility to not need have two xdc files for v2 and v1.
I wonder if the “A” version is detected by Vivado?
The “non-A” is not detected by the Vivado’s built-in SPI Flash bridge for programming.
You can use a bus width of 1, 2, or 4. It’s not only QSPI but the QSPI commands are allowed at boot without extra configuration.
It still won’t be detected by Vivado as they check ID codes against only a few chips. Even though it’s probably otherwise identical to program it’ll still not work.
I managed to add our chip to the list (including the chip ID), but when I tried to program it, the logs seems to indicate that the bridge used by Vivado didn’t got any answer from the chip (received ID Code was 0).
So, so far it looks like it’s not that the ID code is rejected, it’s that it can’t communicate with the chip.
It’s turning out to be a bit of a challenge to find the A version at a good price.
I’d love to hear from people what features are a priority between QSPI loading, Vivado compatibility, programming speed, and price (say $5).
I think compatibility with Vivado could be a big plus because the tools provided by Vivado become more and more useful as the design gets complex.
Especially the debugging tools (simulations and ILA) and the block design that comes pretty handy to wire modules together easily.
About the ability to program the flash directly from Vivado, it’s not that hard to use the Alchitry programmer, but I still think that professionals and Vivado-only users would appreciate a fully integrated experience, which could mean more possible customers for the boards which in turn may bring more interest into Lucid 
About the programming speed and configuration time, my designs are too small yet so with compression active, I have a few seconds programming time and almost instant configuration time.
If I disable compression, it’s much longer (10+ seconds programming and a few seconds configuration), but I don’t know if this is reflecting a real use-case.
Every other flash chip I’ve seen has an erase time of 10-90 seconds. This would add on top of whatever time it takes now. The current chip’s erase time is nearly instant. Some optimization could be done to just erase the parts you’re loading to but this wouldn’t save time for bigger files.
Vivado compatibility over JTAG will be there regardless. This was merely being able to program the flash via their hardware manager. A quick look into the chips supported and they’re all quite slow (~30-50s erase times).
I’m currently leaning on just going with the A version and hoping I can get a better source in the future.