- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Link Copied
0 Replies

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page