Patent Description:
Different types of integrated circuit devices may have programmable resources. While an application specific integrated circuit (ASIC) having programmable resources, other devices comprise dedicated programmable logic devices (PLDs). One type of PLD is the Complex Programmable Logic Device (CPLD). A CPLD includes two or more function blocks that are connected together and to input/output (I/O) resources by an interconnect switch matrix, and may include a two-level AND/OR structure similar to that used in a Programmable Logic Array (PLA) or a Programmable Array Logic (PAL) device. Another type of PLD is a field programmable gate array (FPGA). In a typical FPGA, an array of configurable logic blocks (CLBs) is coupled to programmable input/output blocks (IOBs). The CLBs and IOBs are interconnected by a hierarchy of programmable routing resources. These CLBs, IOBs, and programmable routing resources are customized by loading a configuration bitstream into configuration memory cells of the FPGA. For both of these types of programmable logic devices, the functionality of the device is controlled by configuration data bits of a configuration bitstream (or configuration data bits sent during a partial reconfiguration) provided to the device for that purpose.

Many PLDs enable reconfiguration and have used an infrastructure for control of independent reconfigurable elements that consists of "Global" control signals, i.e., signals which are broadcast from a central controller, along with local state elements which can mask the effect of these Global controls, often referred to as Global Signal Control (GSC) bits. The GSC bit infrastructure depends on software which can keep track of the state of every GSC bit on a device. This can be described as a "Global Snapshot" of GSC bit state. Any partial reconfiguration event in the system requires the software to have a Global Snapshot of device programming before and after, as well as knowledge of the state of all the GSC bits on the device. There can be tens of thousands of independent functional blocks and GSC bits on a large reconfigurable device. As a result, the software needed to generate the programming and control information is very large and memory/compute intensive. This type of software often requires hours to run on a powerful computer.

Therefore, there is a need for circuits for and methods of configuring and reconfiguring integrated circuit devices that overcome problems of conventional devices.

<CIT> describes an architecture for information processing devices which allows the construction of low cost, high performance systems for specialized computing applications involving sensor data processing. The reconfigurable processor architecture of the invention uses a programmable logic structure called an Adaptive Logic Processor (ALP). This structure is similar to an extendible field programmable gate array (FPGA) and is optimized for the implementation of program specific pipeline functions, where the function may be changed any number of times during the progress of a computation. A Reconfigurable Pipeline Instruction Control (RPIC) unit is used for loading the pipeline functions into the ALP during the configuration process and coordinating the operations of the ALP with other information processing structures, such as memory, I/O devices, and arithmetic processing units. Multiple components having the reconfigurable architecture of the present invention may be combined to produce high performance parallel processing systems based on the Single Instruction Multiple Data (SIMD) architecture concept.

<CIT> describes systems and methods relating to a programmable circuit. The programmable circuit includes multiple sectors. Each sector includes configurable functional blocks, configurable routing wires, configuration bits for storing configurations for the functional blocks and routing wires, and local control circuitry for interfacing with the configuration bits to configure the sector. The programmable circuit may include global control circuitry for interfacing with the local control circuitry to configure the sector. Each sector may be independently operable and/or operable in parallel with other sectors. Operating the programmable circuit may include using the local control circuitry to interface with the configurations bit and configure the sector. Additionally, operating the programmable circuit may include using the global control circuitry to interface with respective local control circuitry and configure the sector.

<CIT> describes architectures integrated in a generic System on Chip (SoC) and consisting of reconfigurable coprocessors for executing nested program loops whose bodies are expressions of operations performed in a functional unit array in parallel. The data arrays are accessed from one or more system inputs and from an embedded memory array in parallel. The processed data arrays are sent back to the memory array or to system outputs. The architectures enable the acceleration of nested loops compared to execution on a standard processor, where only one operation or datum access can be performed at a time. The invention can be used in a number of applications especially those which involve digital signal processing, such as multimedia and communications. The architectures are used preferably in conjunction with von Neumann processors which are better at implementing control flow. The architectures can be scaled easily in the number of data stream inputs, outputs, embedded memories, functional units and configuration registers. A computational system may entail several general purpose processors and several coprocessors derived from this architectural template. The coprocessors are connected either synchronously or using asynchronous first in first out memories (FIFOs), forming a globally asynchronous locally synchronous system. Each coprocessor can be programmed by tagging and rewriting the nested loops in the original program. The programming tool produces a coprocessor configuration per each nested loop group, which is replaced in the original code with coprocessor input/output operations and control.

<NPL>; discloses a reconfigurable unit/cluster and its reconfiguration using configuration registers.

A circuit for configuring function blocks of an integrated circuit device is defined in claim <NUM>.

A method of configuring function blocks of an integrated circuit device is defined in claim <NUM>.

Advances in integrated circuit technology have made it possible to embed an entire system, such as including multiple processor cores, multiple memory controllers, and high-performance network-on-chip structures, in a single semiconductor chip. This type of chip is commonly referred to as a system-on-chip (SoC). Other SoCs can have different components embedded therein for different applications. Some, which include specialized compute elements, are referred to as Adaptive Compute Acceleration Platforms or ACAPs.

The SoC provides many advantages over traditional processor-based designs. It is an attractive alternative to multi-chip designs because the integration of components into a single device increases overall speed while decreasing size. The SoC is also an attractive alternative to fully customized chips, such as an application specific integrated circuit (ASIC), because ASIC designs tend to have a significantly longer development time and larger development costs. Programmable SoC devices (PSoCs), which include programmable logic, have been developed to obtain the benefits of both programmable logic and SoC. Now the flexibility of these systems has been improved by constructing many of the SoC components out of programmable SoC elements.

One model of reconfiguration control and programming involves a subset of device resources which can be independently programmed and controlled without knowledge of the state of the rest of the resources on the device. In this case the control mechanism is local to each independent functional block. A central controller individually addresses each block requiring control or programming. The programming can be generated by a small piece of software that can run in real time on an embedded processor, for example. This can be referred to as the "Driver" model of partial reconfiguration.

The circuits and methods for configuring function blocks of an integrated circuit device may use an addressable bus for applying control for configuration and partial reconfiguration (PR) of functional blocks which are found in programmable logic devices such as FPGA, Programmable SoC, or ACAP. Unlike fine-grained reconfigurable functions such as LUTs, configurable logic elements (CLEs), interconnect blocks, RAM elements, and the like, which may be better suited to a system of global control with local control masking, the circuits and methods may be well suited for large-grained reconfigurable functions such as high-speed serial transceivers, network-on-chip elements, and memory controllers, for example.

According to various implementations, multiple buses are used for configuring different parts of the integrated circuit device. For example, a distributed configuration memory array bus may be used for configuring fabric (e.g. CLBs, IOBs, and programmable routing resources), an APB or NPI bus may be used for configuring the NoC, XPIO, data transceivers, memory interfaces, for example, and the NoC itself may be used to configure a Math Engine array, for example. Each of these configuration targets may also have unique infrastructure used for control during configuration or partial reconfiguration. In the case of fabric, a Global Signal infrastructure could be used. In the case of NPI-configured blocks, a structure called a Programming Control and Status Register (PCSR) can be used. Each independent functional block that is configured via NPI has a dedicated PCSR - this enables its independence from a configuration and control standpoint. The PCSR has a collection of controls that perform similar functions internally to the NPI-configured blocks that the Global Signals do in configurable fabric. These functions include reset, clock enable, default configuration enable, calibration trigger, tristate (for external IO), as well as status that can be polled to check on device state.

While the specification includes claims defining the features of one or more implementations of the invention that are regarded as novel, it is believed that the circuits and methods will be better understood from a consideration of the description in conjunction with the drawings. While various circuits and methods are disclosed, it is to be understood that the circuits and methods are merely exemplary of the inventive arrangements, which can be embodied in various forms. Therefore, specific structural and functional details disclosed within this specification are not to be interpreted as limiting, but merely as a basis for the claims and as a representative basis for teaching one skilled in the art to variously employ the inventive arrangements in virtually any appropriately detailed structure. Further, the terms and phrases used herein are not intended to be limiting, but rather to provide an understandable description of the circuits and methods.

<FIG> is a block diagram depicting a system-on-chip (SoC) <NUM> according to an example. The SoC <NUM> is an integrated circuit (IC) comprising a processing system <NUM>, a network-on-chip (NoC) <NUM>, a configuration interconnect <NUM>, and one or more programmable logic regions <NUM>. The SoC <NUM> can be coupled to external circuits, such as a nonvolatile memory (NVM) <NUM>. The NVM <NUM> can store data that can be loaded to the SoC <NUM> for configuring the SoC <NUM>, such as configuring the NoC <NUM> and the programmable logic region(s) <NUM>. In general, the processing system <NUM> is connected to the programmable logic region(s) <NUM> through the NoC <NUM> and through the configuration interconnect <NUM>. Configuration can come from several different sources, such as PCIe, Ethernet, CAN, network storage, DDR, etc. The only part that will generally come from NVM is the initial boot image for the Platform Management Controller (PMC) and perhaps the configuration for a complex interface such as PCIe.

