Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
13 years ago

Triple Speed Ethernet - Lost packages, timing problem?

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 ms
Then, 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

1 Reply

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    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.