Shared devices and memory using split bus and time slot interface bus arbitration

[0002] 1. Field of the Invention

[0003] This invention relates generally to time division multiplexed (TDM) digital systems. More particularly, it relates to arbitration methods and apparatus in an extended digital system.

[0004] 2. Background of Related Art

[0005] Numerous digital devices are utilized by consumers throughout the world. In each of these devices, digital samples are passed between individual components, often using time division multiplexed (TDM) techniques over serial and/or parallel busses between the components. Arbitration for use of a system bus for passing these digital samples is typically controlled by an arbiter responsible for the system bus.

[0006] A TDM data stream typically comprises a repeating data cycle or frame, with each data frame being divided into a plurality of time slots. The data frame repeats over and over, but typically with new data samples in relevant time slots for each new cycle or frame of data. The data frames are conventionally synchronized with a frame synchronization signal or similar signal.

[0007] In a more general sense, time slots can relate to the time-shared usage of a system bus, e.g., a 32 bit parallel system bus. During an assigned time slot, a particular device can make exclusive use of the system bus up to the length of time allowed by a pre-determined configuration.

[0008] Time slots may be of any particular length, and separate time slots in a particular data frame may have different lengths.

[0009] Depending upon the needs of a particular application, conventional input and output channels of TDM system buses typically have fixed locations within a data frame assigned by a master controller or processor in the system.

[0010] A significant amount of flexibility can be provided using a time slot which may be used by any of a plurality of devices. For instance, if one particular device on a system bus requires a significant amount of time (and thus a long time slot) to perform a particular activity, then it would conventionally request bus access from the master controller. The conventional master controller assigns use of the TDM system bus in accordance with a given set of arbitration rules, e.g., a round-robin allocation, or an interrupt driven access request resulting in a first come, first served allocation.

[0011] The more flexibility in the use of a TDM system bus, the wider the market applications. In conventional systems, the designer typically implements this flexibility within the program code of the master controller of the system. In such systems, the master controller or processor allows access to a TDM system bus in accordance with its established arbitration rules. Flexibility is provided in such conventional devices by allowing the controller to change the length of access for any particular requesting device as desired.

[0012] Conventional system bus arbitration requires substantial resources or overhead of the master controller, which only increase as the complications of the system become greater. This is particularly true in multiple processor based systems, where communication data traffic between the processors increases as requests for access to the arbitrated system bus increase. Moreover, as the size of systems increases and as the number of agents on a particular system bus grows, the arbitration processing becomes enormous. This increased overhead results in a decreased amount of processing available for other tasks.

[0013] Conventional system arbiters exist, but are typically a priority-based super arbiter inside a super core or microcontroller.

[0014] There is thus a need for a more flexible arbitration architecture allowing use of a TDM system bus without requiring the significant overhead otherwise conventionally required in a master controller.

[0015] In accordance with the principles of the present invention, apparatus for arbitrating access to a data bus comprises a priority-based arbiter associated with a first portion of a data bus. A time slot arbiter is associated with a second portion of the data bus. An isolation device isolates the first portion of the data bus from the second portion of the data bus allowing, when isolated, the priority-based arbiter to control access to the first portion of the data bus and the time slot arbiter to control access to the second portion of the data bus.

[0016] A method of arbitrating access to a common data bus from a plurality of bus masters in accordance with another aspect of the present invention comprises separating the common data bus into two isolated portions. The first isolated portion of the common data bus is arbitrated based on a priority of each requesting bus master on the first isolated portion of the common data bus. The second isolated portion of the common data bus is arbitrated based on time slot assignments of each bus master on the second isolated portion of the common data bus.

[0017] Features and advantages of the present invention will become apparent to those skilled in the art from the following description with reference to the drawings, in which:

[0018] FIG. 1 shows the use of two distinct arbiters on a common bus, wherein the bus is separable using, e.g., a tri-state buffer device, under the control of a PTSI arbiter, in accordance with the principles of the present invention.

[0019] FIG. 2 shows an exemplary split bus architecture which combines hardware and software functionality to provide programmable time slot arbitration, in accordance with the principles of the present invention.

