JP7457654B2 - Steps for implementing source-based routing within an interconnect fabric on a system-on-chip - Google Patents

Description

Cross-references to related applications This application is incorporated by reference to U.S. Provisional Patent Application No. 62/650,589 (PRTIP001P) filed March 30, 2018 and U.S. Provisional Patent Application No. 62/800,897 (filed February 4, 2019). PRT1P003P). Each of these priority underlying applications is incorporated herein by reference in its entirety for all purposes.

This application relates to arbitrating access to a shared resource, and in particular to arbitrating between portions of multiple transactions and transmitting the winning portion over one of multiple virtual channels associated with an interconnect every clock cycle.

A system-on-a-chip (“SoC”) is an integrated circuit that includes multiple subsystems, often referred to as an intellectual property (“IP”) agent or core. IP agents are typically "reusable" blocks of circuitry designed to implement or perform a specific function. SoC developers typically lay out and interconnect multiple IP agents on a chip so that they communicate with each other. Using IP agents can significantly reduce the time and cost of developing complex SoCs.

One of the challenges faced by SoC developers is interconnecting various IP agents on a chip so that they work with each other. To address this problem, the semiconductor industry has adapted interconnect standards.

One such standard is the Advanced Microcontroller Bus Architecture (AMBA), developed and popularized by ARM Ltd. of Cambridge, England. AMBA is a widely used bus interconnect standard for connecting and managing functional IP agents on SoCs.

In AMBA, a transaction defines a request and requires a separate response transaction. In a write transaction, a source requests to write data to a remote destination. Once the write operation is performed, the destination sends an acknowledgment transaction back to the source. A write operation is considered complete only when a response transaction is received by the sender. In a read transaction, a source requests access to read a remote location. A read transaction is only completed when the response transaction (ie, the accessed content) is returned to the source.

In AMBA, arbitration processing is used to grant access to an interconnect bus between multiple competing transactions. During a given arbitration cycle, one of the competing transactions is selected as the winner. The interconnect bus is then controlled for the duration of the data portion of the winning transaction. The next arbitration cycle begins only after all data for the current transaction is completed. This process is repeated continuously provided there are multiple outstanding transactions competing for access to the interconnect.

One problem with the AMBA standard is latency. The bus interconnect is arbitrated on a transaction-by-transaction basis. During any part of a transaction, whether the transaction is a read, write, or response, the bus is controlled for the entire transaction. Once a transaction has started, it cannot be interrupted. For example, if the data portion of a transaction is four cycles long, all four cycles must complete before another transaction can access the bus. As a result, (1) transactions cannot be arbitrated every clock cycle, and (2) all non-winning conflicting transactions must wait until the data portion of the current transaction is complete. Both of these factors tend to reduce the efficiency of the interconnect and the overall performance of the SoC.

Arbitration systems and methods are disclosed for arbitrating access to shared interconnects among multiple subsystems on a system-on-chip or SoC. Arbitration systems and methods each clock cycle: (1) arbitrate between portions of multiple transactions generated by multiple subsystems; (2) select a winning portion among the portions of multiple transactions; (3) comprising an arbitration element configured to transmit the winning portion via one of a plurality of virtual channels associated with the interconnect;

By repeatedly performing (1)-(3), multiple winning portions are transmitted over multiple virtual channels, each interleaved over multiple clock cycles. Arbitrating multiple transaction parts over multiple virtual channels every clock cycle provides many benefits, including reduced latency and increased interconnect efficiency and utilization. These attributes make the arbitration system and method disclosed herein well suited for arbitrating access to interconnects on a system-on-chip (SoC).

The present application and its advantages are best understood by reference to the following description taken in conjunction with the accompanying drawings.

1 is a block diagram illustrating a shared interconnect for a system-on-chip (SoC) in accordance with non-exclusive embodiments; FIG.

FIG. 6 is a diagram illustrating an example packet of a transaction, in accordance with a non-exclusive embodiment.

4 is a logic diagram illustrating an arbitration element according to a first non-exclusive embodiment.

FIG. 7 is a logic diagram illustrating arbitration elements in accordance with a second non-exclusive embodiment.

5 is a flowchart illustrating operational steps for arbitrating and transmitting portions of a transaction over a virtual channel of a shared interconnect, in accordance with a non-exclusive embodiment.

FIG. 3 is a diagram illustrating a first example of interleaving transmissions of parts of different transactions over virtual channels of a shared interconnect, according to a non-exclusive embodiment;

FIG. 13 illustrates a second example of interleaving the transmission of parts of different transactions over virtual channels of a shared interconnect, according to a non-exclusive embodiment.

FIG. 3 is a block diagram illustrating two shared interconnects for handling traffic in two directions, according to another non-exclusive embodiment of the invention.

FIG. 2 is a block diagram illustrating an example interconnection fabric of a SoC, in accordance with non-exclusive embodiments of the invention.

FIG. 3 is a diagram illustrating a look-up table (LUT) used to resolve both physical addresses and source-based routing (SBR) addresses to one or more IP ports, in accordance with non-exclusive embodiments of the invention.

FIG. 2 is a diagram illustrating available hash functions in accordance with non-exclusive embodiments of the invention.

FIG. 2 is a diagram illustrating the expansion and consolidation of transactions sent over the interconnection fabric of an SoC, in accordance with non-exclusive embodiments of the present invention. FIG. 2 is a diagram illustrating the expansion and consolidation of transactions sent over the interconnection fabric of an SoC, in accordance with non-exclusive embodiments of the present invention.

FIG. 3 is a diagram illustrating trunking links and the selection of physical links among the trunking links, according to a non-exclusive embodiment of the invention. FIG. 2 illustrates trunking links and selection of physical links from among the trunking links in accordance with a non-exclusive embodiment of the present invention.

Like symbols may be used in the drawings to designate like structural elements. It should also be understood that the depictions in the figures are schematic and are not necessarily to scale.

The present application is described in detail below with reference to several non-exclusive embodiments illustrated in the accompanying drawings. In the following description, numerous specific details are set forth to facilitate a thorough understanding of the present disclosure. However, it will be apparent to one of ordinary skill in the art that the present disclosure may be practiced without some or all of these specific details. Additionally, detailed descriptions of well-known process steps and/or structures have been omitted to avoid unnecessarily obscuring the present disclosure.

Many of the integrated circuits currently being developed are highly complex. As a result, many chip designers have used a system-on-chip or "SoC" approach to interconnect multiple subsystems or IP agents on a single silicon. Consumer devices (e.g., handhelds, mobile phones, tablet computers, laptop and desktop computers, media processing, etc.), virtual or augmented reality (e.g., robotics, autonomous vehicles, aircraft, etc.), medical equipment (e.g., imaging, etc.) ), industrial home automation, industrial (e.g. smart home appliances, home monitoring equipment, etc.) and data center applications (e.g. network switches, connected storage devices, etc.) available or being developed.

The present application is generally directed to arbitration systems and methods for arbitrating access to shared resources. Such shared resources may be, for example, bus interconnects, memory resources, processing resources, or nearly any other resource shared among multiple competing parties. For purposes of explanation, the shared resources detailed below are interconnects shared by multiple subsystems on a system-on-chip or "SoC."

In a SoC, as described in more detail below, there are multiple subsystems that exchange traffic with each other in the form of transactions, the shared resource is a physical interconnect, various transactions or portions thereof are transmitted over multiple virtual channels associated with the shared interconnect, and one of multiple different arbitration schemes and/or priorities may be used to arbitrate access to the shared interconnect for transmission of transactions between subfunctions.

There are at least three types or classes of transactions within the above-mentioned shared interconnect used in the transaction class SoC, including Posted (P), Non-posted (NP), and Completion (C). A brief definition of each is provided in Table 1 below.

Posted transactions (such as writes) do not require a response transaction. Once the source writes the data to the specified destination, the transaction is complete. Non-posted transactions (such as either reads or writes) do require a response. However, the response is forked as a separate Completion transaction. In other words, for a read, an initial transaction is used for the read operation and a separate but related Completion transaction is used to return the read contents. For a non-posted write, an initial transaction is used for the write, while once the write is complete, a second related Completion transaction is required for confirmation.

A transaction, regardless of type, can be represented by one or more packets. In some situations, a transaction may be represented by a single packet. In other situations, multiple packets may be required to represent the entire transaction.

A beat is the amount of data that can be transmitted over a shared interconnect per clock cycle. For example, if the shared interconnect is physically 128 bits wide, 128 bits may be transmitted in each beat or clock cycle.

In some situations, a transaction may need to be split into multiple parts for transmission. Consider a transaction that has a single packet with a payload that is 512 bits (64 bytes). If the shared interconnect is only 128 bits wide (16 bytes), then the transaction needs to be split into four parts (e.g., 4 x 128 = 512) and transmitted in four clock cycles or beats. On the other hand, if the transaction is only a single packet that is less than 128 bits wide, the entire transaction may be sent in one clock cycle or beat. If the same transaction happens to include additional packets, additional clock cycles or beats may be required.

