Data space arbiter

A digital processor has a default bus master having a highest priority in a default mode, a plurality of secondary bus masters having associated priorities, wherein the plurality of secondary bus masters have a predetermined priority relationship to each other, and a data space arbiter. The data space arbiter is programmable in a non-default mode to raise a priority of any of the secondary bus masters to have a priority higher than the priority of the default bus master while maintaining the predetermined priority relationship to only those secondary bus masters for which the priority level also has been raised above the priority of the default bus master.

TECHNICAL FIELD

The present disclosure relates to digital processors, and, more particularly, to data arbiter priority control systems in a digital processor.

BACKGROUND

In embedded systems using digital processors, e.g., microcontrollers, having a plurality of peripheral devices and a central processing unit (CPU), certain functional units are shared between the CPU and at least some of the peripherals such as a direct memory access (DMA) controller or an in-circuit debug (ICD) controller. Thus, a data space arbiter is used to determine access rights to the memory or special function registers that are shared. In a data space arbiter for a multi-master system, the CPU is typically the highest priority bus master. A typical data space arbiter consists of a priority encoder and a set of data bus multiplexers. A conventional programmable data space arbiter implements the programmability within the priority encoder but uses predetermined priorities in which the CPU generally has the highest priority. Thus, whenever the CPU is accessing the memory all other peripherals usually are stalled. However, in embedded systems it may sometimes just temporarily be more critical to respond to an external event by, for example, a peripheral then to ensure high CPU throughput.

Therefore there exists a need for an improved more flexible data space arbiter.

SUMMARY

According to an embodiment, a digital processor may comprise a default bus master having a highest priority in a default mode; a plurality of secondary bus masters having associated priorities, wherein the plurality of secondary bus masters have a predetermined priority relationship to each other; and a data space arbiter, wherein the data space arbiter is programmable in a non-default mode to raise a priority of any of the secondary bus masters to have a priority higher than the priority of the default bus master while maintaining the predetermined priority relationship to only those secondary bus masters for which the priority level also has been raised above the priority of the default bus master.

According to a further embodiment, the data space arbiter may grant access to data memory and the data memory may comprise at least one of random access memory, dual port memory, special function registers. According to a further embodiment, the digital processor may further comprise a bus master priority register having priority override bits, at least one of the secondary bus masters is assigned to one of the priority override bits, wherein the bus master priority register programmably specifies which ones of the plurality of secondary bus masters have higher or lower priorities than the default bus master priority. According to a further embodiment, setting a priority override bit may cause a priority level of an associated secondary bus master to be raised above the priority level of the default bus master. According to a further embodiment, the data space arbiter may comprise a separate arbiter unit for read and write accesses. According to a further embodiment, the data space arbiter comprises a separate arbiter unit for memory and special function register accesses. According to a further embodiment, the data space arbiter may comprise a separate arbiter unit for memory and special function register accesses. According to a further embodiment, the digital processor may further comprise an address decoder coupled between the data space arbiter and the data memory. According to a further embodiment, the digital processor may further comprise a coarse address decoder coupled between the data space arbiter and the default bus master or secondary bus masters. According to a further embodiment, the digital processor can be a digital signal processor and the random access memory may be split into an X-memory and a Y-memory. According to a further embodiment, the default bus master can be a central processing unit (CPU).

According to another embodiment, a method for arbitrating data space access in a digital processor, may comprise: assigning priorities to a default bus master and a plurality of secondary bus masters wherein the default bus master has the highest priority in a default mode and wherein the plurality of secondary bus masters have a predetermined priority relationship to each other; and programming a data space arbiter in a non-default mode to raise a priority of any of the secondary bus masters to have a priority higher than the priority of the default bus master while maintaining the predetermined priority relationship to only those secondary bus masters for which the priority level also has been raised above the priority of the default bus master.