[0020] FIG. 3 shows memory sharing and overlap wherein on-board memory is segmented into unshared memory and shared memory with or without overlapping sections.

[0021] FIG. 4 is a more detailed block diagram of a monitoring arbiter circuit (MONARC) responsible for arbitration on its portion of the bus except during a special time slot wherein the tri-state buffer connects the two portions of the bus and returns arbitration control back to the super arbiter, in accordance with the principles of the present invention.

[0022] FIG. 5 is a timing diagram showing exemplary time slots in each of a series of system cycles using a programmable time slot interface (PTSI) bus arbitration concept based on the use of a hierarchical bus cycle definition, in accordance with the principles of the present invention.

[0023] FIG. 6 is a block diagram of a platform circuit useful in many applications, including in the example application of a Asynchronous Digital Subscriber Loop (ADSL) capable device, in accordance with the principles of the present invention.

[0024] FIG. 7 is a more detailed block diagram of the platform circuit shown in FIG. 6.

[0025] The present invention provides a programmable time slot interface (PTSI) bus arbiter and monitor separate from a super arbiter associated with a controller of a typical system. The PTSI arbiter offloads arbitration overhead from a controller system, particularly as the number of devices on the system bus grows, and provides a programmable alternative to existing methods such as fixed round-robin or interrupt priority based allocation.

[0026] In conventional digital systems which arbitrate from a single arbiter for use of time slots, the main controller typically handles arbitration and bus allocation tasks. In the preferred embodiment, a separate arbiter (i.e., the PTSI arbiter and bus monitor) is connected outside or external to a main controller (e.g., microcontroller, microprocessor or digital signal processor (DSP)), and thus removes the burden of arbitration and bus management, therefore freeing up valuable processing power of the main controller. Aspects relating to the use of two arbiters are disclosed in the present invention, as are adaptive methods and apparatus relating to the use of a history buffer to adaptively adjust the assignment of time slots by an arbiter.

[0027] The Programmable Time Slot Interface (PTSI) bus arbitration scheme has particular application with multiple processor systems, and in particular with “platform” system-on-a-chip devices that incorporate multiple bus masters and a shared communication bus. These “platform” chips are typically intended to serve multiple market applications. Consequently, they need to be flexible and extendable. In such devices, the ability to add or delete IP blocks capable of bus mastering is important, which becomes further complicated by the need to divide the shared bus bandwidth to accommodate system performance requirements.

[0028] The use of two (or more) arbiters on a common system bus is also particularly attractive for systems that consist of a mixture of cached controllers/processors, bus master-capable peripherals (DMA and external network interfaces), and/or slave peripherals (memory, timers).

[0029] In accordance with the principles of the present invention, a second arbiter (i.e., the PTSI arbiter) provides an on-chip bus arbitration system separate from the controller or controllers in the system. The system may be a single chip, or may be a plurality of integrated circuits on a printed circuit board (PCB). The PTSI arbiter programmably allocates time-slots for a shared TDM parallel bus among multiple bus masters (e.g., processors or agents).

[0030] If a particular agent does not currently require control of an allocated time slot, the PTSI arbiter is capable of adaptively re-allocating the relevant time slot for use by another bus master. This makes the shared bus usage adaptive to the data flow needs of the system in real time. This also allows for external bus mastering devices (i.e. co-processors) to share an external memory interface with internal agents.

[0031] The PTSI arbiter includes multiple PTSI configuration register sets (e.g., registers A & B) to allow the allocation of available time slots to be changed “in-situ”.

[0032] Preferably, bus cycle hierarchy can be used to create a system cycle from which statistics can be gathered and dynamic configuration register set swapping can be accomplished.

[0033] FIG. 1 shows the use of two distinct arbiters on a common bus, wherein the bus is separable using, e.g., a tri-state buffer device, under the control of the PTSI arbiter, in accordance with the principles of the present invention.