Thus, the term "portion" of a transaction is the amount of data that can be transferred across a shared interconnect during a given clock cycle or beat. The size of the portion may vary depending on the physical width of the shared interconnect. For example, if the shared interconnect is physically 64 data bits wide, then the maximum number of bits that can be transferred during any one cycle or beat is 64 bits. If a given transaction has a payload of 64 bits or less, the entire transaction may be sent over the shared interconnect in a single part. On the other hand, if the payload is larger, the packet must be sent over the shared interconnect in multiple parts. Transactions with payloads of 128, 256, or 512 bits require 2, 4, and 8 parts, respectively. As such, the term "part" should be broadly interpreted to mean either part or the entire transaction that may be sent over a shared interconnect during any given clock cycle or beat. .

Streams A stream is defined as a pairing of a virtual channel and a transaction class. For example, if there are four virtual channels (e.g., VC0, VC1, VC2, and VC3) and three transaction classes (P, NP, C), there are a maximum of 12 different possible streams. The various combinations of virtual channels and transaction classes are detailed in Table 2 below.

Note that the number of transaction classes described above is merely illustrative and should not be construed as limiting. Conversely, any number of virtual channels and/or transaction classes may be used.

Arbitration on Virtual Channels of a Shared Interconnect Referring now to Figure 1, there is shown a block diagram of an arbitration system 10. In a non-exclusive embodiment, the arbitration system is used to arbitrate access to a shared interconnect 12 by multiple subfunctions 14 (i.e., IP1, IP2, and IP3) attempting to send transactions to upstream subfunctions 14 (i.e., IP4, IP5, and IP6).

Shared interconnect 12 is a physical interconnect that is N data bits wide and includes M control bits. Also, shared interconnect 12 is unidirectional, which handles traffic only in the direction from sources (i.e., IP1, IP2, and IP3) to destinations (i.e., IP4, IP5, and IP6). It means that.

In various alternatives, the number of N data bits may be any integer number, but are typically each a power of two bit wide (e.g., 21, 22, 23, 24, 25, 26, 27, 28, 29, etc.) or (2, 4, 6, 8, 16, 32, 64, 128, 256, etc.). In most practical applications, the number of N bits is either 32, 64, 128, 256, or 512. However, it is to be understood that these widths are merely illustrative and should not be construed as limiting in any way.

The number M of control bits also varies and may be any number.

One or more logical channels (not shown) (hereinafter referred to as “virtual channels” or “VCs”) are associated with shared interconnect 12. Each virtual channel is independent. Each virtual channel may be associated with multiple independent streams. The number of virtual channels may vary widely. For example, up to 32 or more virtual channels may be defined or associated with shared interconnect 12.

In various alternative embodiments, each virtual channel may be assigned a different priority. One or more virtual channels may be assigned a higher priority, while one or more other virtual channels may be assigned a lower priority. High priority channels are given or arbitrated more access to the shared interconnect 12 than lower priority virtual channels. In another embodiment, each of the virtual channels may be given the same priority, in which case one virtual channel is prioritized over another when granting or arbitrating access to the shared interconnect 12. There is no priority. In yet another embodiment, the priority assigned to one or more of the virtual channels may change dynamically. For example, in a first set of situations, all virtual channels may be assigned the same priority, but in a second set of situations, certain virtual channels may be assigned a higher priority than other virtual channels. Good too. Therefore, as circumstances change, the priority scheme used between virtual channels may be changed to best suit current operating conditions.

Each of the subsystems 14 is typically a "reusable" block of circuitry or logic and is commonly referred to as an IP core or agent. Most IP agents are designed to perform specific functions, such as controllers for peripheral devices such as Ethernet ports, display drivers, SDRAM interfaces, USB ports, etc. Such IP agents typically provide necessary subsystem functionality within the overall design of a complex system provided on an integrated circuit (IC) such as an application specific integrated circuit (ASIC) or a field programmable gate array (FPGA). used as a "building block" to provide By using the library of available IP agents, chip designers can easily "bolt" various logic functions in more complex integrated circuit designs, reducing design time and development costs. can be saved. Although subsystem agent 14 is described above with respect to a dedicated IP core, it should be understood that this is not a requirement. Conversely, subsystem 14 may be a collection of IP functions connected to or sharing a single port 20. Therefore, the term "agent" should be broadly interpreted as any type of subsystem connected to port 20, whether the subsystem performs a single function or multiple functions. It is.

A pair of switches 16 and 18 each provide access between each of the subsystem agents 14 and the shared interconnect 12 via a dedicated access port 20. In the exemplary embodiment of the figure:
(1) Subsystem agents IP1, IP2, and IP3 are connected to the switch 16 via access Port0, Port1, and Port2, respectively.
(2) Subsystem agents IP4, IP5, and IP6 are connected to the switch 18 via Port3, Port4, and Port5, respectively.
(3) Additionally, access port 22 provides access for subsystem agents IP4, IP5, and IP6 to switch 16 as a whole via interconnect 12.

Switches 16 and 18 perform multiplexing and demultiplexing functions. Switch 16 selects upstream traffic generated by subsystem agents IP1, IP2, and/or IP3 and sends the traffic downstream via shared interconnect 12. At switch 18, a demultiplexing operation is performed and the traffic is provided to the target subsystem agent (ie, either IP4, IP5, or IP6).

Each access port 20 has a unique port identifier (ID) and provides each subsystem agent 14 dedicated access to either switch 16 or 18. For example, subsystem agents IP1, IP2, and IP3 are assigned to access ports Port0, Port1, and Port2, respectively. Similarly, subsystem agents IP4, IP5, and IP6 are assigned to access ports Port3, Port4, and Port5, respectively.

In addition to providing entry and exit points to/from switches 16, 18, unique port ID 20 is used to address traffic between subsystem agents 14. Each port 20 has a specific amount of allocated addressable space within system memory 24.

In some non-exclusive embodiments, all or some of the access ports 20 may be assigned a "global" port identifier as well as a unique port ID. Transactions and other traffic may be sent to all or some of the access ports assigned to the global port identifier. Thus, global identifiers allow transactions and other traffic to be broadly originated or broadcast to all or some of the access ports 20, eliminating the need to individually address each access port 20 with a unique identifier. Can be eliminated.

Switch 16 further includes an arbitration element 26, an address resolution logic (ARL) 28, and an address resolution lookup table (LUT) 30.

During operation, subsystem agents IP1, IP2, and IP3 generate transactions. As each transaction is generated, it is packetized by the sending subsystem 14, and the packetized transaction is then injected into the local switch 16 via the corresponding port 20. For example, the portions of the transactions generated by IP1, IP2, and IP3 are provided to the switch 16 via Port 0, Port 1, and Port 2, respectively.

Each port 20 includes a number of first-in, first-out buffers (not shown) for each of the virtual channels associated with the interconnect channel 12. In a non-exclusive embodiment, there are four virtual channels. Then, each port 20 includes four buffers, one for each virtual channel. Again, it should be understood that the number of virtual channels and buffers included in a port 20 may vary and is not limited to four. Conversely, the number of virtual channels and buffers may be more or less than four.

If a given transaction is represented in two (or more) parts, those parts are maintained in the same buffer. For example, if interconnect 12 is 128 data bits wide and a transaction is represented by a packet containing a 512-bit payload, then the transaction needs to be split into four parts that are transmitted in four clock cycles or beats. On the other hand, if a transaction can be represented by a single packet with a 64-bit payload, then a single part can be transmitted in one clock cycle or beat. By maintaining all parts of a given transaction in the same buffer, the virtual channels remain logically independent. In other words, all traffic associated with a given transaction is always sent on the same virtual channel as the stream and is never branched through multiple virtual channels.

Arbitration element 26 is responsible for arbitrating between competing buffered portions of transactions maintained by various access ports 20. In non-exclusive embodiments, arbitration element 26 performs arbitration every clock cycle if multiple competing transactions are available. A cycle-by-cycle arbitration winner is granted access to interconnect 12 and generates a portion of a transaction to be transmitted over interconnect 12 from one of subsystems IP1, IP2, and IP3.

When generating a transaction, the source subsystems IP1, IP2, and IP3 typically know the addresses in the address space for possible destination subsystem agents IP4, IP5, and IP6, but do not send the transaction to the destination. It does not know the information needed to route (eg, port ID 20 and/or 22). In one embodiment, local address resolution logic (ARL) 28 is used to resolve known destination addresses into the necessary routing information. In other words, source subagent 14 may simply know that it wishes to access a given address in system memory 24. ARL 28 is therefore tasked with accessing LUT 30 and performing an address lookup for port 20/22 along the delivery path to the final destination corresponding to the specified address. Once the port 20/22 is known, this information is inserted into the destination field within the transaction's packet. As a result, the packet is delivered to port 20/22 along the delivery path. In principle, downstream nodes along the delivery path do not need to perform further lookups since the requested delivery information is already known and included in the destination field of the packet. In another type of transaction called source-based routing (SBR), as detailed below, the source P-agent learns the destination port address. As a result, lookups performed by ARL 28 typically do not need to be performed.

In alternative embodiments, not all nodes in the interconnect require ARL 28 and LUT 30. For nodes that do not have these elements, transactions without the necessary routing information may be forwarded to the default node. At the default node, ARL 28 and LUT 30 may be accessed and the necessary routing information may then be inserted into the header of the transaction's packet. The default node is typically upstream from the node that does not have ARL 28 and LUT 30. However, this is by no means essential. One or more default nodes may be located anywhere on the SoC. By eliminating ARL 28 and LUT 30 from some nodes, node complexity can be reduced.

