A humble request to seniors and experienced developers if they can write a guide for actual implementation process of using the ethernet IP to enable us to learn and implement the ethernet IP with ease. can make a tutorial video of implementation uploaded to youtube or can provide it in document form whatever easy to him.

Thanks in advance and it would be a great help.

Ok, you're on. I'll take you up on that.

I've thought about writing a tutorial on how to build ethernet IP for some time. The general complexity involved, though, has held me back since I've been worried that it would go over a readers head. There would be several parts to such:

1. Stream processing in general, since it makes data packet processing easier to do
2. Adding a preamble and then a MAC to a stream of data
3. Stuffing the packet to the minimum length, if it isn't already minimal length
4. Adding a CRC to the end of the packet
5. Optionally, you could add an IP checksum to the first several values of the packet

The receive side is the same in reverse. You can see a core built to do all of this in the OpenArty project.

This gets you ethernet IP. The next problem is using that IP. To do that, you need to first support the ARP protocol, then the ICMP protocol, then IP. For IP, you'd typically support UDP first, then TCP. I've done the UDP part, just not (yet) the TCP part. I have a demo of the first several parts of this here. I'll likely update it soon in the near future based upon user request to run the interface at high speed.

Blogging about all of this would be fun.

Dan

Sir thanks for your kind replay. Sir, I think you want to say about the tutorial how all this is implemented in Verilog or VHDL. yes, that would be an exceptionally great help but at present, if a tutorial about how this ETHERNET MAC IP core is physically implemented in Xilinx or Altera FPGA. means how to use these IP cores in a project.

Oh, absolutely! There's a bit more involved as well:

As you mentioned, you need to deal with IP core design. My own ethernet IP core exposes two ports on the bus: a pseudo memory port and a control port. Messages you would like to send are written to one half of the memory port, and messages that have been received are read from the other half of the memory port. A control port, with registers for controlling both transmit and receive, can be used to control what happens. The transmit control register tells the core how long the packet is, the receive control register may be read to learn how long the received packet was. Beyond that, there are some subtleties about how the packets are written to the memory--such as that (in my own implementation) the local MAC address is filled in for you by the ethernet core itself.

Many other implementations will give the network controllers access to the bus to master it, so that as a packet comes in they might automatically write it to memory (receive), or for transmit they might automatically read it from memory. While this was not my own approach, for reasons of simplicity, this is a viable approach.

So, using the core works in this wise: you assemble a packet to be transmitted. You copy it to the transmit memory, then you send a message to the transmit control register and away it goes! There's a touch of software difficulty here in multiprocessing systems: You'll need to make certain that only one processor has control of the ethernet port at any given time. Otherwise you'll get packets containing parts of two or three other packets and ... nothing will make sense. A simple semaphore will fix this nice and easily.

As for receiving a packet, just turn the network on and packets will be received and read. However, in my own implementation, a received packet will stay in the network memory buffer, blocking future packets from arriving, until the first packet is disposed of.

How do you handle a received packet? Linux systems call a net_rx() function to indicate a packet has arrived into the system. The packet is then adjusted, such as the headers and footers for that layer are removed, and then it is sent to the respective sublayer with a similar function call. Having the proper data structure to do this is important.

In my own demonstration software, I only implement a couple of protocols: ARP and ICMP. (I might have implemented UDP as well--can't remember.) These two protocols are a minimum for network communication. Without ARP, nothing will know the MAC address to use to contact your core. Likewise, without ICMP, you might never know that your core was available on the network.

Implementing just the ARP protocol requires listening for ARP packet requests, and responding to them when you get one. The other half requires you to make a request and then process the packet you receive in response. As I mentioned above, without this your IP-based design will never work.

ICMP packets are "ping" packets. You'll want your design to be able to "ping" another computer--just to know that your design works. You'll also want your design to be able to respond to pings. This means you have a piece of software that can send a ping, and a piece of software that recognizes you've received a ping and can send a response.

I look forward to implementing a full TCP stack when I get the chance. It doesn't look all that hard to do.

By the way, wikipedia is your friend. You'll find some wonderful discussions of the various (required) network protocols there. Their articles on Ethernet, ARM, ICMP, IP, UDP, and TCP, are all quite commendable and usable.

Your other big friend is wireshark. As you are trying to get something up and running, there's really no better program than wireshark to see what's going on.

Dan