[0034] Two arbiters do not necessarily communicate with one another. For instance, the described monarc arbiter “jams” the tri-state buffer to electrically separate the two portions of the split system bus, e.g., eASB from the iASB. Then, if the processor needs access to the eASB memory space, it will attempt that access but get an error condition, and act on that error condition by activating an interrupt service routine. The interrupt service routine will request that the monarc arbiter freeze its state and “unjam” the tri-state buffer. This can be referred to as “pre-emption”.

[0035] In particular, in FIG. 1, a super arbiter 142 is associated with a system bus of a controller 140. The controller and its system bus (referred to as, e.g., the internal iASB bus) may have associated peripherals. The present invention includes a tri-state mechanism 197 connected to the system bus of the controller 140. In the disclosed embodiment, the tri-state mechanism is associated with an external socket (EIC Socket) into which an external bus may be connected.

[0036] A second arbiter (the MONitor ARbiter Circuit MONARC) 134 is connected to an added or second portion of the common system bus, referred to as an external eASB bus. The MONARC may have a plurality of devices or agents connected to the eASB, for which the MONARC has arbitration responsibility. Other busses and communication paths exist between the arbiters and peripherals (as will be shown in FIG. 7), but which are not shown in FIG. 1 for simplicity of explanation.

[0037] FIGS. 2 and 3 show the handling of external devices and/or shared memory in general using a split bus architecture and time slot arbitration, in accordance with the principles of the present invention.

[0038] With ever emerging new technologies and shrinking feature sizes, it has become possible to integrate a tremendous amount of functionality into a single integrated circuit, thus providing a system-on-a-chip solution. Associated with such a solution are problems of sharing bus bandwidth, bus arbitration among multiple bus masters, developing a scalable architecture and providing means for sharing and overlapping memory among various chips on a single Printed Circuit Board. The proposed architecture allows the main microcontroller on the chip to function efficiently by relieving it of tasks relating to maintaining data flow and bus arbitration.

[0039] Chip architectures that are microcontroller/DSP based typically place the burden of controlling bus traffic and handling data flow through the system on the main microcontroller/DSP. As a result, the main controller may lose valuable MIPS in responding to individual interrupt requests from peripherals, and/or shuffling data around. Interrupt driven architectures offer less flexibility in terms of adding new blocks or replacing existing blocks due to varying interface requirements. Complex bus arbitration schemes to handle multiple bus masters could end up locking the main controller or some of the other bus masters off the bus, thus causing failure of the entire system.

[0040] FIG. 2 shows an exemplary split bus architecture which combines hardware and software functionality to provide programmable time slot arbitration, in accordance with the principles of the present invention.

[0041] In particular, as shown in FIG. 2, Arbiter1 (i.e., Super Arbiter) 142 is a priority-based arbiter, and Arbiter2 (i.e., MONARC Arbiter) 134 is a programmable time slot arbiter, both functioning in accordance with the principles of the present invention.

[0042] Each agent (i.e., each bus master 295, 297) is allotted a time slot during which it can transfer data to or from off-chip/on-board memory 107 without interrupting the controller 140. However, the controller 140 always has the ability to interrupt the data transfer whenever it needs access to the bus.

[0043] External devices 112 can request access to the off-chip, shared memory bus, and share overlapping regions of the external memory 107.

[0044] A socket 197 connects an internal bus to an external bus when the microcontroller 140 needs to access off-chip memory 107. As long as the microcontroller 140 accesses internal peripherals 291 and internal memory 293,the socket 197 disconnects the internal bus and the external bus. Arbiter2134 can then take control of the external bus and allocate time slots for granting the external bus to each of the other bus masters 295, 297.

[0045] Arbiter2134 can also accept requests from external devices 112 for access to the memory bus. Each external device 112 is allotted a time slot in the entire arbitration scheme. When the external device 112 requires access to the off-chip memory 107,it generates a request which is fed to Arbiter2134. During the external device's time slot, Arbiter2134 generates a bus grant to the external device 112 and a control signal to tri-state the pins of the memory interface 124 to allow the external device 112 access to the shared external memory 107.

