Slave side bus arbitration

A method includes, in response to a master port requesting bus access for a bus transfer with a slave port, selecting the master port to allow a master device that is coupled to the master port to perform a bus transfer with a slave device that is coupled to the slave port. The bus transfer is associated with at least one bus cycle. The method includes, in response to an end of the bus transfer, maintaining selection of the master port for at least one additional bus cycle.

BACKGROUND

A computer system may include interconnection fabric, or a bus, for purposes of communicating data between initiating bus devices called “masters” (processor cores and direct memory access (DMA) engines, for example) and target bus devices, or “slaves” (memory devices, for example). In a typical bus operation, a master initiates a bus transfer (such as a bus transfer to read or write data) with a given slave by driving appropriate address signals onto the bus to target the slave, along with the appropriate control signals and data signals (if data is being written to the slave). The slave that is the target of the bus transfer responds by generating the appropriate signals onto the bus for such purposes as transferring data to the master; receiving data from the master; indicating an error; or signaling the master to retry the bus transfer.

The bus is a limited system resource, which typically couples a single master to a single slave at any one time. Therefore, when multiple masters concurrently contend for access to the same slave, the system typically time-multiplexes bus transfers by these masters with the slave by applying an arbitration policy.

SUMMARY

In an example embodiment, a method includes, in response to a master port requesting bus access for a bus transfer with a slave port, selecting the master port to allow a master device that is coupled to the master port to perform a bus transfer with a slave device that is coupled to the slave port. The bus transfer is associated with at least one bus cycle. The method includes, in response to an end of the bus transfer, maintaining selection of the master port for at least one additional bus cycle.

In another example embodiment, an apparatus includes a plurality of master ports, which include a given master port; a plurality of slave ports; a bus layer that is associated with the given master port; a demultiplexer and a slave side arbiter device. The demultiplexer has a bus layer input that is coupled to the bus layer and a plurality of bus layer outputs. Each bus layer output is associated with a different slave port of the plurality of slave ports. The slave side arbiter device is associated with a given slave port of the plurality of slave ports to, in response to granting of a request associated with the given master port to perform a bus transfer with the given slave port, causes the given slave port to be coupled to the bus layer output of the demultiplexer associated with the given slave port and maintain coupling of the given slave port to the bus layer output associated with the given slave port for at least one bus cycle after the bus transfer.

In yet another example embodiment, an apparatus includes an integrated circuit that includes a bus interconnect matrix. The bus interconnect matrix includes a plurality of master ports, a plurality of slave ports, bus connection fabric and an arbiter. The arbiter selects a given master port of the plurality of master ports. The given master port is coupled to a master device, and the given master requests bus access for a bus transfer with a given slave port of the plurality of slave ports. The bus transfer is associated with at least one bus cycle. The arbiter maintains selection of the given master port for at least one additional bus cycle after an end of the bus transfer.

Advantages and other desired features will become apparent from the following drawings, description and claims.

DETAILED DESCRIPTION

An electronic system may include various master devices, such as processing cores, direct memory access (DMA) engines, and so forth, which perform bus transfers with various slave devices (volatile memory devices, non-volatile memory devices, other peripheral devices, and so forth) of the system for purposes to storing and retrieving data and instructions. Slave side bus arbitration-based techniques and systems are disclosed herein for purposes of enhancing system performance for such bus transfers.

Referring toFIG. 1, an electronic system10may include a microcontroller unit (MCU)24and various components70that are controlled by the MCU24. As examples, the components70may include one of more of the following depending on the particular application: an electrical motor, a household appliance, an inventory control terminal, a computer, a tablet, a smart power meter, a wireless interface, a cellular interface, an interactive touch screen user interface and so forth. All or part of the components of the MCU24may be part of an integrated circuit (IC), or semiconductor package30. For example, all or part of the components of the MCU24may be fabricated on a single die or on multiple dies (a multi-chip module, for example) of the semiconductor package30.

