5327 Report

8/10/2019 5327 Report

1/62

Packet Parsing and Analysis Module

For A

Network Router

EE5327 VLSI Design Laboratory

Final Report

Ravi Teja Doddapaneni (4641235)

Surya Ramakrishna Asish Kolanu (4851688)

Abstract:

This report presents the work done on the packet processing module of a network packet

router. A router is used to connect two or more networks. To forward the data from the

source to the destination, router needs the data that is a part of the packet. Therefore, one of

the primary functions of a router is to extract metadata from the incoming packet and verify

its validity. Depending on the extracted data, the router makes the decisions such as the need

to forward the data to another router or the need to drop the packet altogether. As part of this

project, a Verilog code has been written that performs the aforementioned functions that deal

with parsing of incoming data and extraction of information from the incoming packet. A

testbench was also created that verifies the operation of the designed module. It was observed

that the total area occupied by the module is while the power consumption is

. Timing analysis of the module reported a maximum slack of .

Keywords: Router, Verilog, Verification, Testbench, Area, Power, Slack

8/10/2019 5327 Report

2/62

Design Description

The various functions of the router and, more specifically, the parsing and analysis module of

the router are presented below:

1) Packet validation

Check if the protocol version is 4

Extract the header length and check if it is greater than 20 bytes

Extract the packet data length and compare if the incoming data length is same as this

value

2) Checksum calculation: Extract the checksum from the incoming data packet, recalculate

the checksum for the given packet and compare both the values

3) Packet Lifetime Control and Checksum Recalculation:

Decrement the TTL by 1 if the incoming TTL is greater than zero

Calculate a new checksum after the TTL has been decremented

4) Statistics Monitor: Maintain statistics regarding the type of traffic passing through the

router

To achieve the functionality desired, the architecture shown in Fig. 3 is the one that we have

implemented.

As presented in the figure, the primary components in the module are: Controller, Version

and Data Length extractor, Fragmentation module, TTL and checksum extractor, source and

destination address extractors. Finally, at the end of the implementation, verifier modules and

statistics modules are present.

We have taken a conventional controller and datapath approach for the design of the digital

system module. A state machine is used to design the controller and the datapath consists of

both sequential and combinational elements. Each of the elements is designed as a separate

8/10/2019 5327 Report

3/62

Verilog module for the sake of easier verification. All the modules are finally integrated in

the extractor module.

There are three inputs to the analyzer module: clock, reset and the incoming data. The clock

is a system clock which is generated on board, during the physical implementation of the IC.

The reset signal is an active high signal. The function of this signal is to set every module to

the initial state when asserted. The initial processing of the data also begins when this signal

is de-asserted. Finally, the data signal could arbitrarily long, within the limits of the IPv4

packet definition. Since a single IP packet could be thousands of bytes long, it is impractical

to consider that all of the data arrives at the same time. Therefore, we have assumed that 4

bytes (32 bits) of data arrive simultaneously.

One of the assumptions that we make as part of this project is that only IPv4 traffic passes

through the network. For the sake of simplicity, we assume that the options field that

introduced in the previous section is also not present. It is also assumed that buffers are

present at the input and output network interfaces.

8/10/2019 5327 Report

4/62

Fig 3 System Architecture

8/10/2019 5327 Report

5/62

The following sections provide the functioning of the various blocks in the processing

module:

Controller

The controller is implemented as a state machine consisting of two states: detection and

processing. The state diagram in fig 4 shows this operation. A frame is said to be detected if

the incoming preamble matches a standard preset pattern. After the detection of the frame, the

various processing functions, defined previously, are performed. This is done by asserting the

enable signals that are at the input of the five modules connected to the controller.

Fig. 4 State diagram for controller

The frame detect signal is asserted when the preamble sequence is matched. Similarly, the

process end signal is asserted when the stop bit sequence is detected. Once the processing

starts, one module from the five attached modules is selected and the data is input. The

appropriate module is selected by keeping track of the data using a counter and the byte

number of the incoming data.

8/10/2019 5327 Report

6/62

Version and packet length extractor

This module is enabled when the first set of 4 bytes of the header data arrives at the input

interface. The function of this element is to get the IP version of the incoming packet as well

as the total data length that is a part of the packet. This information is later sent to a verifier

module that checks if the version is valid for processing or if the packet has to be discarded.

Fragmentation module

The function of this module is to merely store the second set of 4 bytes of data in a temporary

register. This information extracted is not necessary for further processing at this stage. This

is because we do not consider fragmentation currently for the first phase of the project.

TTL and Checksum Extractor

The third set of 4 bytes of data that is received by the router contains information about the

TTL and the header checksum. This module extracts these the data in these fields and stores

the same in temporary data registers that are then used to drive the inputs of the Packet

Validator and the CRC verifier blocks.

Source Address Extractor

This module is enabled when the fourth set of 32 bits of data is received at the network

interface. This data corresponds to the source address from which the data is sent.

Destination Address Extractor

This module is enabled when the fifth set of 32 bits of data is received at the network

interface. This data corresponds to the destination address to which the data is to be sent.

Packet Validator

The incoming packet can be deemed invalid if either the TTL becomes zero or if the

calculated CRC does not match the CRC value received at the network interface. Even if the

packet is broken and the data length shown in the header does not match the receive data

length, the packet has to be discarded and deemed invalid.

8/10/2019 5327 Report

7/62

CRC Verifier

Cyclic redundancy check (CRC) is an error correcting code used in communication systems

to either detect or correct any errors that may have been caused during transmission. In an

IPv4 packet, the CRC is 16 bit wide and is calculated for the header only, and not the data.

This code is based on polynomial arithmetic. For each type of code, a generator polynomial is

used whose degree is lesser than that of the incoming polynomial. In case of CRC-16. the

following generator is used as a standard:

G(x) = x16+ x15+ x2+ 1

CRC-16 can detect all single and double errors and all errors with odd number of bits.

To calculate the 16 bit CRC of a IP header, the following steps are performed in Verilog

code:

1)

Each 32 bit group of data is split into two sets of 16 bits each

2)

The numbers are then added in temporary registers

3) If there is a carry, it follows the wrap around convention

The circuit used to implement this function is shown in fig 5.

Fig 5 CRC-16 calculation