According to a further embodiment of the method, the method may further comprise: requesting access to a data space by a secondary bus master while the default bus master has access to the data space and if the priority of the secondary bus master is higher than the priority of the default bus master, granting access to the data space other wise stalling the secondary bus master. According to a further embodiment of the method, the data space can be data memory which comprises at least one of random access memory, dual port memory, special function registers. According to a further embodiment of the method, the step of programming a data space arbiter to raise a priority of the secondary bus masters may comprise the step of setting a bit in a bus master priority register. According to a further embodiment of the method, at least one of the secondary bus master may have an associated bit in the bus master priority register. According to a further embodiment of the method, the data space arbiter may comprise a separate arbiter unit for read and write accesses. According to a further embodiment of the method, the data space arbiter may comprise a separate arbiter unit for memory and special function register accesses. According to a further embodiment of the method, the data space arbiter may comprise a separate arbiter unit for memory and special function register accesses.

According to yet another embodiment, a method for arbitrating data space access in a digital processor may comprise: assigning a highest priority to a central processing unit (CPU) and further priorities to a plurality of non-CPU bus masters in a default mode wherein the plurality of non-CPU bus masters have a predetermined fixed priority relationship to each other; programming a data space arbiter by setting a bit in a bus master priority register to raise a priority of one of the non-CPU bus masters to have a priority higher than the priority of the CPU while maintaining the predetermined priority relationship to only those non-CPU bus masters for which the priority level also has been raised above the priority of the CPU; and requesting access to a data space by a bus master while the CPU has access to the data space and if the priority of the bus master is higher than the priority of the CPU, granting access to the data space other wise stalling the bus master, wherein the data space is data memory which comprises at least one of random access memory, dual port memory, special function registers.

DETAILED DESCRIPTION

According to various embodiments, a data space arbiter is designed to allow the priority of any bus master to be raised relative to the priority of the bus master having the highest priority in default mode (hereinafter “default master”), thereby increasing real-time response flexibility in a digital processor system. This can be accomplished in a easy way by maintaining the predetermined priority relationship between the raised bus master and only those bus masters for which the priority level also has been raised above the priority of the default master. Hence, no complicated reassignment of priority levels of each bus master is necessary. According to the teachings of this disclosure, each bus master (except the default master) may opt to override this priority. If the default master is the CPU, any (non-CPU) bus master priority can, thus, be defined, for example, through user defined programmable priority override bits, to be higher or lower than that of the CPU. However, the relative priority of all bus masters within the priority group higher than the default master is designed not to change. Similarly, the relative priority of all bus masters within the priority group lower than the default master does not to change. The incoming bus master requests are simply reordered, for example, by using multiplexers, based on the state of the priority override bits. They are then sent to a simple fixed priority encoder and prioritized as usual. The resulting bus grant signals are then remapped back to their original order, for example, again using the state of the priority override bits, and the winning bus master is granted bus access. All other bus masters are stalled.

FIG. 1shows a principal block diagram of a digital signal processor100with three different bus masters, a CPU110, an in-circuit debugger (ICD) unit105and a direct memory access (DMA) controller115. However, other configurations with a general purpose processor and different bus masters may apply as will be appreciated by a person skilled in the art. A coarse address decoder120is coupled with these bus masters to decide whether a request hits the ransom access memory (RAM) or the special function registers (SFR). This coarse address decoder generates a plurality of output signals which are coupled with respective dedicated read arbiters130and140, and dedicated write arbiters135and145. The RAM arbiters130,135are coupled with a panel level address decoder for accessing two separate static random access memories (SRAM)170and175. In addition, a dual port (DP) SRAM180is provided which is on one hand coupled with the output of address decoder160and on the other hand with a special coarse address decoder190which may be part of or associated with coarse address decoder120. The outputs of all memory devices170,175, and180are coupled through various multiplexers125,150,155, and185with the different bus masters110,105,115. A peripheral device interface165may be coupled directly through multiplexer185with ICD unit105. However, as mentioned above other memory configuration may be used according to various embodiments, for example, a single memory can be used with a general purpose processor.

Also, in this specific embodiment of a digital signal processor or microcontroller, separate arbiters for RAM and SFR are provided. Moreover, within each arbiter separate arbiters or read (130;140) and write accesses (135;145) are provided. However, other designs may be used and the number of actual arbiters may vary. For example, a single arbiter may be used to provide the same functionality.

