Patent Description:
Many different types of known buses and other interfaces are used to connect different components using a wide variety of interconnection topologies. For example, on-chip buses are used to couple different on-chip components of a given integrated circuit (IC) such as a processor, system on chip or so forth. External buses can be used to couple different components of a given computing system either by way of interconnect traces on a circuit board such as a motherboard, wires and so forth.

A recent multi-drop interface technology is an Improved Inter Integrated Circuit (I3C) Specification-based bus, available from the MIPI Alliance, Inc. This interface can be used to connect devices, such as internal or external sensors or so forth, to a host processor, applications processor or standalone device via a host controller or input/output controller. While a bus master capability can be transferred from one device to another device via a bus ownership transfer flow, there is considerable overhead and complexity that may make this operation difficult or ineffective in various situations.

<CIT> describes a host controller that includes a clock control circuit to cause the host controller to communicate a clock signal on a clock line of an interconnect, the clock control circuit to receive an indication that a first device is to send information to the host controller and to dynamically release control of the clock line of the interconnect to enable the first device to drive a second clock signal onto the clock line of the interconnect for communication with the information.

<CIT> discloses a slave device comprising a clock generation circuit using IBI (in-band interrupts) for requesting a transaction to another slave to be acknowledged by the master. The master remains master and bridges the slave-to-slave communication.

<CIT> discloses peer-to-peer communication between slave devices which is initiated by an in-band interrupt. Secondary masters and peer-to-peer slave devices have different codes assigned in the bus characteristic register BCR so that these devices belong to different device categories.

In various examples, a slave device coupled to a multi-drop interconnect may be granted authorization by a master or bus owner to perform peer-to-peer communications with one or more other slave devices coupled to the interconnect. Understand that such peer-to-peer communications occurs without the need for the initiating slave device to seek an ownership transfer for the interconnect. Instead the slave device seeks authorization for a limited capability of performing peer-to-peer transactions, including driving a clock signal on the interconnect during such communications. But this limited capability does not include granting the slave device bus ownership, or allowing the slave device to handle other bus control issues. In this way, the complexity involved in a negotiation for ownership transfer is avoided, enabling efficient peer-to-peer communications with reduced overhead.

Some examples may be used in connection with intra-device communications on an I3C bus. Such transactions may occur without the need for a bus master to be involved in the communications, such as by way of identifying destination device and performing clock management during such transactions. Furthermore, by enabling an initiating slave device to drive the clock signal, improved signal integrity is realized, as both data and clock may issue from the same source, avoiding skew or other signal integrity issues. While examples may be used in many different circumstances, example implementations may be used for performing management component transport protocol (MCTP) transactions between various components. As such, examples may be used on a transaction-by-transaction basis to enable a single or limited amount of peer-to-peer communications to occur without incurring the overhead of a bus ownership transfer process.

Referring now to <FIG>, shown is a block diagram of a system in accordance with an example. More specifically, system <NUM> shown in <FIG> represents at least a portion of any one of a variety of different types of computing devices. In different examples, such computing devices can range from relatively small low power devices such as a smartphone, tablet computer, wearable device or so forth, to larger devices such as laptop or desktop computers, server computers, automotive infotainment devices and so forth. In any case, system <NUM> includes a bus <NUM>, which may take the form of any medium of communication including printed circuit board, flex cable or other communication media. In examples herein, bus <NUM> may be implemented as an I3C bus in accordance with an I3C specification, available from the MIPI Alliance, Inc. , Inter-Integrated Circuit (I<NUM>C) bus according to an I<NUM>C specification available from NXP Semiconductors or another half duplex communication interconnect that may be implemented with a minimal set of wires (e.g., two). Understand that as used herein, the term "IxC" is intended to refer to any and all variations of half-duplex links that may implement an example, such as I<NUM>C or I3C interconnects. However, understand the scope is not limited in this regard and in other examples, bus <NUM> may be implemented as any type of multi-drop interconnect.

