Chapter 4: INSTANTIATION OF CUSTOMIZED SOFT IP CORE FOR …shodhganga.inflibnet.ac.in/bitstream/10603/25454/11/11_chapter_04… · FIREWALL IMPLEMENTATION 1 Chapter 4 Instantiation

Chapter 4: INSTANTIATION OF CUSTOMIZED SOFT IP CORE FOR MULTIPROCESSOR

FIREWALL IMPLEMENTATION

1

Chapter 4 Instantiation of Customized Soft IP Core for Multiprocessor Firewall Implementation

This chapter presents the complete system design based on the core principle

of hardware-software co-design. The main contribution is reporting the technical

know-how related to the codesign aspects that comprehend synergic mixture of soft IP

cores of the content addressable memory (CAM) in hardware and software with the

Xilinx Spartan 3e and Microblaze processor. Another striking attribute of this

chapter is presentation of the customization / adaptation of the Xilinx Microblaze

processor in terms of multiprocessor configuration and to facilitate the inter-

processor communication for accessing the filter rule base and packet parsing. The

toolset used to accomplish the hardware-software codesign is the Xilinx Embedded

Design Kit (EDK). The design flow comprises of the IP core design in Handel-C,

embedded in EDK driven by the central customized core of Microblaze. At the end of

the chapter the device usage summary is covered with in-depth description of the

overall design flow and the resulting System on Chip (SoC) on the Xilinx Spartan 3e

FPGA.

4.1 Introduction

The most appropriate means in the complex product design with heavy software

overhead such as the present ones i.e. firewall is adopting the methodology of

amalgamation of various IP cores and customizing them to work on a single prototyping

platform such as FPGA. The literature also reveals a similar trend and expresses that the

System-chip design which starts at the RTL-level today has hit a plateau of productivity

and re-use which can be characterized as a “Silicon Ceiling” has become the upcoming

methodology in the VLSI arena. However, breaking through this plateau and moving to

higher and more effective re-use of IP blocks and system-chip architectures demands a

move to a new methodology: one in which the best aspects of today’s RTL based methods

are retained, but complemented by new levels of abstraction and the commensurate tools to



2

allow designers to exploit the productivity inherent in these higher levels of abstraction [1].

The state of art System on Chip (SoC) design shows a clear trend toward integration of

multiple processor cores especially for the applications in networked paradigm. The SoC

system driver section of the International Technology Roadmap for Semiconductors

