Small job - Advice on network solutions

Have a job you want to post? Freelance? New employee needed for your own company? Post it here for all to see!
mrdunky
New User
Posts: 3
Joined: Fri Jul 13, 2012 12:46 am

Small job - Advice on network solutions

Postby mrdunky » Fri Jul 13, 2012 1:32 am

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.
User avatar
Berni
Respected Member
Posts: 363
Joined: Thu Dec 10, 2009 10:17 pm
Contact:

Postby Berni » Sat Jul 14, 2012 10:55 am

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.
mrdunky
New User
Posts: 3
Joined: Fri Jul 13, 2012 12:46 am

Postby mrdunky » Fri Jul 27, 2012 1:22 pm

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
User avatar
segher
XCore Expert
Posts: 843
Joined: Sun Jul 11, 2010 1:31 am
Contact:

Postby segher » Fri Jul 27, 2012 3:13 pm

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 :-)
ozel
Member++
Posts: 24
Joined: Wed Sep 08, 2010 10:16 am

Postby ozel » Sat Jul 28, 2012 12:12 pm

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.
User avatar
Allein
Member
Posts: 12
Joined: Wed Apr 04, 2012 5:48 pm
Contact:

Postby Allein » Sun Jul 29, 2012 9:45 am

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

Return to “Jobs”

Who is online

Users browsing this forum: No registered users and 2 guests