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

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
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.

Fig 3 System Architecture


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.
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.
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) = x
16
+ x
15
+ x
2
+ 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
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.










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.




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

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 optimizing any aspects of the design is as follows:
****************************************
Report : area
Design : extractor
Version: 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: 591
Number of cells: 7
Number of references: 7

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

Total cell area: 3500.507967
Total 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.


The timing report showing the slack before optimization is given below:

****************************************
Report : timing
-path full
-delay max
-max_paths 1
-sort_by group
Design : extractor
Version: D-2010.03-SP5
Date : 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 r
x0/U161/Z (ND2I) 0.62 4.62 f
x0/U448/Z (IVI) 0.64 3.26 r
x0/U207/ZN (INV_X2) 0.12 3.38 f
x0/U182/ZN (INV_X4) 0.18 3.56 r
x0/data_request (controller) 0.00 3.56 r
U117/ZN (INV_X4) 0.04 3.60 f
U116/ZN (INV_X2) 0.16 3.75 r
datarequest (out) 0.00 3.75 r
data arrival time 3.75

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













The following report shows the power consumption/dissipation before optimization:
****************************************
Report : power
-analysis_effort low
Design : extractor
Version: D-2010.03-SP5
Date : Sun May 11 09:26:24 2014
****************************************


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)

Information: The library cell 'EOI' in the library 'class' is not
characterized for internal power. (PWR-227)
Information: The library cell 'FD1' in the library 'class' is not
characterized 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 not
characterized for internal power. (PWR-227)
Information: The design contains cells, other than constants and
black boxes, that are not characterized for internal power. (PWR-
228)

Operating Conditions:
Wire Load Model Mode: top

Design Wire Load Model Library
------------------------------------------------
extractor 5K_hvratio_1_1 NangateOpenCellLibrary


Global Operating Voltage = 5
Power-specific unit information :
Voltage Units = 1V
Capacitance Units = 0.100000ff
Time Units = 1ns
Dynamic 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%)
---------
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 : area
Design : extractor
Version: D-2010.03-SP5
Date : Sun May 11 09:55:33 2014
****************************************

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: 593
Number of cells: 9
Number of references: 9

Combinational area: 1458.726013
Noncombinational area: 2861.977976
Net Interconnect area: 625.012570

Total cell area: 4320.703989
Total area: 4945.716559








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
Design : extractor
Version: D-2010.03-SP5
Date : Sun May 11 09:54:47 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 r
x0/U161/Z (ND2I) 0.62 4.62 f
x0/U448/Z (IVI) 0.64 3.26 r
x0/U207/ZN (INV_X2) 0.12 3.38 f
x0/U182/ZN (INV_X4) 0.18 3.56 r
x0/data_request (controller) 0.00 3.56 r
U117/ZN (INV_X4) 0.04 3.60 f
U116/ZN (INV_X2) 0.16 3.75 r
datarequest (out) 0.00 3.75 r
data arrival time 3.75

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


Analysis:
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:
****************************************
Report : area
Design : extractor
Version: D-2010.03-SP5
Date : Sun May 11 10:14:48 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: 593
Number of cells: 9
Number of references: 9

Combinational area: 1456.440013
Noncombinational area: 2855.149976
Net Interconnect area: 625.198612

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
-path full
-delay max
-max_paths 1
-sort_by group
Design : extractor
Version: D-2010.03-SP5
Date : Sun May 11 10:15:18 2014
****************************************

Operating Conditions:
Wire Load Model Mode: top

Startpoint: x0/process_end_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/process_end_reg/CP (FD2) 0.00 0.00 r
x0/process_end_reg/QN (FD2) 2.84 2.84 r
x0/U45/Z (ND2I) 0.52 3.36 f
x0/U43/ZN (INV_X1) 0.68 4.03 r
x0/U42/ZN (INV_X4) 0.03 4.06 f
x0/U44/ZN (INV_X1) 0.51 4.58 r
x0/data_request (controller) 0.00 4.58 r
U117/ZN (INV_X4) 0.04 4.61 f
U116/ZN (INV_X2) 0.19 4.80 r
datarequest (out) 0.00 4.80 r
data arrival time 4.80