The processing system <NUM> can include one or more processor cores. For example, the processing system <NUM> can include a number of ARM-based embedded processor cores. The programmable logic region(s) <NUM> can include any number of configurable fabric block types, such as Configurable Logic Elements (CLEs), block RAMs (BRAM/URAM), digital signal processing blocks (DSP), etc, which may be programmed or configured using the processing system <NUM> through the configuration interconnect <NUM>. The configuration interconnect <NUM> can enable, for example, frame-based programming of the fabric of the programmable logic region(s) <NUM> by a processor core of the processing system <NUM> (such as a platform management controller (PMC) described further below).

<FIG> is a block diagram depicting the NoC <NUM> according to an example. The NoC <NUM> includes NoC master units (NMUs) <NUM>, NoC slave units (NSUs) <NUM>, a network <NUM>, NoC peripheral interconnect (NPI) <NUM>, and register blocks <NUM>. Each NMU <NUM> is an ingress circuit that connects a master circuit to the NoC <NUM>. Each NSU <NUM> is an egress circuit that connects the NoC <NUM> to a slave endpoint circuit. The NMUs <NUM> are connected to the NSUs <NUM> through the network <NUM>. In an example, the network <NUM> includes NoC packet switches <NUM> and routing <NUM> between the NoC packet switches <NUM>. Each NoC packet switch <NUM> performs switching of NoC packets. The NoC packet switches <NUM> are connected to each other and to the NMUs <NUM> and NSUs <NUM> through the routing <NUM> to implement a plurality of physical channels. The NoC packet switches <NUM> also support multiple virtual channels per physical channel. The NPI <NUM> includes circuitry to program the NMUs <NUM>, NSUs <NUM>, and NoC packet switches <NUM>. For example, the NMUs <NUM>, NSUs <NUM>, and NoC packet switches <NUM> can include register blocks <NUM> that determine functionality thereof. The NPI <NUM> includes a peripheral interconnect coupled to the register blocks <NUM> for programming thereof to set functionality. The register blocks <NUM> in the NoC <NUM> support interrupts, QoS, error handling and reporting, transaction control, power management, and address mapping control. The register blocks <NUM> can be initialized in a usable state before being reprogrammed, such as by writing to the register blocks <NUM> using write requests as described below. Configuration data for the NoC <NUM> can be stored in the NVM <NUM> (or any other configuration data source) and provided to the NPI <NUM> for programming the NoC <NUM> and/or other slave endpoint circuits.

<FIG> is a block diagram depicting connections between endpoint circuits through the NoC <NUM> according to an example. In the example, endpoint circuits <NUM> are connected to endpoint circuits <NUM> through the NoC <NUM>. The endpoint circuits <NUM> are master circuits, which are coupled to NMUs <NUM> of the NoC <NUM>. The endpoint circuits <NUM> are slave circuits coupled to the NSUs <NUM> of the NoC <NUM>. Each endpoint circuit <NUM> and <NUM> can be a circuit in the processing system <NUM>, a circuit in a programmable logic region <NUM>, or a circuit in another subsystem. Each endpoint circuit in the programmable logic region <NUM> can be a dedicated circuit (e.g., a hardened circuit) or a circuit configured in programmable logic.

The network <NUM> includes a plurality of physical channels <NUM>. The physical channels <NUM> are implemented by programming the NoC <NUM>. Each physical channel <NUM> includes one or more NoC packet switches <NUM> and associated routing <NUM>. An NMU <NUM> connects with an NSU <NUM> through at least one physical channel <NUM>. A physical channel <NUM> can also have one or more virtual channels <NUM>.

<FIG> is a block diagram depicting connections to a register block <NUM> through the NPI <NUM> according to an example. To connect to a register block <NUM>, the NPI <NUM> includes a root node <NUM>, one or more NPI switches <NUM>, and a protocol block <NUM>. The root node <NUM>, in some examples, resides on a platform management controller (PMC) <NUM>, which may further reside in the processing system <NUM>, although in other examples, the root node <NUM> can be an independent circuit or reside on another system or circuit. The PMC <NUM> may control device configuration, security, power management, and debug operations for example. Generally, the root node <NUM> can packetize a transaction request into a format implemented by the NPI <NUM> and can transmit a memory mapped transaction request to an NPI switch <NUM>, which can further transmit the memory mapped transaction request to other NPI switches <NUM> or to a protocol block <NUM>. The protocol block <NUM> can then translate the memory mapped transaction request into a format implemented by the register block <NUM>. The register block <NUM> is illustrated in <FIG> as an example of a slave endpoint circuit to which the NPI <NUM> can be connected. The NPI <NUM> can further be connected to other slave endpoint circuits, such as programmable components of a memory controller, temperature sensor, clock generator, etc. The NPI <NUM> is generally a tree topology as described by the example of <FIG>.

The PMC <NUM> is further connected to the configuration interconnect <NUM>, which is in turn connected to the programmable logic regions <NUM>. The PMC <NUM> is configured to program the fabric of the programmable logic regions <NUM> through the configuration interconnect <NUM>. The configuration interconnect <NUM> is a delivery mechanism for programming programmable units on the SoC <NUM> that is independent of the delivery mechanism of the NPI <NUM> for programming other programmable units (e.g., slave endpoint circuits) on the SoC <NUM>.

<FIG> illustrates a simplified tree topology of the NPI <NUM> according to an example. Other configurations may be implemented in other examples. The root node <NUM> is the interface between one or more master circuits on the SoC <NUM> and the NPI <NUM>. Ends of branches of the tree topology of the NPI <NUM> are connected to the slave endpoint circuits, such as the register blocks <NUM> in this example.

The root node <NUM> can implement an arbitration scheme, such as a round robin scheme, for handling transaction requests received from the one or more master circuits. The root node <NUM> can further translate between a protocol used by the one or more master circuits and a protocol used by the NPI <NUM>. For example, the one or more master circuits can implement the Advanced eXtensible Interface fourth generation (AXI4) protocol, and the NPI <NUM> can implement an NPI Protocol. Hence, in such examples, the root node <NUM> can translate transaction requests and transaction responses between AXI4 and NPI Protocol.

The NPI switches <NUM> (individually illustrated as NPI switches 408a, 408b, etc.) include one input port and one or multiple (e.g., four) output ports. The respective input port of each NPI switch <NUM> is connected to an output port of a preceding node (e.g., root node <NUM> or NPI switch <NUM>) in the tree topology. For example, the input port of the NPI switch 408a is connected to an output port of the root node <NUM>; the input port of the NPI switch 408b is connected to an output port of the NPI switch 408a; the input port of the NPI switch 408c is connected to an output port of the NPI switch 408b; the input port of the NPI switch 408d is connected to an output port of the NPI switch 408b; and the input port of the NPI switch 408e is connected to an output port of the NPI switch 408b. As indicated, output ports of the NPI switches <NUM> can be connected to input ports of subsequent NPI switches <NUM> or to subsequent protocol blocks <NUM> in the tree topology. In the illustrated example, another output port of the NPI switch 408a is connected to an input port of the protocol block 410a; another output port of the NPI switch 408b is connected to an input port of the protocol block 410b; an output port of the NPI switch 408c is connected to an input port of the protocol block 410c; an output port of the NPI switch 408d is connected to an input port of the protocol block 410d; and respective output ports of the NPI switch 408e are connected to input ports of the protocol blocks 410e and 410f. Each output port of the NPI switches <NUM> can create a subsequent, or downstream, branch of the tree topology of the NPI <NUM>.

As described in a more detailed example below, the upper NPI switch 408a in the tree topology receives transaction requests from the root node <NUM>, and the upper NPI switch 408a and any subsequent NPI switch <NUM> (e.g., NPI switches 408b, 408c, etc.) direct the transaction requests to subsequent branches of the tree topology of the NPI <NUM> according to a destination identification of a slave endpoint circuit (e.g., register block <NUM>) indicated in the respective transaction request.

The protocol blocks <NUM> have an input port connected to an output port of a preceding NPI switch <NUM>, as described previously, and an output port connected to an input port of a subsequent register block <NUM>. In the illustrated example, the output port of the protocol block 410a is connected to the input port of the register block 212a; the output port of the protocol block 410b is connected to the input port of the register block 212b; the output port of the protocol block 410c is connected to the input port of the register block 212c; the output port of the protocol block 410d is connected to the input port of the register block 212d; the output port of the protocol block 410e is connected to the input port of the register block 212e; and the output port of the protocol block 410f is connected to the input port of the register block 212f. The protocol blocks <NUM> can translate the transaction request from the protocol implemented on the NPI <NUM> to a protocol implemented by the respective slave endpoint circuit (e.g., register block <NUM>). In some examples, the protocol blocks <NUM> can translate between NPI Protocol and the Advanced Microcontroller Bus Architecture (AMBA) <NUM> Advanced Peripheral Bus (APB3) protocol.