As illustrated, a current master device <NUM> couples to bus <NUM>. While in some cases, current master device <NUM> may be a primary master, for purposes of discussion herein, any bus master-capable device may be the current master. In various examples, master device <NUM> may be implemented as a host controller that includes hardware logic to act as a bus master for bus <NUM>. Master device <NUM> may include a controller (not shown in the high level view of <FIG>) to control data (SDA[<NUM>]-[n]) and clock (SCL), as well as use (e.g.,) internal current sources or passive pullups to hold bus <NUM> when all coupled devices are powered off. In some cases, master device <NUM> may be a relatively simple host controller for a low complexity bus or other multi-drop bus, such as in accordance with an I<NUM>C or I3C specification. Other multi-drop interfaces such as Serial Peripheral Interface and/or Microwire also may be present in a particular example. While in <FIG>, bus <NUM> has multiple data lines, examples may also be used in connection with a bus having a single data line and a single clock line.

In different implementations, master device <NUM> may be an interface circuit of a multicore processor or other system on chip (SoC), application processor or so forth. In other cases, master device <NUM> may be a standalone host controller (such as a given integrated circuit (IC)) or main master device for bus <NUM>. And of course other implementations are possible. In other cases, master device <NUM> may be implemented as hardware, software, and/or firmware or combinations thereof, such as dedicated hardware logic, e.g., a programmable logic, to perform bus master activities for bus <NUM>.

Note that bus <NUM> is implemented as a multi-wire bus in which one or more serial lines form a data interconnect and a single serial line forms a clock interconnect. As such, in the general case data communications can occur, e.g., in bidirectional manner between masters and slaves and clock communication can occur from master to slaves. Master device <NUM> may be a relatively compute complex device (as compared to other devices on bus <NUM>) that consumes higher power than other devices coupled to bus <NUM>.

As shown in <FIG>, multiple secondary master devices <NUM><NUM> - <NUM>N are present. In various examples, secondary master devices <NUM> (generically) may be implemented as dedicated master or bridge devices such as standalone IC's coupled to bus <NUM>. In other cases, these devices may be independent logic functionality of a SoC or other processor (and in some cases may be implemented in the same IC as master device <NUM> known as a secondary master). One or more such secondary master devices <NUM> may be controlled to act as bus master for bus <NUM> while master device <NUM> is in a low power state, to enable bus operations to continue to proceed while in this low power state, based on a role definition in which as current master it drives a clock signal. Only one master can be the active master at a time. When one is the master, the others are acting as slaves.

As further illustrated in <FIG>, a plurality of slave devices <NUM><NUM> - <NUM>N also couple to bus <NUM>. In different examples, slave devices <NUM> (generically) may take many different forms. For purposes of discussion herein, it may be assumed that slave devices <NUM> may be always on (AON) devices, such as sensors like micro-electrical mechanical systems (MEMS), imaging sensors, peer-to-peer devices, debug devices or so forth. In examples, at least certain slave devices <NUM> may be configured to operate in a peer-to-peer (P2P) communication mode in which a given slave device <NUM> can receive P2P communication permission from master device <NUM> to issue P2P transactions to one or more other slave devices <NUM> (and/or one or more secondary master devices <NUM>). Such P2P transactions may be used to effect intra-device transactions in certain implementations. In these instances, the initiating slave device <NUM> may be configured with, at least, clock control circuitry such that it may generate and provide the clock signal during such P2P communications. Understand that such P2P communications do not incur the overhead and complexity of a bus master role transfer. Instead, the slave device is simply granted permission by master device <NUM> to perform one or more P2P communications in which it provides the clock signal, while master device <NUM> maintains the bus master role. And such slave devices <NUM> having capability for P2P communications may implement limited additional functionality as compared to secondary master devices <NUM>. Understand while shown at this high level in the example of <FIG>, many variations and alternatives are possible.

