InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Flexible Test Case Driven Verification Method for Network Processor

IP.com Disclosure Number: IPCOM000184051D
Original Publication Date: 2009-Jun-09
Included in the Prior Art Database: 2009-Jun-09
Document File: 3 page(s) / 36K

Publishing Venue



Described is a flexible test case driven verification method for network processors. A random frame/cell generator can randomize all parameters regarding each task and provide expected results each task. The Network Processor under test then can be programmed to interpret and execute each task. Some of these ideas have been used before, but the unique aspect of this invention is the combination of methods.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 51% of the total text.

Page 1 of 3

Ȉ ˇ ˄ ˙

Ȉ ˇ ˄ ˙ Ȉ ˇ ˄ ˙

A typical network processor receives frame inputs, processes them and sends them out again. Typical processing consists of routing, in which a source and destination MAC address is looked up and a new frame is constructed and sent out again. The tasks associated with normal operation are fairly static, such as converting a frame from one format to another format. Standard network processor tasks using existing working environments would not stress a new, programmable network processor. Using a 'Flexible Test Case Driven Verification Method for

Network Processors',

             a set of tasks are defined that exercise all design features of a new network processor design. The tasks are not related to any existing network protocol. The network processor is then programmed to implement each basic task. A frame generator is written to randomly generate input frames, containing tasks and predicting output frames. Our implementation used a 20-byte verification frame header format.

     Let the long verification frame format header (VFFH) be 5 words long, W0, W1, W2, W3, and W4. And each word has bits numbered 31 down to 0, left to right. A frame header is 20 bytes and the rest of the length of the frame is data. We defined a short VFFH of one byte in length and containing the most significant bit value of 0b1. Any frame containing the most significant bit value of 0b0 is long VFFH.

Table 1 - "Verification Frame Format Header"

Word 0

Bit 31 = Short frame bit. If a system is configured to support short frames and this bit is a

0b1, the frame is less than 20 bytes.

Bits 30:16 = Guided Frame Key. A guided frame is part of a prearranged network path for quick handling of high volume traffic.

Bits 15:00 = Frame ID. Each frame in and out of the system is given a unique frame ID.

Word 1

Bits 31:27 = Frame Control Info bits 4:0

Bit 26 = Q, Quality required bit

Bits 25:16 = QID[9:0] , quality of service ID

Bit 15 = Parity

Bits 14:06 = PQID[8:0]

Word 2

Bits 31:24 = Frame Allocation Control Block 1 index

Bits 23:16 = Frame Allocation Control Block 2 index

Bits 15:08 = Test Scenario

Bit 07 = load/store

Bits 06:00 = Latency

Word 3

Bits 31:24 = Byte 1

Bits 23:16 = Byte 2

Bits 15:08 = Byte 3

Bits 07:00 = Byte 4

Word 4


Page 2 of 3

Bits 31:24 = Byte 5

Bits 23:16 = Byte 6

Bits 15:08 = Byte 7

Bits 07:00 = Byte 8

Table 2 - 'Test Scenarios'

x"00" - Simple Unicast frame Enqueue
x"01" - Read 1st 2 Bytes of Header and compare
x"02" - Read Byte 65 in frame and compare with byte B3
x"03" - Read Byte pointed to by B1 || B2 and compare to byte B3 x"04" - Break buffer at byte pointed to by B1 || B2
x"05" - Change 1st buffer
x"06" - Change buffer containing the byte pointed to by B1 || B2 x"07" - Replace Halfword pointed to by B1 || B2 with bytes in B3 || B4 x"08" - Recirculate Frame to GD0 Queue
x"09" - Recirculate Frame to GD1 Queue
x"0C" - Recirculate Frame to GF Queue
x"0D" - Recirculate Frame to GG Queue