[0046] The microcontroller 140 must set up a memory map to allocate regions of the external memory 107 for the bus masters 295, 297, data storage, code storage and external devices 112. The external device 112 could be any suitable device utilizing the common memory bus, e.g., a hardware accelerator, a co-processor, a digital signal processor (DSP) or other processor device (e.g., a microprocessor or a microcontroller).

[0047] On receiving a bus grant, the external device 112 can access its allocated memory space, complete the required data processing, and de-assert its bus request when finished.

[0048] Also, the external device can send a feedback signal 299 to the microcontroller 140 which may be used, e.g., to trigger an interrupt into the microcontroller 140. Since the feedback signal 299 indicates completion of a particular activity, the microcontroller 140 can thereafter access the results, e.g., from the relevant allocated portion of the external memory 107. This provides an efficient way for intelligent devices to co-exist and share a common memory bus.

[0049] Shared memory has many practical uses, e.g., for sharing code and/or data among various devices on a circuit board and/or to facilitate communication between various devices. Extending the same concept, Arbiter2134 can handle requests from multiple external devices 112 for the memory bus. This provides external devices 112 access to the off-chip, external memory 107.

[0050] FIG. 3 shows memory sharing and overlap wherein on-board external memory 107 is segmented into unshared memory portions and shared memory portions, with or without overlapping sections.

[0051] In particular, as shown in FIG. 3, when an external device 112, 114 requires control over the memory bus, it generates a request to Arbiter2134 and is granted the bus during its pre-programmed time slot. During this assigned time slot, any device currently given control of the bus by the Arbiter2134 and any other external devices 112, 114 sharing the common memory bus preferably tri-state their memory bus pins so that the newly requesting external device can exclusively access shared or overlapped memory regions.

[0052] In accordance with the principles of the present invention, new hardware modules can be tested on a test circuit board using shared external memory before being permanently implemented in a fabricated integrated circuit chip.

[0053] FIG. 4 is a more detailed block diagram of a monitoring arbiter circuit (MONARC) 134 responsible for arbitration on its portion of the bus except during a special time slot wherein the tri-state buffer connects the two portions of the bus and provides arbitration control back to the super arbiter, in accordance with the principles of the present invention.

[0054] In particular, in FIG. 4, an exemplary MONARC arbiter 134 includes two main sub-blocks: the eASB arbiter 200 and the eASB bus monitor 202.

[0055] The eASB arbiter 200 accepts bus request inputs from its serviced peripherals, and also arbitration parameters stored in the configuration registers (which drive counters), and grants ownership of the eASB accordingly.

[0056] The eASB bus monitor 202 snoops transactions on the eASB bus and collects historical information and/or bus usage statistics which can be used by the controller 140 to adaptively re-tune the arbitration parameters of the added MONARC arbiter 134. Changes to the arbitration parameters of the MONARC arbiter 134 are allowed when the tri-stated portions of the system bus are re-connected during a special time slot allowing the super arbiter 142 arbitration control of the entire common system bus (i.e., the iASB and eASB).

[0057] The master controller 140 (e.g., an ARM940T) is tightly coupled with the MONARC arbiter 134 in this implementation wherein the controller supercore includes an internal super arbiter 142 which is dovetailed with the programmable time slot nature of the MONARC arbiter 134. The arbitration configuration registers of the MONARC can be accessed by the controller 140 through a separate bus communication mechanism, e.g., through an APB interface available in the ARM940T device.

[0058] The eASB bus monitor 202 is adjunct to the eASB arbiter 200 as shown in FIG. 4. The eASB bus monitor 202 may include a time slot history buffer 208.

[0059] The time slot history buffer 208 stores information regarding past bus transactions for some or all time slots. For instance, information regarding the last three, or the last ten transactions can be saved in the time slot history buffer 208. Thus, using information obtained by the eASB bus monitor 202 and obtained by the time slot history buffer 208,an additional set of registers may be included to compile statistics on shared bus usage for one, some or all time slots.

