A Reconfigurable ASIC Implementation of a NetworkGateway Based on the IPv4 Protocol

Crístian MüllerMicroelectronics Group

Federal University of SantaMaria

Santa Maria, Brazilcristianmuller@ieee.org

Paulo César AguirreMicroelectronics Group

Federal University of SantaMaria

Santa Maria, Brazilaguirre@ieee.org

Lucas TeixeiraMicroelectronics Group

Federal University of SantaMaria

Santa Maria, Brazilteixeira@ieee.org

Leonardo L. de OliveiraMicroelectronics Group

Federal University of SantaMaria

Santa Maria, Brazilleonardo@mail.ufsm.br

João Baptista MartinsMicroelectronics Group

Federal University of SantaMaria

Santa Maria, Brazilbatista@inf.ufsm.br

ABSTRACTThis paper describes the design and the test results of afull-duplex Internet Protocol Version 4 based ASIC imple-mentation. Routing and addressing features with a reconfig-urable ARP table were integrated. The design was timing-driven and previous simulations have shown a 125MHz max-imum operating frequency on a 0.35µm technology. Theestimated statistical power consumption is 48mW. The pro-totyped chip has 19,060 logic equivalent cells and a totaldie area of 5.43mm2. Initial tests in the prototyped in-tegrated circuit indicate a maximum operating frequencyaround 50MHz, limited by the test environment constraints,but the real maximum operating frequency was estimatedaround 95MHz.

KeywordsASIC, IPv4, Network Gateway.

1. INTRODUCTIONPerformance improvements as well as reduced latency in allnetwork communications systems are desired [1]. The de-velopment of communications protocols in hardware devicesis a straight-forward issue to solve this problem. In thiscontext, the main goal of this paper is to describe the hard-ware implementation of a reconfigurable network gatewayIPv4 (Internet Protocol Version 4) based protocol [3] andthe ASIC (Application Specific Integrated Circuit) design ofthis IP-core. A similar implementation, in an FPGA (FieldProgrammable Gate Array) device, is presented in [2]. Inaddition, brief explanations about the test environment andthe experimental test results of this ASIC are also reported.

ARP /

ARP table

Network interface 1

Sender

IPv4

Network interface 0

Receiver

Figure 1: Designed IP-core block diagram.

2. INTEGRATED CIRCUIT DESIGNThe designed ASIC described in this paper is an IP-core,based on the IPv4 protocol, that was developed and vali-dated previously in simulations and in an Stratix II FPGAdevice. This design includes routing and addressing fea-tures, Gigabit Ethernet support and full-duplex operationmode as well as presented in [2]. However, our design is notlimited by a static storage information. This flexibility issueis provided by a reconfigurable ARP (Address ResolutionProtocol) table that was developed and integrated insteadof the static feature. This table can be updated during theASIC operation and has default values in the chip startup.

The design architecture is shown in figure 1 and is dividedin three main blocks, each one is responsible for a singletask. Blocks Receiver and Sender are responsible to evalu-ate and forward, with necessary modifications, the receiveddatagram. The reconfigurable ARP table is intrinsic to theaddressing function and provides the MAC (Media AccessControl) address of each host in the network.

In order to achieve the specified operating frequency, i.e. 125MHZ, a specific block placed between the designed ASIC

Q

QSET

CLR

S

R

Flip-Flop

Integrated

Circuit

output

Output data

cell (PAD)

Q

QSET

CLR

S

R

Flip-Flop

Q

QSET

CLR

S

R

Flip-Flop

Interface Circuit

Clock

Internal

circuitry

Smaller

combina-

tional logic

Combinational

logic necessary

due to working

features

Figure 2: Circuit used to brake the main delays paths.

IP-core subblocks interconnections was used. Its task is tobrake the main delays paths by the inserction of registers atthe cost of few clock cicles increasement. Also, the externalinterface delays were reduced using the same structure. Thecontrol signals, in both directions, are buffered.

Figure 2 outlines the shape of the circuit used in the inter-faces. Extra registers and combinational cells are used tokeep the same behaviour in the communication with bothinterface sides (invisible circuit). This solution was adoptedto avoid that the more complex blocks , already verified, donot need to be completely redesigned.

After these modifications the improved IP-core was proto-typed in a Stratix II EP2S60-F672C3N FPGA device forvalidation before the ASIC design flow.

The IP-core was designed in SystemVerilog hardware de-scription language. The logical and physical syntheses werecarried out with Synopsys Design Compiler and CadenceFirst Encounter, respectively. The design was time-drivento operate at 125MHz. This frequency was specified to pro-vide to the ASIC the same Gigabit Ethernet standard clockfrequency. The integrated circuit was prototyped using anX-FAB 0.35µm process with four metal layers and packagedwith a 68L CLDCC-J ceramic package (68 pins). The IClayout photography is shown in figure 3. The estimated sta-tistical power consumption, provided by First Encounter,is 48mW. The prototyped chip has 19,060 logic equivalent(NAND2) cells and a total die area of 5.43mm2.

Figure 3: Die of the designed integrated circuit.

3. TEST ENVIRONMENTThe development of the test environment was split in twoparts: Personal computer (PC) software (for stimuli genera-tion) and hardware (to directly deal with the designed chipinterfaces).

The test environment checks all functionalities of the coredescribed in the Section 2. The following test procedureswere adopted: packets crossing by all 4 ways (the IP blockis placed between two interfaces and the network packets aresent from and to both interfaces), ARP table programmingand network packets discarding. The latter occurs for invalidvalues in the internet protocol header.