Referring now to <FIG>, shown is a block diagram of a system in accordance with an example. As shown in <FIG>, a portion of a system <NUM> includes a current master <NUM> including a host controller <NUM> coupled to a plurality of devices <NUM>A - 140c via a multi-drop bus <NUM>. As further illustrated, current master <NUM> includes an input/output (I/O) section <NUM>. Devices <NUM> (also referred to herein as "slaves") may have different operational characteristics and also may have different capabilities of being added/removed from bus <NUM>. As will be described herein, host controller <NUM> may be configured as a bus master, in at least certain operational phases. For ease of illustration, bus <NUM> is implemented as a two-wire bus in which a single serial line forms a data interconnect and another single serial line forms a clock interconnect. However in other implementations, there may be multiple data lines. Data communications can occur in bi-directional manner and clock communications can occur in a unidirectional manner. Understand that for granted P2P communications, the clock signal may be sent instead from a given slave device <NUM> and not from bus master <NUM> for such transactions.

At the high level illustrated in <FIG>, assume that different types of devices <NUM> are present. Devices 140a-c have, inter alia, different physical placements and electrical performance. For example, device <NUM>A may be always powered on and present as being coupled to bus <NUM>. As an example, device <NUM>A may be a given type of sensor, such as an accelerometer or other sensor which may be incorporated in a given system (such as a smartphone or other mobile platform). In some implementations, device <NUM>A may have debug capabilities and may seek to communicate debug information with one or more other slave devices <NUM>.

As illustrated in <FIG>, device <NUM>A may include a peer-to-peer (P2P) control circuit <NUM>. In examples, control circuit <NUM> may be configured to issue a P2P communication request to current master <NUM>. When granted such permission, control circuit <NUM> then may send one or more P2P communications to other slave devices <NUM>. In addition, control circuit <NUM> in such mode may also transmit a clock signal (generated within a clock generator <NUM>) via the clock line of bus <NUM>. As illustrated, clock generator <NUM> may output the clock signal via a driver <NUM> onto bus <NUM>. Otherwise during normal bus communications, slave device <NUM>A may receive the clock signal in a receiver <NUM> via the clock line of bus <NUM>. Data communications in input and output directions may be handled via corresponding receiver <NUM> and driver <NUM>.

For issuing a P2P communication requests, control circuit <NUM> may generate an in-band interrupt (IBI) command having a predetermined mandatory data byte (MDB) value to request permission from current master <NUM>. Note that in various implementations, device <NUM>A may not have full bus mastering capabilities, such that the device is not capable of operating as a bus master or secondary master. Yet with P2P control circuit <NUM>, slave device <NUM>A may be granted the limited ability to issue P2P transactions to one or more other slave devices <NUM>, including driving of a clock signal as described herein.

Device <NUM>B may be powered when it is to be active. As an example, assume that device <NUM>B is another type of sensor, such as a camera device. In such example, device <NUM>B may be powered on only when a camera functionality of the system is active. In other cases device <NUM>B may be a slave device that can be physically added/removed via a hot plug or hot unplug operation, such as a cable, card, or external peripheral device that is coupled to bus <NUM>, e.g., by a cable, external connection or so forth. In still other cases, device <NUM>B may be coupled via an in-box cable. In such cases, there may be a long distance between device <NUM>B and host controller <NUM>. In some implementations, device <NUM>B may be relatively further away from host controller <NUM> than device <NUM>A.

In the example of <FIG> slave device <NUM>B may be implemented as a secondary master such that in certain circumstances such as where current master <NUM> is to be powered down to reduce power consumption, slave device <NUM>B may operate in the bus master role. Also shown in <FIG> is another slave device 140c, which may be any other type of slave device either without secondary master capabilities, and further may include P2P capabilities as described herein. Note that a recipient of a P2P communication may be unaware that the initiating slave device is driving the clock signal; instead such communication appears to the receiving device as any other transaction (albeit with the advantage of improved signal integrity given the common source of clock and data). Stated another way, the P2P responsibility granted to an initiating slave device is transparent to receiving slave devices. And with an example as in <FIG>, it is possible for master device <NUM> to act as a slave device and participate in P2P communications when one of devices <NUM>B,C are current master.

