We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

Showing results for 
Search instead for 
Did you mean: 
Visitor ian.maw
Registered: ‎02-03-2014

Possible way to work around the Zynq 7000 QSPI 16M limit issue but is it practical ?


For reference we intend to support the 030, 035 and 045 devices.

Would the following be practical please ? :-

We store our program in the first 'page' of flash memory i.e. with the extended address register and zero and our bitstream in the second page. We could then switch the extended address register to zero after configuring the fabric thereby removing the need for the workaround mentioned in AR# 57744 (Design Advisory for Zynq-7000 SoC - Zynq and QSPI reset requirements when using larger than 16MB flash).

If a soft reset were to occur during code execution we would, I assume, restart with the first page of flash thereby booting normally. 

I know this might seem wasteful but we have 64MB.




0 Kudos
1 Reply
Xilinx Employee
Xilinx Employee
Registered: ‎10-11-2011

Re: Possible way to work around the Zynq 7000 QSPI 16M limit issue but is it practical ?

To be 100% recovery on the reset without a reset going to the flash you should copy the FSBL at every 16MB (or 32MB if you are Dual Parallel) boundary.

Is that what you are proposing?

If not, you might have a window in time where, if a reset is receive, the part will be trying to boot from the sencond page NOT finding the image.

If you can guarantee that no reset is received during that time, then swithing back to the first page after bitstream programming should work fine.

0 Kudos