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

As others have suggested, TCP is something that implemented entirely in hardware, would be pretty resource intensive. There are many operations going on which are well suited for an embedded CPU to handle. Acceleration (or off-loading) can be done by handling things such as checksum calculations in hardware... in the end, I think that you'll see many embedded Ethernet solutions (on FPGA or not) use a mix of HW and SW to implement everything.

Also, if you're willing to take a look at unsupported IP (in contrast to commercial IP), I would also second that you take a look at the opencores.org 10/100 MAC. It has been ported to support the Nios CPU (and Plugs IP stack)... in my own playing with it, it takes just over

2500LEs and has its own integrated DMA controller - its really well architected. The port (ready to drop into SOPC Builder if you want to give it a try with Nios) is available from MaCo-Engineering
formatting link
in the "Download" page.

Jesse Kempa Altera Corp. jkempa at altera dot com

Hi, > > As a study for a project I need to investigate the possibility of > implementing a tiny TCP/IP stack and tiny MAC controller on FPGA. This > stack is capable to transfer some data packets directly into S(D)RAM > without help of the microcontroller. Thus a simple communication via > Ethernet from the desktop PC is required for download/upload to/from > the memory. > > The FPGA board is attached to an Ethernet PHY device such as DP83847A. > In this case a MAC controller was implemented in FPGA but the FPGA > utilitization is too high. There is less room available for other > blocks. My intention is to build a small TCP/IP stack and MAC blocks > in the FPGA and the transaction between FPGA/Ethernet PHY and the > desktop PC has to kept as simple as possible. Thus no heavy/extensive > protocol is needed. > > The questions raised are: > 1. What is the minimum TCP/IP function set required to do simple file > transfer and etc.? > 2. Is it possible to perform all tasks only in FPGA without help of > the microprocessor? > 3. Are there any resources (VHDL code and C program on PC) available > on this topic? > > I will welcome all comments and suggestions. please feel free to write > us at snipped-for-privacy@philips.com Thank you all.
Reply to
Jesse Kempa
Loading thread data ...

How does that table/CAM get initialized?

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

--
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
 Click to see the full signature
Reply to
Hal Murray

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?
Reply to
Erik Coenders

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)

--
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
 Click to see the full signature
Reply to
Hal Murray

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.