ARL 28 may be referred to as an "ordering point" because it defines the order for the winning portion of a transaction within each virtual channel, in addition to decoding the destination for the winning portion of the transaction. As each arbitration is resolved, the winning portion of the transaction is inserted into a first-in, first-out queue provided to each virtual channel, regardless of whether ARL 28 is used to perform address port lookups. The winning portion of the transaction then waits in a buffer for its turn for transmission over interconnect 12.

ARL 28 is also used to define "upstream" and "downstream" traffic. In other words, any transactions generated by IP agents 14 (ie, IP1, IP2, and IP3) associated with switch 16 are considered upstream to ARL 28. All transactions after ARL 28 (ie, transmitted to IP4, IP5, and IP6) are considered downstream traffic.

IP agents 14 (ie, IP1, IP2, and IP3) associated with switch 16 may communicate with each other and send transactions to each other, either directly or indirectly. Direct communication (often referred to as source-based routing (SBR)) allows IP agents 14 to send transactions to each other in a peer-to-peer model. In this model, the source IP agent knows the unique port ID of its peer IP agent 14, eliminating the need to use ARL 28 to access LUT 30. Alternatively, transactions between IP agents associated with switch 16 may be routed using ARL 28. In this model, as described above, the source IP agent only knows the address of the destination IP agent 14 and does not know the information necessary for routing. ARL 28 is then used to access LUT 30 and find the corresponding port ID, which is then inserted into the destination field of the transaction's packet.

Packet format IP agent 14 generates and processes transactions over virtual channels associated with interconnect 12. Each transaction typically consists of one or more packets. Each packet typically has a fixed header size and format. In some examples, each packet may have a fixed size payload. In another example, the packet payload may vary in size from large to small, or there may be no payload at all.

With reference to FIG. 2, an example packet 32 is shown. The packet 32 comprises a header 34 and a payload 36. In this particular embodiment, the header 34 is 16 bytes in size. It should be understood that this size is exemplary and that packets of larger (e.g., more bytes) or smaller (e.g., fewer bytes) sizes may be used. It should also be understood that the headers 34 of the packet 32 do not all have to be the same size. In alternative embodiments, the size of the packet headers in the SoC may be variable.

The header 34 includes a destination identifier (DST_ID), a source identifier (SRC_ID), a payload size indicator (PLD_SZ), a reserved field (RSVD), a command field (CMD), a TAG field, a status (STS), and a transaction ID field (TAG). , an address or ADDR field, a USDR/compact payload field, a transaction class or TC field, a format FMT field, and a byte enable (BE) field. The various fields of header 34 are briefly described in Table 3 below.

Payload 36 contains the contents of the packet. The size of the payload may vary. In some examples, the payload may be large. In other examples, the payload may be small. In yet another example, if the content is very small or "compact" it can be carried in the USRD field of header 34.

The type of transaction often indicates whether one or more packets used to represent the transaction have a payload. For example, for either Posted or Non-posted reads, the packet specifies the location address to be accessed, but typically has no payload. However, the associated Completion transaction packet includes a payload containing read content. In both Posted and Non-posted write transactions, the packet includes a payload containing the data to be written to the destination. In non-posted versions of writes, the Completion transaction's packet typically does not define a payload. However, in some situations, the Completion transaction specifies the payload.

The example packet and description above covers many of the basic fields that may be included in a packet. It should be understood that additional fields may be removed or added. For example, private signaling fields may be used so that the source and destination can share private messages.

Arbitration Referring to FIG. 3A, a logic diagram illustrating arbitration logic performed by arbitration element 26 in Peripheral Component Interconnect (PCI) ranking is shown.

In PCI ranking, each port 20 has a separate buffer for each virtual channel and transaction class (P, NP, and C) combination. For example, if there are four virtual channels (VC0, VC01, VC2, and VC3), Port0, Port1, and Port2 each have 12 first-in, first-out buffers. In other words, for each port 20, a buffer is provided for each transaction class (P, NP, and C) and virtual channel (VC0, VC1, VC2, and VC30) combination.

When each IP agent 14 (e.g., IP1, IP2, and IP3) generates a transaction, the resulting packet is sent to the corresponding port (e.g., port 0, port 1, and port 2), respectively. Placed in the appropriate buffer based on transaction type. For example, the Posted (P), Non-posted (NP), and Completion (C) transactions generated by IP1 are Posted, Non-posted, and Completion (C) transactions, respectively, within port 0 for the assigned virtual channel. , are placed in the Completion buffer. Transactions generated by IP2 and IP3 are similarly placed in the Posted, Non-posted, and Completion buffers for the assigned virtual channels within Port 1 and Port 2 in a similar manner.

If a given transaction is represented by multiple packets, all packets for that transaction are inserted into the same buffer. As a result, all packets of a transaction are ultimately transmitted over the same virtual channel. In this policy, the virtual channels remain independent, meaning that different virtual channels are not used for the transmission of multiple packets related to the same transaction.

Within each port 20, packets can be assigned to a given virtual channel in many different ways. For example, the assignment may be random. Alternatively, the allocation may be based on the workload and amount of outstanding traffic for each virtual channel. When one channel is very busy and other channels are not, the port 20 often attempts to balance the load and allocates newly generated transaction traffic to the underutilized virtual channel. As a result, routing efficiency is improved. In yet another alternative, transaction traffic may be assigned to particular virtual channels based on urgency, security, or a combination of both. If a particular virtual channel is given higher priority and/or security than other virtual channels, higher priority and/or secure traffic is assigned to the higher priority virtual channel. In yet another embodiment, port 20 may be hard-coded, meaning that port 20 has only one virtual channel and all traffic generated by port 20 is routed to that one virtual channel. means transmitted over a channel.

In yet another embodiment, virtual channel assignment may be performed by source IP agent 14 alone or in conjunction with its corresponding port 20. For example, source IP agent 14 may generate a control signal to a corresponding port 20 to request that packets of a given transaction be assigned to a particular virtual channel. IP agent 14 can also make allocation decisions that are random, hard-coded, or based on balanced utilization, security, urgency, etc. across all virtual channels, as described above.

In selecting an arbitration winner, arbitration element 26 performs multiple arbitration steps per cycle. These arbitration steps include:
(1) The process of selecting a port,
(2) selecting a virtual channel; and (3) selecting a transaction class.

The above orders (1), (2), and (3) are not fixed. Conversely, the three steps described above may be completed in any order. Regardless of which order is used, a single arbitration winner is selected each cycle. The winning transaction is then transmitted via the corresponding virtual channel associated with interconnect 12.

Multiple arbitration schemes or rulesets may be used for each arbitration (1), (2), and (3) performed by arbitration element 26. Such arbitration schemes may include strict or absolute priority, weighted priority where each of the four virtual channels is assigned a certain proportion of transaction traffic, or a round robin scheme where transactions are assigned to the virtual channels in a predetermined order. It can be included. In further embodiments, other priority schemes may be used. Arbitration element 26 may also dynamically switch from time to time between different arbitration schemes, and/or (1), (2), and (3) the same or different arbitration schemes. It should be understood that different arbitration schemes may be used.

In an optional embodiment, the availability of destination ports 20 defined by outstanding transactions considered during a given arbitration cycle is taken into account. If the buffer at destination port 20 does not have resources available to process a given transaction, the corresponding virtual channel is not available. As a result, the transaction does not compete for arbitration, but rather waits until a subsequent arbitration cycle when the target resource becomes available. On the other hand, if the target resource is available, the corresponding transactions are arbitrated and compete for access to interconnect 12.

The availability of the destination port 20 may be checked at different times with respect to the arbitration steps (1), (2) and (3) described above. For example, the availability check can be performed before the arbitration cycle (ie, before the completion of any of steps (1), (2), and (3)). As a result, only transactions that specify available destination resources are considered during subsequent arbitration. Alternatively, the arbitration check may be performed during any of the three arbitration steps (1), (2), and (3), regardless of the order in which the arbitration steps are performed.

There are advantages and disadvantages to performing destination resource availability checks early or late during the arbitration process. By performing the check early, potentially conflicting portions of transactions can potentially be eliminated from conflict if their destination is not available. However, early knowledge of availability can create a significant amount of overhead to system resources. As a result, depending on the circumstances, it may be more practical to perform availability checks later during a given arbitration cycle.

For the arbitration process, which involves the selection of a transaction class, several rules are defined for arbitrating between the competing portions of N, NP, and C transactions. These rules include the following:
For a Posted (P) transaction,
- A Posted transaction part cannot overtake another Posted transaction part.
- Posted transaction parts must be able to overtake Non-posted transaction parts to avoid deadlocks.
- A Posted transaction part must be able to overtake a Completion if both are in strong order mode. In other words, in strong mode, transactions must be executed strictly according to the rules, and the rules cannot be relaxed.
- A Posted request is allowed, but not required, to overtake a Completion if any transaction part has its Relaxed Order (RO) bit set. Relaxed Order generally follows the rules, but exceptions can be made.
For Non-posted (NP) transactions,
- Non-posted transaction parts must not overtake posted transaction parts.
- A non-posted transaction part must not overtake another non-posted transaction part.
- A Non-posted transaction part must not pass a Completion if both are in strongly ordered mode.
- Non-posted transaction parts are allowed to pass a Completion if any transaction part has its RO bit set, but are not required to.
For a Completion (C) transaction,
- A Completion must not overtake a Posted transaction portion if both are in strongly ordered mode.
- Completion is permitted, but not required, to overtake a Posted transaction part if any transaction part has its RO bit set.
- Completion must not overtake a Non-posted transaction part if both are in strongly ordered mode.
- Completions are permitted, but not required, to overtake Non-posted transaction parts if any transaction part has its RO bit set.
- A Completion is not allowed to overtake another Completion.

