# PrismParser: A Framework for Implementing Efficient P4-Programmable Packet Parsers on FPGA
## 3 Proposed P4-Programmable Parser
### Software Overview
#### 3.1.2 P4 Compiled JSON File
Since increasing the frequency is not feasible due to inherent limitations, the focus shifts to doubling the bus size while reusing the base block. The initial step involves employing two base blocks. By increasing the bus size from 64 to 128 bits, the first base block processes the first 64 bits and the second 64 bits by the second base block. However, the second base block cannot complete its calculations without the results from the first base block. Waiting for one clock cycle to obtain the results for the second base block would require processing another packet. If the packet is not stored, it will be dropped; if stored, it necessitates additional logic, memory, and more clock cycles to parse the header. The solution, illustrated in Figure 5, is to modify the second base block to process all possible scenarios from the first block in parallel. This modified block, along with the original base block, runs concurrently. Before the result from the first block is available, the modified second block begins processing the data. The result from the first block drives a multiplexer that selects the appropriate result from the second block. Similarly, the modified base block can be replicated \(x-1\) times to support processing a \((x)\times(64\)-bit) bus size. The parameter \(x\) can be defined before FPGA implementation, thus creating an overlay design, as shown in Figure 6.

Figure 5: Overlay Block: In the multiplexer ID, the first digit indicates the parser block it belongs to, and the second digit indicates the multiplexer number, referred to in the text with a #. The operation of the modified base block is designed to process data in parallel across multiple blocks without waiting for the results from previous blocks, thereby improving throughput and reducing latency. Each new modified block increments the clock by one, simulating that it is working in the next cycle. However, in reality, all blocks work in parallel, and only the output is selected based on the result from the previous block. Multiplexer #0, which handles the control sets and is controlled by the clock number, remains the same across all blocks to ensure that each block receives the correct control signals based on the current clock cycle. Multiplexer #1, also controlled by the clock, selects the proper set of controls by comparing the result bitmap from the previous block (i \(-\) 1) with the possible bitmap combinations for the current block (i). This comparison ensures that the correct control set is selected for the current block based on the outcomes of the previous block. In the base design, Multiplexer #2 was used to select one control set out of multiple \(m\) sets. In the modified design, this multiplexer is discarded. Instead, multiple Protocol Navigator blocks run in parallel, each handling a different control set. This parallel operation eliminates the need to wait for the results from the first block, allowing all possible scenarios to be processed simultaneously. The Prism Controller manages the control signals and ensures that each block operates based on the current clock cycle, sending the appropriate control signals to Multiplexer #0 and Multiplexer #1. Each Protocol Navigator block processes data based on the control signals it receives, with multiple Protocol Navigators running in parallel to handle different control signals. The Bitmap Match unit compares the current bitmap with possible outcomes to select the appropriate data for processing, ensuring that the correct path is followed based on the previous block's results. This design removes the need to wait for a clock cycle to obtain the result from the first block, significantly reducing latency and increasing throughput. Figure 5 also illustrates how blocks from 0 to \(m-1\) in Protocol Navigator blocks operate in parallel within the modified base block, resulting in a more efficient and faster processing pipeline. The performance of different overlay sizes was evaluated by varying the parameter \(x\).