Packet Decoder
How hard can it be?
You recently got a new task to code a packet decoder module for a network processing unit. The packet decoder is responsible for taking in a stream of packets and classifying them into two categories: big packets and small packets. Looking at the task, you think how hard a packet decoder can be and decide to hand-over this task to your intern, who graciously accepts it. You give the intern the specifications for the packet decoder and they start working on it.
After a few hours and spending $$ amount on burning tokens, the intern comes back to you with the code for the packet decoder. The code seems to be functionally correct, you review the testbench and the code and it seems to be doing what it is supposed to do. Thinking that the task is complete, you review the code and let it be merged on a FRIDAY evening.
You come back to office on Monday morning and see that you have been getting bombarded with comments about how the timing degradation caused by the packet decoder module. You are not sure what to do, but you know that you need to fix the timing issues as soon as possible.
Given the specifications for the packet decoder, identify the potential timing issues in the code and suggest possible solutions to fix them.
All the flops should be positive edge triggered with active high resets (if any).
Interface Definition
pkts_i => A 512-bit input vector representing the incoming packets
big_pkt_o => The output vector indicating big packets
small_pkt_o => The output vector indicating small packetsA packet is represented by a 2-bit pattern in the input vector. The first 2 bits of each packet indicate the type of the packet. The remaining bits of the packet is the payload of the packet. The packet decoder needs to classify the packets based on the first 2 bits and output the corresponding big and small packet vectors.
Small Packet
A small packet is only 16 bits long and is represented by the following 2-bit patterns in the LSB of the packet:
- 00: Small Packet Type 0
- 01: Small Packet Type 1
- 10: Small Packet Type 2
Big Packet
A big packet is 32 bits long and is represented by the following 2-bit patterns in the LSB of the packet:
- 11: Big Packet
Given the input vector of packets is 512 bits long, it can contain up to 32 packets (since each packet is either 16 or 32 bits long).
Interface Requirements
- The 32bit output vectors for big packets and small packets should indicate which packets in the input vector are big and small respectively.
- The output should be valid in the same cycle as the input packet vector is asserted.
- The packets can be in any order in the input vector with the only constraint that the first 16b in the input vector corresponds to the first valid packet
- The interface guarantees that the last 16b of the input vector will never be a valid big packet, such that the big packet doesn't straddles across the boundary of the input vector. However, the last 16b of the input vector can be a valid small packet or the upper 16b of a big packet.
Example
Given the following input vector of packets (pkts_i assuming 128 bits for simplicity):
pkts_i[127:0] = {16'hFEE3, 16'hBEEF, 16'h1234, 16'hDEAD, 16'hC0DF, 16'h5678, 16'h9ABC, 16'hDEF0}
The output vectors for big packets and small packets would be:
big_pkt_o[7:0] = 8'b01001000
small_pkt_o[7:0] = 8'b00100111
Explanation:
- The first packet (16'hDEF0) is a small packet (00 in the LSB[1:0]) and is valid, so small_pkt_o[0] is set to 1.
- The second packet (16'h9ABC) is a small packet (00 in the LSB[1:0]) and is valid, so small_pkt_o[1] is set to 1.
- The third packet (16'h5678) is a small packet (00 in the LSB[1:0]) and is valid, so small_pkt_o[2] is set to 1.
- The fifth packet (16'hC0DF) is a big packet (11 in the LSB[1:0]) and is valid, so big_pkt_o[3] is set to 1.
- The sixth packet (16'hDEAD) is the upper part of a big packet and hence is not a valid packet, so both big_pkt_o[4] and small_pkt_o[4] are set to 0.
- The fourth packet (16'h1234) is a small packet (00 in the LSB[1:0]) and is valid, so small_pkt_o[5] is set to 1.
- The seventh packet (16'hBEEF) is a big packet (11 in the LSB[1:0]) and is valid, so big_pkt_o[6] is set to 1.
- The eighth packet (16'hFEE3) is the upper part of a big packet and hence is not a valid packet, so both big_pkt_o[7] and small_pkt_o[7] are set to 0.Loading the interactive workspace...