Reconfigurable hardware firewall

Abstract

A reconfigurable hardware firewall system for network packet classification implements a two-level architecture on a programmable logic device. The system includes a physical interface circuit for receiving and transmitting network packets, and a master packet dealer circuit that separates incoming packets into headers and payloads, generates tag identifiers, and stores payloads in a packet reference table. A first-level classification circuit uses a probabilistic data structure, such as a Bloom filter with a bit array and a hash function, to perform constant-time membership testing of packet headers against firewall rules. Headers indicating potential matches are forwarded to an integrated processing core that performs second-level verification to distinguish true matches from false positives. Safe packets are reassembled and transmitted, while matched packets are discarded. The architecture enables high-throughput packet filtering with dynamic rule reconfiguration capability.

Description

RECONFIGURABLE HARDWARE FIREWALLCROSS REFERENCE

[0001] This application claims the benefit of an Indian provisional patent application filed on February 18, 2025, in the Indian Patent Office and assigned an application number 202541013644, titled " RECONFIGURABLE HARDWARE FIREWALL," which is hereby incorporated by reference in its entirety.FIELD

[0002] Various embodiments of the disclosure relate to a reconfigurable hardware firewall. More specifically, the present disclosure relates to network security systems, particularly to a reconfigurable hardware firewall that implements probabilistic data structures for fast packet classification and dynamic rule updates.BACKGROUND

[0003] Network security is a critical concern in today's interconnected digital landscape. As the volume and complexity of network traffic continue to grow, traditional software-based firewalls struggle to keep pace with the increasing demands for high-speed packet processing and real-time threat detection. These software firewalls, which rely on general -purpose CPUs to inspect and filter network packets, often become bottlenecks in high-speed network environments, leading to increased latency and reduced overall network performance. Existing hardware-based firewalls address the performance limitations of software solutions by offloading packet filtering to specialized hardware components.However, existing hardware firewalls are basically isolated processor systems with a specialized OS. They are prone to software vulnerabilities and lack speed. Further, existing hardware accelerators for the hardware firewalls lack flexibility and scalability.

[0004] Furthermore, current firewall systems often struggle to efficiently manage large rule sets without compromising performance. As the number of security rules grows, the time required to match incoming packets against these rules increases, leading to longer processing times and reduced throughput. This scalability issue becomes challenging in enterprise and data center environments where thousands of rules may need to be evaluatedfor each packet. Another significant challenge in existing firewall systems is the trade-off between speed and accuracy in packet classification. Fast packet processing often comes at the cost of reduced rule-matching granularity, potentially leading to false positives or negatives. Conversely, more accurate classification methods tend to be computationally intensive, resulting in increased latency and reduced overall system performance. The dynamic nature of modern network threats also poses a significant challenge to current firewall architectures. Many existing solutions cannot quickly and efficiently update their rule sets in response to new security threats or changing network conditions. This limitation leaves networks vulnerable to emerging attacks and reduces the overall effectiveness of the security infrastructure.

[0005] These challenges highlight the need for a firewall system, framework, or architecture that may integrate the speed and efficiency of hardware-based solutions with the flexibility and adaptability of software-based approaches. Such a solution would need to address scalability issues associated with large rule sets, support rapid rule updates, and maintain high performance across a wide range of network speeds and traffic patterns.

[0006] The limitations and disadvantages of conventional and traditional approaches will become apparent to one of skill in the art through the comparison of the described systems with some aspects of the present disclosure, as set forth in the remainder of the present application and with reference to the drawings.SUMMARY

[0007] A system, a device, and an apparatus described in the subject specification may implement the steps of a method described. In an embodiment, the system and method are provided for a reconfigurable hardware firewall system for network packet classification. The terms reconfigurable hardware firewall system, " " system, reconfigurable hardware firewall architecture, etc., may be used interchangeably in the subject specification and correspond to the reconfigurable hardware firewall system.

[0008] In an embodiment, the system and method provide a programmable logic device that implements network packet classification through hardware-based circuits. The programmable logic device serves as the foundational platform for packet processing, classification, and forwarding operations. This implementation on programmable logicenables real-time packet processing with deterministic timing characteristics while maintaining the flexibility to update classification rules without hardware replacement.

[0009] In an embodiment, the system and method provide a physical interface circuit configured to receive network packets from a first network and transmit network packets to a second network. The physical interface circuit operates at the boundary between the network physical layer and the packet classification system, enabling bidirectional data flow between connected networks. Data reception and transmission occur through standardized interface protocols that allow the firewall to be deployed in-line between network segments without introducing protocol incompatibilities.

[0010] In an embodiment, the system and method provide a master packet dealer circuit communicatively coupled to the physical interface circuit. The master packet dealer circuit receives network packets from the physical interface circuit and performs packet decomposition operations. The circuit separates network packets into packet headers and packet payloads, enabling independent processing paths for classification operations and payload storage. The master packet dealer circuit generates tag identifiers for network packets, each serving as a reference pointer that associates a packet header with its corresponding payload throughout the classification pipeline.

[0011] In an embodiment, the system and method provide storage of packet payloads in a packet reference table indexed by tag identifiers. The packet reference table maintains payload data in on-chip memory while classification operations are performed on the corresponding headers. This separation of header processing from payload storage enables parallel operations, allowing classification to proceed on incoming packet headers while payloads from previously classified packets are retrieved for transmission.

[0012] In an embodiment, the system and method provide a first-level classification circuit comprising a probabilistic data structure configured to perform constant-time membership testing. The probabilistic data structure receives packet headers and determines whether they match rules in a set. The constant-time membership testing characteristic ensures that classification latency remains bounded regardless of the number of rules encoded in the data structure. The first-level classification circuit generates a classification output indicating a potential match or no match, where a potential match indicates that the packet header may correspond to a rule requiring action.

[0013] In an embodiment, the system and method provide a processing core configured to receive packet headers corresponding to potential matches indicated by thefirst-level classification circuit. The processing core performs second-level verification of packet headers against the rules and generates a verification result indicating whether the packet header matches a true positive or a false positive. This two-level verification architecture enables the system to combine the speed of probabilistic filtering with the accuracy of deterministic rule matching.

[0014] In an embodiment, the system and method provide packet handling based on classification results through the master packet dealer circuit. When the first-level classification circuit indicates no match, the master packet dealer circuit retrieves packet payloads from the packet reference table and forwards reassembled network packets to the physical interface circuit for transmission. When the processing core indicates a false positive, the master packet dealer circuit retrieves packet payloads from the packet reference table and forwards reassembled network packets to the physical interface circuit for transmission. When the processing core indicates a true match, the master packet dealer circuit discards network packets by invalidating corresponding entries in the packet reference table.

[0015] In an embodiment, the system and method provide a probabilistic data structure comprising a Bloom filter. The Bloom filter comprises a bit array stored in on-chip memory and hash function modules configured to compute hash indices from packet headers. The first-level classification circuit reads bit values from the bit array at positions determined by the hash indices and generates a classification output indicating a potential match when all read bit values equal a predetermined value. This implementation enables membership testing in constant time with memory requirements that are independent of the size of individual rules.

[0016] In an embodiment, the system and method provide a synchronization buffer configured to transfer data between the first-level classification circuit operating at a first clock frequency and the processing core operating at a second clock frequency. The synchronization buffer comprises a dual-port memory structure and Gray code counters configured to synchronize read and write pointers across asynchronous clock domains to prevent metastability. The first clock frequency is higher than the second, enabling the first-level classification circuit to process packets at a higher throughput than the processing core while maintaining data integrity across clock-domain boundaries.

[0017] In an embodiment, the system and method provide hash function modules that implement a Jenkins lookup3 hash mechanism. The hash function modules are configuredbased on the size of the bit array and the number of rules in the rule set. The Jenkins lookups hash mechanism exhibits favorable avalanche characteristics and low collision rates, making it suitable for hardware implementation with minimal resource consumption.

[0018] In an embodiment, the system and method provide a physical interface circuit comprising a receive synchronization FIFO configured to perform clock-domain crossing between a PHY receive clock domain and a firewall clock domain, and a transmit synchronization FIFO configured to perform clock-domain crossing between the firewall clock domain and a PHY transmit clock domain. These synchronization structures enable the firewall to interface with physical-layer devices operating at frequencies different from those of the internal classification logic.

[0019] In an embodiment, the system and method provides a packet reference table comprising on-chip memory where each entry comprises a valid bit indicating whether the entry contains valid packet data, a frame buffer configured to store packet payload bytes, a received byte counter tracking a number of bytes received, a transmitted byte counter tracking a number of bytes transmitted, and a frame completion indicator indicating whether an entire packet payload has been received. This entry structure enables precise tracking of packet state throughout the classification and forwarding process.

[0020] In an embodiment, the system and method provide a to-send FIFO configured to queue tag identifiers for network packets determined to be safe, and a to-invalidate FIFO configured to queue tag identifiers for network packets determined to be unsafe. The master packet dealer circuit retrieves tag identifiers from the to-send FIFO to initiate packet transmission and retrieves tag identifiers from the to-invalidate FIFO to invalidate corresponding packet reference table entries. This FIFO-based queuing mechanism decouples classification decisions from packet handling operations.

[0021] In an embodiment, the system and method provide a processing core comprising a RISC-V processor configured to perform second-level verification by implementing a trie-based search mechanism. The time complexity of the trie-based search mechanism is independent of the number of rules in the rule set, and instead proportional to the number of bits in the packet header fields being matched. This characteristic ensures that verification latency remains bounded as the rule sets scale.

[0022] In an embodiment, the system and method provide the master packet dealer circuit configured to extract packet header fields from network packets while concurrently storing packet payload bytes in the packet reference table. The master packet dealer circuitasserts a force-stop signal to the physical interface circuit when no free entries are available in the packet reference table or when network packets being received are determined to be unsafe. This concurrent operation and flow-control mechanism enables on-the-fly packet processing with minimal buffering requirements.

[0023] In an embodiment, the system and method provide dynamic reconfiguration capability, in which the processing core is further configured to dynamically reconfigure the first-level classification circuit by updating the probabilistic data structure based on a modified set of rules when processing of network packets is suspended. This reconfiguration capability enables rule updates without requiring hardware replacement or extended service interruptions.

[0024] In an embodiment, the system and method provide a method for classifying network packets in a reconfigurable hardware firewall. The method comprises receiving network packets from a first network by a physical interface circuit implemented on a programmable logic device. Network packets are separated into packet headers and packet payloads by a master packet dealer circuit. Tag identifiers corresponding to network packets are generated by the master packet dealer circuit. Packet payloads are stored in packet reference table entries indexed by tag identifiers.

[0025] In an embodiment, the system and method provide constant-time membership testing performed by a first-level classification circuit that uses a probabilistic data structure over packet headers to determine whether the packet headers match rules in a set of rules. The constant-time membership testing comprises computing hash indices from packet headers by hash function modules, reading bit values from a bit array stored in on-chip memory at positions corresponding to the computed hash indices, and determining a potential match when all read bit values equal a predetermined value.

[0026] In an embodiment, the system and method provide packet handling based on first-level classification results. When determining that there is no potential match, the method comprises retrieving packet payloads from the packet reference table, reassembling network packets, and transmitting the reassembled network packets to a second network. When determining a potential match, the method comprises transferring packet headers to a processing core and performing second-level verification of packet headers using rules to determine whether a true match exists.

[0027] In an embodiment, the system and method provide packet handling based on second-level verification results. When determining that no true match exists, packetpayloads are retrieved, network packets are reassembled, and reassembled network packets are transmitted to the second network. When determining that a true match exists, network packets are discarded by invalidating packet reference table entries.

[0028] In an embodiment, the system and method provide for transferring packet headers to the processing core through a synchronization buffer. The transfer comprises queuing packet headers and tag identifiers in a synchronization buffer, including a dual-port memory structure and synchronizing read and write pointers of the synchronization buffer using Gray code encoding to prevent metastability during clock domain crossing between a first clock domain of the first-level classification circuit and a second clock domain of the processing core.

[0029] In an embodiment, the system and method provide second-level verification comprising traversing a trie data structure using bits of the packet header, comparing packet headers with rule patterns encoded in the trie data structure, and determining a match when a traversal path reaches a terminal node corresponding to a complete rule. The trie-based traversal ensures verification time is bounded by the header bit length rather than the rule count.

[0030] In an embodiment, the system and method monitor the availability of entries in the packet reference table and, when no free entries are available, discard network packets at the physical interface circuit until an entry becomes available. This flow-control mechanism prevents buffer overflow while maintaining system stability under high traffic.

[0031] In an embodiment, the system and method provide dynamic reconfiguration of the first-level classification circuit by suspending reception of network packets at the physical interface circuit, updating the probabilistic data structure based on a modified set of rules, and resuming reception of network packets at the physical interface circuit. This reconfiguration sequence ensures rule consistency between the first-level and second-level classification stages.

[0032] In an embodiment, the system and method provide packet headers that include a protocol field, a source address field, a destination address field, a source port field, and a destination port field based on IPv4 packet format specifications. These header fields enable classification based on standard network addressing and transport layer port information.

[0033] In an embodiment, the system and method provide for storing packet payloads by writing payload bytes to packet reference table entries as they are received from the physical interface circuit and setting a frame completion indicator upon receiving the finalbyte of a network packet. The storing occurs concurrently with constant-time membership testing performed by the first-level classification circuit, enabling pipelined operation that minimizes end-to-end latency.

[0034] In an embodiment, the system and method provide a network packet classification apparatus comprising a programmable logic device configured to implement a physical interface circuit, a master packet dealer circuit, a first-level classification circuit, a processing core, and a packet forwarding mechanism. The physical interface circuit receives network packets from a first network. The master packet dealer circuit separates network packets into packet headers and packet payloads, generates tag identifiers for network packets, and stores packet payloads in packet reference table entries indexed by tag identifiers. The first-level classification circuit, which comprises a probabilistic data structure, performs constant-time membership testing on packet headers to determine whether they match rules in a rule set. The processing core receives packet headers, and when the first-level classification circuit determines a potential match, it performs second-level verification of packet headers using rules, determines whether a true match exists, and generates a verification result.

[0035] In an embodiment, the system and method provide a packet forwarding mechanism configured to retrieve packet payloads from the packet reference table and transmit reassembled network packets to a second network when the first-level classification circuit determines that no potential match exists. The packet forwarding mechanism retrieves packet payloads from the packet reference table and transmits reassembled network packets to the second network when the processing core determines no true match exists. The packet forwarding mechanism discards network packets by invalidating packet reference table entries when the processing core determines a true match exists. This forwarding mechanism implements the complete packet disposition logic based on classification outcomes from both verification levels.

[0036] The reconfigurable hardware firewall system achieves high-throughput packet classification by combining constant-time probabilistic first-level filtering implemented in hardware with deterministic second-level verification implemented in a processing core. Separating packet headers from payloads during classification enables concurrent processing and minimizes latency. The synchronization mechanisms employing Gray code counters and dual-port memory structures enable reliable data transfer across asynchronous clock domains. The trie-based second-level verification provides rule matching with time complexityindependent of rule count. The dynamic reconfiguration capability enables rule updates while maintaining system availability.BRIEF DESCRIPTION OF THE DRAWINGS

[0037] FIG. 1 illustrates an environment including a reconfigurable hardware firewall system for network packet classification, according to an exemplary embodiment.

[0038] FIG. 2 illustrates a deployment of the reconfigurable hardware firewall system, according to an exemplary embodiment.

[0039] FIG. 3 A and FIG. 3B illustrates a flow diagram showing a sequence of operations executed by the reconfigurable hardware firewall system, according to an exemplary embodiment.

[0040] FIG. 4A and FIG. 4B illustrates the PRT architecture, according to an exemplary embodiment.

[0041] FIG. 5 illustrates the reconfigurable hardware firewall architecture, according to an exemplary embodiment.

[0042] FIG. 6A and FIG. 6B illustrates the master packet dealer architecture, according to an exemplary embodiment.

[0043] FIG. 7 illustrates an Ethernet IP architecture receive path, according to an exemplary embodiment.

[0044] FIG. 8 illustrates a transmit path architecture for a physical interface circuit, according to an exemplary embodiment.

[0045] FIG. 9 illustrates a waveform diagram showing test bench results, according to an exemplary embodiment.

[0046] FIG. 10 illustrates a synchronization FIFO architecture, according to an exemplary embodiment.

[0047] FIG. 11 illustrates a second-level verification mechanism implemented using the trie data structure for packet header classification, according to an exemplary embodiment.

[0048] FIG. 12 illustrates a performance graph showing output throughput characteristics of the reconfigurable hardware firewall system, according to an exemplary embodiment.

[0049] FIG. 13 A and FIG. 13B illustrates a flow diagram for classifying network packets in the reconfigurable hardware firewall system, according to an exemplary embodiment.

[0050] FIG. 14 illustrates an exemplary hardware configuration of a special-purpose computer that may be used to implement components and embodiments of the reconfigurable hardware firewall system, according to exemplary embodiments.DETAILED DESCRIPTION

[0051] The following description sets forth exemplary aspects of the present disclosure. It should be recognized, however, that such a description is not intended as a limitation on the scope of the present disclosure. Rather, the description also includes combinations and modifications to those exemplary aspects described herein.

