xapp807-Minimal Footprint Tri-Mode Ethernet MAC Processing Engine

The limit is CPU cycles. Software guys have done lots of work on that area - mostly in the context of a full OS which normally has the extra overhead of copying data between user and kernel address spaces.

How you make it go faster depends upon what you want to do.

--
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
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.

I can't see any OS related sw in the document. Ultracontroller2 runs tcp/ip stack and httpd from 16kB Instruction cache. I don't think there is an OS (kernel-user space) in xapp807 . User application software is running as direct executable. (probably)

But if your application runs on ML403 board with Linux, it will use external SDRAM which is slower than Inst. cache. Also Linux is slower than direct executable.

But these excuses does not mean bottleneck is not sw.

yusuf

Hi , when you create a TCP/IP stack, the most timing consuming process is the CRC calculation of the IP payload(when is done in SW). The Xilinx Embedded MAC has been tested with the treck TCP/IP.

and it seems with this HDL TCP/IP stack you can up to

700 mbps (don't remember exactly the bandwith achieved)

The MAC itself gives you no limitation. For example in a full duplex mode the MAC just add "55 55 55 55 55 55 DA" at the beginning of the frame and add the 4 bytes CRC at the end.

The most time consuming problem when you create a TCP/IP stack is the CRC calculation. The xapp807 also uses the uIP TCP/IP stack that gives you a lot of limits. for example (if I remember) to save memory the SW buffer for TX and RX is the same. Another limitation is: TCP uses a sequence number to check that the data transmitted are received (on the far end). uIP use a SW state machine that checks that the TCP packet has arrived before send the next one, this SW machine is quite simple, it does work but is very slow.

So, the answer to your question is To increase the bandwith you need a TCP/IP stack in HDL that creates the TCP/IP stack for you.

At moment I'm currently designing a TCP/IP stack in HDL, in my case the application is a VOIP application, to do testing RFC2544 type at a

1Gbps.

good luck, Francesco

XAPP807 is not targeted towards high-speed communication. It is intended to be used in control type applications, i.e. in environments where you want to control or monitor a system from within the FPGA by using the smallest amount of FPGA resources possible. The whole web server uses one embedded PowerPC, two Virtex-4 FIFOs, 1 Tri-mode Ethernet MAC, 20 LUTs and 20 FFs.

There are two limiting factors in this setup.

1. The data path is only 8 bits wide which matches the data port of the TEMAC. However, with that the PPC needs to read every single byte out of the receive FIFO and send every single byte to the transmit FIFO. By changing the design and adding a little bit more logic the data path can be widened to 32 bits reducing the read/write overhead by a factor four.

1. The FIFOs are kept small. There is one 2KB FIFO each for receive and transmit. The software is written as a single control loop, i.e. one Ethernet Frame at a time. With that, there is receive FIFO overflow at higher transfer rates. Again, with some additional resources the FIFO depth can be enlarged and performance improved.

The design has intentionally be kept small and simple but still versatile. While it connects to 10/100/1000 Mpbs networks to fulfill its purpose of monitoring and control through a web server it does not mean it can sustain data rates at these link speeds.

If you are looking for high-speed data transfer over TCP/IP check out XAPP535 and XAPP536.

- Peter

snipped-for-privacy@gmail.com wrote: