FPGA Gigabit Ethernet Interface Chip

[beetlejuice]

I have a board which is using a lattice FPGA combined with a Davicom DM9000 ethernet controller. The DM9000 chip contains the MAC and PHY and has a 16bit interface to the FPGA. This all works great.
I'm now needing to up the speed and have been looking for a similar Gigabit ethernet chip with integrated MAC/PHY and a parallel interface, but I can't find anything anywhere!
Can anyone suggest such a device, or event a pair of chips (separate MAC and PHY) that I can interface to with a 16bit parallel bus ?

 

[KlausST]

Hi,

Sorry, I can't help with 16 bit parallel interface.

But there are modern and cheap chips with MII interface. Maybe this is an alternative.

Kaus

 

[FvM]

As far I'm aware of, Gigabit PHY are exclusively using GMII (8 data bits SDR) and RGMII (4 data bits DDR) MAC interface.

 

[dpaul]

I have worked with Ethernet designs where the MAC soft IP core always resides inside the FPGA and the PHY is on-board.
As suggested in the above post, the MAC and PHY interface can be GMII or RGMII (there are also others). An advantage of such design is that you are saving FPGA I/O pins.

I'm now needing to up the speed and have been looking for a similar Gigabit ethernet chip with integrated MAC/PHY and a parallel interface, but I can't find anything anywhere!

How exactly do you want to speed up or what bottleneck do you currently observe?
Ethernet frames are byte oriented, so when the chip with MAC core outputs data using a 16 bit parallel bus, I am assuming that it is delivering 2 bytes of a frame in 1 clock cycle.
The Gigabit MAC cores sold by FPGA vendors (I have the Xilinx TEMAC core in mind) works at 125MHz and outputs 1 byte per clock cycle using the AXI-Stream protocol.

 

[beetlejuice]

Thanks both for your replies.

I have come across Ethenet Phy devices with a RGMII interface. This interface would be acceptable, but what concerns me is having to implement the MAC part of the design in the FPGA. It seems like a complicated task.
I'm currently trying to research what's involved in the MAC. If you have any pointers to a "minimum" Gigabit ethernet MAC implementation that would be a great help. The FPGA device only ever connects on a pier to pier network with fixed IP address, so maybe this simplifies the design of the MAC?

 

[dpaul]

I'm currently trying to research what's involved in the MAC. If you have any pointers to a "minimum" Gigabit ethernet MAC implementation that would be a great help. The FPGA device only ever connects on a pier to pier network with fixed IP address, so maybe this simplifies the design of the MAC?

For an evaluation work I can suggest the Xilinx TEMAC IP core if you are in to Xilinx FPGAs. Other FPGA vendors should also have their MAC core.
For the Xilinx TEMAC core, you have the PG051 documentation. It might look overwhelming in the beginning but the trick is to focus only on the parts your need or are of your interest. For running a simulation model focus on Chapter5 and Chapter6. It is a pretty good documentation .

A 'hardware evaluation license' is available for this core for which the generated bitsteam will work on hardware for about 2 hours.
Decide for yourself.

 

[beetlejuice]

The bottleneck is simply that I need to shift more data. The data is an image captured by a camera. We can currently move three images per second, which was fine in the past but now we need to go faster. I was hoping to do most of this using an external chipset.
Moving to a different FPGA / Vendor is not a nice option.
I found a Microchip part - KSZ9893. This is a 3 port switch with 2 x MAC/PHY and one additional port being an RGMII interface. They suggest it can be interfaced to a Microcontroller / FPGA.
I think I'll take a look at what's involved in interfacing to this.

 

[beetlejuice]

I just thought I would share this with anyone else coming across this thread and looking for answers.

I came across this excellent document - **broken link removed**

