Problems 1: What are the differences between UA API and standard user space API (Socket, Libnet/Libpcap)?

With UA API in user space, the metadata of the received packet can be got and the metadata of the packet can be set before sending. According to the UM specification, UA applications are able to get the physical port of received packets, precise received timestamp and other information. When sending a packet, the output port can be set in metadata. However, it is difficult to get these information with socket, Libnet/Libpcap API.

Moreover, UA can get the specified the data flows with the flow table in FPGA hardware. Furthermore, the packet processing functions can be offloaded into FAST UM for hardware acceleration.

In conclusion, UA APIs are suitable for developing various packet processing applications, such as L2/L3 packet switching, firewall, Intrusion Detection System(IDS) and other middlebox applications.

Problem 2: Are UA applications bound to the customized to FAST platforms?

UA applications are not bound to the FAST platforms including FAST UM. Theoretically, any host systems with network interface card support the UA applications. To be specific, similar to OpenvSwitch datapath module, it only needs to insert a Linux kernel module simulating the FAST UM.

At the receiving end, this kernel module classifies the received packets with the configured rules in UA-M (UA manager). For the packets to be transmitted into protocol stack, it allocates a skbuf buffer (the standard data structure used in protocol stack) for each packet. For the packets sent to specific UA, it construct a metadata for each packet, followed by sending the packets into user space with the communication mechanism (such as netlink). At the transmitting end, the module sends the packets to the specified output port with the metadata.

Problem 3: How to read/write the hardware registers?

Developers can read/write the hardware registers with the reg_wr tool provided by the Fast software development environment. The detailed operations are shown as follows:

After loading the kernel driver, users should switch the current directory into fast/tools/reg_wr directory. Then the value of register whose address is “addr” could be acquired by inputing “./reg_wr rd addr”. Similarly, by executing “./reg_wr wr addr value”, the “value” is written into the register whose address is “addr”. After the value is written into register, the value of the register would be read automatically for the comparison with the value that user inputs. If both of the values are same, it prints “OK”. Otherwise, it prints ”Err”.

The registers users can access are listed as follows:

Version register: OpenBox-S28 platform: 0x38; NetMagic08 platform: 0x0;

Default register: OpenBox-S28 platform and NetMagic08 platform: 0x201f8;

General Action register: OpenBox-S28 platform and NetMagic08 platform: 0x20000 + 0x8*flow table number. For example: the address of action register in the first flow entry is: 0x20000 + 0x8 * 1 = 0x20008

Problem 4: How to get the version number of FAST?

The FAST is a software-hardware co-design architecture. The software mainly includes libreg, librule and libua developing libraries. The hardware consists of FPGA OS and UM. Both of software and hardware have its version number respectively. The methods to get the version numbers are shown as follows:


  • Libreg: the version number of Libreg library is shown by calling fast_init_hw();
  • Librule: the version number of Librule library is shown by calling init_rule();
  • Libua: the version number of Libua is shown by calling fast_ua_init();

OpenBox-S4 driver: when users input “modinfo /mnt/openbox/openbox-s4.ko”, the system would print these information:

Hardware: Users get the version number of hardware modules with the “debug” tool in fast/tools/debug

  • FPGA OS: the version number of FPGA OS is shown by inputting “debug 43c00000 0x1000 0”
  • UM: the version number of UM is shown by inputting “debug 43c00000 0x1000 8”

 Moreover, all the version numbers of hardware/software components can be acquired with FAST_version tool.

  • Libreg: input “./version libreg”;
  • Libua: input “./version libua”;
  • Librule: input “./version librule”;
  • UM: input “./version um”;
  • FPGA OS: input “./version fpgaos”.

Problem 5: Install dependent libraries when setting up cross-compiling environment

Reason: the current OS is 64 bit, lacking of dependent libraries of 32 bit OS

Solution: Users only need to input two commands when connecting with Internet:

  • sudo apt-get update
  • sudoapt-get install libgtk2.0-0:i386 libxtst6:i386 gtk2-engines-murrine:i386 lib32stdc++6libxt6:i386 libdbus-glib-1-2:i386 libasound2:i386

Problem 6: Permission problems when setting up cross-compiling environment

Reason: “dpkg-reconfigure” command is not supported in general users mode

Soluction: input “dpkg-reconfigure-plow dash”. Then it shows in the figure below:

Finally, select “No”, the problem would be solved.

Problem 7: Makefile could not be generated when configure the compiling environment

Reason: The version of built-in intltool tools in OS is old, which could meet the requirement of configuration.

Solution: input the command in figure below.

Problem 8: The Libpcap/Libnet library could not found when setting up cross-compiling environment

Reason: The lib library is not installed so that the corresponding library files could not found by linker.

Solution: Uncompressing the lib.tar.gz in arm-xilinx-linux-gnueabi folder of cross-compiling environment.

Problem 9: Bugs after compiling L2 switching application

Reason: It uses old library files when compiling project.

Solution: Delete the header files and library files of libreg, librule, libua in arm-xilinx-linux-gnueabi

Problem 10: Failed to generate bitstream in OpenBox-S4 hardware project

Solution: Delete the selected items below

Problem 11: It prints “times out” error and UA could not send packets

Reason: The hardware code is burned again when users reboot OS. The previous hardware code that has negotiated states with software driver is overlapped. Therefore, the software driver could not send packets to hardware through DMA path. When the sending buffers are used up, it prints “times out” error.

Solution: Users rename the openbox-s4.ko driver in /mnt/openbox path so that the driver could not be loaded automatically. After burning the hardware code, users should use “insmod /mnt/openbox/driver name” to insert driver.