Xilinx Demo Documentation

Jump to: navigation, search

A Demonstration of Treck Internet Protocols on Xilinx Evaluation Boards

Setting up and Evaluating Treck TCP/IP Performance and Capabilities Using the Xilinx ML507, SP605, and ML605 Embedded Development Platforms by Tim Carney and Aaron Bauer


Abstract

This document and the corresponding software demonstrate a variety of uses for the Treck TCP/IP stack and some of its accompanying protocols. The hardware and software design included in this demo couple the hardware advantages of the Xilinx Multi-Port Memory Controller (MPMC) and embedded Tri-Mode Ethernet MAC (TEMAC) with the highly optimized Treck TCP/IP stack to achieve exceptional networking performance over Ethernet. The performance test results included in this demo were collected using the same software and hardware designs that accompany this document so that they may be easily reproduced.

In addition to performance testing, this demo contains examples of an SNMP agent, Telnet server, FTP server, and Web server all developed by Treck Inc. Several other networking protocols are also offered. For a complete list of additional protocols please visit http://www.treck.com or contact the sales department at sales@treck.com.


Included Systems

The PowerPC 440 reference system provided is the ml507_ppc440_emb_ref which can be found in the demo kit, treck_demo_virtex5.zip

The Spartan 6 MicroBlaze reference system provided is the sp605_mb_emb_ref which can be found in the demo kit, treck_demo_spartan6.zip

The Virtex 6 Microblaze reference system provided is the ml605_mb_emb_ref which can be found in the demo kit, treck_demo_virtex6.zip


System Specifics

The ML507 PPC440 system is configured as:

PPC440 clock: 400 MHz
PLBv46 clock : 100 MHz

The SP605 MicroBlaze system is configured as:

MB clock: 100 MHz
PLB clock: 100 MHz

The ML605 MicroBlaze system is configured as:

MB clock: 100 MHz
PLB clock: 100 MHz


Hardware and Software Requirements

The hardware and software requirements for this demo package are listed below.

Hardware

Virtex 5 PPC system

  • Xilinx ML507 board
  • Xilinx Platform USB or Parallel IV programming cable
  • Cat5e or Cat6 Ethernet cable
  • RS232 serial cable

Spartan 6 MicroBlaze system

  • Xilinx SP605 board
  • 2 USB cables (one for JTAG and one for UART)
  • Cat5e or Cat6 Ethernet cable

Virtex 6 MicroBlaze system

  • Xilinx ML605 board
  • 2 USB cables (one for JTAG and one for UART)
  • Cat5e or Cat6 Ethernet cable


Software

Virtex 5 and Spartan 6 systems

  • Xilinx Platform Studio EDK 11.4
  • Xilinx Software Development Kit 11.4
  • PC running Linux or Windows, and a Gigabit capable Ethernet interface
  • iPerf installed on the PC, available from http://sourceforge.net/projects/iperf or

http://www.dast.nlanr.net/Projects/Iperf/

Virtex 6

  • Xilinx Platform Studio EDK 12.3
  • Xilinx Software Development Kit 12.3
  • PC running Linux or Windows, and a Gigabit capable Ethernet interface
  • iPerf installed on the PC, available from http://sourceforge.net/projects/iperf or

http://www.dast.nlanr.net/Projects/Iperf/


Introduction

The Treck TCP/IP stack

Treck Inc. and Xilinx have developed a partnership to deliver products that have been integrated and tested together. The Treck/Xilinx solutions offer a high performance internet protocols available for networking products. The Treck/Xilinx solution is able to achieve near line rates for Gigabit Ethernet using the performance tests described in this write up.

For the purposes of this demo, it is assumed the reader understands TCP/IP and Ethernet based networks. A thorough introduction is provided in the Treck TCP/IP User Manual.

This demo application uses the Treck protocol stack to provide the following protocols: TCP, UDP, IP, ARP, ICMP FTP, HTTP, CGI, Telnet, and SNMP.