clock CLK (rise edge) 7.00 7.00
clock network delay (ideal) 0.00 7.00
output external delay -0.38 6.62
data required time 6.62
-----------------------------------------------------------
data required time 6.62
data 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.











Flattening
The following report presents the area occupied by the design when only flattening is applied
as the optimization criteria:
****************************************
Report : area
Design : extractor
Version: D-2010.03-SP5
Date : Sun May 11 10:12:33 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: 593
Number of cells: 9
Number of references: 9

Combinational area: 1459.194013
Noncombinational area: 2861.977976
Net Interconnect area: 625.234072

Total cell area: 4321.171989
Total area: 4946.406061

The following report presents the slack achieved as part of the optimization process involving
only structuring:
****************************************
Report : timing
-path full
-delay max
-max_paths 1
-sort_by group
Design : extractor
Version: D-2010.03-SP5
Date : Sun May 11 09:49:08 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/QN (FD2) 3.67 3.67 r
x0/U47/Z (OR2P) 0.95 4.62 r
x0/U43/Z (CLKBUF_X3) 0.20 4.82 r
x0/U44/ZN (INV_X1) 0.16 4.99 f
x0/data_request (controller) 0.00 4.99 f
U117/ZN (INV_X4) 0.09 5.07 r
U116/ZN (INV_X2) 0.06 5.14 f
datarequest (out) 0.00 5.14 f
data 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
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 process
stored 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.02
2 788 1080 0/0/0 50.85% 0.04
3 144 936 0/0/13 57.62% 0.08
4 57 879 0/0/13 60.24% 0.09
5 28 851 0/0/13 61.55% 0.11
6 28 823 0/0/13 62.83% 0.11
7 5 818 0/0/13 63.06% 0.12
8 351 467 0/0/13 79.04% 0.13
9 153 314 0/0/13 86.02% 0.17
10 107 207 0/0/13 90.93% 0.17
11 92 115 0/0/13 95.16% 0.17
12 20 95 0/0/13 96.07% 0.18
13 8 87 0/0/13 96.44% 0.18
14 14 73 0/0/13 97.08% 0.18
15 4 69 0/0/13 97.27% 0.18
16 13 56 0/0/13 97.57% 0.18
17 13 43 0/0/13 98.16% 0.19
18 19 24 0/0/13 99.04% 0.19
19 3 21 0/0/13 99.10% 0.19
20 3 18 0/0/14 99.17% 0.19
21 2 16 0/0/14 99.27% 0.20
22 5 11 0/0/14 99.49% 0.20
23 3 8 0/0/14 99.63% 0.20

Uncollapsed Stuck Fault Summary Report
-----------------------------------------------
fault class code #faults
------------------------------ ---- ---------
Detected DT 2170
Possibly detected PT 0
Undetectable UD 48
ATPG untestable AU 0
Not detected ND 8
-----------------------------------------------
total faults 2226
test coverage 99.63%




