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

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
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
(www.maco-engineering.de), in the "Download" page.

Jesse Kempa
Altera Corp.
jkempa at altera dot com


snipped-for-privacy@philips.com (Erik Coenders) wrote in message
Quoted text here. Click to load it

Re: Tiny TCP/IP stack and tiny MAC controller on FPGA for direct download to S(D)RAM memory
Quoted text here. Click to load it

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
We've slightly trimmed the long signature. Click to see the full one.
Re: Tiny TCP/IP stack and tiny MAC controller on FPGA for direct download to S(D)RAM memory
snipped-for-privacy@suespammers.org (Hal Murray) wrote in message
Quoted text here. Click to load it

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?

Re: Tiny TCP/IP stack and tiny MAC controller on FPGA for direct download to S(D)RAM memory
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.

Quoted text here. Click to load 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.

Quoted text here. Click to load it

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.)

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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
We've slightly trimmed the long signature. Click to see the full one.

Site Timeline