The Treck stack is built as a library. This library is then linked with the software applications running on the Xilinx embedded processor. In the provided systems only a time-limited pre-compiled linkable library and associated include files are provided. The complete source is available from Treck Inc.


Examples Included in the Demo Application

A number of examples are bundled into the software application. It should be noted that the demo contains two separate applications: one that runs the Treck TCP/IP stack on top of Xilinx Xilkernel, and one that runs the Treck stack standalone, without an OS. Both applications will look and interact with the user the same way, but the two applications have different implementations which can be studied in the included source code. The software application source code is included in the /treck_demo_virtex5/TreckDemoSrc and /treck_demo_spartan6/TreckDemoSrc directories.


Both applications use the serial port UART to setup and run individual examples. The examples included are:

  1. Ping, TCP and UDP Loopback Tests: Simple tests that can be used to verify the TCP/IP stack is working properly and begin debugging device driver problems.
  2. Simple Blocking TX Client: A simple TCP client that will send a buffer of data and block until that buffer has been sent. This test will continue sending buffers until a set number of bytes has been sent and received by the peer.
  3. TCP TX Client with Callbacks: Similar to the previous test, this is another TCP client that will send a set number of bytes to the peer. In this test however, a callback function is registered with the client TCP socket. This function is called when the socket send queue is getting low. Inside of the callback function more data is sent to the peer ensuring the socket send queue always has data to send. This is more efficient than the Simple Blocking TCP Client.
  4. TCP RX Server: A simple TCP server that accepts a connection, receives and discards data from a client.
  5. UDP TX Client w/o Connection:' A simple UDP client that uses an unconnected socket to send UDP data to a server as fast as possible.
  6. UDP RX Server: A simple UDP server that receives UDP datagrams from a client as fast as possible and discards them.
  7. HTTP Server Toggle: Enable/disable the Treck HTTP server.
  8. FTP Server Toggle: Enable/disable the Treck FTP server.
  9. Telnet Server Toggle: Enable/disable the Treck Telnet server.
  10. SNMP Agent Toggle: Enable/disable the Treck SNMP agent.


Treck Inc.

Since 1997, Treck has been designing, distributing and supporting real-time embedded internet protocols for worldwide technology leaders. Treck protocols are built specifically for embedded systems, from the ground up, not derived from public domain code, so you can be certain that your device will outperform, be more reliable and flexible than the competition.

Additional Products Include:

  • TCP/IPv4
  • TCP/IPv4/v6 Dual Stack
  • IPsec/IKE
  • SSL
  • DHCPv4/v6
  • PPP/PPPoE
  • HTTP/HTTPS
  • FTP/FTPS/TFTP
  • Telnet
  • IGMP
  • Auto IP
  • DNS Resolver
  • SNMPv1/v2c/v3
  • SMTP/POP3
  • NAT
  • Mobile IP
  • Universal Plug and Play


Test Setup

Running the Application

Figure 17: Treck Demo Main Menu

Figure 17: Treck Demo Main Menu

Whether the demo is run on Xilkernel or standalone, using PowerPC or MicroBlaze, the application will look the same to the user. The screen shown above will be displayed when the software starts. This demo is configured to communicate with a PC over the serial port, meaning that a terminal emulator such as Tera Term, HyperTerminal, PuTTY, etc. that supports serial communication is required to interact with the software running on the board. If Linux is being used and the serial communication program can't open the interface, see the Troubleshooting section. Use the settings in the table below to properly setup serial communication with the board.

Port COM port
Baud Rate 115200
Data 8-bit
Parity None
Stop 1-bit
Flow Control None

The Network MTU must be set correctly for the maximum sized packets expected on the Ethernet network. The application defaults to an MTU of 1500 but if the network interface card being used in the test supports jumbo frames, the MTU can be set to 9000. See the Settings Menu section below for more details.


Basic Function

