Sign in

username:

password:



Not a member?

Search fpga-cpu



Search tips

Subscribe to fpga-cpu



fpga-cpu by Keywords

Altera | CISCifying | IDE | ISA | Java | JHDL | JTAG | LBU | MicroBlaze | PAR | PCI | RISC | SoC | Spartan | Transputers | Verilog | VHDL | Virtex | VLIW | WebPack | Xilinx | Xsoc | YARD-1A

Ads

Discussion Groups

Discussion Groups | FPGA-CPU | Re: TCP/IP on FPGA

This list is for discussion of the design and implementation of field-programmable gate array based processors and integrated systems. It is also for discussion and community support of the XSOC Project (see http://www.fpgacpu.org/xsoc).

TCP/IP on FPGA - Anand Gopal Shirahatti - Apr 5 16:42:00 2002

Hi All,

Recently I have been able to see that lot of Software applications
are ported on to the FPGA's. Very Recent discussions on Task
Scheduler Implementations were also quite Intersting.

What I was wondering is, R there are Implementations of the TCP/IP
Implementation over a Single FPGA, for mutilple connections.

How the Dynmaic memory allocation which is the primary requirement
for the Protocol stacks can be Implemented on the FPGA's.

Any Innovative Ideas or Some Good Links shall be apperciated.

Regards,
Anand.




(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )


RE: TCP/IP on FPGA - Jan Gray - Apr 6 0:26:00 2002

> What I was wondering is, R there are Implementations of the TCP/IP
> Implementation over a Single FPGA, for mutilple connections.

The simplest thing to do is run a software TCP/IP stack on a compact
FPGA CPU core.

By the way at ESC I saw TCP/IP running on uCLinux on Altera Nios with a
CS8900A ethernet MAC.

I also note that a compact FPGA CPU core with integral DMA (e.g. xr16)
may be hybridized into the data shovel aspect of an ethernet MAC.
(Flexibly shovel the incoming bits to/from buffers, etc.) Indeed, one
enhanced FPGA CPU might (time multiplexed or otherwise) manage several
physical links.

You can also build hardware implementations of the TCP/IP protocol
itself. There are several such implementations in custom VLSI. For
FPGA approaches, see e.g.

Smith et al's XCoNet,
http://www-ee.eng.hawaii.edu/~msmith/XCoNET/XCoNET.htm

BlueArc SiliconServer: http://www.bluearc.com/,
http://www.bluearc.com/news/downloads/datasheets/server_wp.pdf. "The
SiliconServer runs all normal TCP/IP functionality in state machine
logic with a few exceptions that are currently dealt with by software
running on the systems attached processor (e.g. ICMP traffic, fragmented
traffic reassembly)."

And related things:
FPXKSM: http://www.fpgacpu.org/log/nov01.html#011106.

> How the Dynmaic memory allocation which is the primary requirement
> for the Protocol stacks can be Implemented on the FPGA's.

How dynamic must it be? Can you predetermine (constrain) no. of
buffers, no. of connections, MTU issues, size of tables, etc.?

Jan Gray, Gray Research LLC



(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

Re: RE: TCP/IP on FPGA - Anand Gopal Shirahatti - Apr 7 13:53:00 2002

Jan,

Thanks for the Responce.

Certainly Embedding the CPU core for Implementing the stack would
be simplest of all.But the Performance Improvements cannot be
considerable. But Yes, I agree that the main CPU can offloaded
from the processing burden.

But rather I am looking for real Hardware Implementation of the
full stack. I am trying to gain some understanding of fact that
how would one approach such a complex control flow Intensive
problem for Implementation in Hardware.

I checked the links but could not get any more details.

Issue of Dynamic memory allocation is to manage a common packet
buffer among multiple conncetions. Based on the fact that data
traffic on each of the link will be different. Remaining
parameters that u have menstioned can be fixed for a
Implementation.

Eitherway thanks once again.

Regards,
Anand. On Sat, 06 Apr 2002 Jan Gray wrote :
> > What I was wondering is, R there are Implementations of the
>TCP/IP
> > Implementation over a Single FPGA, for mutilple connections.
>
>The simplest thing to do is run a software TCP/IP stack on a
>compact
>FPGA CPU core.
>
>By the way at ESC I saw TCP/IP running on uCLinux on Altera Nios
>with a
>CS8900A ethernet MAC.
>
>I also note that a compact FPGA CPU core with integral DMA (e.g.
>xr16)
>may be hybridized into the data shovel aspect of an ethernet
>MAC.
>(Flexibly shovel the incoming bits to/from buffers, etc.)
>Indeed, one
>enhanced FPGA CPU might (time multiplexed or otherwise) manage
>several
>physical links.
>
>You can also build hardware implementations of the TCP/IP
>protocol
>itself. There are several such implementations in custom VLSI.
>For
>FPGA approaches, see e.g.
>
>Smith et al's XCoNet,
>http://www-ee.eng.hawaii.edu/~msmith/XCoNET/XCoNET.htm
>
>BlueArc SiliconServer: http://www.bluearc.com/,
>http://www.bluearc.com/news/downloads/datasheets/server_wp.pdf.
>"The
>SiliconServer runs all normal TCP/IP functionality in state
>machine
>logic with a few exceptions that are currently dealt with by
>software
>running on the systems attached processor (e.g. ICMP traffic,
>fragmented
>traffic reassembly)."
>
>And related things:
>FPXKSM: http://www.fpgacpu.org/log/nov01.html#011106.
>
> > How the Dynmaic memory allocation which is the primary
>requirement
> > for the Protocol stacks can be Implemented on the FPGA's.
>
>How dynamic must it be? Can you predetermine (constrain) no.
>of
>buffers, no. of connections, MTU issues, size of tables, etc.?
>
>Jan Gray, Gray Research LLC >To post a message, send it to:
>To unsubscribe, send a blank message to:






(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

Re: TCP/IP on FPGA - Jacob Nelson - Apr 7 18:12:00 2002

On 5 Apr 2002, Anand Gopal Shirahatti wrote:

> What I was wondering is, R there are Implementations of the TCP/IP
> Implementation over a Single FPGA, for mutilple connections.

I think an embedded CPU core would be the easiest way to do it. If you had
some reason for avoiding this, though, it might be a very good application
for microcode.

jake




(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

Re: RE: TCP/IP on FPGA - Eric Smith - Apr 7 19:24:00 2002

> Certainly Embedding the CPU core for Implementing the stack would be
> simplest of all.But the Performance Improvements cannot be
> considerable.

Why not? Your "CPU core" can be custom-tailored to the job at hand.

> But rather I am looking for real Hardware Implementation of the
> full stack.

It's a complex problem, so it's going to need one or more fairly
complex state machines. You can call them state machines, microcoded
controllers, or CPUs, but it all amounts to the same thing.

Complex state machines implemented in "real hardware" are equivalent
to microcoded controllers, although the names perhaps imply different
implementation styles. You might think of a one-hot state machine
as being different than a microcoded controller, but all you've done
is to distribute the microcode into the state decode logic.

> I am trying to gain some understanding of fact that
> how would one approach such a complex control flow Intensive
> problem for Implementation in Hardware.

Step one: define your state machines. That's necessary no matter
what kind of hardware you're going to design.





(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

Re: TCP/IP on FPGA - Martijn Emons - Arcobel ASIC Design Centre B.V. - Apr 8 2:22:00 2002

Dear all,

I have embedded an TCP/IP stack into an ASIC design. The best
partitioning of HW/SW (from my
experience) is to embed the MAC-functionality in order to off-load the
CPU. This means that at a 'packet-level'
the SW controls the MAC. nearly all internet connected devices have
this partitioning( from Microsoft to Linux-systems to
most embedded systems) use this partitioing.

This is done the most efficient way by using 'scatter-gather'
DMA-support by the HW,
mainly because the packet-header at the MAC-level also have a
'linked-list' defined which can be used by the
scatter-gather DMA engine. The interface to the Enthernet-PHY is an
interface which is standardized by the
IEEE-spec. (called something similar like "MII" if I remember correclty)
....there is no FPGA-vendor
out there that sells FPGA's which include an Ethernet-PHY on-board
The maximum latency requirements between the packets
(inter-packet-delay) are quite hard-to-meer without
any buffering near to the MAC-block. Note that this depends on
SDRAM-load caused by other memory-agents.
Hence a buffer-size of 16kbyte for Transmit and 16kbyte for receive are
not extravagant.

There is little use of a HW-only implementation of the complete stack
because I can't think any real-life application
which doesn't use SW in *processing* the data that comes the
intra/internet. Hence, because there is a CPU anyway
available, it can also do low-life issues like TCP-processing.

Quickest route to heaven:
* buy an ARM-kit from Altera/Atmel.
* download the TCP/IP software from the ARM-website.
* take a look at the available MAC-cores (free-cores.org, Alcatel etc.
etc.) and design your own.
* integrate & simulate 'till your dead.

Amen!
Martijn Emons

Eric Smith wrote:

>>Certainly Embedding the CPU core for Implementing the stack would be
>>simplest of all.But the Performance Improvements cannot be
>>considerable.
>>
>
>Why not? Your "CPU core" can be custom-tailored to the job at hand.
>
>>But rather I am looking for real Hardware Implementation of the
>>full stack.
>>
>
>It's a complex problem, so it's going to need one or more fairly
>complex state machines. You can call them state machines, microcoded
>controllers, or CPUs, but it all amounts to the same thing.
>
>Complex state machines implemented in "real hardware" are equivalent
>to microcoded controllers, although the names perhaps imply different
>implementation styles. You might think of a one-hot state machine
>as being different than a microcoded controller, but all you've done
>is to distribute the microcode into the state decode logic.
>
>>I am trying to gain some understanding of fact that
>>how would one approach such a complex control flow Intensive
>>problem for Implementation in Hardware.
>>
>
>Step one: define your state machines. That's necessary no matter
>what kind of hardware you're going to design. >
>
>To post a message, send it to:
>To unsubscribe, send a blank message to: >_____________________________________________________________________________________________
>This inbound message from KPN has been checked for all known viruses by KPN IV-Scan, powered by MessageLabs.
>For further information visit: http://www.veiliginternet.nl
>_____________________________________________________________________________________________ --

Kind regards, Martijn Emons

- Designer Consultant -
Arcobel ASIC Design Centre B.V.
Hambakenwetering 1
5231 DD 's-Hertogenbosch,
The Netherlands.
tel.: +31 73 64 60 100
fax : +31 73 64 60 115

_____________________________________________________________________________________________
This outbound message from KPN has been checked for all known viruses by KPN IV-Scan, powered by MessageLabs.
For further information visit: http://www.veiliginternet.nl
_____________________________________________________________________________________________


(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

RE: RE: TCP/IP on FPGA - Gary Watson - Apr 8 3:41:00 2002


Look at www.uspto.gov and find patent number 6,226,680 by Boucher, et al.
This describes in great detail how the Alacritech TCP/IP Offload Engine
(TOE) works. You should be aware that there is are is a huge amount of
patent-filing going on with TOE technology and almost anything you do will
ultimately require royalties to some big NIC company. You can also look at
iReady's approach in patent 6,034,963. Each of these patents will give you
links to other related patents.

One thing, though, if your embedded CPU is fast enough, with a little bit of
hardware like a checksum generator you can probably attain wire-speed with a
conventional network stack unless maybe you are doing 10 GbE or something.
I guess this is the plan a lot of people have with the new Virtex II Pro
chips -- you can dedicate one or more of the PowerPC cores to handling your
network stack(s) with maybe a little bit of SDRAM hanging off the side for
buffering.

Gary Watson
Nexsan Technologies -----Original Message-----
From: Anand Gopal Shirahatti [mailto:]
Sent: Sunday, April 07, 2002 7:54 PM
To:
Subject: Re: RE: [fpga-cpu] TCP/IP on FPGA Jan,

Thanks for the Responce.

Certainly Embedding the CPU core for Implementing the stack would
be simplest of all.But the Performance Improvements cannot be
considerable. But Yes, I agree that the main CPU can offloaded
from the processing burden.

But rather I am looking for real Hardware Implementation of the
full stack. I am trying to gain some understanding of fact that
how would one approach such a complex control flow Intensive
problem for Implementation in Hardware.

I checked the links but could not get any more details.

Issue of Dynamic memory allocation is to manage a common packet
buffer among multiple conncetions. Based on the fact that data
traffic on each of the link will be different. Remaining
parameters that u have menstioned can be fixed for a
Implementation.

Eitherway thanks once again.

Regards,
Anand.





(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

Re: TCP/IP on FPGA - Anthony Leroyer - Apr 8 8:20:00 2002

Dear all,

I'm about to design an acquisition card based on the PCI bus.
There are two different ways to implement the bus interface :
- using a dedicated chip such as 9052 (PLX tech.)
- using a FPGA
I'm now looking for information about the way to interface PCI with a FPGA.
Can somebody give me some tips on that subject?

Thanks by advance

Anthony Leroyer




(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

Kanda AT40 FPGA Development kit - Vincent Crabtree - Apr 8 8:31:00 2002

Hi all,
has anyone used one of these? Id like to email them direct if so.

Im having a few problems; kind of wish Id bought an Xsess board instead. THanks, Vincent
-----------------------------------------------------------
+ Vincent Crabtree, Researcher, Optical Engineering Group +
+ Loughborough University, United Kingdom +
+ Email: +
+ http://www.lboro.ac.uk/departments/el/research/optics/ +
+---------------------------------------------------------+

---------- ---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.338 / Virus Database: 189 - Release Date: 3/14/02 [Non-text portions of this message have been removed]



(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

Re: RE: RE: TCP/IP on FPGA - Anand Gopal Shirahatti - Apr 8 13:26:00 2002

Hi,

I Thank all of u who Took some Intrest towards this Problem.

Some of my explnations to Issues been put forth are as follows:

>You should be aware that there is are is a huge amount > of
>patent-filing going on with TOE technology and almost > anything
>you do will
>ultimately require royalties to some big NIC company.

1. Gary, I Guess u probably warned me at right time. I Never Thot
about it at all. Still I am not sure How serious are these Patent
Stuff...Eitherway I am not planning for any Commercial Prodcut
Either.

2. What I am actually trying out is an Experimental Methodology to
capture the Absolute Hardware Implementation of the TCP/IP
Specifications.

3. Though I am using the BSD's stack as reference.

>Why not? Your "CPU core" can be custom-tailored to
>the job at hand.

4. Eric, I Guess I am not sure How well the CPU custom tailored
will suit. As the considerable Effort needs to imparted to build
the Instruction set model that addresses the problem very well and
then Equal Efforts in Building the Hardware. After that still the
problem isn't over, As I shall not have any Compiler to target the
code to this platform may be I need to build one...Since Mannual
mapping of such an complex algoritham to a custom hardware seems
Impossible. This is Considerable Effort, May be I can't Afford.
Yes, this is very Long term solution..Good Commercial Devlopment
platfrom !!

5. Also the paradigm of CPU's which to the maximum address the
Issue of the parallelism at the Operation level. But this problem
requires the Parallelism at the "Control flow" level. So though
the Mulitple CPU cores address the same Issue, But I am not quite
Intersted since that is not my goal and Integration doesn't seem
my cup of Tea either.

>Step one: define your state machines. That's >necessary no
>matter
>what kind of hardware you're going to design. 6. Probably as Eric has said, the Step One to approach the problem
is to atleast come out with the Block level design and then Define
the state machines required and there Interaction since Single
Won't do. Then probably if required simple micro-codes without
much specific or fiexd micro-instructions format may be the good
solution, what I thot at this point.

Anyway shall keep the Group Informed. Please do send me any
further links or Ideas. Thanks.

Regards,
Anand.





(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )