Circuit for configuring and partially reconfiguring functional blocks of integrated circuit device and method for configuring and partially reconfiguring functional blocks of integrated circuit device
The described circuit and method enable efficient configuration and reconfiguration of integrated circuit devices by using a peripheral interface bus and local control registers, addressing the computational challenges of managing global signal control bits, thereby improving performance and reducing software requirements.
Patent Information
- Application Number
- JP2025138743
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2019-03-27
- Filing Date
- 2025-08-22
- Publication Date
- 2025-12-23
AI Technical Summary
Existing integrated circuit devices with programmable resources face challenges in efficient configuration and reconfiguration due to the need for large and computation-intensive software to manage global signal control bits, requiring significant computational resources and time.
A circuit and method for configuring functional blocks of integrated circuit devices using a peripheral interface bus and programming registers, enabling local control of functional blocks through a distributed configuration memory array bus, APB or NPI bus, and NoC, with each block having a dedicated Programming Control and Status Register (PCSR) for independent control.
This approach reduces the computational burden and time required for configuration and reconfiguration, allowing for efficient and localized control of functional blocks, optimizing performance and reducing the need for extensive software management.
Smart Images

Figure 2025186265000001_ABST
Abstract
Description
[Technical Field]
[0001] Examples of the present disclosure relate generally to electronic circuits, and more particularly to circuits for configuring functional blocks of integrated circuit devices and methods for configuring functional blocks of integrated circuit devices. [Background technology]
[0002] Various types of integrated circuit devices can have programmable resources. Application-specific integrated circuits (ASICs) have programmable resources, while other devices comprise dedicated programmable logic devices (PLDs). One type of PLD is the complex programmable logic device (CPLD). A CPLD contains two or more functional blocks 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 those used in programmable logic array (PLA) or programmable array logic (PAL) devices. Another type of PLD is the 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 the FPGA's configuration memory cells. For both of these types of programmable logic devices, the functionality of the device is controlled by configuration data bits in a configuration bitstream (or configuration data bits sent during partial reconfiguration) that are provided to the device for control purposes.
[0003] Many PLDs enable reconfiguration and use an infrastructure for control of independent reconfigurable elements consisting of "global" control signals—in other words, signals broadcast from a central controller—along with local state elements, often called global signal control (GSC) bits, that can mask the effects of these global controls. The GSC bit infrastructure relies on software that can track the state of every GSC bit on the device. This can be described as a "global snapshot" of the GSC bit state. Any partial reconfiguration event in the system requires the software to have a global snapshot of the device programming before and after, as well as knowledge of the state of all 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 required to generate the programming and control information is extremely large and memory- and computation-intensive. This type of software often requires many hours to run on a powerful computer.
[0004] Therefore, there is a need for circuits for configuring and reconfiguring integrated circuit devices and methods for configuring and reconfiguring integrated circuit devices that overcome the challenges of conventional devices. Summary of the Invention
[0005] A circuit for configuring a functional block of an integrated circuit device is described, the circuit comprising: a processing system; a peripheral interface bus coupled to the processing system; and a functional block coupled to the peripheral interface bus, the functional block having programming registers and a functional block core, wherein the programming registers store data that determine functionality of the functional block core and comprise programming control registers that enable configuration of the functional block core using the data.
[0006] A method of configuring a functional block of an integrated circuit device is also described, the method comprising coupling a peripheral interface bus to a processing system, coupling a functional block to the peripheral interface bus, providing programming registers and programming control registers in the functional block, storing programming data in the programming registers, where the programming data determines functionality of a functional block core of the functional block, and storing control data in the programming control registers of the functional block, where the control data enables configuration of the functional block core using the programming data. [Brief explanation of the drawings]
[0007] [Figure 1] 1 is a block diagram illustrating a system-on-chip (SoC), according to an example. [Figure 2] 1 is a block diagram illustrating a network-on-chip (NoC), according to an example. [Figure 3] 1 is a block diagram illustrating connections between endpoint circuits through an NoC, according to an example. [Figure 4] 1 is a block diagram illustrating connections to register blocks through an NoC peripheral interconnect (NPI), according to an example. [Figure 5] 1 is a simplified tree topology of an NPI, according to an example. [Figure 6] FIG. 10 illustrates exemplary write and read request and response formats, according to an example. [Figure 7A] 10 is a flowchart of the operation of a root node of an NPI, according to some examples. [Figure 7B] 10 is a flowchart of the operation of a root node of an NPI, according to some examples. [Figure 8A] 10 is a flowchart of the operation of an NPI switch of an NPI, according to some examples. [Figure 8B]10 is a flowchart of the operation of an NPI switch of an NPI, according to some examples. [Figure 9] 10 is a flowchart of the operation of a protocol block of an NPI, according to some examples. [Figure 10] 1 is a simplified diagram of at least a portion of an SoC, according to some examples. [Figure 11] FIG. 1 is a block diagram of an integrated circuit that provides local control for functional blocks, according to an example. [Figure 12] 1 is a block diagram of a portion of a circuit having a memory interface, according to an example. [Figure 13] 1 is a block diagram of a portion of a circuit having a data transceiver interface, according to an example. [Figure 14] FIG. 1 is a block diagram of a circuit having a functional block with a programming control and status register (PCSR), according to an example. [Figure 15] 1 is a block diagram of a portion of a circuit for configuring an integrated circuit using global control signals, according to an example. [Figure 16] FIG. 16 is a block diagram of a configurable logic element that may be implemented in FIG. 15, according to an example. [Figure 17] 1 is a flowchart illustrating a method for configuring functional blocks of an integrated circuit device, according to an example. DETAILED DESCRIPTION OF THE INVENTION
[0008] Advances in integrated circuit technology have made it possible to embed entire systems, including multiple processor cores, multiple memory controllers, and high-performance network-on-chip structures, on a single semiconductor chip. This type of chip is typically called a system-on-chip (SoC). Other SoCs may have different components embedded within them for different applications. Some that include dedicated computational elements are called adaptive compute acceleration platforms, or ACAPs.
[0009] SoCs offer many advantages over older processor-based designs. SoCs are an attractive alternative to multi-chip designs because the integration of components into a single device increases overall speed while decreasing size. SoCs are also an attractive alternative to fully customized chips, such as application-specific integrated circuits (ASICs), because ASIC designs tend to have significantly longer development times and higher development costs. Programmable SoC devices (PSoCs) containing programmable logic have been developed to capture the benefits of both programmable logic and SoCs. Now, the flexibility of these systems has been improved by building many of the SoC building blocks from programmable SoC elements.
[0010] One model of reconfiguration control and programming involves a subset of device resources that 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 that requires control or programming. Programming can be generated by a small piece of software that can run in real time on an embedded processor, for example. This is sometimes called the "driver" model of partial reconfiguration.
[0011] Circuits and methods for configuring functional blocks of an integrated circuit device may use addressable buses to apply controls for configuration and partial reconfiguration (PR) of the functional blocks, such as those found in programmable logic devices, such as FPGAs, programmable SoCs, or ACAPs. Unlike fine-grained reconfigurable functions, such as LUTs, configurable logic elements (CLEs), interconnect blocks, RAM elements, and the like, which may be more suitable for systems of global control with local control masking, the circuits and methods may be suitable for coarse-grained reconfigurable functions, such as, for example, high-speed serial transceivers, network-on-chip elements, and memory controllers.
[0012] According to various implementations, multiple buses are used to configure different portions of the integrated circuit device. For example, a distributed configuration memory array bus may be used to configure the fabric (e.g., CLBs, IOBs, and programmable routing resources), an APB or NPI bus may be used to configure, e.g., the NoC, XPIOs, data transceivers, memory interfaces, and the NoC itself may be used to configure, e.g., the math engine array. Each of these configuration targets may also have a unique infrastructure used for control during configuration or partial reconfiguration. In the case of the fabric, a global signal infrastructure may be used. In the case of NPI-configured blocks, a structure called a Programming Control and Status Register (PCSR) may be used. Each independent functional block configured via the NPI has a dedicated PCSR, which allows for functional block independence from a configuration and control standpoint. The PCSR has a collection of controls that perform similar functions internally to NPI-configured blocks as global signals do in a configurable fabric. These functions include reset, clock enable, default configuration enable, calibration trigger, tristate (for external IO), and status that can be polled to check device state.
[0013] While this specification includes claims defining features of one or more implementations of the invention believed to be 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 should be understood that the circuits and methods are merely exemplary of arrangements of the invention, which may be embodied in various forms. Therefore, the specific structural and functional details disclosed within this specification should not be construed as limiting, but merely as a basis for the claims, and as a representative basis for teaching those skilled in the art to variously employ arrangements of the invention in substantially any appropriately detailed structure. Furthermore, the terms and phrases used herein are not intended to be limiting, but rather to provide an understandable description of the circuits and methods.
[0014] FIG. 1 is a block diagram illustrating a system-on-chip (SoC) 102, according to an example. The SoC 102 is an integrated circuit (IC) that includes a processing system 104, a network-on-chip (NoC) 106, a configuration interconnect 108, and one or more programmable logic regions 110. The SoC 102 may be coupled to external circuitry, such as a non-volatile memory (NVM) 112. The NVM 112 may store data that may be loaded into the SoC 102 to configure the NoC 106 and the programmable logic regions 110, such as to configure the NoC 106 and the programmable logic regions 110. Typically, the processing system 104 is connected to the programmable logic regions 110 through the NoC 106 and through the configuration interconnect 108. Configuration may come from several different sources, such as PCIe, Ethernet, CAN, network storage, DDR, etc. The only parts that will typically come from the NVM are the initial boot image for the platform management controller (PMC) and, in some cases, the configuration for complex interfaces, such as PCIe.
[0015] Processing system 104 may include one or more processor cores. For example, processing system 104 may include several ARM-based embedded processor cores. Programmable logic region 110 may include any number of configurable fabric block types, such as configurable logic elements (CLEs), block RAMs (BRAM / URAM), digital signal processing blocks (DSPs), etc., that may be programmed or configured using processing system 104 through configuration interconnect 108. Configuration interconnect 108 may enable frame-based programming of the fabric of programmable logic region 110 by processor cores of processing system 104 (such as a platform management controller (PMC) described further below), for example.
[0016] FIG. 2 is a block diagram illustrating an example NoC 106. The NoC 106 includes an NoC master unit (NMU) 202, an NoC slave unit (NSU) 204, a network 214, an NoC peripheral interconnect (NPI) 210, and a register block 212. Each NMU 202 is an ingress circuit connecting a master circuit to the NoC 106. Each NSU 204 is an egress circuit connecting the NoC 106 to a slave endpoint circuit. The NMUs 202 are connected to the NSUs 204 through the network 214. In one example, the network 214 includes an NoC packet switch 206 and routing 208 between the NoC packet switches 206. Each NoC packet switch 206 performs NoC packet switching. The NoC packet switches 206 are connected to each other and to the NMUs 202 and NSUs 204 through the routing 208 to implement multiple physical channels. The NoC packet switch 206 also supports multiple virtual channels per physical channel. The NPI 210 includes circuit elements for programming the NMU 202, the NSU 204, and the NoC packet switch 206. For example, the NMU 202, the NSU 204, and the NoC packet switch 206 may include register blocks 212 that determine the functionality of the NMU 202, the NSU 204, and the NoC packet switch 206. The NPI 210 includes a peripheral interconnect coupled to the register blocks 212 for programming the NPI 210 to configure functionality. The register blocks 212 in the NoC 106 support interrupts, QoS, error handling and reporting, transaction control, power management, and address mapping control. The register blocks 212 may be initialized to an enabled state before being reprogrammed, such as by writing to the register blocks 212 using a write request described below. Configuration data for the NoC 106 may be stored in the NVM 112 (or any other configuration data source) and provided to the NPI 210 to program the NoC 106 and / or other slave endpoint circuits.
[0017] 3 is a block diagram illustrating connections between endpoint circuits through NoC 106, according to an example. In this example, endpoint circuit 302 is connected to endpoint circuit 304 through NoC 106. Endpoint circuit 302 is a master circuit coupled to NMU 202 of NoC 106. Endpoint circuit 304 is a slave circuit coupled to NSU 204 of NoC 106. Each endpoint circuit 302 and 304 may be a circuit in processing system 104, a circuit in programmable logic region 110, or a circuit in another subsystem. Each endpoint circuit in programmable logic region 110 may be a dedicated circuit (e.g., a hardened circuit) or a circuit configured in programmable logic.
[0018] The network 214 includes multiple physical channels 306. The physical channels 306 are implemented by programming the NoC 106. Each physical channel 306 includes one or more NoC packet switches 206 and associated routing 208. The NMUs 202 connect to the NSUs 204 through at least one physical channel 306. A physical channel 306 may also have one or more virtual channels 308.
[0019] 4 is a block diagram illustrating a connection to register block 212 through NPI 210, according to an example. To connect to register block 212, NPI 210 includes a root node 404, one or more NPI switches 408, and a protocol block 410. The root node 404 resides on a platform management controller (PMC) 402, which may also reside in processing system 104 in some examples, while in other examples, the root node 404 may be a separate circuit or reside on another system or circuit. The PMC 402 may control, for example, device configuration, security, power management, and debug operations. In general, the root node 404 may packetize transaction requests into a format implemented by NPI 210 and send the memory-mapped transaction requests to NPI switch 408, which may further send the memory-mapped transaction requests to other NPI switches 408 or to protocol block 410. The protocol block 410 can then convert the memory-mapped transaction request into the format implemented by the register block 212. The register block 212 is illustrated in FIG. 4 as an example of a slave endpoint circuit to which the NPI 210 may be connected. The NPI 210 may further be connected to other slave endpoint circuits, such as programmable components such as a memory controller, a temperature sensor, a clock generator, etc. The NPI 210 is generally in a tree topology, as illustrated by the example of FIG. 5.
[0020] PMC 402 is further connected to configuration interconnect 108, which is connected to programmable logic region 110. PMC 402 is configured to program the fabric of programmable logic region 110 through configuration interconnect 108. Configuration interconnect 108 is a push mechanism for programming programmable units on SoC 102 that is separate from the push mechanism of NPI 210 for programming other programmable units (e.g., slave endpoint circuits) on SoC 102.
[0021] 5 illustrates a simplified tree topology of the NPI 210, according to an example. Other configurations may be implemented in other examples. The root node 404 is the interface between the NPI 210 and one or more master circuits on the SoC 102. The ends of the branches of the NPI 210's tree topology are connected to slave endpoint circuits, such as register blocks 212 in this example.
[0022] The root node 404 can implement an arbitration scheme, such as a round-robin scheme, for handling transaction requests received from one or more master circuits. The root node 404 can also translate between the protocol used by the one or more master circuits and the protocol used by the NPI 210. For example, the one or more master circuits can implement the Advanced Extensible Interface Fourth Generation (AXI4) protocol, and the NPI 210 can implement the NPI protocol. Thus, in such an example, the root node 404 can translate transaction requests and transaction responses between the AXI4 and NPI protocols.
[0023] The NPI switches 408 (individually illustrated as NPI switches 408a, 408b, etc.) include one input port and one or more (e.g., four) output ports. The respective input ports of each NPI switch 408 are connected to the output ports of the preceding node (e.g., root node 404 or NPI switch 408) in the tree topology. For example, the input port of NPI switch 408a is connected to the output port of root node 404, the input port of NPI switch 408b is connected to the output port of NPI switch 408a, the input port of NPI switch 408c is connected to the output port of NPI switch 408b, the input port of NPI switch 408d is connected to the output port of NPI switch 408b, and the input port of NPI switch 408e is connected to the output port of NPI switch 408b. As indicated, the output ports of NPI switches 408 can be connected to the input ports of subsequent NPI switches 408 or to subsequent protocol blocks 410 in the tree topology. In the illustrated example, another output port of NPI switch 408a is connected to an input port of protocol block 410a, another output port of NPI switch 408b is connected to an input port of protocol block 410b, an output port of NPI switch 408c is connected to an input port of protocol block 410c, an output port of NPI switch 408d is connected to an input port of protocol block 410d, and each output port of NPI switch 408e is connected to an input port of protocol blocks 410e and 410f. Each output port of NPI switch 408 can create a subsequent, or downstream, branch of the tree topology of NPI 210.
[0024] As described in a more detailed example below, the upper NPI switch 408a in the tree topology receives a transaction request from the root node 404, and the upper NPI switch 408a and subsequent NPI switches 408 (e.g., NPI switches 408b, 408c, etc.) direct the transaction request to subsequent branches of the tree topology of the NPI 210 according to the destination identification information of the slave endpoint circuit (e.g., register block 212) pointed to in each transaction request.
[0025] As previously described, protocol block 410 has an input port connected to the output port of the preceding NPI switch 408 and an output port connected to the input port of the succeeding register block 212. In the illustrated example, the output port of protocol block 410a is connected to the input port of register block 212a, the output port of protocol block 410b is connected to the input port of register block 212b, the output port of protocol block 410c is connected to the input port of register block 212c, the output port of protocol block 410d is connected to the input port of register block 212d, the output port of protocol block 410e is connected to the input port of register block 212e, and the output port of protocol block 410f is connected to the input port of register block 212f. Protocol block 410 can translate transaction requests from the protocol implemented on NPI 210 to the protocol implemented by the respective slave endpoint circuit (e.g., register block 212). In some examples, the protocol block 410 can convert between the NPI protocol and the Advanced Microcontroller Bus Architecture (AMBA) 3 Advanced Peripheral Bus (APB3) protocol.
[0026] As indicated in the examples below, connections between various nodes may be described as being between input ports and output ports, although such connections may enable bidirectional communication. The description of the various input and output ports is in the context of the directionality of transaction requests from a master circuit to a slave endpoint circuit, and such designation as an input port or an output port is for convenience only. As described below, transaction responses to transaction requests may be sent from input ports and received at output ports.
[0027] In some examples, the NPI protocol is implemented by NPI 210. FIG. 6 illustrates exemplary transaction request and response formats of the NPI protocol in some examples. FIG. 6 shows an NPI protocol write request format 602, an NPI protocol write response format 604, an NPI protocol read request format 606, and an NPI protocol read response format 608. In the illustrated example, the transaction request and response formats implement data flow control digits (flits). 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 whether the data flit containing the last signal indication is the last data flit of the transaction request or response. In the illustrated example, formats 602, 604, 606, and 608 each implement one or more data flits, each 34 bits [33:0] in length, although in other examples, any number of bits can be implemented in a data flit.
[0028] The NPI protocol write request format 602 includes at least two data flits, and as shown includes three data flits. The first data flit is a header data flit and is formatted as follows: The two least significant bits [1:0] are reserved or don't care. Bits [15:2] - Destination Address Bits [24:16] - Slave destination identification (ID) Bit
[28] - Reserved or Don't Care Bits [30:27] - Burst length (BLEN) of the data flit containing the data to be written Bit
[31] - Read / Write Indication (Write) Bit
[32] - Reserved or Don't Care Most significant bit
[33] - Last signal indication (0 if at least one subsequent data flit follows)
[0029] The subsequent data flits are formatted as follows: The lowest 32 bits [31:0] - the data to be written Bit
[32] - Reserved or Don't Care Most significant bit
[33] - Last signal indication (0 if at least one subsequent data flit follows, or 1 if this is the last data flit)
[0030] The NPI protocol write response format 604 contains one data flit formatted as follows: The lowest 32 bits [31:0] are reserved or don't care. Bit
[32] - Response (1 for success, 0 for error) Most significant bit
[33] - Last signal indication (1 for last data flit)
[0031] The NPI protocol read request format 606 contains one data flit formatted as follows: The two least significant bits [1:0] are reserved or don't care. Bits [15:2] - Destination Address Bits [24:16] - Slave Destination ID Bit
[28] - Reserved or Don't Care Bits [30:27] - Burst length (BLEN) of the data flit containing the data to be written Bit
[31] - Read / Write Indication (Read) Bit
[32] - Reserved or Don't Care Most significant bit
[33] - Last signal indication (1 for last data flit)
[0032] The NPI protocol read response format 608 includes one or more data flits, where each data flit is formatted as follows: The lowest 32 bits [31:0] - the data to be read Bit
[32] - Response (1 for success, 0 for error) Most significant bit
[33] - Last signal indication (0 if at least one subsequent data flit follows, or 1 if this is the last data flit)
[0033] Some exemplary data flows are described in the context of the tree topology of FIG. 5 and the NPI protocol transaction request and response formats of FIG. 6 , according to some examples. SoC 102 can include, for example, 512 slave endpoint circuits to which NPI 210 can write and / or read; thus, NPI 210 can be connected to 512 register blocks 212 or other slave endpoint circuits. The 512 slave endpoint circuits (e.g., register blocks 212) are reflected in this example by nine bits [24:16] of NPI protocol write request format 602 and NPI protocol read request format 606. Each register block 212 can include a configuration address space, such as 64 KB, that is addressable by a destination address, such as bits [15:2], of NPI protocol write request format 602 and NPI protocol read request format 606. The configuration address space can be contiguous or non-contiguous for any register block 212. The address spaces of multiple register blocks 212 may be grouped together. The slave endpoint circuitry may be, for example, a component of the NoC 106 (such as the NoC packet switch 206, the NMU 202, and the NSU) or another component in the SoC 102 (such as a component in a memory controller, a clock generator, a temperature sensor, etc.).
[0034] Each NPI switch 408 can implement an auto-discovery scheme to identify which slave endpoint circuit is beneath it or connected to which output port of the respective NPI switch 408, and the root node 404 has a mapping from upper address bits to slave endpoint circuit destination IDs. The root node 404 is configured to translate the address of the slave endpoint circuit of a transaction request received from a master circuit into a destination ID and destination address by converting the upper bits of the address of the received transaction request into a destination ID while retaining the lower 16 bits of the address of the received transaction request for the destination address. The root node 404 translates the received transaction request into an NPI protocol transaction request in NPI protocol write request format 602 or NPI protocol read request format 606. The root node 404 then transmits the NPI protocol transaction request to the first NPI switch 408 in the tree topology (e.g., NPI switch 408a). The first NPI switch 408 determines which output port to send the NPI protocol transaction request to based on the destination ID of the NPI protocol transaction request. If the first NPI switch 408 determines that the slave endpoint circuit with the destination ID is located lower, for example, on the second output port of the first NPI switch 408 rather than the first output port, the first NPI switch 408 sends the NPI protocol transaction request on the second output port. Each subsequent NPI switch 408 that receives the NPI protocol transaction request makes a similar decision based on the destination ID of the NPI protocol transaction request and sends the NPI protocol transaction request on the lower output port that is the slave endpoint circuit specified by the destination ID, until the protocol block 410 corresponding to that slave endpoint circuit receives the NPI protocol transaction request.The protocol block 410 then converts the NPI protocol transaction request to the protocol implemented by the slave endpoint circuit and sends the converted transaction request to the designated slave endpoint circuit.
[0035] When the slave endpoint circuit receives the converted transaction request, the slave endpoint circuit transmits a transaction response back toward the root node 404. The protocol block 410 is configured to convert the slave endpoint circuit's transaction response into an NPI protocol transaction response in either the NPI protocol write response format 604 or the NPI protocol read response format 608. The protocol block 410 then transmits the NPI protocol transaction response to the NPI switch 408 to which the input port of the protocol block 410 is connected in the tree topology. Each NPI switch 408 that receives the NPI protocol transaction response at its output port then transmits the NPI protocol transaction response up the tree topology by transmitting the NPI protocol transaction response through the input port of the NPI switch 408. The NPI protocol transaction response propagates up the tree topology toward the root node 404, which converts the NPI protocol transaction response into a converted response that is then sent to the appropriate master circuit.
[0036] The root node 404 is further configured to handle multiple transaction requests received from the master circuit. If the root node 404 receives multiple transaction requests from the master circuit simultaneously, the root node 404 implements an arbitration scheme, such as a round-robin scheme, and serializes the transaction requests accordingly. If the root node 404 receives multiple transaction requests from the master circuit simultaneously and / or within a short period of time, the root node 404 can serialize and buffer the transaction requests in a buffer, such as a first-in, first-out (FIFO) buffer. The root node 404 can convert the transaction requests in a serial manner and then transmit data flits, for example, in bursts. A single data flit can be an NPI protocol transaction request, or multiple data flits can constitute an NPI protocol transaction request that can be transmitted in bursts. The root node 404 transmits the data flits in a pipelined manner to the first NPI switch 408 (e.g., NPI switch 408a) of the tree topology.
[0037] The NPI switch 408 handles the first received NPI protocol transaction request using the n data flits of the first received NPI protocol transaction request, as described above. The NPI switch 408 will continue to propagate data flits following the first data flit of the first received NPI protocol transaction request (e.g., of the first and / or subsequent NPI protocol transaction requests) until (i) the NPI switch 408 determines that a subsequently received NPI protocol transaction request should be transmitted on an output port of the NPI switch 408 over which the first received NPI protocol transaction request was not transmitted, and (ii) the NPI switch 408 no longer receives an NPI protocol transaction response from the slave endpoint circuit to which the first received NPI protocol transaction request was transmitted. In other words, the NPI switch 408 will not transmit an NPI protocol transaction request down a branch of the tree topology different from the branch on which another previous NPI protocol transaction request is currently pending. If the NPI switch 408 receives an NPI protocol transaction request to be sent on an output port different from the output port on which the previous NPI protocol transaction request was sent, and the NPI switch 408 has not received an NPI protocol transaction response to the previous NPI protocol transaction request, the NPI switch 408 blocks further propagation of any data flits from the NPI switch 408, and in some examples, from upstream nodes, until an NPI protocol transaction response to every respective previous NPI protocol transaction request is received by the NPI switch 408. The NPI switch 408 can block propagation of data flits received by the NPI switch 408, and in some examples, by the preceding NPI switch 408 in the tree topology and the root node 404.When the appropriate NPI switch 408 receives an NPI protocol transaction response for each previous NPI protocol transaction request, the NPI switch 408 can end blocking the propagation of data flits, and propagation of data flits through the NPI switch 408 can resume.
[0038] To further illustrate the example, assume that a first master circuit sends a write request for 96 bits of data at some address in register block 212f, and a second master sends a read request for 64 bits of data at some address in register block 212a. Further assume that root node 404 receives the write request one clock cycle before root node 404 receives the read request, or that root node 404 receives the write request and the read request simultaneously and, according to an arbitration scheme, determines that the write request takes priority over the read request. Thus, root node 404 handles and serializes the write request before the read request.
[0039] The root node 404 converts the received write request into an NPI protocol write request according to the NPI protocol write request format 602. The NPI protocol write request consists of four data flits, where (i) the first header data flit includes a destination ID of the register block 212f, a destination address to be written, a burst length of three data flits (e.g., three write data flits), an indication of the write request, and an indication that the data flit is not the last signal, and (ii) the second, third, and fourth data flits include data to be written, with the second and third data flits each having an indication that the 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 404 transmits the header data flit in a clock cycle and transmits three subsequent write data flits in each subsequent clock cycle. The root node 404 places received write requests in a FIFO buffer until a response to the NPI protocol write request is received.
[0040] The root node 404 then converts the received read request into an NPI protocol read request according to the NPI protocol read request format 606. The NPI protocol read request consists of one data flit including the destination ID of the register block 212a, the destination address to be read, a burst length of two data flits (e.g., two read data flits), an indication of the read request, and an indication that the data flit is the last signal. The root node 404 transmits the data flit of the NPI protocol read request in the clock cycle following the transmission of the last data flit of the NPI protocol write request. The root node 404 places the received read request in a FIFO buffer until a response to the NPI protocol read request is received. Thus, the write request precedes the read request in the FIFO buffer.
[0041] Referring again to the NPI protocol write request, NPI switch 408a receives the header data flit in the first clock cycle. From the header data flit, NPI switch 408a determines that the destination ID corresponds to the slave endpoint circuit below the first output port, and therefore, NPI switch 408a transmits the header data flit to NPI switch 408b through the first output port in the next clock cycle. NPI switch 408a continues transmitting data flits through the first output port in each clock cycle until it transmits a data flit including an indication that the data flit is the final signal of the NPI protocol write request. Similarly, NPI switch 408b receives the header data flit in the second clock cycle. From the header data flit, NPI switch 408b determines that the destination ID corresponds to the slave endpoint circuit below the third output port, and therefore, NPI switch 408b transmits the header data flit to NPI switch 408e through the third output port in the next clock cycle. The NPI switch 408b continues to send data flits through the third output port in each clock cycle until it sends a data flit including an indication that the data flit is the last signal of the NPI protocol write request. Furthermore, the NPI switch 408e receives a header data flit in the third clock cycle. The NPI switch 408e determines from the header data flit that the destination ID corresponds to the lower slave endpoint circuit of the second output port, and therefore sends the header data flit through the second output port to the protocol block 410f in the next clock cycle. The NPI switch 408e continues to send data flits through the second output port in each clock cycle until it sends a data flit including an indication that the 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 is received at protocol block 410f (which then converts the NPI protocol write request and forwards the converted write request to register block 212f), the first write data data flit is received at NPI switch 408e, the second write data data flit is received at NPI switch 408b, and the third write data data flit is received at NPI switch 408a.
[0042] The NPI switch 408a receives the data flit of the NPI protocol read request in the fifth clock cycle, and the data flit of the NPI protocol write request continues to propagate down the branches of the NPI switches 408b and 408e. The NPI switch 408a determines from the data flit of the NPI protocol read request that the destination ID corresponds to the slave endpoint circuit below the second output port. However, the NPI switch 408a maintains, for example, in a buffer, that the NPI protocol transaction request, i.e., the NPI protocol write request, was sent through the first output port of the NPI switch 408a and that the NPI switch 408a did not receive an NPI protocol transaction response to the NPI protocol transaction request. Therefore, the NPI switch 408a implements a block on the propagation of the data flit in the NPI switch 408a (e.g., the NPI switch 408a does not send the data flit of the NPI protocol read request). The NPI switch 408a (and in some examples, the upstream NPI switch 408 and the root node 404) remains blocked until the NPI switch 408a receives an NPI protocol write response to the NPI protocol write request. During this blocked state, the NPI switches 408 downstream of the NPI switch 408a, such as the NPI switches 408b and 408e, can continue to propagate data flits unless, for example, a fork and corresponding blocking condition occurs in the downstream NPI switch 408.
[0043] After seven clock cycles, the four data flits are sent to and received by protocol block 410f, which converts the NPI protocol write request into the format implemented by register block 212f. Register block 212f then processes the converted write request and sends a write response for the converted write request to protocol block 410f, which converts the write response into an NPI protocol write response according to NPI protocol write response format 604. The NPI protocol write response consists of one data flit that includes an indication of whether the write in register block 212f was successful and an indication that the data flit is the last signal. The data flit in the NPI protocol write response can then be sent upstream through NPI switches 408e, 408b, and 408a back to the root node 404, such as synchronously or asynchronously.
[0044] Upon receiving the NPI protocol write response at the NPI switch 408a, the NPI switch 408a finishes blocking the transmission of data flits from the NPI switch 408a (and in some examples, the upstream NPI switch 408a and the root node 404). Thus, the NPI switch 408a transmits the data flit of the NPI protocol read request to the protocol block 410a through its second output port in the next clock cycle. The protocol block 410a converts the NPI protocol read request into a format implemented by the register block 212a. The register block 212a then processes the converted read request and transmits a read response for the converted read request to the protocol block 410a, which converts the read response into an NPI protocol read response according to the NPI protocol read response format 608. The NPI protocol read response consists of two data flits, each containing read data and an indication of whether the respective data flit is the last signal. The data flits of the NPI protocol read response may then be transmitted upstream through the NPI switch 408a back to the root node 404, such as synchronously or asynchronously.
[0045] As a result of the serialization of NPI protocol transaction requests by the root node 404 and the possible blocking by the NPI switch 408 when a fork occurs, NPI protocol transaction responses to NPI protocol transaction requests are received by the root node 404 in the order in which the root node 404 sent the NPI protocol transaction requests to the NPI switch 408. Thus, the root node 404 can maintain a FIFO buffer of transaction requests received from master circuits and send corresponding transaction responses to master circuits for those transaction requests based on the order of the NPI protocol transaction responses received by the root node 404. For example, in the example described above, the root node 404 sends a transaction response to a first master circuit based on a received NPI protocol write response before the root node 404 sends a transaction response to a second master circuit based on a received NPI protocol read response. Furthermore, due to the serialization and possible blocking of transaction requests, the root node 404 may send a response to a master circuit before sending a transaction request up the tree topology, as described in further detail below.
[0046] In some examples, serial NPI protocol transaction requests to a common slave endpoint circuit may not be blocked by the NPI switch 408. In such a situation, propagation of data flits of the NPI protocol transaction request does not create a branching condition in the NPI switch 408. The slave endpoint circuit may process and transmit a transaction response for each successively received NPI protocol transaction request. In some examples, the last NPI switch 408 to a slave endpoint circuit may initiate a block when the slave endpoint circuit does not contain a buffer for the transaction request, such as to allow the slave endpoint circuit sufficient time to process a previous transaction request.
[0047] Benefits of implementing the NPI as described in the above example include optimizing write and consecutive read requests. Assume that a master circuit sends a write request to write data to a given address of a slave endpoint circuit. The master circuit may subsequently, such as in an immediately following clock cycle, send a read request to read data from that given address of the slave endpoint circuit. Serialization of these two transactions by the root node 404 allows, for example, the propagation of a subsequent read request through the various NPI switches 408 before the root node 404 and master circuit receive a response to the write request. Thus, the read request may be propagated to some node or block in the NPI 210 before the write request is processed or completed.
[0048] 7A and 7B are flowcharts of the operation of the root node 404, according to some examples. Figure 7A is a flowchart for handling a received transaction request by the root node 404, and Figure 7B is a flowchart for handling a received transaction response by the root node 404.
[0049] 7A , at block 702, the root node 404 receives one or more transaction requests from one or more master circuits. At block 704, the root node 404 prioritizes the received transaction requests. For example, consecutively received transaction requests are prioritized in the order in which the transaction requests are received, and transaction requests received simultaneously (e.g., in the same clock cycle) are arbitrated according to an arbitration scheme, such as a round-robin arbitration scheme, implemented by the root node 404 to determine the priority of the simultaneously received transaction requests. At block 706, the root node 404 serializes the received transaction requests according to the priority assigned to each transaction request at block 704. At block 708, the root node 404 converts the received transaction requests into a format implemented by the NPI, such as the NPI protocol write request format 602 and the NPI protocol read request format 606 of FIG. 6 .
[0050] In block 710, optionally, the root node 404 buffers the converted transaction request, for example, in a FIFO buffer. The converted transaction request may be buffered in block 710 when a subsequent NPI switch 408 in the tree topology deasserts its ready to receive signal, as described later. In block 712, the root node 404 transmits the converted transaction request serially to the subsequent NPI switch 408 in the tree topology. The root node 404, for example, first transmits the converted transaction request stored in the buffer in the order in which the converted transaction request was stored (e.g., FIFO), and then transmits the converted transaction request thereafter. Thus, the root node 404 transmits the converted transaction request serially in the order in which the received transaction request was serialized in block 706. In addition to transmitting the converted transaction request in serialized order, the root node, in some examples, transmits one data flit per clock cycle. A single data flit may constitute a transformed transaction request, and / or multiple consecutively transmitted data flits may constitute a transformed transaction request.
[0051] At block 714, the root node 404 queues the received transaction requests in the order in which each corresponding converted transaction request was sent to the subsequent NPI switch 408 in the tree topology. The queue may be implemented, for example, by pushing to a FIFO buffer. The queue maintains the received transaction requests that have been processed and sent by the root node 404, so that the root node 404 can send the transaction responses back to the corresponding master circuit when the root node 404 receives the corresponding transaction response. As described above, serialization and interception of transaction requests across the tree topology can cause the received responses to be in the order in which the transaction requests were sent, and thus the received transaction response can correspond to the head entry in the FIFO buffer.
[0052] 7A assumes that a subsequent NPI switch 408 in the tree topology has asserted its readiness to receive a signal. In some examples, an NPI switch 408 in the tree topology may assert its readiness to receive a signal in a default state and deassert its readiness to receive a signal under some conditions, such as when a subsequent NPI switch 408 has insufficient storage space. As described above, if a subsequent NPI switch 408 in the tree topology deasserts its readiness to receive a signal, the root node 404 may buffer the converted transaction request, as shown in block 710, thereby continuing to receive and process transaction requests in blocks 702-708.
[0053] Referring to FIG. 7B , in block 752, the root node 404 receives a transaction response in a format implemented by the NPI from a subsequent NPI switch 408 in the tree topology. In block 754, the root node 404 determines which master circuit corresponds to the received transaction response based on the order of the queued received transaction requests in block 714 of FIG. 7A . For example, the root node 404 can pop an entry from a FIFO buffer and determine which master circuit sent the transaction request to the root node 404, since the ordering of the transaction requests and transaction responses can be maintained by the serialization and blocking described above. In block 756, the root node 404 sends the transaction response to the determined master circuit based on the received transaction response. The root node 404 can create the transaction response to be in a format implemented by the determined master circuit.
[0054] In another example, the root node 404 can send a response to the master circuit once a transaction request received from the master circuit is serialized in block 706 of FIG. 7A . By merging transaction requests through serialization, the ordering of transaction requests can be maintained. Thus, the root node 404 can respond to the master circuit even before sending the transaction request to the tree topology. This can avoid delays that can occur due to waiting for a response to a transaction request before sending another transaction request by the master circuit. For example, a master can send a write request to a location, the root node 404 can receive and serialize the write request, and the root node 404 can send a response to the master circuit before sending the write request to the tree topology. Furthermore, because serialization and interception can ensure that a location is properly written before it is subsequently read, once the master circuit receives a response from the root node 404, it can send a read request for the same location, even if that read request is sent from the master circuit before the root node 404 sends the write request to the location.
[0055] The order of operations in these flowcharts is merely exemplary, and various operations may be implemented in a different logical order. Those skilled in the art will readily recognize different orders of operations that may be implemented in other examples, as well as modifications to the flowcharts of FIGS. 7A and 7B to implement those different orders. For example, the conversion of block 708 may be implemented at any time before the transmission of the converted transaction request of block 712, and, for example, any of the prioritization of block 704, the serialization of block 706, the buffering of block 710, and the queuing of block 714 may be performed on a received or converted transaction request. Furthermore, those skilled in the art will understand that the operations of FIGS. 7A and 7B may be performed in parallel for different transaction requests and transaction responses, such as in pipeline processing. Various buffers may be implemented, for example, to accommodate pipeline or other processing.
[0056] 8A and 8B are flowcharts of the operation of NPI switch 408, according to some examples. Figure 8A is a flowchart for handling a received transaction request by NPI switch 408, and Figure 8B is a flowchart for handling a received transaction response by NPI switch 408.
[0057] As described further below, each NPI switch 408 includes a 1-to-N buffer that may be implemented to receive and transmit transaction requests. Generally, one or more buffers, e.g., FIFO buffers, may be implemented to store received transaction requests awaiting processing and transmission. Additionally, one or more other buffers, e.g., FIFO buffers, may be implemented to store transmitted transaction requests that are pending and awaiting transaction responses. The buffers may be implemented to maintain serialization of transaction requests.
[0058] Referring to FIG. 8A, in block 802, the NPI switch 408 determines whether space is available to receive a transaction request. The available space to receive a transaction request may be in a buffer, as described above, for storing the received transaction request as it awaits processing and transmission. If space is available, the ready to receive signal is asserted, which may be the default state, as described above with respect to FIG. 7A. If space is not available, the NPI switch 408 deasserts the ready to receive signal, which prevents the previous node (e.g., the NPI switch 408 or the root node 404) from sending the transaction request. Blocks 802 and 804 may loop until space is available to receive a transaction request, at which point the ready to receive signal may be asserted if the signal is deasserted.
[0059] In block 806, the NPI switch 408 receives a transaction request from a previous node in the tree topology (e.g., the NPI switch 408 or the root node 404) on an input port of the NPI switch 408. Upon receipt, the NPI switch 408 may store the received transaction request in a FIFO buffer for processing and subsequent transmission. In block 808, the NPI switch 408 determines through which output port of the NPI switch 408 the transaction request should be transmitted. The NPI switch 408 may determine the output port by identifying the output port based on the destination ID of the slave endpoint circuit in the transaction request, as previously described. In block 810, the NPI switch 408 determines whether a pending transaction request was previously transmitted on an output port other than the determined output port.
[0060] If a pending transaction request has not previously been transmitted on an output port other than the determined output port, in block 812, the NPI switch 408 transmits the transaction request to a subsequent node (e.g., the NPI switch 408 or the protocol block 410) through the determined output port, which may include transmitting multiple data flits of the transaction request in each clock cycle until a data flit containing a final signal indication is transmitted. Upon transmission, the NPI switch 408 may pop the received transaction request from the FIFO buffer in which the received transaction request 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 the received transaction request was stored, space may become available in the FIFO buffer for subsequent reception of another transaction request.
[0061] The stored transmitted transaction request may point to a previously transmitted pending transaction request for the determination at block 810. Referring again to block 810, the determination may reference the destination ID of the stored previously transmitted transaction request. If there are no stored transmitted transaction requests, the determination at block 810 is negative, and the transaction request is transmitted at block 812. If there are stored transmitted transaction requests and the destination of any of the stored transmitted transaction requests (e.g., the first or last pending request) indicates that they were transmitted on an output port of the NPI switch 408 that is the same as the determined output port determined at block 806, the determination at block 810 is negative, and the transaction request is transmitted at block 812. If there are stored transmitted transaction requests and the destination of any of the stored transmitted transaction requests (e.g., the first or last pending request) indicates that the requests were transmitted on an output port of the NPI switch 408 different from the determined output port determined in block 806, the determination of block 810 will be affirmative and the transaction request will not be transmitted. In such a scenario, the determination of block 810 may continue to loop until the determination is negative. Clearing of pending transaction requests, which may cause the determination to be negative, is described in more detail with respect to FIG. 8B.
[0062] A positive determination at block 810 indicates a branch condition. By blocking transmission of transaction requests when a branch condition occurs by acting on the determination at block 810 and subsequent looping, serialization of transaction requests can be maintained, which can maintain proper serialization of transaction responses.
[0063] 8B, in block 852, the NPI switch 408 receives the transaction response on an output port. In block 854, the NPI switch 408 clears the earliest pending transaction request. For example, the NPI switch 408 may pop the stored transmitted transaction request in the FIFO buffer that is the earliest pending transmitted transaction request. By clearing the pending transmitted transaction request, the branching condition in the NPI switch 408 may be removed (e.g., by clearing the condition that resulted in a positive determination in block 810). In block 856, the NPI switch 408 transmits the transaction response to the previous node (e.g., the NPI switch 408 or the root node 404) on the input port of the NPI switch 408.
[0064] In the illustrated example of FIGS. 8A and 8B , the NPI switch 408 may continue to receive transaction requests when a branch condition occurs, as determined in block 810. The received transaction requests may be stored in the appropriate FIFO buffer until no space is available in that FIFO buffer to store the received transaction requests. During the branch condition, transaction requests are not transmitted, and thus received transaction requests are not popped from the FIFO buffer that stores received transaction requests. This may lead to the FIFO buffer becoming full and no space being available to store received transaction requests. Once no space is available to store received transaction requests, the ready to receive signal is deasserted in block 804, and the NPI switch 408 does not receive any further transaction requests from the preceding node. In this example, therefore, transaction requests may propagate throughout the tree topology until a branch condition in the tree topology is reached and the available space for storing received transaction requests is full. This can reduce delays by continuing to propagate transaction requests as long as it is acceptable to maintain serialization.
[0065] In another example, when a branch condition occurs in a tree topology, a signal indicating that a branch condition has occurred may be asserted or deasserted to a preceding node in the tree topology and to the root node 404 to block any transmission of transaction requests in the tree topology.
[0066] The order of operations in these flowcharts is merely an example, and various operations may be implemented in a different logical order. Those skilled in the art will readily recognize different orders of operations that may be implemented in other examples, as well as modifications to the flowcharts of FIGS. 8A and 8B to implement those different orders. Furthermore, those skilled in the art will understand that the operations of FIGS. 8A and 8B may be performed in parallel for different transaction requests and transaction responses, such as in pipeline processing. Various buffers may be implemented to accommodate pipeline or other processing, for example. For example, the NPI switch 408 may implement a buffer to receive a transaction request at block 806 and send another transaction request at block 812 in the same clock cycle.
[0067] 9 is a flowchart of the operation of the protocol block 410, according to some examples. In block 902, the protocol block 410 receives a transaction request in a format implemented by the NPI (e.g., the NPI protocol write request format 602 and the NPI protocol read request format 606 of FIG. 6 ) from a preceding NPI switch 408 in the tree topology. In block 904, the protocol block 410 converts the received transaction request to a format implemented by the slave endpoint circuit (e.g., according to the APB3 protocol). In block 906, the protocol block 410 transmits the converted transaction request to the slave endpoint circuit. The conversion and transmission of blocks 904 and 906 may be performed per data flit and / or per transaction request, respectively. For example, if the transaction request is three data flits, the protocol block 410 may implement a buffer to store the received data flits until the entire transaction request is received, and the protocol block 410 may then convert the entire transaction request.
[0068] In block 908, the protocol block 410 receives a transaction response from the slave endpoint circuit in a format implemented by the slave endpoint circuit. In block 910, the protocol block 410 converts the received transaction response to a format implemented by the NPI (e.g., NPI protocol write response format 604 and NPI protocol read response format 608 of FIG. 6). In block 912, the protocol block 410 transmits the converted transaction response to the preceding NPI switch 408 in the tree topology. The protocol block 410 can transmit the converted transaction response to the preceding NPI switch 408 on a data flit every clock cycle, for example.
[0069] The order of operations in this flowchart is only an example, and various operations may be implemented in a different logical order. Those skilled in the art will readily recognize different orders of operations that may be implemented in other examples, as well as modifications to the flowchart of FIG. 9 to implement those different orders. Furthermore, those skilled in the art will understand that the operations of FIG. 9 may be performed in parallel for different transaction requests and responses, such as in pipeline processing. Various buffers may be implemented to accommodate, for example, pipeline or other processing.
[0070] 10 is a simplified diagram of at least a portion of an SoC 102, according to some examples. The illustrated SoC 102 includes an NoC 106 interconnected between, for example, a processing system 104, a programmable logic region 110, and other IPs 1002 (such as a memory controller 1004). The NoC 106 includes an NMU 202 connected to an NSU 204 through interconnected NoC packet switches 206 and routing 208, which form, for example, a network 214 having physical channels 306 and virtual channels 308. The NoC 106 further includes an NPI 210, which includes a root node 404 (residing on a PMC 402 in the processing system 104), an NPI switch 408 in a tree topology, and a protocol block 410 connected to a slave endpoint circuit. While not shown in detail for simplicity, the protocol block 410 may be a preceding slave endpoint circuit in the tree topology. The slave endpoint circuitry may include, for example, the register block 212 of the NoC packet switch 206, the NMU 202, the NSU 204, the memory controller 1004, and / or others.
[0071] FIG. 11 is a block diagram of an integrated circuit that provides local control to functional blocks, according to an example. The circuit 1100 of FIG. 11 includes, in addition to a PLR 110, several other functional blocks (described in more detail below), as well as other blocks that enable configuration and operation of the functional blocks. For example, the circuit 1100 may include a data interface subsystem 1102 having functional blocks such as a transceiver (TX / RX) block 1104 and a routing block 1106. For particular implementations in which the data interface subsystem includes a PCIe subsystem, the data interface subsystem may also include a CCIX PCIe module (CPM) 1108. An example of the operation of a data interface subsystem, such as a Peripheral Component Interconnect Express (PCIe) subsystem, is described in more detail with reference to FIG. 13. The circuit 1100 of FIG. 11 also includes a memory interface subsystem 1110, which may include functional blocks such as a physical interface block (PHY) block 1112 and an input / output (IO) block 1114. An example of the operation of a memory interface subsystem is described in more detail with reference to FIG. 12. A processor system (PS) 1116, which may be considered a subsystem of the SoC, may be implemented to enable operation of the elements of the integrated circuit device. For example, the PS 1116 may include, for example, an application processor (APU) core, a real-time processor (RPU) core, and a processor subsystem manager (PSM).
[0072] In addition to NoC 1118 and NPI 1120, which may generally be implemented, for example, as NoC 106 and NPI 210 described above, other elements of circuit 1100 are provided to enable implementation of the circuit. For example, a clock routing element (RCLK) 1122 enables routing of a clock signal so that data may be transmitted, such as data associated with data interface subsystem 1102 or memory interface subsystem 1110. A configuration frame circuit element (CFRAME) 1124 is provided to enable reading and writing CFI data frames. A high density IO (HDIO) 1126, a multi-rate media access control (MRMAC) 1129, a PCIE-B block 1130, and other functional blocks may be embedded between the PLR.
[0073] According to some implementations, each subsystem may include a collection of functional blocks. Some elements of circuit 1100, such as PLR 110, may be configured via the CFI bus and receive configuration control, e.g., using global signals, while other elements may be configured through the NPI bus and controlled using PCSRs embedded in each programmable element configured through the NPI bus. Each defined subsystem configured through the NPI bus may be reconfigured without any knowledge of the state of the rest of the integrated circuit device. For example, a data interface system comprising a PCIe subsystem may consist of gigabyte transceiver (GT) quads (i.e., four channels each), a dedicated routing block that may have pipelined registers, a CPM, and NoC elements. According to some implementations, the CPM may include, e.g., PCIe logic and direct memory access (DMA) circuitry. As described in more detail below with reference to FIG. 13, PCSRs may be used to provide individual configuration control of elements of the subsystem. According to another implementation, the memory subsystem 1110 may be, for example, a double data rate (DDR) interface and may include various IO blocks, physical interfaces, PLLs, a DDR memory controller, and various NoC elements, as described in more detail with reference to Figure 12. Reconfiguring these subsystems in a traditional PLD without device-wide configuration information can be difficult, but the use of the NPI bus and PCSR infrastructure allows for reconfiguration of these subsystems by a firmware driver that only has information about the resources associated with the subsystem.
[0074] According to some implementations, the NPI bus and configuration registers may enable "burst register programming." This burst register programming supports high-speed register-based configuration using several related mechanisms, including, for example, (1) the ability to send bursts to endpoints even though the endpoint interface is not burstable (in other words, transactions are chopped up into individual register accesses), (2) grouping of configuration-specific registers to simplify writing to registers using ordered memory accesses (OMA), and (3) the ability to turn on / off error reporting for accesses to unimplemented register addresses. Error reporting can be turned off for burst register programming and turned on again with appropriate error detection.
[0075] According to some implementations, device configuration may generally consist of the following stages: programming registers in the NoC, GTs, memory controller, etc. via the NPI bus; configuring fabric blocks (CLEs, INTs, DSPs, BRAMs, etc.) through the CFI; and initiation sequence events (e.g., MMCM lock, DCI calibration, data transceiver calibration, memory controller calibration, and fabric initiation) controlled through a combination of PCSR writes and global signal assertion / deassertion sequences. The source of firmware, NPI programming data, and PL frame data may be a flash storage device connected to the device, which may be, for example, an FPGA, through interface pins in the PMC. Other possible sources of configuration data may include, for example, PCIE, DRAM, JTAG, or fabric NoC ports.
[0076] FIG. 12 is a block diagram of a portion of a circuit having a memory interface subsystem 1200, according to an example. Memory interface subsystem 1200 may be implemented as memory interface subsystem 1110 of FIG. 11. Memory interface subsystem 1200, which may be, for example, a double data rate (DDR) memory interface, may include a memory controller 1202 having a programming control register 1204, such as a PCSR. Memory controller 1202 is coupled to a peripheral interface bus 1205, which may be an NPI bus and implemented, for example, in NPI 210 or NPI 1120 described above. A phase-locked loop (PLL) 1206 is a functional block coupled to the NPI bus and includes a programming control register 1208, such as a PCSR register described above. The memory interface subsystem also includes an interface channel including a physical interface (PHY) block 1210, which is a functional block having a programming control register 1212, such as a PCSR register, and a corresponding IO block 1214, which is a functional block having a programming control register 1216, such as a PCSR register. 12 implementation, four sets of PHY and IO block pairs are shown for memory controller 1202. However, it should be understood that additional or fewer sets of PHY and IO block pairs may be associated with a memory controller, and that multiple memory interface subsystems may be implemented, such as to control the sets of PHY and IO blocks shown outside the dotted box with the sets of PHY and IO blocks associated with memory controller 1202. Using the NPI bus and PCSR infrastructure, it is possible to reconfigure the memory interface subsystem without knowing the state of any other device elements, where each element of the subsystem can be individually controlled and programmed.
[0077] Figure 13 is a block diagram of a portion of a circuit having a data transceiver interface 1300, according to an example. The data transceiver interface 1300 of Figure 13 includes a data transceiver controller 1302 having programming control registers 1304, such as the PCSR registers described above. An NOC 1306 for the NMU (having programming control registers 1308, such as the PCRS register) and an NOC 1310 for the NSU (having programming control registers 1312, such as the PCRS register) are each coupled to a peripheral interface bus 1313, such as the NPI bus described above. The data transceiver interface 1300 also includes a routing block 1314, which is a functional block having programming control registers 1316, such as the PCSR registers, and a corresponding data transceiver (TX / RX) 1318, which is a functional block having a data transceiver (TX / RX) 1320. The routing block may include a dedicated routing block associated with the data transceiver, as shown. That is, the routing blocks may be separate from the general interconnect routing in an integrated circuit device and, in particular, may be used to route signals in a data transceiver subsystem. While four sets of routing blocks 1314 and corresponding data transceivers 1318 are shown, it should be understood that additional or fewer sets of routing blocks and data transceivers may be associated with a data transceiver controller, and that multiple data transceiver subsystems may be implemented, such as to control the sets of routing blocks and data transceivers shown outside the dotted box with the sets of routing blocks and data transceivers associated with the data transceiver controller 1302. Using the NPI and PCSR infrastructure, it is possible to configure or reconfigure the data transceiver subsystem without knowing the state of any other device elements, where each element of the subsystem may be individually controlled and programmed.
[0078] FIG. 14 is a block diagram of a portion of a circuit having functional blocks, such as those of FIGS. 12 and 13, according to an example. More particularly, an endpoint protocol block 1402, which may be implemented as described for protocol block 410 described above, is coupled to provide signals to functional block 1401. Functional block 1401 includes a program register block 1404 having programming registers 1405 and programming control registers 1406, such as PCSRs. Data from programming register block 1404 and control signals from the PCSRs are provided via peripheral interface bus 1403 to functional block core 1408 to enable operation of the functional block. The functional block communicates with other elements of the integrated circuit device via interface 1409, depending on the operation and function of the functional block. While programming control register 1406 is shown as part of programming register block 1404, it should be understood that programming control register 1406 may be part of a separate register block.
[0079] According to one implementation, the function block receives programming data (also known as configuration data) from the NPI endpoint protocol block 1402, where the programming data may be stored in programming registers of the programming registers block 1404. The programming data (in other words, Q(N-1:0) in FIG. 14) is provided to a first input of an AND gate 1410, which may be configured to receive a gating signal (GATEPROG), which enables gating of the programming data for the function block core 1408. The function block core 1408 comprises several control blocks adapted to receive control signals and to perform control functions associated with the function block core. For example, a status block 1412 may be configured to receive a status (STATUS) signal; i.e., a PCSR may be polled by the PMC, for example, to determine the status of the function block. The functional block 1414 may include several status bits. The status bits may provide information that can be used in starting the functional block or for debugging purposes. The output logic block 1414 is configured to receive a disable (ODISABLE) signal, which can be used to disable the functional block core. For example, when the functional block's programming is being updated or a scan is being performed, the output block should drive a constant neutral value on its output interface. Some blocks with multiple interfaces may require separate control depending on power sequencing or other considerations. For example, an NoC NPS block may have four independent interfaces. The reset logic block 1416 is configured to receive an initial state (INITSTATE) signal. The initial state signal initializes the block state, where the block state may be programmable. A hold state (HOLDSTATE) may be provided to the clock enable logic 1418, which includes a clock enable for the user-visible state. A calibration trigger (STARTCAL) signal may be provided to the calibration logic 1420 to enable the calibration function.Other functions, such as test functions, may be controlled by the PCSR controls as described in Table 1 and may be placed in other control block 1422 based on other control signals not provided to one of blocks 1412-1420. The control data in Table 1 is a standard group of controls that allows standard firmware functions to be defined and used during configuration or partial reconfiguration. JPEG2025186265000002.jpg254170JPEG2025186265000003.jpg103170
[0080] The programming registers define the operation of the programmable blocks, such as, for example, the routing block, the data transceiver, the physical interface block, and the IO block, and may be reset when the power-on reset (POR) signal for the functional block is asserted.
[0081] One key difference between the use of global signals (associated with CFI configuration) and PCSR (associated with NPI configuration) is that with global signals, the PR tool must identify all blocks that are "static" (e.g., not PR targets) and all blocks that are part of a reconfigurable module (RM) and set all GSC bits accordingly. With the PCSR structure, the PR tool only needs to be aware of blocks that are in the RM. Static blocks can be ignored, allowing the "driver" model of partial reconfiguration in Figures 11-14 to be beneficial.
[0082] The NP / Programming Control Status Register (PCSR) structure is a group of registers containing control bits (PCR) and status bits (PSR) that may be used primarily during start or stop sequencing of functional blocks. Note that the control and status registers are contained in functional blocks that may receive their programming bits or signals from the NPI bus and, using CFI programming, perform functions similar to the global signals used in the fabric and programmable logic (PL) portions of an integrated circuit device. In the simplest case, a block may only require a few of these control signals. Other blocks may require many control signals. There may also be mask registers to enable individual control bit writing. The control bits are similar to global signals and are used to ensure that blocks behave correctly as they are programmed and can be made user-operated or non-user-operated in a seamless manner.
[0083] The PCSR may define the granularity of partial reconfiguration. That is, the PCSR may resemble a global signal control (GSC) without NPI-programmed blocks, where the structures controlled by the PCSR are independently reconfigurable. According to some implementations, a block may not disturb any interface attached to it until a user operation transitions it. The block may avoid internal contention, oscillation, or enter a high-current state during the programming process. Inputs to the block may toggle randomly during programming, and appropriate gating may be used to avoid possible undesirable block behavior. The block may allow initialization to either a hardwired reset state or a programming-dependent state under the control of a programming source. After initialization, the block state may remain unaffected by the behavior of inputs other than the programming control input. Blocks that drive signals off-chip may tri-state all output drivers or, in the case of data transceivers, drive a neutral signal.
[0084] FIG. 15 is a block diagram of a portion of a circuit for configuring an integrated circuit using global control signals, such as by using the CFI bus described above, according to an example. The CLB of FIG. 15 includes a CLE 1502, a configuration memory (CRAM) 1504, and gating logic 1506. The circuit may include gating logic 1506, where a local enable signal, such as mc_gsc, can control the operation of the gating logic circuit 1506. Similarly, a configuration memory element associated with programmable resources 1522 includes configuration memory 1504. Thus, the circuit of FIG. 15 provides both a gated local signal to the CLE to control the operation of the CLE, as well as a gated configuration write enable signal that enables the CLE's ability to write to a configuration memory, 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 configuration memory 1504 enables operation of the CLE, as described in more detail below with reference to FIG. 16.
[0085] Gating logic 1506 is coupled to receive a global signal at input 1512, a configuration write enable signal at input 1514, and a local enable signal mc_gsc at input 1516. Note that the local enable signal mc_gsc may be a memory bit stored in configuration memory, as described above. Gating logic 1506 also receives a global enable (en_glob) signal at input 1518. A gated local signal generated at output 1522 is coupled to input 1524. Thus, 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 on configuration write data provided during a partial reconfiguration, where a gated reconfiguration write enable signal associated with some configuration memory cells, such as configuration memory cells associated with a CLB, is generated in response to a local enable signal provided to that CLB.
[0086] The GSC bits and logic function to selectively "mask" the effects of these global signals for functional blocks that are intended to continue functioning during a partial reconfiguration (PR) event. An additional global enable signal (EN_GLOB) allows the override of the state of the GSC bits. This signal is asserted during initial configuration to allow the global signals to be valid across the entire device. The global enable signal and the local enable signal determine whether the configurable block will respond to a stop sequence, which is a sequence of logic state changes of the global signals. Although specific global signals are described, it should be understood that different or additional global signals may be implemented, where the specific global signals may be unique to a particular type of circuit block. Different or additional global signals will be routed to each circuit block of a particular type of circuit block, but local reconfiguration signals are associated with the different or additional global signals based on the local enable signal.
[0087] FIG. 16 is a block diagram of a configurable logic element that may be implemented in an integrated circuit device, such as CLE 1502 of FIG. 15, according to an example. In particular, FIG. 16 illustrates, in simplified form, a configurable logic element that is an example of the programmable logic of configuration logic block 1502 of FIG. 15. In the implementation of FIG. 16, slice M 1601 includes four look-up tables (LUTMs) 1601A-1601D, each driven by six LUT data input terminals A1-A6, B1-B6, C1-C6, and D1-D6, 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 1611, and the LUT output signals are supplied to the interconnect structure. Slice M also includes output select multiplexers 1611A-1611D that drive output terminals AMUX-DMUX, multiplexers 1612A-1612D that drive data input terminals of memory elements 1602A-1602D, combinational multiplexers 1616, 1618, and 1619, bounce multiplexer circuits 1622-1623, circuitry represented by inverter 1605 and multiplexer 1606 (which together provide optional inversion on the input clock path), and carry logic with multiplexers 1614A-1614D, 1615A-1615D, 1620-1621 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 Figure 16, the select inputs are controlled by configuration memory cells. That is, configuration bits of a 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 well-known configuration memory cells have been omitted from Figure 15, as well as from selected other figures herein, for clarity.
[0088] In the depicted implementation, each memory element 1602A-1602D can 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 the synchronous / asynchronous selection circuit 1603. When a memory element is programmed such that the S / R (set / reset) input signal provides the set function, the REV input terminal provides the reset function. When a memory element is programmed such that the S / R input signal provides the 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, for example, by a global clock network or by an interconnect structure. Such programmable memory elements are well known in the art of FPGA design. Each memory element 1602A-1602D provides registered output signals AQ-DQ to the interconnect structure. Each LUT 1601A-1601D provides two output signals O5 and O6, so the LUTs can be configured to function as two 5-input LUTs with five shared input signals (IN1-IN5) or as one 6-input LUT with input signals IN1-IN6.
[0089] In the implementation of FIG. 16, each LUT 1601A-1601D can function in one of several modes. When in look-up table mode, each LUT has six data input signals IN1-IN6 provided by the FPGA interconnect structure via input multiplexers. One of 64 data values is programmably selected from the configuration memory cells based on the values of signals IN1-IN6. When in RAM mode, each LUT functions as a single 64-bit RAM or two 32-bit RAMs using shared addressing. RAM write data is provided to the 64-bit RAM via input terminal DI1 (via multiplexers 1617A-1617C for LUTs 1601A-1601C) or to two 32-bit RAMs via input terminals DI1 and DI2. RAM write operations in the LUT RAM are controlled by a clock signal CK from multiplexer 1506 and a write enable signal WEN from multiplexer 1507, which can selectively pass either the clock enable signal CE or the write enable signal WE. In shift register mode, each LUT functions as two 16-bit shift registers, or two 16-bit shift registers are serially coupled to create a single 32-bit shift register. A shift-in signal is provided via one or both of input terminals DI1 and DI2. 16-bit and 32-bit shift-out signals can be provided through the LUT output terminals; the 32-bit shift-out signal can also be provided more directly via LUT output terminal MC31. The 32-bit shift-out signal MC31 of LUT 1601A can also be provided to a common interconnect structure for shift register chaining via output select multiplexer 1611D and CLE output terminal DMUX. Thus, the circuits and methods described above may be implemented in a device such as the device of FIG. 15, or in any other suitable device.
[0090] FIG. 17 is a flowchart illustrating a method for configuring a functional block of an integrated circuit device, according to an example. In block 1702, a peripheral interface bus, such as the NPI bus described above, is coupled to a processing system. In block 1704, a functional block, such as the functional blocks described in FIGS. 11-14, is coupled to the peripheral interface. In block 1706, programming registers and programming control registers, such as the programming registers and control registers described in FIG. 14, are provided in the functional block. In block 1708, programming data is stored in the programming registers, where the programming data determines the functionality of the functional block's functional block core. In block 1710, control data is stored in the programming control registers of the functional block, where the control data enables configuration of the functional block core using the programming data.
[0091] The method may further comprise coupling an endpoint protocol block between the peripheral interface bus and the functional block, where the endpoint protocol block translates transaction requests for the functional block into a format implemented by the functional block. The method may also comprise enabling partial reconfiguration of the functional block by the processing system, where signals comprising control and status bits used during start or stop sequences of functional block storage may be stored in programming control registers.
[0092] The method may find a specific application in a memory controller, where the functional block comprises a memory controller having a first set of programming registers. A physical interface block may be coupled to a peripheral interface bus, where the physical interface block comprises a second set of programming registers. An input / output block may be coupled to the peripheral interface bus, where the input / output block comprises a third set of programming registers. The method may also find a specific application in a data interface controller, where the functional block may comprise a data interface controller having the first set of programming registers. A routing block may be coupled to the peripheral interface bus, where the routing block comprises a second set of programming registers. A TX / RX block may also be coupled to the peripheral interface bus, where the TX / RX block comprises a third set of programming registers.
[0093] While the foregoing is directed to particular examples, other and further examples may be devised without departing from the basic scope thereof, the scope of which is determined by the claims that follow.
Claims
1. A circuit for configuring a functional block of an integrated circuit device, a processing system (1116); a peripheral interface bus (PIB) (1403) coupled to said processing system; an input / output block (1214) coupled to the peripheral interface bus; a functional block (1401) coupled to the PIB, the functional block (1401) having a programming register (1404) and a functional block core (1408); Equipped with the programming registers (1405) include a set of programming control registers (1406) that store data that determines the functionality of the functional block cores and enable configuration of the functional block cores using said data; circuit.
2. 2. The circuit of claim 1, further comprising an endpoint protocol block (1402) coupled between the PIB (1403) and the function block (1401), the endpoint protocol block translating transaction requests for the function block into a format implemented by the function block.
3. The processing system (1116) enables partial reconfiguration of the functional block (1401). the functional block comprises a memory controller (1202) having a second set of programming control registers (1204); or the input / output block (1214) comprises a third set of programming control registers (1216); 2. The circuit of claim 1, wherein the at least one of:
4. 2. The circuit of claim 1, wherein the processing system (1116) enables partial reconfiguration of the functional block (1401), and the set (1406) of programming control registers is a first set of programming control registers configured to store signals comprising control and status bits used during start or stop sequences of the functional block (1401).
5. a physical interface block (1210) coupled to said PIB (1403), said physical interface block (1210) comprising a fourth set of programming control registers (1212); or a routing block (1314) coupled to the peripheral interface bus (1313), the routing block (1314) comprising a fifth set of programming control registers (1316); The circuit of claim 1 further comprising at least one of:
6. 13. The circuit of claim 1, wherein the functional block comprises a data interface controller (1302) having a sixth set of programming control registers (1304).
7. 7. The circuit of claim 6, further comprising a TX / RX block (1318) coupled to the PIB, the TX / RX block comprising a seventh set of programming control registers (1320).
8. 1. A method of configuring functional blocks of an integrated circuit device, comprising: Coupling (1702) the PIB (1403) to the processing system (1116); coupling an input / output block to the PIB; Coupling (1704) a function block (1401) to the PIB; Providing (1706) a programming register (1404) and a programming control register (1406) in said functional block; storing (1708) programming data in the programming registers (1405) of the functional block, the programming data determining functionality of a functional block core of the functional block; storing (1710) control data in the programming control register (1406) of the functional block, the control data being for enabling configuration of the functional block core (1408) using the programming data; A method comprising:
9. 9. The method of claim 8, further comprising coupling an endpoint protocol block (1402) between the PIB (1403) and the function block (1408), the endpoint protocol block configured to migrate transaction requests for the function block to a format implemented by the function block.
10. The method of claim 8 , further comprising enabling partial reconfiguration of the function block by the processing system, wherein the control data comprises a standard group of control data.
11. 11. The method of claim 10, further comprising storing in the programming control register (1406) signals comprising control and status bits used during a start or stop sequence of the functional block (1401).
12. the functional block comprises a memory controller (1202) having a second set of programming control registers (1204); or the functional block comprises a data interface controller (1302) having a third set of programming control registers (1304); or the input / output block comprises a fourth set of programming control registers (1216); The method of claim 8, wherein the at least one of
13. 10. The method of claim 8, further comprising coupling a physical interface block (1210) to the PIB (1205), the physical interface block comprising a fifth set of programming control registers (1212).
14. 10. The method of claim 8, further comprising coupling a routing block (1314) to the PIB (1313), the routing block comprising a sixth set of programming control registers (1316).
15. 10. The method of claim 8, further comprising coupling a TX / RX block (1318) to the PIB, the TX / RX block comprising a seventh set of programming control registers (1320).
Citation Information
Patent Citations
Hierarchically-Scalable Reconfigurable Integrated Circuit Architecture With Unit Delay Modules
US20120126850A1
Processors, methods, and systems for a configurable spatial accelerator with transactional and replay features
US20190004945A1
Methods and circuits enabling dynamic reconfiguration
US8415974B1
Systems and methods for refreshing data in memory circuits
US9934841B1