Table 4 below provides a summary of the PCI ordering rules. In boxes with no choices in (a) and (b), strict ordering rules need not be followed. In the table boxes with choices (a) and (b), either the strict order (a) rule or the relaxed order (b) rule, depending on whether the RO bit is reset or set, respectively. may be applied. In various alternative embodiments, the RO bit may be set or reset globally or individually at the packet level.

The arbitration element 26 selects the final winning transaction portion by performing arbitration among the competing ports 20, virtual channels, and transaction classes, respectively, in no particular order. The winning portion per cycle has access to the shared interconnect 12 and is transmitted over the corresponding virtual channel.

Referring now to FIG. 3B, a logic diagram is shown illustrating the arbitration logic performed by arbitration element 26 in device ranking. The arbitration process, and possibly consideration of available destination resources, is essentially the same as described above, with two differences.

First, device ordering allows for only two classes of transactions, including (a) non-posted read or write transactions that require a response to every request, and (b) a Completion transaction that specifies the requested response. defined. Since there are only two transaction classes, there are only two buffers per virtual channel at each port 20. For example, if there are four virtual channels (VC0, VC1, VC2, and VC3), each port 20 (eg, Port0, Port1, and Port2) has a total of eight buffers.

Second, the rules for selecting transactions for device ordering are also different from PCI ordering. In device ordering, there are no strict rules that apply to the selection of one class over its overclass. Conversely, any transaction class may be selected arbitrarily. However, the general method typically requires a favorable Completion transaction to release resources that cannot be made available until the Completion transaction is resolved.

Otherwise, the arbitration process for device ordering is essentially the same as described above. In other words, arbitration steps (1), (2), and (3) are performed in any particular order to select an arbitration winner for each arbitration cycle. When transaction class arbitration is performed, device ordering is utilized rather than PCI ordering rules. Additionally, destination resource and/or virtual channel availability may be considered before or during any of arbitration steps (1), (2), and (3).

Operational Flowchart As previously discussed, the arbitration scheme described above may be utilized to share access to any shared resource and is not limited to use with shared interconnects. Such other shared resources may include ARL 28, processing resources, memory resources (such as LUT 30), or nearly any other type of resource shared between multiple parties competing for access.

Referring to FIG. 4, a flowchart 40 illustrating operational steps for arbitrating access to shared resources is shown.

At step 42, various source subsystem agents 14 generate transactions. Transactions can be any of three classes including Posted (P), Non-posted (NP), and Completion (C).

At step 44, each transaction generated by the source subsystem agent 14 is packetized. As mentioned above, packetization of a given transaction may result in one or more packets. Packets may vary in size, with some packets having large payloads and other packets having small payloads or no payloads at all. In situations where a transaction is represented by a single packet with a data payload 36 smaller than the width of the interconnect 12, the transaction may be represented by a single portion. In situations where a transaction is represented by multiple packets or a single packet with a data payload 36 larger than the access width of the shared resource, multiple parts are required to represent the transaction.

At step 46, the portion of the packetized transaction generated by each of the subsystem agents 14 is injected into the local switch 16 via the corresponding port 20. Within port 20, each transaction's packets are assigned to a virtual channel. As previously mentioned, allocation may be random, hard-coded, or based on balanced utilization across all virtual channels, security, urgency, etc.

At step 48, the portions of the packetized transactions generated by each of the subsystem agents 14 are transmitted by both transaction classes and by the virtual channels assigned to them (e.g., VC0, VC1, VC2, and VC3), respectively. , stored in the appropriate first-in, first-out buffer. As mentioned earlier, virtual channels may be assigned by one of many different priority schemes, such as strict or absolute priority, round robin, weighted priority, least recently serviced, etc. . If a given transaction has multiple parts, each part is stored in the same buffer. As a result, multiple parts of a given transaction are transmitted on the same virtual channel associated with interconnect 12. When a transaction portion is submitted, a corresponding counter for tracking the number of content items in each buffer is decremented. When a particular buffer is filled, its counter is decremented to zero, meaning that the buffer can no longer accept further content.

At steps 50, 52, and 54, first, second, and third level arbitration is performed. As previously mentioned, the selection of ports 20, virtual channels, and transaction classes may be performed in any order.

Element 56 may be used to maintain the rules used to perform the first, second, and third levels of arbitration. In each case, element 56 is used as necessary to resolve each of the arbitration levels. For example, element 56 may maintain PCI and/or device ordering rules. Element 56 may include rules for implementing several priority schemes (strict or absolute priority, weighted priority, round robin, etc.) and the logic or intelligence to determine which one to use in a given arbitration cycle.

At step 58, the winner of the arbitration is determined. At step 60, the winning portion is placed into a buffer used to access the shared resource and a counter associated with the buffer is decremented.

At step 62, the buffer associated with the winning portion is incremented since the winning portion is no longer in the buffer.

At step 64, the winning portion accesses the shared resource. Once the access is complete, the buffer for the shared resource is incremented.

Steps 42-64 are each repeated continuously during successive clock cycles. As different winning parts, each gets access to shared resources.

Interleaving - Example 1
Transactions may be transmitted over interconnect 12 in one of several modes.

In one mode, called "header in-line" mode, the header 34 of a packet 32 of a transaction is always transmitted first before the payload 36, each in a separate portion or beat. The header in-line mode may or may not waste available bits on the interconnect 12, depending on the relative size of the header 34 and/or payload 36 to the number of data bits N on the interconnect 12. For example, consider an interconnect 12 that is 512 bits wide (N=512) and a packet with a 128-bit header and a 256-bit payload. In this scenario, the 128-bit header is transmitted in the first portion or beat, leaving the remaining 384 bits of bandwidth of the interconnect 12 unused. In the second portion or beat, the 256-bit payload 36 is transmitted, leaving the remaining 256 bits of bandwidth of the interconnect 12 unused. In this example, a significant percentage of the bandwidth of the interconnect is unused during the two beats. On the other hand, if most of the packets in a transaction are the size of the interconnect or larger, the amount of wasted bandwidth is reduced or eliminated. For example, with headers and/or payloads that are 384 or 512 bits, the amount of wastage is greatly reduced (e.g., 384 bits) or eliminated altogether (e.g., 512 bits).

In another mode, called "header on side-band," the header 34 of the packet is transmitted "on the side" of the data, which means that the payload 36 is transmitted on the interconnect 12 N data bits. This means that the control bit M is used during the process. In header-on-sideband mode, the number of bits or size of the payload 36 of the packet 32 determines the number of beats required to transmit the packet on a given interconnect 12. For example, for a packet 32 with a payload 36 of 64, 128, 256, or 512 bits, and an interconnect 12 with 128 data bits (N=128), the packet would be 1, 1, 2, and 1, respectively. , requires 4 beats. In each transmission of a beat, the header information is transmitted in control bits M along with or "on the side" of the payload data in N data bits of interconnect 12.

In yet another mode, the header 34 of the packet 32 is transmitted in the same manner as the payload, but there is no requirement that the header 34 and payload 36 be transmitted in separate parts or beats. If the packet 32 has a 128 bit header 34 and a 128 bit payload 36, the total size is 256 bits (128+128). If the N data bits of interconnect 12 are 64, 128, 256, and 512 bits wide, then the 256-bit packets are transmitted in 4, 2, 1, and 1 beats, respectively. In another example, packet 32 has a 128-bit header and a 256-bit payload 36, or a total packet size of 384 bits (128+256). On the same interconnect 12 of 64, 128, 256, or 512 wide N data bits, packets are transmitted in 6, 3, 2, or 1 beats, respectively. This mode is always at least as efficient as the header inline mode described above.

Referring to FIG. 5, a first example of interleaving portions of different transactions over multiple virtual channels is illustrated. In this example, only two transactions are shown for simplicity. Two transactions are competing for access to shared interconnect 12, which in this example is 128 data bits wide (N=128). Details of the two transactions include:
(1) Transaction 1 (T1): Generated at time T1 and assigned to virtual channel VC2. The size of T1 is 4 beats, and the beats are designated as T1A, T1B, T1C, and T1D.
(2) Transaction 2 (T2): Generated at time T2 (after time T1) and assigned to virtual channel VC0. The size of T2 is a single portion or beat.

In this example, the VCO is assigned an absolute or strict priority. Over a number of cycles, parts of two transactions T1 and T2 are transmitted on the shared interconnect, as shown in FIG. 5, according to the following.
Cycle 1: Beat T1A of T1 is transmitted on VC2 because it is the only available transaction.
Cycle 2: Beat T1B and a single portion of T2 compete for access to interconnect 12. Since the VCO has strict priority, T2 automatically wins. Therefore, the beat of T2 is transmitted on VC0.
Cycle 3: Beat T1B of T1 is transmitted on VC2 since there are no conflicting transactions.
Cycle 4: Beat T1C of T1 is transmitted on VC2 since there are no conflicting transactions.
Cycle 5: Since there are no conflicting transactions, beat T1D of T1 is transmitted on VC2.

