In order to make the Silicon Firewall system work properly, various parameters have to be written to the peripherals. In this specific system, there are two peripherals that need to be initialized, the CS8900A and the CAM.
5.5.1.1 CS8900A Initialization
The Silicon Firewall system design uses the example hardware Nios 32-bit CPU reference design for a single daughter card in the Nios EDK CD-ROM as the starting point. In the reference design, the CS8900A has been connected to the Nios CPU and configured already. After loading the reference design to the Altera FPGA, the Nios CPU can communicate with the CS8900A by running the example source file. In the SDK of the reference design, the “lib” folder contains the C program that initialized the CS8900A.
In the Silicon Firewall design, the configuration of the CS8900A was changed. There are two differences between the reference design configuration and Silicon Firewall system configuration.
1. In the reference design, the interrupt pin is not activated in the configuration program. However the interrupt from the CS8900A is a very important signal for the hardware in the Silicon Firewall system, so additional configuration data are written into the internal registers of the CS8900A to enable the interrupt pin. 2. In the reference design, the CS8900A is configured for promiscuous mode, in
which case it will accept all receive frames, irrespective of DA (Destination Address). In the Silicon Firewall system, the CS8900A is configured for only broadcast mode and individual address mode. When the individual address
mode is set, frames with a DA that matches the individual address are accepted, while in broadcast mode, all broadcast frames are accepted. This last mode is necessary since broadcast frame are required in a number of protocols (i.e. Ping command using the ICMP protocol).
5.5.1.2 CAM Initialization
The CAM is another important peripheral in the Silicon Firewall system (see figure 3.2). CAM can be used to accelerate a variety of applications such as local-area networks (LANs), database management, file-storage management, table look up, pattern recognition, artificial intelligence, fully associative and processor-specific cache memories, and disk cache memories [20]. In the Silicon Firewall system, CAM is used to do address matching. In order to do that, the CAM has to be initialized, that is to say some data has to be stored in the CAM in advance. In this research project design, the Nios CPU writes a set of data (Source IP addresses) in the CAM before the operation of the system.
A CAM megafunction is built through the MegaWizard in Quartus II, and then it is added to the system. Since the CAM is a complex peripheral, 48 parallel I/O (input/output) pins are used to make the CAM work properly.
5.5.2 Polling vs. Interrupt
This design used Nios version 1.1 to begin with. The reference design is also 1.1-based. However the 1.1-based designs have a problem with the interrupt circuitry. The interrupt arrives at the Nios core asynchronous to the main CLK (clock) signal, causing occasional spurious interrupts to other values than the assigned interrupt (irq) number.
However, in the Silicon Firewall design, the Nios CPU is not intended to read all the packet data, only the packet data with the permitted source IP address is read. In that case, a signal from CAM will interrupt the Nios CPU, thus the interrupt feature of the Nios CPU is very important for this design. Fortunately, the Nios 2.0 core fixes this with a D-Flip-Flop between the CS8900A and the Nios, clocked by CLK and implements this fix internally.
Accordingly, there is a major change in the plugs library in Nios 2.0 CPU. That is the plugs library may now be run with interrupts enabled, polling is no longer necessary. From an CPU efficiency stand point this is very desirable.
5.5.3 Mode Switching
As mentioned previously, this design is a hardware and software codesign, so another concern is how to make the hardware and software work together properly and efficiently. After splitting the function of hardware and software in this system, a method to switch between hardware mode and software mode has to be provided. In this design, two PIOs (parallel input/output) are used to do this. One of the PIOs is defined as output by the Nios CPU and is connected to related hardware to make the hardware work correctly. The Nios CPU uses this signal as a control signal to switch between hardware mode and software mode. The other PIO is defined as input by the Nios CPU. In reality this input PIO is connected to the output PIO. The reason for doing this is as follows: the output PIO is used to control the hardware, however that is not enough since the Nios CPU will do different things in different modes. That is to say the Nios CPU has to “know” which mode it is in before it does something as requested.
After the interrupt is enabled in the Nios 2.0 CPU, there is an interrupt handler in the “lib” folder in the reference design. The interrupt service routine will check for events and dispatch packet when there is an interrupt. However, there are two modes in the Silicon Firewall design, so before the interrupt service routine does something, the current mode has to be determined. The input PIO is used to do this.
5.5.4 Flow Chart
The following is the flow chart of the software mode. In this figure, “Hw” means hardware mode, “Sw” means software mode.
The Silicon Firewall system uses software mode to begin with. After the system initialization, the Silicon Firewall is ready to function. In the flow chart, the interrupt could come from two places, the first one is directly from the CS8900A; the second one is from the Silicon Firewall system hardware when there is an authorized packet coming in.
Hw Sw No Yes Interrupt? Interrupt Service Routine Read Packet Data Switch to Sw Read Packet Data Switch to Hw Hw or Sw? Software Mode (Peripheral Initialization)