10-31-2017 04:51 AM
On my board I am using an Artix-7 in combination with the S25FL127S FLASH. In the flash there are non-volatile bits that indicate a certain latency code which in our case is set to "11". Which in our case (QSPI read back) the clock is allowed to have a maximum frequency of 50 MHz, where the FPGA should requires 2 mode cycles and 1 dummy cycle.
My question is: does the Artix read back these latency code bits from the configuration register (CR1) and act to these bits or does the Artix start configuring according to the way it is told in the constraint file whilst generating the programming file?
10-31-2017 09:01 AM
As all SPI devices differ in features, I cannot see anywhere this is supported (it is not supported ...).
Perhaps in future if this becomes universal (standard) it might appear in new devices. Certainly will never appear in an existing device.
11-01-2017 12:39 AM
Thank you for your quick reply.
I have added a screenshot to this post to show what configuration we are using. When the Artix configures itself it does it with an SPI clock of 66 MHz (+/- 50%) with the LC code at "11". I am not sure why this latency code is "11". Those bits are non-volatile so perhaps during initial JTAG programming, these bits are set. That is something I have to figure out, but for now I still do not understand why my FPGA does configure itself.
Surely the Artix needs to take these dummy cycles in account, or at least has to act to it, when it is configuring itself otherwise configuration should fail. I mean, we are running the flash device out of spec which in my opinion is something that you do not want.
Now when I look at other flash devices, these all require some dummy cycles after sending a read command to the flash. Isn't there a fixed amount of dummy cycles perhaps that the Artix is sending to the flash during configuration?
11-01-2017 06:49 AM - edited 11-01-2017 06:50 AM
I am unaware of any dummy cycles,
Not unusual to be out of specification in a design. The CCLK frequency is programmable, and can be varied by commands in the bitstream. So, often in the past, devices start slower in some modes. I would look at the configuration users guide for such details.
Often such details are overlooked until problems occur in manufacturing (in my experience). Not all engineers are as thorough as you have been...
11-01-2017 11:46 PM
When I look at other flash devices, they all require dummy/latency cycles when you are trying to read from it. It takes some time before the requested data is driven to the outputs of the flash device itself. Since our device is supported by Xilinx I don't really think there is an issue.
Don't get me wrong, the powerup cycles never fail after thoroughly having tested boot cycles but we also want to be able to reprogram the flash ourselfs in the field and we have to be absolutely sure that it doesn't fail due to driving the device out of spec...
Thank you for your support. It's very much appreciated, but I shall look in the configuration user guide once more.
11-03-2017 02:05 AM
You can refer to UG470, page 52 which it mentions during configuration startup the cclk clock frequency is around 3 Mhz, so when fpga sends read command the clock frequency is still at 3Mhz and it will change after the bitstream header is read where it will look for the cclk rate option and set accordingly after which SPI clock-to-data output timing and FPGA DIN setup timing need to be considered for configuration completion.
I have added the snapshot from ug470 which you can refer also the timing diagram shows the read command from fpga and bitstream data transactions.
Let us know if you have additional questions on this
11-08-2017 02:27 AM
Thank you for your reply. I am very aware of the startup process, but when my configuration constraints kick in which in my case is QSPI @ 66 MHz then I wonder how the Artix handles the required constraints for my flash device?
In other words: how does the Artix know how much dummy cycles are required for each flash device? Or is it a standard amount of cycles which is supported by Xilinx, hence the list of supported flash devices which are recommended by Xilinx?
09-05-2018 06:08 AM
Did you hear back from Xilinx? I'm facing a similar issue: I can't seem to find any documentation about the QSPI interface. I'm not sure what the requirements of the Flash chip are, and am having a hard time moving forward with my project.