[0060] In particular, the disclosed time slot history buffer 208 is a set of registers capable of storing the address, data, control signals and aribter status regarding past eASB transactions, e.g., is selectable based on the size of the hardware buffer that is designed into the device. This historical information can be used to generate a trigger signal for a peripheral device (either connected to the eASB, the iASB, or external to the entire system) based on eASB bus activity.

[0061] The time slot history buffer 208 may also contain registers relating to statistics obtained by the MONARC arbiter 134 over many (e.g., millions) of system cycles. This info can be used by the controller 140 (or system user) to optimize the arbitration and time slot parameters used to control the MONARC arbiter 134.

[0062] In the disclosed embodiment, the monarc arbiter 134 includes a redundant set of time slot configuration registers. The redundant sets (A & B) of time slot configuration registers allows one set of registers to be used by the MONARC arbiter 134 while the other set is being written to by the controller 140. Thus, e.g., a new set of time slot parameters can be written into configuration register set B 224, while the MONARC arbiter 134 is functioning based on parameters previously stored in configuration register set A 220. A hardware interlock device may be provided to prevent access to the active configuration register set. In an alternative embodiment, a double buffering scheme can be used to allow one set to be written and pre-loaded while the previous values are used.

[0063] Historical information may be used in an adaptive fashion by the master controller 140 of the system to improve system performance and perhaps power consumption. The history buffer is also useful for system debugging. In this case, the user can take advantage of the resident controller 140 to process the statistical/historical information obtained by the monarc arbiter 134 to modify the PTSI arbitration or other system parameters relating to the arbitration rules used by the monarc arbiter 134 (such as clock enables or memory allocation) to improve performance.

[0064] Triggering conditions can be added to the time slot history buffer 208 to allow an internal eASB bus transaction to set external event flags (or Bit I/O signals) to be used by an external device.

[0065] A programmable address filter 210 may optionally be used at the front end of the time slot history buffer 208 between the eASB bus and the time slot history buffer 208,to allow the ability to restrict the address range of captured bus transactions.

[0066] In the disclosed embodiment, the user can program the configuration registers for the monarc arbiter 134. This is done in the disclosed embodiment with an alternating pair comprising of a first configuration register set (e.g., Register Set A) and a second configuration register set (e.g., Register Set B). While one of the register sets is in use, the other may be accessed by the master controller or other system device to adjust the time slots for accessing a relevant TDM system bus in the system. Thus, first the inactive set of registers is programmed, and then the active set of registers is switched by command from the controller 140. Reprogramming of arbitration parameters at least with respect to the eASB allows the user of the system to dynamically tune allocation of the eASB for better efficiency. Once one time slot configuration register set 220, 224 is swapped in or becomes active, the other configuration register set becomes available for modification and future use. In this way, the time slot parameters relating to arbitration on the eASB portion of the common system bus may be reconfigured as desired, as often as once per system cycle.

[0067] For instance, in the disclosed embodiment, the user is able to swap time slot configuration register sets 220, 224 at the end of any system bus cycle. Although capable of being reconfigured each system cycle, this ability to dynamically change the construction of the system bus and agent bus cycle is intended to be used after many system bus cycles (i.e., preferably not on a per system cycle basis—because of the added overhead).

[0068] A user can change the system bus cycle to match different real time processes in the overall system. The user can do this based on a priori knowledge of the software flow, or through a more adaptive process that uses some of the statistics compiled by the monitor.

[0069] Exemplary contents for the programmable time slot configuration register sets A & B 220, 224 are shown in Table 1. In Table 1, the PTSI System Parameters refer to exemplary higher level parameters that are used to construct the system cycle, and in Table 2 the PTSI Agent Time Slot Parameters refer to exemplary lower level parameters used to define the length of each time slot.

[0070] In the deterministic mode, each time slot is automatically given and they last the max pre-programmed length. The time allocated and the latency for the system cycle to return back to each agent time slot is pre-determined.

[0071] In the adaptive mode, a time slot is granted to an agent only if it is requested, and an agent can terminate the use of its allocated time cycle prior to the max time. In this case, the system cycle has an accordion like behavior which is dictated by the demands of the data flow through the data ports.

