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

Triple Speed Ethernet - Lost packages, timing problem?

Altera_Forum
Honored Contributor II
1,212 Views

Hello, 

 

I'm having some problems with the TSE IP (RGMII) provided by Altera, and Nichestack 

 

I have the core instantiated inside a Qsys system, with all the required connections (SGDMA, descriptor memory, Nios...). Right now, I only want to be sure that the design is correct and I can communicate with the board (a Cyclone IV GX dev. board), so after loading Nichestack with eclipse I ping the board. 

 

At first I couldn't see any response (using Wireshark), but the tx led was blinking. For what I have read in this forum, it could be a timing problem (I hadn't modified the constraints file generated by qsys). 

 

So I modified it, setting the correct TX_CLK and RX_CLK (125 MHz): 

 

# Frequency of network-side interface clocks or reference clocks set TSE_CLOCK_FREQUENCY "125 MHz" # Frequency of FIFO data interface clocks set FIFO_CLOCK_FREQUENCY "75 MHz" # Frequency of control and status interface clock set DEFAULT_SYSTEM_CLOCK_SPEED "75 MHz" set TX_CLK "enet_gtx_clk" set RX_CLK "enet_rx_clk" I tried to include CLK, FF_TX_CLK, FF_RX_CLK (75 MHz): 

 

set FF_TX_CLK "clocks_inst|pll_inst|altpll_component|auto_generated|pll1|clk" set FF_RX_CLK "clocks_inst|pll_inst|altpll_component|auto_generated|pll1|clk" set REF_CLK "clocks_inst|pll_inst|altpll_component|auto_generated|pll1|clk" But these clocks are generated with a PLL, and the create_clock command didn't work, since in the sdc file uses get_ports. 

 

Nevertheless, now it worked. Kind of. It answers to my pings, but some of the responses get lost: 

 

daniel@daniel-pc:~$ ping 192.168.2.200 PING 192.168.2.200 (192.168.2.200) 56(84) bytes of data. 64 bytes from 192.168.2.200: icmp_req=1 ttl=64 time=4.27 ms 64 bytes from 192.168.2.200: icmp_req=2 ttl=64 time=0.386 ms 64 bytes from 192.168.2.200: icmp_req=3 ttl=64 time=0.379 ms 64 bytes from 192.168.2.200: icmp_req=4 ttl=64 time=0.380 ms 64 bytes from 192.168.2.200: icmp_req=11 ttl=64 time=0.328 ms 64 bytes from 192.168.2.200: icmp_req=12 ttl=64 time=0.317 ms 64 bytes from 192.168.2.200: icmp_req=13 ttl=64 time=0.393 msThen, I modified the portion of the .sdc file where the clocks are created, and changed "get_ports" to "get_pins". In this case I don't have any problems with the clocks, but it doesnt work, I get a blinking tx light but no response. 

 

I am really a bit lost here. Do you think that it is a timing problem, as it seems? What could I do? 

 

Thank you
0 Kudos
1 Reply
Altera_Forum
Honored Contributor II
387 Views

What you have to do is create or derive PLL clocks yourself and only then put their names to TSE mac SDC like (FF_TX_CLK, FF_RX_CLK) etc. Specifying pins or ports there won't do the job. 

 

After you are done with that you have to make sure you constrain RGMII input and output pins properly (i.e. apply proper pin delays, set false path etc). I am not sure what board you have, though. I have Arria II GX 6G with Marvell PHY 88E1111 and that PHY works with center-aligned I/O. You have to check your reference manual. 

 

I recommend you dive deep into AN477 — http://www.altera.com/literature/an/an477.pdf. It describes RGMII timing, has SDC examples etc. 

 

Here are also some articles that were a bit useful for me: 

 

* http://www.altera.com/support/examples/timequest/exm-tq-ca_ss_in.html 

* http://www.altera.com/support/examples/timequest/exm-tq-ca_ss_out.html 

 

Though if I reckon correctly, those got some typos and are not full. 

 

Don't forget to check what your sofware is doing as well. For example, center-aligned I/O can be changed to edge-aligned by enabling RX & TX delays on the PHY through MDIO (for Marvell it is register 20 bits 7 and 1 if I remember correctly). So until you figure out what timing your design expects, you can't really constrain RGMII properly. 

 

Also, there must be some examples with dev kit for your board. Check them. 

 

P.S.: Oh, boy. I remember the frustration that I had when I was learning how to do that :))) My design was either not sending, not receiving, or both, or dropping packets randomly. Anyhow, it takes some time, a deep though, careful reading of some scattered documentation, and of course experimentation.
0 Kudos
Reply