FPGA's for Ethernet?

Yes, we did some preliminary work for a customer using the opencores MAC and the LWIP stack. There were stability problems, and evidence pointed to the opencores MAC, rather than LWIP. In the end the customer went with a commercial adaptation of the MAC and IP stack, though they still weren't happy with the end results. Granted, they wanted SSL...

What bandwidth do you want out of it?

Regards,

--
Mark McDougall, Engineer
Virtual Logic Pty Ltd, 
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266

The Ethernet MACs are mostly commerically available and they're not free. Xilinx has its own Ethernet MAC and it's easy to integrate it into the MicroBlaze soft processor. I think whether choosing MAC+PHY chip or MAC(FPGA) + PHY chip is largely dependent on your budget. For mass production, MAC implemented inside FPGA seems a better choice and a shorter time-to-market can be expected.

If you simply want to add Ethernet to your embedded system, you may consider using microprocessors from Rabbit semiconductor, instead of FPGA. Although I do not using their chips, I believe it's the most direct and easiest solution to your post.

Good luck, JJ

"Todd" ??????: snipped-for-privacy@e64g2000cwd.googlegroups.com...

Hi Todd,

I've designed Ethernet MACs for a couple of clients, they're reasonably straightforward. The CRC is possibly the most complicated bit but there is VHDL code out there on the internet for that if you go looking.

I've also used the SMSC LAN91C111, it's a nice chip but I found it slightly awkward to use the buffer manager. If you design the MAC into your Fpga and use a PHY chip then you can design your own buffer manager, which I would recommend, as it gives you flexibility and more easily achieved higher performance should you need it.

Alan

Hi Todd,

I worked on a project doing Ethernet using Nios and a LAN91C111 a few years ago. The performance was quite disappointing (I forget which stack we were using but it wasn't "paid for"). Then again, that was a few years ago; this is now - and your requirements may vary. What exactly are you doing on the TCP/IP side? What wire speed are you targeting?

Yes, I'd say never assume that *any* company (and to be fair that includes the one I work for!) will continue to produce better and better products indefinitely. Most people prefer to hedge their bets and make their design as vendor-independent as possible, in case of nasty surprises.

Well, of course! :-) You could get yourself a Virtex-4 FX12 part with an integrated 400MHz PowerPC 405 processor and two hard-macro 10/100/1000 Ethernet MAC blocks, all in a decent-sized FPGA with 32 XtremeDSP slices to implement your DSP algorithms.

For gigabit ethernet, you might consider the low-cost LatticeECP2M FPGA, which has 3.125Gbps SERDES and advanced DSP blocks built in.

In addition, for a 32-bit soft processor, check out the LatticeMico32, which is open source and free.

Hope this helps, Bart Borosky, Lattice

I have used the LAN91C111 in the past with an Altera chip and isn't a bad solution if you don't want high performance. LAN91C111 isn't a cheap chip from my experience so watch out if you are cost sensative. There isn't much choice in stand alone non-PCI chips so if you want much choice with a stand alone then you might consider implementing a PCI host interface. For a cost sensitive volume production item it is hard to beat a low cost PCI Ethernet chip on cost but off course you need to add the cost of the PCI interface in the FPGA.

For a FPGA MAC solution there is a choice from all the vendors and not a lot to choose between. FPGA MACs can be quite large and tend to need a larger end device to support them so do examine the core datasheet before committing to this approach. There some technical advantages as other posts have mentioned.

A nice Xilinx alternative if you are not penny pinching is the Virtex-4 FX12. We have put this in a very compact processor system with a pile of other sexy things and I was well impressed. Something like it might make our product line one of these days. Depending on your pricing it can be actually reasonably close in cost to a low cost FPGA + non-PCI Ethernet chip. This chip has dual channel 10/100/1000 capability and if you find it useful an embedded PowerPC as well.

John Adair Enterpo> Hi all

We used the STMicroelectronics STE100P PHY.

Regards,

--
Mark McDougall, Engineer
Virtual Logic Pty Ltd, 
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266

Todd,

I have tried a lot of solutions...

1) Using the opencores core embedded inside Altera (Cyclone I) with NIOS and a purchsed stack. The preformance was dreadful. Now, this was about 5 years ago now, so things must be better. The fastest we could ever get the pig to sustain was something around 20 mbits/second.

2) External PCI-based chip with a PCI bridge implemented in the FPGA using embedded Linux. This was a real fast and "sexy" solution. We were seeing sustained rates around 78 mbits/sec.

3) Virtex 4 with the embedded hard core macro using embedded Linux. Sweet, but we had to write a driver. Performance was awsome but it took a while to get working due to the software writing exercise.

4) We used an external Ethernet to USB adaptor (bought at Fry's) with a Linux driver. Then we stuck a USB core in the Xilinx and ran embedded Linux. This was done to prove that we didn't need PCI (solution 2). The nice part about this solution was the guaranteed bandwidth allocation.

5) We used the Rabbit silicon as well. It was real nice - the crap just worked with no fuss.

As for the interconnect with the DSP ... I would ask if the algorithms can be implemented in the FPGA's directly. I am not a DSP expert, but both Xilinx and Altera are winning a lot of traditional DSP designs these days. The DSP guys that I know all love the FPGA's.

As for chosing a vendor - they both have workable solutions. If you have a good FAE supporting you for Altera - stick with them. I have done several SOC-type designs from each family and every single one of them had "wierd" problems related to the tools - without good support I'd have been dead meat. Just glance at all the compiler/fitter/mapper problems posted here. As much as they try for it not to happen ... we end up holding the bag.

Trevor