Using the full sequential test, we achieved 99.63% fault coverage.
--------------------------------------------
#patterns #faults test process
simulated detect/active coverage CPU time
--------- ------------- -------- --------
1 310 1868 14.53% 0.01
2 788 1080 50.85% 0.03
3 144 936 57.62% 0.03
4 57 879 60.24% 0.03
5 28 851 61.55% 0.04
6 28 823 62.83% 0.04
7 5 818 63.06% 0.04
8 351 467 79.04% 0.04
9 153 314 86.02% 0.05
10 107 207 90.93% 0.05
11 92 115 95.16% 0.05
12 20 95 96.07% 0.05
13 8 87 96.44% 0.05
14 14 73 97.08% 0.06
15 4 69 97.27% 0.06
16 13 56 97.57% 0.06
17 13 43 98.16% 0.06
18 19 24 99.04% 0.06
19 3 21 99.10% 0.06
20 3 18 99.17% 0.06
21 2 16 99.27% 0.06
22 5 11 99.49% 0.06
23 3 8 99.63% 0.06
Begin PROOFS fault simulation of 8 Stuck faults on 3 external patterns
----------------------------------------------------------------------
--
#patterns #faults cum. #faults fault test
process
simulated detect/total detect/active coverage coverage CPU
time
--------- ------------- ------------- -------- -------- ------
--
3 8 8 2178 0 97.84 100.00
0.00
Fault simulation completed: faults simulated = 8, fault coverage =
97.84%, test coverage = 100.00%, CPU time = -0.00
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 process
stored 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.02
2 774 1134 0/0/0 49.57% 0.04
3 149 985 0/0/13 56.52% 0.08
4 47 938 0/0/13 58.63% 0.09
5 34 904 0/0/13 60.16% 0.10
6 21 883 0/0/13 61.10% 0.12
7 4 879 0/0/13 61.28% 0.13
8 359 520 0/0/13 77.24% 0.14
9 175 345 0/0/13 84.96% 0.16
10 92 253 0/0/13 89.08% 0.17
11 89 164 0/0/13 93.07% 0.18
12 16 148 0/0/13 93.79% 0.19
13 13 135 0/0/13 94.37% 0.19
14 11 124 0/0/13 94.87% 0.19
15 6 118 0/0/13 95.13% 0.20
16 12 106 0/0/13 95.40% 0.20
17 20 86 0/0/13 96.30% 0.20
18 23 63 0/0/13 97.33% 0.21
19 20 43 0/0/13 98.23% 0.21
20 14 29 0/0/13 98.86% 0.21
21 4 25 0/0/14 98.95% 0.21
22 2 23 0/0/16 98.99% 0.22
23 2 21 0/0/18 99.08% 0.22
24 4 17 0/0/20 99.26% 0.22
25 1 16 0/0/20 99.30% 0.22
26 1 15 0/0/20 99.33% 0.22

Uncollapsed Stuck Fault Summary Report
-----------------------------------------------
fault class code #faults
------------------------------ ---- ---------
Detected DT 2215
Possibly detected PT 0
Undetectable UD 0
ATPG untestable AU 0
Not detected ND 15
-----------------------------------------------
total faults 2230
test coverage 99.33%
-----------------------------------------------






The full sequential simulation report is presented below:
------------------------------------------------------------
#patterns #faults #ATPG faults test process
stored detect/active red/au/abort coverage CPU time
--------- ------------- ------------ -------- ----------
2 77 1986 0/0/0 11.37% 1.38
3 967 1019 0/0/0 54.73% 3.65
4 464 555 0/0/0 75.29% 4.36
5 248 307 0/0/0 86.41% 6.95
6 79 228 0/0/0 89.80% 8.63
7 18 210 0/0/0 90.58% 9.22

MAX total CPU time reached : timeUsed = 49.34, MAX = 30.00 ... Sequential
Test Generation terminated
7 0 210 0/0/2 90.58% 49.34

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































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 data every 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 approach is 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.








































































































































































































































































































































































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.


Verification succeeded as shown in the following screenshot:




Conclusions
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.
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
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

//Top level module that integrates all blocks
module extractor ( clk, //clock signal
reset_n, //active low reset
data_in, //32 bit input data
version, //IP version
total_length, //Data length in packet
ttl_value, //Time to live value in field
protocol, //protocol in packet
checksum_recv, //Received checksum value
source_address, //Source IP addres
dest_address, //Destination IP address
crc_cal, //Calculated CRC value
datarequest, //Requested data
counter, //Counter activated
no_of_invalid_checksum, //No of packets with invalid CRC
no_of_invalid_ttl, //No of packets with invalid TTL
no_of_invalid_ip, //No of packets with invalid version
no_of_invalid_destaddr, //No of packets with invalid
//destination address
no_of_valid, //No of valid packets
no_of_invalid //Total number of invalid packets
);

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


