Open (functional!) core for Ethernet / VHDL for Ethernet - Spartan 6?

[Kremmen]

Hi, my turn to pose a tough nut - at least for me. For an upcoming project i am looking for alternatives for connecting to Ethernet from a motion control system. One alternative is to use a FPGA and it would have to be a Xilinx Spartan 6. I am not about to sell the house to license a Xilinx core for this so the question is, if any open alternatives exist. While Google has come up with something, the definitive solution escapes me still. I would only need a relatively basic implementation supporting the basic stack and IP, TCP but nothing more - well possibly ping but that's it.

All pointers / hints gratefully accepted. A generic solution or one tailored for a different environment would be good info, because i am prepared to do necessary modifications, just don't have the time to start from scratch.

[AndyC_772]

Another option is to use a microcontroller that includes an Ethernet interface, and for which an IP stack is freely available. If I recall correctly, Microchip have one that you can use on a PIC32 platform.

Doing it in an FPGA is certainly possible, but probably more time consuming than you'd like. I've done the RMII bit myself, and although it's not "difficult" as such, it does mean spending rather a lot of time doing stuff at a very low level that's already been done many times before in other devices.

[Balaur]

I have some (i.e. not extensive) experience on this, so please take my comments as is.

In early 2003, I had to design a system around a FPGA with some kind of Ethernet connectivity. After a lot of considerations, I've choose something like this.

The choice was motivated by many factors, including cost and availability of user-friendly Ethernet solutions (not that many at the time). There was significant effort in developing and especially validating the firmware, which was rather complex. We manufacture several tens of such devices and they are still in usage right now.

Then, I helped designing a FPGA-only system where the Ethernet connectivity consists in a Xilinx Virtex 4 with embedded PowerPC CPUs and a Linux OS, eventually complemented by a off-the-shelf Ethernet PHY device.