As indicated in an example below, the connections between various nodes may be described as between input and output ports; however, such connections can permit bi-directional communications. The description of various input ports and output ports are in the contexts of directionality of a transaction request from a master circuit to a slave endpoint circuit, and such designation as an input port or an output port is merely for convenience. As described below, a transaction response to a transaction request can be transmitted from an input port and received at an output port.

In some examples, the NPI Protocol is implemented by the NPI <NUM>. <FIG> illustrates example transaction request and response formats of the NPI Protocol in some examples. <FIG> shows an NPI Protocol write request format <NUM>, an NPI Protocol write response format <NUM>, an NPI Protocol read request format <NUM>, and an NPI Protocol read response format <NUM>. In the illustrated examples, the transaction request and response formats implement a data flow-control digit (flit). A transaction request or response can include any number of data flits, where a last signal indication can indicate whether a subsequent data flit will follow the data flit containing the last signal indication, or the data flit containing the last signal indication is the last data flit of the transaction request or response. In the illustrated example, each of the formats <NUM>, <NUM>, <NUM>, and <NUM> implement one or more data flits that are each thirty-four bits [<NUM>:<NUM>] in length, although other examples, any number of bits may be implemented in a data flit.

The NPI Protocol write request format <NUM> includes at least two data flits, and as illustrated, includes three data flits. The first data flit is a header data flit and is formatted as follows:.

The subsequent data flits are formatted as follows:.

The NPI Protocol write response format <NUM> includes one data flit that is formatted as follows:.

The NPI Protocol read request format <NUM> includes one data flit that is formatted as follows:.

The NPI Protocol read response format <NUM> includes one or more data flits, where each data flit is formatted as follows:.

Some example data flows are described in the context of the tree topology of <FIG> and the NPI Protocol transaction request and response formats of <FIG>, according to some examples. The SoC <NUM> can include, for example, <NUM> slave endpoint circuits to and/or from which the NPI <NUM> can write and/or read, and hence, the NPI <NUM> can be connected to <NUM> register blocks <NUM> or other slave endpoint circuits. The <NUM> slave endpoint circuits (e.g., register blocks <NUM>) is reflected in this example by the nine bits [<NUM>:<NUM>] of the NPI Protocol write request format <NUM> and the NPI Protocol read request format <NUM>. Each register block <NUM> can include a configuration address space, such as 64KB, that is addressable by the destination address, such as bits [<NUM>:<NUM>], of the NPI Protocol write request format <NUM> and the NPI Protocol read request format <NUM>. The configuration address space can be contiguous or non-contiguous for any register block <NUM>. Address space of multiple register blocks <NUM> can be grouped together. The slave endpoint circuits can be, for example, components of the NoC <NUM> (such as the NoC packet switches <NUM>, NMUs <NUM>, and NSUs) or other components in the SoC <NUM> (such as components in a memory controller, clock generator, temperature sensor, etc.).

Each NPI switch <NUM> can perform an auto-discovery scheme to identify which slave endpoint circuit is below or connected to which output port of the respective NPI switch <NUM>, and the root node <NUM> has a mapping from upper address bits to a Destination ID of a slave endpoint circuit. The root node <NUM> is configured to translate an address of a slave endpoint circuit of a transaction request received from a master circuit into a Destination ID and a Destination Address by converting the upper bits of the address of the received transaction request into the Destination ID while maintaining the lower sixteen bits of the address of the received transaction request for the Destination Address. The root node <NUM> translates the received transaction request into an NPI Protocol transaction request that is in the NPI Protocol write request format <NUM> or the NPI Protocol read request format <NUM>. The root node <NUM> then transmits the NPI Protocol transaction request to a first NPI switch <NUM> in the tree topology (e.g., NPI switch 408a). The first NPI switch <NUM> determines on which output port to transmit the NPI Protocol transaction request based on the Destination ID of the NPI Protocol transaction request. If the first NPI switch <NUM> determines that the slave endpoint circuit with the Destination ID is below, for example, the second output port and not the first output port of the first NPI switch <NUM>, the first NPI switch <NUM> transmits the NPI Protocol transaction request on the second output port. Each subsequent NPI switch <NUM> that receives the NPI Protocol transaction request makes a similar determination based on the Destination ID of the NPI Protocol transaction request and transmits the NPI Protocol transaction request on the output port below which is the slave endpoint circuit designated by the Destination ID until the protocol block <NUM> corresponding to that slave endpoint circuit receives the NPI Protocol transaction request. The protocol block <NUM> then translates the NPI Protocol transaction request to the protocol implemented by the slave endpoint circuit and transmits the translated transaction request to the designated slave endpoint circuit.

Once the slave endpoint circuit has received the translated transaction request, the slave endpoint circuit transmits a transaction response back towards the root node <NUM>. The protocol block <NUM> is configured to translate the transaction response of the slave endpoint circuit into an NPI Protocol transaction response that is in the NPI Protocol write response format <NUM> or the NPI Protocol read response format <NUM>. The protocol block <NUM> then transmits the NPI Protocol transaction response to the NPI switch <NUM> to which the input port of the protocol block <NUM> is connected in the tree topology. Each NPI switch <NUM> that receives the NPI Protocol transaction response at an output port then transmits the NPI Protocol transaction response up the tree topology by transmitting the NPI Protocol transaction response through its input port. The NPI Protocol transaction response propagates up the tree topology to the root node <NUM>, which translates the NPI Protocol transaction response to a translated response that is then transmitted to the appropriate master circuit.

The root node <NUM> is further configured to handle multiple transaction requests received from master circuits. If the root node <NUM> receives multiple transaction requests from master circuits simultaneously, the root node <NUM> implements an arbitration scheme, such as a round robin scheme, and serializes the transaction requests accordingly. If the root node <NUM> receives multiple transaction requests from master circuits simultaneously and/or over a short period, the root node <NUM> can serialize and buffer the transaction requests in a buffer, such as a first-in-first-out (FIFO) buffer. The root node <NUM> can translate the transaction requests in a serial manner and can subsequently transmit data flits in bursts, for example. A single data flit may be an NPI Protocol transaction request, or multiple data flits may compose an NPI Protocol transaction request, which may be transmitted in a burst. The root node <NUM> transmits the data flits in a pipelined manner to the first NPI switch <NUM> of the tree topology (e.g., NPI switch 408a).

The NPI switches <NUM> handle the first received NPI Protocol transaction request, with its n number of data flits, as described above. The NPI switches <NUM> will continue to propagate data flits (e.g., of the first and/or subsequent NPI Protocol transaction requests) following the first data flit of the first received NPI Protocol transaction request until: (i) an NPI switch <NUM> determines that a subsequently received NPI Protocol transaction request is to be transmitted on an output port of the NPI switch <NUM> on which the first received NPI Protocol transaction request was not transmitted, and (ii) that NPI switch <NUM> has not received an NPI Protocol transaction response from the slave endpoint circuit to which the first received NPI Protocol transaction request was transmitted. Stated differently, the NPI switches <NUM> do not transmit an NPI Protocol transaction request down a branch of the tree topology different from a branch where another previous NPI Protocol transaction request is currently pending. If an NPI switch <NUM> receives an NPI Protocol transaction request to be transmitted on an output port different from an output port where a previous NPI Protocol transaction request was transmitted and the NPI switch <NUM> has not received an NPI Protocol transaction response for the previous NPI Protocol transaction request, the NPI switch <NUM> blocks further propagation of any data flit from that NPI switch <NUM> and, in some examples, from upstream nodes, until an NPI Protocol transaction response to all respective previous NPI Protocol transaction requests have been received by the NPI switch <NUM>. The NPI switch <NUM> can block propagation of any data flit received by the NPI switch <NUM> and, in some examples, any preceding NPI switch <NUM> and root node <NUM> in the tree topology. Once the appropriate NPI switch <NUM> receives an NPI Protocol transaction response for each previous NPI Protocol transaction request, the NPI switch <NUM> can terminate blocking propagation of any data flit, and propagation of data flits through the NPI switches <NUM> may resume.

To further illustrate the example, assume that a first master circuit transmits a write request for ninety-six bits of data at some address located in register block 212f, and that a second master transmits a read request for sixty-four bits of data at some address located in register block 212a. Further, assume that the root node <NUM> receives the write request one clock cycle before the root node <NUM> receives the read request, or that the root node <NUM> receives the write request and read request simultaneously and determines that the write request has priority over the read request according to the arbitration scheme. Hence, the root node <NUM> handles and serializes the write request before the read request.

