Timing Analysis

[targonix]

Hello,

I'm using Spartan-3e and ISE v13.1. Firstly, constraint RMII from PHY <--> FPGA. By RMII timings data setup to clock is 4 ns, data hold is 2 ns. Looks easy:

NET "IP_PHY1_EFCLK" TNM_NET = PHY1_RMII_CLK ;
TIMESPEC "TS_PHY1_RMII_CLK" = PERIOD "PHY1_RMII_CLK" 20.0 ns HIGH 12.0 ns ;

NET "OP_PHY1_ETXEN" TNM_NET = RMII_OUTPUT_GROUP1 ;
NET "OP_PHY1_ETXD0" TNM_NET = RMII_OUTPUT_GROUP1 ;
NET "OP_PHY1_ETXD1" TNM_NET = RMII_OUTPUT_GROUP1 ;

TIMEGRP "RMII_OUTPUT_GROUP1" OFFSET = OUT 8 ns AFTER "IP_PHY1_EFCLK" RISING ;
OFFSET = IN 4 ns VALID 6 ns BEFORE "IP_PHY1_EFCLK" RISING ;

1) I'm not sure about OFFSET OUT constraint. Errors here?

Secondly, forwarding clock to MCU RMII with ODDR2:

NET "OP_MCU_EFCLK" TNM_NET = RMII_MCU_GROUP ;
NET "OP_MCU_ERXDV" TNM_NET = RMII_MCU_GROUP ;
NET "OP_MCU_ERXD0" TNM_NET = RMII_MCU_GROUP ;
NET "OP_MCU_ERXD1" TNM_NET = RMII_MCU_GROUP ;

TIMEGRP "RMII_MCU_GROUP" OFFSET = OUT 8 ns AFTER "IP_PHY1_EFCLK" RISING ;
TIMEGRP "RMII_MCU_GROUP" OFFSET = OUT 8 ns AFTER "IP_PHY1_EFCLK" FALLING ;

 2) Here is big troubles, how to keep timing relations between forwarded clock and data (TX and RX)? Have no idea how constraint MCU RMII RX to forwarded clock.

Thanks for help,

Alexey

[graces]

There's no constraint to constrain the skew between forwarded clock and data within a range. The skew can only be "reported" by specifying REFERENCE_PIN keyword.

e.g.

TIMEGRP "RMII_MCU_GROUP" OFFSET = OUT 8 ns AFTER "IP_PHY1_EFCLK" REFERENCE PIN "RGMII_RX_CLK" RISING ;
TIMEGRP "RMII_MCU_GROUP" OFFSET = OUT 8 ns AFTER "IP_PHY1_EFCLK" REFERENCE PIN "RGMII_RX_CLK" FALLING ;

REFERENCE_PIN allows a bus skew analysis of the output signals relative to the ref_pin signal. You can find it in datasheet section in timing report.

By default, the bus skew report is referenced to the signal with the minimum clock to output delay.

[targonix]

Okay, thanks graces for clearing this question. I've placed FF in IOB with (* IOB="FORCE" *), result seems the same, and no timing constraint required. But still, I need to capture RMII data according to regenerated clock (FPGA output). Placing OFFSET IN to regenerated clock doesn't make sense. Any suggestions to constrain?

[eteam00]

But still, I need to capture RMII data according to regenerated clock (FPGA output).

For RMII interfaces, there should be no reason for a 'regenerated clock'  Both the MAC and the PHY should be using the 50MHz reference clock as... as the timing reference for both TXD and RXD.  Here is the RMII specification.

Using the NatSemi (now part of TI) DP83848 PHY as an example:

• Reference clock is 50MHz

• RXD output from PHY is valid from 14nS (max) after each positive Ref Clk edge to 2nS (min) after the next positive Ref Clk edge.

Let's say, for the purposes of discussion:

• You cannot use a DCM to generate the 50MHz reference clock.  Spartan-3E DCM outputs exceeed the maximum jitter allowance for the reference clock (50 PPM) (ref: DS312 Table 105).  The 50MHz reference clock must be generated externally.

