Embedded Ethernet, looking for an efficient solution...

A tall task for a newbie... good luck in your efforts; it's a big subject.

That's because "it depends". Like many things, there are a lot of factors that contribute to the efficiency. Under ideal circumstances it can be nearly 100Mbps each direction.

For example... big, small, or jumbo packets? IP or raw Ethernet? TCP or UDP? Crossover cable or switch ports? Cut-through switch or store & forward? Full or half duplex?

Another "it depends". 2 stats specific to network processors - packets/sec and bytes/sec. Packets/sec is more indicative of the processor's speed, where bytes/sec is more about bus width and transfer methods.

How much will you be doing with the packets? Are you an endpoint that calculates checksums, buffers TCP, etc. while running both ports at line rate, or are you a network router that shovels packets from port to port with little processing on them?

E.g., TCP endpoints can have a lot of overhead, particularly RAM, and especially on high-volume high-latency links (e.g., fast WAN links) where huge buffers are needed for max performance.

At the line rates you spec, you'll be looking at PCI or on-chip solutions. Requiring 2 on-chip Ethernets quickly narrows the playing field. And then there's the question of whether the Ethernet controller can perform at line rate, not to mention the TCP/IP stack you're likely to license.

Let's say half duplex TCP over a crossover cable...

Can I get this kind of benchmarking information for different processors from somewhere?

An endpoint. All the meaningful data processing is done by DSP, the network processor has to take data from the DSP and send it over to another node. I am hoping to have a DMA channel taking care of the inter-processor communication.

I would really like to avoid using PCI between the DSP and the network processor...

These are exactly the issues I am trying to clarify...

Thanks, /Mikhail

If you want a non-PCI solution with external MACs, then you are most likely to be looking at SMSC and Asix Ethernet controllers. We've used SMSC for years, and find them easy from the software point of view. We have not yet used the Asix parts.

If you want a CPU with two integrated 10/100 controllers, AFAIR there are a couple of ARM-based parts. These require much more software, since they all require DMA. However the throughput can be impressive.

Once you have the basic packet level drivers running, the real software adventure starts. Doing a port of a TCP/IP stack is a big job if you haven't done it before. Be prepared for a long learning curve, even if you are buying in the stack.

We have our PowerNet stack to sell

Stephen

-- Stephen Pelc, snipped-for-privacy@INVALID.mpeltd.demon.co.uk MicroProcessor Engineering Ltd - More Real, Less Time

133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: - free VFX Forth downloads

Could you please elaborate a little more on why more software will be needed for CPUs with integrated controllers?

I think I would prefer the controllers to be integrated, but there is this requirements of having a clear path to upgrading to the gigabit ethernet and AFAIK there are no mainstream processors with 2 gigabit ports on-board or are there?

Could you please explain why having embedded controllers would increase the throughput compared to the case with external controllers?

My job is to design the hardware :)

What can it run on? I understand that in theory it probably OS and CPU independent but what have you tested it on?

Thanks, /Mikhail

Because the integrated controllers do not typically have several full-sized Ethernet packet buffers, but rely on DMA to fill main memory, and on interrupts to manage the DMA chains/lists

Most external controllers will use a 16 bit memory bus, but the on-chip controllers use a 32 bit bus. I am of course assuming that you will use a 32 bit CPU. On-chip registers will be faster than off-chip peripherals.

We've ported it to: 68xxx, ARM/StrongARM, H8S, and Coldfire soon. The footprint for a complete system with multithreaded Telnet and web server (with CGI and ASP) is about 110 kb, including all drivers and the open interactive Forth system. It is being used for mass-spectrometers, PABXs, access control, and seismic data-logging among other applications.

It is designed to run native with the multi-tasker we ship with our compilers. No separate OS is required. See

for more details.

Stephen

-- Stephen Pelc, snipped-for-privacy@INVALID.mpeltd.demon.co.uk MicroProcessor Engineering Ltd - More Real, Less Time

133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: - free VFX Forth downloads

Take a look at Motorola, er, um, I mean 'Freescale'. We use PowerQUICC II processors with 10/100 Ethernet, but it looks like the newer PowerQuick II Pro (MPC83xx) and PowerQuick III (MPC85xx) processors have dual 10/100/1000 Ethernet.

These processors are PowerPC based and have separate RISC processors to manage the communications peripherals on the chip. They also have TDM interfaces suitable for serial links to DSPs, CODECs, framers, etc.

One of our customers runs Linux on one of our MPC82xx products, so you could probably do that too if you want.

Start here:

================================

Greg Neff VP Engineering

*Microsym* Computers Inc. snipped-for-privacy@guesswhichwordgoeshere.com

(I do a lot of MIPS stuff, so this is biased towards what I know, but I suspect the PPC and ARM worlds have similar stuff)

Is the gig-e requirement real or a marketing bullet item? Can your DSP generate enough data to really need it? If it's not real, you could probably get away with a 66 MHz PCI and PCI gig-e chips. Put in a decent CPU with PCI 66, interface it back to your DSP, smile and say "yes, of course it does gig-e ethernet"

A chip with a PCI-X interface like the NEC Vr7701 with an external PCI-X gig-e chip would be the next step up.

The parts with gig-e and the CPU on one chip tend to be a lot more expensive. Broadcom makes the BCM-112x and BCM-1250 parts with gigabit interfaces and PMC-Sierra has the Rm9000 series.

Another option would be to buy some IP for a gig-e controller, maybe a memory controller and put it into an FPGA with an on-board CPU like a xilinx v2pro.