03-07-2018 07:35 AM
We're using Kintex-7 and Artix-7 with QSPI as configuration flash. We want to upgrade the flash via in-system programming. Bitstream source is transferred from PCIe core in the FPGA.
Previously we used PROM as flash and XAPP581 technology to upgrade the FPGA. But PROM is EOL and we have to move on to QSPI.
XAPP1191 uses a STARTUPE3 primitive that is not available in Kintex/Artix-7. Can I use general IO pins that connected to the same flash for this design? There also a reason to use general IO pins because we're planning to use tandem SPI boot-up design XAPP1179 due to PCIe requirement, in which those dual-purpose IOs are persist after configuration and not available to user logic. I assume upgrade through these pins cannot be done.
We're trying to avoid use tandem PCIe design because the host system may very, that rely on system driver to load the 2nd part of the FPGA is not easily controllable.
Could you suggest a solution for our application? Thanks.
03-07-2018 02:14 PM
Can I use general IO pins that connected to the same flash for this design?
We use Kintex-7 and Micron Flash MT25QL128 which is capable of SPIx1 and SPIx4 operation. After FPGA is configured, bitstream file is brought into the FPGA via custom VHDL UART. Bitstream is then sent to Flash using custom VHDL and flash SPIx1 connections. Almost all the FPGA connections to the flash (FPGA pins MOSI, DIN, FCS_B) can be controlled as general I/O after the FPGA is configured. The only exception is the clock connection to flash which can be accessed via the STARTUPE2.USRCCLKO primitive (see ug953).
Table C-2 in ug908 says that Kintex-7 can use SPIx4 operation of MT25QL128. So, I think that methods I have described for SPIx1 remote update of bitstream will work (after straightforward modifications) for SPIx4.
03-07-2018 06:10 PM
The dilemma is that we also need to use PCIe tandem design, which require to persist all configuration pins after FPGA is loaded. So we have to use other general IOs.
I did try modify the ref design project that comes with XAPP1191, remove STARTUPE3 and use general IO pins, as well as use FIFO36E1 to fit Kintex-7 part. Bitstream can be generated no problem.
03-09-2018 11:50 AM
I do not have experience using PCI-Express (PCIe) to configure the FPGA. However, I am interested and hope we can discuss your requirements further.
I understand that you are developing a product that must communicate using PCIe. To meet PCIe requirement of “100ms boot time”, you must get the FPGA configured and running quickly after power is applied. Xilinx document pg054 describes two methods for doing this called Tandem-PROM and Tandem-PCIe.
Tandem-PROM has drawback that interface with PROM “persists” (ie. cannot be re-purposed as user I/O) after FPGA configuration. Tandem-PCIe does not have the persist problem but requires that part of the bitstream be uploaded through the PCIe interface during power-up configuration of the FPGA.
Finally, you want to update bitstream(s) stored in PROM while the FPGA is running. The “persist” of Tandem-PROM prevents this type of access to PROM. Tandem-PCIe allows the PROM access that you need but externally uploading part of the bitstream through the PCIe bus at every power-up is undesirable. Did I describe things correctly?
I’m sure you’ve thought of this – but digital muxs (switches) placed external to the FPGA and on the PROM-to-FPGA lines are a work-around for persist problem of the Tandem-PROM method. A simple RC-timer could hold muxs in one state for ~200ms during power-up and while FPGA is configured. After 200ms, muxs toggle to new state, connecting PROM control lines to FPGA digital I/O that you control.
03-12-2018 08:11 AM
Hi Mark email@example.com
Thanks for the reply and idea. You described my problem exactly.
The initial idea was to have some other general IO pins connected to the same QSPI (in parallel with dedicate config pins) for after configuration access, like upgrade in the field. After some more reading and research in the forum, now I have concern that those dedicate pins may be behave badly that preventing normally access via other channel, either from general FPGA IO or even external SPI port. It was said that if config persist is set, the FPGA will periodically access the flash after configure is done.
I'm thinking the same idea as you suggested. RC delay probably not need though. Using one other FPGA pin to control the switch (tri-buffer) should be doable. That pin is hi-z during configuration and remain so until I need to get access to the flash. The difficulty may be to find proper bi-directional tri-state buffer cause QSPI DQs are bi-directional.
The other way is that even those pins are persist as set, I have a feeling that they are still accessible via STARTUPE2. I'll try a project that uses STARTUPE2 see if it compiles.
03-12-2018 12:14 PM
....the FPGA will periodically access the flash after configure is done.
I wonder why? If this is true then it could be a show-stopper for you.
That pin is hi-z during configuration and remain so until I need to get access to the flash.
Be careful here! On our Kintex-7 board, we have a digital line that needs to remain high during configuration and until the firmware takes control of it. I can't recall the details but we found that "hi-z during configuration" was not always the case. We ended up adding a small circuit on the board that held the line high during board power-up. After the firmware was up and running (ie. after a simple RC timer ran out), the small circuit gave control of the line to the FPGA output.
03-12-2018 02:28 PM
Good to know that firstname.lastname@example.org, thanks.
For your board that won't hold hi-z during configuration, are you sure PUDC_B wasn't tied low or in xdc didn't set pull_up/down for that pin? Anyways, I also have concern here 'cause the circuit increase the FPGA not load risk.
After trying my project of different settings, it seems the STARTUPE2 can't be used in a tandem design.
For non-tandem design bitstream option "persist" will not prevent the user access of STARTUPE2 in design. But not the case in tandem design.
Although the core generate tcl script already have that primitive in the stage1 pblock, I still got this error:
[DRC 23-20] Rule violation (HDTC-12) CONFIG cells must be in stage one - Configuration cell 'fpga_top_inst/STARTUPE2_inst' is not marked as a stage 1 cell. This cell must be added to stage 1 or removed from your design.
If manually include it in stage1 Pblock, I got this error:
[DRC 23-20] Rule violation (PLDE-1) Design Exceptions - [Over-Constrained 1] fpga_top_inst/STARTUPE2_inst constrained such that no valid location exists on the device. Last constraint applied is of type User:AreaGroupClosed
Not a easy way to fix this place error. Also, using STARTUPE2 don't save me to much, it's only connected to CCLK pin, not any other configuration dedicated pins. So we still have to use some external buffers, add one more to the CCLK and won't use STARTUPE2 at all probably is the only solution.
Could any Xilinx expert provide a better solution? Thanks so much.
03-12-2018 02:44 PM
03-13-2018 06:51 AM
For your board that won't hold hi-z during configuration, are you sure PUDC_B wasn't tied low or in xdc didn't set pull_up/down for that pin?
Thanks for helpful suggestion! Actually, I incorrectly described my situation. We have tied PUDC_B low and were counting on an FPGA standard output (pin G8) to stay in a valid logic state (any valid state) until firmware took control of the output. I incorrectly said that we were counting on G8 to remain in hi-z state - sorry. Oscope showed a couple of millisec-length pulses on G8 during FPGA power-up and configuration. AR50802 and AR66871 apply to what we were trying to do. Anyway, the added small circuits that I described previously are working for us.
Good luck with your project! -hope those Xilinx experts show up to help you.