DP83822I: RMII with SFD on CRS / RX_D3

Hi Gordon, 

From what I am understanding, you want to use the PHY in RMII Master mode (with the 25MHz input clock as opposed to the 50MHz). You also wanted to use this same clock as an input to the MAC (FPGA), which would generate the 50MHz from the supplied 25MHz. This may cause timing mismatch between the clock of the PHY and the clock of the FPGA. It is recommended to supply the FPGA with the generated clock from the PHY.  

Gordon Leather said:

• In RMII Master mode, does IEEE 1588 TX Pin Select (PTPPSEL(6:4)) take precedence over default CRS_DV output in RMII mode?
• In RMII Master mode, does IOCTRL1(10:8) – RX_D3 / GPIO_3 Control take precedence over the default MAC IF CLK Out on RX_D3?

These registers should take priority over the default functions. I will verify this functionality and reply back here to confirm if these register settings do take precedence.

Gordon Leather said:

In RMII Master mode, is the phase alignment between 50-MHz MAC IF Clock and 25-MHz Clock-In constant, and if so, what is

I believe that the clocks should be in phase, or at least have a constant phase difference. I will also confirm this in the lab and reply back here. 

Please expect my results from the lab by EoD Thu (1/23)

Best,

Vivaan

Hi Vivaan,

Thank you for the quick reply.

Vivaan Jaiswal said:

This may cause timing mismatch between the clock of the PHY and the clock of the FPGA. It is recommended to supply the FPGA with the generated clock from the PHY.

Yes, if we were starting a new design, this is what we'd do.  Or use RMII Slave mode at 50MHz.  Unfortunately we're trying to upgrade the functionality of existing fielded HW (which was configured as an MII interface), so I'm working on getting SFD signals to the FPGA without changing any existing circuitry.

As the PHY and the FPGA both receive the same 25MHz clock, and both the PHY and FPGA generate 50MHz from the same 25MHz source, there will be no frequency drift....hopefully all we need to do is set the phase of the FPGA 50MHz to match the phase of the PHY 50MHz, then we can control setup/hold times easily.

Thank you very much for investigating this - I'll check back tomorrow.

Cheers,
Gordon

Hi Gordon, 

Thank you for your patience. Here is what I found

Gordon Leather said:

• In RMII Master mode, does IEEE 1588 TX Pin Select (PTPPSEL(6:4)) take precedence over default CRS_DV output in RMII mode?
• In RMII Master mode, does IOCTRL1(10:8) – RX_D3 / GPIO_3 Control take precedence over the default MAC IF CLK Out on RX_D3?

I was able to confirm that IOCTRL1 does take precedence over the default 50MHz out on RX_D3. I will be testing the SFD on CRS tomorrow and update here again.

Gordon Leather said:

In RMII Master mode, is the phase alignment between 50-MHz MAC IF Clock and 25-MHz Clock-In constant, and if so, what is it?

I was also able to confirm that the 50MHz clock should be synchronous with the 25MHz input although there may be a slight negligible delay between the two. Regardless, this small delay will be constant and should not be anything big enough to worry about. 

I also wanted to stress the fact that this application may work but we cannot guarantee that the device will function nominally in this application. This device was designed to have a common 50MHz clock being shared between the PHY and MAC interfaces in RMII mode, not 2 independent clocks.

Best,

Vivaan

Thanks Vivaan, good news so far.

I recognise your caution, and appreciate this approach is unconventional and not recommend :-)  If the SFD on CRS also works, I think we can achieve what we want with changes in the FPGA.

The 2 clocks aren't truly independent - they come from a single low-drift 25MHz source via a matched-skew clock buffer and matched delay PCB traces, so if PHY 50MHz is aligned with incoming 25MHz and FPGA 50MHz is aligned with the same incoming 25MHz, all we have to account for is different PLL bandwidths and jitter - I'd expect these combined to be below a nanosecond cycle-to-cycle, so there's plenty of slack in the 20ns clock period after accounting for setup, hold and IO skew.

There are some other tricks we can use in the FPGA - for example we know trace and IO delays, and we have much faster internal clocks available (also synchronous to the main 25MHz), so we could oversample RX_DV, RX_D[1:0] and infer the PHY RX_CLK position based on the edges.....but I'm hoping that won't be necessary.

Cheers,
Gordon

Hi Gordon, 

I was able to verify today that the PTPPSEL bits do override the default CRS_DV function. Usually, CRS_DV is a required signal for RMII, and it consists of carrier sense and receive data valid signals. I was going to suggest connecting RX_DV, but looks like your hardware was originally built for MII, so it already has this signal connected. 

This is definitely an unconventional and interesting application. Theoretically, I do see how it could work. Please keep me updated on whether this application was successful or not.

Best,

Vivaan