[0052] As used herein, the term "circuit" refers to a hardware component, a software component, or a combination thereof configured to perform the functions described. A circuit may be implemented using one or more processors, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), programmable logic devices, discrete logic components, or any combination thereof. Similarly, the terms "system," "apparatus," and "device" may be used interchangeably throughout this disclosure to refer to the reconfigurable hardware firewall and its constituent components, whether implemented in hardware, software, firmware, or combinations thereof. A "programmable logic device" includes FPGAs, complex programmable logic devices (CPLDs), and any integrated circuit configurable after manufacturing using hardware description languages such as Verilog, VHDL, or Bluespec SystemVerilog.

[0053] As used herein, the term "configured to" indicates that a circuit, component, or system includes the necessary hardware, software, firmware, or combination thereof to perform the specified operation or function. When a component is described as "configured to" operate, it implements that operation through its structural arrangement, programmed instructions, components, sub-components, modules, engines, and a combination thereof. The methods, mechanisms, and flow diagrams described herein may be implemented and / or performed by any of the systems, apparatuses, or devices described, and the system claims the structural components configured to execute the corresponding method steps.

[0054] The circuits described herein may operate synchronously within a single clock domain or asynchronously across multiple clock domains, with appropriate synchronization mechanisms used to ensure reliable data transfer. Circuit boundaries described are illustrative and may be combined, divided, or reorganized in alternative implementations without departing from the scope of the present disclosure.

[0055] In the context of this disclosure, the following definitions apply:

[0056] Network firewall: A security system that monitors and controls incoming and outgoing network traffic based on predetermined security rules.

[0057] Packet: A unit of data transmitted over a network, typically containing both header information and payload data.

[0058] Header: The portion of a packet containing metadata such as source and destination addresses, protocol information, and other control data.

[0059] Payload: The actual data being transmitted within a packet, excluding the header information.

[0060] Bloom filter: A space-efficient probabilistic data structure used to evaluate whether an element is a member of a set.

[0061] False positive: In the context of Bloom filters, an error where the filter incorrectly indicates that an element is in the set when it is not.

[0062] False negative: An error where a test result incorrectly indicates that a condition is absent when it is present. Bloom filters do not produce false negatives.

[0063] Hardware- software codesign: An approach to system design that considers both hardware and software components simultaneously to optimize overall system performance.

[0064] Field-Programmable Gate Array (FPGA): An integrated circuit designed to be configured by a customer or a designer after manufacturing.

[0065] System-on-Chip (SoC): An integrated circuit that integrates all or most components of a computer or other electronic system into a single chip.

[0066] Throughput: The amount of data processed in a given amount of time.

[0067] Latency: The time delay between the initiation of a process and its completion.

[0068] Dynamic reconfiguration: The ability to modify the functionality or structure of a system while it is operating without requiring a restart.

[0069] Probabilistic data structure: A data structure that uses probability theory to achieve space efficiency at the cost of a small probability of error.

[0070] Constant-time operation: An operation whose time complexity does not depend on the size of the input data.

[0071] In an embodiment, the terms "frame" and "packet" may be used interchangeably in this disclosure when referring to units of data transmitted over a network.

[0072] The terms "first-level classification" and "hardware-based classification" may be used interchangeably to refer to the initial packet screening performed by the firewall's hardware components.

[0073] Similarly, "second-level verification" and "software-based verification" may be used interchangeably to describe the more detailed packet analysis performed by the system's software components.

[0074] Throughout this disclosure, these terms will be used consistently, as defined above, to ensure clarity and precision in describing the reconfigurable hardware firewall system.

[0075] FIG. 1 illustrates an environment 100 including a reconfigurable hardware firewall system for network packet classification, according to an exemplary embodiment. In an embodiment, FIG. 1 shows an environment 100 including a reconfigurable hardware firewall system that includes a first network physical layer 102 A, a second network physical layer 102B, a master packet dealer (MPD) 104, a probabilistic data structure 106, and a processing core 108. The master packet dealer 104 comprises FIFO buffers 104A and a packet reference table 104B. The processing core 108 may be operable to implement a second level verification module 108 A and a firewall rules update module 108B.

[0076] The first network physical layer 102 A and the second network physical layer 102B may be implemented as physical interface circuits (e.g., physical layer 1 and physical layer 2 corresponding to network 1 and network 2) configured to interface with respective network segments. The first network physical layer 102A may be configured or operable to receive multiple network packets from a first network and transmit data to the master packet dealer 104. The second network physical layer 102B may be configured to receive data from the master packet dealer 104 and transmit the network packets to a second network. In one embodiment, the first network physical layer 102 A and the second network physical layer 102B may comprise receive synchronization FIFOs configured to perform clock domain crossing between a PHY receive clock domain and a firewall clock domain, and transmit synchronization FIFOs configured to perform clock domain crossing between the firewall clock domain and a PHY transmit clock domain.

[0077] The master packet dealer 104 may be communicatively coupled to the first network physical layer 102 A and the second network physical layer 102B. The master packet dealer 104 may be configured to receive the network packets from the first network physical layer 102 A, separate one or more network packets from the received network packets into one or more packet headers and one or more packet payloads, generate one or more tag identifiers for the one or more network packets, and store the one or more packet payloads in the packet reference table 104B indexed by the one or more tag identifiers. The master packet dealer 104 may be further configured to extract multiple packet header fields from the network packets received while concurrently storing packet payload bytes in the packet reference table 104B. The master packet dealer 104 may be configured to assert a force-stop signal to the first network physical layer 102A when no free entries may be available in the packet reference table 104B or when the network packets being received may be determined to be unsafe.

[0078] The FIFO buffers 104A may comprise an input first-in-first-out (FIFO), a to-send FIFO, and a to-invalidate FIFO. The input FIFO may be configured to queue the packet headers and tag identifiers for processing by the probabilistic data structure 106. The to-send FIFO may be configured to queue one or more tag identifiers for network packets determined to be safe. The to-invalidate FIFO may be configured to queue tag identifiers for network packets determined to be unsafe. The master packet dealer 104 may retrieve the tag identifiers from the to-send FIFO to initiate packet transmission and may retrieve the tag identifiers from the to-invalidate FIFO to invalidate corresponding packet reference table entries.

[0079] The packet reference table 104B may comprise on-chip memory and may be configured to store packet payloads indexed by tag identifiers. Each entry in the packet reference table 104B may comprise a valid bit indicating whether the entry contains valid packet data, a frame buffer configured to store packet payload bytes, a received byte counter tracking a number of bytes received, a transmitted byte counter tracking a number of bytes transmitted, and a frame completion indicator indicating whether an entire packet payload has been received.

[0080] The probabilistic data structure 106 may be implemented as a first-level classification circuit configured to perform constant-time membership testing on the packet headers. The probabilistic data structure 106 may be configured to receive the packet headers from the FIFO buffers 104 A, determine whether the packet headers match rules frommultiple rules, and generate a classification output indicating a potential match or no match. In one embodiment, the probabilistic data structure 106 may comprise, for example, a Bloom filter having a bit array stored in on-chip memory and multiple hash function modules configured to compute hash indices from packet headers. The probabilistic data structure 106 may be configured to read bit values from the bit array at positions determined by the hash indices and generate the classification output indicating a potential match when all read bit values equal a predetermined value. In another embodiment, the hash function modules may implement a Jenkins lookup3 hash mechanism, and the plurality of hash function modules may be configured based on the size of the bit array and the number of rules in the plurality of rules.

[0081] The processing core 108 may execute operations to receive the packet headers corresponding to those identified as potential matches by the probabilistic data structure 106. The second-level verification module 108 A may be configured to verify the packet headers using multiple rules and to generate a verification result indicating whether the packet headers match a true positive or a false positive. In one embodiment, the processing core 108 may comprise a RISC-V processor configured to perform the second-level verification by implementing a trie-based search mechanism. The time complexity of the trie-based search mechanism may be independent of the number of rules in the plurality of rules. The firewall rules update module 108B may be configured to dynamically reconfigure the probabilistic data structure 106 by updating the probabilistic data structure based on a modified plurality of rules when processing network packets may be suspended.

[0082] A synchronization buffer may be configured to transfer data between the probabilistic data structure 106 operating at a first clock frequency and the processing core 108 operating at a second clock frequency. The synchronization buffer may comprise a dualport memory structure and Gray code counters configured to synchronize read and write pointers across asynchronous clock domains to prevent metastability. The first clock frequency may be higher than the second clock frequency, enabling the probabilistic data structure 106 to process packets at a higher throughput than the processing core 108.

[0083] FIG. 2 illustrates a deployment 200 of the reconfigurable hardware firewall system, according to an exemplary embodiment. FIG. 2, described in conjunction with FIG.1, shows a deployment 200 of the reconfigurable hardware firewall between two network segments. FIG. 2 shows the detailed implementation of the network packet classification apparatus on a programmable logic device. In an embodiment, the reconfigurable hardwarefirewall system comprises a first network interface, for example, Ethernet 1 202A, communicatively coupled to a first physical layer 102 A, and a second network interface, for example, Ethernet 2202B, communicatively coupled to a second physical layer 102B. An input port 204 configured to receive network packets from the first network, an output port 206 configured to transmit network packets to the second network, a hardware firewall 208 implementing a first-level classification circuit, a master packet dealer 104 with an integrated packet reference table 104B, an arbiter 218, a SoC 212 implementing a processing core for second-level verification, and a firewall configuration interface 210 providing pathways for updating firewall rules. The reconfigurable hardware firewall system includes data pathways 214 and 216, facilitating communication between the hardware firewall 208 and the SoC 212.

[0084] The first network interface, Ethernet 1 202A, and the second network interface, Ethernet 2202B, may be implemented as physical interface circuits operable to interface with physical layer components 102A and 102B, respectively. The Ethernet interfaces 202A and 202B may support the media-independent interface (Mil) or reduced-gigabit mediaindependent interface (RGMII) standards, operating at 10 Mbps, 100 Mbps, or 1000 Mbps line rates. The physical interface circuits Ethernet 1 202A and Ethernet 2202B may include receive synchronization FIFO structures operable to perform clock-domain crossing between a PHY receive clock domain and a firewall clock domain, and transmit synchronization FIFO structures configured to perform clock-domain crossing between the firewall clock domain and a PHY transmit clock domain. The synchronization FIFO structures may be implemented using dual-port Block RAM (BRAM) with Gray code counters for read and write pointer synchronization to prevent metastability during clock domain crossing operations.

[0085] The input port 204 receives network packets from the first network via Ethernet 1 202 A and directs the received network packets to the master packet dealer 104 for processing. The output port 206 transmits processed network packets to the second network via Ethernet 2202B after the packets have been classified and deemed safe for transmission. The bidirectional nature of the system 200 allows network packets received from either network segment to be processed through the firewall classification pipeline.

[0086] The master packet dealer 104 may be implemented as a master packet dealer circuit communicatively coupled to the physical interface circuits Ethernet 1 202A and Ethernet 2202B. The master packet dealer 104 receives network packets from the input port 204 and separates each network packet into a packet header and a packet payload. The master packet dealer 104 generates a tag identifier for each network packet, where the tag identifiermay be implemented as a 2 -bit value in embodiments supporting up to four concurrent packet entries. The packet reference table 104B, integrated within the master packet dealer 104, stores packet payloads indexed by the tag identifiers. Each entry in the packet reference table 104B comprises a valid bit indicating whether the entry contains valid packet data, a frame buffer configured to store packet payload bytes with a configurable maximum size corresponding to the maximum transmission unit (MTU) of 1500 bytes, a received byte counter tracking the number of bytes received, a transmitted byte counter tracking the number of bytes transmitted, and a frame completion indicator indicating whether the entire packet payload has been received.

[0087] The master packet dealer 104 extracts packet header fields from network packets while concurrently storing packet payload bytes in the packet reference table 104B. The packet header fields may include a protocol field, a source address field, a destination address field, a source port field, and a destination port field, as specified in the IPv4 packet format. The extracted header together with the tag identifier forms a combined header and tag data unit that may be pushed to an input FIFO buffer within FIFO buffers 104A shown in FIG. 1. The combined header and tag data unit may comprise 107 bits including 13 bytes for the header fields, 2 bits for the packet reference table slot tag, and 1 bit for an Ethernet port tag indicating which Ethernet port to transmit the packet through.

[0088] The hardware firewall 208 implements a first-level classification circuit comprising a probabilistic data structure configured to perform constant-time membership testing on packet headers. The probabilistic data structure may include, for example, a Bloom filter with a bit array stored in on-chip BRAM and hash function modules operable to compute hash indices from packet headers. The bit array size may be configurable from 1 bit to 32768 bits, depending on the number of rules and available lookup table (LUT) resources on the programmable logic device. The hash function modules may implement a Jenkins lookup3 hash mechanism, where the number of hash function modules k is configured according to the formula:

[0090] where ‘m’ represents the number of bits in the bit array, and ‘n’ represents the number of rules. Each hash function module may require 296 LUTs and 352 flip-flops for implementation.

[0091] The hardware firewall 208 receives the combined header and tag data unit from the master packet dealer 104, dequeues the header and tag from the input FIFO, and feeds thepacket header into the Bloom filter for first-level classification. The hash function modules compute hash indices from the packet header, and the hardware firewall 208 reads bit values from the bit array at positions determined by the computed hash indices. The hardware firewall 208 generates a classification output indicating a potential match when all read bit values equal a predetermined value of 1, or generates a classification output indicating no match when at least one read bit value equals 0.

[0092] The data pathway 214 carries packet headers and tag identifiers from the hardware firewall 208 to the SoC 212 when the first-level classification indicates a potential match. The data pathway 216 carries verification results from the SoC 212 back to the hardware firewall 208 and the master packet dealer 104. The data pathways 214 and 216 may be implemented through a synchronization buffer designated as a CPU buffer, configured to transfer data between the hardware firewall 208 operating at a first clock frequency and the SoC 212 operating at a second clock frequency. The synchronization buffer includes a dualport memory structure implemented, for example, as a BRAM-based synchronization FIFO with a depth of 4 entries, matching the number of packet reference table entries. Gray code counters synchronize read and write pointers across asynchronous clock domains to prevent metastability. The hardware firewall 208 may employ a clock frequency of 50 MHz or higher, enabling it to process packets at a higher throughput than the SoC 212.

[0093] The SoC 212 implements a processing core configured to receive packet headers corresponding to packets identified as potential matches by the hardware firewall 208, perform second-level verification of the packet headers against firewall rules, and generate a verification result indicating whether the packet header corresponds to a true match or a false positive. The SoC 212 may comprise a RISC-V processor, such as the SoC 64-bit core, configured to perform second-level verification by implementing a trie-based search mechanism. The time complexity of the trie-based search mechanism may be independent of the number of rules since the traversal depth depends on the number of bits in the packet header rather than the number of rules in the rule set. The SoC 212 communicates with the hardware firewall 208 via an AXI-Lite interface.

[0094] The arbiter 218 manages data flow between the hardware firewall 208, the master packet dealer 104, and the output port 206. The arbiter 218 directs packet headers classified as safe by the hardware firewall 208 to a to-send FIFO configured to queue tag identifiers corresponding to network packets determined to be safe. The arbiter 218 directs packet headers classified as unsafe following second-level verification to a to-invalidateFIFO configured to queue tag identifiers corresponding to network packets determined to be unsafe. The master packet dealer 104 retrieves tag identifiers from the to-send FIFO to initiate packet transmission by retrieving packet payloads from the packet reference table 104B, reassembling network packets, and forwarding the reassembled network packets to the output port 206 for transmission via Ethernet 2202B. The master packet dealer 104 retrieves tag identifiers from the to-invalidate FIFO to invalidate corresponding packet reference table 104B entries by clearing the valid bit.

[0095] The firewall configuration interface 210 provides a pathway for the SoC 212 to dynamically reconfigure the hardware firewall 208 by updating the probabilistic data structure based on a modified set of rules. The reconfiguration process may be initiated by the SoC 212 through a serial interface. During reconfiguration, the SoC 212 disables the packet reception on the Ethernet interfaces 202A and 202B, updates the Bloom filter bit array, and resumes packet reception after the update completes. The Bloom filter may require complete rebuilding when rules are modified, since incremental rule addition may not be supported without rebuilding the bit array.

[0096] The master packet dealer 104 may be configured to assert a force-stop signal to the physical interface circuits Ethernet 1 202A and Ethernet 2202B when no free entries are available in the packet reference table 104B or when network packets being received are determined to be unsafe. The force-stop mechanism automatically clears the frame buffer once the current frame has been fully received from the PHY layer, allowing the system to prepare for the next incoming frame without requiring the master packet dealer 104 to read or clear the buffer contents.

[0097] In operation, network packets arrive at the system 200 through the first network segment via physical layer 102 A and Ethernet 1 202 A. The input port 204 receives the network packets and forwards them to the master packet dealer 104. The master packet dealer 104 separates each network packet into a packet header and a packet payload as packet bytes are received byte-by-byte from the Ethernet interface. The master packet dealer 104 generates a tag identifier for each packet and stores the packet payload in the packet reference table 104B at an entry indexed by the tag identifier. The valid bit for the entry is set to true, and as payload bytes are received, the received byte counter increments. Upon receiving the final byte of the network packet, the frame completion indicator is set to true.

[0098] Concurrently with the payload storage, the master packet dealer 104 extracts header fields and pushes the combined header and tag to the input FIFO once the completeheader has been received from the physical interface. The hardware firewall 208 dequeues the header and tag from the input FIFO and performs constant-time membership testing using the Bloom filter. The hash function modules compute hash indices from the header fields, and the hardware firewall 208 reads corresponding bit positions from the bit array.