As discussed in further detail below, the MCU24includes a bus interconnect matrix (BIM)200, which contains bus fabric for performing bus transfers (read and write operations, for example) between bus master devices44(a processing core, a DMA engine, and so forth) and bus slave devices (volatile memory devices, non-volatile memory devices, peripheral devices, and so forth) of the MCU24. The BIM200may be an Advanced High-speed Bus (AHB), in accordance with example embodiments. As described further herein, a slave side arbiter201of the BIM200regulates bus interconnections between the master44and slave40devices in a manner that limits slave device idle time.

Referring toFIG. 2, in accordance with an example embodiment, the MCU24includes such master devices44, as a processing core150and a DMA engine204. As an example, in some embodiments, the processing core150may be a 32-bit core, such as the Advanced RISC Machine (ARM) processing core, which executes a Reduced Instruction Set Computer (RISC) instruction set. In further example embodiments, the processor core150may be a more powerful core or a less powerful core, such as an 8-bit core (an 8051 core, for example). In general, the processing core150and DMA engine204communicate with such slave devices40of the MCU24, as one or more non-volatile memory devices260(Flash memory devices, for example), and volatile memory devices262and264(static random access memory (SRAM) memory devices, for example).

It is noted that the MCU24may contain master devices and slave devices other than the ones depicted inFIG. 2, in accordance with further example embodiments. For example, the slave devices may include components other than memory storage components, such as, as examples, a math accelerator; components that receive analog signals, such as analog-to-digital converters (ADCs) or comparators; components that are external to the MCU24; and digital components, such as, as examples, a Universal Serial Bus (USB) interface, a universal asynchronous receiver/transmitter (UART), a system management bus (SMB) interface, a serial peripheral (SPI) interface, and so forth. Moreover, as depicted inFIG. 2, the slave devices44may include such additional devices as a bridge266. For example, in accordance with some embodiments, the bridge266may couple the BIM200to a lower speed Advanced Peripheral Bus (APB) (not shown), which is coupled to peripheral devices (not shown) that operate at relatively slower speeds, as compared to the slaves40.

The BIM200may be an integrated circuit (fabricated on a single die or on multiple dies, for example); and in further embodiments, the BIM200may be a set of integrated circuits. Depending on the particular embodiment, the BIM200may be entirely formed from hardware components or may be formed from a combination of hardware and software.

For the example embodiment ofFIG. 2, the BIM200contains master ports248(specific master ports M0and M1being depicted inFIG. 2) that are coupled to the processing core150and the DMA engine204. In this manner, each master device44communicates address, control and data signals of an associated layer205with a corresponding master port248. InFIG. 2, the processor core150is shown as being coupled to the M0master port248. A given master device44may be assigned multiple master ports248. In such a case, each bus port of the master device44may be coupled to individual master ports248. The master ports of a given master device44may also be multiplexed and then coupled to one or more of the master ports248, in accordance with further example embodiments.

The BIM200further contains slave ports252(specific slave ports S0, S1, S2and S3being depicted inFIG. 2), which are selectively coupled to address, control and data signals of the slave devices401; and the BIM200further contains bus connection fabric203, which represents the bus communication paths and circuitry that couple the master248and slave252ports together to allow bus transfers to occur.

More specifically, a given master device44, such as the processing core150, may assert (drive high, for example) a bus request signal (part of an address and control bus phase of a bus transfer) to request access to the bus connection fabric203for a bus transfer with a given slave device40, and the master device44may also provide (as part of the address and control phase) a corresponding address that identifies a particular slave port252that is the target of the requested bus transfer. In accordance with example embodiments, the particular slave port252that is the target of a given request may be identified by decoded higher order address bits, as represented by address signals that are furnished by the master device44.

In addition to providing the address and requesting bus access during the address and control phase, a master device44may also provide control signals, which indicate the particular transfer (read operation, write operation, and so forth), the width of the transfer, whether the transfer is a burst operation, and so forth. In addition to the address and control phase, the bus transfer includes a data phase, which spans one or more bus cycles for purposes of transferring data from a master device44to a slave device40, or vice versa.