[0072] The number of agent time slots refers to the programmable number of time slots in each system cycle. Each agent of the eASB bus can be programmed to 0, 1 or more time slots within a given system cycle.

[0073] The number of agents refers to the number of dataports, i.e. universal serial bus (USB), Ethernet media access controller (MAC), peripheral components interface (PCI), high speed serial input/output (HSIO) and other bus master capable devices that are attached to the eASB bus and governed by the MONARC arbiter.

[0074] The time slot sequence (agent IDs) refers to the programmable order in which the agent time slots occur.

[0075] The number of unit cycles per system refers to the lowest level bus clock cycle. Many unit cycles are selected to make up an agent time slot. Many agent time slots are selected to make up a system cycle.

[0076] Other register values, e.g., PTSI Agent time slot parameters, may be as shown in Table 2.

[0077] The number of completion unit cycles for each agent time slot refers to a certain number of unit cycles which can be programmed at the end of each agent cycle to allow for the agent to complete a bus transaction prior to giving up the bus because the arbiter is moving on to the next time slot.

[0078] The eASB bus monitor shown in FIG. 4 may further include statistics registers 204. The statistics gathered by the bus monitor are updated to the statistics registers 204, which are readable by the master controller 140. The statistics become valid at the end of every system bus cycle (in the MONARC update time slot). The statistics maintained in the statistics registers 204 can be reset or initialized at the end of every system bus cycle. Statistical information in conjunction with the time slot related parameters used in the configuration registers can be used to characterize the efficiency of the programmed PTSI values that were used for a given application.

[0079] Table 3 contains some exemplary statistics that can be maintained by the eASB bus monitor 202 in the statistics registers 204:

[0080] The principles of the present invention regarding arbitration and/or internal bus monitoring are applicable to many types of systems, particularly to “system-on-a-chip” devices that use a shared bus architecture. While described with respect to shared use of time slots in a TDM system bus system, the concept has applicability to many other types of applications.

[0081] FIG. 5 is a timing diagram showing exemplary time slots in each of a series of system cycles using the PTSI bus arbitration concept based on the use of a hierarchical bus cycle definition, in accordance with the principles of the present invention.

[0082] In particular, in FIG. 5, at the lowest level the bus is toggled at a unit cycle rate. The unit cycle rate may or may not be tied to the clock speed of one of the bus masters. It is the fastest speed at which the bus signals can be switched. Simulation and special layout considerations must be made to ensure that the loading, parasitics and noise characteristics can support the selected unit cycle rate.

[0083] The second level bus cycle is called the agent time slots. It is the time of bus ownership that is allocated to a given bus master. It is programmable and is based on a given number of unit cycles. As ownership is passed from one bus master agent to another, a protocol is established to ensure that the bus is not simultaneously driven by multiple masters.

[0084] At the top level, the PTSI has a system cycle rate. The system cycle is composed of a programmable number of agent cycles. The completion of a system cycle (or many system cycles) could be used to change the PTSI arbitration parameters stored in the time slot configuration registers 220, 224, and/or to compile/update bus usage statistics. The same agent can appear at many different times (with varying agent cycle lengths) of a system cycle.

[0085] The time slot configuration parameters set in the time slot configuration registers 220, 224 establish the state machine 230 which governs the control of bus ownership and defines the agent time slot and system cycle attributes. Upon reset, the system will be in an initialization state which is suitable for system setup (e.g., the master controller 140 will have ownership of a separate APB bus). The controller 140 uses this APB bus to set the parameters in the time slot configuration registers 220, 224.

[0086] During this initialization, the iASB and eASB bus requests are joined and the super arbiter has access to the entire memory mapped address space.

[0087] After the master controller 140 has setup the desired values into the time slot configuration registers 220, 224,it will set an enable bit which will allow the MONARC PTSI configuration to be invoked. From this point on, the selected set of PTSI values will be used and the designated agents will be given bus ownership in the programmed sequence. The inactive set of configuration registers (e.g., initially the “B set” 224) can be used to set up another PTSI configuration while the first PTSI configuration is running based on the values stored in the “A set” 220. The inactive set of configuration registers can be invoked at the end of any system cycle.