[0099] When all bit values equal 1, the hardware firewall 208 determines a potential match and forwards the header and tag through data pathway 214 to the CPU buffer for second-level verification. The SoC 212 retrieves the header and tag from the CPU buffer, traverses the trie data structure using bits of the packet header, compares the header with rule patterns encoded in the trie structure, and determines a match when the traversal path reaches a terminal node corresponding to a complete rule. The SoC 212 writes the verification result back to the CPU buffer.

[0100] When the SoC 212 determines a true match exists, the arbiter 218 directs the tag to the to-invalidate FIFO, and the master packet dealer 104 invalidates the corresponding entry in the packet reference table 104B by clearing the valid bit, thereby discarding the network packet. When the SoC 212 determines the potential match was a false positive, the arbiter 218 directs the tag to the to-send FIFO for transmission.

[0101] When the hardware firewall 208 determines that no potential match exists at the first level, indicating that the packet is safe, the tag is forwarded directly to the to-send FIFO without requiring second-level verification. The master packet dealer 104 retrieves the tag from the to-send FIFO when the physical interface indicates it is ready to transmit a new frame. The master packet dealer 104 retrieves payload bytes from the packet reference table 104B entry indexed by the tag and forwards the reassembled network packet to the output port 206 byte-by-byte. The output port 206 transmits the packet via Ethernet 2202B to the physical layer 102B, and onward to the second network. Once all payload bytes have been transmitted and the transmitted byte counter equals the received byte counter, the packet reference table 104B entry is invalidated by clearing the valid bit, making the entry available for subsequent packets.

[0102] FIG. 3A and FIG. 3B illustrates a flow diagram 300 showing a sequence of operations executed by the reconfigurable hardware firewall system, according to an exemplary embodiment. FIG. 3 A and FIG. 3B are described in conjunction with FIG. 1 and FIG. 2. In an embodiment, the flow diagram 300 described in FIG. 3A and FIG. 3B shows the data path from packet reception to classification and the transmission or discarding ofnetwork packets based on the sequence of operations executed by the reconfigurable hardware firewall system.

[0103] FIG. 3 A shows the initial reception and first-level classification stages of the packet processing. A receive packet at PHY-IP block 302 may represent the entry point for network packets arriving from a first network via the physical interface circuit. The physical interface circuit 102 A receives incoming network packets and initiates the processing sequence. A store in frame buffer RX block 304 follows the reception block 302, where received packet data may be temporarily held in a receive-side frame buffer within the physical interface circuit 102 A. The frame buffer RX operates as described in connection with FIG. 8 to handle clock-domain crossings between the PHY receive clock domain and the firewall clock domain via synchronization FIFO structures.

[0104] An MPD splits the header and payload block 306 depicts the function performed by the master packet dealer circuit 104. The master packet dealer circuit 104 receives incoming packet bytes from the physical interface circuit 102 A and separates network packet data into packet headers containing protocol fields, source address fields, destination address fields, source port fields, and destination port fields, along with packet payloads containing the remaining packet data. The separation occurs as bytes are received, with header fields extracted during the initial portion of packet reception while the payload continues to arrive.

[0105] A store payload in PRT with tag block 308 represents the storage operation performed by the master packet dealer circuit 104 in coordination with the packet reference table 104B. The master packet dealer circuit 104 generates a tag identifier for the network packet and stores packet payload bytes in the packet reference table 104B at an entry indexed by the generated tag identifier. The tag identifier may be a 2 -bit value when the packet reference table 104B contains between 2 and 4 entries. Each entry in the packet reference table 104B includes a valid bit indicating whether the entry contains valid packet data, a frame buffer configured to store packet payload bytes, a received byte counter tracking a number of bytes received, a transmitted byte counter tracking a number of bytes transmitted, and a frame completion indicator indicating whether an entire packet payload has been received. The storage of payload bytes in the packet reference table 104B occurs concurrently with header extraction, enabling on-the-line packet processing without unnecessary buffering delays.

[0106] A push header plus tag to input FIFO block 310 depicts the queuing operation in which the extracted packet header, concatenated with the associated tag identifier from the packet reference table 104B, is pushed into an input FIFO within the FIFO buffers 104A. The input FIFO queues packet headers awaiting first-level classification by the hardware firewall.

[0107] A hardware firewall bloom filter block 312 represents the first-level classification circuit comprising the probabilistic data structure 106 configured to perform constant-time membership testing. The hardware firewall bloom filter block 312 receives packet headers from the input FIFO and determines whether packet headers match rules from a rule set. The probabilistic data structure 106 may comprise, for example, a Bloom filter including a bit array stored in on-chip block RAM and hash function modules configured to compute hash indices from packet header fields. The hash function modules may implement the Jenkins-3 hash mechanism. The first-level classification circuit reads bit values from the bit array at positions determined by the computed hash indices and generates a classification output indicating a potential match when all read bit values equal a predetermined logical one. When no potential match occurs, the classification output indicates that the packet header does not match any rule in the rule set.

[0108] The flowchart 300 in FIG. 3A shows a decision branch following the hardware firewall bloom filter block 312. When the first-level classification circuit determines a match or a potentially unsafe condition, the packet header and associated tag identifier may be forwarded to a CPU buffer block 314. The CPU buffer 314 comprises a synchronization buffer configured to transfer data between the first-level classification circuit operating at a first clock frequency and the processing core 108 operating at a second clock frequency. The CPU buffer 314 includes a dual -port memory structure and Gray code counters configured to synchronize read and write pointers across asynchronous clock domains to prevent metastability at clock-domain crossings. A connector A leads from the CPU buffer block 314 to the continuation in FIG. 3B for second-level verification processing.

[0109] When the first-level classification circuit determines that no match is found, indicating that the packet may be transmitted safely, a connector B leads from the hardware firewall bloom filter block 312 to the packet reassembly and transmission stages shown in FIG. 3B.

[0110] FIG. 3B shows the second-level verification, packet reassembly, and transmission stages of the packet processing flowchart 300. Connector A from FIG. 3A leads to a CPU second-level check block 316. The CPU second-level check block 316 representsthe second-level verification performed by the processing core 108 on packet headers flagged as potential matches by the first-level classification circuit. The processing core 108 may comprise a RISC-V processor configured to perform second-level verification by implementing a trie-based search mechanism. The trie-based search mechanism traverses a trie data structure using bits of the packet header, compares packet header fields with rule patterns encoded in the trie data structure, and determines a match when a traversal path reaches a terminal node corresponding to a complete rule. The time complexity of the triebased search mechanism may be independent of the number of rules in the rule set, operating instead as a function of the number of bits in the packet header.

[0111] Following the CPU second-level check block 316, a decision branch determines whether the verification result indicates the packet is safe or unsafe. When the processing core 108 determines the packet may be unsafe based on a true match with a firewall rule, the packet header and tag identifier may be forwarded to a to-invalidate FIFO within the FIFO buffers 104A. An invalidate PRT entry block 324 depicts the discarding operation, in which the corresponding entry in the packet reference table 104B may be invalidated by clearing the valid bit, making the entry available for new packets. The master packet dealer circuit 104 retrieves tag identifiers from the to-invalidate FIFO and invalidates corresponding packet reference table entries.

[0112] When the processing core 108 determines that a packet may be safe based on a false positive (i.e., no true match exists), the packet header and tag identifier may be forwarded to a to-send FIFO within the FIFO buffers 104A. This path merges with connector B, arriving from FIG. 3 A for packets that were classified as safe by the first-level classification circuit without requiring second-level verification.

[0113] A retrieve payload from PRT block 318 depicts the retrieval operation where the master packet dealer circuit 104 retrieves stored packet payload bytes from the packet reference table 104B based on the tag identifier obtained from the to-send FIFO. The packet reference table 104B provides the packet payload bytes to the master packet dealer circuit 104, and the transmitted byte counter tracks the number of bytes sent.

[0114] A reassemble packet block 320 shows the packet reassembly operation where the master packet dealer circuit 104 combines the retrieved packet payload with appropriate packet framing to reconstruct network packets for transmission. A transmit via PHY IP block 322 represents the final transmission stage, where reassembled network packets may be forwarded to the physical interface circuit for transmission to a second network. The physicalinterface circuit 102B transmits packet data to the physical layer via a transmit-side frame buffer and synchronization FIFOs that manage clock-domain crossings between the firewall clock domain and the PHY transmit clock domain.

[0115] FIG. 4A and FIG. 4B illustrates the PRT architecture 400, according to an exemplary embodiment. FIG. 4A and FIG. 4B is described in conjunction with FIG. 1, FIG.2, and FIG. 3. FIG. 4A and FIG. 4B shows the PRT architecture and associated data flow operations executing in the reconfigurable hardware firewall system 100. The packet reference table 400 includes a valid bit field 402, a frame buffer 404 implemented using Block RAM (BRAM), a number of bytes received counter 406, a number of bytes sent counter 408, and a frame fully received indicator 410. The PRT architecture 400 may further include logic circuitry configured to manage data reception and transmission operations, and to validate entry states. A receive PRT slot tag output 412 may be provided to indicate which entry of the packet reference table 400 stores incoming frame data. A transmit PRT slot tag input 414 may be received to specify which entry of the packet reference table 400 should provide outgoing frame data. The packet reference table 400 includes a get transmit data byte output 416 configured to provide byte-by-byte payload data during transmission operations, an is-it-last-byte transmit output 418 configured to indicate when the final byte of a frame has been transmitted, a set frame fully received input 420, and entry invalidation logic 422. The packet reference table 400 may also include a free slot available output 424, an any invalid PRT entry detector 426, an invalidate PRT entry slot input 428, a push receive data byte input 430, an is-it-last-byte receive input 432, entry validation logic 434, and byte counter increment logic 436.

[0116] The valid bit field 402 may be stored as a single-bit register indicating whether the corresponding entry of the packet reference table 400 contains valid frame data. When the valid bit field 402 is set to 1, the entry may be considered occupied and unavailable for new packet storage. When the valid bit field 402 holds a logical value of zero, the entry may be considered free and available for storing incoming packet data. The frame buffer 404 may be implemented using on-chip BRAM configured to store packet payload bytes received from a master packet dealer circuit. The frame buffer 404 may have a depth equal to the maximum transmission unit size, configured to store up to 1500 bytes per entry. The frame buffer 404 may store hexadecimal data values representing the packet payload content as bytes arrive sequentially from the physical interface circuit.

[0117] The number of bytes received counter 406 may be implemented as a register configured to track the quantity of payload bytes written into the frame buffer 404 for a given entry. The number of bytes received counter 406 may be incremented each time a new payload byte is pushed into the packet reference table 400 via the push receive data byte input 430. The 408-byte-sent counter may be implemented as a register configured to track the number of payload bytes read from the frame buffer 404 during transmission operations. The number of bytes sent counter 408 may be incremented each time a payload byte is retrieved from the packet reference table 400 via the get transmit data byte output 416. The frame fully received indicator 410 may be implemented as a single-bit register that indicates whether the complete packet payload has been received and stored in the frame buffer 404.

[0118] The receive PRT slot tag output 412 may be generated when the packet reference table 400 allocates a free entry for storing an incoming packet. The receive PRT slot tag output 412 may comprise a tag identifier value corresponding to the index of the allocated entry within the packet reference table 400. In one embodiment, the tag identifier may be a two-bit value supporting up to four concurrent packet entries. The transmit PRT slot tag input 414 may be received from a to-send FIFO when a packet has been classified as safe and is ready for transmission. The transmit PRT slot tag input 414 may specify which entry of the packet reference table 400 contains the payload data to be transmitted.

[0119] The get transmit data byte output 416 may be configured to provide sequential byte values from the frame buffer 404 based on the current value of the number of bytes sent counter 408. Each retrieval operation may cause the number of bytes sent counter 408 to increment by one. The is-it-last-byte transmit output 418 may be asserted when a comparison operation determines that the number of bytes sent counter 408 plus one equals the number of bytes received counter 406, and the frame fully received indicator 410 is set. This condition may indicate that the current byte being transmitted represents the final byte of the stored packet payload.

[0120] The set frame fully received input 420 may be asserted by the master packet dealer circuit when the physical interface circuit indicates that the complete frame has been received from the network. Upon assertion of the set frame fully received input 420, the frame fully received indicator 410 may be set to a logical value of one for the corresponding entry. The entry invalidation logic 422 may be triggered when a comparison operation determines that the number of bytes sent counter 408 equals the number of bytes received counter 406, and the frame fully received indicator 410 is set. Upon triggering, the entryinvalidation logic 422 may clear the valid bit field 402 to zero, reset the number of bytes received counter 406 to zero, reset the number of bytes sent counter 408 to zero, and clear the frame fully received indicator 410, thereby making the entry available for storing a new packet.

[0121] The free slot available output 424 may be asserted when any invalid PRT entry detector 426 identifies at least one entry whose valid bit field 402 is set to zero. The any invalid PRT entry detector 426 may be implemented as combinational logic configured to examine the valid bit field 402 of each entry in the packet reference table 400. When all entries have the valid bit field 402 set to one, the free slot available output 424 may be deasserted, indicating that no storage capacity remains for incoming packets.

[0122] The invalidate PRT entry slot input 428 may be received from a to-invalidate FIFO when a packet has been classified as unsafe by second-level verification performed by a processing core. Upon receiving the invalidate PRT entry slot input 428, the packet reference table 400 may clear the valid bit field 402 of the specified entry to zero without transmitting the stored payload data, thereby discarding the unsafe packet.

[0123] The push receive data byte input 430 may be configured to receive sequential payload bytes from the master packet dealer circuit as the bytes arrive from the physical interface circuit. Each byte received via the push receive data byte input 430 may be written to the frame buffer 404 at a position corresponding to the current value of the number of bytes received counter 406. The is-it-last-byte receive input 432 may be asserted by the master packet dealer circuit to indicate that the current byte being pushed represents the final payload byte of the incoming frame.

[0124] The entry validation logic 434 may be configured to set the valid bit field 402 to 1 when a new entry is allocated to store an incoming packet. The entry validation logic 434 may be triggered in response to the master packet dealer circuit initiating storage of a new packet when the free slot available output 424 is asserted. The byte counter increment logic 436 may be configured to increment the number of bytes received counter 406 by one each time a payload byte is successfully written to the frame buffer 404 via the push receive data byte input 430.

[0125] In operation, when a new network packet arrives at the physical interface circuit, and the free slot available output 424 indicates that storage capacity exists, the packet reference table 400 may allocate an available entry by identifying an entry whose valid bit field 402 equals zero. The receive PRT slot tag output 412 may then provide the index of theallocated entry to the master packet dealer circuit. The entry validation logic 434 may set the valid bit field 402 to one, marking the entry as occupied. As payload bytes arrive sequentially from the physical interface circuit, each byte may be received via the push receive data byte input 430 and stored in the frame buffer 404 at the position indicated by the number of bytes received counter 406. The byte counter increment logic 436 may increment the number of bytes received counter 406 after each byte storage operation. When the master packet dealer circuit determines that the complete frame has been received from the physical interface circuit, the set frame fully received input 420 may be asserted, setting the frame fully received indicator 410 to one.

[0126] In an embodiment, when a packet stored in the packet reference table 400 is classified as safe by the first-level classification circuit or by second-level verification performed by the processing core, the to-send FIFO may provide the corresponding tag identifier via the transmit PRT slot tag input 414. The packet reference table 400 may then provide sequential payload bytes via the get transmit data byte output 416 based on the current value of the number of bytes sent counter 408. After each byte retrieval, the number of bytes sent counter 408 may be incremented. The is-it-last-byte transmit output 418 may be monitored to determine when the final byte of the payload has been provided. When the number of bytes sent counter 408 equals the number of bytes received counter 406, and the frame fully received indicator 410 is set, the entry invalidation logic 422 may automatically clear the valid bit field 402, reset both counters, and clear the frame fully received indicator 410, thereby releasing the entry for reuse.

[0127] In an embodiment, when a packet stored in the packet reference table 400 is classified as unsafe by second-level verification performed by the processing core, the to-invalidate FIFO may provide the corresponding tag identifier via the invalidate PRT entry slot input 428. The packet reference table 400 may then clear the valid bit field 402 of the specified entry without performing any transmission operations, thereby discarding the packet payload and releasing the entry for storing subsequent incoming packets.

[0128] In another embodiment, the packet reference table 400 may be implemented with a configurable number of entries, ranging from 2 to 4, to optimize resource utilization on a programmable logic device. The tag identifier bit-width may be adjusted based on the configured number of entries. In another embodiment, the frame buffer 404 depth may be configured to accommodate jumbo frames exceeding the standard maximum transmission unit size. In another embodiment, concurrent read and write access to the packet referencetable 400 may be managed through registered data paths that allow proper read operations and clean write updates in subsequent clock cycles.

[0129] FIG. 5 illustrates the architecture 500 of the reconfigurable hardware firewall, according to an exemplary embodiment. FIG. 5 is described in conjunction with FIG. 1 through FIG. 4B. FIG. 5 shows an architecture 500 of the reconfigurable hardware firewall that may execute operations to perform two-level packet classification using a probabilistic data structure and a processing core. FIG. 5 shows a slot tag header input 502, hash function modules 504, 506, and 508, a hardware filter array 510, a BRAM-slice 512, a circular buffer (FIFO) 514, an AXILite interface 516, a decision module 518, a result output path 520, a second result output path 522, a rule matching module 524, and a reconfiguration module 526. The hardware firewall system 500 receives a header combined with a slot tag (HEADER + SLOT TAG) at the slot tag header input 502 and processes the header using parallel hash function computations to determine whether the header matches a predefined rule.