This example shows: (1) In a virtual channel with absolute priority, traffic is immediately granted access to the shared interconnect 12 whenever it becomes available, regardless of whether other traffic is waiting first. , and (2) winning portions or beats of different transactions are interleaved and transmitted on different virtual channels associated with interconnect 12. In this example, the virtual channel VCO is given absolute priority. It should be appreciated that in an absolute or strict priority scheme, any of the virtual channels may be assigned the highest priority.

Interleaving - Example 2
Referring to FIG. 6, a second example of interleaving portions of different transactions over multiple virtual channels is illustrated.

In this example, the priority scheme for access to interconnect 12 is weighted, meaning that VCO is given access with a probability of (40%) and VC1-VC3 are each given access with a probability of (20%). Also, the interconnect is 128 bits wide.

Furthermore, in this example, there are four conflicting transactions T1, T2, T3, and T4.
-T1 is assigned to VC0 and includes four parts or beats T1A, T1B, T1C and T1D.
-T2 is assigned to VC1 and includes two parts or beats T2A and T2B.
-T3 is assigned to VC2 and includes two parts or beats T3A and T3B.
-T4 is assigned to VC3 and includes two parts or beats T4A and T4B.

In this example, the priority scheme is weighted. As a result, each virtual channel wins according to its weight ratio. In other words, during 10 cycles, VC0 wins 4 times and VC1, VC2, and VC3 each win 2 times. For example, as shown in Figure 6,
- The four parts of T1 or beats T1A, T1B, T1C and T1D are transmitted through the VCO in 4 out of 10 cycles (40%) (i.e. cycles 1, 4, 7 and 10) is,
- two parts of T2 or beats T2A and T2B are transmitted over VC1 in 2 out of 10 cycles (20%) (i.e. cycle 2 and cycle 6);
- two parts of T3 or beats T3A and T3B are transmitted over VC2 in 2 out of 10 cycles (20%) (i.e. cycle 5 and cycle 9);
- The two parts of T4 or beats T4A and T4B are transmitted over VC3 in 2 out of 10 cycles (20%) (ie, cycle 3 and cycle 8).

Thus, this example illustrates: (1) a weighted priority scheme in which each virtual channel is given access to interconnect 12 based on a predetermined ratio, as well as (2) another example in which winning portions of different transactions are transmitted interleaved on different virtual channels associated with interconnect 12.

It should be appreciated that in this weighting example, there is enough traffic to allow portions of transactions to be assigned to the various virtual channels according to the weighting ratios. On the other hand, if the amount of traffic is insufficient, the weighting ratios may or may not be strictly enforced. For example, if there is a large amount of traffic on virtual channel VC3 and limited or no traffic on the other virtual channels VC0, VC1, and VC2, then VC3 will carry all or most of the traffic if the weighting ratios are strictly enforced. However, as a result, the interconnect 12 may not be fully utilized since it cannot transmit portions of transactions on every clock cycle or beat. On the other hand, if the weighting ratios are not strictly enforced, it is possible to reallocate transaction traffic (e.g., traffic is transmitted on a greater number of cycles or beats) to increase utilization of the interconnect.

The above two examples are applicable regardless of which of the transmission modes described above is utilized. Once transactions are divided into parts or beats, they may be interleaved and transmitted on the shared interconnect 12 using any of the arbitration schemes defined herein.

The arbitration schemes described above are just a few examples. In other examples, low jitter, weighted, strict, round robin, or nearly any other arbitration scheme may be used. Accordingly, the arbitration schemes listed or described herein are illustrative and should not be considered limiting in any way.

Multiple Simultaneous Arbitrations So far, only a single arbitration has been described for simplicity. However, it should be understood that in practical applications (such as on a SoC), multiple arbitrations may occur simultaneously.

7, there is shown a block diagram of two shared interconnects 12 and 12Z for handling traffic in two directions between the switches 16, 18. As described above, the switch 16 directs transaction traffic from source subfunctions 14 (i.e., IP1, IP2, and IP3) to destination subfunctions 14 (i.e., IP4, IP5, and IP6) via the shared interconnect 12. To handle transaction traffic in the reverse direction, the switch 18 comprises an arbitration element 26Z and, optionally, an ARL 28Z. In operation, the elements 26Z and the ARL 28Z operate in a complementary manner to that described above, which means that transaction traffic generated by source IP agents 14 (i.e., IP4, IP5, and IP6) is arbitrated and sent to destination IP agents (i.e., IP1, IP2, and IP3) via the shared interconnect 12Z. Alternatively, arbitration may be performed without ARL 28Z, meaning that arbitration simply makes a decision between competing ports 20 (e.g., Port 3, Port 4, or Port 5) and the portion of the transaction associated with the winning port is transmitted on interconnect 12, regardless of the portion's ultimate destination. Elements 12Z, 26Z, and 28Z have already been described, and therefore, for the sake of brevity, a detailed description is not provided here.

There may be multiple levels of subfunctions 14 and multiple shared interconnects 12 in the SoC. In each case, the arbitration scheme described above may be used to simultaneously arbitrate between transactions sent across interconnect 12 between various subfunctions.

Interconnect Fabric Referring to FIG. 8, an example SoC 100 is shown. The SoC 100 includes a plurality of IP agents 14 (IP1, IP2, IP3, . . . IPN). Each IP agent 14 is connected to one of several nodes 102. Shared interconnects 12, 12Z are in opposite directions and are provided between the various nodes 102. In this configuration, transactions may flow in both directions between each pair of nodes 102, eg, as described above with respect to FIG.

In a non-exclusive embodiment, each node 102 includes various switches 16, 18, an access port 20 for connecting to the local IP agent 14, and an access port 22 for connecting to the shared interconnect 12, 12Z. , an arbitration element 26, an optional ARL 28, and an optional LUT 30. In alternative embodiments, a node may not include arbitration element 26 and/or ARL 28. For nodes 102 that do not have these elements, transactions without the necessary routing information may be forwarded to the default node as described above. Each of these elements has been described above with respect to FIG. 1, so a detailed description will not be provided here for the sake of brevity.

Collectively, the various nodes 102 and bidirectional interconnects 12, 12Z define an interconnect fabric 106 for the SoC 100. The illustrated interconnect fabric 106 is relatively simple for the sake of brevity. In a practical embodiment, the interconnection fabric on the SoC 100 comprises hundreds or thousands of IP agents 14, multiple levels of nodes 102, all interconnected by a large number of interconnects 12, 12Z, and a highly Please understand that it can be complicated.

In some applications, such as broadcast, multicast, and anycast machine learning or artificial intelligence, transactions generated by one IP agent 14 are typically broadcast widely to multiple IP agents 14 on the SoC 100. It is. Transactions broadcast to multiple IP agents 14 may be performed by broadcast, multicast, or anycast. Broadcast, multicast, and/or anycast may each be implemented independently or together on a given SoC 100. A brief definition of each of these types of transactions is provided below.
- A broadcast is a transaction sent to all IP agents on the SoC 100. For example, in the SoC 100 shown in FIG. 8, IP2 to IPN each receive a transaction as a result of a broadcast being sent by IP1.
- Multicast is a transaction sent to two or more (potentially all) of the IP agents on the SoC. For example, if IP1 generates a multicast transaction specifying IP5, IP7, and IP9, these agents 14 will receive the transaction, but the remaining IP agents 14 on SoC 100 will not. When a multicast is sent to all IP agents 14, it is basically the same as a broadcast.
- Read response multicast is a modification of the multicast transaction described above. With read response multicast, a single IP agent 14 may read the contents of a memory location. Rather than only the initiating IP agent 14 receiving the content, multiple destination IP agents 14 receive the content. The IP agents 14 that receive the read results may range from two or more IP agents 14 to all IP agents 14 on the SoC 100.
- Anycast is a transaction generated by IP agent 14. However, the sending IP agent 14 does not specify a target IP agent 14 at all. Instead, interconnect fabric 106 (ie, one or more of nodes 102) determines the receiving IP agent 14. For example, if IP1 generates an anycast transaction, one or more of the nodes 102 determine which of the other agents IP2-IPN will receive the transaction. In various embodiments of anycast transactions, one, more, or all of the IP agents 14 on the SoC may receive the anycast transaction.

A given transaction may be initiated in several ways: as a broadcast, a multicast (including a read response multicast), or an anycast. For simplicity, hereafter, these transactions are collectively referred to as "BMA" transactions, which means broadcast, multicast (including a read response multicast), or anycast transactions.

In one embodiment, an IP agent 14 may initiate a BMA transaction with a coded command inserted in a command field CMD of a header 34 of a packet 32 representing the transaction. The coded command causes the interconnect fabric 106 of the SoC 100 to recognize or understand that the transaction is a BMA transaction, rather than a normal transaction that specifies one source and one destination IP agent 14. For example, a unique combination of bits may define a given transaction as either a broadcast, multicast, read response multicast, or anycast, respectively.

In another embodiment, a BMA transaction may be implemented by issuing a read or write transaction with the BMA address specified in the ADDR field of the header 34 of the packet 32 representing the transaction. A BMA address is designated within the SoC 100 system as indicating one of a broadcast, multicast, or anycast transaction. As a result, the BMA address is recognized by the interconnect fabric 106 and the transaction is treated as a broadcast, multicast, or anycast.

