dylcobfp

Hi @JColvin, thank you again for the indepth reply
After further investigation we have come to the conclusion that this is not a hardware problem, but rather attributed to the fact that we were placing the mode bits of the flash into continuous Quad IO Read mode to save having to write out the instruction. This caused confusion in the part when the PROG_B went low and the reset sequence began, since the FPGA was expecting the bitstream but the flash was expecting a Quad IO Read
We have since resolved the problem and confirmed that it works as expected
Thank you

Hi @dylcobfp,
I believe I responded to you earlier, but my understanding is that the pins not listed on the schematic are not connected to the FPGA as they are either Reserved for Future Use or Do Not Use pins as designated by the manufacturer's datasheet in section 6 (https://www.infineon.com/dgdl/Infineon-S25FL128S_S25FL256S_128_Mb_(16_MB)_256_Mb_(32_MB)_3.0V_SPI_Flash_Memory-DataSheet-v18_00-EN.pdf?fileId=8ac78c8c7d0d8da4017d0ecfb6a64a17; if your board instead has the 127S part loaded that datasheet is available here: https://www.mouser.com/datasheet/2/100/001_98282_S25FL127S_128_MBIT_16_MBYTE_3_0_V_SPI_FL-1299705.pdf). I've attached a picture coloring in the the connected traces that I am able to see on the flash part, which indeed is just the 8 connected pins (2 in each corner of the IC).
Some differences between the two parts as they are not functionally equivalent are explained a bit in our Product Change Notice available on the Arty S7 Resource Center: https://digilent.com/reference/programmable-logic/arty-s7/start#documentation.
Unfortunately, I do not know if the pin 3 on the flash chip is set to RESET# or RFU; I looked through the datasheet, but as far as I could tell did not find anything detailing a list of which models use which configuration. Though at least based on the description in the datasheet, the pin itself is either connected to RESET# internally, or is left unconnected externally and is only connected to VCC internally, so in theory you could always test your idea and it at least "should" not harm the flash chip, but I would recommend checking the connections with a multimeter first to see if the RESET pin is electrically connected to Vcc from an external standpoint or not.
Based on your description of needing two pulses on the RESET line on your part, that seems to be in line with the Hardware (Warm) Reset (section 5.3.2) description in the datasheet where if the POR process didn't complete properly, reset going low will initiate the full POR process rather than the hardware reset process. I am uncertain if that is what you are experiencing though.
I'm not certain about your setup to your computer, but something else that could be happening is that Xilinx's Vivado Hardware Manager is maintaining a connection to the FPGA in such a way that when you program the flash chip, it does not properly reset the board and boot from flash until you fully disconnect the device from the Xilinx software (either by closing out the hardware server connection or disconnecting the USB cable connection); again this might not be the problem, but is something that Digilent experiences with flash programming on our boards.
Thanks,
JColvin