8/10/2019 5327 Report

8/62

Statistics

One of the auxiliary functions of a router is to classify the incoming packets and to

continuously maintain statistics about the traffic. This is required for security features such as

firewall and also to determine the priority of traffic. For example, video and voice traffic may

get preference over data. The third set of data has protocol field which is used for this

classification.

For easier understanding of the processing module, the IPv4 header is presented in Fig.

8/10/2019 5327 Report

9/62

Typical Processing Flow:

A typical flow for the incoming packet processing is done according to the following steps:

When the first bit arrives, the state machine in Fig. gets activates. It checks for a

particular sequence of incoming bits. If this sequence is confirmed, the incoming bit

stream is detected as a frame sequence and the state machine moves to the second state

that corresponds to the processing. In this state, the various functions mentioned in the

beginning of the section are performed.

Initially, the version and packet length are extracted and verified. The results of this

module are used in blocks as described later.

The fragmentation module merely stores the incoming 32 bits and does not affect the

design in this project,

From the next 32 bit of data, the TTL and checksum are calculated. These values are then

sent to the packet validator module.

For the fourth and fifth clock cycles, the source and destination addresses are extracted by

the respective modules in the design. They do not affect the validator or classifier

modules but, in a real design, they are used in conjunction with the forwarding table to

determine the output port.

After the data arrives, in the next clock cycle, the CRC verifier is activated and the new

CRC is calculated based on the data. This value is sent to the packet validate module.

Finally, depending on the TTL, input, the calculated and extracted CRC values and the

version number, the validity of the packet is determined.

8/10/2019 5327 Report

10/62

The following table describes the pins at the interface of the IC and the external environment:

Pin name Type Function

Clk Input System clock for the module

Data Input 32 wide data to be processed

Reset Input Resets all signals from the

controller to the five modules

such that none of them

processes data

Packet valid Output Depending on the various

results previously, the

validity of the packet is

determined

CRC valid Output After comparing the

calculated CRC and the

received CRC, the output is

either asserted or de-asserted

No_IP Output Total number of IP packets

that passed through the router

No_CRC Output Total number of packets that

have a CRC different from

the received CRC

No_TTL Output Total number of packets that

had a TTL of 0 when they

were received by router

8/10/2019 5327 Report

11/62

Synthesis Results

Synthesizing the design comes with a number of tradeoffs in terms of speed, area and power.

For the preliminary phase, no optimization was done during the process of synthesis.

However, we have now achieved an optimized design that considers the tradeoffs between

speed and area.

The area before optimizingany aspects of the design is as follows:

****************************************Report : areaDesign : extractorVersion: D-2010.03-SP5

Date : Sun May 11 09:25:10 2014****************************************

Information: Updating design information... (UID-85)Library(s) Used:

NangateOpenCellLibrary (File:/home/vlsilab/nangate/NangateOpenCellLibrary_PDKv1_3_v2009_07/synop_db/ng09_7_slow_ecsm.db)

class (File: /home/vlsilab/synopsys/syn_D-2010.03-SP5/libraries/syn/class.db)

Number of ports: 279

Number of nets: 591Number of cells: 7Number of references: 7

Combinational area: 1218.256007Noncombinational area: 2282.251961Net Interconnect area: 602.429228

Total cell area: 3500.507967Total area: 4102.937196

Analysis:

From the report, it can be seen that the non-combinational area is larger than the

combinational area. This is primarily because of the huge number of registers that are present

in the design. These registers store all the data that comes from the incoming packet which is

finally used in the CRC calculation block.

8/10/2019 5327 Report

12/62

The timing report showing the slack before optimizationis given below:

****************************************Report : timing

-path full

-delay max-max_paths 1-sort_by group

Design : extractorVersion: D-2010.03-SP5Date : Sun May 11 09:33:01 2014****************************************

Operating Conditions:Wire Load Model Mode: top

Startpoint: x0/current_state_reg

(rising edge-triggered flip-flop)Endpoint: datarequest(output port)

Path Group: (none)Path Type: max

Des/Clust/Port Wire Load Model Library------------------------------------------------extractor 5K_hvratio_1_1 NangateOpenCellLibrary

Point Incr Path-----------------------------------------------------------x0/current_state_reg/CP (FD2) 0.00 0.00 r

x0/current_state_reg/Q (FD2) 4.00 4.00 rx0/U161/Z (ND2I) 0.62 4.62 fx0/U448/Z (IVI) 0.64 3.26 rx0/U207/ZN (INV_X2) 0.12 3.38 fx0/U182/ZN (INV_X4) 0.18 3.56 rx0/data_request (controller) 0.00 3.56 rU117/ZN (INV_X4) 0.04 3.60 fU116/ZN (INV_X2) 0.16 3.75 rdatarequest (out) 0.00 3.75 rdata arrival time 3.75

clock CLK (rise edge) 7.00 7.00clock network delay (ideal) 0.00 7.00

output external delay -0.38 6.62data required time 6.62-----------------------------------------------------------data required time 6.62data arrival time -3.75-----------------------------------------------------------slack (MET) 2.87

8/10/2019 5327 Report

13/62

The following report shows the power consumption/dissipation before optimization:

****************************************Report : power

-analysis_effort lowDesign : extractorVersion: D-2010.03-SP5Date : Sun May 11 09:26:24 2014****************************************

Library(s) Used:



Information: The library cell 'EOI' in the library 'class' is notcharacterized for internal power. (PWR-227)Information: The library cell 'FD1' in the library 'class' is notcharacterized for internal power. (PWR-227)Information: The library cell 'IVI' in the library 'class' is not

characterized for internal power. (PWR-227)Information: The library cell 'MUX21H' in the library 'class' is notcharacterized for internal power. (PWR-227)Information: The design contains cells, other than constants andblack boxes, that are not characterized for internal power. (PWR-228)


Design Wire Load Model Library------------------------------------------------

extractor 5K_hvratio_1_1 NangateOpenCellLibrary

Global Operating Voltage = 5Power-specific unit information :

Voltage Units = 1VCapacitance Units = 0.100000ffTime Units = 1nsDynamic Power Units = 100nW (derived from V,C,T units)Leakage Power Units = Unitless

