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: 
Observer pevide
Registered: ‎05-27-2016

Zynq QSPI pcb routing delays

Hi all,


I am in the process of routing a QSPI (Micron N25Q128A) to a Zynq-7020.

While gathering information, I saw the following formula related to the trace propagation delay in page 68 of UG933:


TQSPICKD < Tckominflash + 2 * Tpd (requirement)


From what I read in the datasheet, the constraint seems rather severe and must be followed even thought it looks like it means the traces will have to have several inches of copper.


Now, here is my question:

Does this rule also apply when the clock feedback is disabled? Meaning, clock speeds lower than 40 MHz.


It is confusing because for clock speeds above 40 MHz the value of TQSPICKD is 1.3ns and it becomes 12.5ns for speeds lower than 40 MHz. This can be seen in page 23 of DS187.

It gets even more confusing by looking at timing diagrams in page 24 where TQSPICKD starts after a falling clock edge when Feedback Clock is enabled and this changes to the rising edge of the clock when Feedback Clock is disabled.


Does this mean the 12.5ns (half of a 40MHz period cycle) can be considered as 0ns in the formula described above due to edge inversion?

The datasheet for the N25Q128A only gives a maximum clock falling edge to data, not a minimum. Is it also correct to assume 0ns in the formula?


Please let me know if the question is not clear.


Thank you,


0 Kudos
4 Replies
Observer carlomundsen
Registered: ‎05-12-2017

Re: Zynq QSPI pcb routing delays

 Hi Marcelo,


Did you get to the bottom of this? I also find the rule of thumb in UG933 a little confusing.




0 Kudos
Teacher muzaffer
Registered: ‎03-31-2012

Re: Zynq QSPI pcb routing delays

@carlomundsen this is a hold requirement and therefore has nothing to do with the clock  speed. Tpd is about the copper trace propagation delay. 


"For example, with a Zynq-7000 AP SoC hold time requirement of 1.3 ns, and a flash clock-to-out of 1.0 ns, the propagation delay of the clock and data lines must be at least 0.15 ns. With a higher hold time requirement, the PCB trace delays will need to increase. "

- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give Kudos to a post which you think is helpful and reply oriented.
0 Kudos
Observer carlomundsen
Registered: ‎05-12-2017

Re: Zynq QSPI pcb routing delays

Thanks for the response. 


I understand it is referring to hold time and have also read the same exert from UG933. 


However, for a zynq hold time requirement of 12.5ns (as it is when feedback is disabled) the tpd requirement and consequent copper length when following this formula become ludicrous i.e ~1 meter. Sanity check...


Perhaps someone can explain the rationale behind this rule? There is no reference to an application note in UG933 explaining how this rule is derived (which would be useful). Its clear to me that keeping the trace lengths matched (to within +/- 50ps as recommended) is necessary, but under normal clocking conditions (feedback disabled) why does this rule apply?

0 Kudos
Observer carlomundsen
Registered: ‎05-12-2017

Re: Zynq QSPI pcb routing delays

OK so the above rule doesn’t apply when not using feedback since the hold times for the Zynq do not extend past the falling edge of the clock. This does occur in feedback mode as can be seen on pg 24 of DS187.


In feedback mode, you want to be sure that before the QSPI attempts to put more data out, the zynq hold time is complete. You can make up for any violation of this by increasing the tpd (you can factor in 2 times since the delay applies to the clock as seen by the NOR and the data line as seen by the zynq). 


With feedback disabled, the hold time completes on the falling edge (when the QSPI, after its output hold time, will output the next data bit), so there is need to compensate with tpd. Still of course important to match data and clock lines to within +/- 50ps.

0 Kudos