According to various embodiments, the arbiters are configurable by the different bus masters. This can be done “on the fly”, in other words, a user program can alter the configuration according to respective needs of the system in which the device is embedded.FIG. 2shows a table with a possible implementation in which a digital processor is associated with, for example, five bus masters such as a CPU which is the highest priority bus muster in a default mode, and a plurality of secondary bus masters such as an Ethernet unit, a USB unit, a DMA controller, and an ICD unit. This simple scheme is easily extended to add more bus masters or use less, and does not rely on a larger, potentially slower, programmable priority encoder. According to one embodiment, the system may not be a fully programmable solution because the bus master relative priority within each group may remain fixed. This can, for example, be accomplished by setting respective bits in the special function register MSTRPR195which is coupled with arbiters130,135,140, and145as shown inFIG. 1.

UUR/WUR/WUR/WU00DMAC0USB0ETH0(M3)(M2)(M1)Bit7bit0
wherein bits15-6are unused and bits6,4,2, and0are reserved. Bit5DMAC (M3) is used to modify the DMAC Bus Master priority relative to the CPU priority. When set to 1: The DMAC Bus master priority is raised above that of the CPU while maintaining the predetermined priority relationship to only those secondary bus masters for which the priority level also has been raised above the priority of the CPU. When set to 0: No change to the DMAC Bus Master priority. The priority of the DMAC Bus Master remains below that of the CPU and is in the predetermined relationship to all other secondary bus masters that have not been raised above the CPU. Bit3USB (M2) is used to modify the USB Bus Master priority relative to the CPU priority. When set to 1: The USB Bus master priority is raised above that of the CPU while maintaining the predetermined priority relationship to only those secondary bus masters for which the priority level also has been raised above the priority of the CPU. When set to 0: No change to the USB Bus Master priority. The priority of the USB Bus Master remains below that of the CPU and is in the predetermined relationship to all other secondary bus masters that have not been raised above the CPU. Bit1ETH (M2) is used to modify the Ethernet Bus Master priority relative to the CPU priority. When set to 1: The Ethernet Bus master priority is raised above that of the CPU while maintaining the predetermined priority relationship to only those secondary bus masters for which the priority level also has been raised above the priority of the CPU. When set to 0: No change to the Ethernet Bus Master priority. The priority of the Ethernet Bus Master remains below that of the CPU and is in the predetermined relationship to all other secondary bus masters that have not been raised above the CPU.

According to an embodiment, the default priorities at reset are set such that the CPU has the highest priority and the ICD the lowest priority. In the embodiment shown above, the priority of the ICD bus master is not assigned a bit in the MSTRPR register195. Thus, its priority remains at the lowest level. However, in other embodiments, the priority of this device may also be raised and it may be assigned to a bit in register195. According to an embodiment, all raised priority bus masters maintain the same priority relation ship relative to each other. According to an embodiment, all masters whose priority remains below that of the CPU maintain the same priority relationship relative to each other. Thus, the secondary bus masters can be split in two groups. The first group contains the secondary bus masters with a raised priority and the second group contains the secondary bus masters whose priority has not been raised.

As shown inFIG. 2, only certain bits are used and result in eight different configurations each having a different priority order of the respective bus masters. This relatively simple scheme allows for an easy implementation in which decoding is kept to a minimum. However, in other embodiments, other decoding schemes may apply which allow for a more assignment of priorities.

The data space arbiters130,135,140,145prioritize concurrent requests from the bus masters (initiators)110,105,115for data space bus resources (targets)170,175, and180using a predetermined priority. The bus matrix connects the winning bus master with the requested resource. Loosing bus masters are not granted access to the requested resource and may be stalled until arbitration determines that the resource is available for them to use (a structural hazard). The arbiters that control access to the data space excluding SFR space are referred to as the read and write RAM arbiters130and135. The arbiters that control access to SFR space are referred to as the read and write SFR arbiters140and145. Each arbiter130,135,140,145is parameterized to support ‘n’ bus masters where n=NUM-BUS-MASTERS, allowing the same leaf cell to be used for all instances. The CPU110, DMAC115and ICD105bus masters may be present in many embodiments, thus generally NUM-BUS-MASTERS>=3 for the RAM arbiters. According to a specific embodiment, only the CPU110and ICD105may access the SFR address space, thus NUM-BUS-MASTERS=2 (always) for the SFR arbiters140and145.

