Patent Description:
A System on a Chip ("SoC") is an integrated circuit that includes multiple sub-systems, often referred to as Intellectual Property ("IP") agents. IP agents are typically "reusable" blocks of circuitry designed to implement or perform a specific function. By using IP agents, the time and cost of developing complex SoCs can be significantly reduced.

SoCs typically include a system controller and an interconnect, such as a bus or Network on a Chip (NoC). The system controller runs system software and is provided to manage the overall operation of the SoC. The various IP agents are connected to the interconnect via one or more links and communicate with one another via the interconnect.

SoC developers commonly use disparate IP agents, often from multiple vendors. Each IP agent will ordinarily implement its own unique procedures for reset. From the perspective of the system controller and the interconnect on the SoC, this is problematic for several reasons.

A typical SoC will normally have multiple IP agents connected to the interconnect. Upon reset, each of the IP agents will likely emerge from the reset state at different times due to the unique reset procedures each uses. The different times each IP agent emerges from reset can cause significant problems. If a source IP agent generates a transaction for a destination IP agent that is still in reset, then the (<NUM>) destination IP agent is unable to process the request and (<NUM>) source IP agent never receives a reply. As a result, the entire system may get hung up, possibly requiring a system-wide reset.

One known approach to prevent hang-ups is to design and place circuitry intermediate each link, between the interconnect and each IP agent. The purpose of this circuitry is to make sure that all the IP agents connected to the interconnect emerge from reset during the same clock cycle. This approach, however, has drawbacks for several reasons:.

On occasion, IP agents malfunction. For example, IP agents may inject spurious transactions onto the interconnect, may fail to respond to a received transaction, generate an exception message, etc. In certain situations, the malfunctioning IP agent may need to be reset. With current SoC interconnect standards, there is no standardized IP agent reset mechanism. Either the entire SoC has to be reset, or intermediary circuitry needs to be designed to perform the necessary isolation, reset, and re-introduction of the IP to the system, etc..

Power management is also not addressed with certain current SoC interconnect standards. The Advanced Microcontroller Bus Architecture (AMBA) protocol, for instance, does not address power management, and provides no method for intentionally powering down or turning off IP agents. To provide this capability, power management functionality typically needs to be custom designed into the SoC on a chip-by-chip basis, by developing for instance, additional intermediate circuitry on the links for handing power management.

Many companies offering multiple SoCs will share certain amounts of the system software among similar devices to reduce the time to market. However, even with SoCs that are similar, the software typically cannot simply be ported from one device to another, even in situations where the IP agents may be the same. If there are minor differences in any intermediate circuitry used for reset and/or power management, the system software may need to be modified and debugged for each device.

Companies that develop a large number of SoCs are thus challenged with (<NUM>) developing customized circuitry for implementing reset and possibly power management for each device and (<NUM>) modifying and debugging the system software for each device. This effort, across multiple devices is expensive, complex and time consuming, reducing the ability to quickly bring products to market.

A system for consistently implementing reset and power management of IP agents on SoCs, removing the need for customization, and which leads to a consistent system software view among multiple SoCs, is therefore needed. <CIT> Al describes an interconnect-power-manager (IPM) that cooperates and communicates signals with an integrated-circuit-system-power-manager (SPM) in an integrated-circuit. <CIT> Al describes methods and apparatus for managing sideband segments in an On-Die System Fabric (OSF). <CIT> describes an apparatus including: a fabric of a first communication protocol to communicate with an upstream agent in an upstream direction and to communicate with a plurality of downstream agents in a downstream direction; a switch coupled between the fabric and at least some of the plurality of downstream agents, the switch to couple to a primary interface of the fabric via a primary interface of the switch and to communicate with the fabric via the first communication protocol, the switch further including a sideband interface to interface with a sideband fabric of the first communication protocol; and the at least some downstream agents coupled to the switch via the sideband fabric, wherein the at least some downstream agents are to be enumerated with a secondary bus of a second communication protocol, and the switch device is to provide a transaction received from the upstream agent to a first downstream agent based on a bus identifier of the secondary bus with which the first downstream agent is enumerated.

A system for consistently implementing reset and power management of IP agents on SoCs, removing the need for customization, and which leads to a consistent system software view among multiple SoCs, is disclosed.

The present application and the advantages thereof, may best be understood by reference to the following description taken in conjunction with the accompanying drawings in which:.

In the drawings, like reference numerals are sometimes used to designate like structural elements.

The present application will now be described in detail with reference to a few non-exclusive embodiments thereof as illustrated in the accompanying drawings. It will be apparent, however, to one skilled in the art, that the present discloser may be practiced without some or all of these specific details. In other instances, well known process steps and/or structures have not been described in detail in order to not unnecessarily obscure the present disclosure.

Many of the integrated circuits under development today are extremely complex. As a result, many chip designers have resorted to the System on a Chip or "SoC" approach, interconnecting a multiple sub-systems or IP agents on a single piece of silicon. SoCs are now available or are being developed for wide variety of applications, such as consumer devices (e.g., handheld, mobile phones, tablet computers, laptop and desktop computers, media processing etc.), virtual or augmented reality (e.g., robotics, autonomous vehicles, aviation, etc.), medical instrumentation (e.g., imaging, etc.), industrial, home automation, industrial (e.g., smart appliances, home surveillance, etc.) and data center applications (e.g., network switches, attached storage devices, etc.).

The present application is broadly directed to an arbitration system and method for arbitrating access to a shared resource. Such a shared resource can be, for example, a bus interconnect, a memory resource, a processing resource, or just about any other resource that is shared among multiple vying parties. For the sake of illustration, the shared resources as described in detail below is an interconnect that is shared by a plurality of sub-systems on a System on a Chip or "SoC".

With an SoC, as described in detail below, there are a plurality of sub-systems that exchange traffic with one another in the form of transactions, the shared resource is a physical interconnect, various transactions, or portions thereof, are transmitted over a multiplicity of virtual channels associated with the shared interconnect and one of a number of different arbitration schemes and/or priorities may be used to arbitrate access to the shared interconnect for the transmission of transactions between the sub-functions.

Within the above-mentioned shared interconnect used for SoCs, there are at least three types or classes of transactions, including Posted (P), Non-posted (NP) and Completion (C). A brief definition of each is provided in Table I below.

A Posted transaction, such as a write, requires no response transaction. Once a source writes data to a designated destination, the transaction is finished. With a Non-posted transaction, such as either a read or a write, a response is required. However, the response is bifurcated as a separate Completion transaction. In other words with a read, a first transaction is used for the read operation, while a separate, but related, Completion transaction is used for returning the read contents. With a Non-posted write, a first transaction is used for the write, while a second related Completion transaction is required for the confirmation once the write is complete.

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

A beat is the amount of data that can be transmitted over the shared interconnect per clock cycle. For example if the shared interconnect is physically <NUM> bits wide, then <NUM> bits can be transmitted each beat or clock cycle.

In some circumstances, a transaction may need to be divided into multiple portions for transmission. Consider a transaction having a single packet that has a payload that is <NUM> bits (<NUM> bytes). If the shared interconnect is only <NUM> bits wide (<NUM> bytes), then the transaction needs to be segmented into four portions (e.g. <NUM> x <NUM> = <NUM>) and transmitted over four clock cycles or beats. On the other hand if a transaction is only a single packet that is <NUM> bits wide or less, then the entire transaction can be sent in one clock cycle or beat. If the same transaction happens to include additional packets, then additional clock cycles or beats may be needed.

