Protocol-level control for reset and power management of System-on-Chip (SoC) agents

Abstract

To provide a system for consistently performing reset and power management of IP agents on system-on-chips (SoCs) that eliminates a need for customization and leads to a consistent system software view across a plurality of SoCs.SOLUTION: A system consistently performs reset and power management of IP agents on SoCs, where, when an IP agent undergoes the reset, individual negotiations take place between interconnection and each IP agent via a link. Each IP agent can come out of the reset on its own time schedule, independent of timing of other IP agents. The interconnection is configured on behalf of any IP agent that is inoperable before the reset, in a power down mode, or during malfunction.SELECTED DRAWING: Figure 8

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application is a joint venture of U.S. Provisional Patent Application No. 62 / 650,589, filed March 30, 2018 (PRT IP001P) and U.S. Provisional Application No. 62 / 691,117, filed June 28, 2018. (PRT1P002P). is incorporated herein by reference in its entirety for all purposes.

[0002] This application relates to a system on chip (SoC), and more particularly to a reset on the SoC. and / or implement power management functions consistently, thus enabling a consistent, System and hardware that provides a more uniform system software view of the SoC across the entire It concerns the method. [Background technology]

[0003] A system on a chip ("SoC") is an integrated circuit that contains multiple subsystems. Often referred to as Intellectual Property ("IP") agents. IP agents typically It contains "reusable" blocks of circuitry designed to implement or perform a specific function. Using IP agents reduces the time and cost of developing a complex SoC. This can significantly reduce costs.

[0004] An SoC typically consists of a system controller and an interconnect (a bus or network The system controller is a system software. It is provided to execute the software and manage the overall operation of the SoC. Various IP agents are connected to an interconnect via one or more links and communicate with each other via the interconnect. do.

[0005] SoC developers typically use different IP agents, often from multiple vendors. Each IP agent typically implements its own procedure for resetting. From the perspective of the system controller and interconnect, this is problematic for several reasons. do.

[0006] A typical SoC usually has multiple IP agents connected to an interconnect. After the reset, each IP agent will have its own unique reset procedure. Each IP agent may come out of reset at any time. The difference in timing can cause serious problems. If a transaction is generated to a destination IP agent that is in the middle of (2) the originating IP agent is unable to process the request, and (3) the originating IP agent does not As a result, the entire system may hang, possibly Often a complete system reset is required.

[0007] One well-known approach to prevent hangs is to use a The goal of this circuit is to design and place a circuit between each link of the All IP agents connected to the interconnect come out of reset during the same clock cycle. However, this approach has drawbacks for several reasons. There is. 1. Designing intermediate circuits takes time and effort, and often slows down the development of SoCs. 2. Intermediate circuits are typically developed by different design teams for each SoC. As a result, the intermediate circuits are usually different for each SoC, or even for different sub-circuits on the same SoC. Even between different operating systems. 3. Circuit complexity typically limits the number of IP agents that can be connected to a given interconnect. The practical effect of this limit is that the number of IP The problem is that more interconnect levels are required to achieve the desired results. Thus, the overall complexity of the SoC increases. The thickness increases.

[0008] Sometimes the IP agent does not work properly. For example, the IP agent sends fake traffic. It can inject transactions into the interconnect, fail to respond to received transactions, e.g. In some cases, it may not function properly. Unused IP agents may need to be reset. Current SoC interconnect standards There is no standard IP agent reset mechanism. The entire SoC must be reset. or an intermediate circuit must provide the necessary isolation, reset, and Either the IP reintroduction or the IP reintroduction must be designed to do something like that.

[0009] Power management is also not addressed by any current SoC interconnect standard. The Microcontroller Bus Architecture (AMBA) protocol, for example, Does not address management and provides a way to intentionally power down or turn off the IP agent. To provide this functionality, the power management function typically By developing additional intermediate circuitry on the link to handle management, It needs to be custom designed into oC.

[0010] Many companies offering multiple SoCs are creating similar products to reduce time to market. Some system software is shared between devices. However, similar S Even in oC, software is typically in a situation where the IP agent can be the same. However, it is not easily portable from device to device. Reset and / or power management If there are small differences in any intermediate circuitry used to process The implementation may need to be modified and debugged for the application.

[0011] Therefore, the challenges for companies developing many SoCs are: (1) how to reset each device; Developing customized circuitry for implementing the BIOS and possibly power management; and (2) modifying and debugging the system software for each Device. This effort across multiple devices is costly, complicated and time-consuming. This reduces the ability to quickly get products to market.

[0012] This eliminates the need for customization and ensures consistent system performance across multiple SOCs. Reset and power management of IP agents on the SoC that lead to the system software view A system is needed to consistently implement force management. Summary of the Invention

[0013] Eliminate the need for customization and ensure consistent system software across multiple SOCs Consistent reset and power management of IP agents on the SoC leading to wear view A system for implementing the method is disclosed.

[0014] In one embodiment, the system includes one or more IP agents, an interconnect, and and one or more links between the IP agent and the interconnect. When the host receives a reset, a separate negotiation begins between the interconnect and each IP over the link. In each negotiation, each IP agent: Resets on its own time schedule, independent of other IP agents' timing After coming out of reset, each IP agent can The system is in a "ready-to-connect" state, is introduced into the interconnect, and is ready to communicate with other elements (system The object is visible to the system (such as the system controller).

[0015] In another embodiment, the interconnection acts as a proxy for any IP agent that is inoperative. This feature may be configured as follows: (1) before the transaction is ready, (2) ) malfunction, and / or (3) inoperability during a power down state. Possible system-wide hang if an agent becomes the target of a transaction This is advantageous because it prevents transactions from being forwarded to the inter-connect when the inter-connect acts as a proxy. An exception message is sent to the sender, which indicates that the sender is the target IP agent. This prevents hangs caused by waiting indefinitely for a response from Cut.

[0016] In yet another embodiment, the interconnect is adapted to act as a proxy for the IP agent. This allows you to (1) reset IP agents individually, and (2) ) IP agents can be put into a power saving state. The states are a low-power operational mode, a low-power inoperative mode with or without preserving state information, Or, it may include one of several modes, such as a power off mode.

[0017] Thus, the present invention solves many problems. The present invention is (2) to manage each IP agent to come out of reset during the IP Eliminates the need to build custom circuitry for agent power management. Instead, The implementation advantageously provides a uniform implementation of both of these functions, allowing for consistent system performance across multiple SoCs. This consistent software view provides a system-wide view of the Eliminates many of the custom designs and software modifications across the family, reducing development costs Cost savings, reduced complexity, and faster time to market are achieved. [Brief description of the drawings]

[0018] For further information about this application and its advantages, please refer to the following description taken in conjunction with the accompanying drawings, in which: can be best understood by

[0019] [Figure 1] 1 is a block diagram illustrating a shared interconnect for a system on a chip (SoC) according to a non-exclusive embodiment.

[0020] [Diagram 2] FIG. 13 illustrates an example of a transaction packet according to a non-exclusive embodiment.

[0021] [Figure 3A] 4 is a logic diagram illustrating an arbitration element according to a first non-exclusive embodiment.

[0022] [Figure 3B] 11 is a logic diagram illustrating an arbitration element according to a second non-exclusive embodiment.

[0023] [Figure 4] 11 is a flow chart illustrating the operational steps for arbitrating and transmitting portions of a transaction over a virtual channel of a shared interconnect according to a non-exclusive embodiment.

[0024] [Diagram 5] FIG. 2 illustrates a first example of interleaving transmissions of parts of different transactions over virtual channels of a shared interconnect according to a non-exclusive embodiment.

[0025] [Figure 6] FIG. 13 illustrates a second example of interleaving transmissions of parts of different transactions over virtual channels of a shared interconnect, according to a non-exclusive embodiment.

[0026] [Figure 7] 1 is a block diagram illustrating two shared interconnects for handling traffic in two directions in accordance with another non-exclusive embodiment of the present invention.

[0027] [Figure 8] 1 is a block diagram illustrating a SoC having reset, power management, and hibernation capabilities in accordance with a non-exclusive embodiment of the present invention.

[0028] [Figure 9] 4 is a flow chart illustrating a reset sequence of an IP agent according to a non-exclusive embodiment of the present invention.

[0029] [Figure 10] 4 is a flow chart illustrating a reset sequence for a malfunctioning IP agent in accordance with a non-exclusive embodiment of the present invention.

[0030] [Figure 11]4 is a flow chart illustrating a power down / up sequence for an IP agent in accordance with a non-exclusive embodiment of the present invention.

[0031] [Figure 12] 4 is a flow chart illustrating a power down / up sequence for an IP agent in accordance with a non-exclusive embodiment of the present invention.

[0032] [Figure 13] 11 is a flow chart illustrating a power down / up sequence for an IP agent in accordance with yet another non-exclusive embodiment of the present invention.

[0033] [Figure 14] 11 is a flow chart showing the steps for putting a link into a dormant state.

[0034] [Figure 15A] 4 is a flow chart illustrating a "wake-up" sequence for an IP agent. [Figure 15B] 4 is a flow chart illustrating a "wake-up" sequence for an IP agent. [Figure 15C] 4 is a flow chart illustrating a "wake-up" sequence for an IP agent. [Figure 15D] 4 is a flow chart illustrating a "wake-up" sequence for an IP agent.