Multiple master devices44may attempt to concurrently access the same slave port252. For example, the processing core150and the DMA controller204may concurrently contend for bus access to the same slave port252for purposes of reading/writing data to/from a memory device that is coupled to the targeted slave port252. To arbitrate such concurrent requests (i.e., to decide which master device44of several master devices44contending for access is granted access to the slave port252), the BIM200includes a slave side arbiter201, which may be distributed among the slave ports252, as further described herein.

In accordance with example embodiments, the arbiter201applies an arbitration policy, such as a time-multiplexed arbitration policy (an arbitration policy generally based on round robin-based arbitration, priority-based arbitration or a policy that takes into account a combination of fairness and priority, as examples) among multiple master devices44that are requesting the same slave port252for purposes of selecting which master device44may access the slave port252. Due to the ability of the BIM200to form multiple, concurrent master-slave connections, concurrent, or parallel, accesses are allowed between pairs of masters and slaves, in accordance with example embodiments.

Referring toFIG. 3, in accordance with example embodiments, the arbiter201arbitrates and controls connections between N master devices (master devices44-1,44-2. . .44-N, being depicted as examples inFIG. 3) and M slave devices40(slave devices40-1,40-2. . .40-M, being depicted as examples inFIG. 3). As depicted inFIG. 3, the arbiter201may be distributed among the slave ports252as slave slide arbiter devices318, as each slave port252may have an associated slave side arbiter device318that controls bus connections for the associated slave port252.

For a given master device44to request access for a bus transfer with a given slave port252, the master device44asserts its associated bus request signal on a communication line of the associated layer205and also provides the address signals to the layer205. As depicted inFIG. 3, each master port248of the BIM200has an associated input stage304. A decoder310that is coupled to the input stage304and is associated with the master port248decodes the upper address bits of the provided address for purposes of identifying the particular slave port252that is targeted by the master device44. The decoder310provides the appropriate signal(s) to a demultiplexer312to couple the layer205associated with the master device44to a multiplexer316that is associated with the targeted slave port252. In this manner, the demultiplexer312has an input layer205and multiple output layers, where each output layer is associated with a different slave port252.

In accordance with example embodiments, multiple master devices44may be concurrently contending for access to the same slave port252. In other words, several master devices44may assert their associated bus request signals at the same and be targeting the same slave port252. For example, master devices44-1and44-N ofFIG. 3may, at a given time, both be asserting (driving high, for example) their bus request signals, which causes the layer205for each master device44-1,44-N to be coupled to different inputs of the multiplexer316for the same slave port252.

In accordance with example embodiments, each multiplexer316is controlled by an associated slave side arbiter device318, and for the scenario in which multiple master devices44are contending for access to the same slave port252, the arbiter device318applies a time-multiplexed-based arbitration policy to select one of the associated master ports248and thus, decide which layer205is coupled to the port252.

In accordance with example embodiments, when a particular slave device40is not being accessed by any master device44, the slave device40may conserve power by entering an idle state in which the device44gates (tri-states, for example) at least some of its output signals and/or otherwise reduces circuit activity of the device44. Correspondingly, the associated slave side arbiter device318may be constructed to introduce a wait state (one bus cycle, for example) before reengaging a new master device44to allow the slave device40to exit the idle state. For the case in which a given master device44is communicating back and forth between different slave devices40(and slave ports252) in a connected series of data transfers, a number of such wait state delays may accumulate while the transfer occurs.

For example, in accordance with example embodiments, a given master device44may perform a series of data transfers between a volatile memory device (one slave device40coupled to one slave port252) and an SPI peripheral device (another slave device40coupled to another slave port252) through several rounds of “ping ponging” bus transfers in which, for each round, the master device44uses a bus transfer to read data from the volatile memory device and uses another bus transfer to write the read data to the SPI peripheral device.