Cell Internal Power = 87.5851 uW (39%)Net Switching Power = 135.1566 uW (61%)

8/10/2019 5327 Report

14/62

---------Total Dynamic Power = 222.7416 uW (100%)

Cell Leakage Power = 17139026.0000

Optimization:

Two of the most common methods used to optimize the design are flattening and structuring.

Flattening is a logic optimization step that removes all intermediate variables and uses

Boolean distributive laws to remove all parentheses. Removing poor intermediate variables

enables design compiler to choose more efficient sub-functions. A flattened structure is

generally fast because it consists of only two levels of combinational logic.

Structuring is a logic optimization step that adds intermediate logic and variables to a design.

Subfunctions that most reduce the logic are turned into intermediate variables and factored

out of design equations.

Structuring and Flattening

The following report shows the area after performing both structuring and flattening:

****************************************Report : areaDesign : extractorVersion: D-2010.03-SP5Date : Sun May 11 09:55:33 2014****************************************

Library(s) Used:


class (File: /home/vlsilab/synopsys/syn_D-2010.03-

SP5/libraries/syn/class.db)

Number of ports: 279Number of nets: 593Number of cells: 9Number of references: 9



8/10/2019 5327 Report

15/62

The following timing report shows the slack obtained after performing both structuring and

flattening:

****************************************Report : timing

-path full-delay max-max_paths 1-sort_by group



Startpoint: x0/current_state_reg(rising edge-triggered flip-flop)

Endpoint: datarequest(output port)



Point Incr Path-----------------------------------------------------------x0/current_state_reg/CP (FD2) 0.00 0.00 rx0/current_state_reg/Q (FD2) 4.00 4.00 rx0/U161/Z (ND2I) 0.62 4.62 fx0/U448/Z (IVI) 0.64 3.26 rx0/U207/ZN (INV_X2) 0.12 3.38 fx0/U182/ZN (INV_X4) 0.18 3.56 rx0/data_request (controller) 0.00 3.56 rU117/ZN (INV_X4) 0.04 3.60 fU116/ZN (INV_X2) 0.16 3.75 r

datarequest (out) 0.00 3.75 rdata arrival time 3.75

clock CLK (rise edge) 7.00 7.00clock network delay (ideal) 0.00 7.00output external delay -0.38 6.62data required time 6.62-----------------------------------------------------------data required time 6.62data arrival time -3.75-----------------------------------------------------------slack (MET) 2.87

Analysis:

8/10/2019 5327 Report

16/62

It is seen that although the area has increased there is not much change in the slack.

Therefore, simultaneous flattening and structuring has not helped increase the speed. In fact,

it has only increased the area overhead. This could be because of the large number of inputs

to the CRC calculation block.

Structuring

The following report presents the area occupied by the design when only structuring is

applied as the optimization criteria:





Number of ports: 279Number of nets: 593Number of cells: 9Number of references: 9


Total cell area: 4311.589989

Total area: 4936.788601

The following report presents the slack achieved as part of the optimization process involving

only structuring:

****************************************Report : timing


Design : extractorVersion: D-2010.03-SP5Date : Sun May 11 10:15:18 2014

8/10/2019 5327 Report

17/62

****************************************


Startpoint: x0/process_end_reg

(rising edge-triggered flip-flop)Endpoint: datarequest(output port)



Point Incr Path-----------------------------------------------------------x0/process_end_reg/CP (FD2) 0.00 0.00 r

x0/process_end_reg/QN (FD2) 2.84 2.84 rx0/U45/Z (ND2I) 0.52 3.36 fx0/U43/ZN (INV_X1) 0.68 4.03 rx0/U42/ZN (INV_X4) 0.03 4.06 fx0/U44/ZN (INV_X1) 0.51 4.58 rx0/data_request (controller) 0.00 4.58 rU117/ZN (INV_X4) 0.04 4.61 fU116/ZN (INV_X2) 0.19 4.80 rdatarequest (out) 0.00 4.80 rdata arrival time 4.80

clock CLK (rise edge) 7.00 7.00clock network delay (ideal) 0.00 7.00output external delay -0.38 6.62data required time 6.62-----------------------------------------------------------data required time 6.62data arrival time -4.80-----------------------------------------------------------slack (MET) 1.82

Analysis:

It is seen that there is a negligible decrease in the area as compared to the case when both

flattening and structuring are applied to the design. However, the area has increased as

compared to the case when the design is not optimized. On the other hand, this increase in

area is accompanied by a good amount of decrease in slack. Therefore, structuring has given

a design that is faster compared to the previous two cases.

8/10/2019 5327 Report

18/62

Flattening

The following report presents the area occupied by the design when only flattening is applied

as the optimization criteria:





Number of ports: 279Number of nets: 593Number of cells: 9

Number of references: 9



The following report presents the slack achieved as part of the optimization process involving

only structuring:

8/10/2019 5327 Report

19/62

****************************************Report : timing




Startpoint: x0/current_state_reg(rising edge-triggered flip-flop)

Endpoint: datarequest(output port)

Path Group: (none)

Path Type: max


Point Incr Path-----------------------------------------------------------x0/current_state_reg/CP (FD2) 0.00 0.00 rx0/current_state_reg/QN (FD2) 3.67 3.67 rx0/U47/Z (OR2P) 0.95 4.62 rx0/U43/Z (CLKBUF_X3) 0.20 4.82 rx0/U44/ZN (INV_X1) 0.16 4.99 fx0/data_request (controller) 0.00 4.99 fU117/ZN (INV_X4) 0.09 5.07 rU116/ZN (INV_X2) 0.06 5.14 fdatarequest (out) 0.00 5.14 fdata arrival time 5.14-----------------------------------------------------------(Path is unconstrained)

Analysis:

It is seen that there is a negligible change in the area as compared to the case when both

flattening and structuring are applied to the design. However, the area has increased as

compared to the case when the design is not optimized. On the other hand, this increase in

area is accompanied by a good amount of decrease in slack. However, this increase in speed

is not as much as that compared to the case where only structuring is applied.

Considering that fact that in network processors speed is of utmost importance because of the

exponential increase in traffic, it is necessary to have a design that can process data very

8/10/2019 5327 Report

20/62

quickly. From the three cases considered above, the optimization where only structuring is