The data space (DS) (not including SFR address space) resources and arbiter targets may be as follows according to an embodiment. Each resource requires an arbiter.

According to a specific embodiment as shown inFIG. 1, the DMA Controller115accesses DPSRAM180via the backside port, so can be seen as a special case. The SFR address space resources and arbiter targets may be as follows according to an embodiment. Each resource requires an arbiter.

According to an embodiment, the lowest priority bus master is M[n−1] where n=NUM-BUS-MASTERS. For both the RAM and SFR arbiters, this may always be the ICD macro. The remaining bus master priorities are somewhat user programmable via the Bus Master Priority control register, MSTRPR as explained above.

A bus master110,105,115read will be a data read from RAM (for the RAM arbiters)170,175or SFR space (for the SFR arbiters). A bus master write will be a data write to RAM (for the RAM arbiters)170,175or SFR space (for the SFR arbiters). The control between the bus masters110,105,115and arbiters130,135,140,145can be realized using a bus request/grant handshake. All bus masters110,105,115may request a bus resource170,175,180by asserting their read or write bus request signals. They will only be permitted to use the requested resource when the associated arbiter130,135,140,145has granted access by asserting the corresponding bus grant signal.

The CPU bus master arbiter interface may be the same as all other masters. However, because it can complete both a read and a write within one bus cycle, wherein all other bus masters may either read or write for each bus transaction, the interface timing is slightly different.

Furthermore, in a low power mode, such as for example, a DOZE mode, the CPU110may be operating at a significantly slower clock rate than the device peripherals. In order to prevent the CPU110from locking out subsequent resource requests from the peripherals, wherein one CPU request cycle could encompass many peripheral cycles, the CPU110requests are not Q-clk based but are synchronized to the P-clks prior to presentation to the arbiters.

There may be 3 address decoders implemented according to an embodiment as shown inFIG. 1. The first address decoder120(SFR coarse space decoder) determines if the CPU110and ICD105read and write addresses target the SFR or RAM arbiters130,135,140,145. The second address decoder190(DPSRAM coarse space decoder) determines if the DMA address (read or write) is targeting the DPSRAM (backside)180or not. The third address decoder160(WY panel decoder) takes the resultant addresses from the RAM read and write arbiters and directs them to either X or Y address space.

A bus arbiter can be a block of combinatorial logic that continuously prioritizes all incoming bus requests, generates a winning grant signal, and directs the winning master address bus to the arbitrated resource. It may consist of a priority encoder and a set of multiplexers. The priority encoder examines all incoming bus requests and prioritizes them based on a programmable priority encoding as explained above. The result of this encoding is passed to the address and data multiplexers, and to a one-hot encoded grant bus that grants the bus transactions to the winning bus master. The corresponding address and data buses are selected and the winning bus master gains access to the requested resource. All other requesting bus masters are held off (stalled) until such time that the winning bus master transaction has completed.

The data write arbiters135,145also direct the winning master data bus to the arbitrated resource. The timing of the incoming request signals dictates the timing of the resultant grant signal, the resource address bus and (as appropriate) resource data bus.FIG. 3shows a respective timing diagram of example transactions for the RAM arbiters130,135with the CPU110having the highest priority.FIG. 4shows a similar timing diagram with the CPU110not having the highest priority. The address multiplexer output is held in a P2flop to keep the winning address valid beyond Q3(CPU address can change after Q3).

A timing diagram of example transactions for the SFR arbiters are shown inFIG. 5wherein that CPU is always highest priority according to an embodiment.FIGS. 6 and 7show control signals received and generated by the arbiter in read and write accesses, respectively.

