Mapping high speed point-to-point interface channels to packet virtual channels
By mapping AXI channels to virtual channels with independent flow control, the congestion problem caused by flow control in packet virtual channels of AXI channels is solved, and efficient communication of AXI devices in packetized networks is realized.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2021-06-23
- Publication Date
- 2026-03-27
AI Technical Summary
In existing technologies, when AXI channels are mapped to packet virtual channels, information blockage can easily occur due to flow control, affecting communication efficiency.
By mapping AXI channels to independent flow-controlled virtual channels, each channel can transmit information independently, avoiding the impact of one channel being blocked on other channels.
It achieves high efficiency for AXI devices to communicate in packet-based networks, while maintaining the advantages of a single channel without internal modifications or performance degradation.
Smart Images

Figure CN116325665B_ABST
Abstract
Description
[0001] Priority Application
[0002] This application claims the benefit of priority to U.S. Application Serial No. 17 / 007,592, filed August 31, 2020, which is incorporated by reference herein in its entirety.
[0003] Statement as to Government Support
[0004] This invention was made with U.S. Government support under Agreement No. HR00111830003 awarded by the Defense Advanced Research Projects Agency (DARPA). The U.S. Government has certain rights in the invention. TECHNICAL FIELD
[0005] Embodiments of the present disclosure generally relate to network protocols, and more specifically, to mapping high-speed point-to-point interface lanes to packet virtual lanes. BACKGROUND
[0006] A common high-speed point-to-point interface, AXI, has 5 lanes for communicating between devices. The 5 lanes are a read address lane, a read data lane, a write address lane, a write data lane, and a write response lane. The read and write address lanes send address and control information. The read and write data lanes send data.
[0007] A chiplet is an emerging technology for integrating various processing functionality. Generally, a chiplet system is composed of discrete chips (e.g., integrated circuits (ICs) on different substrates or dies) that are integrated on an interposer and packaged together. This arrangement is distinct from a single chip (e.g., IC) that contains distinct blocks of devices (e.g., intellectual property blocks) on one substrate (e.g., a single die), such as a system on a chip (SoC), or discrete packaged devices integrated on a board. Generally, chiplets provide better performance (e.g., lower power consumption, reduced latency, etc.) than discrete packaged devices, and chiplets provide greater production efficiencies than single-die chips. These production efficiencies can include higher yields or reduced development costs and time.
[0008] Chiplet systems generally consist of one or more application chiplets and support chiplets. Here, the distinction between application and support chiplets pertains only to possible design scenarios for chiplet systems. Thus, for example, a synthetic vision chiplet system may include application chiplets for generating synthetic vision output and support chiplets, such as memory controller chiplets, sensor interface chiplets, or communication chiplets. In typical use cases, synthetic vision designers may design the application chiplet and obtain the support chiplet from other sources. Therefore, design costs (e.g., in terms of time or complexity) are reduced by avoiding the design and manufacturing of functionality embodied in the support chiplet. Chiplets also support the tight integration of intellectual property blocks that might otherwise be difficult, such as those using intellectual property blocks with different feature sizes. Therefore, for example, devices with larger feature sizes designed during previous manufacturing processes, or those where feature sizes are optimized for power, speed, or thermal generation—as might be the case for sensors—can be integrated with devices of different feature sizes, which is easier than attempting to do so on a single die. Furthermore, by reducing the overall die size, chiplet yields tend to be higher than those of more complex single-die devices. Attached Figure Description
[0009] This disclosure will be more fully understood from the detailed description given below and from the accompanying drawings of various embodiments thereof. However, the drawings should not be construed as limiting this disclosure to the specific embodiments, but are for illustrative and understanding purposes only.
[0010] Figure 1A and 1B An example of a chiplet system according to an embodiment is described.
[0011] Figure 2 This describes the components of an example of a memory controller chiplet according to an embodiment.
[0012] Figure 3 This describes an example of routing between chiplets using a chiplet protocol interface (CPI) network according to an embodiment.
[0013] Figure 4 This is a block diagram of data grouping including multiple flow control units (flits) according to some embodiments of the present disclosure.
[0014] Figure 5 This is a block diagram of a circuit that converts a signal from an AXI master device into CPI packets according to some embodiments of the present disclosure.
[0015] Figure 6 This is a block diagram of a circuit that converts CPI packets into signals for an AXI master device according to some embodiments of the present disclosure.
[0016] Figure 7is a block diagram of circuitry to convert CPI packets to signals to an AXI slave device according to some embodiments of the present disclosure.
[0017] Figure 8 is a block diagram of circuitry to convert signals from an AXI slave device to CPI packets according to some embodiments of the present disclosure.
[0018] Figure 9 is a flowchart showing operations of a method performed by circuitry in converting AXI signals to packets according to some embodiments of the present disclosure.
[0019] Figure 10 is a block diagram of an example computer system in which embodiments of the present disclosure can operate. DETAILED DESCRIPTION
[0020] Embodiments of the present disclosure are directed to systems and methods for mapping from parallel, synchronous, multi-lane connections with separate read and write lanes to packet virtual lanes. For the purposes of this description, the technology will be described in the context of AXI and CPI, but this is by way of example and not limitation. A chip with AXI interfaces converts AXI data to a packet format. Information in AXI lanes is multiplexed onto fewer signals and transmitted over multiple cycles. AXI lanes are mapped to virtual lanes of a packet transfer protocol.
[0021] Converting AXI lanes to a packet format without virtual lanes can hinder independent transmission of information in the AXI lanes; if packet transmission stops because information for one of the AXI lanes is flow controlled at the destination, information for other AXI lanes is also blocked and cannot flow. Thus, by mapping AXI lanes to virtual lanes that do independent flow control, any blockage will be on a lane-by-lane basis, allowing some AXI lanes to be processed without being blocked because another AXI lane stopped.
[0022] Data from multiple AXI lanes can be combined in a single packet. For example, an AXI write address transaction is combined with its corresponding write data transaction into a single packet on virtual lane 0. Virtual lanes can be specified in the command field of the header of the packet. Continuing the mapping of this example embodiment, AXI write response transactions are transmitted using virtual lane 1 as a packet; AXI read address transactions are transmitted using virtual lane 2 as a packet; and AXI read data transactions are transmitted using virtual lane 3 as a packet.
[0023] One of the benefits of embodiments of the present disclosure is that AXI devices can be connected to a packetized network without losing the advantages of separate lanes for different types of communication. This allows existing AXI devices to use packetized network communication without internal modification or performance degradation. Other benefits will be apparent to those of ordinary skill in the relevant art(s) who have the benefit of this disclosure.
[0024] The particular AXI protocol used for the examples herein is AXI4, but the techniques can be equally applicable to AXI3, AXI4-Lite, AXI Coherency Extensions (ACE), and AXI-Lite.
[0025] Figure 1A and 1B An example of a chiplet system 110 is illustrated in accordance with an embodiment. Figure 1A is a representation of a chiplet system 110 mounted on a peripheral board 105 that can be connected to a larger computer system through, for example, Peripheral Component Interconnect Express (PCIe). The chiplet system 110 includes a package substrate 115, an interposer 120, and four chiplets: an application chiplet 125, a host interface chiplet 135, a memory controller chiplet 140, and a memory device chiplet 150. As will be apparent from the discussion below, other systems can include many additional chiplets to provide additional functionality. The package of the chiplet system 110 is illustrated as having a lid or cover 165, but other packaging techniques and structures for chiplet systems can be used. Figure 1B is a block diagram labeling components in the chiplet system 110 for clarity.
[0026] The application chiplet 125 is illustrated as including a network-on-chip (NOC) 130 to support a chiplet network 155 for inter-chiplet communication. In example embodiments, the NOC 130 can be included on the application chiplet 125. In examples, the NOC 130 can be defined in response to selected support chiplets (such as chiplets 135, 140, and 150) to enable a designer to select an appropriate number of chiplet network connections or switches for the NOC 130. In examples, the NOC 130 can be located on a separate chiplet, or even within the interposer 120. In the examples discussed herein, the NOC 130 implements a CPI network.
[0027] CPI is a packet-based network that supports flexible and high-speed interaction of virtual lanes between tiles. CPI enables bridging from intra-tile networks to tile network 155. By way of example, Advanced eXtensible Interface (AXI) is a widely used specification for designing intra-chip communications. However, the AXI specification encompasses a wide variety of physical design options, such as the number of physical lanes, signal timing, power, etc. Within a single chip, these options are typically selected to meet design goals, such as power consumption, speed, etc. However, to enable flexibility of a tile system, an adapter (e.g., CPI) is used to interface between various AXI design options that can be implemented in various tiles. By enabling physical lane to virtual lane mapping and encapsulating time-based signaling with a packetized protocol, CPI bridges intra-tile networks across tile network 155.
[0028] CPI can use a variety of different physical layers to transport packets. A physical layer can include a simple conductive connection or drivers to increase voltage, or otherwise facilitate the transmission of signals over longer distances. One example of such a physical layer can include an Advanced Interface Bus (AIB), which can be implemented in interposer 120 in various instances. Although details of an AIB physical layer are described herein, other physical layers with similar or different characteristics can be used. AIB uses source-synchronous data transfer with a forwarded clock to transmit and receive data. Packets are transferred across the AIB at single data rate (SDR) or double data rate (DDR) with respect to the transmitted clock. Other multiples of the clock rate are also possible.
[0029] Various lane widths are supported by AIB and other physical layers. When operating in SDR mode, AIB lane widths are multiples of 20 bits (20, 40, 60,...), and for DDR mode are multiples of 40 bits: (40, 80, 120,...). AIB lane widths include both transmit (TX) and receive (RX) signals. A lane can be configured to have a symmetric number of TX and RX inputs / outputs (I / O), or have an asymmetric number of transmitters and receivers (e.g., all transmitters or all receivers). A tile that provides the master clock is the master tile; another tile is the slave tile. In such cases, the master tile can have independence from the other tiles, and it can have supervisory rights over one or more slave tiles. This relationship can be similar to the relationship between devices sometimes described using the derogatory and outdated terms master and slave. AIB I / O cells support three clocked modes: asynchronous (i.e., non-clocked), SDR, and DDR. Other physical layers can support any or all of these clocked modes or can support additional clocked modes. In various instances, the non-clocked mode is used for the clock and some control signals. The SDR mode can use dedicated SDR-only I / O cells or dual-purpose SDR / DDR I / O cells.
[0030] In an example, a CPI packet protocol (e.g., point-to-point or routable) can use symmetric receive and transmit I / O units within an AIB lane. The CPI streaming protocol allows more flexible use of AIB I / O units. In an example, an AIB lane for streaming mode can configure the I / O units as all TX, all RX, or half TX and half RX. The CPI packet protocol can use an AIB lane in SDR or DDR mode of operation. In an example, for SDR mode, an AIB lane is configured in increments of 80 I / O units (i.e., 40 TX and 40 RX), while for DDR mode it is 40 I / O units. The CPI streaming protocol can use an AIB lane in SDR or DDR mode of operation. Here, in an example, for both SDR and DDR modes, an AIB lane is in increments of 40 I / O units. In an example, each AIB lane is assigned a unique interface identifier. The identifier is used during CPI reset and initialization to determine paired AIB lanes across adjacent small chips. In an example, the interface identifier is a 20-bit value that includes a 7-bit small chip identifier, a 7-bit column identifier, and a 6-bit link identifier. The AIB physical layer uses an AIB out-of-band shift register to transmit the interface identifier. The 20-bit interface identifier is conveyed across the AIB interface in both directions using bits 32 to 51 of the shift register.
[0031] An AIB defines a set of stacked AIB lanes as an AIB lane column. An AIB lane column has a certain number of AIB lanes plus an auxiliary (AUX) lane. The AUX lane contains signals for AIB initialization. All AIB lanes within a column (except the AUX lane) have the same configuration (e.g., all TX, all RX, or half TX and half RX, and also have the same number of data I / O signals). In an example, the AIB lanes are numbered in consecutive increasing order starting with the AIB lane adjacent to the AUX lane. The AIB lane adjacent to the AUX is defined as AIB lane 0.
[0032] In general, a CPI interface on an individual small chip can include serialization-deserialization (SERDES) hardware. SERDES interconnects work well for situations where high-speed signaling with a low signal count is desired. However, SERDES can result in additional power consumption and longer latency for multiplexing and demultiplexing, error detection or correction (e.g., using block-level cyclic redundancy check (CRC)), link-level retry or forward error correction. However, when low latency or energy consumption is a primary concern for ultra-short reach small chip to small chip interconnects, a parallel interface with a clock rate that allows data transfer with minimal latency can be utilized. CPI includes elements to minimize both latency and energy consumption in these ultra-short reach small chip interconnects.
[0033] For flow control, CPI employs a credit-based technique. For example, an application sink chip 125, such as a memory controller sink chip 140, provides a source that provides credits representing available buffers. In an example, the CPI sink has buffers for each virtual lane in a given unit of time. Thus, if the CPI sink supports five messages in time and a single virtual lane, the sink has five buffers arranged in five rows (one row per unit of time). If four virtual lanes are supported, the sink has twenty buffers arranged in five rows. Each buffer holds the payload of one CPI packet.
[0034] As the source transmits to the sink, the source decrements the available credits based on the transmissions. Once all of the sink's credits are consumed, the source stops sending packets to the sink. This ensures that the sink always has available buffers to store transmissions.
[0035] As the sink processes received packets and frees buffers, the sink passes available buffer space back to the source. This credit is then available to be used by the source to allow transmission of additional information.
[0036] A small chip mesh network 160 using direct small chip to small chip technology without a NOC 130 is also described. The small chip mesh network 160 can be implemented in CPI or another small chip to small chip protocol. The small chip mesh network 160 generally enables a small chip pipeline, where one small chip serves as an interface to the pipeline, and the other small chips in the pipeline only interface with themselves.
[0037] Additionally, specialized device interfaces, such as one or more industry standard memory interfaces 145 (e.g., a synchronous memory interface such as DDR5, DDR6, for example) can also be used to interconnect the small chips. Connection of the small chip system or individual small chips to external devices, such as a larger system, can be made through a desired interface, such as a PCIE interface. In an example, this external interface can be implemented through a host interface small chip 135, which in the depicted example provides a PCIE interface external to the small chip system 110. Such specialized interfaces 145 are generally employed when industry convention or standards have focused on such an interface. The described example of a DDR interface 145 connecting the memory controller small chip 140 to a dynamic random access memory (DRAM) memory device small chip 150 is merely one such industry convention.
[0038] Among the various possible support chips, a memory controller chip 140 is likely to be present in the chiplet system 110 due to the almost ubiquitous use of memory for computer processing and the sophisticated advances for memory devices. Thus, using memory device chiplets 150 and memory controller chiplets 140 produced by others enables chiplet system designers to use robust products produced by sophisticated producers. Generally, the memory controller chiplet 140 provides a memory device specific interface to read, write, or erase data. Often, the memory controller chiplet 140 can provide additional features such as error detection, error correction, maintenance operations, or atomic operation execution. For some types of memory, maintenance operations tend to be specific to the memory device chiplet 150, such as garbage collection in NAND flash or storage class memory and temperature regulation (e.g., cross-temperature management) in NAND flash memory. In examples, maintenance operations can include logical to physical (L2P) mapping or management to provide a level of indirection between a physical representation and a logical representation of data. In other types of memory, such as DRAM, some memory operations, such as refresh, can be controlled by the host processor or the memory controller at some times and by the DRAM memory device or by logic associated with one or more DRAM devices (e.g., an interface chip (in an example, a buffer)) at other times.
[0039] Atomic operations are data manipulations that can be performed, for example, by the memory controller chiplet 140. In other chiplet systems, atomic operations can be performed by other chiplets. For example, the atomic operation “increment” can be specified by the application chiplet 125 in a command that includes a memory address and possibly an increment value. After receiving the command, the memory controller chiplet 140 retrieves a number from the specified memory address, increments the number by the amount specified in the command, and stores the result. Upon successful completion, the memory controller chiplet 140 provides an indication of the command success to the application chiplet 125. Atomic operations avoid the transmission of data across the chiplet mesh network 160, enabling lower latency execution of such commands.
[0040] Atomic operations can be classified as built-in atoms or programmable (e.g., custom) atoms. Built-in atoms are a limited set of operations that are implemented immutably in hardware. Programmable atoms are small programs that can be run on a programmable atom unit (PAU) of the memory controller chiplet 140, such as a custom atom unit (CAU). FIG. 1 illustrates an example of a memory controller chiplet that includes a PAU.
[0041] Memory device die 150 can be or include any combination of volatile memory devices or non-volatile memory. Examples of volatile memory devices include, but are not limited to, random access memory (RAM) - such as DRAM, synchronous DRAM (SDRAM), and graphics double data rate type 6 SDRAM (GDDR6 SDRAM), etc. Examples of non-volatile memory devices include, but are not limited to, NAND-type flash memory, storage class memory (such as phase change memory or memristor-based technologies), and ferroelectric RAM (FeRAM), etc. The illustrated example includes memory devices as memory device die 150, however, memory devices can reside elsewhere, such as in different packages on board 105. For many applications, multiple memory device dies can be provided. In examples, these memory device dies can each implement one or more storage technologies. In examples, a memory die can include multiple stacked memory dies of different technologies (such as one or more DRAM devices stacked with or otherwise in communication with one or more SRAM devices). Memory controller die 140 can also be used to coordinate operations between multiple memory dies in die system 110 (such as utilizing one or more memory dies in one or more cache memory levels and using one or more additional memory dies as main memory). Die system 110 can also include multiple memory controller dies 140, which can be used to provide memory control functionality for separate processors, sensors, networks, etc. A die architecture such as die system 110 provides the advantage of allowing adaptation to different memory storage technologies and adaptation to different memory interfaces through an upgrade of the die configuration without needing to redesign the rest of the system structure.
[0042] Figure 2An example of components of a memory controller chiplet 205 according to an embodiment is illustrated. The memory controller chiplet 205 includes a cache 210, a cache controller 215, an off-die memory controller 220 (e.g., for communicating with off-die memory 275), a network communication interface 225 (e.g., for interfacing with a chiplet network 285 and communicating with other chiplets), and a set of atomic and merge operation units 250. Members of this set can include, for example, a write merge unit 255, a hazard clear unit 260, a built-in atomic operation unit 265, or a PAU 270. Each component is illustrated logically, not necessarily as they will be implemented. For example, the built-in atomic operation unit 265 likely includes different devices along the path to off-die memory. For example, the built-in atomic operation unit 265 can be in an interface device / buffer on the memory chiplet, as discussed above. In contrast, the PAU 270 is likely implemented in a separate processor on the memory controller chiplet 205 (but in various examples, can be implemented elsewhere, such as on the memory chiplet).
[0043] The off-die memory controller 220 is directly coupled to the off-die memory 275 (e.g., via a bus or other communication connection) to provide write operations to and read operations from one or more off-die memories (such as off-die memory 275 and off-die memory 280). In the depicted example, the off-die memory controller 220 is also coupled for output to the atomic and merge operation units 250 and for input to the cache controller 215 (such as a memory-side cache controller).
[0044] In an example configuration, the cache controller 215 is directly coupled to the cache 210, and can be coupled to the network communication interface 225 for input (such as incoming read or write requests), and can be coupled for output to the off-die memory controller 220.
[0045] The network communication interface 225 includes a packet decoder 230, a network input queue 235, a packet encoder 240, and a network output queue 245 to support a packet-based chiplet network 285, such as a CPI. The chiplet network 285 can provide packet routing between and among processors, memory controllers, hybrid thread processors, configurable processing circuitry, or communication interfaces. In such a packet-based communication system, each packet typically includes destination and source addressing as well as any data payload or instructions. In an example, the chiplet network 285 can be implemented as a set of crossbars with a folded Clos configuration or a mesh network providing additional connectivity, depending on the configuration.
[0046] In various examples, the chiplet network 285 can be part of an asynchronous switched fabric. Here, data packets can be routed along any of various paths such that arrival of any selected data packet at an addressed destination can depend on routing occurring at any of a plurality of different times. Additionally, the chiplet network 285 can be implemented at least in part as a synchronous communication network, such as a synchronous mesh communication network. Consideration of both communication network configurations is used in accordance with examples of the present disclosure.
[0047] The memory controller chiplet 205 can receive packets with, for example, a source address, a read request, and a physical address. In response, the off-die memory controller 220 or the cache controller 215 will read data from the specified physical address (which can be in the off-die memory 275 or in the cache 210) and assemble a response packet to the source address containing the requested data. Similarly, the memory controller chiplet 205 can receive packets with a source address, a write request, and a physical address. In response, the memory controller chiplet 205 will write data to the specified physical address (which can be in the cache 210 or in the off-die memory 275 or 280) and assemble a response packet to the source address containing confirmation that the data was stored to memory.
[0048] Thus, the memory controller chiplet 205 can receive read and write requests via the chiplet network 285 and process the requests using the cache controller 215 that interfaces with the cache 210, if possible. If a request cannot be handled by the cache controller 215, the off-die memory controller 220 handles the request by communicating with the off-die memory 275 or 280, the atomic and merge operation unit 250, or both. As noted above, one or more levels of cache can also be implemented in the off-die memory 275 or 280, and in some such examples can be directly accessed by the cache controller 215. Data read by the off-die memory controller 220 can be cached by the cache controller 215 in the cache 210 for later use.
[0049] The atomic and merge operation unit 250 is coupled to receive the output of the off-die memory controller 220 (as input) and provide output to the cache 210, network communication interface 225, or directly to the small chip network 285. The memory hazard clear (reset) unit 260, write merge unit 255, and built-in (e.g., predetermined) atomic operation unit 265 can each be implemented as state machines with another set of combinational logic circuitry (e.g., adder, shifter, comparator, AND gate, OR gate, XOR gate, or any suitable combination thereof) or other logic circuitry. These components can also include one or more registers or buffers for storing operands or other data. The PAU 270 can be implemented as one or more processor cores or control circuitry and various state machines with other combinational logic circuitry or other logic circuitry, and can also include one or more registers, buffers, or memory for storing addresses, executable instructions, operands, and other data, or can be implemented as a processor.
[0050] The write merge unit 255 receives the read data and the request data and merges the request data with the read data to create a single unit with the read data and the source address for use in a response or return data packet. The write merge unit 255 provides the merged data to a write port of the cache 210 (or equivalently, to the cache controller 215 to write to the cache 210). Optionally, the write merge unit 255 provides the merged data to the network communication interface 225 to encode and prepare a response or return data packet for transmission on the small chip network 285.
[0051] When the request data is for a built-in atomic operation, the built-in atomic operation unit 265 receives the request from the write merge unit 255 or directly from the off-die memory controller 220 and reads the data. The atomic operation is performed, and the resulting data is written to the cache 210 using the write merge unit 255, or provided to the network communication interface 225 to encode and prepare a response or return data packet for transmission on the small chip network 285.
[0052] The built-in atomic operation unit 265 handles predefined atomic operations, such as fetch and increment or compare and swap. In an example, these operations perform simple read-modify-write operations on a single memory location of size 32 bytes or less. Atomic memory operations are initiated from a request packet transmitted over the small chip network 285. The request packet has a physical address, an atomic operator type, an operand size, and optionally up to 32 bytes of data. The atomic operation performs a read-modify-write on a cache memory line of the cache 210, filling the cache memory if necessary. The atomic operator response can be a simple completion response, or a response with up to 32 bytes of data. Example atomic memory operators include fetch and AND, fetch and OR, fetch and XOR, fetch and add, fetch and subtract, fetch and increment, fetch and decrement, fetch and minimize, fetch and maximize, fetch and swap, and compare and swap. In various example embodiments, 32-bit and 64-bit operations are supported, as well as operations on 16 or 32 bytes of data. The methods disclosed herein can also be compatible with hardware that supports larger or smaller operations and more or less data.
[0053] The built-in atomic operations can also involve requests for "standard" atomic operations on the requested data, such as relatively simple single loop integer atoms, such as fetch and increment or compare and swap, which will occur in the same amount of processing as a regular memory read or write operation that does not involve an atomic operation. For these operations, the cache controller 215 can typically reserve the cache line in the cache 210 by setting a hazard bit (in hardware) so that the cache line cannot be read by another process while it is being transitioned. The data is obtained from off-die memory 275 or the cache 210 and provided to the built-in atomic operation unit 265 to perform the requested atomic operation. After the atomic operation, in addition to providing the resulting data to the data packet encoder 240 to encode an outgoing data packet for transmission on the small chip network 285, the built-in atomic operation unit 265 also provides the resulting data to the write coalesce unit 255, which also writes the resulting data to the cache 210. After the resulting data is written to the cache 210, any corresponding hazard bits that were set are cleared by the memory hazard clear unit 260.
[0054] PAU 270 enables high performance (high throughput and low latency) of programmable atomic operations (also referred to as “custom atomic operations”) that are comparable in performance to built-in atomic operations. Unlike performing multiple memory accesses, in response to an atomic operation request that specifies a programmable atomic operation and a memory address, circuitry in the memory controller chiplet 205 communicates the atomic operation request to the PAU 270 and sets a hazard bit stored in a memory hazard register corresponding to the memory address of the memory line used in the atomic operation to ensure that no other operations (reads, writes, or atomic) are performed to that memory line, then clears the hazard bit after the atomic operation is completed. The additional direct data path provided for the PAU 270 to perform programmable atomic operations allows additional write operations without being subject to any limitations imposed by the bandwidth of the communication network and without adding any congestion to the communication network.
[0055] The PAU 270 includes a multi-threaded processor, such as, for example, a multi-threaded processor based on the RISC-V ISA, with one or more processor cores and further with an extended instruction set for performing programmable atomic operations. When provided with the extended instruction set for performing programmable atomic operations, the PAU 270 can be embodied as one or more hybrid thread processors. In some example embodiments, the PAU 270 provides barrel-style loop instantaneous thread switching to maintain a high per-clock instruction rate.
[0056] Programmable atomic operations can be performed by the PAU 270, involving a request for a programmable atomic operation on requested data. A user can prepare program code to provide such programmable atomic operations. For example, the programmable atomic operation can be a relatively simple multi-cycle operation, such as a floating point addition, or a relatively complex multi-instruction operation, such as a Bloom filter insertion. The programmable atomic operations can be the same as or different from predetermined atomic operations, as long as they are defined by the user and not by the system vendor. For these operations, the cache controller 215 can reserve a cache line in the cache 210 by setting a hazard bit (in hardware) so that the cache line cannot be read by another process while it is being transformed. Data is obtained from the cache 210 or off-die memory 275 or 280 and provided to the PAU 270 to perform the requested programmable atomic operation. After the atomic operation, the PAU 270 will provide the resulting data to the network communication interface 225 to directly encode an outgoing data packet with the resulting data for transmission on the chiplet network 285. In addition, the PAU 270 will provide the resulting data to the cache controller 215, which also writes the resulting data to the cache 210. After the resulting data is written to the cache 210, any corresponding hazard bit that was set will be cleared by the cache controller 215.
[0057] In selected instances, the approach taken for programmable atomic operations is to provide a plurality of custom atomic request types that can be sent from a raw source such as a processor or other system component to the memory controller chiplet 205 over the chiplet network 285. The cache controller 215 or off-die memory controller 220 recognizes the request as custom atomic and forwards the request to the PAU 270. In representative embodiments, the PAU 270: (1) is a programmable processing element capable of efficiently executing user-defined atomic operations; (2) can perform loads and stores to memory, arithmetic and logical operations, and control flow decisions; and (3) utilizes the RISC-V ISA with a new set of specialized instructions to facilitate interaction with such controllers 215, 220 to perform user-defined operations atomically. In desired instances, the RISC-V ISA contains a full set of instructions that support high-level language operators and data types. The PAU 270 can utilize the RISC-V ISA, but when contained within the memory controller chiplet 205 will typically support a more limited set of instructions and a limited register file size to reduce the die size of the unit.
[0058] As mentioned above, prior to writing the read data to the cache 210, the set hazard bit for the reserved cache line will be cleared by the memory hazard clearing unit 260. Thus, when the request and read data are received by the merge unit 255, a reset or clear signal can be transmitted by the memory hazard clearing unit 260 to the cache 210 to reset the set memory hazard bit for the reserved cache line. Also, resetting this hazard bit will release pending read or write requests involving the specified (or reserved) cache line, providing the pending read or write requests to the inbound request multiplexer for selection and processing.
[0059] Figure 3 An example of using a CPI network to route between chiplets in a chiplet layout 300 according to an embodiment is illustrated. The chiplet layout 300 includes chiplets 310A, 310B, 310C, 310D, 310E, 310F, 310G, and 310H. The chiplets 310A-310H are interconnected by a network including nodes 330A, 330B, 330C, 330D, 330E, 330F, 330G, and 330H. Each of the chiplets 310A-310H includes a hardware transceiver, labeled 320A-320H.
[0060] CPI packets can be communicated between the chiplets 310 using AIB. AIB provides physical layer functionality. The physical layer transmits and receives data using source-synchronous data transfers with a forwarded clock. Packets are communicated across AIB in SDR or DDR with respect to the transmitted clock. Each lane width is supported by AIB. When operating in SDR mode, AIB lane widths are multiples of 20 bits (20, 40, 60,...), and for DDR mode, multiples of 40 bits (40, 80, 120,...). AIB lane widths include both TX and RX signals. Lanes can be configured to have a symmetric number of TX and RX (I / O) or have an asymmetric number of transmitters and receivers (e.g., all transmitters or all receivers). Lanes can be used as AIB master or slave lanes depending on which chiplet provides the master clock.
[0061] AIB adapters provide an interface to the AIB link layer and an interface to the AIB physical layer (PHY). AIB adapters provide data staging registers, power-on reset sequence generators, and control signal shift registers.
[0062] AIB physical layer is composed of AIB I / O cells. AIB I / O cells (implemented by hardware transceivers 320 in some example embodiments) can be input-only, output-only, or bidirectional. An AIB lane is composed of a set of AIB I / O cells, and the number of cells depends on the configuration of the AIB lane. Received signals on one chiplet are connected to transmitted signals on a paired chiplet. In some example embodiments, each column includes AUX lanes numbered 0 through N and data lanes.
[0063] AIB lanes are typically configured as half TX data plus half RX data, all TX data, or all RX data plus associated clock and miscellaneous controls. In some example embodiments, the number of TX and RX data signals is determined at design time and cannot be configured as part of system initialization.
[0064] CPI packet protocols (point-to-point and routable) use symmetric receive and transmit I / O cells within AIB lanes. CPI streaming protocols allow more flexible use of AIB I / O cells. In some example embodiments, AIB lanes for streaming mode can configure I / O cells as all TX, all RX, or half TX and half RX.
[0065] Data packets are routed among the chiplets 310 by network nodes 330. A node 330 can determine, based on one or more data fields of a data packet, a next node 330 to which to forward a received data packet. For example, a source or destination address, a source or destination port, a virtual lane, or any suitable combination thereof can be hashed to select a successive network node or available network path. Selecting a path in this way can be used to balance network traffic.
[0066] Thus, in Figure 3 A data path from chiplet 310A to chiplet 310D is shown. A data packet is sent by hardware transceiver 320A to network node 330A; forwarded by network node 330A to network node 330C; forwarded by network node 330C to network node 330D; and delivered by network node 330D to hardware transceiver 320D of chiplet 310D.
[0067] A second data path from chiplet 310A to chiplet 310G is also shown in Figure 3 A data packet is sent by hardware transceiver 320A to network node 330A; forwarded by network node 330A to network node 330B; forwarded by network node 330B to network node 330D; forwarded by network node 330D to network node 330C; forwarded by network node 330C to network node 330E; forwarded by network node 330E to network node 330F; forwarded by network node 330F to network node 330H; forwarded by network node 330H to network node 330G; and delivered by network node 330G to hardware transceiver 320G of chiplet 310G. As Figure 3 As is clear in
[0068] The AIB I / O unit supports three clocked modes: asynchronous (i.e., non- clocked), SDR, and DDR. The non-clocked mode is used for clock and some control signals. The SDR mode can use a dedicated SDR-only I / O unit or a dual-purpose SDR / DDR I / O unit.
[0069] The CPI packet protocol (point-to-point and routable) can use the AIB channel in SDR or DDR operation mode. In some example embodiments, the AIB channel is incremented by 80 I / O units (i.e., 40 TX and 40 RX) for SDR mode and by 40 I / O units for DDR mode.
[0070] The CPI streaming protocol can use the AIB channel in SDR or DDR operation mode. In some example embodiments, the AIB channel is incremented by 40 I / O units for both modes (SDR and DDR).
[0071] Each AIB lane is assigned a unique interface identifier. The identifier is used during CPI reset and initialization to determine the paired AIB lanes across adjacent tiles. In some example embodiments, the interface identifier is a 20-bit value that includes a 7-bit tile identifier, a 7-bit column identifier, and a 6-bit link identifier. The AIB physical layer uses an AIB out-of-band shift register to transmit the interface identifier. The 20-bit interface identifier is sent in both directions across the AIB interface using bits 32 to 51 of the shift register.
[0072] In some example embodiments, the AIB lanes are numbered in a sequential increasing order starting from the AIB lane adjacent to the AUX lane. The AIB lane adjacent to the AUX is defined as AIB lane 0.
[0073] By way of example, Figure 3 Eight tiles 310 connected by a network comprising eight nodes 330 are shown. More or fewer tiles 310 and more or fewer nodes 330 can be included in a tile network, allowing for the creation of a network of tiles of arbitrary size.
[0074] Figure 4 is a block diagram of a data packet 400 comprising a plurality of flits according to some embodiments of the present disclosure. The data packet 400 is divided into flow control units (flits), each of which consists of 36 bits. The first flit of the data packet 400 includes a control path field 405, a path field 410, a destination identifier (DID) field 415, a sequence continuation (SC) field 420, a length field 425, and a command field 430. The second flit includes address fields 435 and 445, a transaction ID (TID) field 440, and a reserved (RSV) field 450. The third flit includes a credit return (CR) / RSV field 455, an address field 460, a source identifier (SID) 465, a bridge type (BTYPE) 470, and an extended command (EXCMD) 475. Each remaining flit includes a CR / RSV field (e.g., CR / RSV fields 480 and 490) and a data field (e.g., data fields 485 and 495).
[0075] Control path field 405 is a 2-bit field that indicates whether the CR / RSV field of a later flit in the packet contains CR data, RSV data, or should be ignored and whether path field 410 applies to control packet ordering. In some example embodiments, a value of 0 or 1 in control path field 405 indicates that the CR / RSV field 455, 480, 490 contains credit return data; a value of 2 or 3 in control path field 405 indicates that the CR / RSV field 455, 480, 490 contains RSV data; a value of 0 indicates that path field 410 is ignored; a value of 1 or 3 indicates that path field 410 is used to determine the path of data packet 400; and a value of 2 indicates that single path ordering will be used. In some example embodiments, a 1-bit field is used. Alternatively, the upper bit of control path field 405 can be considered a 1-bit field that controls whether the CR / RSV field 450, 455 contains credit return data or RSV data.
[0076] Path field 410 is an 8-bit field. When control path field 405 indicates that path field 410 is used to determine the path of data packet 400, all data packets having the same value for path field 410 are guaranteed to take the same path through the network. Thus, the order of the data packets will be invariant between the sender and the receiver. If control path field 405 indicates that single path ordering will be used, the path of each packet is determined as if path field 410 were set to 0. Thus, all packets take the same path and the order will be invariant regardless of the actual value of path field 410 for each data packet. If control path field 405 indicates that path field 410 is to be ignored, the data packets are routed without regard to the value of path field 410, and the data packets can be received by the receiver in a different order than they were sent by the sender. However, this can avoid congestion in the network and allow increased throughput in the device.
[0077] DID field 415 stores a 12-bit DID. The DID uniquely identifies a destination (e.g., a destination flit) in the network. Data packet sequences that have SC field 420 set are guaranteed to be delivered in order. Length field 425 is a 5-bit field that indicates the number of flits that comprise data packet 400. The interpretation of length field 425 can be non-linear. For example, values 0 to 22 can be interpreted as 0 to 22 flits in data packet 400, and values 23 to 27 can be interpreted as 33 to 37 flits in data packet 400 (i.e., 10 more than the indicated value). Other values of length field 425 can be vendor-defined rather than protocol-defined.
[0078] The command of data packet 400 is stored in command field 430, which is a 7-bit field. The command can be a write command, a read command, a pre-defined atomic operation command, a custom atomic operation command, a read response, an acknowledgement response, or a vendor specific command. Additionally, the command can indicate a virtual lane of data packet 400. For example, different commands can be used for different virtual lanes, or 1, 2, 3, or 4 bits of 7-bit command field 430 can be used to indicate a virtual lane, and the remaining bits can be used to indicate a command. According to some example embodiments, the table below shows protocol based virtual lanes, and commands below.
[0079] Virtual Channel CPI Protocol AXI Protocol 0 Read / Write Request Write Request 1 Read / Write Response Write Response 2 Unused Read Request 3 Unused Read Response
[0080] The address of the command can be indicated in path field 410, address fields 435, 445, and 460, or any suitable combination thereof. For example, the 38 most significant bits of a 4-byte aligned 41-bit address can be indicated by concatenating address field 460, address field 435, path field 410, and address field 445 in order (most significant bits first). TID field 440 is used to match a response to a request. For example, if a first packet 400 is a read request identifying a memory location to be read, a responsive second packet 400 containing read data will include the same value in TID field 440.
[0081] SID field 465 identifies the source of data packet 400. Thus, a recipient of packet 400 can send a responsive packet by copying the value in SID field 465 into DID field 415 of the responsive packet. 4-bit BTYPE field 470 specifies the command set used for packet 400. BTYPE 0 indicates a first method for determining the command of packet 400 (e.g., a command determined based on the CPI protocol and command field 430). BTYPE of 1 indicates a second method for determining the command of packet 400 (e.g., a command based on the AXI protocol and EXCMD field 475). Other BTYPE values indicate other methods of determining the command of packet 400. Thus, instead of encapsulating a packet of a second protocol entirely within the data field of data packet 400 for transmission over a network using a first protocol, the much lower overhead of adding one or two flits that identify the protocol of packet 400 allows the network to support both protocols (in this example, CPI and AXI).
[0082] Memory access commands can identify the number of bytes to write or access, the memory space to access (e.g., off-die memory 275 or instruction memory for custom atomic operations), or any suitable combination thereof. In some example embodiments, a command can indicate that additional bits of the following flit identify the command. For example, a multi-byte command can be sent by using a vendor-specific command in the 7-bit command field 430 and using some or all of a 7-bit extension command (EXCMD) field 475 that contains a larger command. Thus, for certain values of the command field 430, the packet 400 contains only one header flit (e.g., Figure 4 the first header flit shown in FIG. 4B, which contains fields 405-430). For other values of the command field 430, the packet 400 contains a predetermined additional number of header flits (e.g., Figure 4 the two additional header flits shown in FIG. 4C, which contains fields 435-475) or a predetermined total number of header flits (e.g., Figure 4 the total of three header flits shown in FIG. 4D, which contains fields 405-475).
[0083] If CR is enabled, two bits of the CR / RSV field 455, 480, 490 identify whether credit return is for virtual lane 0, 1, 2, or 3, and the other two bits of the CR / RSV field 455, 480, 490 indicate whether the number of credits to return is 0, 1, 2, or 3.
[0084] Figure 5 is a block diagram of circuitry 500 that converts signals from an AXI master device into CPI packets, in accordance with some embodiments of the present disclosure. The circuitry 500 includes a state machine 505; first-in-first-out (FIFO) buffers (also referred to as FIFOs) 510A, 510B, 510C, 510D, 510E, and 510F; registers 535; multiplexers (MUXs) 525 and 555; an error correction code (ECC) generator 545; an arbiter 560; a memory 565; and a credit updater 570. The components of the circuitry 500 are connected via hardware traces, buses, or other physical connections.
[0085] The left side of the circuitry 500 is connected to an AXI master device. The right side of the circuitry 500 is connected to a CPI network. The circuitry 500 receives read addresses, write addresses, and write data commands from the AXI master device and provides corresponding CPI packets to the CPI network.
[0086] The state machine 505 provides ARREADY, AWREADY, and WREADY signals to the AXI master. Each signal, if raised, indicates that the circuit 500 is ready to receive the corresponding input. The ARREADY signal, if raised, indicates that the circuit 500 is ready to receive a read address. The AWREADY signal, if raised, indicates that the circuit 500 is ready to receive a write address. The WREADY signal, if raised, indicates that the circuit 500 is ready to receive write data.
[0087] The AXI master provides ARVALID, AWVALID, and WVALID signals to the state machine 505, each of which can be raised to indicate that the corresponding input is valid or lowered to indicate that the corresponding input is not valid. The ARVALID signal, when raised, indicates that the AXI master is providing a valid read address to the FIFO 510A. The AWVALID signal, when raised, indicates that the AXI master is providing a valid write address to the FIFO 510B. The WVALID signal, when raised, indicates that the AXI master is providing valid write data to one or more of the FIFOs 510C to 510F.
[0088] Thus, when both the ARREADY and ARVALID signals are raised, the circuit 500 processes a read address input by the AXI master to the read address FIFO 510A. Similarly, when both the AWREADY and WVALID signals are raised, the circuit 500 processes a write address input by the AXI master to the write address FIFO 510B. The read or write address is provided to the arbiter 560, which generates a corresponding CPI packet.
[0089] For a read command, only an address is needed (no data is needed). The arbiter 560 verifies with the credit updater 570 that sufficient credits are available on the virtual lane corresponding to the read command (e.g., virtual lane 2) and updates the available credits for the virtual lane. Each field of the CPI packet is provided by the AXI master (e.g., the address), statically defined by the circuit 500 (e.g., the source identifier), dynamically defined by the circuit 500 based on AXI signals (e.g., by looking up a destination ID in the memory 565 based on the address provided by the AXI master or by determining the length of the packet based on the command and data provided by the AXI master), or dynamically defined by the circuit 500 based on the state of the circuit 500 (e.g., selecting an available transaction ID). The CPI packet is provided to the MUX 555 and held in the register 535 for access by the ECC generator 545. The generated CPI packet is provided to the CPI network.
[0090] Unlike a read command, a write command uses both address and data. When both the WREADY and WVALID signals are raised, data is received by the circuit 500 from the AXI master in one or more of the FIFOs 510C to 510F. The received data is provided to the MUX 525, which selects the valid data and provides it to the MUX 555, which reorganizes the data and encapsulates the data into a data flit (e.g., a flit including the fields 480 and 485 of Figure 4B). Thus, when a write address is received from the AXI master, the header of the CPI packet of the write command is formed by the arbiter 560, and when write data is received, the body of the CPI packet is formed by the MUX 555. After the write address has been received into the AW FIFO and the write data has been received into the WFIFO, the completed CPI packet is provided to the CPI network. Figure 4
[0091] Figure 6 is a block diagram of a circuit 600 that converts a CPI packet into signals to an AXI master according to some embodiments of the disclosure. The circuit 600 includes a state machine 605; first-in-first-out (FIFO) buffers (also referred to as FIFOs) 630A, 630B, 630C, 630D, 675A, and 675B; registers 615A, 615B, 615C, 615D, 615E, 615F, and 640; multiplexers (MUXs) 620A, 620B, 620C, 620D, 620E, 620F, 620G, 680A, and 680B; an ECC checker 650; and mappers 685A and 685B. The components of the circuit 600 are connected via hardware traces, buses, or other physical connections. In some example embodiments, the circuit 500 is integrated with the circuit 600, and the individual components of the circuits 500 and 600 are also connected via hardware traces, buses, or other physical connections.
[0092] The left side of the circuit 600 is connected to an AXI master. The right side of the circuit 600 is connected to a CPI network. The circuit 600 receives a CPI packet from the CPI network and provides corresponding AXI signals to the AXI master.
[0093] Circuit 600 receives data from the CPI network using FIFOs 630A through 630D. The incoming data is also provided to registers 640 for processing by ECC checker 650. The received data is processed by one or more of MUXs 620A through 620G to set data in registers 615C through 615F if the received CPI packet contains read data; to send the appropriate RVALID, BVALID, and BLAST signals; and to map the transaction ID of the CPI packet to an AXI write response identifier (BID) or read data identifier (RID) using mappers 685A and 685B, which mapping has been established and recorded in the mappers when the master device issued a CPI request corresponding to the CPI response, and to send the appropriate signals on the write response channel or read data channel using registers 615A and 615B.
[0094] State machine 605 provides BVALID, RVALID, and RLAST signals to the AXI master device and receives BREADY and RREADY signals from the AXI master device. The BVALID signal, if raised, indicates that circuit 600 is providing write response signals in register 615A. The RVALID signal, if raised, indicates that circuit 600 is providing read data in one or more of registers 615B through 615F. The RLAST signal, if raised, indicates that the current read data is the last read transfer of a burst. The BREADY signal, if raised, indicates that the AXI master device is accepting write response signals from register 615A. The RREADY signal, if raised, indicates that the AXI master device is accepting read data from registers 615B through 615F. Thus, by using circuits 500 and 600, the AXI master device is enabled to communicate with other devices via the CPI network without modification of the AXI master device.
[0095] Figure 7 is a block diagram of circuit 700 that converts CPI packets to signals to an AXI slave device in accordance with some embodiments of the present disclosure. Circuit 700 includes: a state machine 705; FIFO buffers (also referred to as FIFOs) 710A, 710B, 710C, 710D, 775A, and 775B; registers 715A, 715B, 715C, 715D, 715E, 715F, and 735; multiplexers (MUXs) 720A, 720B, 720C, 720D, 720E, 720F, 720G, 780A, and 780B; an ECC checker 750; and mappers 785A and 785B. The components of circuit 700 are connected via hardware traces, buses, or other physical connections.
[0096] The right side of circuit 700 is connected to an AXI slave device. The left side of circuit 700 is connected to a CPI network. Circuit 700 receives read and write request packets from the CPI network and provides corresponding AXI signals to the AXI slave device.
[0097] CPI packets are received via FIFOs 710A-710D. A portion of the CPI packets are provided to register 735 for error checking by ECC checker 750. The received CPI packets are processed by MUXs 720A-720G to determine the command included in the CPI packet and to extract the address of the command. For example, mappers 785A and 785B can determine the identifier to use (e.g., a read address identifier (ARID) or a write address identifier (AWID)) based on the TID and command fields of the incoming CPI packet. The ID and address are provided to a corresponding FIFO (e.g., FIFO buffer 775A or 775B) and to a corresponding MUX 780A or 780B. The MUXs select between the output of the FIFO buffer and the current output of the mappers and provide the correct address for a read command to register 715A or the correct address for a write command to register 715B. Write data is provided in one or more of registers 715C-715F.
[0098] State machine 705 receives ARREADY, AWREADY, and WREADY signals from the AXI slave device. Each signal, if raised, indicates that the AXI master device is ready to receive the corresponding input. The ARREADY signal, if raised, indicates that the AXI master device is ready to receive a read address. The AWREADY signal, if raised, indicates that the AXI master device is ready to receive a write address. The WREADY signal, if raised, indicates that the AXI master device is ready to receive write data.
[0099] State machine 705 provides ARVALID, AWVALID, and WVALID signals to the AXI slave device, each of which can be raised to indicate that the corresponding input is valid or lowered to indicate that the corresponding input is not valid. The ARVALID signal, when raised, indicates that circuit 700 is providing a valid read address to register 715A. The AWVALID signal, when raised, indicates that circuit 700 is providing a valid write address to FIFO 715B. The WVALID signal, when raised, indicates that circuit 700 is providing valid write data to one or more of registers 715C-715F.
[0100] Thus, when both ARREADY and ARVALID signals are raised, the AXI slave processes the read address provided by circuit 700 in read address register 715A. Similarly, when both AWREADY and WVALID signals are raised, the AXI slave processes the write address provided by circuit 700 in write address FIFO 715B.
[0101] Figure 8 Figure 8 is a block diagram of circuit 800 that converts signals from an AXI slave into CPI packets, according to some embodiments of the present disclosure. Circuit 800 includes a state machine 805, FIFO buffers (also referred to as FIFOs) 830A, 830B, 830C, 830D, 830E, and 830F, registers 840, MUXs 825 and 855, an error correction code (ECC) generator 845, an arbiter 860, a memory 865 (e.g., RAM), and a credit updater 870. The components of circuit 800 are connected via hardware traces, buses, or other physical connections. In some example embodiments, circuit 700 is integrated with circuit 800, and the various components of circuits 700 and 800 are also connected via hardware traces, buses, or other physical connections.
[0102] The right side of circuit 800 is connected to an AXI slave. The left side of circuit 800 is connected to a CPI network. Circuit 800 receives AXI response signals from the AXI slave and provides corresponding CPI packets to the CPI network.
[0103] For a write response, no data needs to be sent back, only an acknowledgement that the write was successfully handled. Arbiter 860 verifies with credit updater 870 that sufficient credits are available on the virtual lane (e.g., virtual lane 1) corresponding to the write response and updates the available credits for the virtual lane. Each field of a CPI packet is statically defined by circuit 800 (e.g., source identifier) or dynamically defined by circuit 800 based on AXI signals (e.g., transaction ID, destination ID, command, and length of the response packet are determined using the BID provided by the AXI master to look up information (e.g., CPI transaction ID, source ID, and command) that was previously received in a corresponding CPI write request packet stored in memory 865). CPI packets are provided to MUX 855 and held in registers 840 for access by ECC generator 845. The generated CPI packets are provided to the CPI network.
[0104] Unlike the write response, the read response uses data. When both the RREADY and RVALID signals are raised, data is received by the circuit 800 from the AXI slave device in one or more of the FIFOs 830C to 830F. The received data is provided to the MUX 825, which selects the valid data and provides it to the MUX 855, which reorganizes the data and encapsulates the data into a data flit (e.g., a flit including the fields 480 and 485 of Figure 4 Thus, when read data is received from the AXI slave device, the header of the CPI packet of the read data response command is formed by both the arbitrator 860 and the memory 865, and the body of the CPI packet is formed by the MUX 855. Each field of the CPI packet is provided by the AXI master device (e.g., data), statically defined by the circuit 800 (e.g., source identifier), or dynamically defined by the circuit 800 based on AXI signals (e.g., using the RID provided by the AXI master device to look up information (e.g., CPI transaction ID, source ID, and command) that has been previously received in a corresponding CPI read request packet stored in the memory 865 to determine the transaction ID, destination ID, command, and length of the response packet). The completed CPI packet is provided to the CPI network.
[0105] The state machine 805 receives the BVALID, RVALID, and RLAST signals from the AXI slave device and provides the BREADY and RREADY signals to the AXI master device. The BVALID signal, if raised, indicates that the AXI slave device is providing write response signals to the buffer 830A. The RVALID signal, if raised, indicates that the AXI slave device is providing read data to one or more of the buffers 830B to 830F. The RLAST signal, if raised, indicates that the current read data is the last read transfer of a burst. The BREADY signal, if raised, indicates that the circuit 800 is accepting write response signals from the buffer 830A. The RREADY signal, if raised, indicates that the circuit 800 is accepting read data from the buffers 830B to 830F. Thus, by using the circuits 700 and 800, the AXI slave device is enabled to communicate with other devices via the CPI network without needing to modify the AXI slave device.
[0106] Figure 9 is a flowchart showing operations of a method 900 performed by a circuit in converting AXI signals into packets, according to some embodiments of the present disclosure. The method 900 includes operations 910, 920, 930, and 940. By way of example and not limitation, the method 900 is described as being performed by the devices of FIGS. 1-3 and 5-8 using the data packets of FIGS. 4 and 9. Figure 4
[0107] In operation 910, a circuit (e.g., the circuit 800 of FIGS. 1-3 and 5-8) receives a plurality of AXI signals from an AXI master device (e.g., the AXI master device 100 of FIGS. 1-3 and 5-8). Figure 5 circuit 500 or Figure 8 The AXI commands are received by the circuit 500 or 800 via AXI connections. For example, Figure 5 The AW* or AR* signals shown in FIG. 4 can be received by the circuit 500 and associated with write request or read request commands, respectively. As another example, Figure 8 The B* or R* signals shown in FIG. 4 can be received by the circuit 800 and associated with write response or read response commands, respectively.
[0108] Based on the AXI commands, in operation 920, the circuit selects a virtual lane. For example, virtual lane 0 can be selected for write requests, virtual lane 1 for write responses, virtual lane 2 for read requests, or virtual lane 3 for read responses.
[0109] In operation 930, the circuit generates a data packet indicating the virtual lane. For example, the data packet 400 can be generated, with the virtual lane indicated as part of the command field 430. For commands associated with an address (e.g., a read command to read from an address or a write command to write to the address, either of which can be received from an AXI master device), the address fields 435, 445, and 460 are populated with the address.
[0110] In operation 940, the circuit transmits the data packet via a bus. For example, the circuit 500 and the circuit 800 can be components of the memory controller chiplet 205, allowing the memory controller chiplet 205 to interface with both AXI devices and the chiplet network 285. Alternatively, the circuit 500 and the circuit 800 can be components of a different chiplet (e.g., chiplet 310D) in communication with a memory controller chiplet (e.g., chiplet 310A). Thus, AXI devices are enabled to communicate with chiplet devices using the chiplet network by using the circuit 500 and the circuit 800.
[0111] The method 900 can be used with protocols other than AXI and CPI, with minor modifications. For example, in a modified operation 910, the circuit receives a command of a first protocol via a first connection. The command can be received on a connection dedicated to commands (e.g., separate dedicated address lines for reads and writes). Alternatively, a signal indicating the command can be received (e.g., a multi-bit connection indicating one of a plurality of possible commands; two single-wire connections both low when no address is provided, one high when a read address is provided, and the other high when a write address is provided; or any suitable combination thereof), and in response to detecting the command, the address is read from a common connection.
[0112] Continuing with this modified example, in modified operation 920, the virtual lane is selected based on the first protocol command. In modified operation 930, the packet of the command is generated for the second protocol. In modified operation 940, the circuit transmits the data packet using the second protocol. Thus, by using modified method 900, a command received via the first protocol is converted into a packet using a virtual lane transmitted (e.g., via a network) using the second protocol. In some example embodiments, modified method 900 is used by a bridge between two packet-based networks of different protocols. In other example embodiments, modified method 900 is used to interface between a direct wired protocol (e.g., AXI) and a packet-based network using a protocol (e.g., CPI), as described for unmodified method 900.
[0113] Figure 10 A block diagram of an example machine 1000 is described utilizing which, in which, or by which any one or more of the techniques (e.g., methodologies) discussed herein can be implemented. As described herein, examples can include or can operate by logic or a number of components of machine 1000 or can be implemented by such components of machine 1000. Circuitry (e.g., processing circuitry) is a collection of circuits implemented in tangible
[0114] In alternative embodiments, the machine 1000 can operate as a standalone device or can be connected (e.g., networked) to other machines. In a networked deployment, the machine 1000 can operate in the capacity of a server machine, a client machine, or both in a server-client network environment. In an example, the machine 1000 can act as a peer machine in peer-to-peer (P2P) (or other distributed) network environment. The machine 1000 can be a personal computer (PC), a tablet PC, a set-top box (STB), a personal digital assistant (PDA), a mobile telephone, a web appliance, a network router, switch or bridge, or any machine capable of executing instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term "machine" shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein, such as cloud computing, software as a service (SaaS), other computer cluster configurations.
[0115] The machine (e.g., computer system) 1000 can include a hardware processor 1002 (e.g., a central processing unit (CPU), a graphics processing unit (GPU), a hardware processor core, or any combination thereof), a main memory 1004, a static memory (e.g., memory or storage for firmware, microcode, a basic-input- output (BIOS), unified extensible firmware interface (UEFI) or the like) 1006, and mass storage 1008 (e.g., hard disk drive, tape drive, flash storage or other block devices), some or all of which can communicate with one another via an interlink (e.g., bus) 1030. The machine 1000 can further include a display unit 1010, an alphanumeric input device 1012 (e.g., a keyboard), and a user interface (UI) navigation device 1014 (e.g., a mouse). In an example, the display unit 1010, input device 1012 and UI navigation device 1014 can be a touch screen display. The machine 1000 can additionally include a storage device (e.g., drive unit) 1008, a signal generation device 1018 (e.g., a speaker), a network interface device 1020, and one or more sensors 1016, such as a global positioning system (GPS) sensor, compass, accelerometer, or other sensor. The machine 1000 can include an output controller 1028, such as a serial (e.g., universal serial bus (USB), parallel, or other wired or wireless (e.g., infrared (IR), near field communication (NFC), etc.) connection to communicate or control one or more peripheral devices (e.g., a printer, card reader, etc.).
[0116] The registers of the processor 1002, the main memory 1004, a static memory 1006, or the mass storage device 1008 can be, or include, machine -readable media 1022 on which are stored one or more sets of data structures or instructions 1024 (e.g., software) embodying or utilized by any one or
[0117] The term“machine-readable medium” can include a single medium or multiple media (e.g., a centralized or distributed database, or associated caches and servers) configured to store the one or more instructions 1024 for execution by, or to store data structures, tables, metadata structures, or other data used by, the machine 1000. The term“machine-readable medium” shall also include any media that are capable of storing or encoding a sequence of instructions for execution by the machine 1000 and that cause the machine 1000 to perform any one or more of the techniques of the present disclosure, alone or in combination with other machines. A machine- readable medium can include storage integrated with a machine, such as machine- readable medium 1022. A machine-readable medium can also include storage external to a machine, such as a storage device 1008 coupled to machine 1000 through external interface 1020. A machine -readable medium can include any one or more of the following: a semiconductor-based or other integrated circuit (IC), a floppy disk, a flexible disk, a hard disk, a Solid State Drive (SSD), a magnetic-holographic disk, a
[0118] In examples, information stored or otherwise provided on machine-readable medium 1022 can be in a format that represents instructions 1024, such as the instructions 1024 themselves or a format from which the instructions 1024 can be derived. Such a format from which the instructions 1024 can be derived can include source code, encoded instructions (e.g., in a compressed or encrypted form), encapsulated instructions (e.g., divided into multiple packages), or the like. Information representing instructions 1024 in machine-readable medium 1022 can be processed by processing circuitry into instructions for implementing any of the operations discussed herein. For example, deriving instructions 1024 from information (e.g., processing by processing circuitry) can include compiling (e.g., from source code, object code, etc.), interpreting, loading, organizing (e.g., dynamically or statically linking), encoding, decoding, encrypting, decrypting, encapsulating, decapsulating, or otherwise manipulating the information into instructions 1024.
[0119] In examples, derivation of instructions 1024 can include assembly, compilation, or interpretation of information (e.g., by processing circuitry) to create instructions 1024 from some intermediate or preprocessed format provided by machine-readable medium 1022. Information, when provided in multiple parts, can be combined, unpacked, and modified to create instructions 1024. For example, information can be in multiple compressed source code packages (or object code or binary executable code, etc.) on one or several remote servers. The source code packages can be encrypted when transported over a network and decrypted, decompressed, assembled (e.g., linked), and compiled or interpreted (e.g., compiled or interpreted into a library, standalone executable, etc.) at a local machine as necessary and executed by the local machine.
[0120] Instructions 1024 can further be transmitted or received using a transmission medium via the network interface device 1020 utilizing any one of a number of transfer protocols (e.g., frame relay, internet protocol (IP), transmission control protocol (TCP), user datagram protocol (UDP), hypertext transfer protocol (HTTP), etc.). Example communication networks can include a local area network (LAN), a wide area network (WAN), a packet data network (e.g., the Internet), mobile telephone networks (e.g., cellular networks), Plain Old Telephone (POTS) networks, and wireless data networks (e.g., Institute of Electrical and Electronics Engineers (IEEE) 802.11 family of standards known as Wi-Fi®, IEEE 802.16 family of standards known as WiMax®), IEEE 802.15.4 family of standards, peer-to-peer (P2P) networks, among others. Bluetooth® Low Energy, ZigBee®, Wi-Fi®, WiMAX, and / or the like. The network interface device 1020 can include one or more physical jack s (such as Ethernet, coaxial, or phone jacks) or one or more antennas to connect to the communications network 1026. In an example, the network interface device 1020 can include multiple antennas to communicate using at least one of single-input multiple-output (SIMO), multiple-input multiple-output (MIMO), or multiple-input single-output (MISO) techniques. The term“transmission medium” shall be taken to include any intangible medium that is capable of storing, encoding or carrying the instructions of the machine 1000, and includes digital or analog communications signals or other intangible media to facilitate communication of such software. The transmission medium is a machine-readable medium.
[0121] In the foregoing specification, some example embodiments of the disclosure have been described. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense. The following is a non-exhaustive list of examples of implementations of the disclosure.
[0122] Example 1 is a system comprising: an interface to a physical lane; a bus interface to a bus; and logic configured to perform operations comprising: detecting a ready signal on the physical lane via the interface; identifying a command based on detecting the ready signal on the physical lane; selecting a virtual lane based on the command; generating a data packet indicative of the virtual lane; and transmitting the data packet via the bus interface.
[0123] In Example 2, the subject matter of Example 1 includes, wherein the transmitting of the data packet comprises transmitting the data packet to a memory controller chip.
[0124] In Example 3, the subject matter of Examples 1-2 includes, wherein: the selecting of the virtual lane based on the command comprises selecting virtual lane 2 based on the command being a read request.
[0125] In Example 4, the subject matter of Examples 1-3 includes, wherein: the interface to the physical lane is a first interface to a first physical lane; the system further comprises: a second interface to a second physical lane; the operations further comprise: receiving an address associated with the command from a master device via the second interface; and the data packet is further indicative of the address.
[0126] In Example 5, the subject matter of Example 4 includes, wherein: the receiving of the address is based on the detecting of the ready signal.
[0127] In Example 6, the subject matter of Examples 1-5 includes, wherein: the interface to the physical channel is a first interface to a first physical channel; the system further comprises: a second interface to a second physical channel; the operations further comprise: receiving a response associated with the command from a secondary device via the second interface; and the data packet is further indicative of the response.
[0128] In Example 7, the subject matter of Examples 1-6 includes, wherein: the interface to the physical channel is a first interface to a first physical channel; the system further comprises: a second interface to a second physical channel; the operations further comprise: receiving data associated with the command via the second interface; and the generated data packet further comprises the data.
[0129] In Example 8, the subject matter of Examples 1-7 includes, wherein: the selection of the virtual channel based on the command comprises selecting virtual channel 0 based on the command being a write request.
[0130] Example 9 is a method comprising: detecting a ready signal on a physical channel via an interface to the physical channel; identifying a command based on detecting the ready signal on the physical channel; selecting a virtual channel based on the command; generating a data packet indicative of the virtual channel; and transmitting the data packet via a bus.
[0131] In Example 10, the subject matter of Example 9 includes, wherein the transmitting of the data packet comprises transmitting the data packet to a memory controller chiplet.
[0132] In Example 11, the subject matter of Examples 9-10 includes, wherein: the selection of the virtual channel based on the command comprises selecting virtual channel 2 based on the command being a read request.
[0133] In Example 12, the subject matter of Examples 9-11 includes, wherein: the interface to the physical channel is a first interface to a first physical channel; the method further comprises: receiving an address associated with the command from a primary device via a second interface to a second physical channel; and the data packet is further indicative of the address.
[0134] In Example 13, the subject matter of Example 12 includes, wherein: the receiving of the address is based on the detecting of the ready signal.
[0135] In Example 14, the subject matter of Examples 9-13 includes, wherein: the interface to the physical lane is a first interface to a first physical lane; the method further comprises: receiving a response associated with the command from a secondary device via a second interface to a second physical lane; and the data packet is further indicative of the response.
[0136] In Example 15, the subject matter of Examples 9-14 includes, wherein: the interface to the physical lane is a first interface to a first physical lane; the method further comprises: receiving data associated with the command via a second interface to a second physical lane; and the generated data packet further comprises the data.
[0137] In Example 16, the subject matter of Examples 9-15 includes, wherein: the selection of the virtual lane based on the command comprises selecting virtual lane 0 based on the command being a write request.
[0138] Example 17 is a non-transitory machine-readable medium storing instructions that, when executed by a system, cause the system to perform operations comprising: detecting a ready signal on a physical lane via an interface to the physical lane; identifying a command based on detecting the ready signal on the physical lane; selecting a virtual lane based on the command; generating a data packet indicative of the virtual lane; and transmitting the data packet via a bus.
[0139] In Example 18, the subject matter of Example 17 includes, wherein the transmission of the data packet comprises transmitting the data packet to a memory controller chiplet.
[0140] In Example 19, the subject matter of Examples 17-18 includes, wherein: the selection of the virtual lane based on the command comprises selecting virtual lane 2 based on the command being a read request.
[0141] In Example 20, the subject matter of Examples 17-19 includes, wherein: the interface to the physical lane is a first interface to a first physical lane; the operations further comprise: receiving an address associated with the command from a primary device via a second interface to a second physical lane; and the data packet is further indicative of the address.
[0142] In Example 21, the subject matter of Example 20 includes, wherein: the receiving of the address is based on the detection of the ready signal.
[0143] In Example 22, the subject matter of Examples 17-21 includes, wherein: the interface to the physical channel is a first interface to a first physical channel; the operations further comprise: receiving a response associated with the command from a secondary device via a second interface to a second physical channel; and the data packet further indicates the response.
[0144] In Example 23, the subject matter of Examples 17-22 includes, wherein: the interface to the physical channel is a first interface to a first physical channel; the operations further comprise: receiving data associated with the command via a second interface to a second physical channel; and the generated data packet further comprises the data.
[0145] In Example 24, the subject matter of Examples 17-23 includes, wherein: the selection of the virtual channel based on the command comprises selecting virtual channel 0 based on the command being a write request.
[0146] Example 25 is at least one machine readable medium including instructions that, when executed by processing circuitry, cause the processing circuitry to perform operations to implement any of Examples 1-24.
[0147] Example 26 is an apparatus comprising means for implementing any of Examples 1-24.
[0148] Example 27 is a system for implementing any of Examples 1-24.
[0149] Example 28 is a method for implementing any of Examples 1-24.
Claims
1. A chiplet system, comprising: an interface to a physical lane; a bus interface to a bus; and logic configured to perform operations comprising: detecting a ready signal on the physical lane via the interface to the physical lane; based on detecting the ready signal on the physical lane, identifying a command; based on the command, selecting a virtual lane; generating a data packet indicative of the virtual lane; and transmitting the data packet to a memory controller chiplet integrated on a interposer via the bus interface.
2. The chiplet system of claim 1, wherein: the selection of the virtual lane based on the command comprises selecting virtual lane 2 based on the command being a read request.
3. The chiplet system of claim 1, wherein: the interface to the physical lane is a first interface to a first physical lane; the chiplet system further comprises: a second interface to a second physical lane; the operations further comprise: receiving an address associated with the command from a master device via the second interface; and the data packet is further indicative of the address.
4. The chiplet system of claim 3, wherein: the receiving of the address is based on the detecting of the ready signal.
5. The chiplet system of claim 1, wherein: the interface to the physical lane is a first interface to a first physical lane; the chiplet system further comprises: a second interface to a second physical lane; the operations further comprise: receiving a response associated with the command from a secondary device via the second interface; and the data packet is further indicative of the response.
6. The chiplet system of claim 1, wherein: the interface to the physical lane is a first interface to a first physical lane; the chiplet system further comprises: a second interface to a second physical lane; the operations further comprise: receiving data associated with the command via the second interface; and the generated data packet further comprises the data.
7. The chiplet system of claim 1, wherein: the selection of the virtual lane based on the command comprises selecting virtual lane 0 based on the command being a write request.
8. The chiplet system of claim 1, wherein the bus interface is connected to a chiplet mesh network.
9. A method for operating a chiplet system, comprising: detecting a ready signal on a physical lane via an interface to the physical lane; based on detecting the ready signal on the physical lane, identifying a command; based on the command, selecting a virtual lane; generating a data packet indicative of the virtual lane; and transmitting the data packet to a memory controller chiplet integrated on a interposer via a bus.
10. The method of claim 9, wherein: the selection of the virtual lane based on the command comprises selecting virtual lane 2 based on the command being a read request.
11. The method of claim 9, wherein: the interface to the physical lane is a first interface to a first physical lane; The method further includes: receiving an address associated with the command from a master device via a second interface to a second physical lane; and the data packet further indicates the address.
12. The method of claim 11, wherein: the receiving of the address is based on the detection of the ready signal.
13. The method of claim 9, wherein: the interface to the physical lane is a first interface to a first physical lane; the method further includes: receiving a response associated with the command from a secondary device via a second interface to a second physical lane; and the data packet further indicates the response.
14. The method of claim 9, wherein: the interface to the physical lane is a first interface to a first physical lane; the method further includes: receiving data associated with the command via a second interface to a second physical lane; and the generated data packet further includes the data.
15. The method of claim 9, wherein: the selection of the virtual lane based on the command includes selecting virtual lane 0 based on the command being a write request.
16. The method of claim 9, wherein a bus interface to the bus is connected to a mesh network of small chiplets.
17. A non-transitory machine-readable medium storing instructions that, when executed by a system, cause the system to perform operations comprising: detecting a ready signal on a physical lane via an interface to the physical lane; based on detecting the ready signal on the physical lane, identifying a command; based on the command, selecting a virtual lane; generating a data packet indicating the virtual lane; and transmitting the data packet via a bus to a memory controller small chiplet integrated on an interposer.
18. The non-transitory machine-readable medium of claim 17, wherein: the selection of the virtual lane based on the command includes selecting virtual lane 2 based on the command being a read request.
19. The non-transitory machine-readable medium of claim 17, wherein: the interface to the physical lane is a first interface to a first physical lane; the operations further include: receiving an address associated with the command from a master device via a second interface to a second physical lane; and the data packet further indicates the address.
20. The non-transitory machine-readable medium of claim 19, wherein: the receiving of the address is based on the detection of the ready signal.
21. The non-transitory machine-readable medium of claim 17, wherein: the interface to the physical lane is a first interface to a first physical lane; the operations further include: receiving a response associated with the command from a secondary device via a second interface to a second physical lane; and the data packet further indicates the response.
22. The non-transitory machine-readable medium of claim 17, wherein: the interface to the physical lane is a first interface to a first physical lane; the operations further include: receiving data associated with the command via a second interface to a second physical lane; and the generated data packet further includes the data.
23. The non-transitory machine-readable medium of claim 17, wherein: the selection of the virtual lane based on the command comprises selecting virtual lane 0 based on the command being a write request.
24. The non-transitory machine-readable medium of claim 17, wherein a bus interface to the bus is connected to a mesh network of small chips.
Citation Information
Patent Citations
Separating transactions into different virtual channels
US20050251612A1
A method and device for improved advanced microcontroller bus architecture (AMBA) and advanced extensible interface (AXI) operations
WO2017196143A1