AM6422: Distorted Reference Clock on Serdes Refclock Input

Likely it is because the CDCE6214 is providing LPHCSL and has its own internal 50ohm terminations and thus you become double terminated when connecting to PCIE of SOC.  PCIE is just HCSL

In the mean time, we found a setup where the clock is no longer distorted by correctly disabling the output of the AM6422.

We still have the problem that due to the internal termination of the SoC, the level is about half of what we expect. This is not a problem regarding the differential amplitude, but Vcross only sits at around 190mV and the PCIe Base Spec expects at least 250mV. Is there a way to disable this internal termination? Or is it okay to have a Vcross lower than what the spec demands?

Hi Manuel, what is your software code base ? (Linux etc)  I will need to ask some s/w experts on how to disable any internal terminations.   Also does you application require to use external reference clock?  There were errata i2236 and i2241 which do not apply with silicon revision 2.0

Hi James, while we would not need the external reference clock now with rev 2.0, we still opted for this option so we could enable spread sprectrum clocking in the future if needed during compliance testing. To my understanding, spread spectrum clock generation still has issues on the rev 2.0 silicon? We are on a Linux 6.6 kernel right now.

Understood.  I will get our linux s/w team involved and reply back this thread.  (I closed the other e2e duplicate)

is the AM64x to be as end point or root complex

Root Complex. We use the PCIe to connect a WiFi card

Hi Manuel, attached is a patch that will disable the internal terminations.  Can you please try this out and see if it corrects your issue.

-James0001-phy-ti-phy-j721e-wiz-disable-reference-clock-termina.patch

Per Michael's email back: 

TI we tested the patch and it does not seem to affect the voltage level:

Performed 'devmem2 0x0F00040C and confirmed Bit 27 is being set to 0b'1'

Also we tested using the AM64 internal 100Mhz ReflClk and it seems to work but with voltage level still lower than we expect.

Does TI have a way to address above voltage level when using AM64 as source of 100Mhz RefClk and what is this internal clock driver type?  Is it LP-HCSL or ??

Hi Michael,

wrt the devmem2 0x0F000040C -> Can you provide the return from this register beyond just Bit 27 value?

wrt AM64 100Mhz RefClk source -> it is type HCSL and with internal termination available

wrt AM64 100Mhz RefClk voltage amplitude -> From our characterization I see clk+ Vmax 600mv and clk+ Vmin 108mv ; clk- Vmax 572mv clk- Vmin 109mv ; Vcross 340mv  ; was a high impedence scope probe used during your measurements?

wrt CDCE6214 as RefClk and no change in amplitudes pre/post patch -> did you mention having measured w/o the AM64 device in place and if so what was the clock diff level in that condition

Lastly, in the other thread, I believe you had mentioned that you determined the source of original clock distortions as needing to disable the AM64x RefClk from sourcing at same time as CDCE6214.  Can you confirm if this correct understanding of that distorted clock issue.

wrt the devmem2 0x0F000040C -> Can you provide the return from this register beyond just Bit 27 value?
(I think you mean 0x0F00040C instead of 0x0F000040C)
devmem 0x0F00040C
-> 1011 1000 0000 0000 0000 0000 0000 0000

wrt AM64 100Mhz RefClk source -> it is type HCSL and with internal termination available
In our case: Do we need any external termination in case of sing the internal clock generator? Because we thought there might be 50 Ohm need to be connected to GND on the CLK P/N Lines. I tested, but this did not fix the voltage Level issue.

wrt AM64 100Mhz RefClk voltage amplitude -> From our characterization I see clk+ Vmax 600mv and clk+ Vmin 108mv ; clk- Vmax 572mv clk- Vmin 109mv ; Vcross 340mv  ; was a high impedence scope probe used during your measurements?
I have measured it two passive high impedance probes to see the voltage cross for PCIe. We have to fulfil a minimum voltage cross 250mV to 550mV aacording to the PCIe specificaiton.
I've also done the measurement with an active differential probe. You already got the measurements results for both variants.

wrt CDCE6214 as RefClk and no change in amplitudes pre/post patch -> did you mention having measured w/o the AM64 device in place and if so what was the clock diff level in that condition

We did the measurements with the AM64 in place, but have seen higher voltage levels at the pcie clock slot than on the REF-CLK to the SoC (W16/W17).

Lastly, in the other thread, I believe you had mentioned that you determined the source of original clock distortions as needing to disable the AM64x RefClk from sourcing at same time as CDCE6214.  Can you confirm if this correct understanding of that distorted clock issue.

The distorted clock issue is fixed, we don't see this behaviour anymore. It was correct that two clock signals have been active as the same time before any of our patches.