As illustrated in <FIG>, host controller <NUM> includes a processing circuit <NUM>. Understand that many different types of host controllers can be provided. As examples, host controller <NUM> may be an interface circuit of a multicore processor or other SoC, application processor or so forth. In other cases, host controller <NUM> may be a standalone host controller for bus <NUM>. And of course other implementations are possible. In a debug context, processing circuit <NUM> may be a debug controller or aggregator to aggregate information received from other debug sources such as may be present in one or more of devices <NUM>. In different implementations, processing circuit <NUM> may represent one or more cores or other hardware processing logic of a particular device or it may simply be part of an interface circuit to act as transmitter and receiver for host controller <NUM>.

In turn, processing circuit <NUM> couples, via a bus control circuit <NUM>, to a driver <NUM> that drives data onto bus <NUM> and a receiver <NUM> that receives incoming data from bus <NUM>. Bus control circuit <NUM> may be configured to handle bus mastering operations for bus <NUM> and further may be configured to delegate bus mastering role to one or more slave devices <NUM> having secondary master capabilities.

Host controller <NUM> further includes a clock generator <NUM> to provide a clock signal (and/or to receive a clock signal, in implementations for certain buses) to a clock line of bus <NUM> via corresponding driver <NUM>. In various examples, clock generator <NUM> may be configured to provide additional clock signals for use in host controller <NUM>, as described herein.

As further illustrated, current master <NUM> further includes a P2P control circuit <NUM>. In various examples, control circuit <NUM> may, in response to receipt of an IBI or other P2P communication request from a given slave device <NUM>, determine whether to grant P2P communication responsibility to such slave device <NUM>. Assuming P2P control circuit <NUM> determines that such delegation is allowed, it may cause communication of an acknowledgement message back to the requesting slave device (via bus control circuit <NUM> and driver <NUM>). Still further, P2P control circuit <NUM> may issue a P2P control signal to clock generator <NUM>, which causes it to stop driving the SCL clock onto bus <NUM>, by disabling driver <NUM>. Similarly, after communication of the acknowledgment message, bus control circuit <NUM> may cause driver <NUM> to be disabled. In this arrangement, host controller <NUM> may receive the clock signal via receiver <NUM>.

Referring now to <FIG>, shown is a flow diagram of a method in accordance with an example. More specifically, method <NUM> is a method for performing peer-to-peer communication between slave devices. In <FIG>, method <NUM> is performed by a slave device seeking permission from a bus master to perform at least one peer-to-peer transaction. As such, method <NUM> may be performed by hardware circuitry, firmware, software and/or combinations thereof, such as may be present in a given slave device.

As seen, method <NUM> begins by sending a request for peer-to-peer communication from the first slave device to the bus master (block <NUM>). In one example this peer-to-peer communication request may be issued as an in-band interrupt having a predetermined value in its mandatory data byte to identify the interrupt as a P2P request. Assuming the bus master grants the request, control next passes to block <NUM> where the slave device receives peer-to-peer bus control from the bus master. To this end, the bus master sends an acknowledgment message and further parks clock and data lines of the bus so that they can be driven by the first slave device.

As further shown in <FIG>, at block <NUM> the first slave device drives a clock signal on a clock line of the bus and further drives a peer-to-peer transaction to one or more second slave devices on a data line of the bus. In different examples, this P2P transaction may be a unicast message directed to a single other slave device or a multicast or broadcast message directed to multiple other slave devices. In any case, while sending the transaction (and possibly additional P2P transactions) and driving the clock signal for the bus, it may be determined whether an abort message is received from the bus master (diamond <NUM>). In one example, the abort message may take the form of a T-bit received from the bus master. If such abort message is received, control passes from diamond <NUM> to block <NUM> where the first slave device may terminate driving the clock signal, as it has lost its P2P transaction capability.