The root node <NUM> translates the received write request according to the NPI Protocol write request format <NUM> to an NPI Protocol write request. The NPI Protocol write request is composed of four data flits, where (i) the first header data flit includes the Destination ID of the register block 212f, the Destination Address to be written, the burst length of three data flits (e.g., three write-data data flits), an indication of a write request, and an indication that the data flit is not the last signal; and (ii) the second through fourth data flits include data to be written with the second and third data flits having an indication that the respective data flit is not the last signal, and the fourth data flit having an indication that the data flit is the last signal. The root node <NUM> transmits the header data flit at a clock cycle and the three subsequent write-data data flits at respective subsequent clock cycles. The root node <NUM> places the received write request in a FIFO buffer pending a response to the NPI Protocol write request.

The root node <NUM> then translates the received read request according to the NPI Protocol read request format <NUM> to an NPI Protocol read request. The NPI Protocol read request is composed of one data flit including the Destination ID of the register block 212a, the Destination Address to be read, the burst length of two data flits (e.g., two read-data data flits), an indication of a read request, and an indication that the data flit is the last signal. The root node <NUM> transmits the data flit of the NPI Protocol read request at a clock cycle following the transmission of the last data flit of the NPI Protocol write request. The root node <NUM> places the received read request in the FIFO buffer pending a response to the NPI Protocol read request. Hence, the write request precedes the read request in the FIFO buffer.

Referring back to the NPI Protocol write request, the NPI switch 408a receives the header data flit at the first clock cycle. The NPI switch 408a determines from the header data flit that the Destination ID corresponds with a slave endpoint circuit below a first output port, and hence, the NPI switch 408a transmits the header data flit through the first output port to the NPI switch 408b at the next clock cycle. The NPI switch 408a continues to transmit data flits at respective clock cycles through the first output port until transmitting a data flit that includes an indication that that data flit is the last signal of the NPI Protocol write request. Similarly, the NPI switch 408b receives the header data flit at the second clock cycle. The NPI switch 408b determines from the header data flit that the Destination ID corresponds with a slave endpoint circuit below a third output port, and hence, the NPI switch 408b transmits the header data flit through the third output port to the NPI switch 408e at the next clock cycle. The NPI switch 408b continues to transmit data flits at respective clock cycles through the third output port until transmitting a data flit that includes an indication that that data flit is the last signal of the NPI Protocol write request. Further, the NPI switch 408e receives the header data flit at the third clock cycle. The NPI switch 408e determines from the header data flit that the Destination ID corresponds with a slave endpoint circuit below a second output port, and hence, the NPI switch 408e transmits the header data flit through the second output port to the protocol block 410f at the next clock cycle. The NPI switch 408e continues to transmit data flits at respective clock cycles through the second output port until transmitting a data flit that includes an indication that that data flit is the last signal of the NPI Protocol write request. After four clock cycles, the header data flit of the NPI Protocol write request has been received at the protocol block 410f (which then translates the NPI Protocol write request and forwards the translated write request to the register block 212f); the first write-data data flit has been received at the NPI switch 408e; the second write-data data flit has been received at the NPI switch 408b; and the third write-data data flit has been received at the NPI switch 408a.

The NPI switch 408a receives the data flit of the NPI Protocol read request at the fifth clock cycle, and the data flits of the NPI Protocol write request continue to propagate down the branch of NPI switches 408b, 408e. The NPI switch 408a determines from the data flit of the NPI Protocol read request that the Destination ID corresponds with a slave endpoint circuit below a second output port. However, the NPI switch 408a maintains, e.g., in a buffer, that an NPI Protocol transaction request-the NPI Protocol write request-has been transmitted through the first output port of the NPI switch 408a, and that the NPI switch 408a has not received an NPI Protocol transaction response to that NPI Protocol transaction request. Hence, the NPI switch 408a implements blocking of the propagation of data flits at the NPI switch 408a (e.g., the NPI switch 408a does not transmit the data flit of the NPI Protocol read request). The NPI switch 408a (and in some examples, any upstream NPI switches <NUM> and the root node <NUM>) remains blocked until the NPI switch 408a receives an NPI Protocol write response to the NPI Protocol write request. During this blocked state, NPI switches <NUM> downstream of the NPI switch 408a, such as NPI switches 408b, 408e, can continue propagating data flits, unless a branching and corresponding blocking condition arises at a downstream NPI switch <NUM>, for example.

After seven clock cycles, the four data flits have been transmitted to and received by the protocol block 410f, which translates the NPI Protocol write request into a format that is implemented by the register block 212f. The register block 212f thereafter processes the translated write request and transmits a write response to the translated write request to the protocol block 410f, which translates the write response according to the NPI Protocol write response format <NUM> to an NPI Protocol write response. The NPI Protocol write response is composed of one data flit including an indication whether the writing in the register block 212f was successful and an indication that the data flit is the last signal. The data flit of the NPI Protocol write response can then be transmitted back upstream through the NPI switches 408e, 408b, 408a to the root node <NUM>, such as synchronously or asynchronously.

Upon receipt of the NPI Protocol write response at the NPI switch 408a, the NPI switch 408a terminates blocking transmission of data flits from the NPI switch 408a (and in some examples, any upstream NPI switch 408a and the root node <NUM>). Hence, the NPI switch 408a transmits the data flit of the NPI Protocol read request through the second output port to the protocol block 410a at the next clock cycle. The protocol block 410a translates the NPI Protocol read request into a format that is implemented by the register block 212a. The register block 212a thereafter processes the translated read request and transmits a read response to the translated read request to the protocol block 410a, which translates the read response according to the NPI Protocol read response format <NUM> to an NPI Protocol read response. The NPI Protocol read response is composed of two data flits, with each including read data and an indication whether that the respective data flit is the last signal. The data flits of the NPI Protocol read response can then be transmitted back upstream through the NPI switch 408a to the root node <NUM>, such as synchronously or asynchronously.

As a result of the serialization of NPI Protocol transaction requests by the root node <NUM> and the blocking by NPI switches <NUM> when branching occurs, NPI Protocol transaction responses to NPI Protocol transaction requests are received by the root node <NUM> in the order that the root node <NUM> transmits the NPI Protocol transaction requests to the NPI switches <NUM>. Hence, the root node <NUM> is capable of maintaining a FIFO buffer of transaction requests received from master circuits and transmitting corresponding transaction responses to the master circuits for those transaction requests based on the order of the NPI Protocol transaction responses received by the root node <NUM>. For example, in the above described example, the root node <NUM> transmits a transaction response to the first master circuit based on the received NPI Protocol write response before the root node <NUM> transmits a transaction response to the second master circuit based on the received NPI Protocol read response. Further, due to the serialization and possible blocking of transaction requests, the root node <NUM> may transmit responses to master circuits before transmitting the transaction requests to the tree topology, as described in further detail below.

In some examples, serial NPI Protocol transaction requests to a common slave endpoint circuit may not be blocked by NPI switches <NUM>. In such a situation, the propagation of data flits of the NPI Protocol transaction requests do not create a branch situation at an NPI switch <NUM>. The slave endpoint circuit may process and transmit a transaction response to each NPI Protocol transaction request sequentially received. In some examples, the last NPI switch <NUM> to the slave endpoint circuit may initiate blocking, such as to permit the slave endpoint circuit sufficient time to process the previous transaction request when the slave endpoint circuit does not include a buffer for the transaction requests.

A benefit of implementing an NPI as described in the foregoing examples includes optimizing write and sequential read requests. Suppose a master circuit transmits a write request to write data into a given address of a slave endpoint circuit. The master circuit may thereafter, such as in the immediately following clock cycle, transmit a read request to read the data from that given address of the slave endpoint circuit. The serialization of these two transactions by the root node <NUM>, for example, permits the propagation of the subsequent read request through various NPI switches <NUM> before the root node <NUM> and master circuit receives a response to the write request. Hence, the read request can be propagated to some node or block in the NPI <NUM> before the write request is processed or completed.

<FIG> are flow charts of operations of the root node <NUM> according to some examples. <FIG> is a flow chart for handling a received transaction request by the root node <NUM>, and <FIG> is a flow chart for handling a received transaction response by the root node <NUM>.

Referring to <FIG>, in block <NUM>, the root node <NUM> receives one or more transaction requests from one or more master circuits. In block <NUM>, the root node <NUM> prioritizes the received transaction requests. For example, transaction requests that are received sequentially are prioritized in the order the transaction requests are received, and transaction requests that are received simultaneously (e.g., at a same clock cycle) undergo arbitration according to an arbitration scheme, such as a round robin arbitration scheme, implemented by the root node <NUM> to determine priority of the transaction requests received simultaneously. In block <NUM>, the root node <NUM> serializes the received transaction requests according to the priority assigned to the respective transaction requests in block <NUM>. In block <NUM>, the root node <NUM> translates the received transaction requests to a format implemented by the NPI, such as the NPI Protocol write request format <NUM> and the NPI Protocol read request format <NUM> of <FIG>.

