Table of Contents
Advertisement
3.5.2
Optimizing Arbiter Settings
3.5.2.1
Arbiter Functionality
The PXA27x processor arbiter features programmable "weights" for the LCD controller, DMA
controller, and Intel XScale® Microarchitecture bus requests. In addition, the "park" bit can be set
which causes the arbiter to grant the bus to a specific client whenever the bus is idle. These two
features should be used to tune PXA27x processor to match your system bandwidth requirements.
The USB host controller cannot tolerate long latencies and is given highest priority whenever it
requests the bus, unless the memory controller is requesting the bus. The memory controller has the
absolute highest priority in the system. Since the weight of the USB host and memory controller
are not programmable, they are not discussed any further in the text below. The weights of the
LCD, DMA controller and Intel XScale® Microarchitecture bus requests are programmable via the
ARBCNTL register. The maximum weight allowed is 15. Each client weight is loaded into a
counter, and whenever a client is granted the bus the counter decrements. When all counters reach
zero, the counters are reloaded with the weights in the ARBCNTL register and the process restarts.
At any given time, the arbiter gives a grant to the client with the highest value in their respective
counter, unless the USB host or memory controller is requesting the bus. If one or more client
counts are at zero and no non-zero clients are requesting the bus, the arbiter grants the bus to the
zero-count client with the oldest pending request. If this happens three times, the counters are all
reloaded even though one more client counts never reached zero. This basic understanding of how
the arbiter works is necessary in order to begin tuning the arbiter settings.
3.5.2.2
Determining the Optimal Weights for Clients
The weights are decided based on the real time (RT) deadline
likelihood of a client requesting the bus. Setting the correct weight helps ensuring that each client is
statistically guaranteed to have a fixed amount of bandwidth.
Over-assigning or under-assigning of weights may violate the BW and RT requirements of a client.
Also, when weights for one or more clients becomes zero, the effective arbitration becomes first
come first serve (FCFS).
3.5.2.2.1
Weight for LCD
The first client to consider is the LCD controller. When used with larger panel sizes or overlays, the
LCD controller has very demanding real-time data requirements, which if not satisfied result in
underruns and visual artifacts. Therefore, the LCD controller is usually given the highest weight of
all of the programmable clients. The safest and easiest method of insuring the LCD controller gets
all of the bandwidth it requires is to set the LCD weight to 15. This gives the LCD controller the
bus whenever it needs it, allowing the LCD FIFO buffers to stay as full as possible in order to avoid
underrun situations. The remaining bus bandwidth, which may be very little if a very large panel is
used, is then split up between the DMA controller and the Intel XScale® Microarchitecture.
3.5.2.2.2
Weight for DMA
The DMA controller is a unique client in that it is "friendly" and always deasserts it's request line
whenever it gets a grant. Therefore, it never performs back-to-back transactions unless nobody else
is requesting the bus. In addition, if the DMA controller is the only non-zero client, there is a fair
chance the client counters are prematurely reloaded due to three zero-count clients getting grants in
1.
Real time deadline is the maximum time that a client can wait for data across the bus without impacting the client's performance (for
example, by causing a stall).
Intel® PXA27x Processor Family Optimization Guide
System Level Optimization
1
, bandwidth (BW) requirements and
3-15
Advertisement
Table of Contents