Otherwise if no abort message is received, the first slave device may determine whether one or more transactions are completed, at diamond <NUM>. If not, control passes back to block <NUM> for further driving of the clock signal and issuing P2P transactions to one or more slave devices. Instead if it is determined at diamond <NUM> that the slave device has completed its P2P transactions, control passes to block <NUM> where the slave device issues a stop signal to the bus master. This stop signal is an indication to the bus master that the slave device has completed its transactions and that the bus master may again begin driving the clock signal. From block <NUM> control passes to block <NUM> where the slave device terminates driving the clock signal. Although shown at this high level in the example of <FIG>, many variations and alternatives are possible.

Referring now to <FIG>, shown is a flow diagram of a method in accordance with an example. More specifically, method <NUM> is a method for performing peer-to-peer communication between slave devices. In <FIG>, method <NUM> is performed by a master device that receives a request from a slave device seeking permission to perform at least one peer-to-peer transaction. As such, method <NUM> may be performed by hardware circuitry, firmware, software and/or combinations thereof, such as may be present in a given master device.

As shown in <FIG>, method <NUM> begins by receiving a peer-to-peer communication request from a slave device in the bus master (block <NUM>). Next it is determined whether this request is valid (diamond <NUM>). For example, the bus master may confirm that the received request, which may be in the form of an in-band interrupt, includes an MDB having the appropriate predetermined value. If not, control passes to block <NUM> where the bus master sends a NACK message to the slave device. Thus in this instance, the bus master does not grant any P2P transaction permission to the slave device and the bus master continues to drive the clock signal as appropriate.

Still with reference to <FIG>, if it is determined that request is valid, control passes to diamond <NUM> where it is determined whether to allow the request. As examples, the bus master may determine whether to grant the request based on a variety of factors, including current bus activities, pending bus master role transfers, bus power transitions and so forth. If the request is not allowed, control passes to block <NUM>, discussed above.

Assuming that the bus master allows the P2P communication request to be granted, control passes to block <NUM> where the bus master sends an acknowledgment message to the slave device, to indicate that the slave device is allowed to perform one or more P2P transactions. In this instance, the bus master may stop driving data and clock lines (blocks <NUM> and <NUM>).

At this point, the bus master has granted limited bus control to the slave device to issue one or more P2P transactions. However, understand that it is possible for the bus master to cause these transactions to terminate early. Thus it may be determined at diamond <NUM> whether peer-to-peer transactions are to be aborted. This determination may be based on higher priority messages to be delivered by the bus master, or for other reasons such as detection of an error condition or so forth. If it is determined to cause P2P transactions to be aborted, control passes to block <NUM> where the bus master may send a T-bit on a data line as a signal to the slave device to cause it to stop its P2P transaction. As such, control passes to block <NUM> where the bus master may regain bus control. Note that the slave device may perform clean up operations in this situation. For example the slave device may keep track of the fact that it did not complete its transaction, and may retry at a later time. To this end, the slave device may start a timer to countdown to when it will retry.

Otherwise, if there is no reason to abort the P2P transactions, control passes next to diamond <NUM> to determine whether the bus master has received a stop signal from the slave device, which is an indication that the slave device has completed its P2P transactions. If so, control passes to block <NUM> where the bus master may regain bus control, including to begin driving the clock signal on the bus, as appropriate. If the slave device is still performing a P2P transaction, control instead loops back to diamond <NUM>. Understand while shown at this high level in the example of <FIG>, many variations and alternatives are possible.

Referring now to <FIG>, shown is a timing diagram illustrating a peer-to-peer communication flow in accordance with an example. In <FIG>, a computing platform <NUM>, which may be any type of system includes multiple devices coupled via a multi-drop bus. As shown in <FIG>, assume the multi-drop bus has a master device <NUM> coupled to it, along with multiple slave devices, namely a first slave device <NUM>, a second slave device <NUM> and a third slave device <NUM>.

In the timing diagram of <FIG>, first slave device <NUM> seeks permission for a P2P transaction by sending an IBI with a mandatory data byte having a predetermined value, namely a magic value to indicate the request. Thereafter, first slave device <NUM> may follow the mandatory data byte with T=<NUM>, to indicate that the current request is complete.