The DMA controller115, ICD105and all peripheral bus masters assert bus requests (xxx_bmx.mst_rd_req=1 or xxx_bmx.mst_wr_req=1, where ‘xxx’ represents the bus master abbreviation) on P3if access (read or write) is required. The discussion below assumes the device is not in low power mode, where the Q-clk and Pclk frequencies can differ. For example, in a low power DOZE mode, the CPU synchronizes bus arbiter requests to the P-clks to maintain arbiter throughput for any lower priority peripheral bus masters. According to an embodiment, for CPU read requests, the CPU110must combinatorially pre-decode the instruction loaded into ROMLATCH on Q3to determine if a read request is required. A CPU read request (xcpu_bmx.mst_rd_req=1) will therefore be asserted some time after Q3. Arbitration for both read and write requests is combinatorially completed and the winning bus grant is then asserted (xcpu_bmx.mst_rd_gnt=1). A CPU Q1latch (flop if grant timing will make Q1setup) holds the grant result, asserting cpu_pfu_stall=1 and stalling the CPU if xcpu_bmx.mst_rd_gnt=0.

According to an embodiment, for CPU write request, the CPU110will assert the write request (xcpu_bmx.mst_wr_req=1) on Q3of the active instruction cycle. For the peripheral bus masters, the arbiter grants are examined prior to P3and if asserted, will cause the associated bus master request signal to be negated at P3. If the bus grant of a requesting peripheral bus masters is not asserted, the peripheral bus master request will remain asserted until such time that the grant is found to be asserted. The peripheral bus master will check the state of the grant signal prior to P3of the next cycle.

According to an embodiment, for CPU reads, the read arbiter grant is examined during Q1and if xcpu_bmx.mst_rd_gnt=1, the instruction underway is allowed to continue execution. The request, xcpu_bmx.mst_rd_req, will be negated at the next Q3. If the CPU110is requesting a read access and the bus master grant is not asserted (xcpu_bmx.mst_rd_gnt=0), the CPU110will stall the PFU (cpu_pfu_stall=0) and the CPU instruction underway (by inhibiting all register updates). The request will remain asserted until such time that the CPU is granted resource access to complete the stalled cycle.

According to an embodiment, for CPU writes, the write arbiter grant is examined prior to Q3. If xcpu_bmx.mst_wr_gnt=1, the instruction underway completes execution and the next instruction is not stalled. If the bus master grant is not asserted (xcpu_bmx.mst_wr-gnt=0), the instruction underway retires (completes execution), buffering the data write. Subsequent instructions are stalled until such time that the grant is found to be asserted. The write request remains asserted while the CPU110is stalled. In both cases, the CPU110will check the state of the grant signal prior to Q3of the next cycle. The CPU110will retire (complete) the instruction underway but buffer the data write for completion at some later time (i.e. after the grant is asserted). In order to allow every instruction to complete after it is started, the CPU may be the only bus master that can buffer a data write. All other bus master requests are stalled for both read and write accesses. A winning bus master read will complete by Q3of the cycle after the request. A winning bus master write will occur on the Q1following the Q3request.

According to an embodiment, bus master reads and writes can complete at a rate of one per bus cycle for the CPU110. The CPU110issues the request (for either read or write) in the same cycle that it will complete it (if granted access to the requested resource.)

The data throughput for peripheral bus masters (i.e. all other bus masters except the CPU) is asymmetrical for reads and writes. Peripherals bus master read requests that occur in one cycle will (if granted resource access) complete the transaction in the next cycle. However, peripherals bus master write requests will (if granted resource access) complete the transaction in the same cycle as the request.

According to an embodiment, the bus arbiters may not be pipelined, so a peripheral bus master must complete a requested transaction before requesting another bus access. Maximum peripheral bus master data throughput is therefore one transaction every 2 cycles for reads (and one transaction every cycle for writes).

Each of the peripheral bus masters can perform either a read or a write (but not both) during an arbitrated transaction which they have won. However, according to an embodiment, read and write requests may be arbitrated separately. Consequently, a read and a write request from two bus masters can be serviced within one cycle. The CPU110can complete both a read and/or a write within one bus cycle. One or both of these accesses may be arbitrated.

The extended data space (EDS) Bus Master Priority Control register MSTRPR<15:0>, which may be located within the CPU110can be used to modify the priority of each of the peripheral bus masters relative to that of the CPU110.

