07-06-2019 09:46 AM
I have a Kintex UltraScale 095 FPGA hardware design which is set up to configure using quad SPI Flash interface. I'm using the STARTUPE3 primitive to gain access to the QSPI pins after configuration is complete. I'm using custom logic to interface to the Flash via the STARTUPE3 primitive rather than the AXI to Quad SPI IP. The problem is, I'm using the end of startup (EOS) signal to determine when configuration of the device is complete, but the EOS signal seems to be behaving incorrectly.
According to UG570 UltraScale Configuration, EOS indicates the absolute end of configuration and start-up of the FPGA. Figure 9-13 on pg. 154 of UG570 shows EOS being asserted at the very end of configuration and start-up. I've brought the EOS signal out to a circuit trace and measured it when I power-up. This signal goes high before FPGA configuration has even started and remains high until power-down. According to UG570, EOS would normally stay low until after the FPGA logic has been globally enabled, but since it's already high when logic is globally enabled, my logic begins trying to communicate to the SPI Flash before being given physical control of the SPI lines. If the EOS was working correctly, my logic would not try to interface to the SPI Flash until the appropriate time.
I have confirmed this by triggering my power-on reset (only resets the FPGA logic) well after the configuration is complete. When I trigger the logic reset after the configuration is done, my logic works correctly to interface to the Flash, but the EOS is not working as an indicator that configuration is complete.
Has anyone else experienced this or have an idea why the EOS is not behaving correctly?
07-09-2019 09:43 AM
Are you able to read the status register at power up and before configuration begins? What does EOS bit indicates?
Sounds strange that EOS signal goes high before configuration begins as you bring signal out to a circuit trace to measure it.
Could you please share the piece of code which instantiate STARTUPE3 primitive? Do you have some other board with Kintex UltraScale 095 FPGA to try the same design?
07-09-2019 02:37 PM
Hi @thakurr ,
Do you have a suggestion on reading the status register before the configuration starts? So far, I can only read the status register after power up. I have to leave the Platform II cable disconnected while configuration occurs and then I can connect, but EOS is already high by that time.
The only thing I haven't done is tried on another board, but I don't have one currently available. I can maybe just extend my power on reset time and use that instead of the EOS, but the EOS would also be a nice solution for power on reset if it was working as I expect.
Here's my instantiation code:
-- STARTUPE3: STARTUP Block -- Kintex UltraScale+ -- Xilinx HDL Language Template, version 2016.1 STARTUPE3_inst : STARTUPE3 generic map( PROG_USR => "FALSE", -- Activate program event security feature. Requires encrypted bitstreams. SIM_CCLK_FREQ => 0.0 ) port map( USRCCLKO => flash_clk_buf, -- 1-bit input: User CCLK input ---------- CFGCLK => open, -- 1-bit output: Configuration internal oscillator clock output CFGMCLK => open, -- 1-bit output: Configuration internal oscillator clock output EOS => EOS, -- 1-bit output: Active-High output signal indicating the End Of Startup PREQ => open, -- 1-bit output: PROGRAM request to fabric output ---------- DO => flash_d_o, -- 4-bit input: Allows control of the D pin output DI => flash_d_i, -- 4-bit output: Allow receiving on the D input pin DTS => n_flash_enable, -- 4-bit input: Allows tristate of the D pin FCSBO => flash_n_cs, -- 1-bit input: Controls the FCS_B pin for flash access FCSBTS => '0', -- 1-bit input: Tristate the FCS_B pin GSR => '0', -- 1-bit input: Global Set/Reset input (GSR cannot be used for the port) GTS => '0', -- 1-bit input: Global 3-state input (GTS cannot be used for the port name) KEYCLEARB => '1', -- 1-bit input: Clear AES Decrypter Key input from Battery-Backed RAM (BBRAM) PACK => '0', -- 1-bit input: PROGRAM acknowledge input USRCCLKTS => '0', -- 1-bit input: User CCLK 3-state enable input USRDONEO => '1', -- 1-bit input: User DONE pin output control USRDONETS => '1' -- 1-bit input: User DONE 3-state enable output );
I then pass the EOS to my QSPI interface and to an external pin for measurement.
07-10-2019 12:38 AM - edited 07-10-2019 12:48 AM
EOS is an internal signal and can be brought to phyicals pins while programming user logic once configuration is complete. I am really not sure how you bring this single to trace circuitary (as you mentioned) at power up before configuration.
EOS is expected to be high once configuration completes and startup phase ends. Does your configuration shows successful with your INIT and Done pin high?
After what time you wish to communicate with flash post configuration. Could you please share your configuration schematic?
Did you also check to XAPP1280 for your reference?
07-15-2020 07:03 AM
We have EXACTLY the same problem, we see EOS not staying HIGH to say Xilinx is finished. it occasionally goes low (which at the same time we lose control of the SPI bus - any data in flight disappears, and AXI QUAD thinks it sent the data !). We see INIT and DONE HIGH.
how was this fixed ?
07-15-2020 06:31 PM
It sounds like your issue may be slightly different. I was trying to use EOS as an enable to logic with an external power-on-reset for global logic reset. I don't think this is possible, as the EOS indicates the logic has finished configuring. I think the EOS can only be used as a global logic reset, not something like a clock enable. If you are already doing this and having an issue, you may have to consult the docs further or hopefully a Xilinx FAE can help. I'm not sure what conditions would cause EOS to de-assert other than power cycling.
My workaround was to use an external power-on-reset which stays asserted a (relatively) long time after the EOS is asserted. This ensures the logic is configured and the SPI lines are ready to use when my reset de-asserts. This may not be an option for you.
One other thing, I can't find it at a quick glance, but I believe there's a requirement to toggle the SPI clock several times before your first transfer as part of the sequence of handing over the SPI lines to the user logic. Make sure you're doing this if you aren't already.
07-17-2020 11:02 AM
We removed the HWICAP module, and the problem with AXI-QUAD-SPI and access to STARTUPE3 pins (SPI Pins) was fixed, i.e the EOS signal behaves correctly
Hence we have a conflict when trying to instantiate all 3 modules, waiting Xilinx to educate us...