performed has the highest speed and least slack. Therefore, this is chosen over the other two

options even though it incurs a small area overhead.

Fault Coverage and Scan Chain Insertion:

Fault simulation was done using ATPG (Automatic Test Pattern Generation) was done for the

design. Both fast and full sequential modes of operation were used. The results are presented

below.

The report below shows that 99.63% coverage was achieved using the fast fault

simulation.

ATPG performed for stuck fault model using internal pattern source.----------------------------------------------------------#patterns #faults #ATPG faults test processstored detect/active red/au/abort coverage CPU time--------- ------------- ------------ -------- --------Begin fast-seq ATPG: #uncollapsed_faults=2178, abort_limit=10, depth=9...1 310 1868 0/0/0 14.53% 0.022 788 1080 0/0/0 50.85% 0.043 144 936 0/0/13 57.62% 0.084 57 879 0/0/13 60.24% 0.095 28 851 0/0/13 61.55% 0.11

6 28 823 0/0/13 62.83% 0.117 5 818 0/0/13 63.06% 0.128 351 467 0/0/13 79.04% 0.139 153 314 0/0/13 86.02% 0.1710 107 207 0/0/13 90.93% 0.1711 92 115 0/0/13 95.16% 0.1712 20 95 0/0/13 96.07% 0.1813 8 87 0/0/13 96.44% 0.1814 14 73 0/0/13 97.08% 0.1815 4 69 0/0/13 97.27% 0.1816 13 56 0/0/13 97.57% 0.1817 13 43 0/0/13 98.16% 0.1918 19 24 0/0/13 99.04% 0.1919 3 21 0/0/13 99.10% 0.1920 3 18 0/0/14 99.17% 0.1921 2 16 0/0/14 99.27% 0.20

8/10/2019 5327 Report

21/62

22 5 11 0/0/14 99.49% 0.2023 3 8 0/0/14 99.63% 0.20

Uncollapsed Stuck Fault Summary Report-----------------------------------------------fault class code #faults

------------------------------ ---- ---------Detected DT 2170Possibly detected PT 0Undetectable UD 48ATPG untestable AU 0Not detected ND 8-----------------------------------------------total faults 2226test coverage 99.63%

Using the full sequential test, we achieved 99.63% fault coverage.

--------------------------------------------#patterns #faults test processsimulated detect/active coverage CPU time--------- ------------- -------- --------1 310 1868 14.53% 0.012 788 1080 50.85% 0.033 144 936 57.62% 0.034 57 879 60.24% 0.035 28 851 61.55% 0.046 28 823 62.83% 0.047 5 818 63.06% 0.04

8 351 467 79.04% 0.049 153 314 86.02% 0.0510 107 207 90.93% 0.0511 92 115 95.16% 0.0512 20 95 96.07% 0.0513 8 87 96.44% 0.0514 14 73 97.08% 0.0615 4 69 97.27% 0.0616 13 56 97.57% 0.0617 13 43 98.16% 0.0618 19 24 99.04% 0.0619 3 21 99.10% 0.0620 3 18 99.17% 0.06

21 2 16 99.27% 0.0622 5 11 99.49% 0.0623 3 8 99.63% 0.06Begin PROOFS fault simulation of 8 Stuck faults on 3 external patterns----------------------------------------------------------------------

--#patterns #faults cum. #faults fault test

processsimulated detect/total detect/active coverage coverage CPU

time--------- ------------- ------------- -------- -------- ------

--3 8 8 2178 0 97.84 100.00

0.00Fault simulation completed: faults simulated = 8, fault coverage =97.84%, test coverage = 100.00%, CPU time = -0.00

8/10/2019 5327 Report

22/62

Fault simulation completed: #patterns=26, CPU time=0.06

The popular design-for-testability (DFT) technique, scan design, was also implemented in

this project. The results for the same are presented below. Fault coverage of 90.58% was

achieved for this implementation.

The fast sequential simulation report is presented below:

----------------------------------------------------------#patterns #faults #ATPG faults test processstored detect/active red/au/abort coverage CPU time--------- ------------- ------------ -------- --------

Begin fast-seq ATPG: #uncollapsed_faults=2230, abort_limit=10, depth=9...1 322 1908 0/0/0 14.73% 0.022 774 1134 0/0/0 49.57% 0.043 149 985 0/0/13 56.52% 0.084 47 938 0/0/13 58.63% 0.095 34 904 0/0/13 60.16% 0.106 21 883 0/0/13 61.10% 0.127 4 879 0/0/13 61.28% 0.138 359 520 0/0/13 77.24% 0.149 175 345 0/0/13 84.96% 0.1610 92 253 0/0/13 89.08% 0.1711 89 164 0/0/13 93.07% 0.1812 16 148 0/0/13 93.79% 0.19

13 13 135 0/0/13 94.37% 0.1914 11 124 0/0/13 94.87% 0.1915 6 118 0/0/13 95.13% 0.2016 12 106 0/0/13 95.40% 0.2017 20 86 0/0/13 96.30% 0.2018 23 63 0/0/13 97.33% 0.2119 20 43 0/0/13 98.23% 0.2120 14 29 0/0/13 98.86% 0.2121 4 25 0/0/14 98.95% 0.2122 2 23 0/0/16 98.99% 0.2223 2 21 0/0/18 99.08% 0.2224 4 17 0/0/20 99.26% 0.2225 1 16 0/0/20 99.30% 0.22

26 1 15 0/0/20 99.33% 0.22

Uncollapsed Stuck Fault Summary Report

8/10/2019 5327 Report

23/62

-----------------------------------------------fault class code #faults------------------------------ ---- ---------Detected DT 2215Possibly detected PT 0Undetectable UD 0

ATPG untestable AU 0Not detected ND 15-----------------------------------------------total faults 2230test coverage 99.33%-----------------------------------------------

The full sequential simulation report is presented below:

------------------------------------------------------------#patterns #faults #ATPG faults test processstored detect/active red/au/abort coverage CPU time--------- ------------- ------------ -------- ----------2 77 1986 0/0/0 11.37% 1.383 967 1019 0/0/0 54.73% 3.654 464 555 0/0/0 75.29% 4.365 248 307 0/0/0 86.41% 6.956 79 228 0/0/0 89.80% 8.637 18 210 0/0/0 90.58% 9.22