According to an embodiment, each peripheral bus master can be assigned a bit within the MSTRPR register. Bit locations for specific bus masters are fixed but ‘M’ numbers associated with each bus master will vary between variants, depending upon which bus masters are present. Bus masters can be added to the MSTRPR register (in fixed locations) as they are developed. According to an embodiment, the arbiter bus master inputs are always sequential (i.e. MO, MI, M2, M3etc.) in all variants.

When the assigned bit is set, the corresponding peripheral bus master is raised to be above that of the CPU110. The CPU priority will remain above that of the peripheral bus masters whose priority has not be raised. According to an embodiment, the relative priority of the peripheral bus masters raised above the CPU priority will remain the same as it was before being raised above the CPU110. Similarly, the relative priority of the peripheral bus masters not raised above the CPU priority will remain the same as it was before being raised above the CPU110. The effect of the MSTRPR register is shown in the table shown inFIG. 2where 5 bus masters are being arbitrated.

According to an embodiment, not all devices may support Ethernet and/or USB peripherals, and the assigned relative priority of these bus masters may differ from that shown in the example.

The parameter NUM-BUS-MASTERS defines the number of bus masters supported by each of the DS/EDS RAM arbiters. According to an embodiment, a separate read and a write arbiter may be required. A RAM arbiter truth table is shown in the table depicted inFIGS. 9 and 10for NUM-BUS_MASTERS=4, and applies to both the read and write arbiter. It arbitrates bus master access to all of DS/EDS except SFR address space.

According to an embodiment, the CPU and ICD bus masters may be always present. The remaining bus masters present in the table shown inFIGS. 9 and 10are the USB and DMAC which are assigned to Bus Master Priority register bits MSTRPR<3> and MSTRPR<5> respectively. All other MSTRPR bits are reserved or unused and therefore ‘don't care’ bits.

A block diagram for the RAM arbiters and address decode block with respective signal interconnections is shown inFIG. 8. According to an embodiment, CPU110is always assigned to MO input of the arbiter130and135. All other masters are assigned other arbiter inputs (M1, M2etc. without gaps) in decreasing order of priority as defined by the device specification. Consequently, the same bus master may be assigned to different arbiter input ports (Mx) in different variants.

All bus masters must access DS/EDS RAM via the RAM arbiter130,135(the backside DPSRAM for the DMAC is considered an exception according to an embodiment). According to an embodiment, the ICC bus master may only gain access to DS/EDS when no other master is requesting access. The ICD bus master priority can never be raised above that of any other master.

According to an embodiment, it is assumed that all peripheral bus masters will only ever transfer data to or from addresses within DS SRAM or DPSRAM (any other address would be indicative of erroneous operation). Bus requests will therefore be allowed for any bus master address. DS SRAM and DPSRAM block decode resides after the arbiter address multiplexer, so addresses outside this range will result in arbitration but will have no effect on DS memory. However, access to unimplemented DS/EDS will result in a CPU110illegal address trap (if the requesting bus master was the CPU110) or a generic soft trap (if the requesting bus master was any peripheral bus master except the ICD105). If the ICD105bus master attempts to access unimplemented DS/EDS, no trap will occur. The grant is issued as usual but a read will return all 0's, and a write will have no effect. The CPU110must send a signal to the Interrupt Controller to indicate which bus master made the request.

According to an embodiment, in a digital signal processor, the CPU X and Y RAM read requests (cpu_xram_rd and cpu_yram_rd) can be logically OR'd together to create a single CPU RAM read request (cpu_bmx.mst_rd_req) signal.

The SFR coarse address decoder120directs the CPU address to either the RAM arbiter130,135or the SFR bus arbiter140,145based on a predetermined address boundary for SFR space defined by parameter SFR_BYTE_SIZE. Bus requests associated with a CPU address that is less than the SFR limit, will be routed to the SFR arbiter140,145. Bus requests associated with a CPU address that is greater than or equal to the SFR limit, will be routed to the RAM arbiter130,135.