[0130] The slot tag header input 502 receives the combined header and slot tag data from an upstream packet processing component. The header portion contains packet header fields extracted from received network packets, while the slot tag portion provides an identifier that references the corresponding packet payload stored in a packet reference table. The combined header and slot tag data may be formatted as a fixed-width data word suitable for parallel processing by the hash function modules 504, 506, and 508.

[0131] The hash function modules 504, 506, and 508 represent a configurable number of hash function units labeled as hash function 1 504, hash function 2506, and hash function k 508, where k indicates that the number of hash functions may be configured based on system parameters. Each hash function module receives the header data from the slot tag header input 502 and computes a hash index value. The hash function modules 504, 506, and 508 may implement a Jenkins lookup3 hash mechanism, wherein each hash function module uses a different initialization parameter to generate independent hash outputs. The hash outputs from hash function modules 504, 506, and 508 may be truncated to match the bitvector size of the hardware filter array 510 for indexing purposes. The hash function modules 504, 506, and 508 may be implemented as parallel hardware units to enable a pipelined processing flow.

[0132] The hardware filter array 510 receives the hash index values computed by the hash function modules 504, 506, and 508 and performs bit lookups at positions corresponding to the computed hash indices. The hardware filter array 510 may be implemented as theBloom filter comprising a bit array stored in on-chip memory. When all bit values read from the hardware filter array 510 at positions determined by the hash indices equal a predetermined value (such as logic high), the hardware filter array 510 indicates a potential match. The BRAM-slice 512 provides physical memory storage for the hardware filter array 510 and may be implemented using block random-access memory resources available on a programmable logic device.

[0133] The decision module 518 receives the lookup results from the hardware filter array 510 and determines whether a hit has occurred in the hardware filter. The decision module 518 evaluates the condition "IS IT A HIT IN THE HARDWARE FILTER" and generates a binary decision output. When the decision module 518 determines that no hit has occurred (NO path), the result, combined with the slot tag (RESULT + SLOT TAG), proceeds through the result output path 520 to indicate that the packet may be classified as safe. When the decision module 518 determines that a hit has occurred (YES path), the header and slot tag data are forwarded to the circular buffer (FIFO) 514 for second-level verification by the processing core.

[0134] The circular buffer (FIFO) 514 provides synchronization between the hardware filter operating at a first clock frequency and the SoC operating at a second clock frequency. The circular buffer (FIFO) 514 stores header and slot tag data (HEADER + SLOT TAG) for packets flagged as potential matches by the hardware filter array 510. The circular buffer (FIFO) 514 outputs the verification result, combined with the slot tag (RESULT + SLOT TAG), after second-level verification has completed.

[0135] The AXILite interface 516 provides communication pathways between the circular buffer (FIFO) 514 and the SoC components. Three AXILite interface connections are shown: a first AXILite interface connecting the circular buffer (FIFO) 514 to the SoC, a second AXILite interface connecting the rule matching module 524 to the SoC, and a third AXILite interface connecting a false positivity checking module to the SoC. The AXILite interface 516 enables the SoC to read header data from the circular buffer (FIFO) 514, write verification results back to the circular buffer (FIFO) 514, and access the rule matching module 524 for second-level verification operations.

[0136] The rule-matching module 524 performs second-level verification by checking for a rule match using a tree-based search algorithm. The rule-matching module 524 receives packet headers from the circular buffer (FIFO) 514 via the SoC and compares them against the complete rule set to determine whether a true match exists. The tree-based searchimplemented by the rule matching module 524 may include the trie data structure that enables verification with time complexity independent of the number of rules. A "CHECK FOR FALSE POSITIVITY" operation may be performed by the SoC to determine whether a flagged packet represents a true positive match or a false positive result from the probabilistic nature of the hardware filter array 510.

[0137] The second result output path 522 carries the result combined with the slot tag (RESULT+SLOT TAG) from the circular buffer (FIFO) 514 after second-level verification has been completed by the SoC. The result indicates whether the packet has been verified as unsafe (true match) or safe (false positive).

[0138] The reconfiguration module 526 enables dynamic reconfiguration of the hardware firewall that may be controlled by the SoC to update the bit array stored in the BRAM-slice 512 when the firewall rule set changes. During reconfiguration, packet reception may be suspended at the physical interface circuit, the hardware filter array 510 may be updated based on a modified set of rules, and packet reception may be resumed after the update completes.

[0139] In operation, the reconfigurable hardware firewall architecture 500 receives header data, along with a slot tag, at the slot tag header input 502. The hash function modules 504, 506, and 508 compute hash indices from the header data in parallel. The hardware filter array 510 reads bit values from the BRAM-slice 512 at positions corresponding to the computed hash indices. The decision module 518 evaluates whether all read bit values indicate a potential match. When no match is detected, the result and slot tag proceed through the result output path 520, and the corresponding packet may be forwarded for transmission. When a potential match is detected, the header and slot tag are stored in the circular buffer (FIFO) 514. The SoC retrieves the header data via the AXILite interface 516 and performs second-level verification using the rule matching module 524. The verification result is written back to the circular buffer (FIFO) 514 and output through the second result output path 522. The reconfiguration module 526 may be invoked by the SoC to update the hardware filter array 510 when firewall rules change.

[0140] FIG. 6A and FIG. 6B illustrates the MPD architecture 600, according to an exemplary embodiment. FIG. 6A and FIG. 6B is described in conjunction with FIG 1 through FIG.5. FIG. 6 A and FIG. 6B shows the architecture of MPD in the reconfigurable hardware firewall system 100. The MPD architecture 600 may be configured to coordinate packet reception, header extraction, firewall classification, and packet transmission operations.Referring to FIG. 6A and FIG. 6B in conjunction with FIG. 1 and FIG. 2, the MPD architecture 600 corresponds to the MPD 104 component. The MPD architecture 600 may include a receive data path, a firewall wrapper, and a transmit data path that operate in coordination with a packet reference table 104B, a to-firewall FIFO 502, a to-send FIFO 962, and a to-invalidate FIFO 534.

[0141] Referring to FIG. 6A, the receive data path of the MPD architecture 600 may include a free slot available input 504, a new frame available from RX input 506, an RX data input 508, and an is frame fully read input 510. The free slot available input 504 may be a Boolean signal received from the packet reference table 104B, indicating whether an invalid entry exists in the packet reference table 104B for storing incoming packet data. The new frame available from RX input 506 may be a Boolean signal indicating that a new frame has arrived from the physical interface circuit and may be available for processing. The RX data input 508 may be an 8-bit byte signal representing packet data received from the physical interface circuit, byte-by-byte. The is frame fully read input 510 may be a Boolean signal indicating whether the entire frame has been received from the physical layer.

[0142] The master packet dealer architecture 600 may include a current frame determination block 512 configured to determine whether received data corresponds to a current frame being processed. The current frame determination block 512 may receive the RX data input 508 and may determine whether the incoming data byte belongs to the frame currently being stored in the packet reference table 104B. A header and tag received determination block 514 may be configured to determine whether the header and tag information has been completely received for the current packet. The master packet dealer 600 may include a header storage block 516 configured to store header bytes as the frame is received from the physical interface circuit. The header storage block 516 may extract header fields, including protocol, source IP address, destination IP address, source port, and destination port, in accordance with the IPv4 packet format specifications.

[0143] The MPD architecture 600 may include a push RX data byte into PRT output 518, configured to output received data bytes to the packet reference table 104B for storage. An is it last byte RX to PRT output 520, maybe a Boolean signal indicating whether the current byte represents the final byte to be stored in the packet reference table entry. An RX PRT slot tag output 522 may indicate the tag identifier corresponding to the packet reference table entry in which the current frame is being stored. The tag identifier may be generated based on the first available invalid entry in the packet reference table 104B.

[0144] A header and slot tag push block 524 may be configured to push the extracted header, concatenated with the slot tag, into the to-firewall FIFO 502 when the header has been fully received. The to-firewall FIFO 502 may queue header and tag information for processing by a first-level classification circuit comprising a probabilistic data structure 106, as shown in FIG. 1. A firewall wrapper 526 may receive header and tag information from the to-firewall FIFO 502 and may provide input to and receive output from the first-level classification circuit.

[0145] The MPD architecture 600 may include a packet safety determination block 528 configured to receive a result and slot tag signal from the firewall wrapper 526 and determine whether a packet has been classified as safe or unsafe. The result and slot tag signals may include verification results from second-level verification performed by the processing core 108, as shown in FIG. 1. When the packet safety determination block 528 determines that a packet is safe, the slot tag may be forwarded to a safe path for packet transmission. When the packet safety determination block 528 determines that a packet is unsafe, the processing may proceed to a packet invalidation path.

[0146] An unsafe header slot tag push block 530 may be configured to push unsafe packet slot tags into the to-invalidate FIFO 534. The to-invalidate FIFO 534 may queue tag identifiers corresponding to packets determined to be unsafe by either the first-level classification or the second-level verification. An invalidate PRT entry slot output 536 may be configured to signal the packet reference table 104B to invalidate the entry corresponding to an unsafe packet by clearing the valid bit of the corresponding entry. A force stop RX output 538 may be a Boolean signal configured to assert a force stop signal to the physical interface circuit when the current incoming packet has been determined to be unsafe or when no free entries are available in the packet reference table 104B.

[0147] Referring to FIG. 6B, the transmit data path of the MPD architecture 600 may include a new frame ready to send input 940 configured to receive a Boolean signal from the physical interface circuit indicating readiness to accept a new frame for transmission. A to-send FIFO 962 may queue tag identifiers corresponding to packets determined to be safe by the firewall classification process. The to-send FIFO 962 may dequeue a slot tag 944 when the physical interface circuit indicates that it is ready to transmit a new frame.

[0148] A wait to send new frame block 942 may be configured to wait for the new frame ready to send input 940 to become active before initiating packet transmission. A TX PRT slot tag output 946 may be configured to output the tag identifier to the packet referencetable 104B to initiate retrieval of stored payload data for the corresponding safe packet. A get TX data byte from PRT input 948 may receive payload data bytes from the packet reference table 104B, one byte at a time for transmission. An is it last byte TX from PRT input 950 may be a Boolean signal indicating whether the current byte represents the final byte of the packet payload stored in the packet reference table entry.

[0149] A get TX frame data block 952 may be configured to retrieve frame data byte-by-byte from the packet reference table 104B and forward the data to the physical interface circuit for transmission. A TX data output 954 may output the retrieved payload bytes to the physical interface circuit as an 8-bit byte signal. An is frame fully sent output 956 may be a Boolean signal indicating to the physical interface circuit that the entire frame has been transmitted. A decision block 958 may determine whether additional bytes remain to be transmitted from the packet reference table entry. A transmission continuation block 960 may continue retrieving and transmitting bytes until the entire frame has been sent.

[0150] The master packet dealer 600 may implement a state machine architecture for coordinating receive and transmit operations. The state machine may include a CHECK PRT IF SLOT AVAILABLE state configured as a starting state that waits for an incoming packet. The state machine may include states GET FRAME DATA O through GET FRAME DATA 37 configured to receive bytes corresponding to the packet header. A HEADER A VAIL ABLE state may be entered when the complete header has been received and may be forwarded to the first-level classification circuit. AHEADER NOT AVAILABLE state may be entered when the classification result has been received, and remaining packet bytes continue to be received.

[0151] The MPD architecture 600 may be configured to manage back-pressure scenarios by maintaining more entries in the packet reference table 104B than the CPU buffer capacity. When the CPU buffer becomes full, packets may be dropped from the CPU buffer, which in turn may cause corresponding packets to be dropped from the packet reference table 104B. The master packet dealer 600 may receive data from the physical interface circuit as 4-bit nibbles at the rising edge of the RX clock, and the physical interface circuit may combine these nibbles to form 8-bit words that may be received by the master packet dealer 600 byte-by-byte and stored in the packet reference table 104B at the same 8-bit width. The MPD architecture 600 may use an internal counter to fetch the corresponding data bytes while receiving a packet, in accordance with IPv4 packet format specifications.

[0152] In operation, the master packet dealer 600 may begin in the CHECK PRT IF SLOT AVAILABLE state and may wait for the free slot available input 504 and a new frame available from the RX input 506 to both become active. Upon activation of both signals, the master packet dealer 600 may begin receiving frame data through the RX data input 508 and may store received bytes in the packet reference table 104B through the push RX data byte into PRT output 518. Concurrently, the master packet dealer 600 may extract header fields as the initial bytes of the frame are received and may store the extracted header in the header storage block 516. When the header has been completely received, the MPD architecture 600 may push the header and slot tag into the to-firewall FIFO 502 through the header and slot tag push block 524. The firewall wrapper 526 may forward the header to the first-level classification circuit for probabilistic membership testing. If the first-level classification indicates no potential match, the slot tag may be forwarded to the to-send FIFO 962. If the first-level classification indicates a potential match, the header may be forwarded to the processing core 108 for second-level verification. The processing core 108 may perform verification using the trie-based search mechanism and may return a result indicating whether a true match or a false positive exists. Based on the verification result, the packet safety determination block 528 may route the slot tag either to the to-send FIFO 962 for safe packets or to the to-invalidate FIFO 534 for unsafe packets. For safe packets, when the new frame is ready to send, input 940 becomes active, and the master packet dealer 600 may dequeue the slot tag from the to-send FIFO 962 and retrieve payload bytes from the packet reference table 104B via the get TX data byte from PRT input 948. The retrieved bytes may be transmitted through the TX data output 954 to the physical interface circuit byte-by-byte until the entire frame has been sent. For unsafe packets, the invalidate PRT entry slot output 536 may signal the packet reference table 104B to clear the valid bit of the corresponding entry, and if the unsafe packet corresponds to the currently receiving frame, the force stop RX output 538 may be asserted to halt further reception from the physical interface circuit.

[0153] FIG. 7 illustrates an Ethernet IP architecture receive path 700, according to an exemplary embodiment. FIG. 7 is described in conjunction with FIGs 1 through FIG. 6B. FIG. 7 shows the Ethernet IP architecture receive path configured to receive network packet data from a physical layer and transfer the received data to a master packet dealer circuit within a reconfigurable hardware firewall system. The Ethernet IP receive path 700 includes a receive clock signal eth mii rx clk 702, a data valid signal eth mii rx dv, a receive data signal eth_mii_rxd[3:0], a BRAM-sync-FIFO 704, a frame buffer implemented as a BRAM-slice 706, a data valid signal path 708, a data nibble path 710, an enqueue operation 712, a dequeue operation 714, a most significant nibble MSN 716, a least significant nibble LSN 718, a start frame delimiter detection block 704B, a rising edge detection block 704A, a frame fully received detection path 720, a bytes received counter 722, a bytes sent counter 724, a buffer in use status indicator 726, a force stop receive input 728, a new frame available output 730, a receive data output 732, an is frame fully read output 734, and conditional logic blocks for controlling data flow between the physical layer interface and the master packet dealer circuit.

[0154] The receive clock signal eth mii rx clk 702 may be clocked at 25 MHz for 100 Mbps Ethernet operation or at 2.5 MHz for 10 Mbps operation. The receive data signal eth_mii_rxd[3:0] may carry four-bit data nibbles from the physical layer, and the data valid signal eth mii rx dv may indicate when valid data is present on the receive data signal eth_mii_rxd[3:0]. The BRAM-sync-FIFO 704 may be configured to perform clock domain crossing between a PHY receive clock domain operating at the receive clock signal eth mii rx clk 702 frequency and a firewall clock domain operating at 50 MHz or higher. The BRAM-sync-FIFO 704 may use dual-port memory with Gray code counters to synchronize read and write pointers across the asynchronous clock domains, thereby preventing metastability during data transfer between the clock domains.

[0155] The data valid signal path 708 and the data nibble path 710 may be coupled to an input of the BRAM-sync-FIFO 704 via the enqueue operation 712. The dequeue operation 714 may retrieve data from the BRAM-sync-FIFO 704 in the firewall clock domain operating at 50 MHz or higher. The rising edge detection block 704A may detect a rising edge in the data valid signal eth mii rx dv, indicating that a new frame is starting to arrive from the physical layer. The start frame delimiter detection block 704B may identify the start frame delimiter within the incoming data stream, marking the beginning of valid frame data. The frame fully received detection path 720 may indicate when an entire frame has been received from the physical layer, which may be detected by observing a falling edge in the data valid signal eth mii rx dv.

[0156] The frame buffer implemented in the BRAM-slice 706 may store incoming frame data bytes as they are received from the physical layer. The most significant nibble, MSN 716, and the least significant nibble, LSN 718, may be combined to form complete eight-bit data bytes for storage in the frame buffer BRAM-slice 706. The bytes received counter 722 may track the number of bytes received and stored in the frame buffer BRAMslice 706 from the physical layer. The bytes-sent counter 724 may track the number of bytes read by the master packet dealer circuit from the frame buffer BRAM slice 706.

[0157] The buffer-in-use status indicator 726 may indicate whether the frame buffer BRAM slice 706 contains valid frame data being processed. When a rising edge in the data valid signal eth mii rx dv is observed at the rising edge detection block 704A, and the buffer in use status indicator 726 indicates false, the incoming frame data may be stored in the frame buffer BRAM-slice 706, and the buffer in use status indicator 726 may be set to true. When the buffer-in-use status indicator 726 is true, and a new frame begins arriving, the incoming frame may be ignored because the frame buffer BRAM slice 706 still contains data from a previous frame.

