Dual RGMII - GbE AVB daisy chain?

Technical discussions around xCORE processors (e.g. xcore-200 & xcore.ai).
Post Reply
User avatar
akp
XCore Expert
Posts: 578
Joined: Thu Nov 26, 2015 11:47 pm

Dual RGMII - GbE AVB daisy chain?

Post by akp »

I see that some of the bigger xCORE-200 parts have dual RGMII. Knowing that, should it be possible to port the 100Mbps AVB daisy chain code to work with Gigabit Ethernet? That may permit daisy chaining with large channel counts. Specifically I am looking to achieve 64+ channels @ 48kHz on a daisy chain, which is beyond what is possible with 100Mbps Ethernet.

Since the RGMII interfaces are on different tiles I suppose I would be limited to about 250Mbps by the xCONNECT link between the two tiles? Still better than 100Mbps.

Further, are any dev boards coming out that support one of these chips with dual RGMII (i.e. for testing the daisy chain port)? Perhaps if it is possible to link together two of the XK-EVK-XE216 boards using 5 bit xCONNECT that might simulate the chip with dual RGMII, obviously I could make the wires pretty short to avoid noise errors on the xCONNECT link.

Read




User avatar
akp
XCore Expert
Posts: 578
Joined: Thu Nov 26, 2015 11:47 pm

Post by akp »

I got the following response to my question from infiniteimprobability:

In theory this is doable. However, there is a *lot* of work to get to this stage. Some thoughts..
- The 100Mb dual mac component relies on shared memory - each Gb mac would be on a seperate tile. So you will need to write a new self contained (connects to 2 x Gb macs) switch function to handle legacy traffic.
- 64Ch endpoint is not yet implemented, but should be feasible. 32ch is in app note 203 - https://download.xmos.com/XM-008708-AN-4.pdf. Getting to 48 is probably Ok with moderate work (possibly doubling/quadrupling up on TDM core + buffering resources and giving the cores 100MIPS + maybe some more optimsiation). 64ch may require quite a lot of hand crafting and possibly doubling up on talker / listener units. Some work had to be done on packetisation to get to 32ch even..
- You will definitely need a 4 tile device - XE232. xConnect performance should be higher than 250Mbps on chip (especially within the same xcore node), however 4 switch paths may be a restriction for the connections between blocks. Haven't fully checked this yet though..
It (single chip switch and 64 ch endoint) would certainly be a very elegant solution, but for an engineering effort (ie cost) point of view, it may be worth considering focussing on the 64ch endpoint along with an off the shelf Gbit AVB switch.
User avatar
akp
XCore Expert
Posts: 578
Joined: Thu Nov 26, 2015 11:47 pm

Post by akp »

Which leads me to the following question:

Excellent, thank you for responding. This is encouraging as a long term solution, and even better -- upon re-reading my question I realize I (accidentally) asked for something harder than I actually want.
What I want is a GbE daisy chain with (say) 4 devices, each of which would have 16 talker channels, to add up to 64 talker channels total (4 x 16). At one end of this daisy chain I would put in a GbE switch. For the sake of this discussion I don't need listeners.
From reading your response it seems that of the difficult things to do, implementing the 64 ch endpoint is the most difficult. Since I only am targetting 16ch per device at present, that part of the system seems "sorted".
Therefore, correct me if I'm wrong, the real difficulty remaining would be in splitting up the shared memory dual 100Mbps MAC / switch function to use xCONNECT with the GbE MACs on different tiles? What I mean is, the novel part is not the number of channels on the device, but integrating the GbE switch function.
At the end of the day this matters to me because I have both physical dimension and power consumption targets I hope to meet.

I thought this discussion might be interesting enough to bring to the forum in case other people are interested in making use of the new 4 tile devices as GbE switches.
will1979
Member
Posts: 12
Joined: Mon Oct 26, 2015 11:06 am

Post by will1979 »

A small correction to your first post

E.ch link in the 4-tile package runs close to 500 Mbit/s. So if you spread your traffic over two streaming channels (odd words one channel, even words the other channel), then you will get very close to line rate. You would still have two links for other traffic.
User avatar
akp
XCore Expert
Posts: 578
Joined: Thu Nov 26, 2015 11:47 pm

Post by akp »

will1979 wrote:A small correction to your first post

E.ch link in the 4-tile package runs close to 500 Mbit/s. So if you spread your traffic over two streaming channels (odd words one channel, even words the other channel), then you will get very close to line rate. You would still have two links for other traffic.
Thank you. That should mean the limiting factor won't be in the xCONNECT links.
User avatar
infiniteimprobability
XCore Legend
Posts: 1126
Joined: Thu May 27, 2010 10:08 am
Contact:

Post by infiniteimprobability »

Spammer bots are back! No, I don't want to buy an essay...

Anyhow, back to the plot.
Since I only am targetting 16ch per device at present, that part of the system seems "sorted".
Definitely - 16ch is no problems..
Therefore, correct me if I'm wrong, the real difficulty remaining would be in splitting up the shared memory dual 100Mbps MAC / switch function to use xCONNECT with the GbE MACs on different tiles? What I mean is, the novel part is not the number of channels on the device, but integrating the GbE switch function.
Yes, this is where the challenge lies. The Gbit MAC uses 95% of one tile, so the MACs will be on different tiles (different nodes even because only one RGMII per node of two tiles) - so everything has to be done using channels across two chips (the XE232 has two die in a MCM). The 100Mb dual MAC uses 7 cores so they can exist on the same tile = shared memory possible.

Also, doing anything useful at full line rate is going to be tough - The Gbit MAC does achieve full line rate Rx and Tx but it is right at the performance limit of the device. At 32b, you are receiving a long word at a rate of 31.25Mwords/second. Using full dual issue on a 62.5MHz core, thats 4 instructions! So implementing multiple filters/decisions in the switch fast path at full line rate etc. is not feasible. Hence why I was thinking that using Xmos as the endpoint along with an AVB gbit switch seemed a practical solution.
chmedly
New User
Posts: 3
Joined: Thu Nov 02, 2017 5:14 pm

Post by chmedly »

I'm curious if anyone has done anything with this concept in the years since this thread. I'm interested in a Gigabit daisy chain system working with 24 channels of 48Khz 32bit audio in each direction (all 24 channels per direction are one stream). It sounds like doing it all on one 4 tile device is a better idea than tying 2 dual tile devices.
Post Reply