1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

Embedded Ethernet, looking for an efficient solution...

Discussion in 'Embedded' started by MM, Aug 18, 2004.

  1. MM

    MM Guest

    Hi all,

    I am a newbie in this, so please bear with me... I was asked to estimate
    various options of embedding Ethernet into our future board level products.
    Here is the list of some of the requirements:

    a) efficient interface to either a C64x or TigerSHARC DSP
    b) minimum of 100BaseT, potentially 1000BaseT
    c) dual Ethernet capability desirable
    d) protocol running on external processor; e.g.,
    - AMD Au1000 or Au1100
    - Motorola Coldfire MFC5470
    - other TBD
    e) support for TCP, UDP, HTTP required; other protocols desirable

    On one hand I am somewhat overwhelmed with the amount of information
    available, but on another hand I don't seem to be able to find answers to
    "simple" questions like the ones below:

    1. What data rate is achievable in practice with 100BaseT assuming there are
    only two nodes talking to each other?

    2. What CPU speed do I need to be able to support 2 100BaseT ports? In other
    words I am not sure whether some of the processors that have 2 100BaseT
    ports on-board can actually process packets quick enough to make efficient
    use of the theoretically available bandwidth...

    I will appreciate any input.

    Thanks,
    /Mikhail
     
    MM, Aug 18, 2004
    #1
    1. Advertisements

  2. MM

    romu Guest

    Hi you,
    About 80Mbits/s in Full Duplex mode.
    Depends on a number of things :

    - the speed and width of the bus connecting the Ethernet chip and the
    uC / DSP
    - the Ethernet chip itself (some can implement IP or even UDP / TCP in
    hardware, but you're tied to that particular stack)
    - the amount of RAM you can spend for the IP stack : larger buffers
    allow faster transfers (this is due to the TCP behaviour ; UDP is less
    sensitive)
    - the board architecture. Since network traffic handling involves
    large transfers of data between memory CPU AND ethernet chip, such
    things as a DMA controller can come handy.
    - CPU type and speed of course come in the bill.
    Perfectly right. A low-end PC with a standard PCI bus hardly handles a
    sustained 100MBits/s network traffic. Not to mention Gbits/s...

    romu
     
    romu, Aug 18, 2004
    #2
    1. Advertisements

  3. MM

    Richard Guest

    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.
     
    Richard, Aug 19, 2004
    #3
  4. MM

    MM Guest

    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
     
    MM, Aug 19, 2004
    #4
  5. MM

    Stephen Pelc Guest

    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.

    <AD>We have our PowerNet stack to sell</AD>

    Stephen

    --
    Stephen Pelc,
    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: http://www.mpeltd.demon.co.uk - free VFX Forth downloads
     
    Stephen Pelc, Aug 19, 2004
    #5
  6. MM

    MM Guest

    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
     
    MM, Aug 19, 2004
    #6
  7. MM

    Stephen Pelc Guest

    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
    www.mpeltd.demon.co.uk/powernet.htm
    for more details.

    Stephen
    --
    Stephen Pelc,
    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: http://www.mpeltd.demon.co.uk - free VFX Forth downloads
     
    Stephen Pelc, Aug 19, 2004
    #7
  8. MM

    Greg Neff Guest

    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:

    http://www.freescale.com/webapp/sps/site/homepage.jsp?nodeId=01DFTQJk19

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

    Greg Neff
    VP Engineering
    *Microsym* Computers Inc.
     
    Greg Neff, Aug 19, 2004
    #8
  9. MM

    Andrew Dyer Guest

    (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.
     
    Andrew Dyer, Aug 20, 2004
    #9
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.