The practical learning of all this is that if you don't want/cannot spend a lot of effort by starting from scratch. You need a fairly good base that usually consists in a CPU, an OS with UDP and TCP/IP capabilities and so on.
Frankly, I cannot see how you can go halfway/basic with the transport layer (TCP/IP or UDP let's say) stuff. It's relatively complex and a custom implementation is bound to encounter problems when connecting to a reasonable-sized network or when transiting through the first hub or switch.

From my perspective, it's not reasonable to start from scratch. It's much more efficient to start with an existing solution, for both technical and cost considerations.
A single-board computer (starting from USD 25) will most likely offer the features, quality and performances you'll need. Use GPIOs to get out of the CPU.
Or choose a FPGA device and a PHY chip; I think that some Ethernet solutions licenses are free in some cases. You will still need a CPU and an OS. It's usually my second preference as it may restrict the implementation choices and will certainly make you spend some time to understand if the licenses you need for your particular eth>cpu>os combination is free or affordable.

Best regards,
Dan

[Kremmen]

Thanks guys. It is exactly these points that prompted me to ask after an already functional implementation. I don't have the time to do the low level stuff from scratch, nor the motivation, frankly.
Also, my plans do not include a soft processor in the FPGA which raises the bar still more. My requirements as to the Ethernet functionality are not complex - this will not be a general purpose Ethernet host, but rather a purpose oriented device running in a dedicated network segment.

The alternative and indeed possibly the first choice is to run Ethernet in a regular microcontroller, because there will be one - an ARM or a 32 bit Atmel. It is just that this is a distributed system and the early system design is in progress. I have yet to fix the hardware platform for each interface.

[poorchava]

How about WizNET W5100 IC? For ~$9 in singles and half of that @1kpcs you get MAC+PHY with integrated protocol stack supporting TCP, UDP, IPv4, ICMP, ARP, IGMP and PPPoE. It has 3 different interfaces including parallel 'direct bus interface' to simple SPI.

I'd say it's worth its  price considering how much time (=money) you would have to spend to implement all that in an FPGA.

[free_electron]

Get an stm32 with built-in ethernet. Use the mikro-e compiler. They give you the entire stack for free. Compiler costs 200$.... No runtime fees (important to know!  A lot of stacks require a runtime fee.. Cmx, micrium etc )
Problem solved.

[nctnico]

Another route is Freertos which runs on almost any microcontroller. Several microcontroller vendors took care of the license fees of an ethernet stack so if you buy their devices, you already have a license.

[Kremmen]

The thing with the processor solution is that if i do the Ethernet there, it needs to coexist with lots of other stuff. So the processor is not only for Ethernet.
FreeRTOS is an old friend and my RTOS of choice; i have done several projects with it. It was in the plans for this project as well. For me the most familiar chip would be an Atmel UC3C that supports Ethernet. The good thing is that the toolchain is free and familiar with no restrictions and i already have much of the code needed for this application. So unless any serious altermnatives emerge on the FPGA side, that will be my Plan A.

[mrflibble]

Depends on the datarate. If you need only 10 or 100 MBit I would go the microcontroller route.

Low IP cost on the fpga usually means <insert plenty of development time here/>. If you only need UDP then for the stack side of it you can get away with a fairly simple FSM, assuming an external PHY. But if you want a full tcp/ip stack you'll need either a softcore or aspirin. Since you say you don't have lots of time to spend on it, and don't even mention a datarate which henceforth shall assumed to be low, mcu it is.

And if you do find a cheap solution for a full tcp/ip stack on spartan-6, please post details.

[Kremmen]

Definitely no more than 100 Mb needed, even 10 would do it but i'm targeting 100 - for no specific reason.
Looks like it will be more trouble than it's worth to try the FPGA route. Oh well, maybe it was a long shot anyway and i don't think the project will actually suffer from doing the network bit in an MCU.
At this point i don't have high hopes of actually finding a worthwhile free implementation for a FPGA. But if miracles happen, i'll be sure to let you know.

[Smokey]

Is there anything on OpenCores you could use?
http://opencores.org/projects

[mrflibble]

You mean as counter examples for good design? Sure thing!

[joelby]

Designing a general purpose TCP implementation in HDL is a bit tricky. UDP is much easier though. For a design that works on a Spartan-6 with the 88E1111 MAC at 1000 Mbps (only), have a look at http://tristesse.org/FPGA/DigilentAtlysResources .

[Kremmen]

Thanks, for some reason i missed this. The 1Gb only could be a showstopper because the actual network may be incapable, but perhaps it can be modified. We'll see.

[marshallh]

Forget about full network on FPGA unless you are an HDL god or have money/time to blow getting the POS jokes on opencores to work.

Recommend using a MCU with 10/100 built in and cooking up a simple bus to communicate between the mcu/fpga.

[Kremmen]

Forget about full network on FPGA unless you are an HDL god or have money/time to blow getting the POS jokes on opencores to work.

Recommend using a MCU with 10/100 built in and cooking up a simple bus to communicate between the mcu/fpga.

Its starting to look more and more like a pointless tour de force to do in the FPGA. No functional solutions seem to be freely available. Opencores is mostly a joke and the licensed cores cost an arm and a leg. While i can hold my own in VHDL, a full Ethernet stack is the opposite of trivial to start from scratch, not an option really because Ethernet is not the point of the project, just a tool to move data.

[codeboy2k]

seconded, the MCU with built in ethernet.

One approach would be to make a memory mapped interface between the MCU and the FPGA if you can, i.e. the MCU looks like memory to the FPGA, or the FPGA looks like memory to the MCU.  There are some MCU's with built in Ethernet that already have an interface that can talk to SRAM, so you can use that to communicate to your FPGA's BRAM and send buffers of data, using mailboxes in the BRAM to indicate status, data ready, etc, plus some external GPIO and interrupt pins

Some MCU's can use one of their built in DMA controllers to communicate to the FPGA as well.

my point being, choose an MCU with either a built in SRAM controller, or one that has enough hardware DMA. This will make interfacing the MCU and FPGA much easier without sacrificing bandwidth by using a simple SPI or USART or I2C interface.

[nctnico]

Forget about full network on FPGA unless you are an HDL god or have money/time to blow getting the POS jokes on opencores to work.

Recommend using a MCU with 10/100 built in and cooking up a simple bus to communicate between the mcu/fpga.

Its starting to look more and more like a pointless tour de force to do in the FPGA. No functional solutions seem to be freely available. Opencores is mostly a joke and the licensed cores cost an arm and a leg. While i can hold my own in VHDL, a full Ethernet stack is the opposite of trivial to start from scratch, not an option really because Ethernet is not the point of the project, just a tool to move data.

IMHO the designs on Opencores aren't the best but some are usefull. You just need to check the code a bit to see if the author knows what he/she is doing.

[joelby]

Thanks, for some reason i missed this. The 1Gb only could be a showstopper because the actual network may be incapable, but perhaps it can be modified. We'll see.

Yep, I don't think it'd be too tricky to modify it to 100 Mbps (only). The MAC in my implementation was taken from the USRP project. In its original form it was not documented at all (and unfortunately my example implementation currently only does a tiny bit to mitigate this) but the code is reasonably straightforward, if a little overcomplicated.

[Kremmen]

seconded, the MCU with built in ethernet.

One approach would be to make a memory mapped interface between the MCU and the FPGA if you can, i.e. the MCU looks like memory to the FPGA, or the FPGA looks like memory to the MCU.  There are some MCU's with built in Ethernet that already have an interface that can talk to SRAM, so you can use that to communicate to your FPGA's BRAM and send buffers of data, using mailboxes in the BRAM to indicate status, data ready, etc, plus some external GPIO and interrupt pins

Some MCU's can use one of their built in DMA controllers to communicate to the FPGA as well.

my point being, choose an MCU with either a built in SRAM controller, or one that has enough hardware DMA. This will make interfacing the MCU and FPGA much easier without sacrificing bandwidth by using a simple SPI or USART or I2C interface.

Yes, i have to decide soon(ish) and although the FPGA route may not be a totally lost cause, i guess it will be for another day.

My MCU of choice would be the Atmel UC3C due to a number of factors:
- first and foremost, it is a familiar chip,
- the toolchain is free and open (gcc), with an out-of-the box functional IDE. And it supports C++ (don't want to use anything else)
- built-in Ethernet MAC
- built-in high speed external bus interface
- separate dedicated memory and peripheral DMA controllers
- hardware assisted peripheral event controller and bus (and i know how to use it)
- hardware floating point unit (must have this)
- a shitload of other peripherals, many of which i will need

Alternative candidates would be ARMs, most likely Cortex M4F that would have many of the same features. If only they had similarly easy and uncrippled toolchains available. I know you can roll your own and i am looking into it. Just noted i have a couple of Stellaris Launchpads sitting on the shelf unused. Maybe take a look into those. Then there is the STM32 and i have heard NXP makes some credible ARMs as well.

[TheDirty]

Somebody already mentioned using one of the Wiznet chips, but there was no response to this.  It seems like a perfect solution.  W5200 or W5100.  It's been a few years since I worked with them, so I don't know the updates.

[Kremmen]

Those Wiznet chips actually look quite interesting. I will have to take a more detailed look into the MCU interface, but it looks like the controller contains at least all that is needed here. Since the Atmel MCU already comes with a MAC, the choice is between using the Wiznet chip or e.g. a TI DP83848I PHY transceiver and a software stack. The LwIP is directly supported in Atmel Software Framework. Using the MCU MAC + SW stack will result in a "true" TCP/IP interface to the app SW. The Wiznet chip provides a SPI interface and i will have to check what kind of data structures it carries over that link. Could be a tough choice. Sure, the Wiznet chip is 4 times the price of the lowest cost Micrel alternative, but maybe that is not a showstopper in a short production run.

[nctnico]

Alternative candidates would be ARMs, most likely Cortex M4F that would have many of the same features. If only they had similarly easy and uncrippled toolchains available. I know you can roll your own and i am looking into it. Just noted i have a couple of Stellaris Launchpads sitting on the shelf unused. Maybe take a look into those. Then there is the STM32 and i have heard NXP makes some credible ARMs as well.

Codesourcery lite for ARM is free and has no limitations. It is the full blow GCC (and binutils). Any IDE which knows how to drive GCC can be used as a front-end.

[Kremmen]

Actually, i am just in the process of looking into that. Sourcery installed with little problems, now it is just to persuade Eclipse to play along...

[Scrts]

OpenCores has 10/100Mbps MAC, which works on Altera FPGAs. You can also consider choosing new FPGA with Ethernet MAC already built-in. Or if You only need some basic data transmission (e.g. using fixed length packets and UDP protocol), then it is not so hard to write Your own MAC. The hardest part will be CRC32, but it is already available in VHDL on the internet.

[Kremmen]

My choice of FPGA is already included in the topic. It would be too heavy to change toolchains at this stage so a Spartan it has to be. Also i already made the decision to use the MCU for Ethernet because there is no compelling reason to use the FPGA and it appears to be an order of magnitude harder to do it there without spendig a lot of cash on licensed IP.
I am now in the process of designing the MCU-FPGA interface based on external bus connection, so any brilliant ideas there are welcome. The MCU is Atmel AT32UC3C due to the simple fact that i have a complete functional toolchain for it, at it should manage the requirements handily.

[gxti]

The milkymist project has a 100mbit mac that works on Spartan 6. It's also used in the OpenRISC SOC project (orpsoc), which I successfully ran on a Digilent Atlys. Would have been flawless if not for a software issue -- the kernel driver did not instruct the PHY to negotiate at 100mbit and it negotiated gigabit by default, which of course doesn't work on a 100mbit mac. For lack of skill I just configured the switch to force 100mbit and everything was great.

As for how hard it will be to interface with the MAC without a CPU, I can't really help you there. Should be easier than talking directly to a PHY, I would hope.

[Kremmen]

You need to compare the implementation complexity of the FPGA based solution with the complexity of the same thing done in an MCU. The UC3 chip i have selected has a regular MII interface to a PHY, in this case either Micrel or TI device. The MCU implements the MAC in hardware and microcode of whatever you want to call that part. What remains is to insert the rest of the stack and that i will do using LwIP. It even seems to be part of the Atmel SW framework.
LwIP offers the functionality i need, i.e. reliable transport on the TCP level, using an easy call interface.
Based on my search and this thread, FPGAs don't come close to offering the same level in anything that is free or open.

[nctnico]

@Kremmen: A quick question did you ever use uIP? If yes, how does that compare to lwIP? I have used uIP but I did had to fix several bugs.

[Kremmen]

Sorry, no I never have. Also, as to LwIP i have used it for relatively basic TCP/IP things as far as networking goes, because my main interest is not the networking part. I only need that for high throughput data streaming between a master and slave devices in motion control systems. So i have only exercised a small subset of the whole functionality of the implementation.

[webphyfpga]

You can download a free demo of the WebPHY DATABUS IP Core from here:
http://www.webphyfpga.com

The IP core can send and receive data between a FPGA and web client over Ethernet using its web-based "rd" and "wr" commands.  The core also has a user-customizable web page allowing browser-based control of the FPGA.  The core connects to Ethernet via standard LVDS-configured IOBs on the FPGA.  No external PHY or DDR/Flash memory chips, software TCP stack or embedded CPU are required - everything is contained within the core.

[Kremmen]

Thanks for the info. While the website looks interesting it appears to target somewhat different use cases from mine. Anyway, that project is already done and the net part works under a MCU. But maybe for another project on another day...

[legacy]

i am thinking about buying a C8900 (Cirrus Logic) Ethernet board from Olimex (parallel interface), see their Ethernet modules, they also have ENC (SPI interface) by Microchip.

[Scrts]

Is there anything on OpenCores you could use?
http://opencores.org/projects

The 10/100 MAC for Altera Avalon bus from OpenCores is proven to work. I think it's even in Altera Wiki page.