In block <NUM>, optionally, the root node <NUM> buffers the translated transaction requests, for example, in a FIFO buffer. The translated transaction request may be buffered in block <NUM> when the subsequent NPI switch <NUM> of the tree topology has de-asserted a ready to receive signal, as described subsequently. In block <NUM>, the root node <NUM> transmits the translated transaction requests serially to the subsequent NPI switch <NUM> of the tree topology. The root node <NUM> transmits translated transaction requests, e.g., stored in the buffer first in the order that the translated transaction requests were stored (e.g., FIFO), and then, transmits subsequently translated transaction requests. Hence, the root node <NUM> transmits the translated transaction requests serially in the order that the received transaction requests were serialized in block <NUM>. In addition to transmitting the translated transaction requests in a serialized order, the root node transmits one data flit per clock cycle, in some examples. A single data flit can compose a translated transaction request, and/or multiple consecutively transmitted data flits can compose a translated transaction request.

In block <NUM>, the root node <NUM> queues the received transaction requests in the order that the respective corresponding translated transaction requests were transmitted to the subsequent NPI switch <NUM> of the tree topology. The queue can be implemented by pushing to a FIFO buffer, for example. The queue maintains received transaction requests that have been processed and transmitted by the root node <NUM> so the root node <NUM> can send transaction responses back to the corresponding master circuits when the root node <NUM> receives corresponding transaction responses. As described above, serialization and blocking of transaction requests through the tree topology can cause received responses to be in the order that the transaction requests were transmitted, and hence, a received transaction response can correspond to a head entry in a FIFO buffer.

The operations of the root node <NUM> illustrated in <FIG> assume that the subsequent NPI switch <NUM> of the tree topology has asserted a ready to receive signal. In some examples, the NPI switches <NUM> of the tree topology assert a ready to receive signal in a default state, and are capable of de-asserting the ready to receive signal under certain conditions, such as when the subsequent NPI switch <NUM> has insufficient storage space. As described above, if the subsequent NPI switch <NUM> of the tree topology de-asserts the ready to receive signal, the root node <NUM> may buffer translated transaction requests as shown in block <NUM> to thereby continue receiving and processing transaction requests in blocks <NUM>-<NUM>.

Referring to <FIG>, in block <NUM>, the root node <NUM> receives from the subsequent NPI switch <NUM> in the tree topology a transaction response in a format implemented by the NPI. In block <NUM>, the root node <NUM> determines which master circuit corresponds to the received transaction response based on the order of the queued received transaction requests in block <NUM> of <FIG>. For example, the root node <NUM> can pop an entry from the FIFO buffer and determine which master circuit transmitted the transaction request to the root node <NUM> since ordering of the transaction requests and transaction responses can be maintained by serialization and blocking as described above. In block <NUM>, the root node <NUM> transmits a transaction response to the determined master circuit based on the received transaction response. The root node <NUM> can create the transaction response to be in a format implemented by the determined master circuit.

In other examples, the root node <NUM> can transmit a response to a master circuit upon the transaction request received from the master circuit being serialized in block <NUM> of <FIG>. By merging transaction requests by the serialization, ordering of the transaction requests can be maintained. Hence, the root node <NUM> can respond to a master circuit before even transmitting the transaction request to the tree topology. This can avoid delay that could occur due to waiting, by a master circuit, for a response to a transaction request before transmitting another transaction request. For example, a master can send a write request to a location, the root node <NUM> can receive and serialize the write request, and the root node <NUM> can transmit a response to the master circuit before the root node <NUM> transmits the write request to the tree topology. Further, the master circuit, upon receiving the response from the root node <NUM>, can transmit a read request of the same location, even if that read request is transmitted from the master circuit before the root node <NUM> transmits the write request to the location, since the serialization and blocking can ensure that the location is written appropriately before the location is subsequently read.

The order of operations in these flow charts are merely examples, and various operations can be implemented in different logical orders. A person having ordinary skill in the art will readily understand different orders of operations that may be implemented in other examples and any modifications to the flow charts of <FIG> to implement those different orders. For example, the translation of block <NUM> may be implemented at any point before the transmission of the translated transaction request of block <NUM>, and, for example, any of the prioritization of block <NUM>, serialization of block <NUM>, buffering of block <NUM>, and queueing of block <NUM> may be performed on the received transaction request or the translated transaction request. Further, a person having ordinary skill in the art will understand that the operations of <FIG> may be performed in parallel for different transaction requests and transaction responses, such as in pipelined processing. Various buffers may be implemented to accommodate pipelined or other processing, for example.

<FIG> are flow charts of operations of an NPI switch <NUM> according to some examples. <FIG> is a flow chart for handling a received transaction request by an NPI switch <NUM>, and <FIG> is a flow chart for handling a received transaction response by an NPI switch <NUM>.

As described further below, each NPI switch <NUM> includes a <NUM>-to-N buffer that can be implemented to receive and transmit transaction requests. Generally, one or more buffer, e.g., a FIFO buffer, can be implemented to store received transaction requests that are waiting processing and transmission. Further, one or more other buffer, e.g., a FIFO buffer, can be implemented to store transmitted transaction requests that are pending and awaiting a transaction response. The buffer(s) can be implemented to maintain serialization of the transaction requests.

Referring to <FIG>, in block <NUM>, the NPI switch <NUM> determines whether space is available to receive a transaction request. The space available to receive the transaction request can be in a buffer, as stated above, to store a received transaction request as it waits processing and transmission. If space is available, a ready to receive signal is asserted, which may be a default state, as stated above with respect to <FIG>. If space is not available, the NPI switch <NUM> de-asserts the ready to receive signal, which prevents the immediately preceding node (e.g., an NPI switch <NUM> or root node <NUM>) from transmitting a transaction request. Blocks <NUM> and <NUM> may loop until space becomes available to receive a transaction request, at which point, the ready to receive signal may be asserted if the signal was de-asserted.

In block <NUM>, the NPI switch <NUM> receives a transaction request from an immediately preceding node (e.g., an NPI switch <NUM> or root node <NUM>) in the tree topology on the input port of the NPI switch <NUM>. Upon receipt, the NPI switch <NUM> may store the received transaction request in a FIFO buffer for processing and subsequent transmission. In block <NUM>, the NPI switch <NUM> determines through which output port of the NPI switch <NUM> the transaction request is to be transmitted. The NPI switch <NUM> may determine the output port by identifying the output port based on a Destination ID of the slave endpoint circuit in the transaction request as previously described. In block <NUM>, the NPI switch <NUM> determines whether a pending transaction request was previously transmitted on an output port other than the determined output port.

If no pending transaction request was previously transmitted on an output port other than the determined output port, in block <NUM>, the NPI switch <NUM> transmits the transaction request through the determined output port to the immediately subsequent node (e.g., NPI switch <NUM> or protocol block <NUM>), which may include transmitting multiple data flits of the transaction request at respective clock cycles until a data flit containing a last signal indication has been transmitted. Upon transmission, the NPI switch <NUM> may pop the received transaction request from the FIFO buffer in which it was stored and store (or push) the transmitted transaction request in another FIFO buffer. By popping the received transaction request from the FIFO buffer in which it was stored, space may become available in the FIFO buffer for subsequent receipt of another transaction request.

The stored transmitted transaction requests can indicate pending transaction requests that were previously transmitted for the determination in block <NUM>. Referring back to block <NUM>, the determination may refer to the Destination ID of any previously transmitted transaction requests that are stored. If there are no stored transmitted transaction requests, the determination of block <NUM> is negative, and the transaction request is transmitted in block <NUM>. If there are stored transmitted transaction requests and the destination of any of the stored transmitted transaction requests (e.g., a first or last pending request) indicates that those requests were transmitted on an output port of the NPI switch <NUM> that is the same as the determined output port that is determined in block <NUM>, the determination of block <NUM> is negative, and the transaction request is transmitted in block <NUM>. If there are stored transmitted transaction requests and the destination of any of the stored transmitted transaction requests (e.g., a first or last pending request) indicates that those request were transmitted on an output port of the NPI switch <NUM> that is different from the determined output port that is determined in block <NUM>, the determination of block <NUM> is positive, and the transaction request is not transmitted. In such a scenario, the determination of block <NUM> can continue to loop until the determination is negative. The clearing of pending transaction requests, which can cause the determination to become negative, is described in more detail with respect to <FIG>.

A positive determination at block <NUM> indicates a branching condition. By blocking transmission of a transaction request when a branching condition occurs by operation of the determination of block <NUM> and subsequent looping, serialization of transaction requests can be maintained, which in turn, can maintain proper serialization of transaction responses.

Referring to <FIG>, in block <NUM>, the NPI switch <NUM> receives a transaction response on an output port. In block <NUM>, the NPI switch <NUM> clears the earliest pending transaction request. For example, the NPI switch <NUM> can pop the stored transmitted transaction request in the FIFO buffer that is the earliest pending transmitted transaction request. By clearing a pending transmitted transaction request, a branching condition at the NPI switch <NUM> may be removed (e.g., by clearing a condition that results in a positive determination in block <NUM>). In block <NUM>, the NPI switch <NUM> transmits the transaction response to the immediately preceding node (e.g., NPI switch <NUM> or root node <NUM>) on the input port of the NPI switch <NUM>.

