Actions
Forum Thread Details
  • State Not Answered
  • Replies 5 replies
  • Subscribers 332 subscribers
  • Views 1078 views
  • Users 0 members are here
Related

DDR3 routing on ZedBoard Rev C

bhfletcher

The Zynq TRM states

  •   All trace lengths must also include the package delay.
  •   Data Groups should be within +/5ps of DQS
  •   Addr/Ctrl within +/-10ps of Ck
  •   Differential pairs should be matched within +/-5 mil

Assuming 160ps/inch for internal FR4 layers, the PCB trace delays are 6.3ps/mm.

ZedBoard Rev C routing does not account for the internal Zynq package delays.  Micron DDR3 timing is specified at the package ball, therefore, the DDR3 package delays do not need to be included in the calculations.

 

Once the Zynq package delays / flight times are incuded in the overall routing delays, the Rev C ZedBoard DDR3 routing violates the recommended guidelines given by Xilinx.  However, ZedBoard has gone through extensive testing which shows the memory system works and is stable.  The routing skew is just one of many factors that affects the overall performance of the memory system.  As shown by ZedBoard, it is possible to violate the skew recommendations and still work, but that is not recommended.  For people designing their own Zynq-based platform, it is recommended that you account for the internal Zynq package delay.

 

The Zynq package delays can be found using an ISE Command prompt with the partgen command.  The syntax to obtain the Package file for the ZedBoard Zynq device is:

partgen -v xc7z020clg484

 

Bryan

  • 0

    Bryan,

    Sounds like you really dug into this.  What is the skew on the pcb?  How close did they get to matching?

    Austin

  • 0

    Austin,

    Regarding the DDR3, I did see that Xilinx recently loosened the Data group matching requirement to match the Address/Control at +/-10ps.  Unfortunately, the ZedBoard is still in violation of this loosened guideline.  Please understand that at the time ZedBoard was designed, much of the documentation had not yet been published.  Since we have working boards, we have been reluctant to make any changes.

    Including the 7020-CLG484 package flight times and the Rev C ZedBoard routing, here are my calculations in picoseconds for skew:

    •   Data Group 0 to DQS0  
          
      •     -18 / +4
        •  
    •   Data Group 1 to DQS1  
          
      •     -17 / +2
        •  
    •   Data Group 2 to DQS2  
          
      •     -24 / +11
        •  
    •   Data Group 3 to DQS3  
          
      •     -33 / +7
        •  
    •   Addr/Ctrl to CLK0  
          
      •     -39 / +39
        •  

    Those calculations assume 6.3ps/mm of trace.

    Note that we are also violating, “Differential traces should be length matched to ±5 mil if possible.”  My calculations on the P vs. N length difference, including package flight time are:

    •   DQS0  
          
      •     20.0 mil
        •  
    •   DQS1  
          
      •     9.1 mil
        •  
    •   DQS2  
          
      •     34.5 mil
        •  
    •   DQS3  
          
      •     61.2 mil
        •  
    •   CLK0  
          
      •     33.4 mil
        •  

     

    In spite of these violations, I recommend that others duplicating the ZedBoard design or creating their own Zynq design do their own timing analysis or strictly follow the Xilinx-provided guidelines.

    Bryan

  • 0 in reply to bhfletcher

    I understand the case for using the ZEDboard constants for DDR3 worksheet calculations, but wanted to understand a little better where these numbers were obtained.


    In the HW user's guide Table 2 shows the Package Length values. I can't get these - partgen and it's Vivado equivalent don't show the length but the flight time only. For example, for DQS0 I get a mean time of ~67.6ps trace delay. For 160ps/mil this is 422mils, while the table gives 504.


    How were the table package length values calculated? What is their source?

  • 0 in reply to vadimv

    When Zynq was first supported in the Xilinx tools, the DDR3 parameters were calculated using an Excel spreadsheet that was included as part of Answer Record 46778. The 504 mils listed for DQS0 was what Xilinx had listed at the time (June 2012). I'm not sure if this was an inaccuracy in the spreadsheet or if the package flight times were refined after that time with additional characterization.

     

    In terms of the Zynq PS DDR3 properly working, having a slightly inaccurate value causes no harm as the silicon is going to calibrate the controller once it comes up. These delay values just need to be close to give the calibration unit a place to start. Incidentally, if you look in a Vivado 2014.2 block design for ZedBoard, DQS0 now shows a Package delay of 68.4725 ps. Is this the Max that you are seeing? I'm not sure why Xilinx would use the Max rather than the mean of Max and Min.

    image

     

    In terms of trace length matching your own PCB with Zynq, you should use the latest values available through a Vivado package report.

     

    Bryan

  • 0 in reply to bhfletcher

    Yes, my tool - Vivado 2014.x - is telling me that the max delay is ~68ps, which represents a shorter package length than what's quoted in the table of the user's guide. I guess the user's guide quotes older numbers, but as you said it's not a huge deal.


    Thanks for your help and reply!