wrt the devmem2 0x0F000040C -> Can you provide the return from this register beyond just Bit 27 value?
(I think you mean 0x0F00040C instead of 0x0F000040C)
devmem 0x0F00040C
-> 1011 1000 0000 0000 0000 0000 0000 0000
JP : yes you dumped the register I meant to type
Please confirm the value you provided was when you had configuration to use the CDC as sourcing RefClk?
if yes to above, are you intending a common clock configuration where the CDC provides RefClk to both the AM64 as Root Complex and also to the wifi card?
1011 1000 0000 0000 0000 0000 0000 0000 would disable AM64 from sourcing a RefClk but would have AM64 as using it's own internal RefClk
Can you share how you implemented to disable the AM64 from sourcing RefClk from your clock distortions debug

wrt AM64 100Mhz RefClk source -> it is type HCSL and with internal termination available
In our case: Do we need any external termination in case of using the internal clock generator? Because we thought there might be 50 Ohm need to be connected to GND on the CLK P/N Lines. I tested, but this did not fix the voltage Level issue.
JP : Sorry, I am not understanding what you tested when stating "I tested, but this did not fix the voltage level issue"
Can you elaborate more on what exactly you tried?
Since the driver is HCSL, yes there will have to be termination resistors somewhere with the source. Using the internal resistor will suffice to set voltage levels

wrt AM64 100Mhz RefClk voltage amplitude -> From our characterization I see clk+ Vmax 600mv and clk+ Vmin 108mv ; clk- Vmax 572mv clk- Vmin 109mv ; Vcross 340mv ; was a high impedance scope probe used during your measurements?
I have measured it two passive high impedance probes to see the voltage cross for PCIe. We have to fulfil a minimum voltage cross 250mV to 550mV according to the PCIe specification.
I've also done the measurement with an active differential probe. You already got the measurements results for both variants.
JP : Aplogies, since we are also discussing the AM64 used as source of RefClk, are your comments referring to CDC as source not meeting Vcross or AM64 as source not meeting Vcross?
My comments wrt characterization results was from AM64 as RefClk source.

wrt CDCE6214 as RefClk and no change in amplitudes pre/post patch -> did you mention having measured w/o the AM64 device in place and if so what was the clock diff level in that condition
We did the measurements with the AM64 in place, but have seen higher voltage levels at the pcie clock slot than on the REF-CLK to the SoC (W16/W17).
JP : Would you mind going back to configuration of CDC as RefClk source and dump again register 0x0F00040C but without the Refclk term disable patch in place?  Want to confirm if the Refclk term disable has already been set elsewhere.

Lastly, in the other thread, I believe you had mentioned that you determined the source of original clock distortions as needing to disable the AM64x RefClk from sourcing at same time as CDCE6214. Can you confirm if this correct understanding of that distorted clock issue.
The distorted clock issue is fixed, we don't see this behavior anymore. It was correct that two clock signals have been active as the same time before any of our patches.
JP : mentioned above, but can you share what changes you made to disable the AM64 from sourcing RefClk

James Pair said:

Please confirm the value you provided was when you had configuration to use the CDC as sourcing RefClk?

Yes. confirmed.

James Pair said:

if yes to above, are you intending a common clock configuration where the CDC provides RefClk to both the AM64 as Root Complex and also to the wifi card?

In case we keep the CDC, then yes the architecture is as root complex.

James Pair said:

1011 1000 0000 0000 0000 0000 0000 0000 would disable AM64 from sourcing a RefClk but would have AM64 as using it's own internal RefClk
Can you share how you implemented to disable the AM64 from sourcing RefClk from your clock distortions debug

That's strange because I got this result on our Board with your newest patch you've attached previously, so the CDC Clock Generator is active instead of the AM64 clock. If you really need the Implementation I need to get feedback from the sw team

James Pair said:

Since the driver is HCSL, yes there will have to be termination resistors somewhere with the source. Using the internal resistor will suffice to set voltage levels

I soldered a 50 Ohm resistor to GND on every clock line according to HCSL. The resistors were placed near the driver, but this did not improve the clock signal. It has been also one of our first thoughts about this issue.

James Pair said:

Aplogies, since we are also discussing the AM64 used as source of RefClk, are your comments referring to CDC as source not meeting Vcross or AM64 as source not meeting Vcross?
My comments wrt characterization results was from AM64 as RefClk source

We meet the Vcross specification of 250mV to 550mV for AM64 as RefClk source. We got about 300mV.
If we use the CDC Clock Generator the Vcross is not met at the CPU Side. But instead at the PCIe Slot (Target) it's high enough (about 360mV).

James Pair said:

Would you mind going back to configuration of CDC as RefClk source and dump again register 0x0F00040C but without the Refclk term disable patch in place?  Want to confirm if the Refclk term disable has already been set elsewhere