• The RXD output from the PHY is valid from 14 nS (max) after each positive Ref Clk edge to 2 nS (min) after the next positive Ref Clk edge.  Normalising to a single clock edge, RXD is valid from 6nS (min) before each positive clock edge to 2nS (min) after each positive clock edge.

• The Spartan-3e pin-to-pin minimum setup and hold times are 4.73 nS and -0.77nS, respectively (ref: DS312 Table 87).  This is well within the RXD valid window guaranteed by the PHY datasheet.

Does this make sense?

-- Bob Elkind

[targonix]

Thanks for answer.

For RMII interfaces, there should be no reason for a 'regenerated clock'  Both the MAC and the PHY should be using the 50MHz reference clock as...

I have FPGA connected to 2 independent PHY's in RMII master mode (each generates own RMII clock; this schematic cannot be changed). Also FPGA connected to MCU's RMII slave port, which requires 50 MHz.

You cannot use a DCM to generate the 50MHz reference clock.

True. Thats why I'm regenerating clock from one of my PHY's. In addition, I have a board where 50 MHz +/- 100 PPM generator caused random packet loss and CRC errors...

The RXD output from the PHY is valid from 14 nS (max) after each positive Ref Clk edge to 2 nS (min) after the next positive Ref Clk edge.  Normalising to a single clock edge, RXD is valid from 6nS (min) before each positive clock edge to 2nS (min) after each positive clock edge.

I'm using National DP83640, timings almost the same. In short, my constraints right?

OFFSET = IN 4 ns VALID 6 ns BEFORE "IP_PHY1_EFCLK" RISING ;
OFFSET = IN 4 ns VALID 6 ns BEFORE "IP_PHY2_EFCLK" RISING ;

Does this make sense?

Not yet. PHY interfaces works fine from start, just want to verify my constraints. But RMII data route from MCU to FPGA while FPGA is clock source, causing random problems.

[eteam00]

Based on page 119 of the DP83640 datasheet (RMII Rx Timing in Master Mode) the specified input timing is:

OFFSET = IN 6 ns VALID 8 ns BEFORE "IP_PHY1_EFCLK" RISING ;
OFFSET = IN 6 ns VALID 8 ns BEFORE "IP_PHY2_EFCLK" RISING ;

This means the RXD data is valid at least 6nS before the rising edge of the master clock from the PHY, and RXD remains valid until at 2nS after the rising edge of the clock (valid time is 6 + 2 = 8 nS).  In the timing constraint syntax, the first numeric value is the position of the data valid time and the second numeric value is the length (duration) of the data valid time.

If the ISE timing analyser says that the actual RXD to PHY_CLK setup time is less than 6nS and the hold time is less than 2nS -- measured at the FPGA pins -- then your design timing works.

This assumes, of course, there is precisely zero board routing skew between the DP83640 and the FPGA.  No problem, right?

But RMII data route from MCU to FPGA while FPGA is clock source, causing random problems.

You'll have to explain this with a bit more detail.  Any idea what 'random problems' means?

-- Bob Elkind

[targonix]

Here is more details.

Based on page 119 of the DP83640 datasheet (RMII Rx Timing in Master Mode) the specified input timing is...

Now, it's clear to me how this constraint works. Thanks.

This assumes, of course, there is precisely zero board routing skew between the DP83640 and the FPGA.  No problem, righ?

No problem, all RMII paths are short enough and have same length. Layout is pretty simple.

You'll have to explain this with a bit more detail.  Any idea what 'random problems' means?

It's CRC errors at FPGA MAC in some MCU's packets. The rate of errors depends on FPGA build configuration. Example: them I'm excluding most part of project from build (not affecting ethernet part) errors rate noticeably lower.

To achieve timings I'm using clock inversion while regenerating it in ODDR2. This means MCU's TX data lines switching at negedge of forwarded clock. Here is reports:

Clock IP_PHY1_EFCLK to Pad
-------------+------------+-------------------+--------+
             | clk (edge) |                   | Clock  |
Destination  |   to PAD   |Internal Clock(s)  | Phase  |
-------------+------------+-------------------+--------+
OP_MCU_EFCLK |    6.352(R)|IP_PHY1_EFCLK_BUFGP|   0.000|
             |    6.352(F)|IP_PHY1_EFCLK_BUFGP|  12.000|
