Xilinx, Inc.

Gordon John Brebner

Michael E Attig

Chidamber R Kulkarni

Philip Bryn James-Roxby

Eric R Keller

Christopher E Neely

Chengchen Hu

Ji Yang

Guanwen Zhong

Weirong Jiang

Haris Javaid

Ian McBryan

Jaime Herrera

Rowan Lyons

Sundararajarao Mohan

Jack S Lo

Chidamber Kulkarni

Yan Zhang

Michael Alan Baxter

Graham F Schelle

Mark Brian Carson

Michaela Blott

Yi-Hua Edward Yang

Henry E Styles

Siyi Qiao

Nguyen Duy Anh Tuan

Mark B Carson

Embodiments herein describe a describe an interface shell in a SmartNIC that reduces data-copy overhead in CPU-centric solutions that rely on hardware compute engine (which can include one or more accelerators). The interface shell offloads tag matching and address translation without CPU involvement. Moreover, the interface shell enables the compute engine to read messages directly from the network without extra data copy—i.e., without first copying the data into the CPU's memory.

Network attached MPI processing architecture in smartnics

Apparatus and associated methods relate to packet header field extraction as defined by a high level language and implemented in a minimum number of hardware streaming parsing stages to speculatively extract header fields from among multiple possible header sequences. In an illustrative example, the number of stages may be determined from the longest possible header sequence in any received packet. For each possible header sequence, one or more headers may be assigned to each stage, for example, based on a parse graph. Each pipelined stage may resolve a correct header sequence, for example, by sequentially extracting length and transition information from an adjacent prior stage to determine offset of the next header. By speculatively extracting selected fields from every possible position in each pipeline stage, a correct value may be selected using sequential hardware streaming pipelines to substantially reduce parsing latency.

Streaming architecture for packet parsing

Embodiments herein describe a hardware accelerator for a blockchain node. The hardware accelerator is used to perform a validation operation to validate one or more transactions before those transactions are committed to a ledger of a blockchain. The blockchain may include multiple peer-nodes, each of which contains standard software running on a server or container. Instead of validating a block of transactions using software, the hardware accelerator can validate the transactions in a fraction of the time. The peer-node software then gathers the validation results from the hardware accelerator and combines the results with received block data to derive the block which is committed to the stored ledger.

Blockchain machine compute acceleration engine with a block verify and a block validate

Examples herein describe a programmable traffic management engine that includes both programmable and non-programmable hardware components. The non-programmable hardware components are used to generate features that can then be used to perform different traffic management algorithms. Depending on which traffic management algorithm the PTM engine is configured to do, the PTM engine may use a subset (or all) of the features to perform the algorithm. The programmable hardware components in the PTM engine are programmable (e.g., customizable) by the user to perform a selected algorithm using some or all of the features provided by the non-programmable hardware components.

Programmable traffic management engine

Embodiments herein describe a hardware accelerator (e.g., a network acceleration engine) for a blockchain machine or node. The hardware accelerator parses packets containing separate components of a block of transactions to generate data to perform a validation process. To avoid the latency that comes with using software, the embodiments herein describe a protocol processor in the hardware accelerator that parses the packets and prepares the data so it can be consumed by downstream components in the accelerator without software intervention. These downstream components can then perform a validation operation to validate one or more transactions before those transactions are committed (i.e., added) to a ledger of a permissioned blockchain.

Blockchain machine network acceleration engine

Examples herein describe an acceleration framework that includes a hybrid congestion control (CC) engine where some components are implemented in software (e.g., a CC algorithm) while other components are implemented in hardware (e.g., measurement and enforcement modules and a flexible processing unit). The hardware components can be designed to provide measurements that can be used by multiple different types of CC algorithms. Depending on which CC algorithms are currently enabled, the hardware components can be programmed to perform measurement, processing, and enforcement tasks, thereby freeing the CPUs in the host to perform other tasks. In this manner, the hybrid CC engine can have the flexibility of a pure software CC algorithm with the advantage of performing many of the operations associated with the CC algorithm in hardware.

Programmable congestion control engine

Mining proxy acceleration may include receiving, within a mining proxy, packetized data from a mining pool server and determining, using the mining proxy, whether the packetized data qualifies for broadcast processing. In response to determining that the packetized data qualifies for broadcast processing, the packetized data can be modified using the mining proxy to generate broadcast data. The broadcast data can be broadcast, using the mining proxy, to a plurality of miners subscribed to the mining proxy.

Mining proxy acceleration