The term "portion" of a transaction is therefore the amount of data that can be transferred over the shared interconnect during a given clock cycle or beat. The size of a portion may vary depending on the physical width of the shared interconnect. For instance, if the shared interconnect is physically <NUM> data bits wide, then the maximum number of bits that can be transferred during any one cycle or beat is <NUM> bits. If a given transaction has a payload of <NUM> bits or less, then the entire transaction can be sent over the shared interconnect in a single portion. On the other hand if the payload is larger, then the packet has to be sent over the shared interconnect in multiple portions. A transaction with a payload of <NUM>, <NUM> or <NUM> bits requires two (<NUM>), four (<NUM>) and eight (<NUM>) portions respectively. As such, the term "portion" or "portions" should therefore be broadly construed to mean either part of or an entire transaction that may be sent over the share interconnect during any given clock cycle or beat.

A stream is defined as the pairing of a virtual channel and a transaction class. For instance, if there are four (<NUM>) virtual channels (e.g., VC0, VC1, VC2 and VC3) and three (<NUM>) transaction classes (P, NP, C), then there are a maximum of twelve (<NUM>) different possible streams. The various combinations of virtual channels and transaction classes are detailed below in Table II.

It should be noted that the number of transaction classes discussed above is merely exemplary and should not be construed as limiting. On the contrary, any number of virtual channels and/or transaction classes may be used.

Referring to <FIG>, a block diagram of an arbitration system <NUM> is shown. In a non-exclusive embodiment, the arbitration system is used for arbitrating access by a number of sub-functions <NUM> (i.e., IP<NUM>, IP<NUM> and IP<NUM>) to a shared interconnect <NUM> attempting to send transactions to upstream sub-functions <NUM> (i.e., IP<NUM>, IP<NUM> and IP<NUM>).

The shared interconnect <NUM> is a physical interconnect that is N data bits wide and includes M control bits. The shared interconnect <NUM> is also one-directional, meaning it handles traffic only from a source (i.e., IP<NUM>, IP<NUM> and IP<NUM>) to a destination (i.e., IP<NUM>, IP<NUM> and IP<NUM>).

In various alternatives, the number of N data bits can be any integer, but typically is some power of the number <NUM> (e.g., <NUM><NUM>, <NUM><NUM>, <NUM><NUM>,<NUM><NUM>, <NUM><NUM>, <NUM><NUM>, <NUM><NUM> ,<NUM><NUM> <NUM><NUM> etc.) or (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM> etc.) bits wide respectively. With most real-world applications, the number of N bits is either <NUM>, <NUM>, <NUM>, <NUM> or even <NUM>. However, it should be understood that these widths are merely illustrative and should not be construed as limiting in any manner.

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

One or more logical channels (not illustrated), hereafter referred to as "virtual channels" or "VCs" are associated with the shared interconnect <NUM>. Each virtual channel is independent. Each virtual channel may be associated with multiple independent streams. The number of virtual channels may widely vary. For example, up to thirty-two (<NUM>) or more virtual channels may be defined or associated with the shared interconnect <NUM>.

In various alternative embodiments, each virtual channel may be assigned a different priority. One or more virtual channel(s) may be assigned a higher priority, while one or more other virtual channel(s) may be assigned a lower priority. The higher priority channels are awarded or arbitrated access to the shared interconnect <NUM> over the lower priority virtual channels. With other embodiments, each of the virtual channels may be given the same priority, in which case, no preference is given to one virtual channel versus another when awarding or arbitrating access to shared interconnect <NUM>. In yet other embodiments, the priority assigned to one or more of the virtual channels may also dynamically change. For instance, in a first set of circumstances, all the virtual channels may be assigned the same priority, but in a second set of circumstances, certain virtual channel(s) can be assigned a higher priority than other virtual channel(s). Thus as circumstances change, the priority scheme used among the virtual channels can be varied to best meet current operating conditions.

Each of the sub-systems <NUM> is typically a block of "reusable" circuitry or logic, commonly referred to as an IP core or agent. Most IP agents are designed to perform a specific function, for example, controllers for peripheral devices such as an Ethernet port, a display driver, an SDRAM interface, a USB port, etc. Such IP agents are generally used as "building blocks" that provide needed sub-system functionality within the overall design of a complex system provided on an integrated circuit (IC), such as either an Application Specific Integrated Circuit (ASIC) or a Field Programmable Gate Array (FPGA). By using a library of available IP agents, a chip designer can readily "bolt" together various logic functions in the design of a more complex integrated circuit, reducing design time and saving development costs. Although sub-system agents <NUM> are described above in terms of a dedicated IP core, it should be understood that this is not a necessary requirement. On the contrary, a sub-system <NUM> can also be a collection of IP functions connected to or sharing a single port <NUM>. Accordingly, the term "agent" should be broadly construed as any type of sub-system connected to a port <NUM>, regardless if the sub-system performs a single function or multiple functions.

A pair of switches <NUM> and <NUM> provides access between each of the sub-system agents <NUM> and the shared interconnect <NUM> via dedicated access ports <NUM> respectively. With the exemplary embodiment shown:.

The switches <NUM> and <NUM> perform multiplexing and de-multiplexing functions. Switch <NUM> selects up-stream traffic generated by the sub-system agents IP<NUM>, IP<NUM>, and/or IP<NUM> and sends the traffic downstream over the shared interconnect <NUM>. At the switch <NUM>, a de-multiplexing operation is performed and the traffic is provided to a target sub-system agent (i.e., either IP<NUM>, IP<NUM>, or IP<NUM>).

Each access port <NUM> has a unique port identifier (ID) and provides each sub-system agent <NUM> dedicated access to either switch <NUM> or <NUM>. For instance, sub-system agents IP<NUM>, IP<NUM> and IP<NUM> are assigned to access ports Port <NUM>, Port <NUM> and Port <NUM> respectively. Similarly, the sub-system agents IP<NUM>, IP<NUM> and IP<NUM> are assigned access ports Port <NUM>, Port <NUM> and Port <NUM> respectively.

Besides providing ingress and egress points to/from the switches <NUM>, <NUM>, the unique port IDs <NUM> are used for addressing traffic between the sub-system agents <NUM>. Each Port <NUM> has a certain amount of allocated addressable space in system memory <NUM>.

In certain non-exclusive embodiments, all or some of the access ports <NUM> can also be assigned a "global" port identifier as well their unique port ID. Transactions and other traffic can be sent to all or some of the access ports assigned to the global port identifier. Accordingly, with the global identifier, transactions and other traffic can be widely disseminated or broadcast to all or some of the access ports <NUM>, obviating the need to individually address each access port <NUM> using its unique identifier.

The switch <NUM> also includes an arbitration element <NUM>, Address Resolution Logic (ARL) <NUM> and an address resolution Look Up Table (LUT) <NUM>.

During operation, the sub-system agents IP<NUM>, IP<NUM> and IP<NUM> generate transactions. As each transaction is generated, it is packetized by the originating sub-system agent <NUM> and then the packetized transaction is injected via the corresponding port <NUM> into a local switch <NUM>. For instance, portions of transactions generated by IP<NUM>, IP<NUM> and IP<NUM> are provided to switch <NUM> by via ports Port <NUM>, Port <NUM> and Port <NUM> respectively.

The ports <NUM> each include a number of first-in, first-out buffers (not illustrated) for each of the virtual channels associated with the interconnect channel <NUM> respectively. In a non-exclusive embodiment, there are four (<NUM>) virtual channels. In which case, each port <NUM> includes four buffers, one for each virtual channel. Again, it should be understood that the number of virtual channels and buffers contained in the ports <NUM> may vary and is not limited to four. On the contrary, the number of virtual channels and buffers may be more or less than four.

If a given transaction is represented by two (or more) portions, those portions are maintained in the same buffer. For instance, if interconnect <NUM> is <NUM> data bits wide and a transaction is represented by a packet containing a payload of <NUM> bits, then the transaction needs to be segmented into four (<NUM>) portions that are transmitted over four clock cycles or beats. On the other hand if the transaction can be represented by a single packet having a payload of <NUM> bits, then the single portion can be transmitted in one clock cycle or beat. By maintaining all the portion(s) of given transaction in the same buffer, the virtual channels remain logically independent. In other words, all the traffic associated with a given transaction is always sent over the same virtual channel as a stream and is not bifurcated over multiple virtual channels.

