Cyclone V: reaching RGMII Data to Clock output skew of +/- 500ps

Hi Jodok,

Check this KDB link https://www.intel.com/content/www/us/en/support/programmable/articles/000079123.html, it's recommended to select the PHY with ability to adjust its input timing.

Thanks,

Regards,

Sheng

Hi,

I think should be no problem with your ddr transmission constraint based on this link https://www.intel.com/content/www/us/en/support/programmable/support-resources/design-examples/horizontal/exm-tse-rgmii-phy.html

I think the ddr is center aligned (tPeriod/2).

(tPeriod/2 - tPHYDELAY) reflects the shifted clock edge to ensure the setup and hold times are correctly met despite the delay

Hi,

Seems like that's the phy delay lacking which causes the violation.

Is the timing pass after adding the phy delay?

Hi,

I think you can refer the timing constraints in AN477: Designing RGMII Interface with FPGA and HardCopy Devices (page 12) https://www.intel.com/content/www/us/en/content-details/654563/an-477-designing-rgmii-interface-with-fpga-and-hardcopy-devices.html

The internal PHY delay is considered in tco for set_input_delay

For the equation in this link https://www.intel.com/content/www/us/en/support/programmable/support-resources/design-examples/horizontal/exm-tse-rgmii-phy.html, $data_delay_min, $data_delay_max, $clk_delay_min, $clk_delay_max put 0 as assume trace delay, pin capacitance, and rise/fall time differences between data and clock are negligible

Design .qar can be found here https://blog.csdn.net/wangyanchao151/article/details/90401027

Let me know if any further update or concern.

Thanks,

Regards,

Sheng

Hi,

May I know you're using External PHY Device with the Delay Option Is Enabled right?

Based on the AN477 page 12 design example, could you try with the 3 combinations below:

Assume trace delay, pin capacitance, and rise/fall time differences between the data and clock are negligible.

Combination 1:

tx_max_delay = tDataTrace(max) + tSU = 0ns+1.05ns = 1.05ns

tx_min_delay = tDataTrace(min) + tHold = 0ns-0.8ns = -0.8ns

Combination 2:

tx_max_delay = tDataTrace(max) + (-tSU) = 0ns+(-1.05ns) = -1.05ns

tx_min_delay = tDataTrace(min) + tHold = 0ns-0.8ns = -0.8ns

Combination 3:

tx_max_delay = tDataTrace(max) + (-tSU) = 0.33ns+(-1.05ns) = -0.72ns

tx_min_delay = tDataTrace(min) + tHold = -0.33ns-0.8ns = -1.13ns

I think Td (TS_CLK to TXD/TX_CTL output data delay) -0.85ns to +0.15ns is not related to rgmii as design example didn't include that as well.

Hi Sheng,

thank you for your response!

How does one then respect the "asymmetrical" characteristic of the Delay introduced by the PHY?

Could you please review the following constraints for a ddr transmission.

max_delay = tData(max) + tSU - (tPeriod/2 - tPHYDELAY)

min_delay = tData(min) - tH - (tPeriod/2 - tPHYDELAY)

Thank you very mouch.

Dear Sheng,

I am not sure if we are on the same page anymore.

My interest is to reach the timing for MII-Tx, so i am not interested in input_delay constraints.

Fact is, if I constrain tx_max_delay and tx_min_delay as following and use a PHY-Delay of 2ns, Timing Analyzer gives me negative slack.

tx_max_delay = tDataTrace(max) + tSU = 0.33ns+1.05ns = 1.38ns

tx_min_delay = tDataTrace(min) + tHold = -0.33ns-0.8ns = -1.13ns

With this constraints made, I should meet the +/- 0.5ns "data to clock output skew" spiecified in RGMII v2.0

But this is not the case, so I wonder where does this negative slack come from.

So please, is Td (TS_CLK to TXD/TX_CTL output data delay) -0.85ns to +0.15ns in Table 48 in the CycloneV Datasheet of relevance in that case? What does it mean? Other sources tell me that it should be irrelevant since the synthesis tool should best match the internal skew of the fpga.

Thank you for your response.

Hi Sheng

Yes, I still use a PHY with delay option of 2ns enabled.

Combination 1 seems the correct one to me. This is what I was doing originally.

But still, with exact this combination TA fails with -0.065ns max slack -40°..+100°C both, fast and slow model analyzed.

Combination 2 seems to be ilegitime, since tx_min_delay has to be smaller than tx_max_delay.

Combination 3 would theoretically be legal since tx_min_delay is smaller than tx_max_delay, but since the formula is the same as for Combination 2, it is false as well.

I will try to find other resources to get on.

Thank you Sheng.

Hi,

Even without the tracedelay, the setup still fail. Could you try with PHY with delay option disabled, does the timing pass?

Seems like there's something wrong with the parameter used.

Hi Sheng,

Correct, even without the tracedelay (Combination 1), the setup fails.

"Could you try with PHY with delay option disabled, does the timing pass?"

But I do need the PHY-delay to shift the data from edge- to center-aligned. Without, timing will fail massivley.

...and did faild massively.

Again, what jitter at the Cyclone V is to be expected for such a combination of both, data and clk coming from ddio-buffer?

Could you please share with me what jitter is to expect.

Does the fpga maybe struggle to delay the data singals internally positive or negative to the clock signal?

Could I help the synthesis tool by shifting the external PHY-delay away from symmetric (2ns) towards a asymmetrical delay for example (+/- 1.5ns). But this is basically what I tried to achive before and failed.