Programmable Devices
CPLDs, FPGAs, SoC FPGAs, Configuration, and Transceivers
21611 Discussions

Output timing measures outside limits predicted by Timequest

Altera_Forum
Honored Contributor II
1,295 Views

I'm having a problem with timing on the Ethernet interface on a 3C120 dev board. 

 

I'm trying to output edge aligned data to the PHY, on a RGMII interface. The clock in the FPGA consists of a clock mux to select a 2.5, 25 or 125MHz clock. This clock is sent to the MAC, and to a ddio output buffer which drives the clock pin, to try to match the delay of the data ddio buffer. The clock output on the dev board is on a VREF pin. 

 

I'm constraining the data outputs to toggle within +/-500ps of clock (RGMII spec). When I compile the design, the compiler turns on the output delay blocks in the data IO buffers, causing the data to arrive (measured) ~800ps after clock, which is clearly incorrect. If I manually turn off the IO delay blocks, the delay is reduced to 250ps, well within spec. 

 

The problem is, when I run a timing analysis with the delay blocks off, timequest give the following timings: 

 

Output timing on txd[0] 

Minimum setup time (at fast 0 degC): 1.106 ns 

Minimum hold time (at slow 85 degC): -1.225nS  

 

Given my constraints that the data must start being valid at +500ps or earlier, and stop being valid -500ps or later: 

Data must be valid until: -0.5 +(-1.225) = -1.725ns 

Data must start being valid at 0.5 - 1.106 = -0.606ns or earlier 

 

Therefore, the data transition must occur between -1.725ns and -0.606ns 

 

But I measure the data transition occurring at +250ps. Something appears wrong with the timing analysis. I don't believe it's my constraints, because if I move the clock pin to a regular IO pin (not a VREF pin), the design meets timing, and the compiler doesn't erroneously turn on the output delay blocks. 

 

Looking at the IO path timing everything is almost identical between the clock and the data lines, except the IO buffer output delay. "enet_txd[0]~output|o" is 2.209ns, and similar on the other data lines. But on the clock pin "enet_gtx_clk~output|o", it's 3.561ns. When I move the clock to a regular IO pin, the delay is similar to the data lines. 

 

The IO placement guidelines say "When VREF pins are used as I/O, they have higher capacitance than regular I/O pins which will slow the edge rates and affect I/O timing", but I assume that the timing should still be within what is predicted by Timequest. What's going on here? 

 

For reference, here are my output timing constraints: 

set_output_delay -clock enetTXClock125Output -max -0.5 enet_tx_en}] set_output_delay -clock enetTXClock125Output -min 0.5 enet_tx_en}] -add_delay set_output_delay -clock enetTXClock125Output -clock_fall -max -0.5 enet_tx_en}] -add_delay set_output_delay -clock enetTXClock125Output -clock_fall -min 0.5 enet_tx_en}] -add_delay # Destination multicycle exceptions set_multicycle_path -setup -end 0 -rise_from -rise_to set_multicycle_path -setup -end 0 -fall_from -fall_to set_multicycle_path -hold -end -1 -rise_from -rise_to set_multicycle_path -hold -end -1 -fall_from -fall_to # False path exceptions for opposite-edge transfers set_false_path -setup -rise_from -fall_to set_false_path -setup -fall_from -rise_to set_false_path -hold -rise_from -fall_to set_false_path -hold -fall_from -rise_to Regards, 

David
0 Kudos
0 Replies
Reply