When master device <NUM> identifies the request as a P2P request by way of the MDB matching the magic value, it may determine whether to authorize the communication. As an example, the master may depending on either a private contract with slave devices or as determined by the MDB and its value to not hand over control for this transaction and abort it, e.g., by issuing a stop command on the bus. Note that in some examples, the magic value may have a size larger than a single byte to allow additional usage types. In some cases, this magic value may be followed by a logical address to identify the receiving slave device. If such logical device is on another physical link, the master device may insert its own address to bridge the P2P communication to the correct link. In other cases, the magic value may be followed by a physical address that the master device may consider in determining whether to allow the peer-to-peer communication. Still further in some cases the magic value may be followed by additional code words to determine specific actions to be taken by the master device before bus handover occurs. Note that in different examples, the magic value may be provided to slave devices capable of P2P communications with a common command code (CCC) or as a fixed constant.

Assuming that master device <NUM> determines to allow the P2P communication to occur, it may back off to relinquish bus control, e.g., by parking the bus or otherwise stopping driving signaling on the bus to the requesting slave until a stop signal is received. In one example, this back off and bus relinquishment may be realized by the master parking a data line of the bus and thereafter parking a clock line of the bus, such as placing both lines to a high logic state, e.g., by tri-stating the data and clock lines, to enable first slave device <NUM> to start the P2P transaction with a restart. This transfer of temporary (and limited) bus control occurs with minimal hardware bus handover overhead and no software bus handover overhead. Note that this authorization is a temporary grant of bus ownership until a stop signal is received in master device <NUM> from first slave device <NUM>, or until master device <NUM> issues an abort command. Thus this bus ownership transfer is of a time limited and temporary duration.

Still with reference to <FIG>, first slave device <NUM>, after being granted this temporary bus ownership by way of the acknowledgement message, may initiate the transaction with a repeated start communication. Note that prior to the actual transaction communication, first slave device <NUM> may perform a mode change such as using an enter high speed mode command (ENTHDR CCC) after issuing a repeated start to enable HDR modes including bulk transfers. For example, one or more MCTP packets may be sent during this bulk transfer in a high speed mode.

As further illustrated further in <FIG>, after entry into this HDR mode, first slave device <NUM> may issue one or more write commands with message packets to second slave device <NUM>, while driving the clock signal until it issues a stop signal back to master device <NUM>. At this point, master device <NUM> may begin to again drive the clock signal, and may initiate further communications after an idle/available time period. Understand that <FIG> is in the context of an IC3 bus; however examples are applicable to other communication protocols. Also understand that in the case of a multi-data line bus, for purposes of the IBI phase additional data lines (e.g., SDA[<NUM>]-[n]) are not used until first slave device <NUM> receives permission from master device <NUM> to start driving a P2P transaction on the bus. For SDR mode, a multi-lane transaction may happen immediately after the repeated start. For HDR modes, a multi-lane transaction may use an ENTHDRx CCC after the repeated start. In both cases, second slave device <NUM> may be configured to accept transactions in a supported multi-lane mode (by master device <NUM>).

With examples, an efficient peer-to-peer mechanism is provided in which a slave device can initiate transactions, after a minimal handover process with a bus master. Such mechanism may be particularly appropriate where the overhead of a full bus handover to a secondary master would outweigh the benefit for short (e.g., time-limited duration) P2P transactions.

Examples may be implemented in a wide variety of interconnect structures. Referring to <FIG>, an example of a fabric composed of point-to-point links that interconnect a set of components is illustrated. System <NUM> includes processor <NUM> and system memory <NUM> coupled to controller hub <NUM>. Processor <NUM> includes any processing element, such as a microprocessor, a host processor, an embedded processor, a co-processor, or other processor. Processor <NUM> is coupled to controller hub <NUM> through front-side bus (FSB) <NUM>. In one example, FSB <NUM> is a serial point-to-point interconnect. In another example, link <NUM> includes a parallel serial, differential interconnect architecture that is compliant with different interconnect standards, and which may couple with one or more masters to control peer-to-peer communications on a bus as described herein.

