UPGRADE YOUR BROWSER

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!

Reply

Zynq PL DDR3 routing/timing

Accepted Solution Solved
Highlighted
Newbie
Posts: 2
Registered: ‎03-13-2018
Accepted Solution

Zynq PL DDR3 routing/timing

I need clarification for PL DDR3 routing. UG933 gives very specific details (+/-10ps) for DDR3 routing for the PS but does not say anything about routing for the PL DDR3. I am most concerned about the internal package delay and whether I need to compensate for that in the PCB layout or if since its PL DDR3 I can compensate for any internal package delay with the built in software compensation. Basically do i need to include the internal package delay from the Zynq in my PCB routing DDR trace length compensations with regard to the PL DDR3.


Accepted Solutions
Scholar
Posts: 1,186
Registered: ‎02-24-2014

Re: Zynq PL DDR3 routing/timing

Oh no,  the external DDR3 timing is fixed relative to the IO cells in the device, so it wouldn't change with different PL designs.   It's a good practice in general to route the PCB with trace lengths that take into account the package internal traces.   The difficulty happens when you use a different FPGA in the same package, and then the trace lengths are different, so this can impair the maximum attainable frequency if the board was designed for a different FPGA.   As long as you always use a 7045 on your board, everything should be fine.

Don't forget to close a thread when possible by accepting a post as a solution.

View solution in original post


All Replies
Scholar
Posts: 1,186
Registered: ‎02-24-2014

Re: Zynq PL DDR3 routing/timing

You haven't said whether this is Zync 7 series or Ultrascale+..     But in any event the DDR3 memory interface user guide (UG586) recommends that the PCB routing should take into account package delays:

 

Trace Lengths
The trace lengths described here are for high-speed operation. The package delay should
be included when determining the effective trace length. Note that different parts in the
same package have different internal package skew values. De-rate the minimum period
appropriately in the MIG Controller Options page when different parts in the same
package are used.
The most accurate and recommended method for determining the delay is to use the L and
C values for each pin from the IBIS models. The delay value is determined as the square
root of (L × C).
Alternatively, a less accurate method is to use PARTGen. The PARTGen utility generates a
PKG file that contains the package trace length in microns (µm) for every pin of the device
under consideration. For example, to obtain the package delay information for the
7 series FPGA XC7K160T-FF676, this command should be issued:
partgen -v xc7k160tff676
This generates a file named xc7k160tff676.pkg in the current directory with package
trace length information for each pin in microns. A typical 6.5 fs/micron (6.5 ps/mm)
conversion formula should be used to obtain the corresponding electrical propagation
delay. While applying specific trace-matching guidelines for the DDR3 SDRAM interface,
this additional package delay term should be considered for the overall electrical
propagation delay. Different die in the same package might have different delays for the
same package pin. If this is expected, the values should be averaged appropriately. This
decreases the maximum possible performance for the target device. These rules indicate
the maximum electrical delays between DDR3 SDRAM signals:
• The maximum electrical delay between any DQ and its associated DQS/DQS# should
be ±5 ps.
• The maximum electrical delay between any address and control signals and the
corresponding CK/CK# should be ±25 ps.
• The maximum electrical delay of any DQS/DQS# should be less than that of
CK/CK#.
DQ to DQS matching can be relaxed by the change in clock period as the frequency is
lowered from the maximum. For example, if the maximum supported frequency for a
configuration is 533 MHz, then the bit time at this frequency is 937.5 ps. The DQ to DQS
PCB skew is allowed to be +/- 5ps. If this design is operated at 400 MHz, the bit time is
1250 ps. The change in period is 1250 minus 937.5 or 312.5 ps. Half of this is 156 ps. Thus
the new skew allowed is +/- (156+5) or +/- 161 ps.
Write leveling is required for both DIMMs and components. Designs using multiple
components should arrange the components in a fly-by routing topology similar to a
DIMM where the address, control, and clocks are shared between the components and the
signal arrives at each component at a different time. The data bus routing for each
component should be as short as possible. Each signal should be routed on a single PCB
layer to minimize discontinuities caused by additional vias.
Don't forget to close a thread when possible by accepting a post as a solution.
Newbie
Posts: 2
Registered: ‎03-13-2018

Re: Zynq PL DDR3 routing/timing

Thanks we are using a XC7Z045. I can understand why the PS DDR routing would need to take into account the internal Zynq package differences because the PS memory controller is not configurable i.e the trace lengths would not change based on FPGA code. I don't understand what to do for the PL or how you would compensate for each change, wouldn't the trace lengths differ depending on the FPGA code? So every time you change the code you could end up changing your internal FPGA logic fabric and trace length/routing for your PL DDR memory?

Scholar
Posts: 1,186
Registered: ‎02-24-2014

Re: Zynq PL DDR3 routing/timing

Oh no,  the external DDR3 timing is fixed relative to the IO cells in the device, so it wouldn't change with different PL designs.   It's a good practice in general to route the PCB with trace lengths that take into account the package internal traces.   The difficulty happens when you use a different FPGA in the same package, and then the trace lengths are different, so this can impair the maximum attainable frequency if the board was designed for a different FPGA.   As long as you always use a 7045 on your board, everything should be fine.

Don't forget to close a thread when possible by accepting a post as a solution.