[0035] In the drawings, like numbers may be used to designate like structural elements. . DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0036] The present application will now be described with reference to some non-exclusive embodiments thereof, which are illustrated in the accompanying drawings. In the following description, numerous specific examples are used to facilitate a thorough understanding of the present disclosure. However, as will be apparent to one skilled in the art, the present disclosure However, the present invention may be practiced without some or all of these specific details. In addition, references may be made to well-known process steps and / or structures in order to avoid unnecessarily obscuring the present disclosure. A detailed description of this will be omitted.

[0037] Many of the integrated circuits currently under development are extremely complex. As a result, many chip designers Using a system-on-chip, or "SoC," approach, It has interconnected multiple subsystems or IP agents. Consumer devices (e.g. , handhelds, mobile phones, tablet computers, laptops and desktops computers, media processing, etc.), virtual or augmented reality (e.g. robotics, autonomous Vehicles, aircraft, etc.), medical equipment (e.g. imaging, etc.), industrial, home automation applications, industry (e.g. smart appliances, home monitoring equipment, etc.) and data centers Applications (e.g. network switches, attached storage devices, etc.) SoCs for applications are currently available or being developed.

[0038] The present application relates to an arbitration system for arbitrating access to a shared resource. Such shared resources may be, for example, bus-to-bus Connections, memory resources, processing resources, or other resources shared among multiple competing parties For ease of explanation, the shared resources detailed below are Interoperability shared by multiple subsystems on a system-on-chip, or "SoC." Let it be a connection.

[0039] In SoC, traffic is exchanged between devices in the form of transactions, as will be described later. There are multiple subsystems that are connected to the same network and the shared resource is the physical interconnect. A transaction or part of a transaction may traverse multiple virtual channels associated with a shared interconnect. and may use one of several different arbitration schemes and / or priorities. ,Access to a shared interconnect for transmitting transactions between subfunctions. may be used to arbitrate.

[0040] Transaction Class The shared interconnects used in SoC include Posted (P), Non-pos There are at least three types, including ted(NP) and Completion(C). There are several classes of transactions, each of which is briefly defined in Table 1 below. [Table 1]

[0041] Posted transactions (such as writes) do not require a reply transaction. A transaction ends when the sender writes the data to the specified destination. -Posted transactions (such as either reads or writes) However, the response is sent as a separate Completion transaction. In other words, for a read, the first transaction branches to the A separate but related Completion transaction is used to read For non-posted posts, the first transaction is The transaction is used for writing, while when the write is completed, the second associated The completion transaction is asked for confirmation.

[0042] A transaction, regardless of type, can be represented by one or more packets. In some circumstances, a transaction may be represented by a single packet. In some situations, multiple packets may be required to represent an entire transaction. .

[0043] 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, then 128 bits are allocated to each bit. The signal can be delivered on either the first or second clock cycle.

[0044] In some situations, a transaction is split into multiple parts for transmission. A single packet with a payload that is 512 bits (64 bytes) Consider a transaction with a shared interconnect that is only 128 bits wide (16 bytes). If so, the transaction is split into 4 parts (e.g., 4 x 128 = 512). A transaction is a sequence of four clock cycles or beats that must be transmitted. If the transaction is only a single packet that is less than 128 bits wide, the entire transaction The same transaction can be sent in one clock cycle or beat. If the packet happens to contain a do.

[0045] Thus, the term "portion" of a transaction refers to a given clock cycle or is the amount of data that can be transferred over the shared interconnect during a beat. The size of the portion is the This can vary depending on the physical width of the interconnect. For example, if a shared interconnect is physically If the width of the 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 portion. If the buffer size is larger, the packet must be sent over the shared interconnect in multiple parts. Transactions with 128, 256, or 512-bit payloads The two versions require 2, 4, and 8 parts, respectively. Thus, the term "part" The term refers to the number of bits transmitted over the shared interconnect during any given clock cycle or beat. should be interpreted broadly to mean either part or the whole of a transaction that may do.

[0046] stream A stream is defined as a pairing of a virtual channel and a transaction class. For example, if there are four virtual channels, say VC0, VC1, VC2, and VC3, ), and three transaction classes (P, NP, C), a maximum of 1 There are two different possible streams. A variety of virtual channels and transaction classes Possible combinations are detailed in Table 2 below. [Table 2]

[0047] The number of transaction classes listed above is merely illustrative and should not be construed as limiting. Conversely, any number of virtual channels and / or transactions may be A class may be used.

[0048] Arbitration on Virtual Channels of a Shared Interconnect Referring to FIG. 1, a block diagram of an arbitration system 10 is shown. In an exclusive embodiment, the arbitration system is Send the transaction to section 14 (i.e., IP4, IP5, and IP6) A number of subfunctions 14 (i.e., IP1, IP2, and I P3) for access to the shared interconnect 12.

[0049] Shared interconnect 12 is a physical interconnect that is N data bits wide and contains M control bits. Also, the shared interconnect 12 is unidirectional, which means that the source (i.e., 1, IP2, and IP3) to the destination (i.e., IP4, IP5, and IP6) This means that the router only handles traffic in the direction to the

[0050] In various alternative embodiments, the number of N data bits may be any integer, but is typically are powers of 2 (e.g., 21, 22, 23, 24, 25, 26, 27, 28, 29, etc.) or (2, 4, 6, 8, 16, 32, 64, 128, 2 In most practical applications, N-bit numbers can be 32, 64, 128, 256, or 512. However, these widths are merely examples and may vary depending on how It should be understood that the above should not be construed as limiting.

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

[0052] One or more logical channels (not shown) (hereafter referred to as "virtual channels" or "VCs" ) are associated with the shared interconnect 12. Each virtual channel is independent. A 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 shared. The optical fiber 10 may be associated with a wired interconnect 12 .

[0053] 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 of its Other virtual channels may be assigned lower priority. High priority channels are: A virtual channel with a higher priority is given access to the shared interconnect 12 than a virtual channel with a lower priority. In another embodiment, each of the virtual channels is given equal priority. In that case, the access rights to the shared interconnect 12 may be granted or arbitrated. When sending a virtual channel, it does not prioritize one virtual channel over another. In an embodiment, the priority assigned to one or more of the virtual channels may be dynamically changed. For example, in a first set of circumstances, all virtual channels may be assigned the same priority. In a second set of circumstances, a particular virtual channel may be assigned to another virtual A higher priority may be assigned to the channel, so that as conditions change Therefore, the priority scheme used among virtual channels is determined to best suit the current operating conditions. The following changes can be made:

[0054] Each of the subsystems 14 is typically a block of "reusable" circuitry or logic. These are generally called IP cores or agents. Most IP agents An agent is designed to perform a specific function, for example, an Ethernet port, a display For peripheral devices such as RAID drivers, SDRAM interfaces, and USB ports Such IP agents are typically integrated circuits (ASICs) that Integrated circuits (ICs) or field programmable gate arrays (FPGAs) ) provides the necessary subsystem functions within the overall design of the complex system provided above. The IP Agents available are used as "building blocks". Libraries allow chip designers to easily design more complex integrated circuits. This reduces design time by allowing various logic functions to be easily "bolted" together. Both can reduce development costs. The subsystem agent 14 is a dedicated IP Although the above is described with respect to subsystems, it should be understood that this is not a requirement. System 14 is a collection of IP functions connected to or sharing a single port 20. Thus, the term "agent" means that the subsystem is a single Any device connected to port 20, whether performing one or more functions, This should be interpreted broadly as a subsystem of the type.

[0055] A pair of switches 16 and 18 each connect to the subsystem via a dedicated access port 20. 1 provides access between each of the system agents 14 and the shared interconnect 12. In an exemplary embodiment, (1) Subsystem agents IP1, IP2, and IP3 are The switch 16 is connected via ports Port0, Port1, and Port2. (2) Subsystem agents IP4, IP5, and IP6 are Por Connect to switch 18 via t3, Port 4, and Port 5. (3) In addition, the access port 22 is connected to the switch 16 as a whole via the interconnect 12. Provides access to subsystem agents IP4, IP5, and IP6.

[0056] Switches 16 and 18 perform multiplexing and demultiplexing functions. Switch 16 Generated by subsystem agents IP1, IP2, and / or IP3 Select the upstream traffic and downlink the traffic through the shared interconnect 12. In the switch 18, a demultiplexing operation is performed and the traffic is , the target subsystem agent (i.e., IP4, IP5, or IP6) (or)

[0057] Each access port 20 has a unique port identifier (ID) and is provides dedicated access for agent 14 to either switch 16 or 18. For example, ,Subsystem agents IP1, IP2, and IP3 are,respectively,access points. Similarly, the subsystems Port0, Port1, and Port2 are assigned to the The system agents IP4, IP5, and IP6 are connected to the access ports Por Assigned to t3, Port4, and Port5.

[0058] In addition to providing ingress and egress points to / from switches 16, 18 Therefore, the unique port ID 20 addresses the traffic between the subsystem agents 14. Each port 20 stores a certain amount of memory in the system memory 24. It has an allocated addressable space.

[0059] In some non-exclusive embodiments, all or a portion of the access port 20 includes a A "global" port identifier may be assigned, not just a specific port ID. Transactions and other traffic are routed through the account assigned to the global port identifier. It can be sent to all or part of the access port. Therefore, a global identifier is used. For example, transactions and other traffic may be distributed across all or part of Access Port 20. It can be publicly announced or broadcast to a portion of the world and each access can be authenticated using a unique identifier. Eliminates the need for separate addressing of port 20.

[0060] The switch 16 further includes an arbitration element 26, an address resolution logic (AR L) 28 and an address resolution lookup table (LUT) 30.