The default IP address of the Xilinx board running the Treck demo is 192.168.2.20. When the demo is done initializing and prints the main menu it will respond to ping requests. If the board does not respond to a ping, check the network connections and be sure the network status LED's on the board match the network settings. The start-up screen will show the speed that the board has auto-negotiated with the PC.

The program used for testing data transfer speeds is iPerf. iPerf is an open source network performance benchmarking application available [here]. iPerf opens a socket and either sends or receives TCP or UDP packets as fast as possible. The program attempts to send the maximum size payloads in the data packets it sends out.

Note Note: These tests attempt to find the maximum network performance. They should be run on an isolated network. Sending large amounts of network traffic on a corporate network is not recommended.


Settings Menu

Figure 18: The Settings Menu

Figure 18: The Settings Menu

The settings menu is accessed by choosing option 0 from the main menu. It allows the user to change different settings to properly setup or experiment further with the Treck demo. Each of the utility menu selections are described below:

  • Setup status dump - prints a summary of settings including IP address, netmask and MTU as well as frame statistics (i.e., number of frames transmitted, received etc.)
  • Csum enable/disable - enable/disable checksum offloading
  • Set IP Address - sets the IP address of the interface
  • Set iPerf IP Address - sets the IP address of the computer running iPerf for performance testing with TCP and UDP
  • Set PHY address - sets the PHY address, must be 0-31
  • Set Network MTU - sets the MTU. Use 9000 to enable Jumbo frames, 1500 otherwise.
  • Set Interrupt Coalescing - Enable Interrupt Coalescing
  • Set TX Test File Size - sets the size of the file sent using the example client applications in the main menu. The new file size must be entered in megabytes.
  • Set TCP Port - sets the TCP port
  • Set Socket buffer size - sets the socket buffer size
  • Close and open the interface - closes and opens the interface
  • Set speed to 10, 100, 1000Mbps - sets the link speed of the interface. 0 can be used to initiate auto-negotiation.
  • Exit Settings Menu - returns to the main menu


Setting Defaults

Most of the program settings can be changed using the Settings Menu however, the application software can be modified to make changes permanent so they do not have to be manually changed every time the program is run or restarted.

The file defaults.h in the application source code can be modified from the SDK to set most of the default parameters.


Treck Loopback Tests

Choosing this option from the main menu will run three sets of tests: Ping, TCP and UDP loopback tests. This tests can be run to ensure the proper operation of the hardware and software used in the demo.


Transmit Tests

There are three applications that test transmission speed: Simple Blocking TX Client, TCP TX Client with Callbacks and UDP TX Client w/o Connection, accessible from the main menu via options 1, 2 and 4 respectively. Each of these applications operate as a client that connects to a server running on a PC. For TCP, once a connection has been established the client sends data as fast as possible to the server running on the PC. The UDP client will begin sending data immediately. The IP address of the server to which these clients will attempt to send data can be set in the settings menu using menu option 3, "Set iPerf IP Address," (the default is 192.168.2.1) Either set your PC's Ethernet adapter to the default address, or use this setting to change the address the board will attempt to connect to. The program recommended for testing data transfer speeds is iPerf as mentioned above. The instructions below will assume iPerf is being used as the server on the PC.


To run the test:

1. Run iPerf from a command line using one of the following commands:
Note Note: These commands will only work if iPerf is defined in the PC's PATH variable or if they are run from the directory containing the iPerf executable
a. For either of the TCP clients
i. Jumbo Frames (9000 MTU)::
iperf -l 8942 -p 5001 -w 1048576 -M 8942 -s -i 5
ii. Standard Frames (1500 MTU)::
iperf -p 5001 -w 1048576 -s -i 5
b. For the UDP client
i. Jumbo Frames (9000 MTU)::
iperf -p 5001 -s -i 5 -u -w 256m -l 8972
ii. Standard Frames (1500 MTU)::
iperf -p 5001 -s -i 5 -u -w 256m -l 8972
2. At the "Enter Selection: " prompt in the application's main menu, type 2, 3 or 5 depending on which client is to be tested, followed by the enter key The output of iPerf should look something like this:
Figure 19: iPerf Output for TCP Client