3.1 Developed softwareThe software was developed in C language and runs in apersonal computer (PC). It provides the stimuli data by anetwork interface board to the hardware part of the sys-tem. These data are sent with the Ethernet packet formatcontaining 200 bytes of random data and the IPv4 proto-col header. All packets are built manually allowing differentheader values and additional randomly generated errors in-sertion to verify the packets discarding feature.

The design under test processes the received frames and per-forms the addressing and routing tasks. After, it sends theprocessed frame to the PC software. This latter knows thepacket content which must be received and compares it withthe received packet. It allows quantifying the lost packetsand consequently the error estimation.

3.2 Developed HardwareThe hardware environment is responsible for receiving thetest stimuli generated by software and, respecting the hand-shake and timing requirements, drive it to the design undertest. To make it possible to drive the data in to the circuitinterfaces and read its answers a hardware circuit prototypedin an FPGA was used.

This hardware test environment is based on a Nios II De-velopment Kit with a Stratix II EP2S60-F672C3N FPGAdevice. A network expansion board interface (High Perfor-mance Triple-Speed Marvell 88E1111 10/100/1000 EthernetPHY) was placed as physical layer between the IP-core blockand the PC to send and to receive Ethernet packets. Figure5 shows the hardware environment used in the tests.

ASICFPGA

PC

Ethernet

Cable

Delay: 4.75ns

Delay: 4.75ns

Internal delay

Figure 4: Path delay between FPGA and ASIC.

Figure 5: Photo of the hardware test environment.

The hardware part allows performing two tests procedures:the first one checks all hardware functionalities of the coreand the second test verify the maximum frequency that pro-vides an error-free operation.

The IPv4 protocol circuit was set and validated to operate at125MHz. However, this frequency value was not reached inthe experiments due to the intrinsic delay of 9.5ns caused bythe test hardware environment in the loop path. This delaycan be observed in figure 6 and figure 4. Then, all testsran using lower frequencies. With the value of hardwareenvironment delay it is possible to estimate the maximumoperating frequency of the designed ASIC.

Furthermore, six different operating frequencies were setfor performance evaluation: 50MHz, 52.08MHz, 55.55MHz,56.82MHz, 57.69MHz and 62.50MHz.

For 50MHz, the circuit operates normally and for 62.5MHzthe circuit stops working completely. The maximum op-

Figure 6: Voltage of clock signal analysed. Greensignal is the same as the yellow one, but measuredafter the loop from FPGA to ASIC package pin andback.

erating frequency estimated for the ASIC may be calcu-lated indirectly as follows: the measured delay (9.5ns) issubtracted from the clock cycle period used in the tests(1/50MHz = 20ns). This result (10.5ns) represents thechip internal delay. From this information the maximumoperating frequency is estimated, as shown in equation 1.

FreqASIC =1

150MHz

− 9.5ns=

1

10.5ns≈ 95MHz (1)

A possible way to reduce the test environment delay is todesign only one PCB board containing an FPGA device andthe designed ASIC because the circuits must be located asclose as possible.

3.3 Test ResultsThe frequency test results give conditions to estimate theaveraged lost packets, as shown in figure 7. The lost packetsnumber is zero up to 50MHz and as the frequency is in-creased the lost packets number increases exponentially.Foreach real operating frequency, this figure also presents, neareach point, the estimated operating frequencies consideringno environment test delays. Table 1 summarizes the ASICperformance results presented in figure 7.

4. CONCLUSIONSThis paper presented the ASIC implementation details of areconfigurable network gateway based on the IPv4 protocoland the test results for evaluating the prototyped integratedcircuit performance. Also, informations about the environ-ment test development as well as the bring up procedures tovalidate the designed ASIC were described. The manufac-tured integrated circuit operated without errors consideringthe evaluated tests and the maximum operating frequenciesachieved were around 50MHz and 95MHz for delay time andno delay time consideration, respectively.

50 52 54 56 58 60 62

10

20

30

40

50

60

70

80

90

100

Test Frequency (MHz)

Lost P

ackets

(%

)

95.24MHz 103.08MHz

117.62MHz

123.47MHz

127.65MHz

145.85MHz

Figure 7: Packet Loss Related To Operating Fre-quency

5. ACKNOLEDGMENTSThe authors would like to thank Josue Paulo Jose de Fre-itas, Gustavo Dessbesell and Taimur Gibran Rabuske Kuntzfor their useful discussions and contributions for this work.They also acknowledge the BRAZIL-IP Program and CNPqprocess number 181508/2008-7 by the financial support.

Table 1: Test ResultsTest Frequency Estimated Frequency Lost Packets

(MHz) (MHz) (%)50.00 95.24 1.5752.08 103.08 2.2255.55 117.62 35.7756.82 123.47 54.9057.69 127.65 74.1662.50 145.85 100

6. REFERENCES[1] M. Borella, A. Sears, and J. Jacko. The effects of

internet latency on user perception of informationcontent. In Global Telecommunications Conference,1997. GLOBECOM ’97., IEEE, volume 3, pages 1932–1936 vol.3, nov 1997.

[2] P. de Aguirre, L. Teixeira, C. Muller, F. Herrmann,L. Pieper, J. de Freitas, G. Dessbesell, and J. Martins.A full duplex implementation of internet protocolversion 4 in an fpga device. In Programmable LogicConference (SPL), 2010 VI Southern, pages 159 –162,march 2010.

[3] M. del Rey. Request for comments 791: Internetprotocol. September 1981.