In yet another embodiment, both the command and the BMA address can be used to specify a broadcast, multicast, or anycast transaction.

Anycast is typically used in situations where a source IP agent 14 wants to send a transaction to multiple destinations, but is unaware of the factors that help select one or more preferred or ideal destination IP agents 14. It will be done. For example, source IP agent 14 may attempt to send a transaction to multiple IP agents, each implementing accelerator functionality. By designating the transaction as anycast, one or more of the nodes 102 participate in the selection of the destination IP agent 14. In various embodiments, the selection criteria may vary widely and include congestion conditions (busy IP agents vs. idle or not busy IP agents), random selection functions, hard-wired logic functions, hash functions, longest time limit, etc. It may be based on a function of usage, power consumption considerations, or any other decision function or criterion. Accordingly, the responsibility for selecting the destination IP agent 14 is shifted to the node 102, which may have more information to make better routing decisions than the source agent 14.

Referring to FIG. 9A, a diagram 90 is shown illustrating logic of node 102 to support BMA addressing. Logic 90 includes LUT 30, an interconnect fabric ID (IFID) table 124, and an optional physical link selector 126. The optional physical link selector 126 is used when there are two (or more) overlapping physical resources that share a single logical identifier (such as in a trunking situation), which will be described in more detail below.

The IFID table includes, for each IP agent 14, (a) a corresponding logical IP ID for logically identifying each IP agent 14 within the SoC 100; and (b) the corresponding IP ID that is local to the node 102. (c) access port 22 to the appropriate interconnect 12 or 12Z leading to the next node 102 along the delivery path to the corresponding IP agent 14; In this configuration, each node has access to the identity of the physical ports 20 and/or 22 necessary to deliver transactions to each IP agent 14 within the SoC 100.

IFID table 124 for each node 102 within fabric 106 is relative (ie, unique). In other words, each IFID table 124 can be sent to other nodes 102 along the distribution path to (1) its local IP agent 14 or (2) other IP agents 14 in the SoC that are not locally connected to node 120. contains only the list of ports 20 and/or 22 needed to deliver transactions to any of the shared interconnects 12, 12Z, of the . In this configuration, each node 102 either (1) delivers the transaction to its local IP agent 14 designated as the destination, or (2) forwards the transaction to another node 102 via the interconnect 12, 12Z. Either you do it, or you do it. The above process is repeated at the next node. By distributing or forwarding transactions locally at each node 102, a given transaction is ultimately distributed to all designated destination IP agents 14 in interconnect fabric 106 for SoC 100.

LUT 30 is the first portion 120 used for conventional transaction routing (ie, transactions sent to a single destination IP agent 14). When a conventional transaction is generated, source IP agent 14 defines the destination address in system memory 24 in the ADDR field of the packet header representing the transaction. The transaction is then provided to local node 102 for routing. In response, ARL 28 accesses first portion 120 of LUT 30 to find the logical IP ID corresponding to the destination address. IFID table 124 then identifies (a) port 20 if destination IP agent 14 is local to node 102 or (b) the appropriate interconnect leading to the next node 102 along the delivery path to destination IP agent 14. 12 or access port 22 to 12Z. The IP ID is placed in the DST field of the header 34 of the packet 32 before being transmitted along the appropriate port 20 or 22.

For broadcast, multicast, or anycast transactions, the second portion 122 of LUT 30 includes a plurality of BMA addresses (e.g., BMA 1 through BMA N, where N is any arbitrary number that may be selected as needed or appropriate). number) and information corresponding to each BMA address. In various embodiments, the corresponding information may be:
(1) One or more unique IP IDs (eg, IP4 and IP7 for BMA address 1, IP5, IP12, and IP24 for BMA address 2).
(2) Unique codes (eg, code 1 and code 2 for BMA addresses 10 and 11).
(3) Bit vector (eg, bit vector for BMA addresses 20 and 21).

Each code uniquely identifies a different set of destination IP agents. For example, a first code can be utilized to specify a first set of destination IP agents (e.g., IP1, IP13, and IP21), and a second code can be used to specify another set of destination IP agents (e.g., IP4, IP9 , and IP17).

In the bit vector, each bit position corresponds to an IP agent 14 on SoC 100. Depending on whether a given bit position is set or re-set, the corresponding IP agent 14 is designated as being a destination or not being a destination, respectively. As an example, a bit vector of (101011...1) indicates that the corresponding IP agents 14 (IP1, IP3, IP5, IP6, and IPN) are configured and the rest are reconfigured.

In each of the above embodiments, one or more logical IP IDs are identified as the destination IP agents for a given transaction. The IFID table 124 is used to translate the logical identifier IP ID values to the physical access ports 20 and/or 22 required to route the transactions to their destination. In the case of BMA addresses, a unique code or bit vector may be used in place of the IP ID value to determine that the correct physical access ports 20 and/or 22 are required.

Both codes and bit vectors can be used to specify multiple destination IP agents 14. The bit vector may potentially be limited by the width of the destination field DST of the header 34 of the packet 32 representing the transaction. For example, if the destination field DST is 32, 64, 128, or 258 bits wide, the maximum number of IP agents 14 is limited to 32, 64, 128, and 256, respectively. If the number of IP agents 14 on a given SoC happens to exceed the number of possible IP agents that can be specified by the width of the destination field DST, other fields in the header 34 may optionally be used; Alternatively, the DST field may be expanded. However, in highly complex SoCs 100, the number of IP agents 14 may exceed the number of available bits that can be practically utilized within a bit vector. This problem is avoided because the code may specify any number of destination IP agents.

It is to be understood that the example provided with respect to FIG. 9A is illustrative in nature and is not intended to be limiting in any way. In actual embodiments, the number of BMA addresses available on SoC 100 may vary widely from one to many.

Source-Based Routing (SBR)
Source-based routing (SBR) differs from conventional routing in the following ways:
(1) The source IP agent 14 has some knowledge or instructions that it provides to the interconnection fabric 106 when issuing a transaction. For example, the source IP agent 14 knows the IP ID of the destination IP agent 14 to which it wants to send the transaction.
(2) source IP agent 14 is not interested in and/or does not know about the addresses in system memory 24 that are normally provided in the ADDR fields of packet headers 34 of packets 32 of the transaction;
(3) nodes 102 in interconnect fabric 106 know to do something other than simply translate the address in the ADDR field of a packet's header 34 into a single IP ID for a single destination IP agent.

Broadcasts and multicasts are both examples of transactions that could possibly, but are not necessarily, SBR transactions. If a source issues a broadcast or multicast that specifies either (a) a broadcast and/or multicast code and (b) a destination IP agent 14 in the header 34 of the packet 32 of the transaction, the transaction Since the agent specifies the destination IP agent, it is considered source-based. On the other hand, if a source initiates a broadcast or multicast transaction using a BMA address without any specific knowledge of the destination, the transaction is considered non-source-based. Anycast transactions are not considered source-based because they do not specify a destination IP agent 14.

Hashing In hashing, a hash function is used to define a destination or a route to a destination. In some embodiments, the hashing function may carefully define multiple destinations and/or multiple routes to multiple destinations.

Referring to FIG. 9B, a diagram 140 is shown illustrating the use of hash functions to make routing decisions. In this embodiment, a hash value 142 is provided in a number of fields of the header 34 of the packet 32 representing the transaction. For example, a subset of address bits, commands, source agent IP, or any possible combination of information or data contained in header 34 may be used to define the hash value. A hash function 144 is applied to the hash value 142 within the corresponding local node 102 or elsewhere on the SoC 100. Routing decisions may be made in response to hash function 144. For example, one or more IP IDs of destination agent 14 may be defined. By providing different hash values, different routing decisions may be defined. It should be appreciated that hashing may be used for many other applications within the SoC. One such application is the use of hash functions for trunking. With trunking, there are two (or more) overlapping physical resources that share a single logical identifier. As discussed in more detail below, hash functions can be used to select among duplicate physical resources.

Optimizing Transaction Traffic Some applications of SoCs can be transaction intensive, such as machine learning, artificial intelligence, and data centers. These types of applications tend to rely on broadcast, multicast, and anycast, which can further increase transaction traffic.

Broadcast transactions can significantly increase the amount of traffic sent over interconnection fabric 106.

Many procedures have been proposed to reduce transaction traffic in order to reduce the occurrence of bottlenecks. Such steps include (1) expanding transactions and consolidating responses at nodes 102 of interconnection fabric 106 of SoC 100; (3) interleaving the above transactions in a stream; and two or more physical links between IP agents sharing a common logical link or two or more identical IP agents sharing a common logical address. Including "trunking".

Transaction amplification and response integration Broadcasting, multicasting, read response multicasting, and anycasting can each significantly increase the amount of transaction traffic between IP agents 14 on SoC 100.

If the SoC 100 has 25 IP agents and one of the IP agents generates a broadcast transaction, up to 24 individual transactions are typically sent across the interconnection fabric to the other IP agents 14. Ru. Non-posted (NP) transactions require a response in the form of a Completion (C) transaction. If the transaction broadcast to 24 IP agents is Non-posted, another 24 Completion (C) transactions are generated as well. As shown in this simple example, broadcasting can rapidly increase the amount of traffic carried on interconnection fabric 106.

