File: arb.fm5, modified 7/23/99
PRELIMINARY INFORMATION
19-1
Arbiter
Chapter 19
by Eino Jacobs, Luis Lucas, Chris Nelson, Allan Tzeng, Gert Slavenburg
19.1
ARBITER FEATURES
The TM1100 internal highway bus conveys all the mem-
ory and MMIO traffic. The peripherals, also called devic-
es or units, described along this data-book are connect-
ed to this internal highway bus. Accesses to the bus are
pictures the whole system where the arbiter is embedded
in the main memory interface block. The traffic includes
the memory requests issued by most of the on-chip de-
vices as well as the MMIO transactions that are issued
by the DSPCPU or by the PCI block and responded to by
the peripherals.
The arbiter has been designed in order to make TM1100
a true real-time system by providing a highly programma-
ble allocation scheme of the bus. The primary character-
istics are:
round robin arbitration
hierarchical organization
programmable allocation of highway bandwidth
dual priorities with priority raising mechanism
These features are explained in the next sections of this
chapter. Arbiter programming is done through two MMIO
registers:
ARB_RAISE
ARB_BW_CTL
The default values (after hardware RESET) stored in
these two MMIO registers are suitable for most of the ap-
plications.
If these default settings introduce violations of real-time
constraints in units like VI, VO, AI and AO (each of these
units have a Highway Bandwidth Error detection mecha-
nism) then ARB_BW_CTL register should be pro-
grammed to 0x090A9. This setting gives almost maxi-
mum priority to real-time units but may slow down the
CPU.
Fine tuning of the arbiter settings is described in the fol-
lowing sections.
19.2
DUAL PRIORITIES WITH PRIORITY
RAISING MECHANISM
The best CPU performance is obtained if cache misses
can take priority over peripheral requests on the high-
way.
However, peripherals need to have a maximum guaran-
teed latency that is low enough to satisfy the real time
constraints of I/O units.
TM1100 provides this feature with the following priority
raising mechanism.
Device requests can have 2 priorities: low priority and
high priority. Within each class there is fair, round-robin
take precedence over requests with low priority.
Devices can indicate the priority of their requests to be
low or high.
A device may initially post a request with low priority. If it
does not get serviced within a particular waiting time,
then the device can raise the priority of the request to
high priority. This can be done when the worst case la-
tency at high priority approaches the real time constraint
of the device. Thus, the device uses only spare band-
width without slowing down the CPU unless real time
constraints require it to claim high priority.
In TM1100, only the ICP unit has its own priority raising
logic (i.e. it controls the low to high transition of the re-
more information.
Priority raising for VLD, PCI, VI and VO units (devices) is
handled by the arbiter central priority raising mechanism.
The central priority raising mechanism settings are con-
trolled from the DSPCPU with the ARB_RAISE MMIO
time for which the arbiter handles the request at low pri-
ority.
The delay is defined by a 5-bit field (dedicated per unit).
Delay is counted in CPU clock cycles. The granularity of
the delay is 16 cycles, so the maximum time spent at low
priority for each request can be programmed from 0 to
496 cycles, inclusive, in steps of 16 cycles.
The default value for the entire ARB_RAISE register is 0.
This causes all requests from VLD, PCI, VI and VO to be
Table 19-1. ARB_RAISE register layout
Offset
Name
Bits
Fields
0x10010C
ARB_RAISE
19:15
VLD_delay[4:0]
14:10
PCI_delay[4:0]
9:5
VI_delay[4:0]
4:0
VO_delay[4:0]