The arbitration element <NUM> is responsible for arbitrating among the competing buffered portions of transactions maintained by the various access ports <NUM>. In a non-exclusive embodiment, the arbitration element <NUM> performs an arbitration every clock cycle, provided multiple competing transactions are available. The arbitration winner per cycle yields a portion of a transaction, from one of the sub-systems IP<NUM>, IP<NUM> and IP<NUM>, that is granted access to and is transmitted over the interconnect <NUM>.

When generating transactions, the source sub-system IP<NUM>, IP<NUM> and IP<NUM> ordinarily knows the address in the address space for the possible destination sub-system agents IP<NUM>, IP<NUM> and IP<NUM>, but does not know the information (e.g., the Port IDs <NUM> and/or <NUM>) needed to route the transactions to their destinations. In one embodiment, the local Address Resolution Logic (ARL) <NUM> is used for resolving the known destination address into the needed routing information. In other words, a source sub-agent <NUM> may simply know that it wishes to access a given address in system memory <NUM>. The ARL <NUM> is therefore tasked to access the LUT <NUM> and performs an address look up of the port(s) <NUM>/<NUM> along the delivery path to the final destination corresponding to the specified address. Once the ports <NUM>/<NUM> is/are known, this information is inserted in a destination field in the packet(s) of the transaction. As a result, the packet(s) is/are delivered to the ports <NUM>/<NUM> along the delivery path. As a general rule, downstream nodes along the delivery path do not have to perform additional look up(s) since the required delivery information is already known and included in the destination field of the packet(s). With other types of transactions, referred to as Source Based Routing (SBR) as described in more detail below, the source IP agent knows the destination port address. As a result, the lookup performed by the ARL <NUM> typically does not need to be performed.

In an alternative embodiment, not all the nodes within the interconnect require an ARL <NUM> and LUT <NUM>. For nodes that do not have these elements, transactions without needed routing information can be forwarded to a default node. At the default node, an ARL <NUM> and LUT <NUM> are accessed and the needed routing information can then be inserted into the headers of the packet(s) of transactions. The default node is typically upstream from the node without the ARL <NUM> and LUT <NUM>. However, this is by no means a requirement. The default node, or nodes, can be located anywhere on the SoC. By eliminating ARLs <NUM> and LUTs <NUM> from certain nodes, their complexity can be reduced.

The ARL <NUM> may also be referred to as an "ordering point" because, besides decoding the forwarding destination for winning portion(s) of transactions, it defines a sequence order for the winning portion(s) of transactions within each virtual channel. As each arbitration is resolved, regardless of whether or not the ARL <NUM> is used to perform an address port lookup, the winning portions of transactions are inserted into a first-in, first out queue provided for each virtual channel. The winning portions of transactions then await their turn for transmission over the interconnect <NUM> in the buffer.

The ARL <NUM> is also used for defining "upstream" and downstream" traffic. In other words any transactions generated by the IP agents <NUM> associated with switch <NUM> (i.e., IP<NUM>, IP<NUM> and IP<NUM>) is considered upstream with respect to the ARL <NUM>. All transaction post the ARL <NUM> (i.e., transmitted to IP<NUM>, IP<NUM> and IP<NUM>) is considered downstream traffic.

The IP agents <NUM> associated with switch <NUM> (i.e., IP<NUM>, IP<NUM> and IP<NUM>) may communicate and send transactions to one another, either directly or indirectly. With direct communication, often referred to as Source Based Routing (SBR), the IP agents <NUM> can send transactions to one another in a peer-to-peer model. With this model, the source IP agent knows the unique Port ID of its peer IP agents <NUM>, bypassing the need to use the ARL <NUM> to access the LUT <NUM>. Alternatively, the transactions between the IP agents associated with the switch <NUM> can be routed using the ARL <NUM>. With this model, similar to that described above, the source IP agent only knows the address of the destination IP agent <NUM>, but not the information needed for routing. The ARL <NUM> is then used to access the LUT <NUM>, find the corresponding Port ID, which is then inserted into the destination field of the packet(s) of the transaction.

The IP agents <NUM> create and process transactions over virtual channels associated with the interconnect <NUM>. Each transaction typically is made up of one or more packets. Each Packet typically has a fixed header size and format. In some instances, each packet may have a fixed sized payload. In other instances, packet payloads may vary in size, from large too small, or even with no payload at all.

Referring to <FIG>, an exemplary packet <NUM> is shown. The packet <NUM> includes a header <NUM> and a payload <NUM>. In this particular embodiment, the header <NUM> is sixteen (<NUM>) Bytes in size. It should be understood that this size is exemplary and either a larger size (e.g., more Bytes) or smaller size (e.g., fewer Bytes) packets may be used. It should also be understood that headers <NUM> of packets <NUM> do not necessarily have to all be the same size. In alternative embodiments, the size of packet headers in a SoC may be variable.

The header <NUM> includes a number of fields including 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), a transaction ID field (TAG), an address or ADDR field, a USDR/Compact payload field, a transaction Class or TC field, a format FMT filed, and a Byte Enable (BE) field. The various fields of the header <NUM> are briefly described in Table III below.

The payload <NUM> contains the contents of the packet. The size of the payload may vary. In some instances, the payload may be large. In other instances, it could be small. In yet other instances, if the content is very small or "compact", it can be transported in the USRD field of the header <NUM>.

The type of transaction will often dictate whether or not the packet(s) used to represent the transaction has/have payloads or not. For example with either a Posted or Non-posted read, the packet(s) will designate the location address to be accessed, but will typically have no payload. The packets for the related Completion transaction, however, will include payload(s) containing the read content. With both Posted and Non-posted write transactions, the packet(s) will include a payload containing the data to be written to the destination. With Non-posted versions of a write, the packets for the Completion transaction will ordinarily not defined a payload. However, in some situations, a Completion transaction will define a payload.

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

Referring to <FIG>, a logic diagram illustrating the arbitration logic performed by the arbitration element <NUM> with Peripheral Component Interconnect (PCI) ordering is shown.