Multicast and anycast transactions can also rapidly scale up the amount of traffic. For each of these transaction types, multiple receivers may be specified, meaning that multiple transactions are sent and possibly multiple completed response transactions are received via interconnection fabric 106. In a read response multicast transaction, the read content may also be sent to multiple destination IP agents 14. As a result, transaction volume can increase significantly for these types of transactions as well.

To make interconnection fabric 106 operate more efficiently, techniques are used to scale and consolidate transactions at nodes 102 to reduce the amount of traffic.

Referring to FIGS. 10A and 10B, diagrams illustrating an example of a SoC are shown. In this example, the SoC comprises an interconnect fabric 106 with five interconnected nodes 102A-102E and ten IP agents 14 (IP1-IP10).

Referring to FIG. 10A, IP1 broadcasts non-posted write transactions to other IP agents IP2-IP10. By using extensions, only a single transaction is sent on each shared interconnect 12. At each downstream node 102B-102E, the node (1) provides the transaction to any local IP agent 14 and (2) forwards the transaction to any upstream node 102. So in this example,
- Node 102B provides the transaction to IP2 and forwards a single instantiation of the transaction to nodes 102C and 102D, respectively.
- At node 102C, transactions are provided to local agents IP3, IP4, and IP5.
- Node 102D provides the transaction to IP7. Further, node 102D also forwards a single instantiation of the transaction to node 102E.
- At node 102E, transactions are provided to IP8, IP9, and IP10.

In the above example, only a single transaction is sent on each shared interconnect 12, regardless of the number of IP agents 1 downstream of the sending IP agent 14.

Integration of response transactions will be described with reference to FIG. 10B. Since the broadcast transaction was a non-posted write, each destination agent IP2-IP10 needs to return a completed transaction. In consolidation, each node 102B-102E consolidates completed transactions received from its local IP agent 14 and then sends only a single completed transaction upstream toward node 102A. In other words,
- Node 102E consolidates completed transactions received from IP8-IP10 and returns a single completed transaction to node 102D.
- At node 102D, completed transactions received from IP7 and node 102E are consolidated and one completed transaction is returned to node 102B.
Similarly, node 102C returns a single consolidated transaction for IP3, IP4, and IP5.
- Finally, node 102B consolidates the completed transactions received from nodes 102C, 102D, and IP2 and returns a single completed transaction to node 102A and IP1.

The above example illustrates the efficiency of expansion and consolidation. Without expansion, nine separate transactions (one for each of agents IP2-IP10) would need to be transmitted across interconnection fabric 106. However, by using dilation, the number of transactions transmitted over the various shared interconnects 12 is reduced to four. A total of nine completed transactions are also consolidated into four.

Sometimes an error may occur and a completed transaction is not generated by one or more of the receiving IP agents IP2-IP10. Errors can be handled in many different ways. For example, only successful completions can be integrated, while error responses can be combined and/or sent separately. In yet another alternative, both successful and error completions may be combined, but each is flagged to indicate either a successful response or a failed response.

Although the above description is provided in the context of broadcasting, it is to be understood that transaction expansion and consolidation may be implemented with multicasting, read response multicasting, and/or anycasting.

The amount of transaction traffic on interconnect fabric 106 that can be scaled and consolidated in transaction-intensive applications such as machine learning, artificial intelligence, and data centers where broadcast, multicast, and anycast transactions are common. can be significantly reduced, eliminating or reducing bottlenecks and improving system efficiency and performance.

The interconnection fabric 106 of the trunking SoC 100 typically has a physical links. If there is only a single link, there is a one-to-one correspondence between a physical link and an access port 20 or 22 for that physical link. Similarly, in most interconnection fabrics 106 there is also a one-to-one correspondence between a physical IP agent 14 and the logical IP ID used to access that IP agent 14.

In high performance applications, it may be advantageous to use a technique called trunking. In trunking, there are two (or more) duplicated physical resources that share a single logical identifier. By duplicating physical resources, bottlenecks can be avoided and system efficiency and performance can be improved. For example, if one physical resource is busy, powered off, or unavailable, one of the duplicated resources can be utilized. Trunking can also improve reliability. If one physical resource (e.g., an interconnect or IP agent) goes down, becomes unavailable, or is unavailable for any reason, the other physical resource can be utilized. By addressing the duplicated resources with the same logical identifier, the benefits of duplicated physical resources can be realized without having to change the logical addressing system utilized on the SoC 100. However, the challenge is to select and keep track of which of the duplicated physical resources to utilize.

11A, an interconnect fabric 106 of SoC 100 is shown that includes several trunking examples. In this example, interconnect fabric 106 includes three nodes 102A, 102B, and 102C. Node 102A includes two IP agents _14i and _142. Node 102B includes two IP agents ₁₄₃ and _144. Node 102C includes one IP agent 14s. Interconnect fabric 106 includes the following trunking examples:
A pair of physical "trunk" lines between node 102A and IP agent ₁₄₂ .
A pair of unidirectional physical "trunk" interconnections 12 ₍₁₎ and 12 ₍₂₎ from nodes 102A to 102C.
A pair of identical IP agents 14s.

In each of these examples, there is no one-to-one correspondence between logical identifiers and physical resources. Conversely, since there are two available physical resources, it is necessary to select which physical resource to use.

11B, a diagram illustrating the optional physical link selector 126 (of FIG. 9A) is shown. As mentioned above, in trunking, there are two (or more) overlapping physical resources that share a single logical identifier. Whenever the IFID table 124 identifies a logical IP ID with overlapping physical resources, such as in a trunking situation, the optional physical link selector 126 is used to make a selection. The physical link selector 126 may make its selection using one or more determinants, such as physical resource availability (or lack thereof), congestion, load balancing, hash functions, random selection, least recently used selection, power conditions, etc. For example, if a physical resource is busy, congested, and/or unavailable, the other physical resource is selected. Alternatively, if a resource is powered off to reduce power consumption, the other resource may be selected. Regardless of how the selection is made, it results in the identification of the physical port 20 or 22 that is used to access the selected physical resource.

