P1020 SGMII possible ESD Problems

[Tilman]

Hi anybody,

we designed a custom board using the P1020 and a GBit Phy (by Marvell) connected via the SGMII (SerDes) lines of the CPU.

During ESD evaluation of our hardware we encountered that the connection to the GBit Phy stops working under some circumstances.

All other interfaces like eLB, DDR, SDCard, 100MBit Eth, ... keep operating.

Analyzing the status of the SerDes using an 8B/10B Protocol Sniffer we found out that there are protocol violations/errors on the TX Path from the P1020 to the GBit Phy if the SerDes channels was disturbed by an ESD pulse.

We never ever did some shoots with the ESD Gun directly on the physical interface. We always shot into the ground/earth connection of the device, far away from the SerDes connection.

So, for my understanding it must have something to do with electrical or magentical fields whcih are generated by the ESD shot.

Is there anybody who has some similar experiences?

Thanks in advance for your time.

Best Regards

Tilman

[emj]

We have a similar implementation and are also seeing issues.  We are using an Atheros GigE PHY connected via SGMII on a P1021.  GigE is used for intra-system communication via backplane, it never leaves chassis.

ESD hits to chassis/earth ground causes the GigE interface to stop functioning.  We're still in debug/info gathering phase, but the Atheros PHY itself appears to be functioning throughout testing.  As above, all other interfaces operate as expected, DDR3, eLBC, 10/100 Ethernet PHYs, etc.

We would greatly appreciate any further information you find on the issue.

Regards,

EMJ

[Tilman]

Pls. try the following procedure to reset the serdes IP core.

If it works, you are facing the same problem.

Original instructions from FSL support:
1.a) set 0th bit of a register located at CCSRBAR + 0xE_3000 + 0x20
1.b) Poll 1st bit of the same register to check if reset procedure is completed. The bit will get set after completion of SERDES reset.

This is a code snippet from our (manual) serdes reset procedure:
  {
   #define SERDES_RESET_REG_ADDR    (Address)(0xffe00000 +0xe3020)
   #define SERDES_RESET_BIT         (1 <<31)
   #define SERDES_RESET_DONE_BIT    (1 <<30)
   if( bSerdesResetRequest ) // async user request (button, GPIO, ...
   {
    int chk ;
    UINT4 RegShadow ;
    RegShadow = ReadIntMem( SERDES_RESET_REG_ADDR ) ;
    printf( "Resetting SERDES %08X ...\n", RegShadow ) ;
    RegShadow |= (UINT4)(1 << 31) ; // Set undocumented reset bit for SERDES
    WriteIntMem( SERDES_RESET_REG_ADDR, RegShadow ) ;
    for( chk = 0; chk < 10000; chk++ )
    {
     RegShadow = ReadIntMem( SERDES_RESET_REG_ADDR ) ;
     if( (RegShadow & SERDES_RESET_DONE_BIT) == 0 ) // Reset pending ?
     {
      printf( "Resetting SERDES running %08X ...\n", RegShadow ) ;
      break ;
     }
    }
    for( chk = 0; chk < 10000; chk++ )
    {
     RegShadow = ReadIntMem( SERDES_RESET_REG_ADDR ) ;
     if( (RegShadow & SERDES_RESET_DONE_BIT) == SERDES_RESET_DONE_BIT) // Reset done ?
     {
      printf( "Resetting SERDES Ok %08X ...\n", RegShadow ) ;
      sleep( 1 ) ;
      break ;
     }
    }
   }

[emj]

Thank you for the additional info, we've started work on your suggestion.

As an aside, we did test adding a small (~20pf) cap to the SERDES reference clock.  This filter did not improve performance under ESD testing.

Regards,

EMJ

[Tilman]

Hi EMJ,

is  there any news from your side?

In the meantime we bougth another device from one of the famous modular embedded board manufacturers with a P1020 inside and onme of the GBit channels connected via SerDes.

Same bad results while doing the ESD testing.

BR

Tilman

[Tilman]

Ok, expected behavior with an additional cap on the serdes clock.

Pls. keep us up to date. It is of high interest for us, if we are facing the same problem.

[kjames]

You may also try filtering the sysclk and ddrclk since they are single ended

[kjames]

Perhaps try putting a filter on the serdes reference clock...something small like a 22pf.

[Tilman]

Is this just an idea or did you get some positive results adding a small Cap?

The serdes reference clock is a differential signal and from my knwoledge, it is not very common to add capacitors.

Pls. correct me if I´m wrong.

[kjames]

you are correct that differential signals will have better ESD rejection since they essentially filter common mode noise.

However, if you source this from a single ended oscillator followed by a single ended to LVDS converter, for instance, then the single ended clock line may be susceptible.

Also, perhaps there are protection diodes or equivalent on the IO pins that are referenced to GND.  These may possibly affect differential signalling operation.  These are all just guesses to the IO architecture in the chip.

As a response to the first question: Yes, I have had positive results adding small decoupling capacitors to the SYSCLK pin.  I was having ESD problems on a custom P1022 based platform.  The problem manifested itself as a system lockup when ESD was applied to the connector nearest the clock circuit on the PCB.  Applying a small filter to this single ended clock line fixed the issue.

[Tilman]

As mentioned below, our main problem is the serdes IP (might be PLL related) because resetting the serdes core always results in a working GBit Ethernet connection. So decoupling the sysclk wouldn´t do the trick.

Nevertheless thanks for the additional help. If we will (ever) come to the point where we got a working GBit connection, we will come back on this issue.

[LPP]

Suggestion is to localize the regions succesible to EMI transients and then to apply hardware measures to fix the problem.

Probable nodes are power supplies, analog power, high speed clocks and decoupling of high speed devices (CPU, PHY, clocks).

To determine the root cause you can perform manual or automatic (if you have access to test equipment) ESD susceptibility scanning.

http://ewh.ieee.org/r1/boston/rl/files/boston_rs_meeting_mar14.pdf

Have a great day,
Pavel

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[Tilman]

FYI: In the meantime we did some more investigations supported by one of the famous EMC Labs here in Germany.

Conclusion (from our point of view): No suitable way to get the P1020 (SerDes Core) working in an industrial environment.