MAX total CPU time reached : timeUsed = 49.34, MAX = 30.00 ... Sequential

Test Generation terminated7 0 210 0/0/2 90.58% 49.34

Uncollapsed Stuck Fault Summary Report-----------------------------------------------fault class code #faults------------------------------ ---- ---------Detected DT 2020Possibly detected PT 0Undetectable UD 0ATPG untestable AU 0Not detected ND 210-----------------------------------------------

total faults 2230test coverage 90.58%-----------------------------------------------

8/10/2019 5327 Report

24/62

Verification Plan and Simulation

The high level verification plan is as mentioned below:

Initially, the reset is low and later it is set to high. Since the module has an active high

low reset, the module then starts processing data.

Randomly generate 32 bits of dataevery clock cycle and input to the design

Verify the output with the expected value

One of the most critical blocks in the design is the CRC calculation block. To verify the

functionality of this block, the output from the design is compared with the output from a

C code. The C code generates a 16 bit CRC for the input data. The value that is generated is

then matched with the one produced by the hardware/Verilog module.

For easy and modular verification of the design, a modular approachis followed. As part of

this, a bottom up verification strategy is employed. Initially, the controller is verified and

then the CRC blocks are verified. Finally, after integration, the top level module is verified

using a Verilog testbench. The testbench and the C code for the CRC generation can be found

in Appendix B.

This section of the report presents the simulation results from the module.

8/10/2019 5327 Report

25/62

8/10/2019 5327 Report

26/62

8/10/2019 5327 Report

27/62

8/10/2019 5327 Report

28/62

8/10/2019 5327 Report

29/62

8/10/2019 5327 Report

30/62

8/10/2019 5327 Report

31/62

8/10/2019 5327 Report

32/62

8/10/2019 5327 Report

33/62

Formal Verification:

For formal verification, the Verilog file of the design was compared with the .ddc file.

The reference design was the .ddc file while the implementation was the Verilog file.

The verification was done using Formality.

The results are presented below:

A total of 959 points were matched.

8/10/2019 5327 Report

34/62

Verification succeeded as shown in the following screenshot:

8/10/2019 5327 Report

35/62

Conclusions

8/10/2019 5327 Report

36/62

This project involves the design and verification of a packet parser and analyzer module used

in a network router. This report presents the various design decisions and tradeoffs that were

a part of the project. Additionally, the final results that were achieved have also been

presented.

Design Considerations

The primary function of the packet parser and analyzer module is to extract the necessary

fields from the incoming data packet and to check for its validity. This is done by comparing

various fields such as CRC checksum, TTL, header etc. If any of these fields do not match

those that are specified by the RFC document, the packet is said to be invalid. Furthermore,

the router also keeps a track of the type of packets that pass through. This data is used for

security purposes such as firewall, blocking certain devices etc.

To achieve the functions described above, a controller and datapath approach was taken and

Verilog code was written for the same. Some of the critical components in the design are the

FSM controller, extractor modules, CRC checksum calculation module, packet validator

module and the statistics module.

For the verification of the aforementioned modules, testbenches were written with random

inputs. The random inputs were generated using MATLAB. To verify the accuracy of the

design, a C code was written for the CRC module and the generated outputs were compared

with the same.

Fault simulation and boundary scan were done on the design. The latter method achieved a

fault coverage of 90.58%

As is the case with any ASIC, a number of tradeoffs were made during the process of design

of the module. In case of network processors, speed of operation is of utmost importance.

8/10/2019 5327 Report

37/62

Therefore, during the process of synthesis, a number of optimization techniques such as

structuring, flattening etc. were performed so as to arrive at an optimal design.

The total

The design operates at a frequency of .The total area occupied by the ASIC is

while the total power consumption is

Challenges faced

While the design of the individual blocks was not much of an issue, the primary concern

during the design was that of integrating all the modules with the controller. One problem

that stood out was that of integrating the CRC checksum calculation module with the rest of

the blocks. There was a two cycle clock delay that was being introduced in the module

because of the states being updated in the FSM. To hide this latency, the CRC module had to

be started two cycles earlier.

One of the more non-obvious hurdles faced during the course of the project is in the design of

the finites state machine (FSM). There was a choice between having more than 7 states in a

single state machine and having just two states: detect and process and break up the latter into

a number of smaller blocks. We chose the latter approach because of the considerably lower

complexity and modularity.

Finally, verification of the design proved to be another challenge. This is primarily because

of the large numbers involved in the verification. Consider the case of the CRC checksum

calculation. It is not possible to manually calculate values for the 16 bit CRC. Therefore, a C

code was written for the same and the output from the hardware was manually compares with

that generated by the C code.

By and large, the results of the project are on same as that we wanted to achieve when the

project was initially proposed. However, there is one aspect of the design that we would have

8/10/2019 5327 Report

38/62

liked to modify if we had a second opportunity to design the ASIC. We would have liked our

design to have some kind of sleep circuitry that can reduce the leakage power. Currently, we

notice that there is considerable amount of leakage power in the chip. If there was certain

logic in the design that would completely turn off or drastically reduce the voltage for a

certain section of the design that would reduce the leakage power considerable. For example,

consider the case of the CRC checksum calculation block. This block comes into the picture

only after five sets of 32 bit arrive and are ready to be processed. Until such time, the block is

not needed for any kind of processing. Therefore, this block could be put in a power down

mode until such time as it is needed i.e. 5 clock cycles after the data arrives.

This course titled VLSI Design Laboratory has given exposure to EDA tools that are used

to industry. Furthermore, through the design project, it has also given an opportunity to apply

some of the commonly used design techniques to full fledged designs. Bearing this in mind,

my advice to future students who would take this course is to spend a good amount of time

exploring the tools and get to understand some of the features that would be important for the

design project. While it is close to impossible to get to know and understand the ins and outs

of the tool, it is very important to know what features exist and how they could be used to

create optimized designs with considerable ease.

Appendix A

Verilog Code

8/10/2019 5327 Report

39/62

//Top level module that integrates all blocksmodule extractor ( clk, //clock signal

reset_n, //active low resetdata_in, //32 bit input dataversion, //IP version