Figure 19: iPerf Output for TCP Client

The throughput will vary slightly. By default the client is set to send 10GB of data. This can be adjusted in the settings menu via option 7, Set TX Test File Size where the new file size entered must be in megabytes. iPerf will report the transfer rate every 5 seconds along with the amount of data received.


Receive Tests

The demo has two applications that can be launched from the main menu to test the speed the at which board can receive data: TCP RX Server and UDP RX Server, options 4 and 6. Once started, the RX server will wait to receive data from a client running on a PC. After starting the client on the PC it will send data as fast as possible to the board. The IP address of the client from which these servers will attempt to receive data can be set in the settings menu using menu option 3, "Set iPerf IP Address," (the default is 192.168.2.1) Either set your PC's Ethernet adapter to the default address, or use this setting to change the address the board will attempt to connect to. The program recommended for testing data transfer speeds is iPerf. The instructions below will assume iPerf is being used as the client on the PC.

Note Note: These tests attempt to find the maximum network performance. They should be run on an isolated network. Sending large amounts of network traffic on a corporate network is not a good idea.

To run the test:

1. At the "Enter Selection: " prompt in the application's main menu, type "4" or "6" depending on which client is to be tested, followed by the enter key
2. Run iPerf from a command line using one of the following commands:
Note Note: These commands will only work if iPerf is defined in the PC's PATH variable or if they are run from the directory containing the iPerf executable.
Note Note: If the board is set to an IP address other than the default, that IP address must be used in the commands below instead of 192.168.2.20
a. For the TCP RX Server
i. Jumbo Frames (9000 MTU):
iperf -i 5 -l 448000 -p 5001 -w 1048576 -M 8960 -c 192.168.2.20 -t 3600
ii. Standard Frames (1500 MTU):
iperf -i 5 -l 73000 -p 5001 -w 1048576 -M 1460 -c 192.168.2.20 -t 3600
b. For the UDP RX Server
i. Jumbo Frames (9000 MTU):
iperf -u -i 5 -l 8972 -w 256m -C -c 192.168.2.20
ii. Standard Frames (1500 MTU):
iperf -u -i 5 -w 256m -C -c 192.168.2.20

The output of the application should look something like this, adding a line for each gigabyte as it is received:

Figure 20: TCP Rx Server Output

Figure 20: TCP Rx Server Output


FTP Server

This demo ships with an FTP server that can be used to manipulate files on the board. Turning it on and off is as easy as selecting option 8 from the main menu. The application will report whether the FTP server has been turned on or off. Logging on to the FTP server can be done through an FTP client like FileZilla or through the command line. Just connect to the default address, 192.168.2.20, or the IP address the board has been set to. The login credentials are below.

This demo uses Treck's example RAM file system. The memory for this file system comes from the simple heap which is only 12 megabytes, meaning the FTP server will only have 12 megabytes of storage. The simple heap size can be increased in trsystem.h by editing the TM_SHEAP_SIZE macro, but the default is 12 megabytes. The Treck FTP server can also be used with other file systems. See the FTPD_API section for more details.

Note Note: The files placed on the board over FTP are being placed in the board's RAM. This won't interfere with the operation of the application, but since RAM is volatile memory, the files will be gone after the board is power cycled.
username treck
password treck
Figure 21: FTP Login

Figure 21: FTP Login


HTTP Server

The demo also ships with an HTTP server. A demo web page is included and discussed in more detail in the Web Page Demo section below, but almost any simple web page will work. Just use the FTP Server to put the web page on the board, start the HTTP server using option 7 from the main menu and type the IP address of the board into the URL field in a web browser.

The application configures the HTTP server to expect index.htm to be in the root directory of the board. index.htm must be the starting point for the web page and it must be present in the root directory for the HTTP server to work.

Web Page Demo

By using the FTP server in conjunction with the HTTP server, the demo web page included with this demo can be hosted on the board and viewed in a web browser on a PC. Follow the procedure below:

1. At the "Enter Selection: " prompt in the application's main menu, type "8", followed by the enter key to turn on the FTP server.

2. Repeat step one using option "7" to turn on the HTTP server.

3. Using your FTP client of choice, copy the contents of /treck_demo_virtex5/demopage into the root directory of the Xilinx board.

Note Note: Do not put the demo page folder onto the board, put the contents of demo page folder onto the board. index.htm must be in the root directory of the board for the HTTP server to find it.

4. Open a web browser on the PC and type the IP address of the board into the URL field.

Web page features:

  • Under the NETSTAT TABLES heading on the left hand side of the page, the demo web page uses CGI to generate a table of TCP and UDP sockets, an ARP table, a routing table and a device table all of which are generated dynamically from the hardware when each link is clicked.
  • A demonstration of CGI form processing
  • Use of CGI to control and read from hardware peripherals: The demo web page can be used to turn LED's on the board off and on as well as read the dip switches located to the right of the LCD.


Telnet Server

The Treck demo also includes a telnet server that can be accessed using a telnet client on the PC. The server can be started using option 9 from the main menu. To setup telnet client on the PC, just supply the IP address of the board and connect. The client will sent a welcome message and a prompt. There are several available commands. tcp, udp and arp print the tcp, udp and arp tables. devices will print the device table. Other commands have been implemented as well; enter help at the prompt for a more complete list.


SNMP Agent

An SNMP agent can be started from the main menu using option 10. The Treck demo is configured to use SNMPv2. SNMPv3 is available from Treck, just not in this demo. Contact sales@treck.com for more information.

For testing, net-snmp is recommended. It is available for Linux, Mac OS, and Solaris as well as Windows through Cygwin. Several tutorials are available for net-snmp so this write-up won't go into too much detail, but two simple commands to ensure everything is up and running properly are below. If using an IP address other than 192.168.2.20 for the board, make sure to use that address in the command instead.

snmpget -v 2c -c public 192.168.2.20 SNMPv2-MIB::sysUpTime.0
snmpwalk -v 2c -c public 192.168.2.20


Optimizing the PC Network Connection

Windows XP Optimizations

The Windows box PC will need to have a Gigabit capable Ethernet card. The drivers and card must also be able to send and receive jumbo frames.

To enable jumbo frames in the TCP/IP stack in Windows XP, Windows 2000, and Windows Server 2003:

Edit the registry via regedit.exe and navigate to

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Increase the TCP/IP window size to 132k and enable RFC 1323 window scaling:

  • Add a registry DWORD named TcpWindowSize, and enter 131400 (decimal)
  • Add a registry DWORD named Tcp1323Opts, and set the value to 1.

Increase the TCP buffer sizes:

  • Add a registry DWORD named ForwardBufferMemory, and set the value to 80000
  • Add a registry DWORD named NumForwardPackets, and set the value to 60000


Linux Optimizations

This information is taken from a more complete write up that can be found in the article, How to Achieve Gigabit Speeds with Linux.

Kernel Configuration

ftxtqueue length high

There are settings available to regulate the size of the queue between the kernel network subsystems and the driver for network interface card. Just as with any queue, it is recommended to size it such that losses do no occur due to local buffer overflows. Therefore careful tuning is required to ensure that the sizes of the queues are optimal for your network connection.

These settings are especially important for TCP as losses on local queues will cause TCP to fall into congestion control - which will limit the TCP sending rates. Meanwhile, full queues will cause packet losses when transporting udp packets.

There are two queues to consider, the txqueuelen; which is related to the transmit queue size, and the netdev_backlog; which determines the recv queue size.

To set the length of the transmit queue of the device. It is useful to set this to small values for slower devices with a high latency (modem links, ISDN) to prevent fast bulk transfers from disturbing interactive traffic like telnet too much.

Users can manually set this queue size using the ifconfig command on the required device. Eg.

/sbin/ifconfig eth2 txqueuelen 2000

