Re: embedded gigabit ethernet


Bryan Hackney wrote:
> Steve at fivetrees wrote:
> > I have a new project coming up that calls for a data acquisition board (wot
> > I have to design) to deliver said data over ethernet at a minimum of
> > 6.25Mbytes/second (not including packetisation/checksum/TCP/protocol
> > overheads). I confess to some trepidation.

I, too, have been tasked with a similar project for work recently. I
need to be able to stream data that will be produced at a bandwidth in
excess of 200 Mb/s (from an A/D converter). This task is primarily a
transimssion task (minimal reception required; certainly nothing
high-speed on the reception side). Essentially, just grab the data,
packetize it up into a TCP packet, and dump it out ASAP. The other end
of the pipe can essentially be thought of as a top of the line PC with
oodles of RAM/disk storage to support the data coming in.

While still evaluating possibilities, my current plan is to use a
Virtex4 FX12 FPGA which has an embedded PowerPC core already in the
chip and an integrated tri-mode ethernet MAC hard core also integrated
into the chip. Xilinx also has their Gigabit System Reference Design
(can be found at:

http://www.xilinx.com/esp/wired/optical/xlnx_net/gsrd.htm

but it is currently setup to support only a few eval boards (and is a
bit much for what I am looking to do). However, Xilinx just released
something much closer to my ideal solution in the form of an app-note
called "Minimal Footprint Tri-Mode Ethernet MAC Processing Engine",
which can be found here:

http://direct.xilinx.com/bvdocs/appnotes/xapp807.pdf

This setup uses uIP, a scaled down TCP/IP stack by Adam Dunkels,
integrated to run on an UltraController 2 (which is essentially a
utilization of the PowerPC core in the Virtex4 that requires no
external memory; 16K of program memory and 16K of data memory in the
form of BRAM are utilized right on the FPGA fabric to hold code/data).
Anyway, the app note shows an example webserver running on the ML403
eval board. I am hoping to play with this over the next few weeks to
see what works and what doesn't work with this setup. I'll report back
new stuff as I find it.

> Please let me (us) know what you decide on. This is on the edge of experience
> for many if not all small systems developers. Thanks.

Yeah...there definitely isn't a ton of stuff out there right now for
references on gigE in embedded stuff. Hopefully this will change with
time (and requirements) change.

Regards,
John Orlando
www.jrobot.net

.

Relevant Pages

  • Re: Scaling noise
    ... >> of swift memory access and function calls, ... >> invalidation latencies. ... > doesnt have to bounce over ethernet in that kind of setup that Larry ... If I want to explicitly allocated shared space I can allocate it ...
    (Linux-Kernel)
  • [PATCH 2.6.17] Clean up and refactor i386 sub-architecture setup
    ... Clean up and refactor i386 sub-architecture setup. ... * Do NOT EVER look at the BIOS memory size location. ... * It does not work on many machines. ... pass the voyager BIOS/SUS info area to the detection ...
    (Linux-Kernel)
  • [x86 setup 32/33] Use the new x86 setup code for x86-64; unify with i386
    ... -# Set this if you want to pass append arguments to the zdisk/fdimage/isoimage kernel ... * and putting them into the appropriate places in system memory. ... -# Check signature at end of setup ... -# This routine checks that the keyboard command queue is empty ...
    (Linux-Kernel)
  • [x86 setup 32/33] Use the new x86 setup code for x86-64; unify with i386
    ... -# Set this if you want to pass append arguments to the zdisk/fdimage/isoimage kernel ... * and putting them into the appropriate places in system memory. ... -# Check signature at end of setup ... -# This routine checks that the keyboard command queue is empty ...
    (Linux-Kernel)