XCore Exchange

Hi,
We are considering looking at what we could achieve with XMos logic on a network card.
Either a standalone device (controlled over IP), or a network interfacing with a host PC over PCIe.

We have a number of possible use cases where the logic is doing things like:
- protocol conversion (eg. UDP in, convert, UDP out)
- network monitoring
- network filtering
- session interuption if limits exceeded.

In all cases, latency between packet in / packet out, or between packet in / PCIe host message out is the critical factor.

Having done my final year project with Occam a couple of decades ago, I am very excited by the XMos concept, and would love to get involved.

Advice on the best way to approach this and the rough size of such a job would be gratefully received, and we consider a consulting contract if the discussion is too big.

Thanks,
Duncan.

PCI-e runs at very high speeds so its likely very difficult to interface with a xmos chip. Its better to use a FPGA or a DSP with a built in PCI-e interface(TI makes a lot of those). There is also the matter of writing drivers for it.

Having one xmos chip with two ethernet ports is a better solution(There is a xmos dev board with that even). But be prepared for quite a bit of software optimization if you want use full bandwidth of 100Mbit ethernet.

Thanks Berni,
The one chip two ethernet ports would work well.

I assume from your comment that we would not be able work at a higher network bandwidth than 100 Mbit Ethernet? Is this a matter of time before XMOS is able to run at these line speeds, or is XMOS simply not aimed at this sort of market.
As an example, I noticed that Solarflare had recently embedded an fpga into their 10GbE network card.

Thanks

The chip can transfer data at that speed easily (you get about four
instructions per data word, per thread that you have work on it). But
the lowest clockrate standard gigabit MII runs at 125MHz; the I/O
port pins on the XCore are only specced for 80MHz if I remember
correctly. Maybe there are some non-standard PHYs you can use?
Or even a full MAC with a dumb host bus.

If you find any, please let us know :-)

the XC-3 board (http://www.xmos.com/products/developmen ... d-tile-kit) is actually not bad for a protocol conversion task. you can get low latency, but only if you don't need to process the full 100mbit bandwidth. last time I tried, the sc_ethernet code was able to switch 100Mbit at wire speed from one to the other port (with bigger delay than a real switch, tough), but as soon as there was traffic in the other direction or you wanted to modify the packets during switching, it all just locked up.
Also keep in mind, that the two phys have to be connected to the same core (as it's he case on the XC-3), if you want efficient packet switching between them. So, for a protocol conversion task, you could also use just one port (e.g. the XC-2) and simply tag the outcoming packets with a certain VLAN ID and then a real switch could do the separation. That way you should have similar performance limitations as with dual ports (maybe even better latency), but need less hardware and processing resources.
Also it could be interesting to wait for the announced L2 with 700Mhz per core chips, they should improve the effective ethernet bandwidth usage with the current sc_ethernet code and also offer xscope debugging, which the G4s just don't support. (but they probably won't do Gbit any better, since the max. clocking speed at the pins wont change I guess) .

In some code/documentation repositories I saw hints, that XMOS did an internal gigabit ethernet demo board a while ago.
But it definitely used a CPLD to help with the GMII interface speed and I think it was written somewhere, that it could only handle 300Mbit. Just ask them directly for more information on that matter.

Hi,
Although I'm not yet experienced enough with 100Mbps Ethernet managed by an XCore to give grounded advices, I can share following experiences with GEth with you (thus confirming some earlier comments):
- GMII runs at 125 MHz: an XS1-L1 Port has max frequencies of 100 MHz (when based on internal ref clock) or 60 MHz (when using an external clock for inputs), so there is no hope for directly managing a GMII bus with current XCore Ports.
- There are plenty of very good FPGA/CPLD GEth controllers around; they'd allow you for implementing a larger data bus between the FPGA/CPLD and the XCore Port, thus reducing the operating frequency: a 32bits (instead of 8) broad bus would divide the freq by 4 resulting into a 31.25 MHz bus, which would become compatible to the XCore Port.
- Having an operating GEth interface is one thing; efficiently using it is another one. This requires a balanced architecture in terms of memory size, memory bandwidth / access time, computation power, ... I saw two GEth designs failing short because of too low performances due to memory, resulting into catastrophic GEth performances.
Hope it may help you.
BR
Alain