In the described example of <FIG>, the NPI switch <NUM> may continue receiving transaction requests when a branching condition occurs as determined in block <NUM>. The received transaction requests can be stored in the appropriate FIFO buffer until no space is available for storing received transaction requests in that FIFO buffer. During the branching condition, no transaction requests are transmitted, and hence, no received transaction requests are popped from the FIFO buffer that stores the received transaction requests. This can lead to the FIFO buffer becoming full and no space being available for storing received transaction requests. Once no space is available for storing received transaction requests, the ready to receive signal is de-asserted in block <NUM>, and the NPI switch <NUM> does not receive further transaction requests from the preceding node. In this example, therefore, transaction requests may be propagated through the tree topology until reaching a branching condition in the tree topology and until available space for storing received transaction requests has become full. This can reduce delay by continuing propagating transaction requests as far as maintaining serialization can permit.

In other examples, once a branching condition occurs in the tree topology, a signal can be asserted or de-asserted that indicates to preceding nodes in the tree topology and to the root node <NUM> that the branching condition has occurred and to block any transmission of transaction requests in the tree topology.

The order of operations in these flow charts are merely examples, and various operations can be implemented in different logical orders. A person having ordinary skill in the art will readily understand different orders of operations that may be implemented in other examples and any modifications to the flow charts of <FIG> to implement those different orders. Further, a person having ordinary skill in the art will understand that the operations of <FIG> may be performed in parallel for different transaction requests and transaction responses, such as in pipelined processing. Various buffers may be implemented to accommodate pipelined or other processing, for example. For example, an NPI switch <NUM> can implement buffers to receive a transaction request in block <NUM> and transmit another transaction request in block <NUM> in a same clock cycle.

<FIG> is a flow chart of an operation of a protocol block <NUM> according to some examples. In block <NUM>, the protocol block <NUM> receives a transaction request in a format implemented by the NPI (e.g., the NPI Protocol write request format <NUM> and NPI Protocol read request format <NUM> of <FIG>) from the preceding NPI switch <NUM> in the tree topology. In block <NUM>, the protocol block <NUM> translates the received transaction request to a format implemented by the slave endpoint circuit (e.g., according to the APB3 protocol). In block <NUM>, the protocol block <NUM> transmits the translated transaction request to the slave endpoint circuit. The translation and transmission of blocks <NUM> and <NUM>, respectively, can be performed on a per data flit basis and/or per transaction request basis. For example, if a transaction request is three data flits, the protocol block <NUM> can implement a buffer for storing received data flits until the entire transaction request is received, and the protocol block <NUM> can then translate the entire transaction request.

In block <NUM>, the protocol block <NUM> receives a transaction response in a format implemented by the slave endpoint circuit from the slave endpoint circuit. In block <NUM>, the protocol block <NUM> translates the received transaction response to a format implemented by the NPI (e.g., the NPI Protocol write response format <NUM> and NPI Protocol read response format <NUM> of <FIG>). In block <NUM>, the protocol block <NUM> transmits the translated transaction response to the preceding NPI switch <NUM> in the tree topology. The protocol block <NUM> can transmit the translated transaction response to the preceding NPI switch <NUM> on a data flit per clock cycle basis, for example.

The order of operations in this flow chart is merely an example, and various operations can be implemented in different logical orders. A person having ordinary skill in the art will readily understand different orders of operations that may be implemented in other examples and any modifications to the flow chart of <FIG> to implement those different orders. Further, a person having ordinary skill in the art will understand that the operations of <FIG> may be performed in parallel for different transaction requests and transaction responses, such as in pipelined processing. Various buffers may be implemented to accommodate pipelined or other processing, for example.

<FIG> is a simplified schematic of at least a portion of the SoC <NUM> according to some examples. The illustrated SoC <NUM> includes an NoC <NUM> interconnected between the processing system <NUM>, programmable logic regions <NUM>, and other IP <NUM> (such as a memory controller <NUM>), for example. The NoC <NUM> includes NMUs <NUM> connected to NSUs <NUM> through interconnected NoC packet switches <NUM> and routing <NUM>, which interconnected NoC packet switches <NUM> and routing <NUM> form the network <NUM> having the physical channels <NUM> and virtual channels <NUM>, for example. The NoC <NUM> further includes the NPI <NUM>, which includes the root node <NUM> (that resides on the PMC <NUM> in the processing system <NUM>), the NPI switches <NUM> in a tree topology, and protocol blocks <NUM> connected to slave endpoint circuits. The protocol blocks <NUM> are not specifically illustrated for simplicity, but may be in the tree topology disposed preceding respective slave endpoint circuits. The slave endpoint circuits, for example, include register blocks <NUM> of the NoC packet switches <NUM>, NMUs <NUM>, NSUs <NUM>, memory controller <NUM>, and/or others.

<FIG> is a block diagram of an integrated circuit providing local control for function blocks according to an example. The circuit <NUM> of <FIG> comprises, in addition to the PLRs <NUM>, a number of other function blocks (as will be described in more detail below), as well as other blocks enabling the configuration and operation of the function blocks. For example, the circuit <NUM> may comprise a data interface subsystem <NUM> having function blocks, such as transceiver (TX/RX) blocks <NUM> and Routing blocks <NUM>. For a particular implementation where the data interface subsystem comprises a PCIe subsystem, the data interface subsystem may also include a CCIX PCIe Module (CPM) <NUM>. An example of an operation of a data interface subsystem, such as a Peripheral Component Interconnect Express (PCIe) subsystem, will be described in more detail in reference to <FIG>. The circuit <NUM> of <FIG> also comprises a memory interface subsystem <NUM>, which may include function blocks, such as for example physical interface blocks (PHY) blocks <NUM> and input/output (IO) blocks <NUM>. An example of an operation of a memory interface subsystem will be described in more detail in reference to <FIG>. A processor system (PS) <NUM>, which may be considered a subsystem of an SoC, may be implemented to enable the operation of the elements of the integrated circuit device. For example, the PS <NUM> may include for example, an Application Processor (APU) core, a real-time processor (RPU) core, and a Processor-Subsystem Manager (PSM).

In addition to NoC <NUM> and NPI <NUM>, which may be implemented generally as NoC <NUM> and NPI <NUM> as described above for example, other elements of the circuit <NUM> are provided to enable the implementation of the circuit. For example, clock routing elements (RCLK) <NUM> enable the routing of clock signals so that data, such as data associated with the data interface subsystem <NUM> or the memory interface subsystem <NUM>, can be transmitted. Configuration frame circuitry (CFRAME) <NUM> is provided to enable reading and writing CFI data frames. High Density IO (HDIO) <NUM>, Multi-Rate Media Access Control (MRMAC) <NUM>, a PCIE-B block <NUM>, and other functional blocks can be embedded between the PLRs.

According to some implementation each sub-system may include of a collection of function blocks. While some elements of the circuit <NUM>, such as the PLRs <NUM>, may be configured by way of a CFI bus and receive configuration control using global signals for example, other elements may be configured through an NPI bus and be controlled using PCSRs embedded in each programmable element configured through the NPI bus. Each defined sub-system that is configured through the NPI bus can be re-configured without any knowledge of the state of the rest of the integrated circuit device. For example, a data interface system comprising a PCIe sub-system may consist of Gigabyte Transceiver (GT) quads (i.e. <NUM>-channels each), dedicated routing blocks which may have pipelining registers, the CPM, and NoC elements. According to some implementations, the CPM may include PCIe logic and direct memory access (DMA) circuits, for example. As will be described in more detail below in reference to <FIG>, PCSRs may be used to provide individual configuration control of the elements of the subsystem. According to other implementations, the memory subsystem <NUM> may be a double data rate (DDR) interface, for example, and include various IO blocks, physical interfaces, a PLL, a DDR Memory Controller, and various NoC elements, as will be described in more detail in reference to <FIG>. While it may be difficult to reconfigure these sub-systems in conventional PLDs without device-wide configuration information, the use of an NPI bus and PCSR infrastructure allows reconfiguration of these subsystems by a firmware driver only having information about resources associated with the subsystem.

According to some implementations, the NPI bus and configuration registers may enable 'burst register programming'. This burst register programming supports fast register-based configuration using a number of related mechanisms including for example: (<NUM>) the ability to send bursts all the way to the endpoint, even though the endpoint interface is not burst capable (i.e. transactions are chopped into individual register accesses) (<NUM>) the grouping of configuration specific registers to simplify writing to the registers using ordered memory access (OMA), and (<NUM>) the ability to turn on/off error reporting for accesses to unpopulated register addresses. Error reporting may be turned off for burst register programming and turned on again for proper error detection.

