9 Replies Latest reply on Mar 6, 2020 2:17 PM by mad_dog

    SD Card Initialization Failing

    mad_dog

      We are using an UltraZed-EG SOM with a custom carrier board that includes an SD card and an Ethernet PHY (DP83867IRPAPT). Including the PHY on the SOM, our system has two Ethernet ports. We are experiencing a mysterious problem where the SD card often fails to initialize properly if our carrier board PHY is enabled. If that PHY is held in reset during any SD initialization we see no problems. This does not appear to be a transient power-up issue as we see this problem when the card is initialized at any time after power up as long as the PHY is also enabled. We are trying to uncover any possible links between the SD card and PHY activity but they seem completely separate entities. Does anyone have any ideas on this?

        • Re: SD Card Initialization Failing
          drozwood90

          Hi there,

           

          First are you using both GEM out of the PS?  Or is one loaded in the PL?

          What power solution are you using?

          You are correct that they are separate hardened IP inside the PS.  The only link they really share is the switching MUX that is in side the PS that allows you to configure the IO pins and which hardened IP is enabled.

           

          The only idea I would encourage you to investigate a bit more is the power issue, but if you are highly satisfied that cannot be the issue, I'm not sure what else to offer, except have you contacted your local FAE?

           

          Here are a few guesses, and again, without knowing more, they are guesses based on just the information you have provided, and especially since I've not personally seen more than 1 design in my career where people use dual ethernet.

          • Maybe try to sequence the initialization always initializing the SDCARD then the PHY?  This might help if there is a problem on the PS power rails or maybe the capacitance is not 100% proper for the switching frequency you are using?
          • Are you configuring those elements using a BDF?  If so, where did the base of that BDF start from?  Maybe the ORDER of initialization is causing some internal issue?  Dubious, but I've seen odd things with clocks when using a BDF and clicking things in the "wrong" order.  This was in OLDER versions of Vivado and my SPECIFIC issues were resolved, but I would offer change the BD PS configuration selection order.  End result SHOULD be the same thing, but the output might be different.
          • Does having a cable plugged into the ethernet jack matter?  That is if the PHY is active, does that matter, or is the issue just that it is out of reset.  I'm curious if there is a logic thing going on (a PHY wait state causing something internal to the PS not being happy until that is released)
          • Have you tried different SDCARDS?  There are some incompatible cards that are marginal...and some that we've tested as certainly good.  Here is a document related to that: http://zedboard.org/zynqgeek First item "SD Card Advice V2 for Zynq and Zynq UltraScale+ SoC Products"
          • Have you tried NO SDCARD?

           

          I'll pass this by a few people here and see if there are any further thoughts

           

          --Dan

          1 of 1 people found this helpful
            • Re: SD Card Initialization Failing
              mad_dog

              Hi Dan...Thanks for your reply and questions. I have passed them along to our VHDL and software people and here are their replies:

               

              • Yes, both GEMs out of the PS.
              • I’m not sure at what point this initialization sequencing should take place. We do know that if the phy is held in reset while the SD card is init’d, we don’t have issues.  However, then we release from reset and linux re-init’s the SD card, and we can have issues there.
              • Our BDF was built from a blank design. At some point I started over and re-built it to clean up the design. Both designs had issues and it’s possible I clicked everything in the exact same way both times. We’ve used 2019.1 for everything.
              • We have not seen any issues with the SD card if the PHY is held in reset through its reset input pin or if we do not have a cable connected at the Ethernet jack. 
              • We have done a fair amount of testing on the IOCC (though we will likely do more) and have so far seen no issues with this SD card.

                     We’re using a SanDisk card and a Samsung card that have had no issues on a separate Zynq 7000 design nor on the Ultrazed SOM/IOCC combo.

               

              I will also mention another odd observation; we've done testing where the SD card always runs at 400KHz (doesn't ratchet up to 50MHz)) and in that state we get errors in init and in normal SD card operation. For those times when we do get a successful init of the card (this whole issue is sporadic) we can run at 50MHz without issue.

               

              From the hardware perspective, we are using JX3 pins 94 thru 100 for our SD card and pins 69 thru 82 connect to our Ethernet PHY. Is there any chance of crosstalk or inadvertent coupling between these groups of pins in the SOM layout? We don't have access to that or I would look at it myself.

               

              Finally, can you provide some guidance for me on SD card layout for carrier cards? I have read that the routing needs to be length matched (ZUS chip package delay + SOM routing delay + carrier card routing delay) but I am confused about the SD card clock. There is mention made of have a certain amount of skew (50-200pS) between the data/cmd signals and the clk. Can I assume the clock should be delayed to allow setup time for the other signals? I have studied the IOCC layout in detail and there was clearly an effort made to match the lengths and the clk does appear to be slightly shorter. What is the function of the series resistor (R34) in the clk line? Since it cannot be located on the SOM (where I would expect a source terminator to make sense) what is the purpose/effect of that resistor on the IOCC? There is a note on the IOCC schematic about locating this resistor within 100mils. Is the intent to locate it within 100mils of the SD card holder edge which then has another 550 mils or so to reach the SD card clk pin? I'm just not sure what's going on here.

               

              Also, we have definitely sent many questions to our FAE but so far we have not made any progress, hence my posting here. Thanks again for your help. It is much appreciated...Mike

              1 of 1 people found this helpful
                • Re: SD Card Initialization Failing
                  drozwood90

                  Hi there,

                   

                  We really do not have a lot of experience with dual ethernet.  I was looking around the Xilinx forums, and there seems to be quite a few posts on using DUAL ethernet.  You might get a bit more exposure if you post there as well.  If you do get a resolution, please cross post to help others that might see this issue.

                   

                  I will have to check on the layout.  I do not think there would be issues with cross talk, but I cannot say we have a spec. where we explicitly state to design against crosstalk from certain pairs.  From what I understand, the layout shouldn't incorporate any more crosstalk than any other bus layout as we do have quite a few spec. callouts for lengths and I believe that the pins were done in pairs, then groups.  This should be listed in the UltraZed Carrier Card Design guide.  If you need to see actual screen shots, you should be able to contact your FAE for official access to that information.  The SOM design files are more protected.

                   

                  For layout guidance, you will want to refer to the above mentioned Carrier Design Guide as well as the Xilinx UG583

                  https://www.xilinx.com/support/documentation/user_guides/ug583-ultrascale-pcb-design.pdf

                   

                  For the Design Guide, head to the UltraZed-EG Product Page:
                  UltraZed-EG

                  Click on Technical Documents,

                  then download the guide

                   

                  As for specifics to the amount of skew, I'm not sure I can answer that.  You can check the BDF configuration that we provide in our repository, as well as compare against the trace lengths that we have for the UltraZed Carriers + SOM + Package.

                   

                  I will have to get back to you on the resistor, however, typically the resistor is there to aid in reduction of reflections.  I cannot be positive, but that might be an SDCARD spec. need.  As I mentioned, I'll ask and get back to you on that.

                   

                  --Dan

                  • Re: SD Card Initialization Failing
                    drozwood90

                    HI there,

                     

                    I was able to confirm, R34 is a termination resistor for SI reasons.  The note means 100mil of the PAD of the card cage.

                     

                    --Dan

                      • Re: SD Card Initialization Failing
                        mad_dog

                        Hi Dan...Sorry for the delay. You should now be able to PM me through zedboard.org. There was a mixup with my account there but it seems to work now. Our FAE has started to produce some results for us with people at Xilinx so we'll see how that goes. His suggestions are mostly in the Linux software realm.  I am still quite confused about the SD card layout. In past versions of UG583 UltraScale Architecture PCB Design there was a bullet item in the SD card section concerning the 50-200 pS skew and the wording was confusing. In fact it inspired several questions on the Xilinx forum that people attempted to answer. In more recent versions of UG583 reference to skew has been deleted. This leaves me with really no guidance as to layout requirements for the SD interface other than some generic common sense things. I intend to ping Xilinx directly about this. So the IOCC layout is the only guidance I have right now and I know it works well. The location and purpose of R34 is still bothering me. Measuring the distance from it to the CLK pad in the card holder I get about 600mils so I still don't know how this matches up with the layout note on the schematic. If the resistor is there for SI reasons you would normally put that close to the driven end of the net which is on the SOM. I wonder if someone did an SI simulation on this and found a sweet spot in the CLK net to place the resistor since it can't be located on the SOM. Thanks for your thoughts...Mike

                          • Re: SD Card Initialization Failing
                            drozwood90

                            Mike,

                             

                            Seems you answered all my questions I was trying to PM you about.

                             

                            I will ask the design team about the position.  I personally did not validate the physical location, so this is interesting to me that you find it to be 600mils out!

                             

                            --Dan

                              • Re: SD Card Initialization Failing
                                drozwood90

                                Mike,

                                 

                                I suspected this and was confirmed, we cannot predict what customers will use these IO for, as you can reprogram them to quite a few things using the PS configurator. If you decide to use the SOM in some other way, those IO might be part of a matched pair or bus and the resistor could toss that out of sync.

                                 

                                As such, we did an analysis of the trace.  The a series resistor is used to trim the impedance of the trace to accommodate the actual board Z. The resistance is adjusted from doing Z analysis along with phase gain and margin with insertion equipment. The resistor can be anywhere from 22 ohms to 49.9 ohms based on this analysis. I was also told you can terminate and Z match at the source or destination of a signal, either works, but preferred at source if being driven hard with high current.  I've personally done similar in my efforts over the years, but was being driven more by IO type (open collector/High-Z) and frequency, which can cause different reflections over a frequency range.  However, I'm thinking at these clock rates it doesn't matter where it ends up.

                                 

                                If you need help with this analysis for your custom board, I can get you in touch with our design services team for a quoted effort on your design.

                                 

                                --Dan