Ethernet on recent FPGAs

Hi,

Am far from being an expert in fpga usage and programming, I was wondering if there exists any ip cores out there that would allow the use of ethernet interfaces on recent FPGAs. For instance say that I have a rather important bandwidth (500Mb/s) and that I want to send that over the Gigabit interface of a Virtex 5 in UDP frames. Is there any blackbox concept IP Core that would allow me to do that without having to learn about UDP frame and TCP and the use of the Xilinx ethernet MAC usage etc etc ?

Thanks

Pat

Reply to
Pat Magnits
Loading thread data ...

Sending UDP packets is rather straightforward. Look here:

formatting link

You'll need a phy to send the data. These aren't difficult to connect & control.

--
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl
Reply to
Nico Coesel

formatting link

Reply to
Symon

10base-t and Gigabit ethernet have different implementation difficulty levels ;-)

FPGA, uC-Core and Gigabit is being done. Look at the Leon or the USRP2/Gnuradio effort.

--
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
 Click to see the full signature
Reply to
Uwe Bonnes

Not if you are using an external phy (which are relatively cheap). In that case you'll have to implement an MII-like interface which is not very difficult. I estimate a Spartan 3 speed grade 5 should do just fine.

--
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl
Reply to
Nico Coesel

That is not particularly difficult if you are using a dedicated hardware MAC in a Xilinx part or even if you are talking GMII directly to an external PHY. To send UDP frames you don't need to be able to receive anything[*].

Most of the difficulty will actually be in forming the first packet header. For UDP data, you can probably reuse the exact header over and over (as long as the length is always the same). There's a lot of stuff in the header that you take for granted which is provided by your network stack (some of which is done by executing low level protocols over the interface[*]).

Also, if you are making a commercial product, you will need to get some actual MAC addresses for your interfaces.

--
Ben Jackson AD7GD

http://www.ben.com/
Reply to
Ben Jackson

In theory yes. However there are still loads of MAC address ranges assigned to companies which are long gone or have moved into a different direction. Unless you will be making millions of units, it is quite safe to pick one of those.

--
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl
Reply to
Nico Coesel

If you have a LAN with 200 (non-clashing) MAC addresses and generate a random (40-bit) address for your node, the probability of its clashing with an existing address is 200/2^40 (call this P), which is about one in 5,5000,000,000

If you make ten million units and each is added to a LAN which already has 200 nodes, the probability of having no clash is (1-P)^10,000,000, which is about 1-10,000,000P, so the probability of a clash is about

10,000,000P = one in 550.

So, under these (extreme) conditions, the probability of even one clash is less than 0.2% (and the probability of more than one clash is much less).

The options seem to be:

1) Buy a batch of unique addresses (which isn't cheap and involves administrative hassle). If you're designing a LAN for an airliner I'm going to fly on, I'd like you to use this method.

2) Generate a random address. There's a chance of about 0.2% that one of your 10,000,000 customers will have a problem. You could:

i) Provide a procedure to deal with this situation (e.g. to generate another random number).

ii) Send a replacement with an apology and a box of chocolates. This is probably the cheaper option.

Mike

Reply to
MikeShepherd564