The output of the arbiters130,135,140,145feeds the RAM address decoders160where the winning address is routed to the correct DS/EDS address space (X or Y) based on the X and Y address boundary parameters XRAM_START_ADDR, XRAM_ADDR_WIDTH and YRAM_ADDR_WIDTH. The X/Y address decoder160contains Q2flops to sample and hold the RAM control signals which select the RAM data source170,175. According to an embodiment, X and Y RAM170,175can always be located to be contiguous within the DS. For example, Y RAM175is placed immediately after the end of the X RAM170as shown inFIG. 1.

As mentioned above, a digital signal processor or microcontroller may not have to include DPSRAM. SRAM and (frontside) DPSRAM address spaces can be combined into a single DS/EDS RAM X address space for all bus masters except for the DMAC115. Because according to an embodiment, the DMAC115has exclusive access to the DPSRAM backside bus, arbitration for this bus master is only required for addresses that fall outside of the DPSRAM address range (i.e. for SRAM only). Other bus masters are permitted access to the DPSRAM frontside bus while the DMAC115is accessing the backside bus. The DPSRAM180may include logic to detect and flag inadvertent concurrent writes to the same DPSRAM address from both ports.

The DPSRAM180may be located at the same address for both frontside and backside accesses. The DPSRAM coarse address decoder190examines both read and write data requests from the DMAC115and determines if they target DPSRAM address space or not. If a DPSRAM access is detected, the corresponding read or write request is routed directly to the DPSRAM180and not to the RAM arbiters130,135,140,145. The DPSRAM coarse address decoder190must also immediately issue a bus grant to the DMAC115in order to allow the access to the backside DPSRAM port to complete. In effect, the arbiter can be viewed as ignoring this request and may grant another bus master access to DS/EDS, including access to DPSRAM180via the frontside bus.

According to an embodiment, the SFR arbiter140,145may only support 2 bus masters, CPU110and ICD105, so NUM-BUS-MASTER=2 (fixed). The CPU110will always win any arbitration, irrespective of the state of the state of cpu_arb_master_priority<7:0> because the ICD105is always at the lowest priority (and cannot cycle steal).

The resultant output of the SFR arbiters140,145will be the winning bus master address, data and read (or write) signal. In order to meet timing for certain peripherals, the winning read address is held in a P2flop. Peripheral address decode is completed within each peripheral.

According to an embodiment, in order to meet device speed objectives, all SFR bus grants in response to SFR read requests (with the exception of memory mapped CPU register SFR addresses as will be explained in more detail below) are pipelined to delay them by one cycle. SFR read accesses will result in a CPU stall and are therefore 2 cycle operations.

Memory mapped CPU registers can reside within SFR address space. However, these registers physically reside within the CPU110. All SFR write requests are granted immediately (subject to successful arbitration), allowing SFR writes to be completed in 1 cycle.

A block diagram for the SFR arbiters and address decode block is shown inFIG. 11. A timing diagram of example transactions for the SFR arbiters are shown inFIG. 5(CPU is always highest priority).

According to an embodiment, the ICD105can read or write any SFR but writes to CPU SFRs are inhibited through ICD firmware. Furthermore, if any code protection is enabled, all ICD SFR accesses are inhibited by the ICD macro According to an embodiment, a CPU trap that disables CPU writes to SFR space (cpu_disable_memwrite=1) should not interfere with any coincident ICD SFR write requests

No system clocks are active in a low power SLEEP mode, so all arbiters130,135,140,145are inactive. In an IDLE mode, the CPU Q-clks are disabled while the peripheral P-clks remain active. Consequently, according to an embodiment, the CPU110cannot make any arbiter bus requests while in IDLE mode. Because all peripheral bus masters (including the ICD macro) operate using P-clks, both the RAM and SFR bus arbiters130,135,140,145continue to operate as normal for these bus masters in IDLE mode.

According to an embodiment, in another low power DOZE mode, the CPU Q-clks run at a (programmable) binary fraction of the peripheral P-clks. As mentioned above, all peripheral bus masters run using the P-clks. Consequently, the CPU110must postpone all arbiter bus requests until the last (P-clk) cycle of each Q-clk cycle. Failure to do so would result in the CPU110monopolizing the bus arbiter, blocking all lower priority bus masters for the duration of each CPU cycle that requires bus access.