With PCI ordering, each Port <NUM> includes separate buffers for each virtual channel and transaction class (P, NP and C) combination. For instance, with four virtual channels (VC0, VC1, VC2 and VC3), the Ports <NUM>, Port <NUM> and Port <NUM> each have twelve first-in, first-out buffers. In other words for each Port <NUM>, a buffer is provided for each transaction class (P, NP, and C) and virtual channel (VC0, VC1, VC2 and VC30 combination.

As each IP agent <NUM> (e.g., IP<NUM>, IP<NUM> and IP<NUM>) generates transactions, the resulting packets are placed in the appropriate buffer, based on transaction type, in the corresponding port (e.g., Port <NUM>, Port <NUM> and Port <NUM>) respectively. For instance, Posted (P), Non-posted (NP) and Completion (C) transactions generated by IP<NUM> are each placed in the Posted, Non-posted and Completion buffers for the assigned virtual channel in Port <NUM> respectively. Transactions generated by IP<NUM> and IP<NUM> are similarly placed in the Posted, Non-posted and Completion buffers for the assigned virtual channels in Ports <NUM> and Port <NUM> in a similar manner.

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

Within each port <NUM>, packets can be assigned to a given virtual channel in a number of different ways. For instance, the assignment can be arbitrary. Alternatively, the assignment can be based on workload and the amount of outstanding traffic for each of the virtual channels. If one channel is very busy and the other not, then the port <NUM> will often attempt to balance the load and assign newly generated transaction traffic to under-utilized virtual channels. As a result, routing efficiency is improved. In yet other alternatives, transaction traffic can be assigned to a particular virtual channel based on urgency, security, or even a combination of both. If a certain virtual channel is given a higher priority and/or security than others, then high priority and/or secure traffic is assigned to the higher priority virtual channel. In yet other embodiments, a port <NUM> can be hard-coded, meaning the port <NUM> has only one virtual channel and all traffic generated by that port <NUM> is transmitted over the one virtual channel. In yet other embodiments, the assignment can be based on the route chosen to reach the destination port <NUM>.

In yet other embodiments, the assignment of virtual channels can be implemented by the source IP agents <NUM>, either alone or in cooperation with its corresponding port <NUM>. For example, a source IP agent <NUM> can generate a control signal to the corresponding port <NUM> requesting that packet(s) of a given transaction be assigned to a particular virtual channel. IP agents <NUM> can also make assignment decisions that are arbitrary, hard coded, based on balanced usage across all the virtual channels, security, urgency, etc., as discussed above.

In selecting an arbitration winner, the arbitration element <NUM> performs multiple arbitration steps per cycle. These arbitration steps include:.

The above order (<NUM>), (<NUM>) and (<NUM>) is not fixed. On the contrary, the above three steps 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 over the corresponding virtual channel associated with the interconnect <NUM>.

For each arbitration (<NUM>), (<NUM>) and (<NUM>) performed by arbitration element <NUM>, a number of arbitration schemes or rule sets may be used. Such arbitration schemes may include strict or absolute priority, a weighed priority where each of the four virtual channels is assigned a certain percentage of transaction traffic or a round-robin scheme where transactions are assigned to virtual channels in a predefined sequence order. In additional embodiments, other priority scheme such may be used. Also, it should be understood that the arbitration element <NUM> may dynamically switch among the different arbitration schemes from time-to-time and/or use the same or different arbitration schemes for each of the (<NUM>), (<NUM>) and (<NUM>) arbitrations respectively.

In an optional embodiment, availability of the destination ports <NUM> defined by the outstanding transaction(s) considered during a given arbitration cycle are considered. If a buffer in a destination port <NUM> does not have the resources available to process a given transaction, then the corresponding virtual channel is not available. As a result, the transaction in question does not compete in the arbitration, but rather, waits until a subsequent arbitration cycle when the target resource becomes available. On the other hand, when target resource(s) is/are available, the corresponding transaction(s) are arbitrated and compete for access to the interconnect <NUM>.

The availability of the destination ports <NUM> may be checked at different times with respect to the multiple arbitration steps (<NUM>), (<NUM>) and (<NUM>) noted above. For instance, the availability check can be performed prior to the arbitration cycle (i.e., prior to completion of any of steps (<NUM>), (<NUM>) and (<NUM>)). As a result, only transactions that define available destination resources is/are considered during the subsequent arbitration. Alternatively, the availability check can be performed intermediate any of the three arbitration steps (<NUM>), (<NUM>) and (<NUM>), regardless of the order in which they are implemented.

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

For the arbitration step involving the selection of a transaction class, a number of rules are defined to arbitrate among competing portions of N, NP and C transactions. These rules include:.

Table IV below provides a summary of the PCI ordering rules. In the boxes with no (a) and (b) options, then the strict ordering rules need to be followed. In the boxes of the Table having (a) and (b) options, either strict order (a) or relaxed order (b) rules may be applied, depending on if the RO bit is reset or set respectively. In various alternative embodiments, the RO bit can be set or reset either globally or on individually on the packet level.

The arbitration element <NUM> selects an ultimate winning transaction portion by performing, in no particular order, arbitrations among competing Ports <NUM>, virtual channels and transactions classes respectively. The winning portion per cycle gains access to the shared interconnect <NUM> and is transmitted over the corresponding virtual channel.

Referring to <FIG>, a logic diagram illustrating the arbitration logic performed by the arbitration element <NUM> with Device ordering is shown. The arbitration process, and possibly the consideration of available destination resources, is essentially the same as described above, except for two distinctions.

First, with Device ordering, there are only two transaction classes defined, including (a) Non-posted read or write transactions where a response for every request is required and (b) Completion transactions, which defined the required responses. Since there are only two transaction classes, there are only two (<NUM>) buffers per virtual channel in each Port <NUM>. For instance, with four (<NUM>) virtual channels (VCO, VC1, VC2 and VC3), each Port <NUM> (e.g., Port <NUM>, Port <NUM> and Port <NUM>) has a total of eight (<NUM>) buffers.

Second, the rules for selecting a Transaction for Device ordering are also different than PCI ordering. With Device ordering, there are no strict rules governing the selection of one class over the over class. On the contrary, either transaction class can be arbitrarily selected. However, common practice typically calls for favoring Completion transactions to free up resources that may not be available until a Completion transaction is resolved.

Otherwise, the arbitration process for Device order is essentially the same as described above. In other words for each arbitration cycle, the arbitration steps (<NUM>), (<NUM>) and (<NUM>) are performed, in any particular order, to select an arbitration winner. When the transaction class arbitration is performed, Device order rather than PCI order rules are used. In addition, the availability of destination resources and/or virtual channels may also be considered either prior to or intermediate any of the arbitration steps (<NUM>), (<NUM>) and (<NUM>).

As previously noted, the above-described arbitration scheme can be used for sharing access to any shared resource and is not limited to use with just a shared interconnect. Such other shared resources may include the ARL <NUM>, a processing resource, a memory resource such as the LUT <NUM>, or just about any other type of resource that is shared among multiple parties vying for access.

Referring to <FIG>, a flow diagram <NUM> illustrating operational steps for arbitrating access to a shared resource is shown.

In step <NUM>, the various source sub-system agents <NUM> generate transactions. The transactions can be any of the three classes, including Posted (P), Non-posted (NP) and Completion (C).

In step <NUM>, each of the transactions generated by the source sub-system agents <NUM> are packetized. As previously noted, packetization of a given transaction may result in one or multiple packets. The packets may also vary in size, with some packets having large payloads and others having small or no payloads. In situations where a transaction is represented by a single packet having a data payload <NUM> that is smaller than the width of the interconnect <NUM>, the transaction can be represented by a single portion. In situations where a transaction is represented by multiple packets, or a single packet with a data payload <NUM> that is larger than the access width of the shared resource, then multiple portions are needed to represent the transaction.

In step <NUM>, the portion(s) of the packetized transactions generated by each of the sub-system agents <NUM> are injected into the local switch <NUM> via its corresponding port <NUM>. Within the port <NUM>, the packet(s) of each transaction are assigned to a virtual channel. As previously noted, the assignment can be arbitrary, hard coded, based on balanced usage across all the virtual channels, security, urgency, etc..

In step <NUM>, the portion(s) of the packetized transactions generated by each of the sub-system agents <NUM> are stored in the appropriate, first-in, first-out, buffer by both transaction class and by their assigned virtual channel (e.g., VC0, VC1, VC2 and VC3) respectively. As previously noted, virtual channels may be assigned by one of a number of different priority schemes, including strict or absolute priority, round-robin, weighted priority, least recently serviced, etc. If a given transaction has multiple portions, each portion will be stored in the same buffer. As a result, the multiple portions of a given transaction are transmitted over the same virtual channel associated with the interconnect <NUM>. As transaction portions are injected, the corresponding a counter for tracking the number content items in each buffer is decremented. If a particular buffer is filled, its counter is decremented to zero, meaning the buffer can no longer receive additional contents.

In steps <NUM>, <NUM> and <NUM>, first, second and third level arbitrations are performed. As previously noted, the selection of a Port <NUM>, a virtual channel and a transaction class can be performed in any order.

Element <NUM> may be used to maintain the rules used to perform the first, second and third levels of arbitration. In each case, the element <NUM> is used as needed in resolving each of the arbitration levels. For instance, element <NUM> may maintain PCI and/or Device ordering rules. Element <NUM> may also contain rules for implementing several priority schemes, such as strict or absolute priority, weighted priority, round robin, etc., and the logic or intelligence for deciding which to use in a given arbitration cycle.

In step <NUM>, a winner of the arbitration is determined. In step <NUM>, the winning portion is placed in a buffer used for accessing the shared resource and a counter associated with the buffer is decremented.

In step <NUM>, the buffer associated with the winning portion is incremented since the winning portion is no longer in the buffer.

In step <NUM>, the winning portion gains access to the shared resource. Once the access is complete, the buffer for the shared resource is incremented.

The steps <NUM> through <NUM> are continually repeated during successive clock cycles respectively. As different winning portions, each gains access to the shared resource.

Transactions can be transmitted over the interconnect <NUM> in one of several modes.

In one mode, referred to as the "header in-line" mode the header <NUM> of packet(s) <NUM> of a transaction are always transmitted first ahead of the payload <NUM> in separate portions or beats respectively. The header in-line mode may or may not be wasteful of the bits available on the interconnect <NUM>, depending the relative size of the header <NUM> and/or the payload <NUM> with respect to the number of data bits N of the interconnect <NUM>. For instance, consider an interconnect <NUM> that is <NUM> bits wide (N = <NUM>) and a packet having a header that is <NUM> bits and a payload of <NUM> bits. With this scenario, the <NUM> bits of the header are transmitted in a first portion or beat, while the remaining <NUM> bits of bandwidth of the interconnect <NUM> are not used. In a second portion or beat, the <NUM> bits of the payload <NUM> are transmitted, while the remaining <NUM> bits of the interconnect <NUM> are not used. In this example, a significant percentage of the bandwidth of the interconnect is not used during the two beats. On the other hand if the majority of the packets of transactions are the same size or larger than the interconnect, than the degree of wasted bandwidth is reduced or possibly eliminated. For example with headers and/or payloads that are <NUM> or <NUM> bits, the amount of waste is either significantly reduced (e.g., with <NUM> bits) or eliminated altogether (e.g., with <NUM> bits).

In another mode, referred to as "header on side-band", the header <NUM> of a packet is transmitted "on the side" of the data, meaning using the control bits M, while the payload <NUM> is transmitted over the N data bits of the interconnect <NUM>. With the header on side band mode, the number of bits or size of the payload <NUM> of a packet <NUM> determines the number of beats needed to transmit the packet over a given interconnect <NUM>. For instance, with a packet <NUM> having a payload <NUM> of <NUM>, <NUM>, <NUM> or <NUM> bits and an interconnect <NUM> having <NUM> data bits (N=<NUM>), the packet requires <NUM>, <NUM>, <NUM> and <NUM> beats respectively. With the transmission of each of the beat(s), the header information is transmitted over the control bits M along with or "on the side" of the data of the payload over the N data bits of the interconnect <NUM>.

In yet another mode, the header <NUM> of packets <NUM> are transmitted in line with the payload, but there is no requirement that the header <NUM> and the payload <NUM> must be transmitted in separate portions or beats. If a packet <NUM> has a header <NUM> that is <NUM> bits and a payload <NUM> that is <NUM> bits, then the total size is <NUM> bits (<NUM> + <NUM>). If the N data bits of interconnect <NUM> is <NUM>, <NUM>, <NUM> or <NUM> bits wide, then a packet of <NUM> bits is transmitted in <NUM>, <NUM>, <NUM> and <NUM> beats respectively. In another example, a packet <NUM> has a header of <NUM> bits and a payload <NUM> of <NUM> bits, or a total packet size of <NUM> bits (<NUM> + <NUM>). With the same interconnect <NUM> of N data bits of <NUM>, <NUM>, <NUM> or <NUM> wide, the packet is transmitted in <NUM>, <NUM>, <NUM>, or <NUM> beats respectively. This mode will always be as least as efficient or more efficient as the header in-line mode described above.

Referring to <FIG>, a first example of the interleaving of portions of different transactions over multiple virtual channels is illustrated. In this example, for the sake of simplicity, only two transactions are defined. The two transactions are competing for access to shared interconnect <NUM>, which is <NUM> data bits wide (N = <NUM>) in this example. The details of the two transactions include:.

In this example, VCO is assigned absolute or strict priority. Over the course of multiple cycles, the portions of the two transactions T1 and T2 are transmitted over the shared interconnect, as depicted in <FIG>, as follows:.

This example illustrates (<NUM>) with a virtual channel with absolute priority, access to the shared interconnect <NUM> is immediately awarded whenever traffic becomes available, regardless of whether or not other traffic has been previously waiting and (<NUM>) the winning portions or beats of different transactions are interleaved and transmitted over different virtual channels associated with the interconnect <NUM>. In this example, virtual channel VCO was given absolute priority. It should be understood that with absolute or strict priority schemes, any of the virtual channels may be assigned the highest priority.

Referring to <FIG>, a second example of the interleaving of portions of different transactions over multiple virtual channels is illustrated.

In this example, the priority scheme for access to the interconnect <NUM> is weighted, meaning VCO is awarded access (<NUM>%) of the time and VC1-VC3 are each awarded access (<NUM>%) of the time respectively. Also, the interconnect is <NUM> bits wide.

Further in this example, there are four competing transactions, T1, T2, T3 and T4:.

With this example the priority scheme is weighed. As a result, each virtual channel will win according to its weight ratio. In other words over the course of ten cycles, VCO will win four times and VC1, VC2 and VC3 will each win two times. For instance, as illustrated in <FIG>:.

This example thus illustrates: (<NUM>) a weighted priority scheme where each virtual channel is awarded access to the interconnect <NUM> based on a predetermined ratio and (<NUM>) another illustration of the winning portions of different transactions being interleaved and transmitted over different the virtual channels associated with the interconnect <NUM>.

It should be understood with this weighted example there is sufficient traffic to allocate portions of transactions to the various virtual channels in accordance with the weighted ratios. If the amount of traffic on the other hand is insufficient, then the weighted ratios can be either strictly or not strictly enforced. For example, if there is a large degree of traffic on virtual channel VC3 and limited to no traffic on the other virtual channels VC0, VC1 and VC2, then VC3 will carry all or a bulk of the traffic if the weighted ratio is strictly enforced. As a result, however, the interconnect <NUM> may be under-utilized as portions of transactions may not be sent every clock cycle or beat. On the other hand if the weighted ratio is not strictly enforced, then it is possible for the transaction traffic to be reallocated to increase the utilization of the interconnect (e.g., traffic is sent over a higher number of cycles or beats).

The above two examples are applicable regardless which of the above-described transmission modes are used. Once transaction(s) is/are divided into portions or beats, they can be interleaved and transmitted over the shared interconnect <NUM> using any of the arbitration schemes as defined herein.

The above-described arbitration schemes represent just a few examples. In other examples, low jitter, weighted, strict, round-robin or just about any other arbitration scheme may be used. The arbitration schemes listed or described herein should therefore be considered as exemplary and not limiting in any manner.

Up to now, for the sake of simplicity, only a single arbitration has been described. It should be understood, however, that in real-world applications, such as on a SoC, multiple arbitrations may occur simultaneously.

Referring to <FIG>, a block diagram of two shared interconnects <NUM> and 12Z for handling traffic in two directions between switches <NUM>, <NUM> is illustrated. As previously described, the switch <NUM> is responsible for directing transaction traffic from source sub-functions <NUM> (i.e., IP<NUM>, IP<NUM> and IP<NUM>) to destination sub-functions <NUM> (i.e., IP<NUM>, IP5 and IP<NUM>) over the shared interconnect <NUM>. To handle transactional traffic in the opposite direction, switch <NUM> includes arbitration element 26Z and optionally ARL 28Z. During operation, elements 26Z and ARL 28Z operate in the complement of that described above, meaning transaction traffic generated by source IP agents <NUM> (i.e., IP<NUM>, IP<NUM> and IP<NUM>) is arbitrated and sent over shared interconnect 12Z to destination IP agents (i.e., IP<NUM>, IP<NUM> and IP<NUM>). Alternatively, the arbitration can be performed without the ARL 28Z, meaning the arbitration simply decides among competing ports <NUM> (e.g., Port <NUM>, port <NUM> or Port <NUM>) and the portion of the transaction associated with the winning port is transmitted over the interconnect <NUM>, regardless of the final destination of the portion. As elements 12Z, 26Z and 28Z have previously been described, a detailed explanation is not provided herein for the sake of brevity.

In a SoC, there can be multiple levels of sub-functions <NUM> and multiple shared interconnects <NUM>. With each, the above described arbitration scheme can be used to arbitrate among transactions sent over the interconnects <NUM> between the various sub-functions simultaneously.

Referring to <FIG>, a block diagram of an SoC <NUM> having reset and power management functionality is illustrated. The SoC <NUM> includes an interconnect <NUM>, a plurality of IP agents <NUM> (e.g., Agent <NUM> through Agent N), one or more links <NUM> connecting or coupling the IP agents <NUM> to the interconnect <NUM>, and a system controller <NUM>. Although not illustrated, each IP agent <NUM> may also include one or more dedicated "hard-wire" inputs for receiving reset input instructions. Such instructions may come from a number of sources, including from off the SoC, the system controller <NUM>, or another IP agent <NUM>, etc..

In various embodiments, the IP agents <NUM> may be disparate and may implement a wide variety of different functions.

The interconnect <NUM> can be a wide variety of different types of interconnects, such a Network on a Chip (NoC), a bus, a switching network, etc..

In various embodiments, the links <NUM> may each be a dedicated link or a bus between each IP agent <NUM> and the interconnect <NUM>. Access to the interconnect <NUM> can be shared among multiple IP agents <NUM> using one link <NUM> and an arbitration scheme is used to select among the competing IP agents <NUM>. In yet another embodiment, a number of virtual channels may be associated with the one or more links <NUM>, such as the virtual channels associated with the shared link as previously described.

The system controller <NUM> and the managers <NUM>, <NUM> and <NUM> may also be implemented in a number of different ways. For instance, as a CPU or microcontroller, as programmable logic, a complex state machine for handling all or most system control functions on the SoC <NUM>, a simple state machine for handling a few exception situations, or any combination thereof. The system controller <NUM> may reside on the SoC <NUM> as shown or, alternatively, located off the SoC <NUM> (not illustrated). Where a state machine is used, the states and the transitions between the states is typically hard-coded into the SoC <NUM>.

In yet other embodiments, one or more of the reset, power and/or quiesce managers <NUM>, <NUM> and <NUM> can each be centralized within the system controller <NUM> as shown. Alternatively, each manager <NUM>, <NUM> and/or <NUM> can be decentralized and distributed throughout various locations on the SoC <NUM> or even off the SoC. Each of the reset manager <NUM>, the power manager <NUM> and the quiesce manager <NUM> can be implemented in software, hardware, programmable logic, a state machine or any other suitable means.

The reset manager <NUM> is responsible for managing the emergence of the various IP agents <NUM> on the SoC <NUM> from reset in an organized manner. A reset of an IP agent <NUM> may be required or desired under a number of circumstances. For instance, a "cold reset" occurs following removal or disruption of power provided to the SoC <NUM> or a system wide reset of the SoC <NUM>. Alternatively, a "warm reset" occurs when one, a group or even all the IP agents <NUM> (similar to a cold reset) are reset, but power is not removed or disrupted from the SoC <NUM>. A warm reset can be implemented via signaling that originates either on the SoC <NUM> or externally. Regardless of how a reset is initiated, the reset manager <NUM> is responsible for managing the emergence of the IP agent <NUM> or IP agents <NUM> from reset in an organized manner.

If an IP agent <NUM> is malfunctioning for some reason, it may have to be reset. Examples of malfunctioning IP agents <NUM> include situations where the IP agent <NUM> is non-responsive, is in an error state, or actively generating erroneous transactions. In yet other examples, an IP agent <NUM> may have to undergo a reset operation upon exiting a lower power state, such as one of several power saving modes as described below.

The power manager <NUM> manages the process of placing the various IP agents <NUM> into a lower power state, typically one of several power saving modes. Depending on the mode, the power manager <NUM> may operate in cooperation with the reset manager <NUM> to reset an IP agent <NUM> if necessary.

The quiesce manager <NUM> operates in cooperation with the system controller <NUM>, reset manager <NUM>, power manager <NUM> and the interconnect <NUM> to (<NUM>) transition an operational or malfunctioning IP agent <NUM> into either a reset or a power savings mode where the IP agent becomes inoperable, (<NUM>) places the link <NUM> between the interconnect and the IP agent <NUM> into a quiescent state and (<NUM>) directs the interconnect to operate as a proxy for the IP agent while inoperable.

The memory <NUM> may include both volatile and non-volatile types of memory. In addition, the memory <NUM> may be centralized on the SoC <NUM> or may be widely distributed among the system controller <NUM>, the interconnect <NUM>, the links <NUM>, and any of the managers <NUM>, <NUM> and/or <NUM>. In yet other embodiments, portions or all of the memory <NUM> may be provided off the SoC <NUM>.

The volatile portions of the memory <NUM> are typically used for system memory, where the current data generated by the system controller <NUM>, managers <NUM>, <NUM>, <NUM>, interconnect <NUM>, IP agents <NUM>, etc., are stored. Such memory may include various caches, SRAM, DRAM, etc..

The non-volatile or persistent portions of memory <NUM> is typically used for storing "boot-up" code for the SoC <NUM>. The boot code enables the system controller <NUM>, including the managers <NUM>, <NUM>, <NUM>, the interconnect <NUM> and the IP agents <NUM>, to each load their operating systems and/or other system software as needed to initiate operation after powering on. The reboot process typically includes a number of self-tests, which when completed, allow the entire system, including each of the IP agents <NUM>, to perform their normal operations. The non-volatile or persistent portions may be implemented using NVRAM (non-volatile random-access memory), EEPROM (electrically erasable programmable read only memory), a hard drive, CD ROM, etc..

The reset manager <NUM> is responsible for coordinating the emergence from reset of any of the IP agents <NUM> in an organized manner. As noted herein, a reset of a given IP agent <NUM> may occur for any number of reasons, including (<NUM>) when the entire SoC <NUM> emerges from reset following an external reset, a re-start command or a power-on event or (<NUM>) or an individual IP agent <NUM> reset during operation of the SoC <NUM> due to malfunction, following a power down or sleep mode, etc. Regardless of the reason, a given IP agent <NUM> is ready to be introduced to the interconnect <NUM> once its internal reset sequence is complete. Upon emergence from reset, a negotiation is then coordinated between the IP agent <NUM> and its IP port <NUM> on the interconnect <NUM> over the link <NUM>.

Referring to <FIG> is a flow diagram showing an exemplary IP agent reset negotiation sequence between an IP agent <NUM> and the interconnect <NUM>.

In the initial step <NUM>, a determination is made if an IP agent <NUM> has emerged from reset and is ready to be introduced to the interconnect <NUM> or not. When emergence occurs, the subsequent steps <NUM> through <NUM> are followed to reintroduce the IP agent <NUM> to the interconnect <NUM>.

In step <NUM>, the interconnect <NUM> generates inquires for the IP agent <NUM> at periodic intervals. With each inquiry, the interconnect <NUM> essentially asks the IP agent <NUM> if it is "awake" (i.e., is it transaction ready, meaning is it capable of sending or processing received transactions).

In decision <NUM>, the interconnect determines if it has received a positive response to the inquiry(s) from the IP agent <NUM>. If not, then the interconnect <NUM> continues to send the inquiries. If yes, then it signifies to the interconnect <NUM> that the IP agent <NUM> has partially completed its reset routine and is ready for the next phase of the negotiation.

In step <NUM>, the interconnect <NUM> and the IP agent <NUM> continue their negotiation by exchanging their credit information respectively. The interconnect <NUM> and the IP agent <NUM> each exchange with the other the available number of beats (i.e., the amount of data that can be transmitted over the link <NUM> per clock cycle. Each partner on opposing sides of the link <NUM>, after the exchange, knows the available number of credits the other has as a result of this negotiation.

In an optional step <NUM>, interconnect <NUM> and the IP agent <NUM> continue their negotiation by exchanging other useful information such as security credentials, an agreed upon number of virtual channels that may be associated with the link <NUM> coupling the interconnect <NUM> and the IP agent <NUM>, etc..

In the last step <NUM>, when the negotiation is complete, the IP agent <NUM> is declared "transaction ready". In other words, the IP agent is ready to either process incoming transactions received from the interconnect <NUM> or to send outgoing transactions over the interconnect <NUM> to another destination. Once the IP agent <NUM> is transaction ready, it becomes visible to both the interconnect <NUM>, the system controller <NUM> and any other element connected or otherwise coupled to the interconnect <NUM>, either directly or indirectly through intermediate circuitry, logic or other element.

The reset manager <NUM> is also responsible for coordinating the reset of malfunctioning IP agents <NUM>. During operation of the SoC <NUM>, an IP agent <NUM> may misbehave (e.g., become non-responsive, enter an error state, erroneously generate transactions, or otherwise malfunction). For instance, the IP agent may be unable to process a received transaction. As a result, the originating IP agent that sent the transaction may get hung up waiting for a response. Depending on the severity of the problem, the hang up can be limited to just the originating IP agent <NUM>, the destination IP agent <NUM>, or in a worst case scenario, other portions or even the entire SoC <NUM> may be adversely affected. Accordingly, in certain circumstances, the misbehaving IP agent may need to be reset to correct the issue.

Referring to <FIG> , a flow diagram <NUM> showing a reset sequence for a malfunctioning IP agent is shown.

In step <NUM>, the various IP agents <NUM> on the SoC <NUM> operate as normal by generating transmitted transactions and/or processing received transactions.

In decision step <NUM>, the system controller <NUM> monitors the operation of the IP agents. If no problems are detected, then the IP agents <NUM> continue their normal operation. On the other hand if an IP agent malfunctions, for any reason, then the reset manager <NUM> flags it as a malfunctioning IP agent <NUM>.

In step <NUM>, the system controller <NUM> and interconnect <NUM> further cooperate to initiate a number of processes that help the remainder of the SoC <NUM> operate without further issues or problems. These additional processes may include:.

In step <NUM>, the reset manager <NUM> generates a reset instruction for the malfunctioning IP agent <NUM>.

In <NUM>, the link <NUM> between the IP agent <NUM> to be reset and the interconnect <NUM> is placed in a quiescent state. This process is further described with regard to <FIG>.

In step <NUM>, the malfunctioning IP agent <NUM> initiates its reset routine in response to the instruction received over the interconnect <NUM> or which may be received via a dedicated reset wire. This process involves the IP agent <NUM> (<NUM>) executing its own reset protocol or routine and (<NUM>) negotiating with the interconnect <NUM>, as described above with regard to <FIG>.

In decision step <NUM>, it is determined if the reset negotiation of the IP agent <NUM> is complete. When complete, control returns to step <NUM> and operation of the IP agents <NUM> and the SoC <NUM> resume as normal. As noted above, the reset IP agent <NUM> becomes visible to the interconnect <NUM> and the system controller after emerging from the reset and becomes transaction ready. Finally, in step <NUM>, the link <NUM> between the now reset IP agent <NUM> and the interconnect <NUM> exits the quiescent mode. At this point, the interconnect <NUM> no longer needs to act as a proxy for the IP agent <NUM>.

The power manager <NUM> is responsible for intelligently and selectively placing IP agents <NUM> into a lower power state, by placing the IP agents <NUM> in one of several power down modes. The powering down or placing of IP agents <NUM> into a powered down mode can be can be performed for a variety of reason.

For example, if the SoC <NUM> is used in a battery powered device, the power manager <NUM> may place IP agents into a power down mode to preserve limited battery power. Alternatively, even in non-battery powered devices, the power manager <NUM> may place non-critical IP agents <NUM> into a low power mode to prevent overheating. These are just a few of the possible reasons for implementing power management. Other reasons may include placing one or more IP agents <NUM> in a power down mode if they are not being used. In various alternative embodiments, the power down modes include:.

<FIG> is a flow diagram <NUM> illustrating a sequence for placing an IP agent <NUM> in and out of the Low Power, Operational Mode.

In the initial step <NUM>, the IP agent <NUM> on the SoC <NUM> operates in its normal mode, meaning the standard clock frequency and voltage are used.

In decision step <NUM>, conditions within the SoC <NUM> are monitored by the system controller <NUM>. If operating conditions are relatively normal or no event occurs triggering a power down of the IP agent <NUM>, then the SoC and IP agent <NUM> continues to operate in its normal mode per step <NUM>. However, if a trigger condition is met (e.g., a reduced battery supply, overheating, etc.), then the power manager <NUM> may elect to place the IP agent <NUM> into the low, power operational mode.

In an optional step <NUM>, the interconnect <NUM> may elect to reconfigure the link <NUM>. The reconfiguration may include changing the arbitration settings for the IP agent <NUM> or reducing the count of possible outstanding transactions to take into account the lower processing capability of the IP agent when operating at the lower power mode.

In step <NUM>, the operating clock frequency of the IP agent <NUM> is reduced if applicable. With the reduced clock frequency, the IP agent consumes less power.

In step <NUM>, the voltage supplied to the IP agent is reduced if applicable. By reducing the voltage, further power savings can be realized.

With the clock frequency and/or the voltage reduced, the IP agent <NUM> remains operational. As a result, it is capable of processing transactions, although possibly at a slower rate when operating at its standard clock frequency and/or supply voltage. In optional embodiments, the interconnect <NUM> can act as a proxy as described above or can be adjusted or reconfigured to take into account and support the lower rate of performance of the IP agent <NUM> in the low power mode. Since these alternatives are optional, they do not necessarily have to be implemented.

In decision step <NUM>, the IP agent <NUM> operates in the low power mode until a decision is made to resume normal operation. In which case, the IP agent <NUM> undergoes a sequence to resume normal operation.

In optional step <NUM>, the voltage is increase to the standard operating voltage if applicable (i.e., if the voltage was previously decreased).

In step <NUM>, the clock frequency is increased if applicable (i.e., provided the clock was previously decreased. In step <NUM>, the IP agent returns to normal operation.

Finally, in optional step <NUM>, the interconnect returns any reconfigured interconnect setting to normal. At this point, the IP agent is ready to resume normal operation, as provided in step <NUM>.

Referring to <FIG>, a flow diagram <NUM> illustrating a sequence for powering down/up an IP agent <NUM> in the Low Power, Inoperable, State Information maintained mode is illustrated.

In step <NUM>, the IP agent <NUM> operates in its normal mode.

In step <NUM>, a decision is made to operate the IP agent <NUM> in low power, inoperable, state information maintained mode.

In step <NUM>, the link <NUM> is placed in the quiescent state and the interconnect <NUM> is configured to operate as a proxy for the IP agent <NUM>. This typically involves (<NUM>) disallowing any new transactions from being generated by the IP agent <NUM>, (<NUM>) waiting for any outstanding transactions to complete and then (<NUM>) acting as a proxy by responding to any transactions targeted for the IP agent <NUM>. For example, the interconnect <NUM> may send an exception message to the source of the non-processed transaction, possibly preventing a hang up situation from occurring because the sender of the transaction never received a response from the IP agent <NUM>.

In step <NUM>, the clock frequency of the IP agent <NUM> is reduced if applicable.

In step <NUM>, the operating voltage of the IP agent <NUM> is reduced if applicable. However, the voltage remains adequate so that memory or storage elements in the IP agent <NUM> maintain their state information.

In decision <NUM>, the IP agent <NUM> remains in the lower power state until a decision has been made to resume normal operation. The system controller <NUM>, an event external to the SoC (e.g., a signal received from a sensor, signal received an external source, etc.), a timer, the IP agent itself or another IP agent, can all trigger the wake-up. When this decision is made, the IP agent undergoes a sequence to resume normal operation.

In steps <NUM> and <NUM>, the voltage and clock frequency provided to the IP agent <NUM> are each increased if applicable. Since the state information has been retained, the IP agent <NUM> resumes normal operation in step <NUM>.

In step <NUM>, link <NUM> exists the quiescent mode and the IP agent becomes transaction ready and the interconnect <NUM> is notified that it longer has to act as a proxy.

Referring to <FIG>, a flow diagram <NUM> illustrating a sequence for the Low Power, Inoperable, Mode is illustrated. In this sequence, steps <NUM>, <NUM> and <NUM> are the same as described above with regard to <FIG>. As such, a discussion of these steps are not repeated herein.

In steps <NUM>, a decision is made to power down the IP agent <NUM>. Thereafter, the interconnect is configured as a proxy (step <NUM>) and the clock for the IP agent <NUM> is turned off completely (if applicable) and/or the voltage is significantly reduced (if applicable) to the point where state information is lost in step <NUM>. Without state information, when a decision is made to resume normal operation per step <NUM>, the voltage is ramped up (if applicable) and clock turned on (if applicable) in step <NUM>. Thereafter, the IP agent <NUM> undergoes a reset operation, as previously described with regard to <FIG>. Once the reset is complete, the IP agent <NUM> becomes transaction ready. The system then waits for the link to exit the quiescent mode in step <NUM>. Once the exit occurs, the IP agent is visible on the interconnect <NUM>. Thereafter, in step <NUM>, the interconnect <NUM> no longer acts as a proxy for the IP agent <NUM>.

Finally, for the Power Off Mode, the sequence is the same as <FIG>, except the power is turned off completely, as opposed to simply reduced. Otherwise the Power Off Mode sequence is the same. In this mode, the IP agent <NUM> consumes virtually no power, is inoperable, and the interconnect <NUM> may act as a proxy on behalf of the IP agent.

Referring to <FIG>, a flow chart <NUM> illustrating the steps for placing a link <NUM> in the quiescent state is illustrated.

In the initial step <NUM>, the system controller <NUM> makes a decision that an IP agent <NUM> should be either reset or placed in one of the inoperable power saving modes.

In step <NUM>, the IP agent <NUM> is instructed to stop generating transactions.

In decision <NUM>, the system determines if all outstanding transactions are complete. For all outstanding Non-posted transactions, a Completion transaction must be received (i.e., with read transactions, the accessed data must be returned, with non-posted write transactions, an acknowledgement must be received). With Posted transactions, no response transaction is required. Posted transactions are therefore considered "complete" once they are sent by the IP agent.

In step <NUM>, the link <NUM> is placed in the quiescent state when all the outstanding transactions are complete. Thereafter, the interconnect <NUM> is configured as a proxy for the IP agent <NUM>.

In step <NUM>, the IP agent is ready to placed in either reset or the desired inoperable low power mode.

<FIG> show flow diagrams of various for IP agent "wake-up" sequences.

Referring to <FIG> a flow diagram <NUM> illustrating an agent-initiated "wake-up" sequence is illustrated. In this embodiment, the wake up sequence is initiated by the IP agent, but implemented through the system controller <NUM>.

In step <NUM>, an IP agent <NUM> in an inoperable state detects a wake-up trigger event. Although an IP agent may be powered down or "off", it may remain at least partially functional in the sense that it maintains the ability to detect when a wake-up trigger occurs. The wake-up trigger may include a number of different types of events. For example, it could be an internal timer that causes the IP agent <NUM> to wake-up after a predetermined period of time, or it can be an event external to the SoC <NUM>, such as another device that wishes to communicate with the IP agent <NUM>. In step <NUM>, the IP agent sends a "wake-up" communication over its link <NUM> to the interconnect <NUM>. Again, although the link is in the quiescent state when its corresponding IP agent <NUM> is in an inoperable state, it is capable of transmitting the wake-up signal to the interconnect <NUM>.

In step <NUM>, the interconnect <NUM> is configured to "listen" for a wake-up signal from an inoperable IP agent. If the signal is detected, the interconnect <NUM> notifies the system controller <NUM>.

In step <NUM>, the system controller <NUM> may send command(s) over the interconnect <NUM> for the IP agent <NUM> to initiate its wake-up sequence.

In step <NUM>, the IP agent initiates its wake-up sequence in response to the command(s).

With the embodiment described above, the IP agent <NUM> asks the system controller to initiate the wake-up sequence. In response to a wake-up command from the system controller, the IP agent initiates its own wake-up sequence. The system controller is therefore aware of the status of the IP agent as it emerges from its inoperable state and becomes visible on the interconnect <NUM>.

<FIG> shows the sequence when the system controller <NUM> initiates a wake-up of an IP agent <NUM>. With this sequence, the system controller <NUM> sends wake up command(s) to the IP agent in step <NUM>, and in response, the IP agent initiates its own wake up sequence in step <NUM>. In a variation of this embodiment (not illustrated), the wake up may be initiated off the SoC <NUM> via the system controller <NUM>. When the system controller <NUM> receives the command(s), the above described process is initiated.

<FIG> shows the sequence when the wake up command for an IP agent <NUM> that originates off the SoC <NUM> and is implemented through the system controller <NUM>. With this sequence, the system controller <NUM> receives the command in step <NUM>. In response, the system controller sends a wake up command to the IP agent in step <NUM>, and in response, the IP agent initiates its own wake up sequence in step <NUM>. With direct wake up from off the SoC <NUM>, the command is provided directly to the IP agent <NUM> via its hard-wire input. In response, the IP agent initiates its own wake up sequence.

Referring to <FIG>, a flow diagram <NUM> illustrating an IP agent initiated and implemented wake up sequence is illustrated. In this embodiment, a wake up condition, such as any of those noted above, occurs in step <NUM>. In response, the IP agent initiates its own wake up sequence in step <NUM>. In step <NUM>, the wake up sequence completes. Thereafter, in step <NUM>, the IP agent notifies the interconnect <NUM> and the system controller <NUM>, either directly or through the interconnect <NUM>, of its awoken status.

In the above examples, sequences for transitioning a single IP agent into one of the above-described low power modes was described for the sake of simplicity. In actual embodiments, multiple IP agents <NUM> on an SoC may be powered down concurrently. If two or more are powered down at or around the same time, each would independently undergo one the above described sequences, depending on the mode.

Claim 1:
A System on a Chip, S oC, comprising:
a plurality of intellectual property, IP, agents provided on the SoC;
an interconnect configured to handle transactional traffic between the plurality of IP agents;
a first IP agent of the plurality of IP agents, the first IP agent arranged to communicate with the interconnect using a link, the link connecting the first IP agent to the interconnect; and
a reset manager configured to initiate a reset of the first IP agent, the reset including a negotiation between the interconnect and the first IP agent, the negotiation conducted over the link and effective to enable the first IP agent to become transaction ready independent of other IP agents among the plurality of IP agents.