From this, I determine in my opinion, the FPGA Media Access Controller (MAC) can be as complex or simple as you need. In my case, I am simply transmitting a known payload (an image frame) to a PC a few times a second using the UDP protocol. Messages from the PC are very simple, infrequent commands just a few bytes in length. The FPGA IP is static and fixed. There is only a simple peer to peer network completely under my control.

From the information here it seems that I can implement a very reduced subset of the IEEE802.3 functionality. In fact since the FPGA design only does one specific well defined operation, some of the functions of the MAC may well be dealt with in the higher layers of the design, for example, we can deal with padding or minimum frame size in our HDL at a higher level to avoid the MAC having to deal with it. In fact, you can even just ensure that your higher level HDL complies with the rules of IEEE802.3 in which case a separate MAC layer is not even required.

In summary - I acknowledge that what I am suggesting here is not going to create reusable HDL, it seems that creating an FPGA MAC with an RGMII interface to a Gigabit ethernet PHY device does not have to be a major project if you are creating a design that has well controlled boundaries and you have total control of the data being transmitted through it.

Thanks to all who took the time to help with their advice.

 

[KlausST]

Hi,

engineers like values, numbers, units - at least me. Otherwise it´s impossible to calculate.

your problem seems to be too low datarate

* 16 bit interface
* The data is an image
* We can currently move three images per second
* we need to go faster
* I am simply transmitting a known payload (an image frame)
* a few times a second
-->is all just vague and does not say anything about datarate

The bottleneck is not "that you need higher bandwidth". The bottleneck is the piece in the communication that currently limits the datarate.
Maybe this is
* the camera
* the data compression algorithm
* The FPGA and/or it´s algorithm
* the interface
* the router
* the PC hardware
* the PC OS
* The PC software
* or...

Thus there is a good chance that using another ethernet chip is just a lot of effort without giving satisfactory results.

I recommend to calculate/measure the necessary datarate and scan to the complete chain to find out the real bottle neck.

Klaus

 

[ads-ee]

Klaus, the the bottleneck is the Ethernet datarate using 10/100. The OP is planning to fix this by switching to 10/100/1000. At 100Mbps they can get 3 images transferred, this translates to images that are approximately 30Mbits per image, which aren't very big if they are being sent in some raw format. If they switch to Gigabit Ethernet they can get a 10x improvement for 30fps.

