Questions on ethernet (XE devices) and handing data reads Topic is solved
-
- XCore Addict
- Posts: 191
- Joined: Tue Jul 05, 2016 2:19 pm
Questions on ethernet (XE devices) and handing data reads
Hello!
For our current project we are using an XE216 on an eXplorerKIT.
We would like to implement USB, Ethernet, SPI, SSC and Audio sampling/compression.
Because the xcore doesnt have DMA, each communication interface needs a core to sample input data?
From what i understood, USB requires 2 cores (XUD, EP0) plus two cores to remain idle (correct?), SPI needs an additional core, SSC will probably be implemented on 3 cores (im a newbie so i dunno yet. Looking to go for an RX,TX,Manager setup I think). Audio sampling and processing (low quality mono audio) should be possible on a single core. Gigabit ethernet consumes 7+1 cores, for a total of 17 cores, plus application threads.
--> not enough ressources available on XE216.
For the target application, gigabit ethernet is not needed. 100 Mbit ethernet is sufficient. Is it possible to use a mii instead of an rgmii interface on xe216 devices/the eXplorerKIT (Id guess no, cause its two different interfaces)? Do you think theres a way of freeing ressources in this setup?
For our current project we are using an XE216 on an eXplorerKIT.
We would like to implement USB, Ethernet, SPI, SSC and Audio sampling/compression.
Because the xcore doesnt have DMA, each communication interface needs a core to sample input data?
From what i understood, USB requires 2 cores (XUD, EP0) plus two cores to remain idle (correct?), SPI needs an additional core, SSC will probably be implemented on 3 cores (im a newbie so i dunno yet. Looking to go for an RX,TX,Manager setup I think). Audio sampling and processing (low quality mono audio) should be possible on a single core. Gigabit ethernet consumes 7+1 cores, for a total of 17 cores, plus application threads.
--> not enough ressources available on XE216.
For the target application, gigabit ethernet is not needed. 100 Mbit ethernet is sufficient. Is it possible to use a mii instead of an rgmii interface on xe216 devices/the eXplorerKIT (Id guess no, cause its two different interfaces)? Do you think theres a way of freeing ressources in this setup?
View Solution
-
- XCore Addict
- Posts: 230
- Joined: Wed Mar 10, 2010 12:46 pm
Hi DemoniacMilk,
There are a few things that you could do, but they are clearly beyond what XMOS tests internally and therefore I can't guarantee they will work.
The first is that you could run the XUD as high priority to allow use of all of the 7 other cores on that tile. This Application Note describes how to do that.
The second is that you can restrict the RGMII interface to only run at 100Mbit which would limit it to a maximum of 5 cores. However, this would require modification of the sources in lib_ethernet.
You need to ensure that you only request 100MBit operation:
And then you'll need to replace all of the contents of the 'else' at line 215 of rgmii_ethernet_mac.xc with something like:
If you just do that you'll get 1 extra core. In order to get down to 5 cores you need to change:
to:
Hope that helps,
Peter
There are a few things that you could do, but they are clearly beyond what XMOS tests internally and therefore I can't guarantee they will work.
The first is that you could run the XUD as high priority to allow use of all of the 7 other cores on that tile. This Application Note describes how to do that.
The second is that you can restrict the RGMII interface to only run at 100Mbit which would limit it to
Code: Select all
using
You need to ensure that you only request 100MBit operation:
Code: Select all
smi_configure(smi, phy_address, LINK_100_MBPS_FULL_DUPLEX, SMI_ENABLE_AUTONEG);
Code: Select all
assert(0); // RGMII no longer supported.
Code: Select all
{
rgmii_buffer_manager(c_rx_to_manager[0], c_speed_change[3],
*p_used_buffers_rx_lp, *p_used_buffers_rx_hp, *p_free_buffers_rx, 0);
}
{
// Just wait for a change from 100Mb mode and empty those channels
c_speed_change[2] :> unsigned tmp;
c_speed_change[4] :> unsigned tmp;
}
Code: Select all
{
rgmii_buffer_manager(c_rx_to_manager[0], c_speed_change[3],
*p_used_buffers_rx_lp, *p_used_buffers_rx_hp, *p_free_buffers_rx, 0);
// Just wait for a change from 100Mb mode and empty those channels
c_speed_change[2] :> unsigned tmp;
c_speed_change[4] :> unsigned tmp;
}
Peter
-
- XCore Addict
- Posts: 230
- Joined: Wed Mar 10, 2010 12:46 pm
Thinking about it, you might need to use
instead of
in order to prevent it getting into gigabit mode.
Code: Select all
SMI_DISABLE_AUTONEG
Code: Select all
SMI_ENABLE_AUTONEG
-
- XCore Addict
- Posts: 191
- Joined: Tue Jul 05, 2016 2:19 pm
Hello Peter,
thank you for your awesome answer!
Ethernet is now running off 5 cores instead 7 and processes ICMP requests just fine! (although I dont understand how changing
affects the program).
I enabled high core priority in xud_(), is that a reasonable place to enable it in?
thank you for your awesome answer!
Ethernet is now running off 5 cores instead 7 and processes ICMP requests just fine! (although I dont understand how changing
Code: Select all
{
rgmii_buffer_manager(c_rx_to_manager[0], c_speed_change[3],
*p_used_buffers_rx_lp, *p_used_buffers_rx_hp, *p_free_buffers_rx, 0);
}
{
// Just wait for a change from 100Mb mode and empty those channels
c_speed_change[2] :> unsigned tmp;
c_speed_change[4] :> unsigned tmp;
}
I enabled high core priority in xud_(), is that a reasonable place to enable it in?
-
- XCore Addict
- Posts: 230
- Joined: Wed Mar 10, 2010 12:46 pm
The change in the ethernet is simply merging two parallel tasks into one. There was no need for them to be separate before, but since the RGMII was taking 7 cores there was also no need to change anything to reduce the core count for 10/100 ethernet case.
In terms of the USB, the place to do it is as the document says for the XUD_Manager task:
In terms of the USB, the place to do it is as the document says for the XUD_Manager task:
Next modify the file module_usb_audio\main.xc, as shown below :This configures the core running the XUD to high priority to ensure that it has enough MIPS to executeCode: Select all
/* USB Interface Core */ { set_core_high_priority_on(); #if (AUDIO_CLASS==2) XUD_Manager(c_xud_out, ENDPOINT_COUNT_OUT, c_xud_in, ENDPOINT_COUNT_IN, c_sof, epTypeTableOut, epTypeTableIn, p_usb_rst, clk, 1, XUD_SPEED_HS, XUD_PWR_CFG); #else XUD_Manager(c_xud_out, ENDPOINT_COUNT_OUT, c_xud_in, ENDPOINT_COUNT_IN, c_sof, epTypeTableOut, epTypeTableIn, p_usb_rst, clk, 1, XUD_SPEED_FS, XUD_PWR_CFG); #endif }
the USB interface. Setting this will allocate 100MIPS to the USB task, leaving 400MIPS to be shared equally
among the remaining tasks. It allows all remaining logical cores to be utilized. 400/7 = 57MIPS is
sufficient for all other functions within the reference design when running at up to 384KHz, with stereo
out.
-
- Experienced Member
- Posts: 75
- Joined: Sat May 07, 2016 11:47 am
Hello, I also wanted to reduce ethernet core usage, so I went and did what is written. However, I get the following error in console:
Code: Select all
xrun: Program received signal ET_ECALL, Application exception.
[Switching to tile[1] core[0]]
rgmii_ethernet_mac (i_rx_lp=@0x7fd94, i_tx_lp=<value optimized out>, c_rgmii_cfg=<value optimized out>, rgmii_ports=<value optimized out>) at C:/Users/MyUser/Documents/XTimeComposerStudio_Workspace3/lib_ethernet/src/rgmii_ethernet_mac.xc:227
227 assert(0); //RGMII No longer supported in this version
-
- Experienced Member
- Posts: 75
- Joined: Sat May 07, 2016 11:47 am
Update: Changing
to
worked.
Thanks for the helpful thread.
Code: Select all
rgmii_inband_status_t current_mode = INITIAL_MODE;
Code: Select all
rgmii_inband_status_t current_mode = INBAND_STATUS_100M_FULLDUPLEX_UP;
Thanks for the helpful thread.
-
- XCore Expert
- Posts: 580
- Joined: Thu Nov 26, 2015 11:47 pm
A note from my implementation.
1.
Seems to make more sense than an initial state of INBAND_STATUS_100M_FULLDUPLEX_UP, and it also works.
2.
I would recommend using
This appears to disable autonegotiation to gigabit but retains autonegotiation to 10/100. When I used SMI_DISABLE_AUTONEG I had to force the other end of the link to 100Mbps in order to get the connection to work (i.e. I couldn't leave the other end of the link in automatic mode, so SMI_DISABLE_AUTONEG is a little inconvenient for the end user).
Caveat is that so far I have tested the link with the following setup only: directly connected to a Mac that has a Gigabit, AVB capable NIC. It negotiates to 100 Mbps and my core usage in AVB mode is down from 8 to 6 on tile 1 of the xCORE-200 Multichannel Audio Platform 2v0
Like the OP I only need 100Mbps Ethernet, I don't need gigabit. So this leaves free cores for adding in some other features I am thinking about.
1.
Code: Select all
rgmii_inband_status_t current_mode = INBAND_STATUS_100M_FULLDUPLEX_DOWN;
2.
I would recommend using
Code: Select all
smi_configure(smi, phy_address, LINK_100_MBPS_FULL_DUPLEX, SMI_ENABLE_AUTONEG);
Caveat is that so far I have tested the link with the following setup only: directly connected to a Mac that has a Gigabit, AVB capable NIC. It negotiates to 100 Mbps and my core usage in AVB mode is down from 8 to 6 on tile 1 of the xCORE-200 Multichannel Audio Platform 2v0
Like the OP I only need 100Mbps Ethernet, I don't need gigabit. So this leaves free cores for adding in some other features I am thinking about.
-
- Active Member
- Posts: 39
- Joined: Mon Jan 05, 2015 12:58 am
Hello,
I have a problem modifying the contents of the 'else' at line 215 of rgmii_ethernet_mac.xc. Removing content of this declaration generates the following error:
Error: Undefined reference to '_Srgmii_buffer_manager_0'
The code is simply that:
else{assert(0);}
No problem with modifying other bits, but that one is the most important...
I have a problem modifying the contents of the 'else' at line 215 of rgmii_ethernet_mac.xc. Removing content of this declaration generates the following error:
Error: Undefined reference to '_Srgmii_buffer_manager_0'
The code is simply that:
else{assert(0);}
No problem with modifying other bits, but that one is the most important...
-
- XCore Expert
- Posts: 580
- Joined: Thu Nov 26, 2015 11:47 pm
As an update, it should be possible to combine rgmii_ethernet_rx_server and rgmii_ethernet_tx_server into a single task. That would reduce your core usage by one. I don't know if it will work in Gbps mode, so it might be possible in 100 Mbps mode only.