[0061] During operation, the subsystem agents IP1, IP2, and IP3 As each transaction is generated, it is The packetized transactions are then forwarded to the corresponding port 20. For example, IP1, IP2, and IP3 are input to the local switch 16 via The parts of the transaction generated by Port0, Port1, and and provided to the switch 16 via Port2.

[0062] Each of the ports 20 is connected to each of the virtual channels associated with the interconnect channel 12. For this purpose, a plurality of first-in, first-out buffers (not shown) are provided. , there are four virtual channels, one for each virtual channel, Port 20 has four buffers. Again, the virtual channels and buffers contained in port 20 are It should be understood that the number of virtual channels may vary and is not limited to four. The number of channels and buffers may be more or less than four.

[0063] If a given transaction is expressed in two (or more) parts, the parts For example, if interconnect 12 is 128 data bits wide, If a transaction is represented by a packet containing a 512-bit payload, The transaction must be divided into four parts, each transmitted in four clock cycles or beats. On the other hand, if a transaction is sent by a single packet with a 64-bit payload, If the data can be represented as a single portion, then a single portion can be transmitted in one clock cycle or beat. By keeping all parts of a given transaction in the same buffer, In other words, the kernels associated with a given transaction remain logically independent. All traffic is always sent on the same virtual channel as the stream, and multiple virtual channels It is not split across channels.

[0064] The arbitration element 26 arbitrates between transactions maintained by the various access ports 20. Responsible for arbitrating between competing buffered portions of a transaction. In a practical embodiment, if multiple competing transactions are available, arbitration is performed. Arbitration element 26 performs arbitration every clock cycle. The arbitration winner is granted access to interconnect 12 and transmits the The part of the transaction that is transmitted through the subsystems IP1, IP2, and IP Generated from one of 3.

[0065] When generating a transaction, the sending subsystems IP1, IP2, and IP3 Typically, the possible destination subsystem agents IP4, IP5, and IP6 It knows the address in the address space, but does not know how to route the transaction to the destination. The user does not know the information required to perform this operation (e.g., port IDs 20 and / or 22). In this embodiment, a local address resolution logic (ARL) 28 resolves known destination addresses to This is used to resolve the necessary routing information. Client 14 simply knows that it wants to access a given address in system memory 24. Therefore, ARL28 is tasked with accessing LUT30 and Address rules for ports 20 / 22 along the delivery path to the final destination corresponding to the specified address Once ports 20 / 22 are known, this information is used to The destination address is inserted into the destination field of the packet. As a result, the packet In principle, the requested delivery information is already known and delivered to ports 20 / 22. and is included in the destination field of the packet so that it can be There is no need for the node to perform any further lookups. Another type of transaction, called SBR, uses the source P age. The agent knows the destination port address. As a result, the lookup performed by the ARL 28 A backup typically does not need to be performed.

[0066] In an alternative embodiment, all nodes in the interconnect include an ARL 28 and a LUT 30. For nodes that do not have these elements, the necessary routines are Transactions without logging information can be forwarded to the default node. In this case, the ARL 28 and the LUT 30 are accessed, and then the necessary routing information is , can be inserted into the header of the transaction packet. The default node is typically is upstream from a node that does not have an ARL28 and a LUT30. However, this is by no means required. The default node or nodes may be located anywhere on the SoC. By removing ARL28 and LUT30 from some nodes, This reduces the complexity of the node.

[0067] In addition to decoding the destination for the winning portion of the transaction, ARL28 also It defines the order for the winning part of a transaction in a virtual channel, so After each arbitration is resolved, the ARL28 Transactions, whether or not they are used to perform a sport lookup The winning portion of the winnings is then inserted into a first-in-first-out queue that is provided to each virtual channel. The winning portion of the transaction awaits its turn in a buffer for transmission over interconnect 12 .

[0068] ARL28 also provides "upstream" and "downstream" traffic In other words, the IP address associated with the switch 16 Any IP addresses generated by agent 14 (i.e., IP1, IP2, and IP3) The transaction is considered to be upstream to ARL28. ARL All transactions after 28 (i.e., those transmitted to IP4, IP5, and IP6) This transaction is considered downstream traffic.

