Actions
Forum Thread Details
  • State Not Answered
  • Replies 3 replies
  • Subscribers 324 subscribers
  • Views 785 views
  • Users 0 members are here
Related

SD Card layout for a custom 7EV carrier board

mad_dog

Hello...Viewing the Zynq-7000 SoC PCB Design Guide (UG933) the following statement is made:

"PCB and package delay skew for SD_DAT[0:3] and SD_CMD relative to SD_CLK must be between 50–200 ps"

I am designing a carrier board for the Avnet UltraZed EV SOM that will have a micro SD card holder. Can someone interpret the Xilinx layout advice for me? I assume the SD_DATA and SD_CMD traces should be matched in length (ie trace plus package delay) but I cannot determine what Xilinx means in reference to the SD_CLK signal. Are they saying the SD_CLK should be delayed 50-200 pS relative to the other traces or the SD_CLK should lead those traces by 50-200 pS? Something else entirely?  Hopefully someone out there has done a successful layout and figured this out. Any help is appreciated. Thanks!

  • 0

    I just did the layout for a micro-SD card for a Zynq SoM. They way I interpreted it was keeping them all matched to within that delay (converted to approximate length since I was doing length matching). After reading up on the internet about it, that was my conclusion. So in my case, I matched the length of ALL of those signals to be within X length of each other. I believe in Altium it's called "group length matching". 

    That said, I haven't tested it yet. The boards will arrive in about 2 weeks which is when I can test it out.

    Please do share what you end up doing in the end!

    Regards,
    Saad

  • 0

    My interpretation:
    SDIO (SD Card) is a synchronous interface (like SPI). You should not delay the response "too much": the response (data in on master) is sampled with the same local, internal SD_CLK (all in relation to this internal clock).
    I take it as: "make sure your delay for SD_DAT[0;3] (very important for a read response) and SD_CMD (sending towards SD card: not delaying this as well for causing a 'late response";) should be in the range of 50.. 200 ps (max.)"

    I do not see a need for SD card interface to match all the trace length. Especially, do NOT delay SD_DAT and SD_CMD lines even more with extending their trace length (e.g. just to match it with a long SD_CLK trace).
    Worst case: SD_CLK is a short trace, all other are longer (and adding "propagation delay" plus "round trip delay"). To trim all these traces, e.g. extend SD_CLK length to the same length as the SD_DAT - does not make sense (it increases the "round trip delay" even more).

    Actually, it tells me just this:
    "keep (all) the traces to the SD card socket as short as possible. If required to keep 200 ps max. delay skew - it results in a maximum trace length you can have" (when signal reaches the SD card socket and is responded).

    Assume: 11.8 in/ns (in vacuum). On a PCB (dielectric constant) the trace length gets shorter (slower speed).
    So, for 200 ps max. - it will result in keeping SD card traces short (resulting in a max. trace length based on this requirement).

    BTW: if you make the traces longer - you lower the max. SD card SD_CLK speed (it will work only with slower speed, esp. to read).
    A trace length matching is not really needed (for my feeling), as long as you do not delay the SD_DAT and SD_CMD lane "too much" (and even not SD_CLK)).

    Just to bear in mind as well: do you want to run SD card in SDR mode or in DDR mode?
    DDR mode is more challenging (just half a clock cycle now, tricky "setup time"): DDR mode is more sensitive to delay skew and potentially this requirement comes from running DDR mode with fastest nominal speed supported by the FPGA.

  • 0 in reply to saadtiwana_int

    Hi Saad...The Altium files for the Avnet carrier board are available online so I looked at their layout. The DATA and CMD tracks are carefully matched at very near 3 inches in length. The CLK track has a total length very near 3.5 inches. This would mean the clock is delayed by about 85pS, putting it in line with "50-200pS range Xilinx specified. So my interpretation is leaning towards meaning the CLK should be skewed (delayed) 50-200pS with respect to the data and command signals. Best...MD