Another option would be to see if the camera has a mode where the image can be sent in a compressed format like JPEG (if there isn't a requirement for getting the raw image). Doing that might allow you to get close to 30fps without changing hardware.

 

[KlausST]

Hi,

yes. I've read what the OP wrote.
To me it seems he "assumes" that the ethernet chip is the bottleneck. I´m just not sure that this is the case. There may be many other reasons...
I want to protect him from a lot of useless work ... by thoroughly checking the situation.
"no values" is always an alarm signal for me that there was no detailed debugging.

Klaus

 

[ads-ee]

Hi,

yes. I've read what the OP wrote.
To me it seems he "assumes" that the ethernet chip is the bottleneck. I´m just not sure that this is the case. There may be many other reasons...
I want to protect him from a lot of useless work ... by thoroughly checking the situation.
"no values" is always an alarm signal for me that there was no detailed debugging.

Klaus

Well it is highly dependent on the image size and whether or not the images are in RAW format or compressed. I was assuming RAW and the images are 24-bit color, which if they are HD (1280x720) the Ethernet can reasonably send ~4 fps. If they are using a camera that isn't HD and has a 1280x960 (a standard 1 Megapixel camera with a 4:3 ratio) with 24-bit color depth then they will be using almost exactly 30Mb of Ethernet bandwidth per picture and would only be able to transfer 3 fps.

So unless they come back and tell us they are using some low end camera with 640x480 resolution then they are probably limited by the Ethernet bandwidth.

If they up the Ethernet to Gigabit then they could easily send 1 Megapixel raw video at 30 fps.

You are correct they did leave out any "values" to double check where they assume there is the problem.

 

[beetlejuice]

Sorry to leave out the "values" and waste your time.

Ads-ee, you nailed it. Its quite simple -

Camera resolution = 1280x920. I'm doing YUV to RGB conversion on the FPGA. Transmitted image size = 29,491,200 bits.
On 100MBit ethernet that allows for a maximum transfer of 3 images per second. You really don't have to do much delving and debugging to work that one out. The actual output from the camera is YUV422, which is essentially 16bits /pixel, so you could argue that I could transmit the YUV data, and that's simple enough. That would be an image size of 19,660,800 and we could potentially, at least in theory get to transfer 5 images per second. We could also do image compression on the FPGA - but I don't want to. I Don't want to do too much work on the FPGA which is why I asked ...

Can anyone suggest such a device, or event a pair of chips (separate MAC and PHY) that I can interface to with a 16bit parallel bus ?

The reason - I want to run at a much higher frames per second rate, and potentially also increase the camera resolution.
How much faster - 10x. How much bigger resolution - that's undecided at the moment (and yes I know that I will not be able to run 10x faster frame rate, if I increase the resolution of the camera).

Thank you for all your suggestions. They are greatly appreciated. While I would still ideally like to solve this with a chip (or chipset) I think I'll end up building a minimum MAC implementation into the FPGA and an RGMII interface to a PHY chip. How difficult can it be !

 

[ads-ee]

Well Lattice does have a Tri-Speed Ethernet MAC is there some reason you can't use it?

If that can't be used then you could try using the TEMAC on opencores, but I don't know if it is any good. The old 10/100 MAC core I'd seen used on projects I've seen on other sites.

If you are using a very low end Lattice part you might not be able to implement a Gigabit Ethernet as it may not have the features like DDR I/O that are used to implement RGMII or it may be too slow.

 

[beetlejuice]

The part on the board is a MachXO2. (Its actually classed as a CPLD if you want to be precise). Its got the DDR IO but its not supported on the Tri Speed Ethernet core from Lattice.
As previously stated - We are only running on a peer to peer network and in complete control of what happens on the other end of the cable, ie in the PC. So I think creating a cut down MAC that only does what it needs to do may a viable solution.

 

[ads-ee]

As previously stated - We are only running on a peer to peer network and in complete control of what happens on the other end of the cable, ie in the PC. So I think creating a cut down MAC that only does what it needs to do may a viable solution.

Well there isn't anything that you can remove from a MAC and still have it work as a MAC...

From the wiki entry on media access control

According to IEEE Std 802-2001 section 6.2.3 "MAC sublayer", the primary functions performed by the MAC layer are:[1]

• Frame delimiting and recognition
• Addressing of destination stations (both as individual stations and as groups of stations)
• Conveyance of source-station addressing information
• Transparent data transfer of LLC PDUs, or of equivalent information in the Ethernet sublayer
• Protection against errors, generally by means of generating and checking frame check sequences
• Control of access to the physical transmission medium

In the case of Ethernet, according to 802.3-2002 section 4.1.4, the functions required of a MAC are:[2]

• receive/transmit normal frames
• half-duplex retransmission and backoff functions
• append/check FCS (frame check sequence)
• interframe gap enforcement
• discard malformed frames
• prepend(tx)/remove(rx) preamble, SFD (start frame delimiter), and padding
• half-duplex compatibility: append(tx)/remove(rx) MAC address

There aren't any features specific to your UDP transmission outside of the half-duplex retransmission and hackoff functions that you can actually remove and expect it to work with another Ethernet MAC. You can only delete those because most connections are done point to point and don't have to support half-duplex with multiple drops.

So I recommend using the one off opencores or buy one from a IP vendor that written as device agnostic as possible. Another possibility is to see if the core produced by the Lattice tools is unencrypted HDL and then swap-out/remove any device specific instantiations and substitute HDL or MachX02 specific primitives in there place.

I've never used a MachX02 is it capable or running logic at 125MHz?