In accordance with example embodiments disclosed herein, the slave side arbiter device318prevents its associated slave device40from entering an idle state for such a connected series of data transfers by applying the following arbitration rule: selection of a previously-selected master port248is maintained for an additional one or multiple bus cycles. Thus, the slave port252remains coupled to the demultiplexer312associated with the selected master port248.

FIG. 4depicts a state diagram400used by the slave side arbiter device318, in accordance with example embodiments. Referring toFIG. 4, in accordance with example embodiments, the slave side arbiter device318, when no master port248is selected, remains in an idle state402. The arbiter device exits the idle state402in response to one or more master ports248requesting a bus transfer with the associated slave port252. In response to the arbiter device318selecting a new master port248based on an arbitration policy, the arbiter device318transitions from the idle state402to a state404. In state404, the arbiter device318asserts the grant line associated with the selected master port248and configures the bus connection fabric for the selected master port248, i.e., the arbiter device318causes the associated multiplexer316(FIG. 3) to couple its slave port252to the appropriate demultiplexer312. At the end of the bus transfer, as depicted inFIG. 4, the arbiter device318transitions from the state404to a state408in which the arbiter318maintains selection of the previously selected master ported device for one or multiple additional bus cycles. In other words, the slave port252remains coupled to the demultiplexer312for the selected master port248, even if the associated master44is no longer requesting the slave port252. During the maintaining of the selection, the arbiter device318keeps the grant line associated with the master port248asserted.

In accordance with example embodiments, the arbiter device318may remain in the state408for a delay such as four to twelve bus cycles, although other delays may be imposed, in accordance with further example embodiments. It is noted that while the master port248remains selected, the associated master device44may perform a bus transfer with another slave port252, as the selection of a given master port248by one slave side arbiter device318does not preclude another slave side arbiter device318from selecting the same given master port248. At the end of the delay imposed in the state408, the arbiter318transitions from the state408back to the idle state402.

In accordance with example embodiments, the arbiter device318may include a counter (a three bit counter, for example), which the arbiter device318uses to measure the delay. For example, the counter may be clocked by a signal that cycles once per bus cycle for purposes of measuring a given number of bus cycles (eight bus cycles, for example), before indicating expiration of the delay by the overflowing or resetting of the counter, for example. The arbiter device318may measure the delay using other circuits/techniques, in accordance with further example embodiments.

Thus, due to the intermediary state408between states404and402, time otherwise consumed in deselecting and reselecting a given master port is avoided, thereby inhibiting slave device idle time for certain connected data transfers and potentially increasing the efficiency of data transfers within the MCU24. Maintaining selection of the master port for up to N additional bus cycles may have specific advantages, in accordance with example embodiments, such as increasing system performance while incurring a minimal current consumption increase.

Referring toFIG. 5, thus, in accordance with example embodiments, a technique500includes selecting (block504) a master port in response to the master device that is coupled to the master port requesting bus access for a bus transfer with a slave port. Pursuant to the technique500, in response to the end of the bus transfer, the technique500includes maintaining selection of the master port for at least one additional bus cycle.

Referring toFIG. 6, the MCU24may be used in numerous different applications. As an example,FIG. 6depicts a motor control application in which an MCU24of a motor control system600generates/receives input and output signals (I/O signals) for purposes of controlling a motor674. In this manner, the MCU24may generate signals at its I/O terminals650for purposes of communicating with a motor interface670(an interface containing drivers, sensors, and so forth); and in connection with this communication, the I/O terminals650may communicate waveforms with the motor interface (pulse width modulation (PWM) signals, for example), receive sensed currents and voltages, communicate data via one or more serial buses, and so forth. I/O terminals640of the MCU24may generate/receive signals to communicate with a user control interface676of the system400for such purposes as communicating status of the motor674or motor interface670, communicating detected fault conditions, receiving user-directed commands and signals, and so forth.

While a limited number of embodiments have been disclosed herein, those skilled in the art, having the benefit of this disclosure, will appreciate numerous modifications and variations therefrom. It is intended that the appended claims cover all such modifications and variations.