//Outputs
output [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;
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 signals
controller 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 integrated
count_zero x1(.clk(clk),.data_zero(datazero), .counter_en(datarequest),
.version(version), .total_length(total_length));

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

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

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

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


//CRC calculation module being integrated
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 integrated
valid 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 integrated
stats 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, //clock
reset_n, //active low reset

data_in, //input data

//data from various counter blocks
data_zero,
data_one,
data_two,
data_three,
data_four,
data_request,counter
);


// interface signals
input 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 parameters
parameter CURR_ST_DETECT = 1'b0; //Frame detect state
parameter CURR_ST_PROCESS = 1'b1; //Frame process state

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


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

//counter registers
reg [15:0] counter;


// registers
wire [31:0] data_in;
reg [31:0] data_dummy;

// output registers
reg [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 wires
wire [31:0] data_zero;
wire [31:0] data_one;
wire [31:0] data_two;
wire [31:0] data_three;
wire [31:0] data_four;
wire data_request;
//wire counter_out;

// assigning current state
always @(current_state or frame_detect or process_end)
begin
case ( current_state)

CURR_ST_DETECT:
begin
if(frame_detect ==1'b1) begin //If frame is detected
next_state <= CURR_ST_PROCESS; //Start processing
process_start <=1'b0;
end
else begin
next_state <= CURR_ST_DETECT; //Otherwise stay in the same state
process_start <=1'b0;
end
end

CURR_ST_PROCESS:
begin
if (process_end == 1'b0) begin //If the processing has not ended
next_state <= CURR_ST_PROCESS; //stay in the same state
process_start <= 1'b1;
end
else begin
next_state <= CURR_ST_DETECT;
process_start <= 1'b0;
end
end
endcase
end

// moving to next state on new clock cycle
always@(posedge clk or negedge reset_n)
begin
if ( reset_n == 1'b0)
current_state <= CURR_ST_DETECT;
else
current_state <= next_state;
end


//counter logic : to end the process state and move to detect state
always@(posedge clk or negedge reset_n)
begin
if ( reset_n == 1'b0 ) //If reset is activates, reset all bits to 0
counter <= 16'b0;
else if( process_start == 1'b1 ) //Otherwise increment count on every
//clock cycle
counter <= counter + 1;
else if( process_start == 1'b0)
counter <= 1'b0;
else
counter <= counter;
end



// preamble & stop bit detection
always@(posedge clk or negedge reset_n)
begin
if ( reset_n == 1'b0 ) begin
frame_detect <=1'b0;
process_end <=1'b0;
end
else if(current_state == CURR_ST_DETECT)
begin
if(data_in == PREAMBLE_PAT)
frame_detect <= 1'b1;
end
else if(current_state == CURR_ST_PROCESS)
begin
if(data_in == STOP_BIT)
process_end <= 1'b1;
else begin
frame_detect <= 1'b0;
process_end <= 1'b0;
end
end
end

// data extraction and output to the count 0->4 blocks
always@(posedge clk or negedge reset_n)
begin
if (reset_n == 1'b0) begin //Initially no counter is active
data_zero_latch <= 32'b0;
data_one_latch <= 32'b0;
data_two_latch <= 32'b0;
data_three_latch<= 32'b0;
data_four_latch <= 32'b0;
end

else if(counter == 16'h0001) //depending on the count value, data is
//assigned to the right counter
data_zero_latch <= data_in;
else if(counter == 16'h0002)
data_one_latch <= data_in;
else if(counter == 16'h0003)
data_two_latch <= data_in;
else if(counter == 16'h0004)
data_three_latch <= data_in;
else if(counter == 16'h0005)
data_four_latch <= data_in;
else begin
data_zero_latch <= data_zero_latch;
data_one_latch <= data_one_latch;
data_two_latch <= data_two_latch;
data_three_latch<= data_three_latch;
data_four_latch <= data_four_latch;
data_dummy <= data_in;
end
end

// driving the output wires
assign data_zero = data_zero_latch;
assign data_one = data_one_latch;
assign data_two = data_two_latch;
assign data_three = data_three_latch;
assign data_four = data_four_latch;
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; //clock
input [31:0] data_zero; //data input
input 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 <= data_zero [31:28];
total_length <= data_zero [15:0];
end
end

endmodule

//////////////counter 1/////////////////////

//Fragmentation module

module count_one(clk, data_zero, counter_en);

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

reg [31:0] tempdat;

always @(posedge clk)
begin
tempdat <= data_zero; //temporarily stores the data in a variable
end

endmodule



////////////////////////counter2/////////////////


//Extract CRC and TTL values
module 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
begin
ttl_value <= data_zero [31:24];
checksum_recv <= data_zero [15:0];
protocol <= data_zero [23:16];
end
endmodule



/////////////////////count 3///////////////////

//Extract source address

module count_three(clk, data_zero, counter_en, source_address);

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

output [31:0] source_address;


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

reg [31:0] source_address;

always @(posedge clk)
begin
if(counter_en == 1) //If counter is enabled
source_address <= data_zero; //store data in source_address register
end

endmodule



//////////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)
begin
if(counter_en == 1) //If counter is enabled
dest_address <= data_zero; //Store data in destination address
//register
end

endmodule


/////////////////crc//////////////////

//CRC checksum calculation block
module crc(
input [31:0] data_zero, //Data from five counters
input [31:0] data_one,
input [31:0] data_two,
input [31:0] data_three,
input [31:0] data_four,

input [15:0] counter,

input crc_en,
input rst,
input clk

output [15:0] crc_out,
);

wire [15:0] crc_out;
wire [15:0] crc_out_cal;
wire [31:0] data_zero;

reg [159:0] data_in;
reg [15:0] lfsr_q,lfsr_c;
reg temp;

assign crc_out = lfsr_q;



always @(*) begin
if( rst == 0) data_in[159:0] = 0;
else begin
if((counter > 16'h0004) && (crc_en == 1'b0)) //Once all data is loaded
begin
data_in[31:0] = data_zero; //Store data in registers of the block
data_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;
end
else
begin
data_in[159:0] = data_in[159:0];
lfsr_c<= {16{1'b0}};
end
end
end


//Logic as shown in the previous section
always @(posedge clk) begin
if((counter > 16'h0006) && (crc_en == 1'b0))
begin
lfsr_c[0] = 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[14] ^ 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[44] ^ 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[74] ^ 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[104] ^ 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[134] ^ 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];
lfsr_c[1] = lfsr_q[6] ^ data_in[0] ^ data_in[15] ^ data_in[30] ^
data_in[45] ^ data_in[60] ^ data_in[75] ^ data_in[90] ^ data_in[105] ^
data_in[120] ^ data_in[135] ^ data_in[150];
lfsr_c[2] = lfsr_q[7] ^ data_in[1] ^ data_in[16] ^ data_in[31] ^
data_in[46] ^ data_in[61] ^ data_in[76] ^ data_in[91] ^ data_in[106] ^
data_in[121] ^ data_in[136] ^ data_in[151];
lfsr_c[3] = lfsr_q[8] ^ data_in[2] ^ data_in[17] ^ data_in[32] ^
data_in[47] ^ data_in[62] ^ data_in[77] ^ data_in[92] ^ data_in[107] ^
data_in[122] ^ data_in[137] ^ data_in[152];
lfsr_c[4] = lfsr_q[9] ^ data_in[3] ^ data_in[18] ^ data_in[33] ^
data_in[48] ^ data_in[63] ^ data_in[78] ^ data_in[93] ^ data_in[108] ^
data_in[123] ^ data_in[138] ^ data_in[153];
lfsr_c[5] = lfsr_q[10] ^ data_in[4] ^ data_in[19] ^ data_in[34] ^
data_in[49] ^ data_in[64] ^ data_in[79] ^ data_in[94] ^ data_in[109] ^
data_in[124] ^ data_in[139] ^ data_in[154];
lfsr_c[6] = lfsr_q[11] ^ data_in[5] ^ data_in[20] ^ data_in[35] ^
data_in[50] ^ data_in[65] ^ data_in[80] ^ data_in[95] ^ data_in[110] ^
data_in[125] ^ data_in[140] ^ data_in[155];
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[8] = lfsr_q[13] ^ data_in[7] ^ data_in[22] ^ data_in[37] ^
data_in[52] ^ data_in[67] ^ data_in[82] ^ data_in[97] ^ data_in[112] ^
data_in[127] ^ data_in[142] ^ data_in[157];
lfsr_c[9] = lfsr_q[14] ^ data_in[8] ^ data_in[23] ^ data_in[38] ^
data_in[53] ^ data_in[68] ^ data_in[83] ^ data_in[98] ^ data_in[113] ^
data_in[128] ^ data_in[143] ^ data_in[158];
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];
end
end // always


always @(posedge clk) begin
if(rst == 1'b0) begin
lfsr_q <= {16{1'b1}};
end
else begin
lfsr_q <= lfsr_c;


end
end
endmodule


///////////////valid//////////////

//Validity verification module

module valid ( clk, //clock
reset_n, //reset
crc_en, //CRC enable block
version, //Version of IP
total_length, //Total length of the data
ttl_value, //Incoming TTL value
protocol, //Protocol of incoming data
checksum_recv, //Received checksum
dest_address, //Destination address
crc_cal, //calculated checksum
counter, //counter number
//outputs
bad_check_sum, //Activated if checksum is invalid
bad_ttl, //Activated if TTL is invalid
bad_ip, //Activated if version is invalid
bad_dest_adress, //Activated if dest address is invalid
validity, //packet validity
valid_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;



always @(posedge clk)
begin
if((crc_cal != 16'h0000) && (crc_cal != 16'hffff)) //If CRC is not
//saturated
begin
temp=crc_cal;


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

if(temp != checksum_recv) //If the checksums do not match, invalid
begin
bad_check_sum <= 16'hffff;
validity <=16'h0000;
end
else

begin
bad_check_sum <= 16'h0000; //If TTL is zero, ivalid
if(ttl_value == 0)
begin
bad_ttl<=16'hffff;
validity<=16'b0;

end
else

begin
bad_ttl<=16'b0;
if(version != 4'b1001) //If version is not IP4, invalid
begin
bad_ip<=16'hffff;
validity<=16'b0;

end
else
begin
bad_ip<=16'b0;

if(dest_address== 32'b0) //If destination address is all zeroes, invalid
begin
bad_dest_adress<=16'hffff;
validity<=16'b0;
end
else
begin
bad_dest_adress<=16'b0; //Update corresponding variables
validity<=16'hffff;
valid_enable = 1'b0;

end
end
end
end
end
else
temp = temp ;
end
endmodule


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

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

//inputs
clk, //clock input
valid_enable, //validity block enable
bad_check_sum, //Bad checksum packet
bad_ttl, //Bad TTL packet
bad_ip, //Bad version packet
bad_dest_adress, //Bad destination address packet
validity, //Determines whether packet is valid or not

//Corresponding counters for different types of invalidity
no_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;

//Initializations
reg [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)
begin
temp1 = valid_enable;


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


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

if((bad_ttl==16'hffff) && (temp1 == 1'b0)) //if TTL is bad
no_of_invalid_ttl = no_of_invalid_ttl + 1; /update TTL counter
else
no_of_invalid_ttl = no_of_invalid_ttl ;

if((bad_ip==16'hffff) && (temp1 == 1'b0)) //if version is wrong
no_of_invalid_ip = no_of_invalid_ip + 1; //update version counter
else
no_of_invalid_ip = no_of_invalid_ip;

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


end
endmodule









Appendix B
Schematics
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

Validator block



Statistics block


CRC calculation block











































Controller after flattening


Validator after flattening



Statistics block after flattening


Gate and register level schematic for entire design



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.
Similarly, scan insertion has also led to a change in area and synthesized schematic.