The problem is that some bits in the MAC address are reserved for other purposes. So the actual number of bits you can use is somewhere between 36 and 38 (don't know exactly). Also, all zeroes and all ones are invalid addresses.

True. Still I know people that had problems because they had network cards with the same MAC address (set by the factory).

--
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl
Reply to
Nico Coesel

MAC addresses are 48 bits. I was being conservative by assuming that only 40 are unique. The (rather poor) article at

formatting link
suggests that only two of the bits are reserved. I think that the "all zeroes" and "all ones" cases can safely be ignored in our approximate calculations, so the revised arithmetic gives:

If you have a LAN with 200 (non-clashing) MAC addresses and generate a random (46-bit) address for your node, the probability of its clashing with an existing address is 200/2^46 (call this P), which is about one in 350,000,000,000.

If you make ten million units and each is added to a LAN which already has 200 nodes, the probability of having no clash is (1-P)^10,000,000, which is about 1-10,000,000P, so the probability of a clash is about

10,000,000P = one in 35,000.

So, under these (extreme) conditions, the probability of even one clash is about 0.003% (and the probability of more than one clash is much less), so you can forget it.

Even if you're designing a LAN for an aircraft I'll fly on, I'm happy for you to allocate the MAC address at random with these odds. Yes, there might be a clash, but I'm more likely to be hit while crossing the road by an errant spacecraft from the planet Zog.

Mike

Reply to
MikeShepherd564

Mike,

While I agree that the MAC ID space is so large that the chance of a collision for a random address is very low, I do not agree with that statement. Buying a range of unique addresses is cheap and easy, and no administrative hassle is involved.

The IEEE administers MAC IDs, and you can buy a range of them for a one time fee online. I bought the OUI package online with a credit card and have no regrets. Take a look at:

formatting link
formatting link
formatting link

You can buy a 4K block of MAC IDs for $500 USD, or a 2^24 block of IDs for $1650. That is lost in the noise for producing a commercial product.

This is a far better deal than I get from the PCI SIG where I have to pay every year to retain my vendor ID. For the MAC IDs, I pay once and it is mine for ever.

While I am a small business owner and complain about every penny spent, I think that the IEEE gives me a fair deal.

Regards,

John McCaskill

formatting link
Xilinx Alliance Partner Impulse C Platform Partner

Reply to
John McCaskill

I accept your point about the cost. By "administrative hassle", I mean that of maintaining records within one's own company. If this were negligible for MAC addresses then you could say the same about DHCP, but you'd make a lot of network admins very unhappy if you took away DHCP.

Mike

Reply to
MikeShepherd564

Well you can make it easy by making it some one else's problem. Make the MAC ID be a starting address plus the serial number. Some where in the company will be an accountant that cares greatly about the serial number and will deal with that issue for you. That is what I do.

Don't let reality get in the way of enjoying the engineering.

Regards,

John McCaskill

formatting link
Xilinx Alliance Partner Impulse C Platform Partner

Reply to
John McCaskill

Giving the job to someone else doesn't make it disappear. In this company, I do it all. There's no "accountant" to be assigned the dirty jobs. Whatever it is, it has to be efficient. Offloading work to others is just a "big company" trick.

In 2008 we automate. Sure, you don't need DHCP or other automated ID allocation systems. Just fill in form B31 and send it to the accountant. He'll reply as soon as he returns from vacation. You could manage without e-mail, too. Just tell that accountant he's also a messenger boy.

Mike

Reply to
MikeShepherd564

Well I may have been a bit flippant with the accountant remark, ours does not actually put the serial numbers on the boards either, but she does care that we do it.

My point is that if you are manufacturing commercial hardware for sale you probably already have serial numbers on the products you are building. Just piggy back MAC ID assignment off of those.

We never put a MAC ID in our products. The software just uses the serial number and our IEEE OUI to generate them.

Enjoy the rest of your weekend,

John McCaskill

Reply to
John McCaskill

formatting link

Another option is to let the customer set the ID through some configuration option. That way collisions can be avoided post manufacture. And the administrator can't claim that you used an ID "without permission".

Reply to
posedge52

There is a story that in the beginnings of ethernet using random 48 bit MAC addresses was considered, but rejected because of the (small) probability of two accidentally choosing the same address.

As I understand it, in the current system there have been devices produced that accidentally had the same address. As the current system involves humans, such as programming ROMs and installing them in cards, there is a relatively high probability of accidents.

Choosing a random 46 bit number with the local administration bit on and the multicast bit off might not be so bad.

-- glen

Reply to
glen herrmannsfeldt

Yes and no. Like others already pointed out, devices need a serial number anyway. Not just for administration but also to keep track of devices. So having a fixed number (MAC address) assigned to unit xyz generally saves a lot of trouble.

Besides, if you are going to generate random MAC addresses you may get intermittant errors because fixed MAC addresses are expected. Those kind of errors are the last you want on a network.

--
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl
Reply to
Nico Coesel

In the early days, address allocations were notified to applicants in the order the bits are transmitted in an ethernet frame on the wire, and a significant number of the early vendors produced loads of kit using completely the wrong OUI as a consequence (with the bits in every octet of the OUI in reverse order).

--
Andrew Gabriel
[email address is not usable -- followup in the newsgroup]
Reply to
Andrew Gabriel

We *did* consider using randomly-chosen addresses, but in a 64-bit address space; the probability of a clash in a 48-bit space was considered too high. I wrote a paper on the subject back in 1979-80, which is probably lost to history.

Although properly-implemented random addresses would have worked, we chose the administered-vendor-space 48-bit scheme of today as being more "politically palatable"; I am sure we would have been hammered even worse about letting randomness control network addressing than we were about letting randomness control the backoff algorithm.

-- Rich Seifert Networks and Communications Consulting 21885 Bear Creek Way (408) 395-5700 Los Gatos, CA 95033 (408) 228-0803 FAX

Send replies to: usenet at richseifert dot com

Reply to
Rich Seifert

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.