According to some implementations, device configuration may generally consist of the following stages: programming of registers in the NoC, GTs, memory controllers, etc., via the NPI bus; configuration of fabric blocks (CLE, INT, DSP, BRAM, etc.) through CFI; and startup sequence events (e.g. MMCM lock, DCI calibration, data transceiver calibration, Memory Controller calibration, and fabric startup) controlled through a combination of PCSR writes and Global Signal assertion/de-assertion sequences. The source of the firmware, NPI programming data, and PL frame data may be a flash storage device connected to the device, which may be an FPGA for example, through interface pins in the PMC. Other possible sources of configuration data may include PCIE, DRAM, JTAG, or fabric NoC ports for example.

<FIG> is a block diagram of a portion of a circuit having a memory interface subsystem <NUM> according to an example. The memory interface subsystem <NUM> may implemented as the memory interface subsystem <NUM> of <FIG>. The memory interface subsystem <NUM>, which may be for example a double data rate (DDR) memory interface, may comprise a memory controller <NUM> having a programming control register <NUM>, such as a PCSR. The memory controller <NUM> is coupled to a peripheral interface bus <NUM>, which may be an NPI bus and implemented in NPI <NUM> or NPI1120 as described above for example. A phase-locked loop (PLL) <NUM> is a function block coupled to the NPI bus and comprises a programming control register <NUM>, such as a PCSR register as described above. The memory interface subsystem also comprises interface channels comprising a physical interface (PHY) block <NUM> which is a function block having a programming control register <NUM>, such as a PCSR registers, and a corresponding IO block <NUM> which is a function block having a programming control register <NUM>, such as a PCSR register. According to the implementation of <FIG>, <FIG> sets of PHY block and IO block pairs are shown for the memory controller <NUM>.

However, it should be understood that additional or fewer sets of PHY block and IO block pairs could be associated with a memory controller, and that multiple memory interface subsystems could be implemented, such as for controlling the sets of PHY blocks and IO blocks shown outside the dashed box having the sets of PHY blocks and IO blocks associated with memory controller <NUM>. Using an NPI bus and PCSR infrastructure, it is possible to reconfigure the memory Interface Sub-System without knowing the state of any other device element, where each element of the sub-system can be individually controlled and programmed.

<FIG> is a block diagram of a portion of a circuit having a data transceiver interface <NUM> according to an example. The data transceiver interface <NUM> of <FIG> comprises a data transceiver controller <NUM> having a programming control register <NUM>, such as a PCSR register as described above. Each of a NOC <NUM> (having programming control register <NUM> such as a PCRS register) for the NMUs and a NOC <NUM> (having programming control register <NUM> such as a PCRS register) for the NSUs are coupled to peripheral interface bus <NUM>, such as an NPI bus as described above. The data transceiver interface <NUM> also comprises routing blocks <NUM> which are function blocks having a programming control register <NUM> such as a PCSR register and corresponding data transceivers (TX/RX) <NUM> which are function blocks having a <NUM>. The routing blocks may comprise dedicated routing blocks associated with a data transceiver as shown. That is, the routing blocks may be separate from general interconnect routing in the integrated circuit device and may be used specifically for routing signals in the data transceiver subsystem. While <NUM> sets of routing blocks <NUM> and corresponding data transceiver <NUM> are shown, it should be understood that additional or fewer sets of routing blocks and data transceivers could be associated with a data transceiver controller, and that multiple data transceiver subsystems could be implemented, such as for controlling the sets of routing blocks and data transceivers shown outside the dashed box having the sets of routing blocks and data transceivers associated with data transceiver controller <NUM>. Using the NPI and PCSR infrastructure, it is possible configure or reconfigure the Data Transceiver Sub-System without knowing the state of any other device element, where each element of the sub-system can be individually controlled and programmed.

<FIG> is a block diagram of a portion of a circuit having a function block, such as the function blocks of <FIG> and <FIG> according to an example. More particularly, an endpoint protocol block <NUM>, which may be implemented as described for the protocol blocks <NUM> as described above, is coupled to provide signals to the function block <NUM>. The function block <NUM> comprises a programming register block <NUM> having programming registers <NUM> and a programming control register <NUM>, such as a PCSR. Data from the programming register block <NUM> and control signals from the PCSR are provided by way of a peripheral interface bus <NUM> to a function block core <NUM> to enable operation of the function block. The function block communicates with other elements of the integrated circuit device by way of an interface <NUM>, depending upon the operation and function of the function block. Although the programming control register <NUM> are shown as a part of the programming register block <NUM>, it should be understood that they could be a part of a separate register block.