[0158] The new frame available output 730 may be asserted when a non-zero number of bytes have been received in the frame buffer BRAM-slice 706 and no bytes have yet been read by the master packet dealer circuit, as indicated by the condition where the bytes received counter 722 is greater than one, and the bytes sent counter 724 equals zero. The receive data output 732 may provide byte-by-byte data to the master packet dealer circuit when the bytes received counter 722 is greater than the bytes sent counter 724 and the buffer in use status indicator 726 is true. The bytes sent counter 724 may be incremented each time the master packet dealer circuit reads a byte.

[0159] The frame fully read output 734 may be asserted when the frame fully received detection path 720 indicates true, and the bytes received counter 722 equals the bytes sent counter 724, indicating that all received bytes have been transferred to the master packet dealer circuit. Upon assertion of the is frame fully read output 734, the buffer in use status indicator 726 may be set to false, the bytes received counter 722 and the bytes sent counter 724 may be reset, and the Ethernet IP receive path 700 may be prepared to receive a subsequent incoming frame.

[0160] The force stop receive input 728 may be asserted by the master packet dealer circuit when the master packet dealer circuit or a first-level classification circuit determines that the currently incoming packet is unsafe. When the force stop receive input 728, which is active, the master packet dealer circuit may no longer be responsible for reading data from the frame buffer BRAM-slice 706. The frame buffer BRAM-slice 706 may be automatically cleared once the current frame is fully received from the physical layer; the buffer-in-use status indicator 726 may be reset to false; and the Ethernet IP receive path 700 may be immediately prepared to manage a subsequent incoming frame.

[0161] In operation, the Ethernet IP receive path 700 may receive data from the physical layer via the receive data signal eth_mii_rxd[3:0], which is clocked by the receive clock signal eth mii rx clk 702 and provides four-bit nibbles. The data nibbles may be enqueued into the BRAM-sync-FIFO 704 along with the data valid signal eth mii rx dv. The BRAM-sync-FIFO 704 may transfer the data from the PHY receive clock domain to the firewall clock domain, where the dequeue operation 714 may retrieve the data at the higher firewall clock frequency. Because the firewall clock operates at a higher frequency than the PHY receive clock, the BRAM-sync-FIFO 704 may never reach a full condition, as data may be dequeued faster than it is enqueued. When a rising edge is detected at the rising edge detection block 704A and the frame buffer BRAM-slice 706 is not in use, data nibbles may be combined into bytes and stored in the frame buffer BRAM-slice 706, with the bytes received counter 722 being incremented for each stored byte. The master packet dealer circuit may begin reading data from the frame buffer BRAM-slice 706 when the new frame available output 730 is asserted, and may continue reading byte-by-byte as the receive data output 732 provides data while incrementing the bytes sent counter 724. When the master packet dealer circuit or the first-level classification circuit determines that the packet is unsafe, the force stop receive input 728 may be asserted, causing the Ethernet IP receive path 700 to automatically clear the frame buffer BRAM-slice 706 upon complete reception of the current frame, thereby preparing the system to receive a subsequent frame without requiring the master packet dealer circuit to read the remaining data.

[0162] FIG. 8 illustrates a transmit path architecture 800 for a physical interface circuit, according to an exemplary embodiment. FIG. 8 is described in conjunction with FIG.1 through FIG. 7. FIG. 8 shows a transmit path architecture 800 configured to transmit network packet data from a master packet dealer circuit to a physical layer. The transmit path architecture 800 comprises a BRAM-slice 802, a BRAM-sync-FIFO 804, transmit data signals 806, a new frame ready to send signal 808, an is frame fully sent signal 810, a most significant nibble (MSN) 812, a least significant nibble (LSN) 814, a valid indicator 816, a data valid signal 818, a data nibble signal 820, an eth mii tx dv signal 822, an eth mii txd signal 824, an eth_mii_tx_clk signal 826, a bytes received counter 828, and a bytes sent counter 830.

[0163] The BRAM-slice 802 may be implemented as a block random access memory structure configured to store frame data bytes received from a master packet dealer circuit. The BRAM-slice 802 may receive transmit data 806 as an input byte from the master packetdealer circuit and may provide a new frame ready to send signal 808 as an output Boolean value indicating availability to accept a new frame. The BRAM-slice 802 may also receive a fully sent signal 810 as a Boolean input from the master packet dealer circuit to indicate completion of frame transmission. The BRAM-slice 802 may operate at a system clock frequency of 50 MHz or higher, which may be equal to or greater than the PHY transmit clock frequency.

[0164] The BRAM-sync-FIFO 804 may be implemented as a synchronization-first-in-first-out buffer configured to perform clock-domain crossing between a firewall clock domain and a PHY transmit clock domain. The BRAM-sync-FIFO 804 may receive data from the BRAM-slice 802 via an enqueue operation and may output data to the physical layer through a dequeue operation. The BRAM-sync-FIFO 804 may be clocked by the eth mii tx clk signal 826 operating at 25 MHz for 100 Mbps Ethernet transmission rates. The BRAM-sync-FIFO 804 may use Gray code counters to synchronize read and write pointers across the asynchronous clock boundary, wherein Gray code encoding changes only one bit at a time, minimizing metastability errors when pointers are sampled across the clock domain boundary. Pointer synchronization may be performed through a series of flip-flop synchronizers to determine full or empty states of the BRAM-sync-FIFO 804.

[0165] The data format within the BRAM-sync-FIFO 804 may comprise the MSN 812, the LSN 814, and the valid indicator 816. The MSN 812 may represent a most significant nibble of the data byte, and the LSN 814 may represent a least significant nibble of the data byte. The valid indicator 816 may be set to a value of 1 when valid data is present in the BRAM-sync-FIFO 804. The BRAM-sync-FIFO 804 may output data in a format comprising the valid indicator 816 followed by eight bits of data represented as "aaaa aaaa" where each "a" represents a data bit.

[0166] The eth mii tx dv signal 822 may correspond to a transmit data valid signal provided to the physical layer. The eth mii txd signal 824 may correspond to transmit data nibbles provided to the physical layer as a 4-bit signal eth_mii_txd[3:0]. The eth mii tx clk signal 826 may correspond to a transmit clock signal from the physical layer used to synchronize data transmission.

[0167] The bytes received counter 828 may track a number of bytes received from the master packet dealer circuit into the BRAM-slice 802. The bytes-sent counter 830 may track the number of bytes transmitted to the physical layer from the BRAM-sync-FIFO 804.

[0168] In operation, the transmit path architecture 800 may perform data transmission via a state machine that manages frame buffering and clock-domain crossings. When the master packet dealer circuit writes frame data to the BRAM-slice 802, the bytes received counter 828 may be incremented by one, and a buffer in use indicator may be set to true. The system may determine whether data is available for transmission by comparing the bytes-received counter 828 with the bytes-sent counter 830. When the bytes received counter 828 exceeds the bytes sent counter 830, data may be available, and the bytes sent counter 830 may be incremented by 1 for each byte transmitted.

[0169] The data valid signal 818 and the data nibble signal 820 may be generated based on the availability of data in the BRAM-slice 802. When valid data is available, the data valid signal 818 may be asserted, and the corresponding data nibble signal 820 may be provided to the BRAM-sync-FIFO 804 for enqueuing. The BRAM-sync-FIFO 804 may dequeue the data synchronized to the eth mii tx clk signal 826 and may provide the eth_mii_tx_dv signal 822 and the eth_mii_txd signal 824 to the physical layer.

[0170] The transmit path architecture 800 may determine whether a frame has been fully received and fully sent by evaluating whether the frame fully received indicator is true and the bytes received counter 828 equals the bytes sent counter 830. When this condition is satisfied, the bytes received counter 828 may be reset to zero, the bytes sent counter 830 may be reset to zero, and the buffer in use indicator may be set to false. The new frame, ready to send signal 808, may then be asserted to indicate that the BRAM-slice 802 is ready to accept a new frame from the master packet dealer circuit.

[0171] The master packet dealer circuit may be configured to continuously write frame data into the BRAM-slice 802 to maintain the bytes received counter 828 greater than the bytes sent counter 830 during transmission. This continuous writing may prevent the frame from being incorrectly split, as a default value with the data valid signal 818 set to false may be sent to the physical layer between segments of valid frame data if the bytes received counter 828 does not exceed the bytes sent counter 830.

[0172] The clock domain crossing performed by the BRAM-sync-FIFO 804 may address timing differences between the firewall clock domain operating at 50 MHz or higher and the PHY transmit clock domain operating at 25 MHz. The higher frequency of the firewall clock domain relative to the PHY transmit clock domain may result in the BRAM-sync-FIFO 804 being dequeued faster than enqueued, thereby preventing the BRAM-sync-FIFO 804 from reaching a full condition during normal operation.

[0173] FIG. 9 illustrates a waveform diagram 900 showing test bench results, according to an exemplary embodiment. FIG. 9 is described in conjunction with FIG. 1 through FIG. 8. FIG. 9 shows a waveform diagram 900 showing test bench results captured by a hardware-integrated logic analyzer (ILA) during operation of the reconfigurable hardware firewall system. The waveform diagram 900 displays signal traces observed during packet transmission through the physical interface circuit, with the ILA status indicated as idle at the time of capture.

[0174] The waveform diagram 900 includes a first signal trace 902 representing an Ethernet Mil receive data valid signal (eth mii rx dv l), which indicates when valid data may be present on the receive data bus. A second signal trace, 904, represents the Ethernet Mil receive data signal (eth_mii_rxd_l[3:0]), configured as a four-bit nibble bus that carries received packet data from the physical layer. A third signal trace, 906, represents the Ethernet Mil transmit enable signal (eth mii tx en), which controls when transmit data may be driven onto the physical layer interface. A fourth signal trace, 908, represents the Ethernet Mil transmit data signal (eth_mii_txd[3:0]), configured as a four-bit nibble bus that carries packet data to be transmitted to the physical layer.

[0175] The horizontal axis of the waveform diagram 900 displays time measurements in microseconds, with a first time scale segment 910 spanning from approximately negative one microsecond to five microseconds, and a second time scale segment 912 spanning from approximately fifteen microseconds to twenty -two microseconds. Time marker 914 indicates a reference point at 1500 within the captured waveform data.

[0176] In operation, the waveform diagram 900 may be generated by implementing the reconfigurable hardware firewall system on a programmable logic device and by connecting a hardware-integrated logic analyzer to monitor the physical interface signals. The test bench configuration may implement a network tester implemented on a separate programmable logic device to generate packets with user-defined patterns. The network tester may feed packets into the firewall system while the integrated logic analyzer captures the signal transitions on the Mil interface signals. The captured waveforms may be used to verify timing relationships between receive and transmit operations, confirm proper packet flow through the firewall system, and analyze throughput performance characteristics. Functional testing may be performed using a simulation model that includes components of the register-transfer-level code, together with the network tester, within a test bench environment.

[0177] FIG. 10 illustrates a synchronization FIFO (SyncFIFO) architecture 1000, according to an exemplary embodiment. FIG. 10 is described in conjunction with FIG 1 through FIG. 9. FIG. 10 shows the SyncFIFO architecture 1000, which may be configured to facilitate clock-domain crossing between asynchronous clock domains within the reconfigurable hardware firewall system. The SyncFIFO architecture 1000 may be used to transfer data between components operating at different clock frequencies, such as between a first-level classification circuit operating at a firewall clock domain and a processing core operating at a CPU clock domain, or between a physical interface circuit and internal firewall components. The SyncFIFO architecture 1000 addresses data corruption and metastability issues common in multi-clock designs through specific hardware techniques, including Gray code counters and pointer synchronization mechanisms.

[0178] The SyncFIFO architecture 1000 comprises a dual-port RAM 1002 configured to store data being transferred between clock domains. The dual-port RAM 1002 includes separate write and read ports that may be accessed independently by different clock domains. A write data input (wdata) 1004 provides data to be written into the dual-port RAM 1002. The dual -port RAM 1002 receives a write address (waddr) 1006 that specifies the memory location for write operations and a read address (raddr) 1008 that specifies the memory location for read operations. A read data output (rdata) 1010 provides data retrieved from the dual -port RAM 1002 during read operations. The dual-port RAM 1002 may be implemented using Block RAM (BRAM) resources available on a programmable logic device.

[0179] The SyncFIFO architecture 1000 includes a write pointer and full logic block (wptr & full) 1012 configured to manage write operations and determine when the FIFO has reached full capacity. The write pointer and full logic block 1012 receives a source clock input (sClkln) 1014 that provides the clock signal for the write domain. A source reset input (sRstln) 1016 provides a reset signal for initializing the write domain logic. The write pointer and full logic block 1012 generate the write address (waddr) 1006 that indexes write operations to the dual-port RAM 1002. A write full signal (wfull) 1018 indicates when the FIFO has no available space for additional write operations. The write pointer and full logic block 1012 also generate a write pointer (wptr) 1020 encoded in Gray code format.

[0180] A write-side Gray code counter 1022 may execute operations in conjunction with the write pointer and full logic block 1012 to generate Gray code encoded pointer values. The write-side Gray code counter 1022 receives a write clock enable signal (wclken) 1024 and a write increment signal (wine) 1026. The Gray code encoding ensures that onlyone bit changes at a time when the pointer value increments, minimizing errors when pointers are sampled across the asynchronous clock boundary. The write-side Gray code counter 1022 outputs the write full signal (wfull) 1018, indicating FIFO full status.

[0181] The SyncFIFO architecture 1000 includes a read pointer and empty logic block (rptr & empty) 1028 configured to manage read operations and determine when the FIFO has no data available. The read pointer and empty logic block 1028 receives a destination clock input (dClkln) 1030 that provides the clock signal for the read domain. The read pointer and empty logic block 1028 generate the read address (raddr) 1008, which indexes read operations to the dual-port RAM 1002. A read-empty signal (rempty) 1032 indicates that the FIFO contains no valid data for read operations. The read pointer and empty logic block 1028 also generate a read pointer (rptr) 1034 encoded in Gray code format.

[0182] A read-side Gray code counter operates in conjunction with the read pointer and empty logic block 1028 to generate Gray code encoded pointer values for the read domain. The read-side Gray code counter receives a read increment signal (rinc) that controls advancement of the read pointer during read operations.

[0183] The SyncFIFO architecture 1000 incorporates pointer synchronization mechanisms to safely transfer pointer values across asynchronous clock boundaries. A synchronized write pointer register (wq2_wptr) 1036 stores the write pointer value synchronized to the read clock domain through a series of flip-flop synchronizers. The synchronized write pointer register (wq2_wptr) 1036 receives the destination clock input (dClkln) 1030 and provides the synchronized write pointer to the read pointer and empty logic block 1028 for determining empty status. A synchronized read pointer register (rq2_wptr) 1038 stores the read pointer value synchronized to the write clock domain through a series of flip-flop synchronizers. The synchronized read pointer register (rq2_wptr) 1038 receives the destination clock input (dClkln) 1030 and provides the synchronized read pointer to the write pointer and full logic block 1012 for determining full status. The pointer synchronization through registered stages ensures that any metastability is contained and allowed to settle before being used for full or empty determination.

[0184] The SyncFIFO architecture 1000 provides interface methods for integration with other system components. An enqueue method (enq Method) provides a standardized interface for write operations, receiving data input, a ready signal (rdy) derived from the inverted write full signal, and an enable signal (en) corresponding to the write increment signal (wine) 1026. A notFull method provides the inverted write full signal (wfull) 1018 toindicate available write capacity. The notEmpty method provides the inverted read-empty signal (rempty) 1032 to indicate that read data is available. The interface methods facilitate integration with the master packet dealer circuit 104, the first-level classification circuit, the CPU buffer, and other FIFO structures within the hardware firewall system.

[0185] In operation, when data is to be transferred from a source clock domain to a destination clock domain, the enqueue method receives write data at the write data input (wdata) 1004 along with an enable signal. The write pointer and full logic block 1012, clocked by the source clock input (sClkln) 1014, generates the write address (waddr) 1006 from the current write pointer value. The write data is stored in the dual -port RAM 1002 at the location specified by the write address (waddr) 1006. The write-side Gray code counter 1022 increments the write pointer (wptr) 1020 using Gray code encoding upon completion of the write operation. The write pointer (wptr) 1020 is synchronized to the read clock domain via the synchronized write pointer register (wq2_wptr) 1036, which samples the Gray-code-encoded pointer value across multiple flip-flop stages to allow metastability to settle. The read pointer and empty logic block 1028 compares the synchronized write pointer with the current read pointer (rptr) 1034 to determine whether valid data is available, deasserting the read empty signal (rempty) 1032 when data is present. Read operations retrieve data from the dual -port RAM 1002 at the location specified by the read address (raddr) 1008, and output the data through the read data output (rdata) 1010. The read-side Gray code counter increments the read pointer (rptr) 1034 using Gray code encoding upon completion of the read operation. The read pointer (rptr) 1034 is synchronized to the write clock domain via the synchronized read pointer register (rq2_wptr) 1038, enabling the write pointer and full logic block 1012 to determine whether space is available for additional writes. When the synchronized read and write pointers indicate that the FIFO is full, the write full signal (wfull) 1018 is asserted to prevent additional write operations until read operations create available space.