System memory <NUM> includes any memory device, such as random access memory (RAM), non-volatile (NV) memory, or other memory accessible by devices in system <NUM>. System memory <NUM> is coupled to controller hub <NUM> through memory interface <NUM>. Examples of a memory interface include a double-data rate (DDR) memory interface, a dual-channel DDR memory interface, and a dynamic RAM (DRAM) memory interface.

In one example, controller hub <NUM> is a root hub, root complex, or root controller in a PCIe interconnection hierarchy. Examples of controller hub <NUM> include a chipset, a memory controller hub (MCH), a northbridge, an interconnect controller hub (ICH), a southbridge, and a root controller/hub. Often the term chipset refers to two physically separate controller hubs, i.e. a memory controller hub (MCH) coupled to an interconnect controller hub (ICH). Note that current systems often include the MCH integrated with processor <NUM>, while controller <NUM> is to communicate with I/O devices, in a similar manner as described below. In some examples, peer-to-peer routing is optionally supported through root complex <NUM>.

Here, controller hub <NUM> is coupled to switch/bridge <NUM> through serial link <NUM>. Input/output modules <NUM> and <NUM>, which may also be referred to as interfaces/ports <NUM> and <NUM>, include/implement a layered protocol stack to provide communication between controller hub <NUM> and switch <NUM>. In one example, multiple devices are capable of being coupled to switch <NUM>.

Switch/bridge <NUM> routes packets/messages from device <NUM> upstream, i.e., up a hierarchy towards a root complex, to controller hub <NUM> and downstream, i.e., down a hierarchy away from a root controller, from processor <NUM> or system memory <NUM> to device <NUM>. Switch <NUM>, in one example, is referred to as a logical assembly of multiple virtual PCI-to-PCI bridge devices. Device <NUM> includes any internal or external device or component to be coupled to an electronic system, such as an I/O device, a Network Interface Controller (NIC), an add-in card, an audio processor, a network processor, a hard-drive, a storage device, a CD/DVD ROM, a monitor, a printer, a mouse, a keyboard, a router, a portable storage device, a Firewire device, a Universal Serial Bus (USB) device, a scanner, and other input/output devices and which may be coupled via an I3C bus, as an example. Often in the PCIe vernacular, such a device is referred to as an endpoint. Although not specifically shown, device <NUM> may include a PCIe to PCI/PCI-X bridge to support legacy or other version PCI devices. Endpoint devices in PCIe are often classified as legacy, PCIe, or root complex integrated endpoints.

Graphics accelerator <NUM> is also coupled to controller hub <NUM> through serial link <NUM>. In one example, graphics accelerator <NUM> is coupled to an MCH, which is coupled to an ICH. Switch <NUM>, and accordingly I/O device <NUM>, is then coupled to the ICH. I/O modules <NUM> and <NUM> are also to implement a layered protocol stack to communicate between graphics accelerator <NUM> and controller hub <NUM>. A graphics controller or the graphics accelerator <NUM> itself may be integrated in processor <NUM>.

Turning next to <FIG>, an example of a SoC design in accordance with an example is depicted. As a specific illustrative example, SoC <NUM> may be configured for insertion in any type of computing device, ranging from portable device to server system. Here, SoC <NUM> includes <NUM> cores <NUM> and <NUM>. Cores <NUM> and <NUM> may conform to an Instruction Set Architecture, such as an Intel® Architecture Core™-based processor, an Advanced Micro Devices, Inc. (AMD) processor, a MIPS-based processor, an ARM-based processor design, or a customer thereof, as well as their licensees or adopters. Cores <NUM> and <NUM> are coupled to cache control <NUM> that is associated with bus interface unit <NUM> and L2 cache <NUM> to communicate with other parts of system <NUM> via an interconnect <NUM>. In the example shown, bus interface unit <NUM> includes a P2P control circuit <NUM>, which may be configured to enable P2P communications as described herein.