According to one implementation, the function block receives programming data (also known as configuration data) from the NPI endpoint protocol block <NUM>, where the programming data may be stored in the programming registers of the programming register block <NUM>. Programming data (i.e. Q(N-<NUM>:<NUM> of <FIG>) is provided to a first input of an AND gate <NUM> that may be configured to receive a gating signal (GATEPROG), which enables the gating of the programming data for the function block core <NUM>. The function block core <NUM> comprises a number of control
blocks adapted to receive control signals and to perform a control function associated with the function block core. For example, a status block <NUM> may be configured to receive a status (STATUS) signal. That is, the PCSR may include certain status bits which can be polled by the PMC for example to determine the state of the function block. The status bits may provide information that can be used in the startup sequencing of a function block or for debug purposes. An output logic block <NUM> is configured to receive a disable (ODISABLE) signal, which may be used to disable the function block core. For example, when a programming of a function block is being updated or when a scan is being performed, the output block should drive a constant, neutral value onto its output interface(s). Some blocks with multiple interfaces may require separate control depending on power sequencing or other considerations. For example, NoC NPS blocks may have <NUM> interfaces that are independent. A reset logic block <NUM> is configured to receive an initial state (INITSTATE) signal. The initial state signal initializes a block state, where the block state may be programmable. A hold state (HOLDSTATE) may be provided to the clock enable logic <NUM> and comprises a clock enable for a user visible state. A calibration trigger (STARTCAL) signal may be provided to calibration logic <NUM> to enable a calibration function. Other functions such as test functions may be controlled by the PCSR controls, as set forth in Table <NUM>, can be implanted in the Other Control block <NUM> based upon other control signals that are not provided to one of the blocks <NUM>-<NUM>. The control data of Table <NUM> is a standard group of controls that allowed standard firmware functions to be defined and used during configuration or partial reconfiguration.

The programming registers define the operation of programmable blocks such as routing blocks, data transceivers, physical interface blocks, and IO blocks, for example, and may be reset when the power-on-reset (POR) signal for the function block is asserted.

One major difference between the use of Global Signals (associated with CFI configurations) and PCSRs (associated with NPI configurations) is that with Global Signals, the PR tools must identify all blocks which are "static" (e.g. not PR targets) and all blocks which are part of the Reconfigurable Module (RM), and set all the GSC bits accordingly. With the PCSR structure, the PR tools only need to be aware of the blocks that are in the RM. The static blocks can be ignored, allowing the "driver" model of Partial Reconfiguration of <FIG> to be beneficial.

The NP/Programming Control Status Register (PCSR) structure is a group of registers that contain control bits (PCR) and status bits (PSR) that may be primarily used during the startup or shutdown sequencing of a function block. It should be noted that control and status registers are included in the function blocks, which may receive their programming bits or signals from the NPI bus and perform functions similar to the Global Signals which are used in the Fabric and programmable logic (PL) parts of the integrated circuit devices using CFI programming. In the simplest case, a block may require only some of these control signals. Other blocks may require many control signals. There may also be a Mask register to allow individual control bit writes. The control bits are similar to the Global Signals and are used to ensure that a block behaves correctly while being programmed and can be brought into or out of user operation in a seamless manner.

PCSRs may define the granularity of Partial Reconfiguration. That is, a PCSR may be similar to Global Signal Control (GSC), but for NPI programmed blocks, where the structure controlled by a PCSR is independently reconfigurable. According to some implementations, a block may not disturb any interface to which it is attached until transitioned into user operation. A block may avoid internal contention, oscillation, or enter a high-current state during the programming process. Inputs to a block may toggle randomly during programming and appropriate gating may be used in order to avoid negative block behavior that might result. A block may allow initialization, either to a hardwired reset state or to a programming dependent state, under the control of the programming source. After initialization the block state may remain unaffected by the behavior of inputs other than the programming control inputs. Blocks that drive signals off-chip may tristate all output drivers or, in the case of data transceivers, may drive a neutral signal.

<FIG> is a block diagram of a portion of a circuit for configuring an integrated circuit using global control signals according to an example, such as by using a CFI bus as described above. The CLB of <FIG> comprises a CLE <NUM>, configuration memory (CRAM) <NUM> and gating logic <NUM>. The circuit could comprise the gating logic <NUM>, where a local enable signal, such as mc_gsc, could control the operation of the gating logic circuit <NUM>. Similarly, the configuration memory elements associated with the programmable resources <NUM> comprise the configuration memory <NUM>. Accordingly, the circuit of <FIG> both providing gated local signals to the CLE to control the operation of the CLE, as well as a gated configuration write enable signal which enables the ability to write to the configuration memory of the CLE, such as a LUT memory. The configuration memory receives configuration (CFG) write data to be written to the configuration memory in response to the gated configuration write enable signal. The configuration data stored in the configuration memory <NUM> enables the operation of the CLE, as will be described in more detail below in reference to <FIG>.

The gating logic <NUM> is coupled to receive the global signals at an input <NUM>, a configuration write enable signal at an input <NUM>, and the local enable signal mc_gsc at an input <NUM>. It should be noted that the local enable signal mc_gsc could be a memory bit stored in the configuration memory, as set forth above. The gating logic <NUM> also receives a global enable (en_glob) signal at an input <NUM>. Gated local signals generated at an output <NUM> are coupled to an input <NUM>. Therefore, the global enable signal allows the local enable (mc_gsc) to be ignored, and all of the programmable resources to be reconfigured during a full reconfiguration. The local enable signal allows some configuration memory elements to be reconfigured based upon configuration write data provided during a partial reconfiguration, where a gated reconfiguration write enable signal associated with certain configuration memory cells, such as the configuration memory cells associated with a CLB for example, is generated in response to the local enable signal provided to that CLB.

The GSC bits and logic have the function of selectively "masking" the effects of these Global Signals for functional blocks which are intended to continue functioning during a partial reconfiguration (PR) event. An additional global enable signal (EN_GLOB) allows override of the state of the GSC bits. This signal is asserted during initial configuration in order to allow the Global Signals to be in effect throughout the entire device. The global enable signal and the local enable signal determine whether or not a configurable block will respond to a shutdown sequence, which is a sequence of changes in the logical states of the global signals. While particular global signals are described, it should be understood that different or additional global signals could be implemented, where a particular global signal may be specific to a particular type of circuit block. While the different or additional global signal would be routed to each circuit block of the particular type of circuit block, local reconfiguration signals associated with the different or additional global signal based upon a local enable signal.

<FIG> is block diagram of a configurable logic element that could be implemented in an integrated circuit device, such as the CLE <NUM> of <FIG> according to an example. In particular, <FIG> illustrates in simplified form a configurable logic element, which is an example of Programmable Logic, of a configuration logic block <NUM> of <FIG>. In the implementation of <FIG>, slice M <NUM> includes four lookup tables (LUTMs) 1601A-1601D, each driven by six LUT data input terminals A1-A6, B1-B6, C1-C6, and D1-D6 and each providing two LUT output signals O5 and O6. The O6 output terminals from LUTs 1601A-1601D drive slice output terminals A-D, respectively. The LUT data input signals are supplied by the FPGA interconnect structure via input multiplexers, which may be implemented by programmable interconnect element <NUM>, and the LUT output signals are also supplied to the interconnect structure. Slice M also includes: output select multiplexers 1611A-1611D driving output terminals AMUX-DMUX; multiplexers 1612A-1612D driving the data input terminals of memory elements 1602A-1602D; combinational multiplexers <NUM>, <NUM>, and <NUM>; bounce multiplexer circuits <NUM>-<NUM>; a circuit represented by inverter <NUM> and multiplexer <NUM> (which together provide an optional inversion on the input clock path); and carry logic having multiplexers 1614A-1614D, 1615A-1615D, <NUM>-<NUM> and exclusive OR gates 1613A-1613D. All of these elements are coupled together as shown in <FIG>. Where select inputs are not shown for the multiplexers illustrated in <FIG>, the select inputs are controlled by configuration memory cells. That is, configuration bits of the configuration bitstream stored in configuration memory cells are coupled to the select inputs of the multiplexers to select the correct inputs to the multiplexers. These configuration memory cells, which are well known, are omitted from <FIG> for clarity, as well as from other selected figures herein.

In the pictured implementation, each memory element 1602A-1602D may be programmed to function as a synchronous or asynchronous flip-flop or latch. The selection between synchronous and asynchronous functionality is made for all four memory elements in a slice by programming Sync/Asynch selection circuit <NUM>. When a memory element is programmed so that the S/R (set/reset) input signal provides a set function, the REV input terminal provides the reset function. When the memory element is programmed so that the S/R input signal provides a reset function, the REV input terminal provides the set function. Memory elements 1602A-1602D are clocked by a clock signal CK, which may be provided by a global clock network or by the interconnect structure, for example. Such programmable memory elements are well known in the art of FPGA design. Each memory element 1602A-1602D provides a registered output signal AQ-DQ to the interconnect structure. Because each LUT 1601A-1601D provides two output signals, O5 and O6, the LUT may be configured to function as two <NUM>-input LUTs with five shared input signals (IN1-IN5), or as one <NUM>-input LUT having input signals IN1-IN6.

In the implementation of <FIG>, each LUTM 1601A-1601D may function in any of several modes. When in lookup table mode, each LUT has six data input signals IN1-IN6 that are supplied by the FPGA interconnect structure via input multiplexers. One of <NUM> data values is programmably selected from configuration memory cells based on the values of signals IN1-IN6. When in RAM mode, each LUT functions as a single <NUM>-bit RAM or two <NUM>-bit RAMs with shared addressing. The RAM write data is supplied to the <NUM>-bit RAM via input terminal DI1 (via multiplexers 1617A-1617C for LUTs 1601A-1601C), or to the two <NUM>-bit RAMs via input terminals DI1 and DI2. RAM write operations in the LUT RAMs are controlled by clock signal CK from multiplexer <NUM> and by write enable signal WEN from multiplexer <NUM>, which may selectively pass either the clock enable signal CE or the write enable signal WE. In shift register mode, each LUT functions as two <NUM>-bit shift registers, or with the two <NUM>-bit shift registers coupled in series to create a single <NUM>-bit shift register. The shift-in signals are provided via one or both of input terminals DI1 and DI2. The <NUM>-bit and <NUM>-bit shift out signals may be provided through the LUT output terminals, and the <NUM>-bit shift out signal may also be provided more directly via LUT output terminal MC31. The <NUM>-bit shift out signal MC31 of LUT 1601A may also be provided to the general interconnect structure for shift register chaining, via output select multiplexer 1611D and CLE output terminal DMUX. Accordingly, the circuits and methods set forth above may be implemented in a device such as the device of <FIG>, or any other suitable device.

<FIG> is a flow chart showing a method of configuring function blocks of an integrated circuit device according to an example. A peripheral interface bus, such as an NPI bus as described above, is coupled to a processing system at a block <NUM>. A function block, such as a function block as described in <FIG>, is coupled to the peripheral interface at a block <NUM>. Programming registers and programming control registers, such as the programming registers and control registers as described in <FIG>, are provided in the function block at a block <NUM>. Programming data is stored in the programming registers, wherein in the programming data determines a functionality of a function block core of the function block at a block <NUM>. Control data is stored in programming control registers of the function block, wherein the control data enables a configuration of the function block core with the programming data at a block <NUM>.

The method may further comprise coupling an endpoint protocol block between the peripheral interface bus and the function block, where the endpoint protocol block transfers a transaction request for the function block into a format implemented by the function block. The method may also comprise enabling, by the processing system, a partial reconfiguration of the function block, wherein signals comprising control and status bits that are used during a startup or shutdown sequence of the function block storing may be stored in programming control registers.

The method may find particular application in a memory controller, wherein the function block comprises a memory controller having a first set of programming registers. Physical interface blocks may be coupled to the peripheral interface bus, wherein the physical interface blocks comprise a second set of programming registers. Input/output blocks may be coupled to the peripheral interface bus, wherein the input/output blocks comprise a third set of programming registers. The method may also find particular application in a data interface controller, wherein the function block may comprise a data interface controller having a first set of programming registers. Routing blocks may be coupled to the peripheral interface bus, wherein the routing blocks comprise a second set of programming registers. TX/RX blocks may also be coupled to the peripheral interface bus, wherein the TX/RX blocks comprise a third set of programming registers.

Claim 1:
A circuit for configuring at least one function block of a plurality of function blocks of an integrated circuit device, the circuit comprising:
a processing system (<NUM>);
a peripheral interface bus, PIB, (<NUM>) coupled to the processing system;
input/output blocks (<NUM>) coupled to the peripheral interface bus, the input/output blocks comprising a first set of programming control registers; and
a plurality of function blocks (<NUM>), wherein at least one function block of the plurality of function blocks is coupled to the PIB, and wherein each of the plurality of function blocks includes programming registers (<NUM>), a second set of programming control registers (<NUM>) and a function block core (<NUM>);
wherein the programming registers (<NUM>) store programming data determining a functionality of the function block core, and the second set of programming control registers store control data comprising controls enabling firmware functions to be defined and used during a configuration of the function block core with the programming data; and
wherein the processing system is configured to perform the configuration using the programming registers (<NUM>) and the second set of programming control registers (<NUM>) of the at least one function block.