[0088] In the disclosed embodiment, two operational modes of the PTSI state machine 230 are set up.

[0089] For instance, the eASB arbiter 200 can be operated in either a deterministic mode (mode 0) or in an adaptive mode (mode 1).

[0090] Mode 0 is completely deterministic in the time domain. In this mode, each agent cycle lasts the entire programmed duration that is set forth in the active time slot configuration register 220 or 224. In this deterministic mode, each bus master will not only have bus ownership for a fixed amount of time, it will also have a fixed period of time between its bus ownership time slots, regardless of whether it needs to transfer data across the bus during that time slot.

[0091] On the other hand, mode 1 is an adaptive mode which allows round robin—allocation based on received bus request signals. The adaptive mode utilizes bus request input signals from the various agents and other peripherals on the eASB to determine if the next assigned bus master has a need to be allocated the upcoming agent cycle. If it does not, the state machine 230 will go through the programmed system cycle sequence to determine which bus master will be given bus ownership next.

[0092] Once an agent cycle has been assigned to a bus master or agent, it will have ownership until the bus master or agent has removed its bus request signal (before the agent cycle has ended) or for the entire time slot duration that was assigned to it by the configuration registers.

[0093] When an agent cycle is prematurely ended (by bus request removal), the state machine 230 will continue on with the PTSI programmed sequence.

[0094] Thus, the adaptive arbitration mode uses the programmed sequence of time slots and the programmed time slot duration as a maximum amount of time to assign bus ownership in an “as needed” basis, allowing reallocation and improved efficiency during otherwise unused portions of an assigned time slot.

[0095] In the adaptive arbitration mode, the duration of a system cycle varies based upon the demand for the eASB bus. In this mode, the agent time slot limits are setup to ensure that specific agents will be guaranteed a minimum piece of the eASB bandwidth.

[0096] The PTSI scheme in general and the MONARC arbiter 134 in particular can be further explained by describing their function within the context of a proposed chip architecture. To this end, FIG. 6 is a block diagram of a platform circuit useful in many applications, including in the example application of an ADSL capable device, in accordance with the principles of the present invention. FIG. 7 is a more detailed block diagram of the platform circuit shown in FIG. 6.

[0097] In FIGS. 6 and 7,the following definitions and explanations apply.

[0098] The master controller 140 can be any suitable processor or general purpose controller, e.g., a microprocessor, a microcontroller, or a digital signal processor (DSP). In the disclosed embodiment, the master controller 140 is an ARM940T controller, which is a 32 bit microcontroller from an English company called ARM (but can be any general purpose processor or controller). The ARM940T includes a 4 kbyte data cache and a 4 kbyte instruction cache. Of course, any suitable multi-purpose microcontroller or other processor can be used.

[0099] MONARC is an acronym that stands for Monitor Arbiter Circuit.

[0100] The MONARC PTSI scheme refers to the process performed by the MONARC arbiter 134 for ownership of the eASB bus.

[0101] The ARM supercore is a superset of the ARM940T controller and its included functional blocks. In the disclosed embodiment shown in FIGS. 6 and 7,peripherals have been added (e.g., a programmable interrupt controller etc.) and sockets have been added to the bus of the ARM940T controller to form the supercore.

[0102] The External Interface Circuit (EIC) includes the tri-state function to separate the common system bus into a first portion associated with the ARM controller 140 and the super arbiter 142,and a second portion associated with the added MONARC arbiter 134 and associated peripherals for which it has arbitration responsibility. Thus, the EIC includes a tri-state buffer to electrically separate the existing ASB bus of the ARM controller 140 from the portion of the bus relating to the added circuitry, creating a split bus comprising a first portion of the common system bus, i.e., internal to the supercore (iASB), and a second portion of the common system bus, i.e., external to the supercore (eASB). The external interface circuit allows blocks outside of the ARM supercore to be added to the iASB bus of the ARM controller 140.

