Re: Tiny TCP/IP stack and tiny MAC controller on FPGA for direct download to S(D)RAM memory

How does that table/CAM get initialized?

I'd suggest putting hacks like that on the back burner until the initial code is working.

What do you mean about "Be sure to fixup the broadcast case"?

It is not the intention to implement all TCP/IP functions in the FPGA (target). As far I had read and understand some stuffs about Ethernet protocols. The minimum "processor-less" requirements is the UDP protocol for a simple data transfer without data loss checks. In the UDP frames a sequence number can be inserted to verify the data completeness. Checksum calculation and handlers can also be implemented in the FPGA. No stack is required when all valid UDP packets will be processed immediately and stored into the SRAM memory. In this case all TCP functions/stack can be removed. It will lead to reduce the amount FPGA logic elements substantiatelly.

I am not sure about some things and have some questions:

1. Is only the UDP protocol sufficient to be implemented in FPGA for simple data transfers to the target (FPGA) from the PC? Do I need also the ARP or other protocols?
2. Which protocols can I miss when the PC knows the 32-bit IP number of the target? Is a 48-bit ethernet address required?
3. Suppose that all UDP packets will also be forwarded through the router(s) to the target. Does it needs a special attention when only the UDP is implemented? Will the routers change the IP header (and UDP header) of the UDP packets before they are arrived at target?
4. Is the connection negotiation required between the PC and the target? Do you think that the PC will always transfer some UDP packets without restrictions?

There isn't much FPGA related in here any more... I'm not sure where this sort of thing gets discussed. I expect the low end micro hackers are good at it.

see below

Yes, you need to answer ARP requests. You can generally fake that when getting started if you hard wire it into the ARP table on the machine you are testing from.

You also need DHCP if you don't want to put your IP address into a config file someplace.

The hardware works on the 48 bit host ID. You could hack around that if you have control of the other end too, but that is abusing Ethernet rather than using it. (Which might be OK if you just need to do a one off hack and don't want to talk to several machines.)

The routers will update the hop count. Mostly, they won't touch anything else. (except to fixup the checksum)

The trick with simple implementations for UDP over Ethernet is that you don't have to know about routers. When you get a packet, you send the answer back to where you got it. That happens at both the Ethernet layer and at the IP layer. All the info you need is in the headers.

The server side of simple UPD protocols doesn't need to save any info. It gets a request packet, looks at a few command bytes (you have to invent this layer of protocol), does what it says (say reads the temperature and puts in into the packet) then fixes up the packet (say changes the packet type from query to response) and sends it back.

The send-it-back part involves copying the source field from the packet into the destination. That happens twice - Ethernet/48 bit layer and also at the IP/32 bit layer. Then you put your info into the source fields, fixup a few more header bytes, compute the IP checksum, and send it off. Note that this doesn't know if it's sending back directly or through a router.

Except for the broadcast, you could just swap the source/destination fields.

The simple/stateless server moves all work of retransmissions and timers back to the other end.

If you want to do something a bit more complicated, the next step is probably TFTP/BOOTP. It's often used to fetch boot files over the network. (for example, because you don't have a disk, or you are installing new software)