FPGA Intellectual Property
PCI Express*, Networking and Connectivity, Memory Interfaces, DSP IP, and Video IP
6359 Discussions

Triple Speed Ethernet clk signals

Altera_Forum
Honored Contributor II
1,126 Views

I am trying to set up a simple ethernet test using the TSE IP core on a Cyclone III dev kit that includes a Marvel 88E1111 PHY (RGMII interface). 

 

I just want to simply set a few registers and send out pings to verify it is working, so I'm not using any SOPC components to interface with the Avalon ports - I'm using my own FSM. 

 

My problem is that I cannot get the (extremely simple) design to meet timing requirements, specifically the 125MHz clock that provides the reference for the RGMII interface (tx_clk). 

 

I also get a troubling warning "Warning: 1 (of 13161) connections in the design require a large routing delay to achieve hold requirements. Please check the circuit's timing constraints and clocking methodology, especially multicycles and gated clocks." 

 

I'm not sure what connection is the problem and I haven't found a way of displaying that information. 

 

I've gone over the TSE data sheet and dev kit reference manual and this is what I think I'm supposed to connect to each clock signal for the generated TSE component: 

 

clk: register access reference clock (I'm using 100MHz for this since 125 doesn't meet timing requirements, and I'm assuming this clock can be different from the others) 

 

tx_clk: RGMII transmit clock reference (must be 125MHz for my PHY), I send the same clock out a pin to the PHY 

 

rx_clk: RGMII receive clock reference (input from the PHY, expected to be 125MHz) 

 

ff_tx_clk: transmit FIFO clock (same clock as for the "clk" signal above) 

 

ff_rx_clk: receive FIFO clock (same clock as for the "clk" signal) 

 

All clocks are generated from the dev kit 50MHz oscillator and pass through their own altpll and altclkctrl megafunctions. 

 

With this setup, the clock going to "tx_clk" doesn't meet the 125MHz requirement and shows a limit of 107MHz in the classic timing analyzer. However, the design will compile and meet requirements if I use 100MHz clocks for everything, but that isn't an option for the RGMII. 

 

How should I be handling these clocks and which ones can be safely independent from the others? Can I gain any insight by investigating the warning I mentioned and how do I go about that? (I'm using Quartus 7.2)
0 Kudos
0 Replies
Reply