(http://public.itrs.net) predicts that the number of processor cores in a typical SoC will

increase fourfold per technology node to match the corresponding applications’ processing

demands. Typical multiprocessor SoC (MPSoC) applications, such as network processors,

multimedia hubs, and baseband telecommunications circuits, have fuelled the above

mentioned trend [3]. Thus Ready-to-use IP designs of complex functionalities greatly

reduce the time and effort of hardware development. However, IP designs in the form of

static library modules have the limitation that they cannot match the optimal

cost/performance tradeoff encountered in every application scenario [2]. Therefore the

design flow for such combination can be realized by using the Hardware-Software

Codesign methodology that makes the best use of each of the domain. It is worthwhile to

present this methodology in contextual reference with the research problem taken in our

work.

4.2 Hardware-Software Codesign: Synergizing the Performance

Hardware/software co-design means meeting system- level objectives by exp loiting

the synergism of hardware and software through their concurrent design. Formal definition

of the same is given as [12]:

“The meeting of system- level objectives by exploiting the trade-offs between

hardware and software in a system through their concurrent design”

The key concepts involved are:

? Concurrent: hardware and software developed at the same time on parallel

paths

? Integrated: interaction between hardware and software development to

produce design meeting performance criteria and functional specs

Since digital systems have different organizations and applications, there are several

co-design problems of interest [4]. Thus designing hardware and software in isolation no



3

longer provides good solutions for complex embedded systems. Hardware-software

codesign (HSC) promises an integrated approach in which hardware and software are

designed in parallel. CAD environments, employing the tenets of HSC, are now being

developed to provide a cost and time effective solution [5].

As far as the history of the HSC is concerned the pioneering work was carried out

by Prakash and Parker of the University of Southern California [6]. Early work also dealt

with co-simulation and soon recognized the same as an essential component of a codesign

methodology. The challenge was to perform co-simulation at mixed abstraction levels to

execute enough input vectors to validate the design. With mixed- level simulation, designers

can trade off simulation performance for accuracy by choosing the detail level at which to

simulate various system components. Such a co-simulator was developed for the first time

in 1992, by Becker, Singh, and Tell [7] that linked a hardware simulator to executions of

application software. In earlier days FSM model was predominantly used to address the

codesign issues [9]. Thus in nutshell HSC is widely expressed in the literature as a complex

discipline that builds upon advances in several areas such as software compilation,

computer architecture and very large scale integration (VLSI) circuit design. Co-design is

perceived as an important problem, but the field is fragmented because most efforts are

applied to specific design problems [10]. However, the things are changing rapidly and

unified design frameworks are emerging. One such framework is recently reported by us in

[11].

4.3 Motivation behind the Hardware Software Codesign

There are number of driving forces fuelling the HSC methodology. Some of them

are as follows:

? Availability of the hard and soft cores of the processors such as Microblaze, the one

used in this work

? Increasing software centric applications of the present VLSI chips

? Capability of the FPGAs to reprogram on a fly



4

? Emerging C based design methodology that eases the EDIF coding of the complex

algorithms

? Possibility of rapid prototyping

? Unified testing environment of the Hardware and software instead of testing them

in isolation

? Better matching of the software with the underlying hardware thus improving the

overall efficiency

? Less possibility of failures with the hardware and software being on one chip

? Reduced development time due to possible parallelism in designing hardware and

software.

However there are many open problems in Hardware Software Codesign when it

comes to applications such as Network on Chip, the one that is dealt in the present

research. The problem is pertaining to evaluation of the effect of networks on chips on

codesign. On the one hand, NoCs provide a more structured system that should be easier to

analyze. On the other, NoCs are themselves complex systems that are not trivial to analyze

for performance or power, so adding them to architecture make it that much harder to

analyze [13]. Nevertheless an increasing number of embedded systems connect to the

Internet, which imposes new workloads and new mixtures of hard and soft deadlines.

Along with this new synthesis tools such as the Xilinx Embedded Design Kit used in our

work are turned out to be viable options to realize the designs. With the completion of more

than a decade since its inception the HSC has become a recognized research field that has

moved from an emerging discipline to a mainstream technology [14]. Therefore, it is

worthwhile to take a review of the existing and recently introduced Hardware Software Co-

Design frameworks.

4.4 Reviewing Recently Introduced Hardware Software Co-Design Frameworks

The power and capabilities of current and future FPGA computing platforms, which

can contain traditional microprocessors, on-chip busses, a wide variety of IO including

high speed interfaces, application specific accelerators, custom communication topologies



5

and all of the glue logic to tie the system together provides a huge opportunity for

embedded designers to more effectively address a wide range of applications [15]. This has

let to the development of various platforms and methodologies to accomplish the HSC.

Some of the prominent design paradigms are as follows:

? PeaCE [16]: Regarded as the first codesign environment, that provides seamless

codesign flow from functional simulation to system synthesis, mainly aimed at

multimedia applications with real-time constraints.

? Embedded UML [17]: It represents a synthesis of various ideas in the real-time

UML community, and concepts drawn from the Hardware-Software co-design field.

Embedded UML first selects from among the competing real-time UML proposals,

the set of ideas which best allow specification and analysis of mixed HW-SW

systems.

? Ptolemy [18]: Reported as the flexible and extensible platform for simulation, rapid

prototyping, and related design environme nts. It provides a large set of building

blocks that can be used to reduce the effort of building new environments and also

defines a set of internal object-oriented interfaces, so that heterogeneous

environments built in the Ptolemaic framework can later be easily merged as

necessary.

? Cosyma [19], Vulcan [20], and the system of Kalavade and Lee [21]: These

platforms are regarded as very useful to explore the design space of heterogeneous

multiprocessors.

? Geko [20]: Applied SoC design method for real-time information-processing

probems is based on an optimal combination of approved design technologies that

are widely used in the industries.

However at the heart of the networked appliances such as firewalls is the software

compiled system design. It is the pr inciple of providing a direct link between the

programmable platform and the originally defined system functionality. This provides the

necessary system verification flow and offers confidence to the designer who wants to fully

explore the design space – pushing the envelope of design innovation and product

differentiation. The methodology also deploys novel technology that permits more



6

informed and flexible hardware/software partitioning. This enables tradeoff analysis,

partition and repartition at any stage in the design, and by using higher level languages

(HLLs) for both hardware and software design, the methodology allows the system

specification to be written in a form that both teams can immediately use, without costly

and time-consuming rewrites [21].

The methodology used in the present work is the integration of soft IP cores and the

software components on the Xilinx Spartan 3e FPGA which is exemplified in fig. 4.1.

Fig. 4.1: Illustrating our Framework of Soft IP cores Instantiation for Realizing the

Networked SoC

Since our framework is heavily based on the instantiation of the soft IP cores, it

becomes necessary to mention few aspects regarding the same.

4.5 Soft IP Cores and their Instantiation

Emergence of independent intellectual property (IP) providers began in the late

1990s. The reason attributed for their growth is the growing complexity of SOC technology



7

that dramatically increases design loading and creates the needs for verified third-party IP

cores to simplify multifunctional chip designs [24]. In order to realize the above mentioned

trends there is upcoming trend to converge the IP, EDA and Library of third party cores to

fulfill application-specific needs. Thus with this trend the integrated-circuit industry is

entering a system-on-chip era in which IP cores will be the key to enhancing design

productivity and meeting the product road map [25]. IP cores fall into one of three

categories: hard cores, firm cores, or soft cores [26]. Hard cores are physical manifestations

of the IP design. These are best for plug-and-play applications, and are less portable and

flexible than the other two types of cores. Like the hard cores, firm (sometimes called semi-

hard) cores also carry placement data but are configurable to various applications. The

most flexible of the three, soft cores exist either as a net list (a list of the logic gate s and

associated interconnections making up an integrated circuit) or hardware description

language (HDL) code. However, the soft IP cores are more in use in FPGA based systems

as they offer the possibility of incorporating soft-cores. Many soft IP cores in the form of

processors can be considered as equivalents to a microcontroller or “computer on a chip”.

They combine a CPU, peripherals, and memory on a single chip. They also provide access

beyond the actual FPGA chip through integrated standard or custom-made interfaces. Some

available reduced instruction set computer (RISC) architectures are [27, 28, and 29]:

1. NIOS and NIOS II CPUs from ALTERA,

2. LEON2 and LEON3 CPUs from Gaisler Research,

3. and the Microblaze CPU from XILINX.

Out of this our work is centered on the Microblaze processor, its customization for

the firewall applications and it integration with the CAM soft IP core deliberated in the

previous chapter.



8

Fig. 4.2: A Generalized flow Diagram of Hardware -Software Codesign



9

More significant in the Soft IP core based design is their customization,

parameterization in order to make them flexible and compatible with the other system

components. Such configurability requires a new focus on "parameterized IP core" [30].

The main advantage of the state of art EDA tools such as the Xilinx EDK is the

instantiation of the tailored synthesizable processors, for FPGA implementation resulting

in processors having less size and performance overhead than a general synthesizable

processor mapped to an FPGA. The above mentioned tailoring of the Soft IP cores not only

frees FPGA resources for use by other circuits co-existing on the FPGA, but also can

enable use of smaller and hence lower-cost FPGA devices. Such reduction is magnified by

the increasingly common situation of users mapping several or even dozens of soft-cores

onto a single FPGA device [31-35], making soft-core customization even more critical to

best utilize available FPGA resources.

4.6 Our Design Framework

The design framework conceptualized for the implementation of the firewall is

shown in fig. 4.3. The design framework goes on the following lines:

Fig. 4.3: The Hardware-Software Constituent used in our work



10

? The IP core of the 32*256 CAM was designed using Handel C.

? The above core was then instantianted as a soft IP core in the Xilinx Emebedded

Design Kit (EDK) environment.

? Different Xilinx soft IP cores (detailed in the folowing part of the chapter) were

instatianted along with the CAM IP core in the EDK.

? One of our signifiacnt contribution is developing the drivers in ‘C’ language in

order to enable the Xilinx soft IP cores to communicate with others.

? In order to faciliatte the scheduling and prioritization of the above mentioned

drivers, Xilinx XilKernel was embedded.

? All the above mentioned constituents were then integrated on the Xilinx Spartan 3e

FPGA using EDK environment.

Thus the entire design thrust is on the Multiprocessor System on Chip (MpSoC)

platform development. The design flow is illustarted by the way of screen shots in figures:

4.7 Design Details

Fig. 4.4 revals the various constituents used in the implementation. Table 4.1.

summarizes the resources.

The implementatation starts from a full C driver software implementation for the

soft IP cores, coupled with the XilKernel and soft IP core of the CAM reported in previous

chapter. The main advantage of our design framework is the individual development of the

modules, refinement and then their gradual integration to form the entire system.



11

Fig. 4.4 Block Schematic of constituents used in the implementation

The description regarding their functionalities and configuration is as follows:

Table 4.1 EDK Resources Used in Our Design

Sr. No.

Name of the Resource Number of Resources used

1 MicroBlaze 1 2 Processor Local Bus (PLB) 4.6 1 3 Local Memory Bus (LMB) 1.0 2 4 Block RAM (BRAM) Block 1 5 LMB BRAM Controller 2 6 XPS Multi-Channel External Memory Controller(SRAM/Flash) 1 7 Multi-Port Memory Controller(DDR/DDR2/SDRAM) 1 8 XPS UART (Lite) 1 9 XPS General Purpose IO 3

10 XPS 10/100 Ethernet MAC Lite 1 11 XPS Timer/Counter 1 12 Clock Generator 1 13 MicroBlaze Debug Module (MDM) 1 14 Processor System Reset Module 1 15 XPS Interrupt Controller 1 16 FILTER 2 17 XPS TFT 1 18 Utility Bus Split 1



12

4.7.1. Microblaze Core

The Microblaze is a proprietray soft IP core developed by Xilnx in VHDL. The

processor core features 32 bit Harvard architecture. The main reason behind using this

processor core is its amenability in the Xilinx EDK platform and Spartan 3e based FPGA.

Moreover the microblaze suits to the netroked system implementation due to its folowing

architectural attributes:

? RAM based 32 by 32-bit registers are lookup table (LUT)

? Guranteed short register access time

? Facilitation of onchip RAM

? Dedicated routing resources coping with the natwork latency requirements.

Table 4.2 gives the interface connection details of the Microblaze cores used in our work.

Table 4.2 Port Lists and Bus Interfaces used by the MicroBlaze Core

PORT LIST These are the ports listed in the MHS file.

# NAME DIR [LSB:MSB] SIGNAL 0 MB_RESET I 0:0 mb_reset 1 INTERRUPT I 0:0 microblaze_0_Interrupt

Bus Interfaces

NAME TYPE BUSSTD BUS Connected To

IXCL INITIATOR XIL_MEMORY_CHANNEL microblaze_0_IXCL DDR_SDRAM DXCL INITIATOR XIL_MEMORY_CHANNEL microblaze_0_DXCL DDR_SDRAM DPLB MASTER PLBV46 mb_plb 11 Peripherals. IPLB MASTER PLBV46 mb_plb 11 Peripherals.

DLMB MASTER LMB dlmb dlmb_cntlr ILMB MASTER LMB ilmb ilmb_cntlr

DEBUG TARGET XIL_MBDEBUG3 microblaze_0_mdm_bus mdm_0



13

4.7.2 Ethernet MAC Core

The Ethernet MAC instantiated here is used for network communication interface.

The above mentioned Ethernet MAC is capable of transmitting and receiving data at 10 and

100 Mbps and supports MII interfacing. The interfacing details of this core are given in

table 4.3

Table 4.3 Ports List and Other Interfacing Details of the Ethernet MAC


# NAME DIR [LSB:MSB] SIGNAL 0 PHY_tx_clk I 0:0 fpga_0_Ethernet_MAC_PHY_tx_clk_pin 1 PHY_rx_clk I 0:0 fpga_0_Ethernet_MAC_PHY_rx_clk_pin 2 PHY_crs I 0:0 fpga_0_Ethernet_MAC_PHY_crs_pin 3 PHY_dv I 0:0 fpga_0_Ethernet_MAC_PHY_dv_pin 4 PHY_rx_data I 0:3 fpga_0_Ethernet_MAC_PHY_rx_data_pin 5 PHY_col I 0:0 fpga_0_Ethernet_MAC_PHY_col_pin 6 PHY_rx_er I 0:0 fpga_0_Ethernet_MAC_PHY_rx_er_pin 7 PHY_tx_en O 0:0 fpga_0_Ethernet_MAC_PHY_tx_en_pin 8 PHY_tx_data O 0:3 fpga_0_Ethernet_MAC_PHY_tx_data_pin 9 PHY_MDC O 0:0 fpga_0_Ethernet_MAC_PHY_MDC_pin 10 IP2INTC_Irpt O 0:0 Ethernet_MAC_IP2INTC_Irpt 11 PHY_MDIO IO 0:0 fpga_0_Ethernet_MAC_PHY_MDIO_pin

Bus Interfaces NAME TYPE BUSSTD BUS Connected To

SPLB SLAVE PLBV46 mb_plb 11 Peripherals.

4.7.3 Embedding the CAM Filter Core

The CAM filter IP core which was designed in the previous chapter is instantiated

here and connected to the rest of the 11 peripherals by means of PLBV46 bus.

Integration of the CAM IP core to the other cores has been done by means of following

steps:

? The design was started in EDK environment by specifying the Spartan 3e starter kit

? Create and Import peripheral wizard was used to instantiate the CAM IP core



14

? In order to facilitate the read/write operations of the peripheral cores with the CAM,

a FIFO mechanism was selected. The FIFO was selected as against the register

mechanism due to the possibility of simultaneous read/write without contention.

? The CAM core originally designed by using Handel C was converted into the EDIF

and then integrated as a black box.

The implementation of the CAM soft IP core in the form of pseudo code is given below:

************************** Pseudo code for the CAM ***********************

interface port_in(unsigned 1 clk with {clockport=1}) clockport();

unsigned 32 result;

interface port_in (unsigned 8 a) Inport() with {busformat = "B<N:0>"};

interface port_out() outport(unsigned 32 p = result) with {busformat = "B<N:0>"};

set clock = internal clockport.clk;

//set clock =external "c9";

mpram filter

{ ram <unsigned 8> ReadWrite[256]; // Read/write port

rom <unsigned 8> Read[256]; // Read only port

}; mpram filter SrcIP1;

void main()

{

unsigned 8 in1;

unsigned 8 IP;

while(1)

{

in1 = Inport.a;

IP=in1;

par (i=0;i<255;i++)

{

SrcIP1.ReadWrite[i]=192;

}



15

par (i=0;i<255;i++)

{ if(IP==SrcIP1.Read[i])

{

result=1;

}

else {

result=0;

} }}

}

*********************************END************************************

The parameters set for this system by us as well by the system are given in table 4.4.

Table 4.4 Parameters setting for the CAM IP core

Parameters These are the current parameter settings for this module.

Name Value C_BASEADDR 0xc4200000 C_HIGHADDR 0xc420ffff C_SPLB_AWIDTH 32 C_SPLB_DWIDTH 32 C_SPLB_NUM_MASTERS 2 C_SPLB_MID_WIDTH 1 C_SPLB_NATIVE_DWIDTH 32

4.7.4 Memory Controller

The DSOCM_V10 data-side On-Chip Memory (OCM) bus interconnect core

featuring Single master - no bus arbitration logic has been used for separate control of data

and instructions being fetched by the Microblaze. The DDRSDRAM is used in our work

for prototyping and testing purpose; while the flash is intended to be reconfigured by the

system administrator ones the black IP addresses are identified.



16

Table 4.5 Interface details for the DDRSDRAM


# NAME DIR [LSB:MSB] SIGNAL 0 MPMC_Clk0 I 0:0 clk_100_0000MHzDCM0 1 MPMC_Clk90 I 0:0 clk_100_0000MHz90DCM0

2 MPMC_Rst I 0:0 sys_periph_reset

3 DDR_Clk O 0:0 fpga_0_DDR_SDRAM_DDR_Clk_pin

4 DDR_Clk_n O 0:0 fpga_0_DDR_SDRAM_DDR_Clk_n_pin

5 DDR_CE O 0:0 fpga_0_DDR_SDRAM_DDR_CE_pin

6 DDR_CS_n O 0:0 fpga_0_DDR_SDRAM_DDR_CS_n_pin

7 DDR_RAS_n O 0:0 fpga_0_DDR_SDRAM_DDR_RAS_n_pin

8 DDR_CAS_n O 0:0 fpga_0_DDR_SDRAM_DDR_CAS_n_pin

9 DDR_WE_n O 0:0 fpga_0_DDR_SDRAM_DDR_WE_n_pin

10 DDR_BankAddr O 0:1 fpga_0_DDR_SDRAM_DDR_BankAddr_pin

11 DDR_Addr O 0:12 fpga_0_DDR_SDRAM_DDR_Addr_pin

12 DDR_DQ IO 0:15 fpga_0_DDR_SDRAM_DDR_DQ_pin

13 DDR_DM O 0:1 fpga_0_DDR_SDRAM_DDR_DM_pin



17

14 DDR_DQS IO 0:1 fpga_0_DDR_SDRAM_DDR_DQS_pin

15 DDR_DQS_Div_O O 0:0 fpga_0_DDR_SDRAM_ddr_dqs_div_io_pin

16 DDR_DQS_Div_I I 0:0 fpga_0_DDR_SDRAM_ddr_dqs_div_io_pin

Bus Interfaces NAME TYPE BUSSTD BUS Connected To

XCL0 TARGET XIL_MEMORY_CHANNEL

microblaze_0_IXCL microblaze_0

XCL0_B

TARGET XIL_MEMORY_CHANNEL

microblaze_0_DXCL microblaze_0

Table 4.6 Interface Details of the FLASH


# NAME DIR [LSB:MSB] SIGNAL 0 RdClk I 0:0 clk_50_0000MHz

1 Mem_A O 31:0 0b00000000 & fpga_0_FLASH_Mem_A_pin_vslice_8_31_concat

2 Mem_CEN O 0:0 fpga_0_FLASH_Mem_CEN_pin 3 Mem_OEN O 0:0 fpga_0_FLASH_Mem_OEN_pin 4 Mem_WEN O 0:0 fpga_0_FLASH_Mem_WEN_pin 5 Mem_DQ IO 7:0 fpga_0_FLASH_Mem_DQ_pin

Bus Interfaces NAME TYPE BUSSTD BUS Connected To SPLB SLAVE PLBV46 mb_plb 11 Peripherals



18

4.7.5 PLB Bus Interface

The Processor Local Bus facilitates the communication between the 11 peripheral

cores, along with the CAM soft IP core to the Microblaze processor. The interfacing details

are given in table 4.7.

Table 4.7 Interface Details of the PLB bus


# NAME DIR [LSB:MSB] SIGNAL 0 PLB_Clk I 0:0 clk_50_0000MHz 1 SYS_Rst I 0:0 sys_bus_reset

Bus Connections INSTANCE INTERFACE TYPE INTERFACE NAME microblaze_0 MASTER DPLB microblaze_0 MASTER IPLB RS232_DTE SLAVE SPLB LEDs_8Bit SLAVE SPLB

DIP_Switches_4Bit SLAVE SPLB Buttons_4Bit SLAVE SPLB

FLASH SLAVE SPLB Ethernet_MAC SLAVE SPLB

xps_timer_0 SLAVE SPLB mdm_0 SLAVE SPLB

xps_intc_0 SLAVE SPLB fil_0 SLAVE SPLB

cam_final_0 SLAVE SPLB



19

4.7.6 Debugging and Testing

The in system debugging and software testing was carried out by using the

Microblaze Debug Module (MDM). Single stepping was possible with the MDM core

integration in this system. Modifications in the registers of the microblaze were visible

through this module. The interfacing details of the MDM are given in table in 4.8.

Table 4.8 MDM Interfacing details for debugging purpose


# NAME DIR [LSB:MSB] SIGNAL 0 Debug_SYS_Rst O 0:0 Debug_SYS_Rst

Bus Interfaces

NAME TYPE BUSSTD BUS Connected To

MBDEBUG_0 INITIATOR XIL_MBDEBUG3 microblaze_0_mdm_bus microblaze_0

SPLB SLAVE PLBV46 mb_plb 11

Peripherals.

4.8 CAM testing for real IPs

The code snippets for testing the entire module for real IPs is given below. Few bad

IPs were reconfigures in the CAM core using the UART. The incoming IPs were sent to the

CAM core and the subsequent results were displayed through the UART. It reveals that the

CAM is giving a complete match for the BAD IPs.

************************** Source Code CAM Filter ***********************

#include "xparameters.h"

#include "xbasic_types.h"

#include "xstatus.h"

#include "CAM_FINAL.h"

Xuint32 *baseaddr_p = (Xuint32 *)XPAR_CAM_FINAL_0_BASEADDR;

int main (void) {



20

Xuint32 i;

Xuint32 temp,ip4_addr1,ip4_addr2,ip4_addr3,ip4_addr4;

Xuint32 baseaddr;

// Clear the screen

xil_printf("%c[2J",27);

// Check that the peripheral exists

XASSERT_NONVOID(baseaddr_p != XNULL);

baseaddr = (Xuint32) baseaddr_p;

xil_printf("Content Addressable Memory Filter Test\n\r");

// Reset read and write packet FIFOs to initial state

CAM_FINAL_mResetWriteFIFO(baseaddr);

CAM_FINAL_mResetReadFIFO(baseaddr);

temp =0xc0a80a01;

CAM_FINAL_mWriteToFIFO(baseaddr,1, temp);

CAM_FINAL_mWriteToFIFO(baseaddr,1, temp);

ip4_addr4=temp & 0x000000ff;

ip4_addr3=temp & 0x0000ff00;

ip4_addr3=ip4_addr3>>8;

ip4_addr2=temp & 0x00ff0000;


ip4_addr1=temp & 0xff000000;


xil_printf("Senders IP = %d.%d.%d.%d\n\r", ip4_addr1,

ip4_addr2,

ip4_addr3, ip4_addr4);

temp = CAM_FINAL_mReadFromFIFO(baseaddr,1);

temp = CAM_FINAL_mReadFromFIFO(baseaddr,1);

xil_printf("Result from CAM HIT = : %d \n\r", temp);

if(temp==1)

{



21

xil_printf("Match Found \n\r");

xil_printf("Packet Forwarded\n\r");

} else

{

xil_printf("Match NOT Found\n\r");

xil_printf("Packet Dropped\n\r");

}

CAM_FINAL_mResetWriteFIFO(baseaddr);

CAM_FINAL_mResetReadFIFO(baseaddr);

xil_printf("for Next Packet\n\n\r");

// Stay in an infinite loop

while(1){

}}

*************************************END********************************

4.9 Timing information and throughput

The latency aspects are very much important in a networked system. The main

initial goal behind the deployment of the firewall on FPGA was not to have the latency

issues which might slow down the entire network. In order to check the same the timing

information was checked and ascertained indirectly by checking the clock details. The

same is presented in table 4.9

Table 4.9 Timing information

Post Synthesis Clock Limits These are the post synthesis clock frequencies.

MODULE CLK Port MAX FREQ

cam_final_0 SPLB_Clk 52.696MHz mdm_0 mdm_0/update 87.627MHz mdm_0 SPLB_Clk 87.627MHz mdm_0 mdm_0/drck_i 87.627MHz

microblaze_0 DCACHE_FSL_OUT_CLK 90.600MHz



22

microblaze_0 DBG_CLK 90.600MHz microblaze_0 DBG_UPDATE 90.600MHz

FLASH MCH_SPLB_Clk 99.010MHz FLASH RdClk 99.010MHz

fil_0 SPLB_Clk 103.445MHz Ethernet_MAC SPLB_Clk 103.509MHz Ethernet_MAC PHY_tx_clk 103.509MHz Ethernet_MAC PHY_rx_clk 103.509MHz

xps_timer_0 SPLB_Clk 128.287MHz RS232_DTE SPLB_Clk 150.015MHz

mb_plb PLB_Clk 156.446MHz proc_sys_reset_0 Slowest_sync_clk 198.531MHz

xps_intc_0 SPLB_Clk 199.960MHz xps_intc_0 Intr<1> 199.960MHz xps_intc_0 Intr<0> 199.960MHz LEDs_8Bit SPLB_Clk 201.086MHz

DIP_Switches_4Bit SPLB_Clk 201.086MHz Buttons_4Bit SPLB_Clk 201.086MHz

ilmb LMB_Clk 249.128MHz dlmb LMB_Clk 249.128MHz

clock_generator_0 CLKIN 379.075MHz clock_generator_0 CLKIN 379.075MHz

The system runs at 50 MHz clock and hence the latency issue doesn’t arise.



23

Fig. 4.5: Screenshot of the Firewall GUI

4.10 Initialization, Testing and Deployment

The system administrator can reconfigure our firewall by using a Graphical User

Interface (GUI) scripted in ‘C’ and ported in the EDK environment. The firewall is

initialized with the setting up of the parameters through the UART on the server side.

There are two primary modes for the system administrator:

? Initialization Mode: For setting up of the parameters

? Run Mode: Actual parsing of the packet to decide whether to allow or deny the

access.

The initialization mode has the following types of parameters which can be setup by the

system administrator:

? Source IP



24

? Destination IP

? Source Port

? Destination Port

? MAC Address

The GUI asks the user regarding the data of the parameters to be permitted and to

be denied. Once the information is entered, further information regarding the initialization

mode in which the system administrator is interested in is asked. The GUI code written in

EDK is as given below:

*********************** Code for GUI in ‘C’ ported to EDK *******************

#include "xparameters.h"

#include "xbasic_types.h"

#include "xstatus.h"

#include "CAM_FINAL.h"

Xuint32 *baseaddr_p = (Xuint32 *)XPAR_CAM_FINAL_0_BASEADDR;

int main (void) {

Xuint32 i;

Xuint32 temp,ip4_addr1,ip4_addr2,ip4_addr3,ip4_addr4;

Xuint32 baseaddr;

xil_printf("%c[2J",27);

// Check that the peripheral exists

XASSERT_NONVOID(baseaddr_p != XNULL);

baseaddr = (Xuint32) baseaddr_p;

xil_printf("Select Firewall \n\r");

xil_printf("Source IP in Decimal Octate Format\n\r");

xil_printf("Destination IP in Decimal Octate Format\n\r");

xil_printf("Source Port\n\r");

xil_printf("Destination Port\n\r");

xil_printf("MAC Address\n\r");

*************************************END********************************

The screenshot of the GUI is shown in fig. 4.5.



25

4.11 Testing and Online Parsing of the TCP/IP Packets

Once the initialization phase is over, the firewall can be configured in the ‘Run’

mode. In this mode, the TCP/IP packets are read through the Ethernet port of the Xilinx

starter Kit and parsed in terms of the mode and the parameters pertaining to the respective

mode. The testing of two modes are verified and the screenshots of the same are

reproduced in fig. 4.6

For one of the testing mode we intended to deny the FTP service and accordingly

the port 21 was configured in the Firewall for denial of access. This mode was also tested

successfully and the screenshot is shown in fig. 4.7.

Fig. 4.6: Screenshot of the Firewall testing reveals denial of access for a bad IP

address



26

Fig. 4.7 Screenshot revealing the denial of FTP access by the firewall.

4.12 Performance Monitoring of the Firewall

One of the goals of the firewall is also to let the system administrator know about its

status and such other information which will enable him/her to know about the network

status. The performance of the firewall in our work is monitored by using the following

parameters:

? Type of the transport layer received packet whether TCP or UDP

? Current mode of the firewall.

? Number of entries in the CAM

? Contents of the CAM such as source/destination port number, source/destination IP

address or source MAC address.

? Number of times the denial of access is invoked



27

4.13 Conclusion

The chapter 4 presented our implementation by using the Hard-Software Codesign and

integration of all the modules using the Xilinx EDK environment. The scheduling and

prioritization issue of the soft IP cores was handled by porting the Xil Kernel, while the

central processor governing the communication and synchronization of all the cores was

Xilinx Microblaze. The CAM core designed in the previous chapter was deployed in the

system with a provision of reconfiguration so as to allow or deny the access. The various

soft IP cores of the peripherals were also made to communicate with each other by using

the PLB bus so as to attain the desired firewall functionality. A GUI was designed in ‘C’

and embedded in the EDK so that the system administrator can configure the firewall. Five

modes related to the different attributes of the TCP/IP packet were provided to complete

the firewall functionality. Finally a real time deployment of the firewall connected to a

workstation verified the firewall functionality.



28

References:

1. Grant Martin, Design Methodologies for System Level IP, DATE 98, Proceedings

of the conference on Design, automation

2. Peter A. Milder, Mohammad Ahmad, James C. Hoe, and Markus P ¨ uschel, Fast

and Accurate Resource Estimation of Automatically Generated Custom DFT IP

Cores, FPGA’06, February 22–24, 2006, Monterey, California, USA.

3. Wander O. Cesário, Damien Lyonnard, Gabriela Nicolescu, Yanick Paviot, Sungjoo

Yoo, and Ahmed A. Jerraya, Lovic Gauthier, Multiprocessor SoC Platforms: A

Component Based Design Approach, IEEE Design & Test of Computers

4. GIOVANNI DE MICHELI, FELLOW, IEEE, AND RAJESH K. GUPTA,

Hardware/Software Co-Design, PROCEEDINGS OF THE IEEE, VOL. 85, NO. 3,

MARCH 1997, pp. 349 -351

5. Gupta, P, Hardware-software codesign, Potentials, IEEE, Issue Date: Dec 2001/Jan

2002, Volume: 20 Issue:5, On page(s): 31 – 32, ISSN: 0278-6648

6. S. Prakash and A.C. Parker, “SOS: Synthesis of Application-Specific

Heterogeneous Multiprocessor Systems,” J. Parallel and Distributed Computing,

vol.16, 1992, pp. 338-351.

7. D. Becker, R.K. Singh, and S.G. Tell, “An Engineering Environment for

Hardware/Software Cosimulation,” Proc. 29th Design Automation Conf., IEEE CS

Press, 1992, pp. 129-134.

8. Massimiliano Chio do, Paolo Giusto, Harry Hsieh Attila Jurecska, Luciano Lavagno

Alb erto Sangiovanni-Vincentelli, A Formal Methodology for Hardware/Software

Co-design of Emb edded Systems

9. R. K. Gupta, C. N. Co elho Jr., and G. De Micheli. Program implementation

schemes for hardware-software systems. IEEE Computer, pages 48{55, January

1994.

10. K. Buchenrieder, A. Sedelmeier, and C. Veith, “Industrial HW/SW codesign,” in

Hardware/Software Co-Design, G.De Micheli and M. Sami, Eds. Amsterdam:

Kluwer, 1996, pp. 453–466.

11. Unleash Reference



29

12. Presentation on Hardware/Software Codesign Overview RASSP Education &

Facilitation Program: Module 14, Retrieved from

www.vhdl.org/rassp/modules/m14/m14_03_00.ppt

13. L. Benini and G. De Micheli, “Networks-on-Chips: A New SoC Paradigm,”

Computer, Jan. 2002, pp. 70-78.

14. Wayne Wolf, A Decade of Hardware/ Software Codesign, IEEE Computer April

2003, pp. 38 -41

15. Don Davis, Srinivas Beeravolu, Ranjesh Jaganathan, Hardware / Software Codesign

for Platform FPGAs, Retrieved from

courses.engr.illinois.edu/ece598/.../hardware_software_codesign_xilinx_7.pdf

16. SOONHOI HA, SUNGCHAN KIM, CHOONSEUNG LEE, YOUNGMIN YI,

SEONGNAM KWON, and YOUNG-PYO JOO, PeaCE: A Hardware-Software

Codesign Environment for Multimedia Embedded Systems,

ACMTransactionsonDesignAutomationofElectronicSystems,Vol.12,No.3,Article24

,Publicationdate:August2007.

17. Grant Martin, Luciano Lavagno and Jean Louis-Guerin, Embedded UML: a merger

of real-time UML and co-design, CODES’01, April 25-27, 2001, Copenhagen,

Denmark

18. Joseph Buck, Soonhoi Ha, Edward A. Lee, and David G. Messerschmitt, Ptolemy:

A Mixed-Paradigm Simulation/Prototyping Platform in C++, Retrieved from

citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.80.2652&rep

19. R. Ernst, J. Henkel, and T. Benner, “Hardware-software cosynthesis for

microcontrollers,” IEEE Des. Test Comput., vol. 10, no. 4, pp. 64–75, Dec. 1993.

20. R. K. Gupta and G. De Micheli, “Hardware-software cosynthesis for digital

systems,” IEEE Des. Test Comput., vol. 10, no. 3, pp. 29–41, Sep. 1993.

21. A. Kalavade and E. A. Lee, “The extended partitioning problem:

Hardware/software mapping, scheduling, and implementation-bin selection,” Des.

Autom. Embed. Syst., vol. 2, no.2,pp. 125–163,Mar. 1997.

22. Theo Kluter, Marcel Jacomet, General-Purpose SoC Platform Handles

Hardware/Software Co-Design, Xcell Journal, First Quarter 2011, pp. 33-37



30

23. Chris Sullivan and Milan Saini, Software-Compiled System Design Optimizes

Xilinx Programmable Celoxica and Xilinx Programmable Systems, XCell Journal

Summer 2003.

24. Shang-yi Chiang, Foundries and the Dawn of an Open IP Era, IEEE Computer

April 2001, pp. 43-46

25. Thangjam, Presnetation on EFFICIENT FPGA IMPLEMENTATION OF PWM

CORE at 105 MAPLD Conference

26. IP core (intellectual property core), Retrieved from

http://whatis.techtarget.com/definition/0,,sid9_gci759036,00.html

27. Altera Corp., NIOS II Processor Reference Handbook, Altera Document NII5V1-

1.2, Altera Corp., San Jose, CA, Jan. 2005

28. Gaisler Resarch, LEON2 Processor User’s Manual –XST Edition, Gaisler Research

AB, Goteborg, Sweden, Jan. 2005

29. XILINX Inc., MicroBlaze Processor Reference Guide, XILINX Document UG081

(v5.0), XILINX Inc., San Jose, CA, Jan. 2005

30. Zhao Junchao; Chen Weiliang; Wei Shaojun, Parameterized IP core design,

ASIC, 2001. Proceedings. 4th International Conference on Issue Date: 2001On

page(s): 744 – 747, Meeting Date: 23 Oct 2001 - 25 Oct 2001, Location: Shanghai ,

China

31. Dwivedi, B.,A. Kumar, M. Balakrishnan, Automatic Synthesis of System on Chip

Multiprocessor Architectures for Process Networks. 2004. International Symposium

on Hardware/Software Codesign and Internation Symposium on System Synthesis

(CODES/ISSS).

32. Huebner, M., T. Becker, J. Becker. Real-Time LUT-Based Network Topologies for

Dynamic and Partial FPGA Self-Reconfiguration. 2004. 13th Symposium on

Integrated Circuit Design and System Design (SBCCI).

33. Jin. Y., N. Satish, K. Ravindran, K. Keutzer. An Automated Exploration

Framework for FPGA-based Soft Multiprocessor Systems. 2005. International

Symposium on Hardware/Software Codesign and Internation Symposium on

System Synthesis (CODES/ISSS).



31

34. Kumar, R., N. Jouppi, D. Tullsen. Conjoined-core Chip Multiprocessing. In the

Proceedings of the 37th International Symposium on Microarchitecture.

35. Kumar, R., V. Zyuban, D. Tullsen. Interconnections in Multi-core Architectures:

Understanding Mechanisms, Overheads and Scaling. 2005. In the Preceedings of

the 32nd International Symposium on Computer Architecture.

Documents

Chapter 4: INSTANTIATION OF CUSTOMIZED SOFT IP CORE FOR …shodhganga.inflibnet.ac.in/bitstream/10603/25454/11/11_chapter_04… · FIREWALL IMPLEMENTATION 1 Chapter 4 Instantiation