total_length, //Data length in packetttl_value, //Time to live value in fieldprotocol, //protocol in packetchecksum_recv, //Received checksum valuesource_address, //Source IP addresdest_address, //Destination IP addresscrc_cal, //Calculated CRC valuedatarequest, //Requested datacounter, //Counter activatedno_of_invalid_checksum, //No of packets with invalid CRCno_of_invalid_ttl, //No of packets with invalid TTLno_of_invalid_ip, //No of packets with invalid versionno_of_invalid_destaddr, //No of packets with invalid

//destination addressno_of_valid, //No of valid packetsno_of_invalid //Total number of invalid packets

);

// interface signalsinput clk, reset_n ;input [31:0] data_in;wire clk, reset_n ;wire [31:0] data_in;

//Outputsoutput [3:0] version;output [15:0] total_length;output [7:0] ttl_value;output [7:0] protocol;output [15:0] checksum_recv;output [31:0] dest_address;output [31:0] source_address;output [15:0] crc_cal;output datarequest;output [15:0] counter;output [15:0] no_of_invalid_checksum;output [15:0] no_of_invalid_ttl;output [15:0] no_of_invalid_ip;output [15:0] no_of_invalid_destaddr;output [15:0]no_of_valid;output [15:0] no_of_invalid;

reg [3:0] version;reg [15:0] total_length;reg [7:0] ttl_value;reg [7:0] protocol;reg [15:0] checksum_recv;reg [31:0] dest_address;reg [31:0] source_address;reg [15:0] crc_cal;

reg datarequest;

8/10/2019 5327 Report

40/62

reg [15:0] counter;

reg [15:0] no_of_invalid_checksum;reg [15:0] no_of_invalid_ttl;reg [15:0] no_of_invalid_ip;

reg [15:0] no_of_invalid_destaddr;reg [15:0]no_of_valid;reg [15:0] no_of_invalid;

wire [31:0] datazero;wire [31:0] dataone;wire [31:0] datatwo;wire [31:0] datathree;wire [31:0] datafour;wire [15:0] bad_check_sum;wire [15:0] bad_ttl;wire [15:0] bad_ip;

wire [15:0] bad_dest_adress;wire [15:0] validity;wire valid_enable;

//Coontroller being integrated with internal signalscontroller x0( .clk(clk),

.reset_n(reset_n),

.data_in(data_in),

.data_zero(datazero),

.data_one(dataone),

.data_two(datatwo),

.data_three(datathree),

.data_four(datafour),

.data_request(datarequest),

.counter(counter));

//Counter zero being integratedcount_zero x1(.clk(clk),.data_zero(datazero), .counter_en(datarequest),.version(version), .total_length(total_length));

//Counter one being integratedcount_one x2 (.clk(clk), .data_zero(dataone), .counter_en(datarequest));

//Counter two being integratedcount_two x3 (.clk(clk), .data_zero(datatwo),.counter_en(datarequest),.ttl_value(ttl_value),.checksum_recv(checksum_recv),.protocol(protocol));

//Counter three being integratedcount_three x4(.clk(clk), .data_zero(datathree), .counter_en(datarequest),.source_address(source_address));

//Counter four being integratedcount_four x5(.clk(clk), .data_zero(datafour), .counter_en(datarequest),.dest_address(dest_address));

//CRC calculation module being integrated

8/10/2019 5327 Report

41/62

crc x6(.data_zero(datazero),.data_one(dataone),.data_two(datatwo),.data_three(datathree),.data_four(datafour),

.counter(counter),.crc_en(datarequest),

.crc_out(crc_cal),

.rst(reset_n),

.clk(clk));

//Packet validator block being integratedvalid x7(.clk(clk),.reset_n(reset_n),.crc_en(datarequest),.version(version),

.total_length(total_length),

.ttl_value(ttl_value),

.protocol(protocol),

.checksum_recv(checksum_recv),.dest_address(dest_address),

.crc_cal(crc_cal),.counter(counter),//outputs.bad_check_sum(bad_check_sum),.bad_ttl(bad_ttl),.bad_ip(bad_ip),.bad_dest_adress(bad_dest_adress),.validity(validity),.valid_enable(valid_enable));

//Statistics block being integratedstats x8(

.clk(clk),.valid_enable(valid_enable),

.bad_check_sum(bad_check_sum),

.bad_ttl(bad_ttl),

.bad_ip(bad_ip),

.bad_dest_adress(bad_dest_adress),

.validity(validity),

.no_of_invalid_checksum(no_of_invalid_checksum),.no_of_invalid_ttl(no_of_invalid_ttl),.no_of_invalid_ip(no_of_invalid_ip),

.no_of_invalid_destaddr(no_of_invalid_destaddr),.no_of_valid(no_of_valid),.no_of_invalid(no_of_invalid)

);endmodule

////MODULES///////////////////FSM CONTROLLER..../////////

module controller(

clk, //clockreset_n, //active low reset

8/10/2019 5327 Report

42/62

data_in, //input data

//data from various counter blocksdata_zero,data_one,

data_two,data_three,data_four,data_request,counter

);

// interface signalsinput clk, reset_n ;input [31:0] data_in;

output [31:0] data_zero;output [31:0] data_one;

output [31:0] data_two;output [31:0] data_three;output [31:0] data_four;output data_request;

output [15:0] counter;

//state parametersparameter CURR_ST_DETECT = 1'b0; //Frame detect stateparameter CURR_ST_PROCESS = 1'b1; //Frame process state

// preamble pattern for start and stopparameter PREAMBLE_PAT = 32'b10101010101010101010101010101011;parameter STOP_BIT = 32'b10101010101010101010101010101000;

// FSM registersreg frame_detect;reg process_end;reg process_start;reg next_state,current_state;

//counter registersreg [15:0] counter;

// registerswire [31:0] data_in;reg [31:0] data_dummy;

// output registersreg [31:0] data_zero_latch;reg [31:0] data_one_latch;reg [31:0] data_two_latch;reg [31:0] data_three_latch;reg [31:0] data_four_latch;

// output wireswire [31:0] data_zero;wire [31:0] data_one;

wire [31:0] data_two;wire [31:0] data_three;

8/10/2019 5327 Report

43/62

wire [31:0] data_four;wire data_request;//wire counter_out;

