Execution and Development Environment

Simulation Mode

A way to evaluate Digenis is with the use of the transactor. The transactor is a cycle and data accurate software model of the IXP1200 microengines, memory, buses and peripherals. The transactor runs under control of the Developer Workbench which also provides an IX Bus device simulation tool that generates network traffic streams onto the IX Bus interface of the transactor. We used the Intel-supplied development environment on a PC running the Windows OS. This is the first step towards developing an application to run on the IXP1200. First, you verify that your application does not have obvious flaws using the Developer Workbench and after that, you take the next step that is to try to run the application on real hardware.

Figure 1: Configuration of Gigabit Ethernet Port

Figure 2: Configuration of Fast Ethernet Port

Figures 1 and 2 show the configuration of the Gigabit Ethernet and Fast Ethernet ports of the IXP1200EEB used during debugging and evaluation of Digenis. As you observe, we have set a huge value to the receive buffer size. We have done this, because, due to a bug in the simulator, if this buffer overflows, the simulation fails.

Hardware Mode

As mentioned before, in this mode Digenis executes on the the IXP1200EEB. This board consists of an Intel IXF440 Multiport 10/100 Mbps Ethernet Controller, an Intel IXF1002 Dual Port Gigabit Ethernet Controller, 32 Mbytes of SDRAM, 2 Mbytes of SRAM and a serial port. As shipped from the factory, the IXP1200EEB is configured to operate as a stand-alone system in a supplied passive PCI backplane connected to a simple 100 Mbps Ethernet line card. Due to bugs contained in the software provided by Intel we decided to use an open source software called VERA.

VERA requires an active PCI backplane, so, we had to reconfigure the board. Specifically, we changed the board jumpers so that it neither generated the global PCI reset signal at power-up nor acted as the PCI arbitrer – both of these functions are performed by motherboards. We also used the firmware supplied by VERA (and programmed it into the on-board Flash EEPROM) which assumes that the board is installed on a PC – on power-up it requests a region of the PCI bus address space from the BIOS, opens a window from the PCI bus to the SDRAM so that the Pentium can download code directly onto the board. The firmware jumps to an entry point in this downloaded code when it receives a signal from the Pentium.

Figure 3: VERA's IXP1200 Toolchain

We used the Linux OS for the development environment. We used the GNU C tools for the Pentium and StrongARM processors. The Pentium compiler is native, while the StrongARM compiler is a cross-compiler supplied by the VERA project. We used the Intel-supplied microcode assembler to assemble the IXP1200 microcode. We ran the microcode assembler on the WINE Windows emulation environment on Linux. The toolchain to create an executable image for the IXP1200 is shown in Figure 3.

Figure 4: Running an Executable Image on the IXP1200EEB

We have used a device driver for the IXP1200EEB implemented in the VERA project in the form of a Linux kernel module. The driver exports a /dev/vera character device. Through its ioctl interface, this device is used to download code from the user space to the IXP1200EEB and give access to the memory and registers of the board during debugging. Figure 4 illustrates how the sgo tool loads and runs an executable image on the IXP1200.