[0186] With reference to FIG. 1 and FIG. 2, the SyncFIFO architecture 1000 may be deployed at multiple locations within the reconfigurable hardware firewall system 100. A receive synchronization FIFO may be positioned between the physical interface circuit and the master packet dealer circuit 104 to transfer received network packet data from a PHY receive clock domain to a firewall clock domain. A transmit synchronization FIFO may be positioned between the master packet dealer circuit 104 and the physical interface circuit to transfer packet data for transmission from the firewall clock domain to a PHY transmit clockdomain. A CPU buffer implemented using the SyncFIFO architecture 1000 may be positioned between the first-level classification circuit comprising the probabilistic data structure 106 and the processing core 108 to transfer packet headers flagged as potential matches from the firewall clock domain to the CPU clock domain for second-level verification 108 A. The SyncFIFO architecture 1000 enables the first-level classification circuit to operate at a higher clock frequency than the processing core 108, allowing rapid first-level classification while the processing core 108 performs detailed verification at a lower clock frequency.

[0187] FIG. 11 illustrates a second-level verification mechanism 1100 implemented using the trie data structure for packet header classification, according to an exemplary embodiment. FIG. 11 is described in conjunction with FIG. 1 through FIG. 10. In an embodiment, FIG. 11 shows an exemplary illustration of the trie data structure, which comprises a root node, intermediate nodes, and terminal nodes arranged in a hierarchical binary tree configuration. The root node branches into two child nodes labeled "0" and "1" representing binary bit values. Each subsequent level of the trie data structure continues this binary branching pattern, with nodes at the second level labeled "00*", "01", "10", and "11*", and nodes at the third level including "000", "001*", "010", "101*", and "111*". A fourth level node "0001*", "0101*", and "1010" may be observed, with a fifth level node "10100*" extending from the "1010" node.

[0188] Terminal nodes in the trie data structure are indicated by asterisks, denoting complete rule patterns stored in the dictionary. The dictionary associated with the trie data structure stores rule patterns including: *, 00*, 001*, 0001*, 11*, 101*, 0101*, 111*, and 10100*. Each asterisk-marked node corresponds to a stored rule pattern that incoming packet headers may be compared against during verification.

[0189] The trie data structure receives a match input value, "10101101," representing a packet header or a portion thereof to be verified. The match value traverses the trie data structure beginning at the root node, with each bit of the match value determining the traversal path through successive nodes. The traversal proceeds by selecting the appropriate child node based on whether the current bit equals "0" or " 1 ".

[0190] In operation, the second-level verification mechanism 1100 receives packet headers flagged by a first-level classification circuit as potential matches. The processing core traverses the trie data structure using bits extracted from the packet header. At each node, the algorithm examines the corresponding bit position of the packet header todetermine whether to proceed to the left child node (for bit value "0") or the right child node (for bit value "1"). When the traversal path reaches a terminal node marked with an asterisk, a rule match may be determined, indicating that the packet header corresponds to a stored firewall rule. When the traversal completes without reaching a terminal node, no rule match occurs, and the packet may be classified as a false positive by the first-level classifier. The time complexity of traversing the trie data structure remains constant with respect to the number of rules stored in the dictionary, as the traversal depth depends on the bit length of the packet header rather than the rule count. This characteristic enables the second-level verification algorithm 1100 to maintain consistent verification performance regardless of ruleset size.

[0191] FIG. 12 illustrates a performance graph 1200 showing output throughput characteristics of the reconfigurable hardware firewall system, according to an exemplary embodiment. FIG. 12 is described in conjunction with FIG. 1 through FIG. 11. In an embodiment, FIG. 12 shows a performance graph 1200 showing the output throughput characteristics of the reconfigurable hardware firewall system as a function of false-positive rate across varying rule set sizes. Graph 1200 presents output throughput values on the vertical axis, measured as a percentage ranging from 0 to 100, representing the ratio of actual throughput to the maximum line rate capacity. The horizontal axis shows false-positive percentages, ranging from 0 to 100, indicating the rate at which the probabilistic data structure incorrectly flags packets as potential matches when no actual rule match exists.

[0192] The graph 1200 displays four distinct performance curves corresponding to different rule set configurations. The first curve corresponds to a rule set (e.g., number of rules) with N = 500 rules. A second curve corresponds to a rule set with N = 1000 rules. A third curve corresponds to a rule set size N = 5000 rules. A fourth curve corresponds to a rule set size N equal to 10000 rules. Each curve shows the relationship between false-positive rates and resulting system throughput for the corresponding rule count.

[0193] The performance curves in graph 1200 demonstrate that output throughput remains substantially constant at approximately 100 percent of the maximum line rate when false positivity values remain below a threshold. As false-positive percentages increase beyond this threshold, the output throughput begins to decrease. The curves indicate that larger rule sets may exhibit throughput degradation at lower false-positive thresholds than smaller ones.

[0194] The data presented in graph 1200 reflect measurements obtained at maximum line-rate operating conditions. The performance characteristics shown correspond to a two-level classification architecture in which packets flagged by the first-level probabilistic data structure are verified by the processing core at the second level. Higher false-positive rates result in increased packet traffic directed to the processing core for secondary verification, which may introduce throughput limitations when the processing core's verification rate becomes a bottleneck.

[0195] In practice, graph 1200 provides system designers with empirical data for configuring the probabilistic data structure parameters, including bit array size and hash function count, to achieve the desired throughput for a given rule set size. The relationship between rule count N, false positivity rate, and output throughput enables the selection of appropriate Bloom filter sizing parameters based on the formula for optimal hash function count:

[0196] k = * In (2) . (2)

[0197] where m represents the bit array size, and n represents the number of rules. The graph 1200 demonstrates that the system maintains full efficiency with output throughput at the maximum line rate for false positivity rates up to approximately 60 percent, beyond which throughput may degrade depending on the specific rule set configuration and processing core verification latency.

[0198] FIG. 13A and FIG. 13B illustrates a flow diagram 1300 for classifying network packets in the reconfigurable hardware firewall system, according to an exemplary embodiment. FIG. 13 A and FIG. 13B is described in conjunction with FIG. 1 through FIG.12. FIG 13A and FIG. 13B shows a flow diagram 1300 for classifying network packets in the reconfigurable hardware firewall system implemented on a programmable logic device. The flow diagram 1300 may also be referenced as a mechanism or method and may be implemented by the components illustrated in FIG. 1 and FIG. 2. For instance, the components of FIG. 1 and FIG. 2 may include the physical interface circuit, a master packet dealer (MPD) 104, the PRT 104B, FIFO buffers 104A, the probabilistic data structure 106 configured to perform constant-time membership testing, and the processing core 108 configured to perform second-level verification 108 A.

[0199] At step 1305, network packets may be received from a first network by a physical interface circuit implemented on a programmable logic device. The physical interface circuit, which may correspond to Ethernet 1 202A or Ethernet 2202B as shown inFIG. 2, may be configured to interface with a physical layer 102A of Network 1 100 as shown in FIG. 1. The physical interface circuit may receive data from the physical layer via receive data valid signals and receive data signals, which may be sampled at a receive clock. To minimize latency, the received data may be temporarily stored in a frame buffer and made immediately available to the MPD 104. The physical interface circuit may include a receive synchronization FIFO configured to perform clock domain crossing between a PHY receive clock domain operating at frequencies such as 2.5 MHz or 25 MHz for 10 / 100 Mbps MII / RGMII Ethernet standards and a firewall clock domain operating at a higher frequency, such as 50 MHz or greater. The synchronization FIFO may use dual-port BRAM-based memory structures, with the Gray code counters configured to synchronize read and write pointers across asynchronous clock domains to prevent metastability at clock-domain crossings. The programmable logic device may be implemented as an FPGA, such as an Artix-200T FPGA, configured to implement the firewall architecture.

[0200] At step 1310, the network packets may be separated into packet headers and packet payloads by a master packet dealer circuit. The MPD 104, as shown in FIG. 1 and FIG. 2, may be communicatively coupled to the physical interface circuit and configured to receive network packets from the physical interface circuit. The MPD 104 may extract packet header fields from the network packets as the packets are received byte-by-byte from the physical interface circuit. The packet headers may include a protocol field, a source address field, a destination address field, a source port field, and a destination port field, as specified in the IPv4 packet format. For an IPv4 implementation, the header may comprise 13 bytes, including the protocol, source IP address, destination IP address, source port, and destination port fields. The separation of headers and payloads may occur concurrently with the storage of payload bytes in the packet reference table, enabling on-the-line processing in which packets are processed as they are received, without unnecessary delays or buffering. The MPD 104 may use an internal state machine architecture with states including CHECK PRT IF SLOT AVAILABLE, GET FRAME DATA O through GET FRAME DATA 37 for receiving header bytes, HEADER A VAIL ABLE for sending headers to the probabilistic data structure, and HEADER NOT AVAILABLE for receiving the remaining packet data after the probabilistic data structure returns a result.

[0201] At step 1315, tag identifiers may be generated for each network packet by the master packet dealer circuit. The tag identifiers may be used to index and identify the packet payloads stored in the packet reference table 104B. As shown in FIG. 2, the MPD 104 maygenerate a TAG that corresponds to each packet and may be used to associate the separated header and payload throughout the classification pipeline. The tag bit-width may be 2 bits in implementations where the packet reference table contains 2 to 4 entries for optimal resource utilization. The tag generation mechanism may use a simple allocation approach, assigning the first free entry in the packet reference table as the tag. The tag identifiers may be appended to the packet headers to form HEADER + TAG data structures that may be forwarded through the FIFO buffers 104A, including the input FIFO, the to-send FIFO, and the to-invalidate FIFO, for processing by downstream components.

[0202] At step 1320, the master packet dealer circuit may store the packet payload in a packet reference table entry indexed by the tag identifiers. The PRT 104B, as shown in FIG.1 and FIG. 2, may comprise on-chip memory implemented using Block RAM (BRAM) on the programmable logic device. Each entry in the packet reference table 104B may include a valid bit indicating whether the entry contains valid packet data, a frame buffer configured to store packet payload bytes up to a maximum MTU size such as 1500 bytes, a received byte counter tracking a number of bytes received from the MPD 104, a transmitted byte counter tracking a number of bytes transmitted to the MPD 104, and a frame completion indicator indicating whether an entire packet payload has been received. The payload bytes may be written to the packet reference table entry as the payload bytes are received from the physical interface circuit, and a frame completion indicator may be set upon receiving the final byte of the network packet. The storage of payloads may occur concurrently with the constant-time membership testing performed by the first-level classification circuit, enabling parallel processing of header classification and payload buffering. When a free entry is available in the PRT 104B as indicated by a FREE-ENTRY- AVAILABLE signal, the MPD 104 may begin receiving the frame and storing it in the identified PRT entry with the VALID-BIT set to true.

[0203] At step 1325, a constant-time membership test may be performed on the packet headers to determine whether the packet header matches a rule from a rule set by a first-level classification circuit comprising a probabilistic data structure. The probabilistic data structure 106, as shown in FIG. 1, may comprise a Bloom filter configured to perform constant-time membership testing on the packet headers. As shown in FIG. 5, the Bloom filter may comprise a bit array stored in on-chip memory implemented using BRAM-SLICE and hash function modules 1 through k configured to compute hash indices from the packet headers. The bit array size may be configurable based on the number of rules and available LUTresources, with verified implementations supporting bit array sizes from 1 to 32768. The hash function modules may implement a Jenkins lookup3 hash mechanism, where the number of hash functions k is configured according to the formula:

[0204] k = * In (2) . (3)

[0205] where m is the number of bits in the bit array, and n is the number of rules. The hash outputs may be truncated to match the Bloom filter bit-vector size for indexing into the bit array. The first-level classification circuit may read bit values from the bit array at positions determined by the hash indices and may generate a classification output indicating a potential match when all read bit values equal a predetermined value, such as 1. The hash functions may be implemented in parallel hardware units for pipelined flow, with each hash function utilizing approximately 296 LUTs and 352 flip-flops on the FPGA. The HEADER + TAG may be dequeued from the input FIFO and fed into the Bloom filter for classification. The probabilistic data structure may be configured to provide constant-time membership testing, use less memory than storing the original rules directly, and avoid false negatives while allowing false positives.

[0206] The method 1300 continues from step 1325, indicated by connector A, to FIG.13B.

[0207] At step 1330, a determination may be made as to whether the first-level classification indicates a potential match or no potential match. This decision step may receive the classification output from the probabilistic data structure 106 and may route the packet processing flow based on the result. When the hardware Bloom filter registers a hit, indicating a potential threat, the packet may undergo second-level verification to determine whether it is a false positive. When no hit is detected, the packet may be deemed safe and may be forwarded to the to-send FIFO for transmission. The determination at step 1330 may result in two processing paths: a first path for packets with no potential match, in which the packet may be forwarded directly for transmission, and a second path for packets with a potential match, in which the packet header may be forwarded to the processing core 108 for second-level verification.

[0208] In response to determining that no potential match exists at step 1330, the method proceeds to step 1335, where the packet payload may be retrieved from the packet reference table, the network packets may be reassembled, and the reassembled network packets may be transmitted to a second network. When the first-level classification circuit indicates no match, the HEADER + TAG may be fed into the to-send FIFO. The MPD 104may retrieve the tag identifiers from the to-send FIFO to initiate packet transmission and may retrieve the packet payloads from the packet reference table 104B based on the tag. As shown in FIG. 2, the payload may be retrieved using the TAG and combined with the header to reassemble the packet. The packet reference table may begin sending the stored data, byte by byte, to the MPD 104, incrementing the NUMBER-OF-BYTES-SENT counter as each byte is sent. Once the frame is entirely received (IS-FRAME-FULLY-RCVD equals true) and fully sent to the MPD (NUMBER-OF-BYTES-SENT equals NUMBER-OF-BYTES-RCVD), the PRT entry may be invalidated by clearing the VALID-BIT. The reassembled network packets may be forwarded to the physical interface circuit for transmission to the second network via physical layer 2 102B, using Ethernet 2202B, as shown in FIG. 2. The data to be transmitted may be obtained byte-by-byte from the PRT and may be immediately sent to the PHY-IP for transmission, with the MPD asserting a FRAME-FULL Y-WRITTEN signal after the last byte is sent. The physical interface circuit may include a transmit synchronization FIFO configured to perform a clock-domain crossing between the firewall clock domain and the PHY transmit clock domain for the transmission of reassembled packets.

[0209] Upon determining a potential match at step 1330, the packet header and tag identifier may be transferred to a processing core for second-level verification. The HEADER+TAG may be forwarded to a CPU buffer, which may be implemented as a synchronization buffer comprising a FIFO structure, such as a circular buffer, with a queue depth of 4 entries, matching the PRT entry count. The synchronization buffer may include a dual-port memory structure and Gray code counters configured to synchronize read and write pointers across asynchronous clock domains to prevent metastability during clock domain crossing between a first clock domain of the first-level classification circuit operating at a higher frequency, such as 50 MHz, and a second clock domain of the processing core 108 operating at its own CPU clock domain. The CPU buffer may connect the hardware firewall 208 to the SoC 212 as shown in FIG. 2, enabling safe clock-domain crossing of the header and result across clock domains where the first clock frequency is higher than the second clock frequency, enabling the first-level classification circuit to process packets at a higher throughput than the processing core.

[0210] The processing core 108, as shown in FIG. 1 and FIG. 2, may be configured to receive the packet headers from the CPU buffer and perform a second-level verification of the packet headers using the rules to determine whether a true match exists. The processingcore 108 may comprise a RISC-V processor, such as a SoC RISC-V 64-bit core, configured to perform the second-level verification by implementing a trie-based search mechanism. As shown in FIG. 11, the trie-based search mechanism may involve traversing a trie data structure using bits of the packet header, comparing the packet headers with rule patterns encoded in the trie data structure, and determining a match when a traversal path reaches a terminal node corresponding to a complete rule. The time complexity of the trie-based search mechanism may be independent of the number of rules and instead a function of the number of bits in the header, providing constant-time verification regardless of the rule count. The processing core 108 may generate a verification result indicating whether the packet headers correspond to a true match or a false positive. The HEADER + TAG + RESULT may be written back to the CPU buffer by the processing core and dequeued for routing to either the to-send FIFO or the to-invalidate FIFO based on the verification result.

[0211] In response to the processing core 108 indicating a false positive (no true match exists), the method may proceed to step 1335, where the packet payload may be retrieved from the packet reference table, the network packets may be reassembled, and the reassembled network packets may be transmitted to the second network as described above.

[0212] At step 1340, the network packets may be discarded by invalidating the packet reference table entry on determining a true match. In response to the processing core 108 indicating a true match where a rule determines the packet is unsafe, the HEADER + TAG may be fed into the to-invalidate FIFO. The MPD 104 may retrieve tag identifiers from the to-invalidate FIFO and invalidate the corresponding packet reference table entries by clearing the VALID-BIT, making the entries available for new packets. When the current frame being received by the MPD from the PHY-IP is found to be unsafe during reception, the MPD may send a FORCE-STOP -RX signal to the physical interface circuit. When the FORCE-STOP -RX signal is active, the MPD may no longer be responsible for reading or clearing the frame buffer, and the frame buffer may be automatically cleared when the BUFFER-IN-USE reset is set to false after the current frame is fully received from the PHY. The counters and state machines may then be reset, the FORCE-STOP -RX may be de-asserted, and the physical interface circuit may be immediately ready to manage the next incoming frame. This mechanism enables the system to handle scenarios where the packet reference table has no free entries by discarding incoming network packets at the physical interface until an entry becomes available.

