Hi to all,
i´ve tried to get a simple ethernet applicaton run! I want to send data from one node to the other and backwards. At MDI side there is a Gigabit Link. But when i sent data on RGMII there is only a 25 MHz TXCLK! From PHY side there comes a 125 MHZ RXCLK. So now my question is, how can i setup the controller to 125 MHz? I´am using the XMOS XEF216-512-TQ128. The board is an own design.
So if you have some experience with Gigabit and XMOS, please let me know!
By the way: I´ve tried this application on xcore-200 explorer board. It´s the AN00199. I´ve just changed the ICMP server to tx_task and rx_task...
best regards Seb
XMOS Gigabit Ethernet TXCLK Problem
-
- Junior Member
- Posts: 6
- Joined: Mon May 02, 2016 6:54 am
-
Verified
- Respected Member
- Posts: 347
- Joined: Wed Jan 27, 2016 5:21 pm
Hi Seb,
Just checking - you do keep RXCLK pulled low during reset?
(keeping the PHY in reset).
Also - it may be helpful to know which PHY you are using.
Cheers,
Henk
Just checking - you do keep RXCLK pulled low during reset?
(keeping the PHY in reset).
Also - it may be helpful to know which PHY you are using.
Cheers,
Henk
-
- Junior Member
- Posts: 6
- Joined: Mon May 02, 2016 6:54 am
Hi Henk,
this is a new PHY under NDA. So i can´t specify this!
RXCLK is pulled low during reset....
I´ve found out, that the PHY doesn´t support IN BAND STATUS. But from my understanding, the Ethernet MAC works with this information and setup the TXCLK according to this!
So I tried to set
rgmii_inband_status_t current_mode = INBAND_STATUS_1G_FULLDUPLEX_UP; //INITIAL_MODE;
This has the effect that TxClk is 125 MHz. But when I send data, i can see txclk on txd0 and txd 3. txd1&txd2 seem to work well! Is there a possibility to work without IN_BAND_STATUS???
Seb
this is a new PHY under NDA. So i can´t specify this!
RXCLK is pulled low during reset....
I´ve found out, that the PHY doesn´t support IN BAND STATUS. But from my understanding, the Ethernet MAC works with this information and setup the TXCLK according to this!
So I tried to set
rgmii_inband_status_t current_mode = INBAND_STATUS_1G_FULLDUPLEX_UP; //INITIAL_MODE;
This has the effect that TxClk is 125 MHz. But when I send data, i can see txclk on txd0 and txd 3. txd1&txd2 seem to work well! Is there a possibility to work without IN_BAND_STATUS???
Seb
-
Verified
- Respected Member
- Posts: 347
- Joined: Wed Jan 27, 2016 5:21 pm
Hi Seb,
Indeed it does; that is a good start.
I don't know if the RGMII library supports disabling in-band status natively; but it should be quite easy to remove it. Just remove any code that checks the state and changes the state; I will see if somebody can point you in the right direction.
When you say you see TX_CLK on TXD0 and TXD3; could you send a picture of the signals that you observe? Given that all signals (TXCLK and TXD*) run at 125 MHz equivalent, the clock on TXD0 and TXD3 means that the RGMII layer is transmitting bytes 0b0xx01xx1 or something like that. What do you see on TX_CTL? Is that low or high?
Cheers,
Henk
Indeed it does; that is a good start.
I don't know if the RGMII library supports disabling in-band status natively; but it should be quite easy to remove it. Just remove any code that checks the state and changes the state; I will see if somebody can point you in the right direction.
When you say you see TX_CLK on TXD0 and TXD3; could you send a picture of the signals that you observe? Given that all signals (TXCLK and TXD*) run at 125 MHz equivalent, the clock on TXD0 and TXD3 means that the RGMII layer is transmitting bytes 0b0xx01xx1 or something like that. What do you see on TX_CTL? Is that low or high?
Cheers,
Henk
-
- XCore Addict
- Posts: 230
- Joined: Wed Mar 10, 2010 12:46 pm
Hi Seb,
It should be relatively straight-forward to disable the INBAND status notification. If you look in rgmii_buffering.xc, there is a function called get_current_rgmii_mode() which is called periodically to determine whether the INBAND status has changed. You can disable this many different ways, but the best is probably to comment out the following code (lines 472-481 in my version of rgmii_buffering.xc):
Regards,
Peter
It should be relatively straight-forward to disable the INBAND status notification. If you look in rgmii_buffering.xc, there is a function called get_current_rgmii_mode() which is called periodically to determine whether the INBAND status has changed. You can disable this many different ways, but the best is probably to comment out the following code (lines 472-481 in my version of rgmii_buffering.xc):
Code: Select all
case tmr when timerafter(t) :> t:
rgmii_inband_status_t new_mode = get_current_rgmii_mode(p_rxd_interframe, current_mode, speed_change_ids);
if (new_mode != current_mode) {
current_mode = new_mode;
done = 1;
}
t += rgmii_mode_poll_period_ms * XS1_TIMER_KHZ;
break;
Peter
-
- Junior Member
- Posts: 6
- Joined: Mon May 02, 2016 6:54 am
Hi peter,
with this method i´am able to perform a 125MHz TX_clk. I can send gigabit-data with the XMOS and receive them with another Controller! But when I send with XMOS to another XMOS, i can´t receive the data. Do you know which timing mode the MAC expects? RXD valid with edge RX_clk or RXD valid when RX_CLK is stabile?
By the way, are there some software settings to disable MAC_Address filters?
regards seb
with this method i´am able to perform a 125MHz TX_clk. I can send gigabit-data with the XMOS and receive them with another Controller! But when I send with XMOS to another XMOS, i can´t receive the data. Do you know which timing mode the MAC expects? RXD valid with edge RX_clk or RXD valid when RX_CLK is stabile?
By the way, are there some software settings to disable MAC_Address filters?
regards seb
-
- XCore Addict
- Posts: 230
- Joined: Wed Mar 10, 2010 12:46 pm
Hi Seb,
That is strange that you can't connect XMOS TX to RX, I'll take a look as to whether I see the same.
In order to disable the MAC address filtering, the simplest is to return -1 (0xffffffff) from the ethernet_do_filtering() function in macaddr_filter.xc. That means that no packets will be filtered.
Peter
That is strange that you can't connect XMOS TX to RX, I'll take a look as to whether I see the same.
In order to disable the MAC address filtering, the simplest is to return -1 (0xffffffff) from the ethernet_do_filtering() function in macaddr_filter.xc. That means that no packets will be filtered.
Peter
-
- Junior Member
- Posts: 6
- Joined: Mon May 02, 2016 6:54 am
Hi Peter,
i´ve found the problem!
in main rgmii_ethernet_mac_config and rgmii_ethernet_mac were defined to run on different tiles!
So running both tasks on tile 1 solved the problem. But I´am a bit confused about signals on RGMII TX lines. As i mentioned this effect in a previous post, i see the 125 MHz clock signal on TXD0-TXD3 in "Idle" phase (attached "TXD.jpg") Did you see this before?
i´ve found the problem!
in main rgmii_ethernet_mac_config and rgmii_ethernet_mac were defined to run on different tiles!
Code: Select all
on tile[0].core[0]: rgmii_ethernet_mac_config...
on tile[1] : rgmii_ethernet_mac...
You do not have the required permissions to view the files attached to this post.
-
Verified
- Respected Member
- Posts: 347
- Joined: Wed Jan 27, 2016 5:21 pm
Hi,
does the pin wiggling happen before the ports are initialised?
Ie, after the RGMII is enabled, but before port 8B is initialised as an output port?
Or is this during every idle phase?
Is TX_DV low?
Cheers,
Henk
does the pin wiggling happen before the ports are initialised?
Ie, after the RGMII is enabled, but before port 8B is initialised as an output port?
Or is this during every idle phase?
Is TX_DV low?
Cheers,
Henk
-
- Junior Member
- Posts: 6
- Joined: Mon May 02, 2016 6:54 am
Hi Henk,
it´s during every idle phase and TX_DV is low!
seb
it´s during every idle phase and TX_DV is low!
seb