The default of 100 is inadequate for long distance, high throughput pipes. For example, on a network with a rtt of 120ms and at Gig rates, a txqueuelen of at least 10000 is recommended.


kernel receiver backlog

For the receiver side, we have a similar queue for incoming packets. This queue will build up in size when an interface receives packets faster than the kernel can process them. If this queue is too small (default is 300), we will begin to loose packets at the receiver, rather than on the network. One can set this value by:

/sbin/sysctl –w sys.net.core.netdev_max_backlog=2000


TCP cache parameter (Yee)

Linux 2.4.x tcp has a function to cache tcp network transfer statistics. The idea behind this was to improve the performance of tcp on links such that it does not have to discover the optimal congestion avoidance settings (ssthresh) of every connection. However, in high speed networks, or during low network congestion periods, a new tcp connection will use the cached values and can perform worse as a result.


In order to rectify this, one can flush all the tcp cache settings using the command:

/sbin/sysctl –w sys.net.ipv4.route.flush=1

This flushes all routes, and is only temporary - ie, one must run this command every time the cache is to be emptied.


SACKs and Nagle

SACKs (Selective Acknowledgments) are an optimization to TCP which, in normal scenarios, considerably improves performance. In Gigabit networks with no traffic competition these have the opposite effect. To improve performance they should be turned off by:

/sbin/sysctl -w net.ipv4.tcp_sack=0

The Nagle algorithm should be turned on. This is the default value. You should verify that your application does not disable Nagle by setting the TCP_NODELAY socket option.


Socket Buffers

TCP uses what it calls the "congestion window" or CWND [4] to determine how many packets can be sent at one time. The maximum congestion window is related to the amount of buffer space that the kernel allocates for each socket. For each socket, there is a default value for the buffer size, which can be changed by the program using a system library call just before opening the socket. If the buffers are too small, like they are when default values are used, the TCP congestion window will never fully open up. If the buffers are too large, the sender can overrun the receiver, and the TCP window will shut down.


Socket buffers and bandwidth delay product

The optimal socket buffer size is twice the size of the bandwidth * delay product of the link:

socket buffer size = 2* bandwidth * delay

Estimating an approximate delay of the path is straightforward with a tool such as ping (see tools section below). More difficult is to have an idea of the bandwidth available. Once again, you shouldn't attempt to transfer Gigabit/s of data when you haven't at least minimal control over all the links in the path. Otherwise tools like pchar and pathchar can be used to have an idea of the bottleneck bandwidth on a path. Note that these tools are not very reliable, since estimating the available bandwidth on a path is still an open research issue.

Note that you should change the socket buffer size in both sender and receiver with the same value. To change the buffer socket size with iperf you use the -W option.

When you are building an application you use the appropriate "set socket option" system call. Here is an example using C (other languages should use a similar construction):

int socket_descriptor, int sndsize; err = setsockopt (socket_descriptor, SOL_SOCKET, SO_SNDBUF, (char*)&sndsize, (int)sizeof(sndsize));

and in the receiver

int socket_descriptor, int rcvsize; err = setsockopt (socket_descriptor, SOL_SOCKET, SO_RCVBUF, (char*)&rcvsize, (int)sizeof(rcvsize));

to check what the buffer size is you can use the "get socket option system call:

int sockbufsize=0; int size=sizeof(int); err=getsockopt(socket_descriptor, SOL_SOCKET, SO_SNDBUF, (char*) &socketbufsize, &size);


socket buffer memory queue limits r|w mem (default and max)

If your program asks for more socket buffer memory than the kernel is configured to give you, the program won't get it. You can adjust the maximum value of socket buffer memory for the system by:

/sbin/sysctl -w net.core.rmem_max= VALUE

Where VALUE should enough for your socket buffer size.

You should also set the "write" value.

/sbin/sysctl -w net.core.wmem_max= VALUE

/sbin/sysctl -w net.ipv4.tcp_mem= MIN DEFAULT MAX

This should be done both in the sender and the receiver.