[0213] The method or flow diagram 1300 may further support dynamic reconfiguration of the first-level classification circuit by the processing core 108. The processing core 108 may be configured to dynamically reconfigure the first-level classification circuit by updating the probabilistic data structure based on modified rules when network packet processing is suspended. The dynamic reconfiguration may involve suspending reception of network packets at the physical interface circuit by disabling Ethernet from receiving packets, updating the probabilistic data structure by updating the Bloom filter vector and configurations, and resuming reception of network packets at the physical interface circuit by enabling the regular packet filtering flow. The processing core 108 may also provide a path for users to update firewall rules 108B for both first-level and second-level classification through a serial interface, as shown in FIG. 1, showing the UPDATES FIREWALL RULES 108B functionality.

[0214] The method or flow diagram 1300, including reception, first-level and second-level firewall verifications, invalidation, and transmission, may be designed to occur on-the-line, meaning that as RX-DATA is received from the physical interface circuit byte-by-byte, it may be immediately made available to the MPD 104, and as soon as the header is fully received, it may be passed to the probabilistic data structure 106 for classification. Similarly, transmission may also occur on-the-line, where data retrieved from the PRT 104B may be continuously sent to the MPD 104 and forwarded to the physical interface circuit continuously. This architecture may provide minimal latency by enabling real-time processing of data as it flows through the system, achieving throughput capabilities of up to 100 Mbps for safe packets with processing rates of approximately 62,000 packets per second.

[0215] In an embodiment, the reconfigurable hardware firewall system for network packet classification comprises a programmable logic device that implements the complete packet processing architecture as illustrated in FIG. 2. The programmable logic device may be implemented using an FPGA such as the Artix-200T, though other programmable logic devices, including ASICs, may be used.

[0216] The programmable logic device comprises a physical interface circuit 202A, 202B configured to receive network packets from a first network and transmit the network packets to a second network. As shown in FIG. 7, the physical interface circuit implements synchronization structures for clock-domain crossings between the PHY receive clock domain and the firewall clock domain. The physical interface circuit uses 10 / 100 / 1000 Mbps MII / GMII / RGMII standard interfaces to connect to the PHY chip. The receive path samplesthe RX-D ATA-VALID and RX-DATA signals at the RX-CLK frequency, which operates at 2.5 MHz or 25 MHz for 10 / 100 Mbps Ethernet, respectively. The sampled data is enqueued into a BRAM-based synchronization FIFO 704, where data nibbles are combined to form 8-bit bytes. The physical interface circuit includes a frame-buffer-rx 710 implemented in BRAM for temporarily storing received frame data. When a rising edge in RX-D ATA-VALID is observed at 704A, indicating a new frame arrival, incoming frame data is stored in the frame-buffer-rx only if the buffer is clear of the previous frame, as indicated by BUFFERIN-USE being false. Counters 716 and 718 track the number of bytes stored and the number of bytes read by the master packet dealer circuit to coordinate data transfer.

[0217] The transmit path of the physical interface circuit, illustrated in FIG. 8, operates symmetrically to the receive path. The physical interface circuit transmits data to the PHY layer via the TX-D ATA-VALID and TX-DATA signals, sampled at TX-CLK. A frame-buffer-tx 806 stores outgoing data, and synchronization FIFO structures 802 handle clockdomain crossings to the PHY transmit clock domain. Counters 812, 814 track bytes written by the master packet dealer circuit and bytes sent to the PHY layer to ensure continuous data flow without frame splitting.

[0218] The MPD 104 is communicatively coupled to the physical interface circuit and configured to receive the network packets from the physical interface circuit. As shown in FIGS. 6 A and 6B, the master packet dealer circuit separates received network packets into packet headers and packet payloads. The master packet dealer circuit extracts packet header fields, including protocol, IP source address, IP destination address, source port, and destination port, based on IPv4 packet format specifications as the packet bytes arrive byte-by-byte from the physical interface circuit. The header extraction occurs through a state machine with states including CHECK PRT IF SLOT AVAILABLE,GET FRAME DATA O through GET FRAME DATA 37 for receiving the 38 header bytes, HE ADER A VAIL ABLE when the header is ready for the Bloom filter, and HEADER NOT AVAILABLE while receiving remaining payload bytes.

[0219] The master packet dealer circuit generates tag identifiers for network packets using a simple allocation mechanism: the first free entry in the packet reference table is assigned to the packet. The tag bit width in the demonstrated implementation is 2 bits, supporting up to 4 concurrent packet entries. The master packet dealer circuit stores the packet payloads in a packet reference table 104B indexed by the tag identifiers. The packet reference table is implemented in on-chip BRAM. Each entry in the packet reference table, asshown in FIG. 4A, comprises a valid bit 402 indicating whether the entry contains valid packet data, a frame buffer 404 configured to store packet payload bytes with capacity for 1500 bytes corresponding to the maximum transmission unit size, a received byte counter 410 tracking the number of bytes received, a transmitted byte counter 412 tracking the number of bytes transmitted, and a frame completion indicator 414 indicating whether an entire packet payload has been received. Storage occurs concurrently with the constant-time membership testing performed by the first-level classification circuit, enabling on-the-fly processing in which payload bytes are written to the packet reference table entry 420 as they are received from the physical interface circuit.

[0220] A first-level classification circuit comprising a probabilistic data structure 106 is configured to perform constant-time membership testing. As illustrated in FIG. 5, the first-level classification circuit receives the packet headers from the master packet dealer circuit via an input FIFO 502. The probabilistic data structure comprises a Bloom filter having a 512-bit bit array stored in on-chip memory implemented using BRAM, and multiple hash function modules 506, 508, 510 configured to compute hash indices from the packet headers. The bit array size is configurable depending on the number of rules and available LUT resources, with verified implementations ranging from 1 bit to 32768 bits. The hash function modules implement a Jenkins lookup3 hash mechanism, selected for its superior performance characteristics, including 41% distribution uniformity, 22.4 ns circuit delay, and 85.6% avalanche behaviour compared to alternative hash functions such as Murmur Hash. The formula determines the number of hash functions k:

[0221] k = * In (2) . (4)

[0222] where m is the number of bits in the bit array, and n is the number of rules, which is configurable upon deployment.

[0223] The first-level classification circuit determines whether the packet headers match rules from a ruleset by reading bit values from the bit array at positions 514 determined by the hash indices. The hash outputs are truncated to match the Bloom filter bitvector size for indexing. The first-level classification circuit generates a classification output 516 indicating a potential match when all read bit values equal a predetermined value of 1. Due to the probabilistic nature of Bloom filters, the classification output may indicate false positives where a packet may be mistakenly identified as matching a rule when different elements hash to the same bit positions. The false positive rate depends on the size of the bitarray m, the number of hash functions k, and the number of inserted rules n, and can be approximated using the formula:

[0225] Testing has demonstrated average false-positive rates around 1% with reasonably sized Bloom filters, with the design operating at full efficiency for false-positive rates up to 60%.

[0226] A processing core 108 is configured to receive the packet headers identified as a potential match by the first-level classification circuit. As shown in FIG. 5, when the first-level classification circuit determines a potential match at decision block 518, the packet header and tag are forwarded from the CPU buffer 520, implemented as a synchronization FIFO, to the processing core. The processing core comprises a RISC-V processor, specifically a 64-bit SoC core, configured to perform second-level verification by implementing a trie-based search mechanism, as illustrated in FIG. 11. The trie data structure 1100 encodes the rule patterns where terminal nodes marked with asterisks indicate complete rules. The time complexity of the trie-based search mechanism is independent of the number of rules in the ruleset, depending instead on the number of bits in the header, ensuring scalable and configurable operation for any ruleset size. The processing core traverses the trie data structure using bits of the packet header 10101101, compares the packet headers against rule patterns encoded in the trie, and determines a match when a traversal path reaches a terminal node corresponding to a complete rule.

[0227] The processing core generates a verification result 522 indicating whether the packet headers correspond to a true match or a false positive. In response to the first-level classification circuit indicating no match, the master packet dealer circuit retrieves the packet payloads from the packet reference table and forwards reassembled network packets to the physical interface circuit for transmission via a to-send FIFO 944. In response to the processing core indicating a false positive, the master packet dealer circuit similarly retrieves the packet payloads from the packet reference table and forwards the reassembled network packets to the physical interface circuit for transmission. In response to the processing core indicating a true match, the master packet dealer circuit discards the network packets by invalidating a corresponding entry in the packet reference table, clearing the valid bit, and making the entry available for new packets.

[0228] The reconfigurable hardware firewall further comprises a synchronization buffer configured to transfer data between the first-level classification circuit operating at afirst clock frequency and the processing core operating at a second clock frequency. As illustrated in FIG. 10, the synchronization buffer comprises a dual-port memory structure 1002 and Gray code counters 1006, 1016 configured to synchronize read and write pointers across asynchronous clock domains to prevent metastability. The Gray code encoding ensures that only one bit changes at a time when pointers are sampled across the asynchronous clock boundary, minimizing errors. Pointer synchronization is achieved through the registered stages 1010, 1012, 1026, and 1028, which determine whether the pointer is in the full state 1008 or the empty state 1030. The first clock frequency of the firewall domain is 50 MHz or higher, while the PHY interface clocks operate at 2.5 MHz or 25 MHz, enabling the first-level classification circuit to process packets at a higher throughput than the processing core.

[0229] The physical interface circuit comprises a receive synchronization FIFO 704 configured to perform clock-domain crossing between the PHY receive clock domain and the firewall clock domain, and a transmit synchronization FIFO 802 configured to perform clockdomain crossing between the firewall clock domain and the PHY transmit clock domain. These synchronization FIFOs are implemented using BRAM-based dual-port structures with independent read and write clocks, ensuring that no multi-bit signals are sampled directly across clock domains.

[0230] The reconfigurable hardware firewall system may include a to-send FIFO configured to queue tag identifiers for network packets determined to be safe, and a to-invalidate FIFO 538 configured to queue tag identifiers for network packets determined to be unsafe. The master packet dealer circuit retrieves tag identifiers from the to-send FIFO to initiate packet transmission and retrieves tag identifiers from the to-invalidate FIFO to invalidate corresponding packet reference table entries. The FIFO depths are configured with the CPU buffer having a queue depth of 4, matching the packet reference table entries, while the input FIFO, to-send FIFO, and to-invalidate FIFO have queue depths of 2. These depths are determined based on the Bloom filter processing headers faster than the physical arrival rate of packets.

[0231] The master packet dealer circuit is configured to extract packet header fields from the network packets received while concurrently storing packet payload bytes in the packet reference table. A counter tracks the byte position during reception to identify the 38 header bytes. The master packet dealer circuit asserts a force-stop signal 534 to the physical interface circuit when no free entries are available in the packet reference table or when the network packets being received are determined to be unsafe. When the force-stop signal isactive, the master packet dealer circuit is no longer responsible for reading or clearing the frame-buffer-rx, which is automatically cleared once the current frame is fully received from the PHY.

[0232] The processing core is configured to dynamically reconfigure the first-level classification circuit by updating the probabilistic data structure based on a modified ruleset when processing the network packets is suspended. The reconfiguration process comprises suspending reception of network packets at the physical interface circuit, updating the Bloom filter vector and configurations via the AXI-Lite interface 524, and resuming reception of network packets at the physical interface circuit. The CPU first disables Ethernet from receiving packets, updates the Bloom filter vector, and then enables the regular packet filtering flow. Rules are specified in a format comprising source IP, destination IP, source port, destination port, and protocol fields, with support for wildcarding using asterisk notation and range expansion. A software interface expands wildcards and ranges into individual rule combinations before feeding them to the Bloom filter hash computation.

[0233] The rule file is specified in JSON format, where rules are laid out as an array of objects with packet fields as attributes. A sample rule comprises source IP "192.169.1.*", destination IP "192.168.1.50", protocol "50", source port minimum "3", source port maximum "13", destination port minimum "10", destination port maximum "10", and action "ACCEPT". The software interface scans the ruleset to detect any conflicting or overlapping rules, and only the minimal ruleset after removing overlapping rules is sent for hash generation.

[0234] In an embodiment, the waveform data 900 captured from an integrated logic analyzer shows the receive and transmit signal timing. The waveforms display eth mii rx dv 902, indicating receive data valid, eth_mii_rxd[3:0] 904, showing received data nibbles, eth mii tx en 906, indicating transmit enable, and eth_mii_txd[3:0] 908, showing transmitted data nibbles. The timing demonstrates on-the-line processing: the received data 910 is processed and transmitted 912, 914 with minimal latency.

[0235] In an embodiment, the performance characterization data 1200, shown in FIG.12, illustrates output throughput versus false positivity rate for rule sets of varying sizes, including n=500, n=1000, n=5000, and n=10000 rules. The graph demonstrates that the system maintains high throughput across different false positivity rates up to approximately 60%, beyond which throughput degradation occurs due to increased second-level verification load on the processing core. Testing at 100 Mbps line rate achieved worst-case throughput of47 Mbps for the smallest packet sizes and approximately 65-88 Mbps for typical traffic patterns, with the system capable of processing roughly 62,000 packets per second.

[0236] The implementation uses 296 LUTs and 352 flip-flops per hash function instance on the FPGA. The critical path lies in the clock-domain-crossing BRAM synchronization FIFO in the Ethernet IP. Testing on the Artix-200T FPGA demonstrated no setup or hold-time violations, with positive worst-case negative slack achieved for all constrained clocks at the 50 MHz system frequency. The PHY-facing logic meets timing at 2.5 MHz and 25 MHz with large inherent margins due to the low clock rates.

[0237] The network packet classification apparatus comprises the programmable logic device configured to implement the physical interface circuit, the master packet dealer circuit, the first-level classification circuit, the processing core, and a packet forwarding mechanism. The packet forwarding mechanism is configured to retrieve the packet payloads from the packet reference table and transmit reassembled network packets to the second network when the first-level classification circuit determines that no potential match exists. The packet forwarding mechanism retrieves the packet payloads from the packet reference table and transmits the reassembled network packets to the second network when the processing core determines no true match exists. The packet forwarding mechanism discards the network packets by invalidating the packet reference table entry when the processing core determines that a true match exists. The packet forwarding mechanism operates through the coordinated actions of the to-send FIFO, the to-invalidate FIFO, and the master packet dealer circuit state machine, which manages data flow between the packet reference table and the physical interface circuit.

[0238] The master packet dealer circuit continuously monitors the availability of packet reference table entries. In response to determining that no free entries are available in the packet reference table, the master packet dealer circuit discards incoming network packets at the physical interface circuit until an entry becomes available. This is achieved by not asserting readiness to receive new frames when FREE-ENTRY-AVAILABLE is false, causing the physical interface circuit to ignore incoming packets.

[0239] The trie-based search mechanism implemented in the processing core performs second-level verification by traversing the trie using bits from the packet header. The comparison of packet headers with rule patterns encoded in the trie data structure proceeds bit-by-bit from the most significant bit. A match is determined when a traversal path reaches a terminal node corresponding to a complete rule, indicated by the asterisk markers in the triestructure. The worst-case scenario occurs when every bit of the incoming header matches with some rule until the last bit, requiring approximately 9,200 cycles at 50 MHz. The bestcase scenario for a safe packet requires roughly 2,000 cycles.

[0240] The constant-time membership testing performed by the first-level classification circuit comprises computing hash indices from the packet headers using the Jenkins lookup3 algorithm. The mix and final modules of the hash algorithm implement specific rotation and XOR operations to achieve good avalanche behavior and distribution uniformity. Reading bit values from the bit array stored in on-chip memory at positions corresponding to the computed hash indices occurs sequentially to optimize resources, with the hash outputs indexing the Bloom filter bit array sequentially rather than in parallel.Determining a potential match occurs when all read bit values equal the predetermined value of 1.

[0241] The transfer of the packet header to the processing core comprises queuing the packet headers and tag identifiers in the synchronization buffer, which includes the dual-port memory structure. Synchronizing read and write pointers in the synchronization buffer using Gray code encoding prevents metastability during clock-domain crossing between the first clock domain of the first-level classification circuit operating at 50 MHz and the second clock domain of the processing core. The synchronization buffer has a queue depth of 4 entries, matching the packet reference table capacity, to ensure that if all active packets require software verification, they can be buffered simultaneously while waiting for CPU verification.

[0242] The setting of the frame completion indicator upon receiving a final byte of the network packet occurs when the FRAME-IS-FULLY-READ signal is sent to the master packet dealer circuit by the physical interface circuit, indicated by a falling edge in RX-DATA-VALID after the complete frame has been received from the PHY layer. Payload storage occurs concurrently with constant-time membership testing, enabling the system to process packets on the line without requiring complete packet reception before classification begins.

[0243] The hardware implementation achieves throughput scaling with packet size, as the idle time on Ethernet decreases with larger packets. At maximum line rate, the total idle time is the sum of idle times between packets, and the number of packets is less when the packet size is larger. For safe packets with no false positives, there is no architectural bottleneck up to a 100 Mbps line rate. The bottleneck for packets requiring second-levelverification is primarily due to CPU processing time. The system has been evaluated with rulesets up to 10,000 rules and maintains operational efficiency with theoretical support for larger rulesets limited only by CPU memory capacity for storing the trie structure.

