Electronic – FPGA TCP Connection

Let's get some terms straight first: An Ethernet interface is typically made from two parts: a MAC and a PHY. The MAC, Media Access Controller, handles all of the packet assembly, transmission, reception, and error checking. A PHY handles all of the PHYsical transport stuff like modulating the signal, managing the DC balancing, tracking baseband wander, etc.

There are some things that both sides do, to some extent. Both MAC and PHY do some level of data error detection. This is not redundant error detection, but just error detection that is related directly to the types of things that the MAC and PHY do. Also, both MAC and PHY are dependent on the packet nature of Ethernet. The MAC because it is using the packet nature to filter, route, and manage the data. The PHY because there are certain signal modulation/demodulation functions that require packets (and the space between packets) to function correctly.

The point is: You cannot get away from packets even if you just use the PHY. Of course, the packet headers do not have to be "standard" headers. And the CRC does not have to be a standard CRC. But you are still limited to the maximum packet length and inter-packet-gap that standard Ethernet requires. (Note: You might be able to do "jumbo" packets if both PHYs support it.)

There are many benefits to using standard Ethernet packet headers, however. We would refer to this as a "Layer 2" protocol. The main benefit is that you can use standard Ethernet switches to help connect different devices together.

You mention just connecting a "TDM stream" directly (more or less) to the PHY. Every time someone has said that to me they have been talking about running multi-channel digital audio over Ethernet. If that is the case then you have a bunch of other issues, like clock synchronization and error detection that will prevent you from doing it the easy way. I won't cover audio over Ethernet more in this answer, but tell me if that is what you want to do because I can add a lot more info in that case.

Historically there have been many products that have taken some sort of data stream and ran it over Cat-5 using Ethernet PHYs and FPGAs, but without traditional MACs. Some of them have used the proper Ethernet Layer 2 or Layer 3 packets, and some of them have not. Some have also used non-Ethernet technology like ATM or FDDI. Some of them have used FPGA's, but inside the FPGA is a more traditional CPU and MAC.

I hope that at this point you have realized that what you want to do (use an FPGA and PHY to transfer a data stream over Cat-5) is difficult. Not impossible, but difficult. Let me try to explain how difficult.

First, you will have to master FPGA logic design. Of all the professional FPGA logic designers I know of, this project is beyond the ability of maybe 95% of them. These are people who have been designing FPGAs for several years or even several decades. It will take you a long time to learn FPGAs enough to design this logic. Probably years if you are doing this as a hobby.

Next, you need to learn exactly what a MAC and PHY do, and how they interface. This is not as hard as learning FPGAs, but it isn't easy either. There are a lot of basic concepts that are important, but not easily learned.

Now you'll have to design a PCB to do all of this. Designing a reliable PCB that uses FPGAs, PHYs, and does all of the proper Ethernet signal integrity stuff is also not easy. Not super hard either. But on a scale of 1-10, with 1 being super easy, this PCB would be about a 6. Not hard for an experienced professional, but definitely hard for a non-professional-EE.

At this point you probably noticed that I didn't directly answer your questions. This was on purpose. I could answer your questions, but honestly that wouldn't help you. It would be like telling you how to build the second story of a house when you haven't figured out how to build the first story or even the foundation.

Start by learning everything about designing FPGAs that you can. Also learn everything about Ethernet that you can. There are lots of online resources from app notes, datasheets, and how-to's. Go to opencores.org and study their Ethernet MAC cores. Do this diligently and in a year you might be ready. And when you are ready then you will likely know the answers to 75% of your questions-- and you will be able to put the other 25% into proper context so when someone does give you an answer it will actually be useful to you.

I've used the TEMAC core directly instanciated in logic so I can probably give you some thoughts and answers.

Documentation

Firstly, Xilinx provides a whole host of documents for each of it's IP cores. They also keep documents for different versions of the core, so be careful to pick the right document. A search of the Xilinx support documents came up with this collection of documents:

Xilinx TEMAC Documentation

The main document that you will want to look at is the user manual. It is VERY detailed and should have everything you need to use the core in a project. Saying that, it can be quite hard to work through and fine the information you want.

I'm basing this on v4.5 of the core, I think that's the most recent direct instanciation version (not AXI bus). What cores you can use will depend on how up-to-date your ISE version is, but they don't change of the basics between versions.

The TEMAC v4.5 user manual is at http://www.xilinx.com/support/documentation/ip_documentation/tri_mode_eth_mac_ug138.pdf

Licence

The TEMAC core requires a licence to use. An evaluation licence is free and fully functional, but it stops working after a while

The core can be tested in the target device for a limited time before timing out (ceasing to function) at which time it can be reactivated by reconfiguring the device.

On the Spartan-6 device I used the core on with a 50 MHz clock the core functioned for about 8 hours, but there's no documentation on exactly how the timeout works.

I would get a quote for a licence before you do too much work with the core, it does cost quite a bit of money!

Function

There's a block diagram of the core on page 52 of the document.

This shows you what the TEMAC does in Ethernet jargon, but basically the core interfaces between the user logic and the Ethernet PHY (which drives the actual line signals) on a packet-by-packet basis.

The key to most of your questions is how the "client interface" works. This is the interface to your logic and is well described. Take a look at that chapter to see what the input and output data from the interface is like.

Answers

To answer your specific questions:

How do I know the MAC address of the board?

The TEMAC takes in the MAC address you give it and uses that, so you'll have to provide it from somewhere. Many development boards provide a MAC address EEPROM chip which has a unique address stored in it for you to read and use. If you don't have a MAC address available on the board itself, you can hard code one, but beware that this is kind of against the rules and could possibly cause a problem if another device on your network happens to have that address. One fairly elegant solution is to find an old Ethernet device that you don't use any more and just use it's address for testing.

And once the Temac core is instantiated, will all the data processing be done by it?

No, not really. The receiver and transmitter interfaces work at an individual Ethernet packet level, so your logic must provide individual packets. This is layer 2 on the OSI model. You'll have to create other logic or use another core to handle any higher-level protocols that you want to use (such as TCP or UDP).

I've used this core to make a system work, including writing my own modules to interface with the client interface, and am happy to answer any other questions. Unfortunately my code is owned by the company I work for, but I can talk about it in general.