A match-action circuit includes one or more conditional logic circuits, each having an input coupled to input header or metadata of a network packet, and each configured to generate an enable signal as a function of one or more signals of the header or metadata. Each match circuit of one or more match circuits is configured with response values associated with key values. Each match circuit is configured to conditionally lookup response value(s) associated with an input key value from the header or metadata in response to the enable signal from a conditional logic circuit. One or more action circuits are configured to conditionally modify, in response to states of the response value(s) output from the match circuit(s), data of the header or the metadata.

Pipelined match-action circuitry

A device includes a programmable passive measurement hardware engine, a programmable active measurement hardware engine, and a configuration engine. The programmable passive measurement hardware engine is configured to collect statistical data, from data transmission at a network line rate, used for network measurement. The programmable active measurement hardware engine is configured to generate probe packets and wherein the programmable active measurement hardware engine is further configured to collect responses to the generated probe packets, wherein the collected responses are used for the network measurement. The configuration engine is configured to receive data settings and wherein the configuration engine is further configured to program the programmable passive measurement hardware engine and the programmable active measurement hardware engine with the received data settings.

Programmable network measurement engine

Apparatus and associated methods relating to data packet deparsing include an editing circuit configured to perform one or more predetermined editing operations on headers of an incoming data packet step by step without extracting all headers from the incoming data packet. In an illustrative example, an editor circuit may include an updating circuit configured to receive the data packet and update a header in the data packet. The editor circuit may also include a removal circuit configured to remove a header from the data packet. The editor circuit may also include an insertion circuit configured to insert one or more consecutive headers to the data packet. A state machine may be configured to enable or disable the updating circuit, the removal circuit, and/or the insertion circuit based on the predetermined editing operations. By using the editing circuit, packet deparsing may be performed with less hardware resources and low latency.

Streaming editor circuit for implementing a packet deparsing process

Methods and apparatus for using dynamic programming to determine the most efficient mapping of a pipeline of virtual flow tables (VFTs) onto a pipeline of physical flow tables (PFTs) in the data plane of a software-defined networking (SDN) device are described. One example method of determining a configuration for an SDN device generally includes receiving a representation of a series of one or more VFTs, each of the VFTs having one or more properties; receiving a representation of a series of one or more PFTs for hardware of the SDN device, each of the PFTs having one or more capabilities; generating, using dynamic programming based on the properties of the VFTs and the capabilities of the PFTs, a mapping of the series of VFTs onto the series of PFTs; and outputting the generated mapping for implementation on the hardware of the SDN device.

Efficient mapping of table pipelines for software-defined networking (SDN) data plane

Devices and methods for performing a cyclic redundancy check are disclosed. For example, a device has a splitter for splitting a data word into a plurality of paths. The device also has a plurality of cyclic redundancy check units. Each of the units is for processing a respective one of the paths. In addition, each of the units includes a first output port for outputting a cyclic redundancy check value for a packet ending within the unit and a second output port for outputting a cyclic redundancy check value for a packet starting or ongoing within the unit.

Modular and scalable cyclic redundancy check computation circuit

In one approach for processing a data packet, in at least one stage of a plurality of stages of a pipeline circuit, a respective packet field value is extracted from the data packet. In each stage of the plurality of stages, a respective tuple field value is inserted into a respective tuple register of the stage at a respective offset. The respective tuple field value in the at least one stage is based on the respective packet field value. In each stage of the plurality of stages except a last one of the stages, the contents of the respective tuple register of the stage are provided as input to a next one of the stages.

Tuple construction from data packets

In an FSM circuit, look-ahead-cascade modules are coupled to receive possible states and corresponding subsets of data inputs. Merge modules are coupled to a second-to-the-lowest to highest order of the look-ahead-cascade modules. The second-to-the-lowest to highest order of disambiguation modules are coupled to at least a portion of the merge modules. The lowest order of the disambiguation modules is coupled to the lowest order of the look-ahead-cascade modules. The lowest-to-highest order of the disambiguation modules are coupled to receive respective sets of interim states of rN states each to select respective sets of next states of r states each. A state register is coupled to receive a portion of the highest order of the sets of next states to provide a select signal. Each of the disambiguation modules is coupled to receive the select signal for selection of the sets of next states of the r states each.

High throughput finite state machine

An integrated circuit can include a programmable circuitry operable according to a first clock frequency and a block random access memory. The block random access memory can include a random access memory (RAM) element having at least one data port and a memory processor coupled to the data port of the RAM element and to the programmable circuitry. The memory processor can be operable according to a second clock frequency that is higher than the first clock frequency. Further, the memory processor can be hardwired and dedicated to perform operations in the RAM element of the block random access memory.

Growing community of inventors

San Jose, CA, United States of America

Gordon John Brebner