[0103] When the supercore iASB bus is connected to the eASB, the ARM supercore effectively has direct accessibility to its entire memory map space (i.e., to peripherals connected to both portions iASB, eASB of the common system bus).

[0104] The ARM supercore 140 generates two busses which use the AMBA bus protocol from the ARM. The APB is the ARM Peripheral Bus, which is intended to be used with slower peripherals. The ASB is the ARM high speed bus that is intended to be used for high speed peripherals. The APB bus is used to read & write status/configuration registers in all of the peripheral blocks. It provides a “slow backdoor” access for the eASB agents. It is also used to directly interface to some of the slower peripherals. The APB bus is generated by the APB bridge which hangs off of the iASB.

[0105] The Internal Direct Memory Access (IDMA) 126 refers to a sub-block connected to each of the eASB data ports. This sub-block allows the dataport First-In, First-out (FIFO) devices (also referred to as DIBs) to buffers incoming & outgoing data to transfer the buffered data to/from external memory.

[0106] The super arbiter 142 is inside the supercore. The super arbiter 142 is a priority based arbiter. The super arbiter 142 is in control of the entire common system bus upon reset, the subordinate MONARC arbiter 134 being inactivated at this time. The ARM controller 140 may configure the time slot parameters in one (or both upon initialization) of the configuration register sets 220, 224. After the MONARC is programmed & enabled, the MONARC arbiter 134 can co-exist with the super arbiter 142 with appropriate electrical separation provided by the tri-state buffers 197. The common system bus becomes electrically re-connected when the MONARC arbiter 134 grants the ARM supercore 140 a time slot on the eASB bus.

[0107] Although the MONARC arbiter time slots are programmable in general, the ARM 140 (e.g., agent #0) preferably has at least one pre-allocated time slot in the time slot sequence that defines the system cycle.

[0108] In FIGS. 6 and 7,the external, or added bus (eASB) is setup for high speed data traffic between a given agent and the external shared memory. Each of these agents (with the exception of the ARM controller 140) has a read and write data buffer and associated status signals which are inputs to the IDMA 126. The IDMA 126 is attached to the MONARC arbiter 134.

[0109] The disclosed system has two levels of ASB bus arbitration hierarchy. The supercore arbiter 142 is the top level of arbitration. It can be configured to allocate the ASB ownership to the EIC socket (i.e. eASB peripherals). After system initialization (when ARM owns the entire ASB bus (both iASB and eASB)), the ARM 140 enables the MONARC arbiter 134 and the supercore arbiter 142 relinquishes control of the extended portion eASB of the common system bus to the eASB arbiter 200 upon system bus tri-state separation. At this point in time, the ARM 140 becomes one of the agents on the eASB bus.

[0110] The ARM 140 is preferably the only agent that can disable the MONARC arbiter 134,and is labeled agent#0 in the disclosed embodiment. The ARM 140 also has a preemption capability which allows it to (in effect) extend its eASB time slot by disabling and suspending the arbitration by the MONARC arbiter 134. When the ARM 140 is finished, it can re-enable the MONARC arbiter 134, and the system arbitration cycle will continue where it left off.

[0111] In an emergency situation on the eASB bus, the MONARC arbiter 134 can be disabled, and the ARM 140 can be given responsibility to determine when to re-enable the MONARC arbiter 134 and again relinquish control of the eASB bus.

[0112] The MONARC arbiter 134 distributes ownership of the eASB bus among the internal interface devices and two external bus master capable peripherals. In the case of external bus masters, they are really not provided access to the eASB bus, but rather are granted access (with no contention) to the external memory bus. Thus, the MONARC arbiter 134 maintains all of the internal agents off of the eASB bus so that the external device can use the external memory interface.

[0113] The present invention is applicable to the architecture of any relevant integrated circuit (IC) irrespective of the intended application.

[0114] While the invention has been described with reference to the exemplary embodiments thereof, those skilled in the art will be able to make various modifications to the described embodiments of the invention without departing from the true spirit and scope of the invention.