Troubleshooting

Non-Platform Specific

Problem: After right clicking a project and selecting Run As->Run on Hardware, the SDK displays the error message, "Launch failed: no binaries"

Solution: This error message occurs when the SDK can't find the binary file to run on the board. This is easily solved by explicitly specifying a run configuration. Instead of selecting Run As->Run on Hardware, choose Run As->Run... From the Run... window, the run configuration that points to the proper .elf file can be selected. Remember the run configuration must match the build configuration. See From the SDK in section Programming the FPGA with the Application File (.elf) for more details.


Problem: While running the UDP or TCP performance tests, the application hangs or stops sending data before the transfer file size has been reached.

Solution: Ensure that the proper iPerf command is being used, e.g., double check that if a TCP server is being run in the demo that a TCP client is being run from iPerf. Make sure that the PC is configured to use the correct MTU, standard 1500 byte frames or 9000 byte frames for jumbo frames by following the instructions in the Optimizing the PC Network Connection section. If the hardware is not capable of using jumbo frames make sure to use 1500 byte frames. Jumbo frames can be disabled by using the Settings Menu in the demo application running on the board. To disable jumbo frames type "5 1500" at the settings menu prompt. This will set the MTU to 1500 instead of 9000.


Problem: The PHY has trouble linking during the application start up or exhibits other strange behavior.

Solution: Ensure that the PHY jumpers are properly configured on the board. Use the default settings (GMII/MII to copper) described in section 21, 10/100/1000 Tri-Speed Ethernet PHY of the ML505/ML506/ML507 Evaluation Platform User Guide (UG347).


Problem: When building the application for XilKernel on a Spartan 6 device with EDK 11.4 the build fails with the following error:

c:/SDK/appnote/treck_on_xilkernel/microblaze_0/lib/libxil.a(microblaze_interrupt_ha ndler.o): In function `__interrupt_handler': / cygdrive/c/SDK/appnote/treck_on_xilkernel/microblaze_0/libsrc/standalone_v2_00_a/sr c/microblaze_interrupt_handler.c:79: multiple definition of `_interrupt_handler' c:/SDK/appnote/treck_on_xilkernel/microblaze_0/lib/libxilkernel.a(entry.o):/cygdriv e/c/SDK/appnote/treck_on_xilkernel/microblaze_0/libsrc/xilkernel_v4_00_a/src/src/ar ch/microblaze/entry.S:348: first defined here /cygdrive/c/Xilinx/11.1/EDK/gnu/microblaze/nt/bin/../lib/gcc/microblaze-xilinxelf/ 4.1.1/../../../../microblaze-xilinx-elf/bin/ld: Disabling relaxation: it will not work with multiple definitions

Solution: This problem has been reported to Xilinx. At the time this document was released there is no official fix from Xilinx. To workaround this issue you can adjust the application's compiler optimization settings to use -O2.


Problem: No output is seen on the terminal window.

Soluition: Ensure that the RS232_UART is selected as the stdin and stdout in the OS and Libraries section of Software Platform Settings.


Linux

Problem: While compiling the Software Platform, the SDK can't find Treck library even though it has been placed properly into sw_services

Solution: Because the default installation directory for the Xilinx tools is often in /opt/, root permissions will be required to copy the Treck libraries into the proper folder. If this is not done carefully, when the SDK is run as a user, the SDK won't have permission to read the files inside these folders. Use the system's file browser to modify the permissions of both Treck libraries to give the user read and write permissions on both Treck library folders and all of their sub-directories. From terminal, the command chmod -R o+rwx location_of_treck_library can be used instead.


Problem: Eclipse periodically displays error message saying it "Could not save master table"

Solution: This was most likely caused by opening a user's workspace as root and then going back to open the workspace as a user. This is similar to the problem above in that it has to do with permissions. The files the SDK generates to periodically save the workspace were created as root, meaning that the user no longer has permission to change them. This can be fixed by editing the permissions on the workspace folder and all of it's sub-directories to give the user read/write/execute permissions on all of the files in those folders. This can be done from the file browser or terminal using chmod -R o+rwx location_of_workspace


