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 ?
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.
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.
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.
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
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
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.
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.
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).
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
Higher than the actual clash rate on the current system?
I have heard stories about NICs produced with the same address, most likely in the same batch with a high probability of being installed on the same net.
We once had a Sun system that the local computer hardware people sent back to Sun to be fixed. The rule at the time was that one should remove the ROM (or battery backed RAM) before sending it in. In this case, it was reinstalled backwards destroying the stored address. Losing the stored address from battery backed RAM can't be that uncommon. (The battery life tends to be less than the processor life.)
Also, I once knew a net with a device with address 00:00:00:00:00:00. As there was only one, it was decided to leave it alone.
As the subject is FPGAs, I believe it isn't hard to change data in a synthesized ROM after the bit file has been generated. That should be pretty convenient for generating the packet. Getting the IP address is a little harder.
Not so much network errors as administration problems. It is harder to track down devices with variable MAC addresses.
The intent was never to have MAC addresses generated at random *in the field*, i.e., upon interface initialization. The idea was to generate them at random in the *manufacturing process*; there would not be "variable" MAC address for a given device over time. We only wanted to avoid the OUI administration problem.
-- Rich Seifert Networks and Communications Consulting 21885 Bear Creek Way (408) 395-5700 Los Gatos, CA 95033 (408) 228-0803 FAX
Cabling-Design.com Forums 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.