[0244] FIG. 14 illustrates an exemplary hardware configuration of a special-purpose computer 1400 that may be used to implement components and embodiments of the reconfigurable hardware firewall system, according to exemplary embodiments. The specialpurpose computer 1400, shown in FIG. 14, includes CPU 1405, including multicore processors, Al processors 1410 including Graphics Processing Units (GPU) 1410A, Field-Programmable Gate Arrays (FPGA) 1410B, Application-Specific Integrated Circuits (ASIC) 1410C, Neural Processing Units (NPU) 1410D, Tensor Processing Units (TPU) 1410E, system memory 1415, network interface 1420, hard disk drive (HDD) interface 1425, external disk drive interface 1430, and input / output (VO) interfaces 1435 A, 1435B, 1435C. The above-described components or hardware elements of the special-purpose computer 1400 may be communicatively coupled via a system bus 1440. In an embodiment, the CPU 1405 may execute arithmetic, logic, and / or control operations by accessing the system memory 1415. The CPU 1405 and the Al processors 1410 may implement the interfaces, the processors, etc., of the exemplary devices and / or systems described above. The Al processors 1410 may execute Al operations. The Al processors 1410 may include multiple types of processors tailored or customized for implementing specific Al workloads.

[0245] In an embodiment, the GPU 1410A may be designed for rendering graphics and is highly effective for executing Al-related operations due to its parallel processing capabilities. The GPU 1410A can execute multiple calculations simultaneously and is suitable for training Al models. The GPU 1410A with Al-specific hardware (e.g., the ASIC 1410C, the NPU 1410D, the TPU 1410E, etc.) may be integrated to accelerate the Al tasks. For example, tensor cores may be designed to speed up the training of neural networks and machine learning models by improving matrix multiplication, a core operation in many Al algorithms. In an embodiment, the FPGA 1410B may be a reconfigurable processor implemented to execute specific Al tasks, thereby offering flexibility and efficiency in realtime applications. The FPGA 1410B may have a unique design that includes a series of interconnected, configurable logic blocks. The reprogrammability of the FPGA 1410B enables high-level customization and supports a wide range of Al applications.

[0246] In an embodiment, the ASIC 1410C may be custom-designed processors optimized for specific Al applications, providing high performance and energy efficiency.The ASIC 1410C may be designed solely to accelerate Al workloads. The ASIC 1410C is not reprogrammable like the FPGA 1410B, but its specialized design enables significant improvements in speed and efficiency for tasks such as deep learning inference and training. In an embodiment, the NPU 1410D may be designed to execute specialized Al operations, particularly neural network-based operations. The NPU 1410D may be designed to accelerate neural network computations and is often integrated into CPUs or Systems on Chips (SoCs). The NPU 1410D may execute operations to process large volumes of data faster than other general -purpose processors and perform various Al tasks such as image recognition and natural language processing (NLP). The NPU 1410D may be used in mobile devices and personal computers to execute Al tasks without significantly increasing power consumption.

[0247] In an embodiment, the TPU 1410E may be designed specifically for accelerating machine learning workloads, particularly those involving tensor computations. The TPU 1410E may be used in data centers to power various Al services such as search algorithms and language translation. The TPU 1410E processor architecture may be optimized for high throughput and low latency, facilitating the implementation of large-scale Al applications. In an embodiment, the Al processors 1410, including the GPU 1410A, the FPGA 141 OB, the ASIC 1410C, the NPU 1410D, and the TPU 1410E, may execute operations or functions to perform multiple complex operations, computations, and calculations simultaneously, thereby enabling faster execution of the Al tasks compared to the sequential processing of general-purpose CPUs. The Al processors 1410 may be designed to execute operations more efficiently. For example, low-precision arithmetic can be used to reduce power consumption, thereby improving the performance of the implemented Al applications. In an embodiment, the Al processors 1410 may be customized to implement specific Al models, machine learning models, machine learning engines, and Al applications, enabling optimized execution of operations or functions.

[0248] In an embodiment, implementing Al workloads or Al tasks using the Al processors 1410 may provide technical advantages, such as parallel processing, reduced precision, hardware optimization, energy efficiency, and support for neural networks. The Al processors 1410 may be designed with high parallelism, allowing them to execute multiple Al-related calculations simultaneously. Al tasks or Al workloads, such as matrix multiplication and vector operations, may be used in neural networks. The Al processors 1410 may use reduced-precision arithmetic (e.g., 8-bit or 16-bit) to improve computational and power efficiency while maintaining acceptable accuracy levels for Al tasks. The Alprocessors 1410 may incorporate specialized hardware components, such as multiply-accumulate (MAC) units and on-chip memory, to execute specific Al workloads. The Al processors 1410 may be optimized for neural network tasks, including forward and backward passes during training and inference, and support various neural network architectures and frameworks.

[0249] In an embodiment, the special -purpose computer 1400 does not necessarily include Al processors 1410, for example, if the special-purpose computer 1400 is used to implement a device other than a central processing device. The system memory 1415 may store information and / or instructions for use in combination with the CPU 1405. The system memory 1415 may include volatile and non-volatile memory, such as random-access memory (RAM) 1445 and read-only memory (ROM) 1450. A basic input / output system (BIOS) containing the basic routines that help to transfer information between elements within the special-purpose computer 1400, such as during start-up, may be stored in the ROM 1450. The system bus 1440 may be any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures.

[0250] The special -purpose computer 1400 may include the network interface 1420 for communicating with other computers and / or devices via a network.

[0251] Further, the special-purpose computer 1400 may include a hard disk drive (HDD) 1455 for reading from and writing to a hard disk (not shown) and an external disk drive 1460 for reading from or writing to a removable disk (not shown). The removable disk may be a magnetic disk for a magnetic disk drive or an optical disk, such as a CD-ROM for an optical disk drive. The HDD 1455 and the external disk drive 1460 are connected to the system bus 1440 by the HDD interface 1425 and the external disk drive interface 1430, respectively. The drives and their associated non-transitory computer-readable media provide non-volatile storage of computer-readable instructions, data structures, program modules, and other data when the special-purpose computer operates as a general-purpose computer. The relevant data may be organized in a database, such as a relational or object database.

[0252] Although the exemplary environment described herein employs a hard disk (not shown) and an external disk (not shown), it should be appreciated by those skilled in the art that other types of computer-readable media which may store data that is accessible by a computer, such as magnetic cassettes, flash memory cards, digital video disks, random accessmemories, read-only memories, and the like, may also be used in the exemplary operating environment.

[0253] Several program modules may be stored on the hard disk, external disk, the ROM 1450, or the RAM 1445, including an operating system (not shown), one or more application programs 1445A, other program modules (not shown), and program data 1445B. The application programs may include at least some of the functionality described above.

[0254] The special -purpose computer 1400 may be connected to input device 1465, such as a mouse and / or keyboard, and to display device 1470, such as a liquid crystal display, via corresponding I / O interfaces 1435A to 1435C and the system bus 1440. In addition to an implementation using a special -purpose computer 1400, as shown in FIG. 14, part or all of the functionality of the exemplary embodiments described herein may be implemented as one or more hardware circuits. Examples of such hardware circuits include, but are not limited to, Large Scale Integration (LSI) and Reduced Instruction Set Circuits (RISC).

[0255] One or more embodiments are now described with reference to the drawings, wherein reference numerals refer to elements throughout. Numerous specific details are set forth in the following description to provide a thorough understanding of the various embodiments. It is evident, however, that the various embodiments may be practiced without these specific details (and without applying them to any networked environment or standard).

[0256] As used in this application, in some embodiments, the terms "component," "system," and the like are intended to refer to, or comprise, a computer-related entity or an entity related to an operational apparatus with one or more specific functionalities, wherein the entity may be either hardware, a combination of hardware and software, software, or software in execution. As an example, a component may be, but is not limited to, a process running on a processor, a processor, an object, an executable, a thread of execution, computer-executable instructions, a program, and / or a computer. By way of illustration and not limitation, both an application running on a server and the server itself may be components.

[0257] The above descriptions and illustrations of embodiments, including what is described in the Abstract, are not intended to be exhaustive or to limit one or more embodiments to the precise forms disclosed. While specific embodiments of, and examples for, one or more embodiments are described herein for illustrative purposes, various equivalent modifications are possible within the scope, as those skilled in the relevant art will recognize. These modifications may be made in accordance with the above description.Rather, the scope is to be determined by the following claims, which are to be interpreted in accordance with established doctrines of claim construction.

[0258] The terms “first,” “second,” “third,” and so forth, as used in the claims, unless otherwise clear by context, are for clarity only and don't otherwise indicate or imply any order in time. For instance, “a first determination,” “a second determination,” and “a third determination” do not indicate or imply that the first determination is to be made before the second determination, or vice versa, etc.

[0259] The description of illustrated embodiments of the subject disclosure as provided herein, including what is described in the Abstract, is not intended to be exhaustive or to limit the disclosed embodiments to the precise forms disclosed. While specific embodiments and examples are described herein for illustrative purposes, various modifications are possible that are considered within the scope of such embodiments and examples, as one skilled in the art can recognize. In this regard, while the subject matter has been described herein in connection with various embodiments and corresponding drawings, where applicable, it is to be understood that other similar embodiments can be used or modifications and additions can be made to the described embodiments for performing the same, similar, alternative, or substitute function of the disclosed subject matter without deviating therefrom. Therefore, the disclosed subject matter should not be limited to any single embodiment described herein but rather should be construed in breadth and scope in accordance with the appended claims below.

Claims

CLAIMSWe Claim:

1. A reconfigurable hardware firewall system for network packet classification, comprising:a programmable logic device, comprising:a physical interface circuit, configured to:receive a plurality of network packets from a first network; and transmit the plurality of network packets to a second network; a master packet dealer circuit communicatively coupled to the physical interface circuit, configured to:receive the plurality of network packets from the physical interface circuit;separate one or more network packets from the received plurality of network packets into one or more packet headers and one or more packet payloads;generate one or more tag identifiers for the one or more network packets; andstore the one or more packet payloads in a packet reference table indexed by the one or more tag identifiers;a first-level classification circuit comprising a probabilistic data structure configured to:perform constant-time membership testing;receive the one or more packet headers;determine whether the one or more packet headers match one or more rules from a plurality of rules; andgenerate a classification output indicating a potential match or no match; a processing core configured to:receive the one or more packet headers corresponding to the one or more packet headers and indicating as a potential match by the first-level classification circuit;perform a second-level verification of the one or more packet headers using the plurality of rules; andgenerate a verification result indicating whether the one or more packet headers correspond to a true match or a false positive.

2. The system of claim 1, wherein the master packet dealer circuit is further configured to:in response to the first-level classification circuit indicating no match, retrieve the one or more packet payloads from the packet reference table and forward one or more reassembled network packets to the physical interface circuit for transmission;in response to the processing core indicating a false positive, retrieve the one or more packet payloads from the packet reference table and forward the one or more reassembled network packets to the physical interface circuit for transmission; andin response to the processing core indicating a true match, discard the one or more network packets by invalidating a corresponding entry in the packet reference table.

3. The system of claim 1, wherein the probabilistic data structure comprises a Bloom filter, comprising:a bit array stored in on-chip memory; anda plurality of hash function modules configured to compute hash indices from the one or more packet headers,wherein the first-level classification circuit is configured to:read bit values from the bit array at positions determined by the hash indices; and generate the classification output indicating a potential match when all read bit values equal a predetermined value.

4. The system of claim 1, further comprising:a synchronization buffer configured to transfer data between the first-level classification circuit operating at a first clock frequency and the processing core operating at a second clock frequency, wherein the synchronization buffer comprises:a dual-port memory structure; andGray code counters configured to synchronize read and write pointers across asynchronous clock domains to prevent metastability,wherein the first clock frequency is higher than the second clock frequency, enabling the first-level classification circuit to process packets at a higher throughput than the processing core.

5. The system of claim 1, wherein the plurality of hash function modules implements a Jenkins lookup3 hash mechanism, and wherein the plurality of hash function modules is configured based on a size of the bit array and a number of rules in the plurality of rules.

6. The system of claim 1, wherein the physical interface circuit comprises:a receive synchronization FIFO configured to perform clock domain crossing between a PHY receive clock domain and a firewall clock domain; anda transmit synchronization FIFO configured to perform clock domain crossing between the firewall clock domain and a PHY transmit clock domain.

7. The system of claim 1, wherein the packet reference table comprises on-chip memory, and wherein each entry in the packet reference table comprises:a valid bit indicating whether the entry contains valid packet data;a frame buffer configured to store packet payload bytes;a received byte counter tracking a number of bytes received;a transmitted byte counter tracking a number of bytes transmitted; anda frame completion indicator indicating whether an entire packet payload has been received.

8. The system of claim 1, further comprising:a to-send FIFO configured to queue the or more tag identifiers corresponding to the one or more network packets determined to be safe; anda to-invalidate FIFO configured to queue the one or more tag identifiers corresponding to the one or more network packets determined to be unsafe,wherein the master packet dealer circuit retrieves the one or more tag identifiers from the to-send FIFO to initiate packet transmission and retrieves one or more tag identifiers from the to-invalidate FIFO to invalidate corresponding packet reference table entries.

9. The system of claim 1, wherein the processing core comprises a RISC-V processor configured to perform the second-level verification by implementing a trie-based search mechanism, wherein a time complexity of the trie-based search mechanism is independent of the number of rules in the plurality of rules.

10. The system of claim 1, wherein the master packet dealer circuit is configured to: extract a plurality of packet header fields from the plurality of network packets received while concurrently storing packet payload bytes in the packet reference table; and assert a force-stop signal to the physical interface circuit when no free entries are available in the packet reference table or when the one or more network packets being received are determined to be unsafe.

11. The system of claim 1, wherein the processing core is further configured to dynamically reconfigure the first-level classification circuit by updating the probabilistic data structure based on a modified plurality of rules when processing the one or more network packets is suspended.

12. A method for classifying network packets in a reconfigurable hardware firewall, the method comprising:receiving, by a physical interface circuit implemented on a programmable logic device, a plurality of network packets from a first network;separating, by a master packet dealer circuit, one or more network packets from the plurality of network packets into one or more packet headers and one or more packet payloads;generating, by the master packet dealer circuit, one or more tag identifiers corresponding to the one or more network packets;storing, by the master packet dealer circuit, the packet payload in a packet reference table entry indexed by the one or more tag identifiers;performing, by a first-level classification circuit comprising a probabilistic data structure, constant-time membership testing on the one or more packet headers, to determine whether the packet header matches a rule from a plurality of rules;in response to the first-level classification, determining no potential match:retrieving the packet payload from the packet reference table;reassembling the one or more network packets; andtransmitting the reassembled one or more network packets to a second network;in response to the first-level classification, determining a potential match:transferring the one or more packet headers to a processing core; performing, by the processing core, a second-level verification of the one or more packet headers using the plurality of rules to determine whether a true match exists;in response to determining no true match exists, retrieving the packet payload, reassembling the one or more network packets, and transmitting the reassembled one or more network packets to the second network; andin response to determining that a true match exists, discarding the one or more network packets by invalidating the packet reference table entry.

13. The method of claim 12, wherein performing constant-time membership testing comprises:computing, by a plurality of hash function modules, a plurality of hash indices from the one or more packet headers;reading bit values from a bit array stored in on-chip memory at positions corresponding to the computed hash indices; anddetermining a potential match when all read bit values equal a predetermined value.

14. The method of claim 12, wherein transferring the packet header to the processing core comprises:queuing the one or more packet headers and the one or more tag identifiers in a synchronization buffer including a dual-port memory structure; andsynchronizing read and write pointers of the synchronization buffer using a Gray code encoding to prevent metastability during clock domain crossing between a first clock domain of the first-level classification circuit and a second clock domain of the processing core.

15. The method of claim 12, wherein performing second-level verification comprises: traversing a trie data structure using bits of the packet header;comparing the one or more packet headers with one or more rule patterns encoded in the trie data structure; anddetermining a match when a traversal path reaches a terminal node corresponding to a complete rule.

16. The method of claim 12, further comprising:monitoring an availability of entries in the packet reference table; andin response to determining that no free entries are available, discarding the one or more network packets at the physical interface circuit until an entry becomes available.

17. The method of claim 12, further comprising dynamically reconfiguring the first-level classification by:suspending a reception of the one or more network packets at the physical interface circuit;updating the probabilistic data structure based on a modified plurality of rules; and resuming the reception of the one or more network packets at the physical interface circuit.

18. The method of claim 12, wherein the one or more packet headers include a protocol field, a source address field, a destination address field, a source port field, and a destination port field based on IPv4 packet format specifications.

19. The method of claim 12, wherein storing the packet payload comprises:writing payload bytes to the packet reference table entry as the payload bytes are received from the physical interface circuit; andsetting a frame completion indicator upon receiving a final byte of the network packet,wherein the storing occurs concurrently with the constant-time membership testing performed by the first-level classification circuit.

20. A reconfigurable hardware firewall apparatus for network packet classification, comprising:a programmable logic device, comprising:a physical interface circuit, configured to:receive a plurality of network packets from a first network; and transmit the plurality of network packets to a second network;a master packet dealer circuit communicatively coupled to the physical interface circuit, configured to:receive the plurality of network packets from the physical interface circuit;separate one or more network packets from the received plurality of network packets into one or more packet headers and one or more packet payloads;generate one or more tag identifiers for the one or more network packets; andstore the one or more packet payloads in a packet reference table indexed by the one or more tag identifiers;a first-level classification circuit comprising a probabilistic data structure configured to:perform constant-time membership testing;receive the one or more packet headers;determine whether the one or more packet headers match one or more rules from a plurality of rules; andgenerate a classification output indicating a potential match or no match;a processing core configured to:receive the one or more packet headers corresponding to the one or more packet headers and indicating as a potential match by the first-level classification circuit;perform a second-level verification of the one or more packet headers using the plurality of rules; andgenerate a verification result indicating whether the one or more packet headers correspond to a true match or a false positive.

Images