We could deliver this information with the help of our SW Team, but in our case if we prefer the configuration with the AM64 standalone - would this help in finding out the issue here ?
Currently our preferred configuration would be the AM64 internal clock to save components cost. If the clock is functioning correctly, we would keep the solution.

OK, we can re-focus to AM64 as RefClk source.  I haven't yet looked in detail your latest response, but did have a request for our linux team's needs.  

Can you provide your Linux device-tree nodes for WIZ and SERDES 

thanks,

James

James Pair said:

1011 1000 0000 0000 0000 0000 0000 0000 would disable AM64 from sourcing a RefClk but would have AM64 as using it's own internal RefClk
Can you share how you implemented to disable the AM64 from sourcing RefClk from your clock distortions debug

&serdes_refclk {
clock-frequency = <100000000>;
};

&serdes0 {
clocks = <&serdes_wiz0 TI_WIZ_PLL0_REFCLK>,
  <&serdes_refclk>;
clock-names = "refclk", "phy_en_refclk";

assigned-clocks = <&serdes_wiz0 TI_WIZ_PLL0_REFCLK>,
    <&serdes_wiz0 TI_WIZ_PLL1_REFCLK>,
    <&serdes_wiz0 TI_WIZ_REFCLK_DIG>;
assigned-clock-parents = <&k3_clks 162 1>,
    <&k3_clks 162 1>,
    <&serdes_refclk>;
};

Hi Michael,

can you request your s/w team to provide your Linux device-tree nodes for WIZ and SERDES?  While reviewing your provided schematics, want to consider your s/w configurations too.

wanted to confirm the differences in h/w and s/w used between the two waveform examples for when AM64x as RefClk source you provided previously and copied below:

The top waveform shows an amplitude of 362mv and bottom showing 279mv but I believe only the bottom was with external 50R on clkp/n.  Is this correct? Was the CDC chip still in the path and its state (powered but with output clocking disabled or ??)  And then on either were you using the patch provided previously?  Do you have devmem 0x0F00040C log corresponding to each?

Thanks,

James

James Pair said:

can you request your s/w team to provide your Linux device-tree nodes for WIZ and SERDES?  While reviewing your provided schematics, want to consider your s/w configurations too.

I posted that already before in the last post.

James Pair said:

The top waveform shows an amplitude of 362mv and bottom showing 279mv but I believe only the bottom was with external 50R on clkp/n.  Is this correct

Yes correct.

James Pair said:

Was the CDC chip still in the path and its state (powered but with output clocking disabled or ??)  And then on either were you using the patch provided previously?

The CDC chip was decoupled for this test. The Patch did not change the Voltage Level and the pictures were without that specific patch for the CDC Clock fix (not for the internal TI Clock).

James Pair said:

Do you have devmem 0x0F00040C log corresponding to each?

This one is internal TI Clock: 

root@localhost:~# devmem2 0x0F00040C
/dev/mem opened.
Memory mapped at address 0xffffaa080000.
Read at address 0x0F00040C (0xffffaa08040c): 0xF9000000
--> Binary: 1111 1001 0000 0000 0000 0000 0000 0000

The other one you already got during mail traffic

I am unable to find the result of devmem2 0x0F00040C that corresponds to the waveform with amplitude of 362mv and from internal TI clock w/o 50R soldered in.

If the 1111 1001 000...  address result was obtained without the supplied disabled_refclk_terminations patch being applied then I need to check further into what s/w is disabling it.  Bit 27 is returning as '1'

Hi Michael,

Please refer below inputs based on the review of the provided schematics:

• Add 50R pulldown for the P and N clock signals near to the SOC pins.
• The SERDES0 supplies needs to be filtered. The power supply page is not provided to review.
• USB0_VBUS voltage divider - follow the SOC data sheet recommendations
• USB data interface signals - connect directly fro the connector
• Verify fail-safe operation
• Verify external ESD protection

Regards,

Sreenivasa

Hi Kallikuppa

Are the 50R pulldowns needed in both modes, with external and internal reference clock? We plan to move our design towards using the internal reference clock generator.

Hello Manuel,

The review comments are based on the below design approach:

here are the schematic extracts of the sections regarding the PCIe Clock. Please let us know when you need some other information.

The Clock Generator Page will be removed and the TI Port W16/W17 will be connected directly to the PCIe mini 5.9mm Slot Terminals. (Pin 11 & Pin 13).

Could you review which external components are needed? Termination Resistors to GND, serial resistors and so on.

If you do not intend to drive any of the attached device with Am64x clock output, i suspect you may not have to populate the 50R pulldowns

Regards,

Sreenivasa

Okay, thank you. We will drive the module in the PCIe mini slot and will therefore foresee the resistors in our schematic