OP_MCU_ERXD0 |    6.374(R)|IP_PHY1_EFCLK_BUFGP|   0.000|
OP_MCU_ERXD1 |    6.370(R)|IP_PHY1_EFCLK_BUFGP|   0.000|
OP_MCU_ERXDV |    6.374(R)|IP_PHY1_EFCLK_BUFGP|   0.000|
OP_PHY1_ETXD0|    7.319(R)|IP_PHY1_EFCLK_BUFGP|   0.000|
OP_PHY1_ETXD1|    7.668(R)|IP_PHY1_EFCLK_BUFGP|   0.000|
OP_PHY1_ETXEN|    7.317(R)|IP_PHY1_EFCLK_BUFGP|   0.000|
-------------+------------+-------------------+--------+

TIMEGRP "RMII_OUTPUT_GROUP" OFFSET = OUT 8 ns AFTER COMP "IP_PHY1_EFCLK"         REFERENCE_PIN BEL "OP_MCU_EFCLK" "RISING";
Bus Skew: 0.022 ns;  
------------------------+-------------+--------------+
PAD                     | Delay (ns)  |Edge Skew (ns)|
------------------------+-------------+--------------+
OP_MCU_EFCLK            |        6.352|         0.000|
OP_MCU_ERXD0            |        6.374|         0.022|
OP_MCU_ERXD1            |        6.370|         0.018|
OP_MCU_ERXDV            |        6.374|         0.022|
------------------------+-------------+--------------+

In this case MCU MAC says no errors. But capturing data from MCU to FPGA use internal clock as reference (while actual clock is regenerated and inverted):

Setup/Hold to clock IP_PHY1_EFCLK
-------------+------------+------------+-------------------+--------+
             |Max Setup to|Max Hold to |                   | Clock  |
Source       | clk (edge) | clk (edge) |Internal Clock(s)  | Phase  |
-------------+------------+------------+-------------------+--------+
IP_MCU_ETXD0 |    0.313(R)|    1.247(R)|IP_PHY1_EFCLK_BUFGP|   0.000|
IP_MCU_ETXD1 |    0.019(R)|    1.482(R)|IP_PHY1_EFCLK_BUFGP|   0.000|
IP_MCU_ETXEN |    2.523(R)|    1.097(R)|IP_PHY1_EFCLK_BUFGP|   0.000|
IP_PHY1_ERXD0|    0.727(R)|    0.907(R)|IP_PHY1_EFCLK_BUFGP|   0.000|
IP_PHY1_ERXD1|    1.024(R)|    0.670(R)|IP_PHY1_EFCLK_BUFGP|   0.000|
IP_PHY1_ERXDV|    3.253(R)|    0.494(R)|IP_PHY1_EFCLK_BUFGP|   0.000|
-------------+------------+------------+-------------------+--------+

[eteam00]

You'll have to explain this with a bit more detail.  Any idea what 'random problems' means?

It's CRC errors at FPGA MAC in some MCU's packets. The rate of errors depends on FPGA build configuration. Example: them I'm excluding most part of project from build (not affecting ethernet part) errors rate noticeably lower.

Perhaps I have not yet had enough coffee this morning, please forgive me for my simple questions...

• What are "MCU" and "MCU's packets" ?  I understant "TXD to PHY" and "RXD from PHY", but not "MCU's packets".
• Are the only 'players' in this discussion the NatSemi ethernet devices and the FPGA, or are there others?

-- Bob Elkind

[targonix]

Are the only 'players' in this discussion the NatSemi ethernet devices and the FPGA, or are there others?

Here we have 2 NatSemi PHY's DP83640 connected to XC3S500E and AT91RM9200 also connected to FPGA by RMII.

What are "MCU" and "MCU's packets" ?  I understant "TXD to PHY" and "RXD from PHY", but not "MCU's packets".

Yep, it's not so clear. In this terms I mean data RXD from MCU e.g. source of data is MCU.

[eteam00]

MCU = AT91RM920?

Can you describe if and how the MCU is connected to the FPGA?

-- Bob Elkind