Interconnect <NUM> provides communication channels to the other components, such as a Subscriber Identity Module (SIM) <NUM> to interface with a SIM card, a boot ROM <NUM> to hold boot code for execution by cores <NUM> and <NUM> to initialize and boot SoC <NUM>, a SDRAM controller <NUM> to interface with external memory (e.g., DRAM <NUM>), a flash controller <NUM> to interface with non-volatile memory (e.g., flash <NUM>), a peripheral controller <NUM> (e.g., an eSPI interface) to interface with peripherals, video codecs <NUM> and video interface <NUM> to display and receive input (e.g., touch enabled input), GPU <NUM> to perform graphics related computations, etc. Any of these interconnects/interfaces may incorporate aspects described herein, including control of intra-device communications. In addition, the system illustrates peripherals for communication, such as a Bluetooth module <NUM>, <NUM> modem <NUM>, GPS <NUM>, and WiFi <NUM>. Also included in the system is a power controller <NUM>.

Referring now to <FIG>, shown is a block diagram of a system in accordance with an example. As shown in <FIG>, multiprocessor system <NUM> includes a first processor <NUM> and a second processor <NUM> coupled via a point-to-point interconnect <NUM>. As shown in <FIG>, each of processors <NUM> and <NUM> may be many core processors including representative first and second processor cores (i.e., processor cores 874a and 874b and processor cores 884a and 884b).

Still referring to <FIG>, first processor <NUM> further includes a memory controller hub (MCH) <NUM> and point-to-point (P-P) interfaces <NUM> and <NUM>. Similarly, second processor <NUM> includes a MCH <NUM> and P-P interfaces <NUM> and <NUM>. As shown in <FIG>, MCH's <NUM> and <NUM> couple the processors to respective memories, namely a memory <NUM> and a memory <NUM>, which may be portions of system memory (e.g., DRAM) locally attached to the respective processors. First processor <NUM> and second processor <NUM> may be coupled to a chipset <NUM> via P-P interconnects <NUM> and <NUM>, respectively. As shown in <FIG>, chipset <NUM> includes P-P interfaces <NUM> and <NUM>.

Furthermore, chipset <NUM> includes an interface <NUM> to couple chipset <NUM> with a high performance graphics engine <NUM>, by a P-P interconnect <NUM>. As shown in <FIG>, various input/output (I/O) devices <NUM> may be coupled to first bus <NUM>, along with a bus bridge <NUM> which couples first bus <NUM> to a second bus <NUM>. Various devices may be coupled to second bus <NUM> including, for example, a keyboard/mouse <NUM>, communication devices <NUM> and a data storage unit <NUM> such as a disk drive or other mass storage device which may include code <NUM>, in one example. Further, an audio I/O <NUM> may be coupled to second bus <NUM>. Any of the devices shown in <FIG> may be configured to control intra-device communications between non-master devices in which one of the devices drives a clock signal for one or more of the interconnect structures, as described herein.

Note that the terms "circuit" and "circuitry" are used interchangeably herein. As used herein, these terms and the term "logic" are used to refer to alone or in any combination, analog circuitry, digital circuitry, hard wired circuitry, programmable circuitry, processor circuitry, microcontroller circuitry, hardware logic circuitry, state machine circuitry and/or any other type of physical hardware component. Examples may be used in many different types of systems. For example, in one example a communication device can be arranged to perform the various methods and techniques described herein.

Claim 1:
An apparatus comprising a first slave device (140A..140C), the first slave device (140A..140C) comprising:
a first receiver (<NUM>) to receive a clock signal from a multi-drop interconnect;
a second receiver (<NUM>) to receive a data signal from the multi-drop interconnect;
a peer-to-peer, P2P, control circuit (<NUM>) to issue a P2P communication request to a bus master (<NUM>) of the multi-drop interconnect to request authorization to send a P2P transaction to at least one second slave device (140A..140C) coupled to the multi-drop interconnect;
a first transmitter to transmit the P2P transaction to the at least one second slave device (140A..140C) when the bus master (<NUM>) grants the authorization for the P2P transaction; and
a second transmitter to output the clock signal to the multi-drop interconnect during the P2P transaction.