Problem: Serial communication program can't open the serial device

Solution: In some Linux distributions, the serial communication devices ttyS0, ttyS1, ttyS2, etc. can only be accessed by users in the group dialout. If the serial communication program is being run as a user that isn't in the group dialout, running the command usermod -a -G dialout user_name as root where user_name is replaced with the user's actual username should fix the problem. After running the command, the user must log out and back in again before the change will take effect.


Problems with the Xilinx 12.2 SDK

Please click here for a list of known issues with the 12.2 version of the Xilinx SDK.

When using the Windows version of the Xilinx 12.2 SDK we encountered what we believe is a interrupt controller issue which would cause random lock-ups on the hardware. We were unable to find an appropriate solution to this issue, so we upgraded to the Xilinx 12.3 SDK.


Results

The test results can be found here.


Conclusion

The demo provided demonstrates the versatility and speed of the Treck TCP/IP stack running in many applications utilizing protocols including TCP, UDP, HTTP, FTP, Telnet and SNMP across different software platforms and architectures. The example code not only provides a method for obtaining performance numbers, but serves as an excellent starting point for using the Treck TCP/IP stack in combination with Xilinx hardware and tool-sets. Combined with the Xilinx Tri-Mode Ethernet MAC (TEMAC), the Treck stack is able to achieve exceptional performance in embedded applications.

For more information about Treck or purchasing information, visit http://www.treck.com or contact sales@treck.com.


References

XAPP1041: Reference System: XPS LL Tri-Mode Ethernet MAC Embedded Systems for MicroBlaze and PowerPC Processors

XAPP1043: Measuring Treck TCP/IP Performance Using the XPS LocalLink TEMAC in an Embedded Processor System

UG111: Embedded System Tools Reference Guide EDK 11.3.1

UG347: ML505/ML506/ML507 Evaluation Platform User Guide

Virtex-6 FPGA Embedded Kit Reference Design and Documentation

OS and Libraries Document Collection (UG 643 April 19, 2010)


Revision History

Date Version Revision
8/19/09 0.9 Draft release to partners
8/27/09 1.0 Initial release to treck.com, demo kit only includes ML507 hardware design
1/29/10 2.0 Updated to include SP605 demo
8/10/10 3.0 Converted to MediaWiki format. All future revision history will be maintained by the wiki.
1/14/11 4.0 Updated numbers for ML605 demo


Notice of Disclaimer

ALL MATERIALS, INFORMATION, DEMO SOFTWARE, AND SERVICES SET FORTH IN THIS DEMO PACKAGE ARE PROVIDED "AS IS" WITH NO WARRANTY OF ANY KIND. TRECK DISCLAIMS ALL WARRANTIES OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, IMPLIED WARRANTIES OF MERCHANTABILITY, AND FITNESS FOR A PARTICULAR PURPOSE OR NON-INFRINGEMENT. TRECK DOES NOT WARRANT THAT THE CONTENT OF THIS DEMO PACKAGE, OR ANY DEMO SOFTWARE ASSOCIATED THEREWITH, IS ACCURATE, RELIABLE, CORRECT, FREE OF ERRORS OR DEFECTS. YOUR USE OF THIS DEMO PACKAGE IS SOLELY AT YOUR RISK. TRECK AND ITS PARTNERS SHALL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, PUNITIVE, INCIDENTAL, SPECIAL OR CONSEQUENTIAL DAMAGES THAT RESULT FROM THE USE OF THIS DEMO PACKAGE OR DEMONSTRATION SOFTWARE AVAILABLE VIA USE OF THIS DEMO. THIS LIMITATION APPLIES WHETHER THE ALLEGED LIABILITY IS BASED ON CONTRACT, TORT, NEGLIGENCE, STRICT LIABILITY OR ANY OTHER BASIS, EVEN IF TRECK HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.