In non-exclusive embodiments, the selection of physical resources is preferably utilized until the operation is complete. If a series of related transactions are sent between a source IP agent 14 and an overlapping pair of destination IP agents (e.g., the two IP agents IP5 in FIG. Sent to destination IP agent. Otherwise, data corruption or other problems may occur. A similar approach is typically preferred if the overlapping physical resources are interconnects. For transactions that require a response (such as a read), both the read request transaction and the result response are preferably sent over the same interconnect. Furthermore, to avoid corruption of transactional packets, it is preferable that the entire transaction and the transactional packets be routed on the same path to the same destination. It is important not to change ports or links until the end of the packet, as the packet requires several beats to traverse the link and may possibly be interleaved with other virtual channels. Otherwise, the multiple beats of the packet may be out of order as portions of the packet travel through the system, thereby corrupting the information. Although it is usually desirable to route responses through the same path as requests, it is not required.

In some non-exclusive embodiments, it is advantageous to provide a destination IP agent with the ability to reorder transactional beats received out of order or from different resources using ordering information sent with each beat. It can be. For example, control bit M may be used to specify a unique "beat count" for each beat of a packet. The beats of packets can then be assembled by the destination IP agent in precise numerical order, with a unique beat count number sent with each beat. By providing a beat count number that is sent with each beat, many of the above-mentioned problems with corruption may be resolved.

Intra-Stream Interleaving As mentioned above, a stream is defined as a pairing of a virtual channel and a transaction class. If there were four virtual channels (eg, VC0, VC1, VC2, and VC3) and three transaction classes (P, NP, C), there are at most 12 different possible streams. The 12 streams are completely independent. Since the streams are independent, they can be interleaved on shared resources, such as interconnect wires 12 and 12Z, for example. At each arbitration step, a stream of virtual channels is selected and the corresponding port 22 is locked to the transaction for the remainder of the transaction. Another virtual channel may be selected to interleave on the same port before the transaction's transmission is complete, but another stream on the same virtual channel cannot be selected until the transaction is complete.

Intra-stream interleaving is the interleaving of two or more transactions that share the same stream, provided that the two transactions are independent of each other. Examples of independent transactions are (1) two different IP agents 14 generating transactions that share the same stream, and (2) the same IP agent 14 generating two transactions that share the same stream. but includes the generating IP agent 14 marking the two transactions as independent. Marking transactions as independent means that they can be reordered and distributed using interleaving. Intra-stream interleaving can relax or eliminate the above-mentioned constraint of locking a virtual channel's stream to a port until the transaction is complete. With intra-stream interleaving, (1) two or more independent transactions can be interleaved on a stream, and (2) different streams associated with the same virtual channel can also be interleaved.

Intra-stream interleaving requires additional information to indicate two (or more) independent transactions that can be interleaved on the same stream. In various embodiments, this may be accomplished in many different ways. In one embodiment, the packet header 34 of an independent transaction is assigned a unique transaction identifier or ID. By using a unique transaction identifier, each beat of each transaction is flagged as independent. By using a unique transaction ID for each transaction, various nodes 102 track the beat of multiple independent transactions that are interleaved on the same stream.

For a given pair of interleaved transactions, the bits specifying the virtual channel and transaction class are the same, but the bits representing the transaction ID for each are different.

Therefore, the additional transaction ID information contained in control bit M allows both source and destination IP agents 14 and interconnection fabric 106 to recognize one transaction relative to another when interleaved on the same stream. or make it possible to distinguish.

In synchronous vs. asynchronous delivery broadcasting, multicasting, read response multicasting, and anycasting, multiple instantiations of the same transaction may be transmitted on interconnection fabric 106. If each of the target destinations and paths to those destinations are available, each destination IP agent 14 will receive the transaction in due course, with a normal latency delay on the network. On the other hand, if either a path or a destination is unavailable (eg, a resource buffer is full), one or more available destinations may receive the transaction before the unavailable destination. Different arrival times under such circumstances raise the possibility of two different implementations.

In a first synchronization or "blocking" embodiment, an effort is made to ensure that each destination receives transactions at approximately the same time. In other words, delivery of transactions to available resources may be delayed or "blocked" until the unavailable resources become available. As a result, reception of transactions by each of the designated receivers is synchronized. This embodiment may be used in applications where it is important to the receiver to receive transactions at approximately the same time.

In a second asynchronous or non-blocking embodiment, no blocking efforts are made to delay delivery of the transaction to available destinations. Instead, each instantiation of the transaction is delivered based on availability, meaning that available resources receive the transaction immediately, while unavailable resources receive the transaction when it becomes available. As a result, delivery can occur asynchronously, i.e. at different times. The advantage of this approach is that available destination IP agents 14 can process the transaction immediately and are not blocked waiting to synchronize with other IP agents. As a result, delays are avoided.

Although only certain embodiments have been described in detail, it will be appreciated that the present application may be practiced in many other forms without departing from the spirit or scope of the disclosure provided herein. Accordingly, these embodiments are to be considered illustrative and not restrictive, and are not limited to the details set forth herein, but within the scope of the appended claims and equivalents. It may be transformed by

Claims (13)

1. A system on chip (SoC), comprising:
an interconnection fabric;
a plurality of IP agents interconnected by the interconnection fabric, the plurality of IP agents being configured to be sources and destinations of transaction traffic transmitted between the IP agents over the interconnection fabric;
Equipped with
a first IP agent configured to generate and transmit a source-based routing (SBR) transaction that identifies one or more destination IP agents among the plurality of IP agents on the SoC;
the interconnect fabric is configured to make routing decisions regarding how to route and deliver the SBR transaction over the interconnect fabric to the one or more destination IP agents among the plurality of IP agents on the SoC ;
The SBR transaction identifies the one or more destination IP agents by providing an address in a header of the transaction, the address being resolved by the interconnect fabric to identify two or more destination IP agents on the SoC. A system-on-chip (SoC),
an interconnect fabric;
a plurality of IP agents interconnected by the interconnection fabric and configured to be a source and destination of transaction traffic transmitted between the IP agents through the interconnection fabric; an IP agent,
Equipped with
a first IP agent configured to generate and send a source-based routing (SBR) transaction identifying one or more destination IP agents among the plurality of IP agents on the SoC;
The interconnection fabric makes routing decisions regarding how to route and deliver the SBR transaction via the interconnection fabric to the one or more destination IP agents among the plurality of IP agents on the SoC. configured to do
The interconnection fabric is transmitted through the interconnection fabric by consolidating and sending one instantiation of the SBR transaction over a shared interconnect between two nodes of the interconnection fabric. The SoC is configured to make the routing decisions to reduce transaction traffic, wherein the shared interconnect leads to two or more destination IP agents along a delivery path . A system-on-chip (SoC),
an interconnect fabric;
a plurality of IP agents interconnected by the interconnection fabric and configured to be a source and destination of transaction traffic transmitted between the IP agents through the interconnection fabric; an IP agent,
Equipped with
a first IP agent configured to generate and send a source-based routing (SBR) transaction that identifies one or more destination IP agents among the plurality of IP agents on the SoC;
The interconnection fabric makes routing decisions about how to route and deliver the SBR transaction via the interconnection fabric to the one or more destination IP agents among the plurality of IP agents on the SoC. configured to do
The interconnection fabric aggregates multiple received response transactions generated in response to the SBR transaction into one instance of the response transaction via a shared interconnect between nodes of the interconnection fabric. the shared interconnect is configured to make the routing decision to reduce transaction traffic sent through the interconnect fabric by forwarding the responses along a response delivery path; SoC to reach transaction goals . A system-on-chip (SoC),
an interconnect fabric;
a plurality of IP agents interconnected by the interconnection fabric and configured to be a source and destination of transaction traffic transmitted between the IP agents through the interconnection fabric; an IP agent of
Equipped with
a first IP agent configured to generate and send a source-based routing (SBR) transaction that identifies one or more destination IP agents among the plurality of IP agents on the SoC;
The interconnection fabric makes routing decisions regarding how to route and deliver the SBR transaction via the interconnection fabric to the one or more destination IP agents among the plurality of IP agents on the SoC. configured to do
The interconnection fabric is further configured to make the routing decision to interleave transmission of multiple transactions on multiple streams associated with a shared interconnection, the interconnection fabric being further configured to: (a) (b) each of the SoCs is defined by a unique combination of virtual channels and transaction types, and (b) one or more parts of the same transaction are transmitted over the same stream . 1. A system on chip (SoC), comprising:
an interconnection fabric;
a plurality of IP agents interconnected by the interconnection fabric, the plurality of IP agents being configured to be sources and destinations of transaction traffic transmitted between the IP agents over the interconnection fabric;
Equipped with
a first IP agent configured to generate and transmit a source-based routing (SBR) transaction that identifies one or more destination IP agents among the plurality of IP agents on the SoC;
the interconnect fabric is configured to make routing decisions regarding how to route and deliver the SBR transaction over the interconnect fabric to the one or more destination IP agents among the plurality of IP agents on the SoC ;
The SoC, wherein the interconnect fabric is further configured to make the routing decision to route two or more independent transactions through a same stream among a plurality of streams associated with a shared interconnect, each of the plurality of streams defined by a unique combination of a virtual channel and a transaction type. A system-on-chip (SoC),
an interconnect fabric;
a plurality of IP agents interconnected by the interconnection fabric and configured to be a source and destination of transactional traffic transmitted between the IP agents through the interconnection fabric; an IP agent of
Equipped with
a first IP agent configured to generate and send a source-based routing (SBR) transaction that identifies one or more destination IP agents among the plurality of IP agents on the SoC;
The interconnection fabric makes routing decisions about how to route and deliver the SBR transaction via the interconnection fabric to the one or more destination IP agents among the plurality of IP agents on the SoC. configured to do
The interconnection fabric comprises redundant physical resources sharing a common logical identifier, and the routing decision includes (a) selecting one of the redundant physical resources; (b) selecting one of the redundant physical resources; and routing the transaction using one of the SoCs. 7. The SoC of claim 6 , wherein the routing decision comprises:
(a) availability of said redundant physical resources;
(b) a relative mixed state between the overlapping physical resources;
(c) load balancing between the overlapping physical resources;
(d) random selection between said overlapping physical resources;
(e) longest time unused selection between said overlapping physical resources;
(f) relative power consumption between the overlapping physical resources;
(g) utilizing a hash function to select between said overlapping physical resources; or
(h) an SoC based on any combination of (a) to (g); 1. A system on chip (SoC), comprising:
an interconnection fabric;
a plurality of IP agents interconnected by the interconnection fabric, the plurality of IP agents being configured to be sources and destinations of transaction traffic transmitted between the IP agents over the interconnection fabric;
Equipped with
a first IP agent configured to generate and transmit a source-based routing (SBR) transaction that identifies one or more destination IP agents among the plurality of IP agents on the SoC;
the interconnect fabric is configured to make routing decisions regarding how to route and deliver the SBR transaction over the interconnect fabric to the one or more destination IP agents among the plurality of IP agents on the SoC ;
The interconnect fabric is further configured to make the routing decision to route two or more independent transactions over a same stream, wherein the two or more independent transactions are each assigned a unique transaction identifier that enables the interconnect fabric to track each beat of the two or more independent transactions so that the two or more independent transactions may be routed over the same stream. 9. The SoC of claim 8 , wherein the two or more independent transactions routed via the same stream share common control information specifying the same stream, but the two or more independent transactions The transaction identifier of each transaction is unique. 10. The SoC of any one of claims 1 to 9 , wherein the SBR transaction provides an identifier in a header of the transaction that logically identifies the one or more destination IP agents on the SoC. the SoC, thereby identifying the one or more destination IP agents; 11. The SoC according to any one of claims 1 to 10 , wherein the SBR transaction identifies the one or more destination IP agents by providing a unique code in a header of the transaction; The unique code is resolved within the interconnection fabric to identify the one or more destination IP agents on the SoC. 12. The SoC of any one of claims 1 to 11 , wherein the interconnection fabric comprises a plurality of nodes, each of the plurality of nodes having access to one or more addresses specified in the SBR transaction. a look-up table for resolving one or more logical identifiers of the one or more destination IP agents. 13. The SoC of claim 1, wherein the interconnect fabric comprises a plurality of nodes, each of the plurality of nodes comprising a table for translating logical identifiers of the one or more destination IP agents into one or more port identifiers used to route the transaction.

Images