// assigning current statealways @(current_state or frame_detect or process_end)

begincase ( current_state)

CURR_ST_DETECT:begin

if(frame_detect ==1'b1) begin //If frame is detectednext_state

8/10/2019 5327 Report

44/62

// preamble & stop bit detectionalways@(posedge clk or negedge reset_n)beginif ( reset_n == 1'b0 ) beginframe_detect

8/10/2019 5327 Report

45/62

assign data_request = process_start;//assign counter_out=counter;

endmodule

/////COUNTER 0///////////////////

//Extracts the version and length of data

module count_zero(clk, data_zero, counter_en, version, total_length);

input clk; //clockinput [31:0] data_zero; //data inputinput counter_en; //counter enable

output [3:0] version; //version of IP

output [15:0] total_length; //total length of data in the packet

wire clk;wire [31:0] data_zero;wire counter_en;reg [3:0] version;reg [15:0] total_length;

always @(posedge clk)begin

if(counter_en == 1) begin //Store data in registers depending on the//posirtion

version

8/10/2019 5327 Report

46/62

//Extract CRC and TTL valuesmodule count_two(clk, data_zero, counter_en,ttl_value,checksum_recv,protocol);

input clk;

input [31:0] data_zero;input counter_en;

output [7:0] ttl_value;output [15:0] checksum_recv;output [7:0] protocol;

wire clk;wire [31:0] data_zero;wire counter_en;

reg [7:0] ttl_value;reg [15:0] checksum_recv;

reg [7:0] protocol;

always @(posedge clk) //Store values in register depending on the//position

beginttl_value

8/10/2019 5327 Report

47/62

//////////count4//////////////////

//Destination address extractor

module count_four(clk, data_zero, counter_en, dest_address);

input clk;input [31:0] data_zero;input counter_en;

output [31:0] dest_address;

wire clk;wire [31:0] data_zero;wire counter_en;

reg [31:0] dest_address;

always @(posedge clk)beginif(counter_en == 1) //If counter is enableddest_address

8/10/2019 5327 Report

48/62

if( rst == 0) data_in[159:0] = 0;else beginif((counter > 16'h0004) && (crc_en == 1'b0)) //Once all data is loadedbegindata_in[31:0] = data_zero; //Store data in registers of the blockdata_in[63:32] = data_one; //By concatenating with each other

data_in [95:64] = data_two;data_in [127:96]= data_three;data_in [159:128]= data_four;data_in[79:64] = 16'b0;

endelsebegindata_in[159:0] = data_in[159:0];

lfsr_c

8/10/2019 5327 Report

49/62

lfsr_c[7] = lfsr_q[12] ^ data_in[6] ^ data_in[21] ^ data_in[36] ^data_in[51] ^ data_in[66] ^ data_in[81] ^ data_in[96] ^ data_in[111] ^data_in[126] ^ data_in[141] ^ data_in[156];



lfsr_c[10] = lfsr_q[0] ^ lfsr_q[15] ^ data_in[9] ^ data_in[24] ^data_in[39] ^ data_in[54] ^ data_in[69] ^ data_in[84] ^ data_in[99] ^data_in[114] ^ data_in[129] ^ data_in[144] ^ data_in[159];

lfsr_c[11] = lfsr_q[1] ^ data_in[10] ^ data_in[25] ^ data_in[40] ^data_in[55] ^ data_in[70] ^ data_in[85] ^ data_in[100] ^ data_in[115] ^data_in[130] ^ data_in[145];

lfsr_c[12] = lfsr_q[2] ^ data_in[11] ^ data_in[26] ^ data_in[41] ^data_in[56] ^ data_in[71] ^ data_in[86] ^ data_in[101] ^ data_in[116] ^data_in[131] ^ data_in[146];

lfsr_c[13] = lfsr_q[3] ^ data_in[12] ^ data_in[27] ^ data_in[42] ^

data_in[57] ^ data_in[72] ^ data_in[87] ^ data_in[102] ^ data_in[117] ^data_in[132] ^ data_in[147];lfsr_c[14] = lfsr_q[4] ^ data_in[13] ^ data_in[28] ^ data_in[43] ^

data_in[58] ^ data_in[73] ^ data_in[88] ^ data_in[103] ^ data_in[118] ^data_in[133] ^ data_in[148];

lfsr_c[15] = lfsr_q[5] ^ lfsr_q[6] ^ lfsr_q[7] ^ lfsr_q[8] ^ lfsr_q[9]^ lfsr_q[10] ^ lfsr_q[11] ^ lfsr_q[12] ^ lfsr_q[13] ^ lfsr_q[14] ^lfsr_q[15] ^ data_in[0] ^ data_in[1] ^ data_in[2] ^ data_in[3] ^ data_in[4]^ data_in[5] ^ data_in[6] ^ data_in[7] ^ data_in[8] ^ data_in[9] ^data_in[10] ^ data_in[11] ^ data_in[12] ^ data_in[13] ^ data_in[29] ^data_in[30] ^ data_in[31] ^ data_in[32] ^ data_in[33] ^ data_in[34] ^data_in[35] ^ data_in[36] ^ data_in[37] ^ data_in[38] ^ data_in[39] ^data_in[40] ^ data_in[41] ^ data_in[42] ^ data_in[43] ^ data_in[59] ^data_in[60] ^ data_in[61] ^ data_in[62] ^ data_in[63] ^ data_in[64] ^data_in[65] ^ data_in[66] ^ data_in[67] ^ data_in[68] ^ data_in[69] ^data_in[70] ^ data_in[71] ^ data_in[72] ^ data_in[73] ^ data_in[89] ^data_in[90] ^ data_in[91] ^ data_in[92] ^ data_in[93] ^ data_in[94] ^data_in[95] ^ data_in[96] ^ data_in[97] ^ data_in[98] ^ data_in[99] ^data_in[100] ^ data_in[101] ^ data_in[102] ^ data_in[103] ^ data_in[119] ^data_in[120] ^ data_in[121] ^ data_in[122] ^ data_in[123] ^ data_in[124] ^data_in[125] ^ data_in[126] ^ data_in[127] ^ data_in[128] ^ data_in[129] ^data_in[130] ^ data_in[131] ^ data_in[132] ^ data_in[133] ^ data_in[149] ^data_in[150] ^ data_in[151] ^ data_in[152] ^ data_in[153] ^ data_in[154] ^data_in[155] ^ data_in[156] ^ data_in[157] ^ data_in[158] ^ data_in[159];endend // always

always @(posedge clk) beginif(rst == 1'b0) begin

lfsr_q

8/10/2019 5327 Report

50/62

//Validity verification module

module valid ( clk, //clockreset_n, //resetcrc_en, //CRC enable block

version, //Version of IPtotal_length, //Total length of the datattl_value, //Incoming TTL valueprotocol, //Protocol of incoming datachecksum_recv, //Received checksumdest_address, //Destination addresscrc_cal, //calculated checksumcounter, //counter number

//outputsbad_check_sum, //Activated if checksum is invalidbad_ttl, //Activated if TTL is invalidbad_ip, //Activated if version is invalidbad_dest_adress, //Activated if dest address is invalid

validity, //packet validityvalid_enable //Enable the block);

wire clk, reset_n,crc_en ;

wire [3:0] version;wire [15:0] total_length;wire [7:0] ttl_value;wire [7:0] protocol;wire [15:0] checksum_recv;wire [31:0] dest_address;wire [15:0] crc_cal;wire [15:0] counter;

reg [15:0] temp = 16'b0;

input clk, reset_n,crc_en ;

input [3:0] version;input [15:0] total_length;input [7:0] ttl_value;input [7:0] protocol;input [15:0] checksum_recv;input [31:0] dest_address;input [15:0] crc_cal;input [15:0] counter;

output valid_enable;output [15:0] bad_check_sum;output [15:0] bad_ttl;output [15:0] bad_ip;output [15:0] bad_dest_adress;output [15:0] validity;

reg valid_enable;reg [15:0] bad_check_sum = 16'b0;reg [15:0] bad_ttl = 16'b0;reg [15:0] bad_ip = 16'b0;

reg [15:0] bad_dest_adress = 16'b0;reg [15:0] validity = 16'h0000;

8/10/2019 5327 Report

51/62

always @(posedge clk)begin

if((crc_cal != 16'h0000) && (crc_cal != 16'hffff)) //If CRC is not

//saturatedbegintemp=crc_cal;

valid_enable = 1'b1; //enable the validator block

if(temp != checksum_recv) //If the checksums do not match, invalidbeginbad_check_sum

8/10/2019 5327 Report

52/62

endmodule

/////////stat///

//Statistics module stores the number of types of invalid and valid data

module stats(

//inputsclk, //clock inputvalid_enable, //validity block enablebad_check_sum, //Bad checksum packetbad_ttl, //Bad TTL packetbad_ip, //Bad version packetbad_dest_adress, //Bad destination address packetvalidity, //Determines whether packet is valid or not

//Corresponding counters for different types of invalidityno_of_invalid_checksum,

no_of_invalid_ttl,no_of_invalid_ip ,no_of_invalid_destaddr,no_of_valid,no_of_invalid

);

input clk;input valid_enable;input [15:0] bad_check_sum;input [15:0] bad_ttl;input [15:0] bad_ip;input[15:0] bad_dest_adress;input [15:0] validity;

wire clk;wire valid_enable;wire [15:0] bad_check_sum;wire [15:0] bad_ttl;wire [15:0] bad_ip;wire [15:0] bad_dest_adress;wire [15:0] validity;

output[15:0] no_of_invalid_checksum;output [15:0] no_of_invalid_ttl;output [15:0] no_of_invalid_ip;output [15:0] no_of_invalid_destaddr;output[15:0] no_of_valid;output[15:0] no_of_invalid;

//Initializationsreg [15:0] no_of_invalid_checksum = 16'b0;reg [15:0] no_of_invalid_ttl = 16'b0;reg [15:0] no_of_invalid_ip = 16'b0;reg [15:0] no_of_invalid_destaddr = 16'b0;reg [15:0] no_of_valid = 16'b0;reg [15:0] no_of_invalid = 16'b0;reg temp1;

always @(negedge clk)

8/10/2019 5327 Report

53/62

begintemp1 = valid_enable;

if((validity == 16'hffff) && (temp1 == 1'b0)) //If packet is validno_of_valid = no_of_valid + 1; //Update validity counter

elseno_of_invalid = no_of_invalid + 1;

if((bad_check_sum==16'hffff) && (temp1 == 1'b0)) //If checksum id badno_of_invalid_checksum = no_of_invalid_checksum + 1; //update CRC counterelseno_of_invalid_checksum = no_of_invalid_checksum;

if((bad_ttl==16'hffff) && (temp1 == 1'b0)) //if TTL is badno_of_invalid_ttl = no_of_invalid_ttl + 1; /update TTL counterelseno_of_invalid_ttl = no_of_invalid_ttl ;

if((bad_ip==16'hffff) && (temp1 == 1'b0)) //if version is wrongno_of_invalid_ip = no_of_invalid_ip + 1; //update version counterelseno_of_invalid_ip = no_of_invalid_ip;

if((bad_dest_adress==16'hffff) && (temp1 == 1'b0)) //If destination addressno_of_invalid_destaddr = no_of_invalid_destaddr + 1; //is wrongelseno_of_invalid_destaddr = no_of_invalid_destaddr;//update respective counter

endendmodule

Appendix B

Schematics

8/10/2019 5327 Report

54/62

This section presents the schematics that were synthesized in this project.

Top level module

Each of the blocks in the schematic have been annotated.

Controller block

8/10/2019 5327 Report

55/62

Validator block

8/10/2019 5327 Report

56/62

Statistics block

8/10/2019 5327 Report

57/62

CRC calculation block

8/10/2019 5327 Report

58/62

Controller after flattening

8/10/2019 5327 Report

59/62

Validator after flattening

8/10/2019 5327 Report

60/62

Statistics block after flattening

8/10/2019 5327 Report

61/62

Gate and register level schematic for entire design

8/10/2019 5327 Report

62/62

Schematic after scan insertion

Analysis:It can be seen that flattening has led to a denser schematic being generated. However, it has

also, resulted in an increase in area as is visible in the schematic. There are more

internconnnections between gates and this has led to a larger area.

5327 Report

Documents

Transcript of 5327 Report