[0069] IP agents 14 (i.e., IP1, IP2) associated with the switch 16 , and IP3) communicate with each other to carry out transactions, either directly or indirectly. Direct communication (often called source-based routing (SB R) allows IP agents 14 to transact with each other in a peer-to-peer model. In this model, a source IP agent can send transactions to its peer IP agents. The unique port ID of agent 14 is known and used by ARL2 to access LUT30. 8. Alternatively, the IP agent associated with the switch 16 may be Transactions between the two entities may be routed using the ARL28. In Dell, as described above, the source IP agent is the destination IP agent 14 The ARL 28 then knows only the address of the It is used to access the LUT30 and find the corresponding port ID, and then The destination ID is inserted into the destination field of the transaction packet.

[0070] Packet Format The IP agent 14 generates transactions and associates them with the interconnect 12. Each transaction typically consists of one or more 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 payloads may vary in size from large to small, and may have no payload at all.

[0071] Referring to Figure 2, an example packet 32 ​​is shown. The packet 32 ​​includes a header 34 and and a payload 36. In this particular embodiment, the header 34 is 16 bytes This size is an example only; larger sizes (e.g., more bytes) packets of smaller size (e.g., fewer bytes) may be used. It should be understood that the headers 34 of a packet 32 ​​are not all the same size. It should also be understood that it is not necessary to The size of may be variable.

[0072] The header 34 contains a destination identifier (DST_ID), a source identifier (SRC_ID), and a payload. field size indicator (PLD_SZ), reserved field (RSVD), command field field (CMD), TAG field, status (STS), transaction ID field field (TAG), address i.e. ADDR field, USDR / CompactPay Load field, Transaction Class i.e. TC field, Format FM Multiple fields, such as the T field and the byte enable (BE) field, are The various fields of the header 34 are briefly described in Table 3 below. [Table 3]

[0073] The payload 36 contains the contents of the packet. The size of the payload varies. In some instances, the payload may be large. In yet another example, the load may be small. If it is “compact”, it can be carried in the USRD field of the header 34.

[0074] Transaction types are often used to describe transactions. Indicates whether the above packet has a payload. For example, Posted or Non- For both posted and read, the packet is sent to the location address being accessed. However, it does not have a payload. The etion transaction packet contains a payload that contains the read content. For both posted and non-posted write transactions, the packet The non-posted version contains a payload that contains the data to be written to the destination. In a write transaction, the Completion transaction packet is normally However, in some circumstances, the Completion transaction The option defines the payload.

[0075] The example packet and the above description illustrate many of the basic fields that may be included in a packet. It is to be understood that additional fields may be removed or added. For example, private messages can be shared between sender and recipient. A signaling field may be used.

[0076] arbitration Referring to Figure 3A, the Peripheral Component Interconnect (PCI) Prioritization 1 shows the arbitration logic executed by arbitration element 26. A logic diagram is shown.

[0077] In PCI ranking, each port 20 is prioritized for each virtual channel and transaction class. Separate buffers for combinations of (P, NP, and C). For example, If there are virtual channels (VC0, VC01, VC2, and VC3), Port0 , Port1, and Port2 each have 12 first-in, first-out buffers. Then, for each port 20, the buffer is divided into 10 for each transaction class (P, NP, and and C) and the combination of virtual channels (VC0, VC1, VC2, and VC30). Provided for matching.

[0078] Each IP agent 14 (e.g., IP1, IP2, and IP3) When you generate an application, each resulting packet is forwarded to the corresponding port (e.g. ,In ,port 0, ,port 1, ,and ,port 2), ,based ,on ,transaction ,type, It is placed in the appropriate buffer. For example, Posted(P) generated by IP1, Non-posted (NP) and Completion (C) transactions are Posted and No for the assigned virtual channel in port 0, respectively. n-posted and placed in the Completion buffer. IP2 and Transactions generated by IP3 are sent in a similar manner within ports 1 and 2. , Posted, Non-posted, and , are similarly placed in the Completion buffer.

[0079] If a given transaction is represented by multiple packets, All packets of a transaction are inserted into the same buffer. All packets end up being transmitted on the same virtual channel. The channels remain independent, which means that multiple packets related to the same transaction This means that different virtual channels are not used for the transmission of

[0080] Within each port 20, packets can be assigned to a given virtual channel in many different ways. For example, the allocation may be random. Alternatively, the allocation may be It may be based on the workload and amount of outstanding traffic for a channel. If the 1000 channel is very busy and the other channels are not busy, port 20 will Often, they attempt to balance the load and newly generated transaction traffic. to the least utilized virtual channel. As a result, routing efficiency is improved. In yet another alternative, transaction traffic may be classified according to urgency, security, , or a combination of both, may be assigned to a particular virtual channel. Certain virtual channels may be given higher priority and / or security than other virtual channels. Given the security, high priority and / or safety traffic will receive higher priority. In yet another embodiment, the port 20 is This means that the port 20 has only one virtual channel and the port All traffic generated by port 20 is transmitted through that one virtual channel. In yet another embodiment, the allocation is to the destination port 20. It may be based on the route chosen to be taken.

[0081] In yet another embodiment, the allocation of the virtual channel is performed by the source IP agent 1 4, either alone or in conjunction with its corresponding port 20. For example, the source IP agent 14 generates a control signal to the corresponding port 20. ,requesting that packets of a given transaction be assigned to a particular virtual channel. The IP agent 14 can also use random, hard-coded or balanced utilization, security, and usage across all virtual channels. Allocation decisions can be made based on availability, urgency, etc.

[0082] In selecting the arbitration winner, the arbitration element 26 The arbitration process is carried out in a number of steps. Including below. (1) selecting a port; (2) selecting a virtual channel; and (3) Selecting a transaction class.

[0083] The above order (1), (2), and (3) is not fixed. On the contrary, the above three steps The steps may be completed in any order. Regardless of which order is used, a single arbitration A transaction winner is then selected each cycle. The received signal is transmitted over a corresponding virtual channel associated with sequence 12.

[0084] Each arbitration (1), (2) performed by the arbitration element 26 For (3), multiple arbitration schemes or rule sets may be used. Such arbitration schemes may include strict or absolute priority, four hypothetical Weighted virtual channels, each of which is assigned a certain percentage of transaction traffic. Priority, or the routing by which transactions are assigned to virtual channels in a given order. In further embodiments, other priority schemes may be used. Alternatively, the arbitration element 26 may use different arbitration may dynamically switch between schemes from time to time, and / or (1), (2), and (3) the same or different arbitrations for each of the arbitrations. It should be understood that each of the schemes may be used.

[0085] In an optional embodiment, the unaccounted for during a given arbitration cycle The availability of the destination port 20 defined by the transaction of the transaction is taken into account. The buffer in destination port 20 is available to process a given transaction. If a resource does not exist, the corresponding virtual channel is not available. Transactions do not compete for arbitration, but rather wait until the target resource is available. Meanwhile, if the target resource is available, the request waits until the next arbitration cycle. If so, the corresponding transaction is arbitrated and access to the interconnect 12 is granted. Competing for Seth.

[0086] The availability of the destination port 20 is determined by the multiple arbitration steps (1), (2) and (3) described above. ), and (3) may be checked at different times. For example, availability checks The check is performed before the arbitration cycle (i.e., steps (1), (2), and (before the completion of either (3) or (4). As a result, Only transactions that specify this will be considered during subsequent arbitration, or The arbitration check is performed regardless of the order in which the arbitration steps are performed. During any of the three arbitration steps (1), (2), and (3), This may also be the case.

[0087] Perform destination resource availability checks early or late during the arbitration process. There are advantages and disadvantages to running the check early. Potentially conflicting parts of a session are hidden from conflicts if their destination is unavailable. However, early availability has a significant impact on system resources. As a result, depending on the situation, It may be more practical to perform availability checks later during the vitiation cycle. It's possible.

[0088] Multiple rules for the arbitration process, including the selection of transaction classes to arbitrate between the competing parts of N, NP, and C transactions. These rules include: For Posted (P) transactions, - A Posted transaction part follows another Posted transaction part. Can't get past it. -Posted transaction parts are non-posted to avoid deadlocks. It must be possible to overtake the ed transaction portion. -Posted transaction parts are both strongly ordered models. If you are in the conversion mode, you must be able to overtake Completion. In other words, in strong mode, transactions must be executed strictly according to the rules. And the rules cannot be relaxed. -Posted requests are processed when any part of a transaction is in its relaxed order. If it has the Order (RO) bit set, it will overtake Completion. In the relaxed order, the rules are generally followed, but overtaking is not mandatory. , exceptions may be allowed. For Non-posted (NP) transactions, -Non-posted transaction parts are the same as posted transaction parts. Do not overtake. -Non-posted transaction part is another non-posted transaction The vehicle must not overtake the tion section. -Non-posted transaction parts are in strongly ordered mode if both are Don't overtake Completion. -Non-posted transaction parts are those parts of any transaction that If it has the RO bit set, it is allowed to overtake Completion, but , not required. For Completion(C) transactions, -Completion is the same as the Posted transaction if both are in strongly ordered mode. Do not overtake the cut-off section. -Completion occurs when any transaction part has its RO bit set. If you do, it is permitted to overtake the Posted transaction portion, but is not required. isn't it. -Completion is Non-posted if both are in strongly ordered mode. Do not overtake the transaction portion. -Completion occurs when any transaction part has its RO bit set. If so, they are allowed to overtake the non-posted transaction portion. However, this is not required. -A Completion is not allowed to overtake another Completion.

[0089] Table 4 below provides an overview of the PCI ordering rules. Options (a) and (b) In boxes without , strict ordering rules do not need to be followed. In the table boxes with options, the options depend on whether the RO bit is reset or set. Either the strict order (a) rule or the relaxed order (b) rule is applied to each of them. In various alternative embodiments, the RO bit may be set globally or in a packet. The levels can be individually set or reset. [Table 4]

[0090] The arbitration element 26, in no particular order, selects the competing ports 20, the virtual By performing arbitration for channels and transaction classes, The winning portion per cycle is shared among all the The data is then accessed through interconnect 12 and transmitted over a corresponding virtual channel.

[0091] Referring to FIG. 3B, the device ranking performed by arbitration element 26 A logic diagram showing the arbitration logic used in the arbitration process is shown in FIG. , and possibly consideration of available destination resources, the two differences are the same as those mentioned above. It is basically the same as:

[0092] First, device ordering does not require (a) a response to every request; -posted A read or write transaction and (b) a requested response. There are two transaction classes, including the Completion transaction you specified. Only two transaction classes are defined. There are only two buffers per channel. For example, there are four virtual channels (VC0, VC 1, VC2, and VC3), each port 20 (for example, Port0, Port Ports t1 and t2) have a total of eight buffers.

[0093] Second, the rules for selecting transactions for device ordering are also different from those for PCI ordering. Device ordering differs from over-class ordering in that it selects one class over the other. There are no strict rules that apply. On the contrary, any transaction class can However, in general practice, the Completion It is recommended to release resources that will not be available until the transaction is resolved. Requests a Completion transaction that meets the requirements.

[0094] Otherwise, the arbitration process for device ordering is essentially the same as above. In other words, for each arbitration cycle, To select a transaction winner, arbitration steps (1), (2), and (3) is executed in any particular order. Transaction class arbitration is When implemented, device ordering is used rather than PCI ordering rules. The availability of resources and / or virtual channels is determined by an arbitration step (1); (2) and (3) may be considered before or during either of them.

[0095] Operational Flowchart As mentioned earlier, the arbitration scheme described above ensures that access to any shared resource is The above-mentioned devices may be used to share a common access and are not limited to use with a shared interconnect. Other shared resources include the ARL28, processing resources, and memory resources (such as LUT30). , or almost any other piece of information shared among multiple parties competing for access. It may include other types of resources.

[0096] Referring to FIG. 4, the operational steps for arbitrating access to a shared resource are shown. A flow chart 40 is shown.

[0097] In step 42, various source subsystem agents 14 Transactions are classified as Posted (P) and Non-posted (NP). , and Completion(C).

[0098] In step 44, the transaction generated by the source subsystem agent 14 is Each transaction is packetized. As mentioned above, the packets for a given transaction are Packetization may result in one or more packets. The packets may vary in size. Some packets may have large payloads and other packets may have small payloads. A transaction has a data payload that is smaller than the width of the interconnect 12. In the situation where a transaction is represented by a single packet having a code 36, the transaction is a single The transaction is larger than the access width of the shared resource. The state represented by multiple packets or a single packet with a data payload 36 In some situations, multiple parts are needed to represent a transaction.

[0099] In step 46, the packets generated by each of the subsystem agents 14 are The part of the transaction that is generated is injected into the local switch 16 via the corresponding port 20. Within port 20, packets of each transaction are assigned to a virtual channel. As mentioned above, the assignment can be random, hard-coded, or Balanced usage, security, urgency, etc. across all virtual channels It is okay to follow.

[0100] In step 48, the packets generated by each of the subsystem agents 14 are The parts of the transaction are processed by both transaction classes and The virtual channels assigned to them (e.g., VC0, VC1, VC2, and VC 3) stores the data in the appropriate first-in-first-out buffer. The channels can be strict or absolute priority, round robin, weighted priority, or least recently served. (least recently serviced), and many other priority schemes. If a given transaction has multiple parts, In this case, each part is stored in the same buffer. As a result, multiple The parts of the number are transmitted on the same virtual channel associated with the interconnect 12. When a transaction is posted, a buffer is created to track the number of content items in each buffer. The corresponding counter is decremented. When a particular buffer is filled, its counter The data is decremented to zero, which means the buffer can no longer accept further content. This means that you cannot

[0101] At steps 50, 52, and 54, first, second, and third level arbitration As mentioned above, port 20, virtual channel, and transaction The selection of action classes may be performed in any order.

[0102] Element 56 is used to perform the first, second and third levels of arbitration. In each case, element 56 may be used to maintain the rules governing arbitration. For example, element 56 is used as needed to resolve each of the partition levels. CI and / or device ordering rules may be maintained. Element 56 may include some priorities. Priority scheme (strict or absolute priority, weighted priority, round robin, etc.) The rules for determining which one to use in a given arbitration cycle are and

[0103] In step 58, the winner of the arbitration is determined. In step 60, the winner The portion is placed in a buffer used to access the shared resource, and the buffer The counter associated with is decremented.

[0104] In step 62, the buffer associated with the winning portion is cleared to indicate that the winning portion is no longer in the buffer. Since it does not exist, it is incremented.

[0105] In step 64, the winning portion gains access to the shared resource. , the buffer for the shared resource is incremented.

[0106] Steps 42-64 are each repeated continuously during successive clock cycles. As a different winning part, each gets access to the shared resource.

[0107] Interleaving – Example 1 Transactions may be transmitted over the interconnect 12 in one of several modes. do.

[0108] One mode is called "header in-line" mode. In this mode, the header 34 of a transaction packet 32 ​​always consists of separate parts. Header inline mode is transmitted first before the payload 36 in the first 32-bit or 16-bit beat. Relative to the number of data bits N of the interconnect 12, the header 34 and / or the payload 36 Depending on the size, it may or may not waste available bits in the interconnect 12 . For example, if an interconnect 12 is 512 bits wide (N=512) and has a 128-bit header and and a packet with a 256-bit payload. In this scenario, An 8-bit header is transmitted in the first part or beat, and the remaining 384 bits of interconnect 12 The bandwidth of the first part is not utilized. The second part or beat carries a 256-bit payload36 is transmitted and the remaining 256 bits of interconnect 12 are unused. A significant percentage of the bandwidth of a transaction is unused during two beats. If most of the packets are the size of the interconnect or larger, the amount of wasted bandwidth is reduced. For example, a header of 384 or 512 bits and / or the amount of waste in the payload is significantly reduced (e.g., 384 bits) or or completely eliminated (e.g., 512 bits).

[0109] It is called "header on side-band". In another mode, the packet header 34 is transmitted "on the side" of the data, which While load 36 is transmitted on interconnect 12 with N data bits, control bits M are utilized. In the header-on-sideband mode, the payload 36 of the packet 32 ​​is The number of bits or size of a packet is the number of beats required to transmit a packet on a given interconnect 12. For example, 64, 128, 256, or 512-bit payloads. , and an interconnect having 128 data bits (N=128). For 12, the packets require 1, 1, 2, and 4 beats, respectively. For each transmission of a packet, the header information is separated from the payload data by N data bits on interconnect 12. The control bit M is transmitted together with or "on the side" of the data.

[0110] In yet another mode, the header 34 of the packet 32 ​​is transmitted in the same manner as the payload. However, the header 34 and payload 36 must be transmitted in separate parts or beats. There is no requirement that a packet 32 ​​must consist of a 128-bit header 34 and a 128-bit If the payload is 36 bits, the total size is 256 bits (128 + 128). The N data bits of the interconnect 12 are available in 64, 128, 256 and 512 bit widths. Then, a 256-bit packet is transmitted in 4, 2, 1, and 1 beats, respectively. In another example, a packet 32 ​​is sent with a 128-bit header and a 256-bit The payload of 36, i.e., the total packet size is 384 bits (128 + 256). The same interconnect 12 of N data bits of width 64, 128, 256 or 512 In this mode, a packet is transmitted in 6, 3, 2, or 1 beat, respectively. is always at least as efficient as the header-inline mode described above.

[0111] Referring to Figure 5, the interfacing of different transaction parts over multiple virtual channels The first example of a leaving transaction is shown in Figure 1. For simplicity, the example shows two transactions. Only one transaction is shown. The two transactions, in this example, are 128 data bits long. The two processors compete for access to the shared interconnect 12, which is 128 Mbps wide. Transaction details include: (1) Transaction 1 (T1): Generated at time T1 and assigned to virtual channel VC2. The size of T1 is 4 beats, which are T1A, T1B, It is designated as T1C and T1D. (2) Transaction 2 (T2): Generated at time T2 (after time T1) and The size of T2 is a single part or beat.

[0112] In this example, the VCO is assigned absolute or strict priority. Throughout, the parts of two transactions T1 and T2 are as shown in Figure 5 according to the following: As such, they are transmitted over a shared interconnect. Cycle 1: Beat T1A of T1 is the only available transaction, so V Transmitted via C2. Cycle 2: T1 beats T1B and a single part of T2 gains access to interconnect 12. Since VCOs have strict priority, T2 automatically wins. Therefore, the beat of T2 is transmitted in VC0. Cycle 3: There are no competing transactions, so T1's beat T1B transmits on VC2. will be done. Cycle 4: There are no competing transactions, so T1's beat T1C transmits on VC2. will be done. Cycle 5: There are no competing transactions, so T1's beat T1D transmits on VC2. will be done.

[0113] This example shows that: (1) a virtual channel with absolute priority cannot handle traffic beyond the Whenever traffic becomes available, it is shared, regardless of whether or not traffic was previously queued. (2) the right to access the interconnection 12 is given immediately; and The winning portion or beat of a game is awarded to different virtual channels associated with the interconnected 12 In this example, the virtual channel VCO is In an absolute or strict priority scheme, any of the virtual channels It should be understood that either one may be assigned the highest priority.

[0114] Interleaving - Example 2 Referring to Figure 6, the interfacing of different transaction parts over multiple virtual channels A second example of leaving is shown.

[0115] In this example, the priority scheme for access to interconnect 12 is weighted. This means that VCO has a probability of (40%) being given access, and VC1 to VC3 have a probability of (10%) being given access. This means that there is a 20% chance that access will be granted. It is 8 bits wide.

[0116] Furthermore, in this example, there are four conflicting transactions T1, T2, T3, and and T4. - T1 is assigned to VC0 and has four parts or beats T1A, T1B, T1C, and 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 contains two parts or beats T4A and T4B.

[0117] In this example, the priority scheme is weighted. As a result, each virtual channel receives In other words, during the 10 cycles, VC0 won 4 times. ,VC1, VC2, and VC3 each win twice. For example, as shown in Fig. 6, - The four parts or beats of T1, T1A, T1B, T1C, and T1D, are divided into 10 segments. Four of the cycles (40%) (i.e., cycles 1, 4, 7, and 10) It is transmitted through a VCO. -Two parts of T2 or beats T2A and T2B are included in 2 cycles out of 10 cycles The data is transmitted over VC1 in cycles (20%) (i.e., cycles 2 and 6). -Two parts of T3 or beats T3A and T3B are taken for 2 cycles out of 10 cycles The data is transmitted over VC2 in cycles (20%) (i.e., cycles 5 and 9). -Two parts of T4 or beats T4A and T4B are taken 2 cycles out of 10 cycles The data is transmitted over VC3 in only two cycles (20%) (i.e., cycle 3 and cycle 8).

[0118] Thus, this example shows that: (1) each virtual channel is assigned a (2) a weighted priority scheme for granting access to the interconnection 12; and The winning portion of the transaction is a different virtual channel associated with the interconnect 12. Another example of interleaved transmission in

[0119] In this weighting example, transactions are directed to various virtual channels according to their weighting ratios. It should be understood that there is enough traffic to allocate a portion of If the amount of traffic is insufficient, the weighting ratios may not be strictly enforced. In some cases this is not possible. For example, if there is heavy traffic on virtual channel VC3, Is there limited traffic on the other virtual channels VC0, VC1, and VC2? In the absence of any, VC3 can handle all or part of the traffic if the weighting ratio is strictly enforced. However, as a result, every clock cycle Because not all data transfers can transmit parts of a transaction in a single beat, the interconnect 12 On the other hand, if the weighting ratio is not strictly enforced, the utilization rate of the interconnection It is possible to reallocate transaction traffic to increase For example, traffic is transmitted over a greater number of cycles or beats.

[0120] The above two examples are applicable regardless of which of the above mentioned transmission modes is used. Once a transaction is divided into parts or beats, they are Interleaved on the shared interconnect 12 using one of the arbitration schemes can be transmitted.

[0121] The arbitration schemes described above are just a few examples. Others include low jitter arbitration schemes. arbitration, weighted, strict, round-robin, or just about any other arbitration Thus, the arbitration schemes listed or described herein may be used. The application schemes are illustrative and should not be construed as limiting in any way.

[0122] Multiple simultaneous arbitrations So far, for simplicity, only a single arbitration has been described. Therefore, in practical applications (such as on an SoC), multiple arbitrations may be performed simultaneously. Please understand that.

[0123] Referring to FIG. 7, the switches 16, 18 handle traffic in two directions. 1 shows a block diagram of two shared interconnects 12 and 12Z for The switch 16 then connects the source subfunction 14 (i.e. IP1, IP2, and IP3) to destination subfunction 14 (i.e., I Directs transaction traffic to IP addresses (IP4, IP5, and IP6). To handle the transaction traffic, the switch 18 must In operation, the element 26Z and the ARL 28Z operates in a complementary manner to the above-mentioned operation, and this is the source IP agent 14 (i.e. i.e., transaction traffic generated by IP4, IP5, and IP6 The traffic is arbitrated and sent to the destination IP agent (i.e. That means that the packet is sent to IP1, IP2, and IP3. Arbitration may be performed without the ARL28Z, which is However, it is simply a matter of deciding between competing ports (e.g. Port3, Port3 or Port5). The winning port determines which part of the transaction is associated with the winning port and which part is the final destination for that part. Regardless of the number of bits, the signal is transmitted over interconnect 12. Elements 12Z, 26Z, and 2 8Z has already been described, so for the sake of brevity a detailed description will not be provided here. .

[0124] An SoC has multiple levels of subfunctions14 and multiple shared interconnects12. Each can have various sub-functions using the arbitration scheme described above. Arbitration between transactions sent over interconnect 12 between can be performed simultaneously.

[0125] IP Agent Reset and Power Management Referring to FIG. 8, a block diagram of an SoC 800 with reset and power management functions is shown. The SoC 800 includes an interconnect 802 and a number of IP agents 14 (e.g., For example, agent 1 to agent N) and an IP agent 14 are connected to the interconnection 802. The system includes one or more links 803 that connect or couple to each other, and a system controller 804 . Although not shown, each IP agent 14 may include one or more external devices for receiving a reset input command. Such instructions may come from multiple sources (such as the SoC from outside the system, from the system controller 804, or from another IP agent 14, etc.) It is okay to lean on it.

[0126] In various embodiments, the IP agent 14 may be different and may be a variety of different The function may be implemented.

[0127] The interconnect 802 may be a network on chip (NoC), a bus, or a switch network. etc., various different types of interconnects.

[0128] In various embodiments, the links 803 each interconnect 8 with each IP agent 14. 02. Alternatively, access to the interconnect 802 may be The IP address may be shared among multiple IP agents 14 using a single link 803. , an arbitration scheme is used to select between competing IP agents 14 . In yet another embodiment, multiple virtual channels are associated with a shared link as previously described. It may be associated with one or more links 803, such as a virtual channel to which it is attached.

[0129] System controller 804 and managers 806, 808, and 809 The arithmetic logic may be implemented in many different ways. For example, As programmable logic, all or most of the system on the SoC800 Complex state machines to handle system control functions, simple state machines to handle some exceptional situations The system controller 804 may be any of the following: As shown in FIG. 1, the SoC 800 may be on the SoC 800, or may be separate from the SoC 800. If a state machine is used, the states and the transitions between the states may be arranged in a is typically hard-coded into the SoC800.

[0130] In yet another embodiment, money for reset, power and / or hibernation One or more of the controllers 806, 808, and 809 may each be a system controller, as shown in the figure. Alternatively, each of the managers 806, 808, and and / or 809 may be distributed and distributed to various locations on the SoC 800 or outside the SoC. A reset manager 806, a power manager 808, and a hibernation manager 809 may be provided. Each of the sensors 809 may be implemented using software, hardware, programmable logic, state machines, and the like. It may be implemented in a single manner, such as by a single processor, a single SPI, or in any other suitable manner.

[0131] The reset manager 806 orchestrates the reset to the various IP entities on the SoC 800. It is responsible for managing the exit of IP Agent 14. The reset of IP Agent 14 For example, removing power supplied to SoC 800 may be required or desirable under certain circumstances. Or after a power outage or a reset of the entire SoC800 system, Or, one, a group, or all of the IP agents 14 may The internals are reset (similar to a cold reset), but only when power is removed or reset from the SoC800. If the power is not disconnected, a "warm reset" occurs. This can be accomplished by signaling originating either from above or externally. Regardless of how it is done, the reset manager 806 systematically keeps one or It is responsible for managing the exit of multiple IP agents 14.

[0132] If the IP Agent 14 is not working properly for some reason, it may need to be reset. An example of IP agent 14 not functioning properly is when IP agent 14 , not responding, in an error state, or actively generating error transactions. In yet another example, the IP agent 14 may may need to undergo a reset operation after coming out of a low power state, such as one of the power saving modes do.

[0133] A power manager 808 may be configured to place the various IP agents 14 in a low power state (typically Depending on the mode, the power manager 8 08, a reset manager 80 to reset the IP agent if necessary. It may work in conjunction with 6.

[0134] The sleep manager 809 is connected to the system controller 804, the reset manager 806, The power manager 808, in conjunction with the interconnect 802, performs the following operations: Possible or malfunctioning IP Agent 14, resetting the IP Agent to become inoperable (2) transitioning the link between the interconnect and the IP agent 802 to a power-saving mode; (3) put the IP agent into a dormant state and act as a proxy for the IP agent while it is down. Instruct the interconnect to

[0135] The memory 810 may include both volatile and non-volatile types of memory. The memory 810 may be centralized on the SoC 800 or may be integrated into the system controller 804. Interconnect 802, link 803, and managers 806, 808, and / or , 809. Some or all of the memory 810 may be provided remotely from the SoC 800.

[0136] The volatile portion of memory 810 is typically utilized for system memory, where the system System controller 804, manager 806, 808, 809, interconnect 802, IP The memory stores current data generated by the agent 14, etc. This may include various caches, SRAM, DRAM, etc.

[0137] The non-volatile or persistent portion of memory 810 is typically referred to as the “block” for the SoC 800. The boot code is used to store the "boot up" code. 808, 809, interconnection 802, and IP agent 14, including the system components Each controller 804 is configured to run the operator as required to begin operation after powering on. operating system and / or other system software. The reboot process typically involves multiple self-tests, which, upon completion, In addition, the entire system, including each of the IP agents 14, is enabled to perform normal operations. The non-volatile or persistent portion is called NVRAM (Non-Volatile Random Access Memory). , EEPROM (Electrically Erasable Programmable Read-Only Memory), Hard Drive , may be implemented using a CD-ROM, etc.

[0138] The reset manager 806 systematically determines whether any of the IP agents 14 are reset. As described herein, a given IP agent is responsible for coordinating the exit of 14 resets are: (1) The entire SoC800 is reset by an external reset, restart command, or or when coming out of reset after a power-on event, or (2) after a power-down or standby event. Individual IP agents 14 in operation on SoC800 due to malfunction after leap mode This can happen for a variety of reasons, including a reset of the IP address of a given IP agent. 4 can be introduced into the interconnect 802 at any time once the internal reset sequence is complete. After exiting the set, negotiation continues on the interconnect 802 via link 803. It is coordinated between the P agent 14 and its IP port 20 .

[0139] Referring to FIG. 9, the IP agent 14 between the interconnect 802 A flow chart illustrating an example of a reset negotiation sequence is shown.

[0140] In a first step 902, the IP agent 14 comes out of reset and connects to the interconnect 802. Upon coming out of reset, the interconnect 80 2, the following steps 904-912 are performed to reintroduce the IP agent 14 to .

[0141] In step 904, the interconnect 802 periodically queries the IP agent 14. With each inquiry, the interconnect 802 is essentially in an “awake” state. Whether the transaction is in a ready state (i.e., the The IP agent 14 is then asked whether the transaction can be sent or processed.

[0142] At decision 906, the interconnect receives an affirmative response to the query from the IP agent 14. If not, the interconnect 802 sends a query. If received, it indicates that the IP agent 14 should continue to execute its reset routine. Partially completed and ready for the next negotiation phase, interconnect 80 Shown for 2.

[0143] In step 908, the interconnect 802 and the IP agent 14 each The negotiation continues by exchanging credit information between the two parties. and the IP agent 14 each determine the available number of beats (i.e., clock cycles Each port on each side of the link 803 exchanges the amount of data that can be transmitted on the link 803 per second. After the exchange, the other party will receive credit for the remainder of the transaction. Know the possible numbers.

[0144] In optional step 910, the interconnect 802 and the IP agent 14 The link connecting the security credentials, the interconnect 802 and the IP agent 14 It also provides other useful information, such as the agreed upon number of virtual channels that can be associated with the network 803. The negotiation continues by exchanging

[0145] Finally, in step 912, once the negotiation is complete, the IP agent 14 , the IP agent 14 is declared "transaction ready." Processes incoming transactions received from interconnect 802 or forwards them to another destination. A send transaction is either ready to be sent or transmitted over interconnect 802 . When IP agent 14 is ready for a transaction, The interconnect 802, the system controller 804, and the Indirectly connected to interconnect 802 through circuitry, logic, or other elements It becomes visible to any other elements to which it is otherwise bound.

[0146] The reset manager 806 also coordinates the reset of the malfunctioning IP agent 14. During operation of the SoC 800, the IP agent 14 may (for example, becoming unresponsive, entering an error state, or having errors in creating a transaction) (This can cause errors or other malfunctions.) For example, an IP agent may It may be impossible to process a transaction. As a result, sending a transaction The sending IP agent may hang waiting for a response, depending on the severity of the problem. The hangup is limited to only source IP agent 14 and destination IP agent 14. In the worst case scenario, this could have a detrimental effect on other parts or the entire SoC800. Therefore, in certain circumstances, a misbehaving IP agent may cause problems. may need to be reset to correct the problem.

[0147] Referring to FIG. 10, a reset sequence for a malfunctioning IP agent is shown. A flow chart 1000 is shown.

[0148] In step 1002, various IP agents 14 on the SoC 800 transmit transactions. by generating transactions and / or processing incoming transactions. Create.

[0149] In step 1004, the system controller 804 determines whether the IP agent is running. If no problems are detected, the IP agents 14 continue their normal operation. On the other hand, if for some reason the IP Agent 14 does not work properly, reset it. The IP manager 806 flags it as a misbehaving IP agent 14 .

[0150] In step 1005, the system controller 804 and the interconnect 802 further , some of which help the rest of the SoC800 to work without further challenges or issues. These further processes may include: 1. The system controller 804 detects any unauthorized access by a malfunctioning IP agent 14. Requires that the interconnect 802 not allow transactions consisting of . 2. Tracking outstanding transactions targeting the misbehaving IP agent 14 . 3. The interconnect 802 detects a malfunctioning IP agent while undergoing a reset negotiation process. Acting on behalf of the IP Agent 14 and accepting any transactions targeted at that IP Agent 14 For example, the interconnect 802 may respond to outstanding transactions. It may respond by generating an exception message. The sender of the application never receives a response from the malformed IP agent 14. Avoid potentially much larger system-wide problems, such as the entire system hanging In various embodiments, the exception message is available to the IP agent 14. There were several different types, such as IP agents in low power mode, In general, a variety of different types of exception messages may be used, each of which may Indicates a failed status or error.

[0151] In step 1006, the reset manager 806 resets the malfunctioning IP agent 1 Generate a reset command for 4.

[0152] In step 1007, between the IP agent 14 to be reset and the interconnection 802 This link 803 is put into a dormant state. This process is further described with respect to FIG. do.

[0153] In step 1008, the malfunctioning IP agent 14 receives a in response to a command that may be received via a dedicated reset wire, The reset routine begins. This process is performed by the IP agent as described above with respect to FIG. Component 14 (1) executes its own reset protocol or routine and (2) 802.

[0154] At decision step 1012, the reset negotiation of the IP agent 14 is completed. Once complete, control returns to step 1002, where the IP agent 14 and SoC800 resume normal operation. As mentioned above, the reset IP address is After coming out of reset, the agent 14 connects the interconnect 802 and the system controller Finally, in step 1014, In the above, the link 80 between the currently reset IP agent 14 and the interconnect 802 is 3 exits the dormant mode. At this point, the interconnect 802 no longer communicates with the IP agent 14. It is not necessary for the organization to act as a proxy for the

[0155] The power manager 808 may place the IP agent 14 in one of several power down modes. By enabling the IP agent 14 to enter a low power state, Powering down the IP Agent 14 or putting it into power down mode This can be done for a variety of reasons.

[0156] For example, if the SoC 800 is used in a battery-powered device, the power manager 80 8. Put the IP Agent into power down mode to conserve limited battery power Alternatively, even in non-battery powered devices, the power manager 808 may To prevent overheating, non-essential IP agents 14 may be put into a low power mode. These are just a few of the possible reasons for implementing power management. As an example, if one or more IP agents 14 are not in use, they are powered down. In various alternative embodiments, the power down mode may include: Includes: 1. Low power mode, operational In one alternative embodiment, the clock frequency of the IP agent 14 The number is slowed down, if applicable. Or the supply voltage is reduced, if applicable. In yet another embodiment, both the clock frequency and the supply voltage may be The clock frequency and / or The reduction in supply voltage will only be made where applicable, but this is the responsibility of all IP agents. 14 may be implemented using either a reduced clock frequency, a reduced supply voltage, or both. It should be understood that this does not mean that the device can operate in either case. In another embodiment, the command to reduce the clock and / or supply voltage comprises: If applicable, the system may be configured to use the IP agent 14 with a low-power operating mode. The IP address may be obtained from the system controller 804 or from the IP agent 14 itself. The interconnect 802 plays no important role in this mode, since the IP agent remains functional. This is because the IP agent 14 can generate the response itself. The interconnect 802 acts as a proxy for the IP agent 14 to forward incoming transactions. However, this means that the IP agent 14 does not need to generate a response to the request. Since performance may be degraded when operating at low clock frequencies, the system controller 804 and and / or the interconnect 802 reconfigures the link 803 for the IP agent 14. The settings that may possibly be changed are the arbitration settings for the IP agent 14. ration settings or possible reduction in the count of allowed outstanding transactions When the IP Agent exits this low power mode, the voltage (if it was reduced) First it is raised, then the clock frequency is increased (if it was lowered), and then Any changes to the settings of link 803 (if any) are restored to normal operating mode. 2. Low power, inoperative mode, maintains state information In this mode, the clock is stopped and the power The power supply is reduced but not turned off completely. As a result, the IP agent 14 memory. Before entering this mode, the interconnect 8 02 prevents new transactions from being started and clears outstanding transactions. By waiting for the completion of the transaction, the IP agent can “deadlock” the transaction that it has already issued. Once all transactions are exhausted, the interconnect 802 will This works by performing the same process as described above for reconfiguring the malfunctioning IP agent 14 ( 1), (2), and (3) may be executed. The IP agent is returned to normal and this When exiting the mode, the voltage is first increased and then the clock frequency is increased. 3. Low power, inoperative mode - no state information retention This mode is available in the IP agent. This is exactly what is described above, except that the voltage is reduced to such an extent that the state information maintained in the This is similar to mode 2 described above. In this mode, the interconnect 802 acts as a proxy, as described above. When power is restored, the IP agent operates in a similar manner as described above with respect to FIG. It is necessary to undergo a reset negotiation process. 4. Power Off Mode In this mode, the clock is turned off and the power is completely removed. The interconnect 802 acts as a proxy as described above. Upon power up, the supply voltage It is first raised and then the reset negotiation process is performed as described above with respect to FIG. It will be executed.

[0157] FIG. 11 illustrates a method for moving the IP agent 14 into and out of a "low power, operational mode." 11 is a flowchart 1100 showing the sequence.

[0158] In a first step 1102, the IP agent 14 on the SoC 800 is in normal mode. It operates at 100 MHz, which means that standard clock frequencies and voltages are utilized.

[0159] In a determination step 1104, the conditions in the SoC 800 are transmitted to the system controller 804. The IP agent 14 is monitored to determine whether the operating conditions are relatively normal or whether the power If no event occurs that triggers a power down, the SoC and IP agent 14 However, if the trigger condition is not met, the device continues to operate in normal mode at step 1102. If the power supply is low, the power manager 808 detects that the battery is overheating. may choose to put the IP agent 14 into a low power, operational mode.

[0160] In optional step 1106, interconnect 802 may reconfigure link 803. The reconfiguration may select arbitration settings for the IP agent 14. or take into account the reduced processing power of the IP Agent when operating in low power mode. This includes reducing the count of possible outstanding transactions to allow for is fine.

[0161] In step 1108, the operating clock frequency of the IP agent 14 is set to The lower the clock frequency, the lower the power consumption of the IP agent.

[0162] In step 1110, the voltage supplied to the IP agent is reduced, if applicable. Further power savings can be realized by lowering the voltage.

[0163] The IP agent 14 operates at a reduced clock frequency and / or voltage. As a result, the transaction can be processed, but at its normal clock frequency. It is likely to be slow when operating at the frequency and / or supply voltage. In an embodiment, the interconnect 802 may function as a proxy as described above, or To support low power mode, taking into account the low operating speed of IP Agent 14 These alternatives are optional and may not necessarily be implemented. There is no need.

[0164] At decision step 1112, the IP agent 14 decides to resume normal operation. The IP agent 14 will then operate in a low power mode until it is powered off. Receive a sequence to resume.

[0165] In optional step 1114, the voltage is adjusted to the voltage), then raised to standard operating voltage.

[0166] In step 1116, the clock frequency is adjusted, if applicable (i.e., if the clock In step 1117, the IP agent Return to normal operation.

[0167] Finally, in optional step 1118, the interconnects are reconfigured to include any reconfigured phases. At this point, the IP agent returns the interconnection settings to normal as provided in step 1102. Then, normal operation is ready to resume.

[0168] Referring to Figure 12, the IP agent in the "low voltage, inoperable, status information retention mode" 12 is a flow chart 1200 showing a sequence for powering down / up the 14 It has been done.

[0169] In step 1202, the IP agent 14 operates in its normal mode.

[0170] In step 1204, the IP agent 1 is in a low power, disabled, state information maintaining mode. The decision is made to run 4.

[0171] In step 1206, link 803 is put into a dormant state and interconnect 802 is reconnected to the IP The agent 14 is configured to operate on behalf of the agent 14. This typically involves: (1) does not allow new transactions to be generated by IP agent 14, (2) wait for any outstanding transactions to complete, and then (3) Acts as a proxy by responding to any transactions targeted at the agent14 For example, the interconnect 802 may be excluded from the source of the non-transaction transaction. A message may be sent, perhaps by the sender of the transaction, IP Agent 1. This prevents a hang-up situation caused by never receiving a response from 4.

[0172] In step 1208, the clock frequency of the IP agent 14 is adjusted, if applicable, Can be obtained.

[0173] In step 1210, the operating voltage of the IP agent 14 is reduced, if applicable. However, the voltage may vary depending on the memory or storage elements of the IP agent 14. The scalability of the ...

[0174] At decision 1212, the IP agent 14 continues to wait until it is determined to resume normal operation. The system controller 804 remains in a low power state when an event outside the SoC ( (e.g. signals received from sensors, signals received from external sources, etc.), timers, IP The agent itself or any other IP agent can trigger a wakeup. Once this decision is made, the IP agent will initiate a sequence to resume normal operation. Receive service.

[0175] In steps 1214 and 1216, the voltage and Each of the clock frequencies is increased, if applicable. State information is maintained so that The IP agent 14 resumes normal operation in step 1217 .

[0176] In step 1218, the link 803 is in a dormant mode and the IP agent The transaction is ready and the interconnect 802 needs to act as a proxy for a long time. You will be notified that there is something.

[0177] Referring to FIG. 13, a flow chart showing the sequence for the "low voltage, disabled mode" is shown. In this sequence, steps 1202, 1206, and 1212 are the same as the steps described above with respect to FIG. and will not be discussed again here.

[0178] In step 1302, a decision is made to power down the IP agent 14. Then, the interconnect is configured as a proxy (step 1206), and in step 1304, the IP agent The clock for Gen14 is turned off completely (if applicable), and / or When the voltage is low, the voltage is reduced to such an extent that status information (if any) is lost. If not, then if a decision is made in step 1212 to resume normal operation, step 1306 Then the voltage is raised (if applicable) and the clock is turned on (if applicable). Thereafter, the IP agent 14 undergoes a reset operation as described above with respect to FIG. Once the set is complete, the IP agent 14 is in a transaction ready state. The system then waits for the link to exit the dormant mode in step 1310. The IP agent is then visible on the interconnect 802. The interconnect 802 no longer acts as a proxy for the IP agent 14 .

[0179] Finally, for the power off mode, the sequence is switched on and off as opposed to simply being switched off. This is the same as Figure 13, except that the power-off The sequence of modes is the same. In this mode, the IP agent 14 essentially The interconnect 802 is essentially powerless and inoperable, and acts as a proxy for the IP agent. It may function as a theory.

[0180] Referring now to FIG. 14, a flow chart illustrating the steps for putting a link 803 into a dormant state is provided. 1400 is shown.

[0181] In a first step 1402, the system controller 804 receives the IP agent 14 should be reset or put into one of the inoperative power saving modes. Make a decision.

[0182] In step 1404, the IP agent 14 stops generating transactions. They are ordered to do so.

[0183] At decision 1406, the system determines whether all outstanding transactions have been completed. For all outstanding non-posted transactions, A Completion transaction must be received (i.e., In a transaction, the accessed data must be returned, and the non- For sted write transactions, an acknowledgment must be received. A sted transaction does not require a reply transaction. A hosted transaction is considered "completed" once it has been sent by the IP agent. It is done.

[0184] In step 1408, link 803 is closed when all outstanding transactions are completed. The interconnect 802 then becomes inactive on behalf of the IP agent 14. It is composed of:

[0185] In step 1410, the IP agent resets or initiates a desired inoperative low power mode. The device is ready to be put into one of the modes.

[0186] 15A-15D show various implementations for the IP agent "wake-up" sequence. A flowchart is shown below.

[0187] Referring now to FIG. 15A, an agent-initiated "wake-up" sequence is shown. A flowchart 1500 is shown. In this embodiment, the wake-up sequence The transaction is initiated by the IP agent but controlled by the system controller 804. It will be implemented.

[0188] In step 1502, the inoperative IP agent 14 receives a wake-up trigger. Detects events. The IP Agent can be powered down or "off", but At least partially, in order to maintain the ability to detect when a wake-up trigger occurs. Wake-up triggers can be triggered by many different types of events. For example, the IP agent 14 may be woken up after a predetermined period of time. It may be an internal timer that is running on the network, or it may be another device that wants to communicate with the IP agent 14. In step 1504, the IP agent The client sends a “wake up” communication over its link 803 to the interconnect 802. Again, a link may be suspended when its corresponding IP agent 14 is inoperative. Although in a stopped state, a wake-up signal can be sent to the interconnect 802.

[0189] In step 1506, the interconnect 802 receives a route from the inoperative IP agent. If a signal is detected, the interconnect 80 2 notifies the system controller 804.

[0190] In step 1508, the system controller 804 detects that the IP agent 14 Send a command over interconnect 802 to initiate a wake-up sequence. good.

[0191] In step 1510, the IP agent responds to the command by performing a wake-up system. Start the sequence.

[0192] In the above embodiment, the IP agent 14 initiates a wake-up sequence. The system controller is asked to wake up. In response to the command, the IP agent initiates its wake-up sequence. Therefore, the System Controller determines whether the IP Agent is out of the inoperable state and can reconnect to the When it becomes visible on the interface 802, it knows the status of the IP agent.

[0193] FIG. 15B shows a process in which the system controller 804 wakes up the IP agent 14. The sequence for starting the process is shown in FIG. 1. In this sequence, the system controller 804 In step 1508, a wake-up command is sent to the IP agent, and in response The IP agent then initiates its wake-up sequence in step 1510. In a variation of this embodiment (not shown), the wake-up is initiated by the system controller 8 8. The system controller 804 may be started outside the SoC 800 via Upon receiving the command, the above process begins.

[0194] FIG. 15C illustrates a wake-up command for the IP agent 14. 8. The sequence when the sequence is performed through the system controller 804. In this sequence, the system controller 804 receives a command in step 1512. In response, the system controller notifies the IP agent in step 1508. In response to sending a wake-up command, the IP agent Initiates its own wake-up sequence. Direct wake-up from outside the SoC800 In this case, commands are provided directly to the IP agent 14 via hardwired inputs. In response, the IP agent initiates its own wake-up sequence.

[0195] Referring to FIG. 15D, the wake-up sequence initiated and performed by the IP agent is A flow chart 1520 illustrating the process is shown. In this embodiment, the wake-up condition A condition (such as any of the conditions described above) occurs in step 1522. In response, The P agent starts its wake-up sequence in step 1524. In 526, the wake-up sequence is completed. Then, in step 1528 The IP agent may then report its awake state to the interconnect 802 and the system controller. The controller 804 is notified either directly or via the interconnect 802 .

[0196] In the above example, for simplicity, we have chosen to use a single IP agent in the low power mode described above. In an actual embodiment, the sequence of transitioning from one to another on the SoC is described. Multiple IP agents 14 may be powered down at the same time. When powered down, each independently performs one of the above sequences depending on the mode. receive.

[0197] Although only a few embodiments have been described in detail, the spirit and scope of the disclosure provided herein is not to be construed as limiting the present invention. It should be understood that the present invention may be embodied in many other forms without departing from the spirit and scope of the present invention. Therefore, these embodiments should be considered as illustrative and not limiting. It is not intended to be limited to the details given in this specification, but to encompass all modifications and variations within the scope of the appended claims and their equivalents. This may be done.

Claims

1. A system on chip (SoC), comprising: A plurality of IP agents; an interconnect for communicating with said plurality of IP agents; a hibernation manager; The hibernation manager: a link between the interconnect and at least one IP agent of the plurality of IP agents in a dormant state, the at least one IP agent being not in a transaction ready state in the dormant state, the dormant manager further comprising: The SoC is configured to instruct the interconnect to act as a proxy for the at least one IP agent when the at least one IP agent is in the dormant state.

2. 2. The SoC of claim 1, wherein the at least one IP agent is not in a transaction ready state when undergoing a reset.

3. 3. The SoC of claim 1 or 2, wherein the at least one IP agent is not in a transaction ready state when in a power down mode.

4. 4. The SoC of claim 1, wherein the at least one IP agent is not in a transaction ready state when malfunctioning.

5. 5. The SoC of claim 1, wherein the interconnect comprises: determining that the at least one IP agent is not in a transaction ready state; determining whether a source sent a transaction to said at least one IP agent while said at least one IP agent was not in a transaction ready state; The SoC acts as the proxy for the at least one IP agent by sending an exception message to the source to notify the source that the at least one IP agent is unavailable.

6. 6. The SoC of claim 5, wherein the sender receives the exception message as a response to a transaction that was sent but not delivered to a destination.

7. 7. The SoC of claim 1, further comprising a reset manager for initiating a reset of each of the plurality of IP agents.

8. 8. The SoC of claim 1 , wherein the interconnect is further configured to engage in an individual negotiation with each of the plurality of IP agents when each of the plurality of IP agents is respectively reset.

9. 9. The SoC of claim 1 , wherein after a reset of two or more of the plurality of IP agents, each of the two or more IP agents is configured to individually reset and become transaction ready, respectively, independent of the other IP agents.

10. 10. The SoC of claim 9, wherein each of the two or more IP agents independently becomes transaction ready on its own time schedule, without the two or more IP agents having to become transaction ready at the same time.

11. 11. The SoC of claim 1, further comprising a system controller, wherein at least one IP agent is visible to the system controller when it is in a transaction ready state.

12. A system on chip (SoC), comprising: A plurality of IP agents; an interconnect for communicating with said plurality of IP agents; a dormancy manager configured to dormant a link between the interconnect and at least one IP agent of the plurality of IP agents, wherein in the dormant state the at least one IP agent is not in a transaction ready state; a power manager for at least partially managing power consumption by the SoC by selectively placing at least one of the plurality of IP agents in a low power state; Equipped with (a) in said low power state; and (b) when unavailable to process transactions. The SoC, wherein the dormancy manager places the link between the interconnect and each of the at least one IP agent in the dormant state and instructs the interconnect to act as a proxy for the at least one IP agent, the interconnect acting as the proxy by providing an exception message to a sender attempting to send the transaction to the at least one IP agent.

13. 13. The SoC of claim 12, wherein the at least one IP agent performs its own low power sequence when entering the low power state.

14. 14. The SoC of claim 12 or 13, wherein the low power state comprises a low power mode in which the at least one IP agent remains in a transaction ready state.

15. 15. The SoC of claim 14, wherein the interconnect does not act as a proxy when the at least one IP agent is in the low power state and remains in a transaction ready state, and adjusts a setting of one of one or more links connecting the plurality of IP agents with the interconnect to accommodate a reduction in clock frequency and / or voltage for the at least one IP agent.

16. 16. The SoC of claim 12, wherein the low power state comprises a low power mode in which the at least one IP agent is no longer transaction ready.

17. 17. The SoC of claim 16, wherein the at least one IP agent retains state information when in the low power mode and is no longer in a transaction ready state.

18. 17. The SoC of claim 16, wherein the at least one IP agent does not retain state information when in the low power mode and is no longer in a transaction ready state.

19. 19. The SoC of claim 12, wherein the low power state comprises a power off mode in which minimal power is supplied to the at least one IP agent.

20. 20. The SoC of claim 12, wherein the low power state is implemented by reducing an operating clock frequency of the at least one IP agent.

21. 21. The SoC of any one of claims 12 to 20, wherein the low power state is implemented by reducing a voltage utilized by the at least one IP agent.

22. 22. The SoC of claim 12, wherein the low power state is reducing an operating clock frequency of said at least one IP agent; The SoC is implemented by reducing a supply voltage utilized by the at least one IP agent after reducing the operating clock frequency.

Images