
TM1100 Preliminary Data Book
Philips Semiconductors
19-8
PRELIMINARY INFORMATION
File: arb.fm5, modified 7/23/99
When VO is running in image mode 4:2:2 or 4:2:0 without
upscaling and overlay enabled, the requirements be-
come:
During the rst 64 VO clock cycles at least one
request must be acked (the OL (overlay) data).
During 128 VO clock cycles, VO block requires to
have 4 requests acked ([4 OLs, two Ys one V and
one U]/2).
If the settings are 33% for the CPU, 33% for VO and 33%
for L3 blocks then the worst case arbitration pattern is
CPU L3 VO, CPU L3 VO, etc.
The first requirement limits the VO/SDRAM ratio to
(64 / [19 + 10 + 20 + 3 * 20]) = 58.7%.
The second requirement gives a VO/SDRAM ratio of
44.29% (128 / [19 + 10 + 20 + 3 * 20 + 3 * 20 * 3]).
Thus if VO clock speed is supposed to be 54MHz (pro-
gressive scan) the SDRAM has to run at least at 122
MHz.
By setting the arbiter to 25% for the CPU, 37.5% for VO
and 37.5% for VI (CPUweight = 1, L2weight = 3, VOweight =
1, L3weight = 1, assuming only VO and VI are enabled)
the arbitration pattern becomes CPU VI VO VI CPU VO
VI VO CPU VI VO.
Now both VI and VO are able to catch one request out of
two, thanks to the read / write overlap. This leads to a
VO/SDRAM ratio of 47.5% or a 113 MHz SDRAM.
19.6.3
Raising Priority
If VO is running at 27 MHz (NTSC or PAL) without over-
lay and CPUweight is set to 3 while all the other weights
are set to 1, then the worst case latency derived from
LVO,sc = (ceil[(1 + 1) / 1] + ceil[(3 + 1) / 1] + 1) * 20 + 10
+ 19 = 169 SDRAM cycles (assumes RVO = 0).
If the SDRAM is running at 80 MHz and since the latency
for VO is one request in 64 VO clock cycles (there is no
back to back request and the requirement is two re-
quests in 128 VO clocks), this gives a maximum latency
for VO of floor(64 / (27 / 80)) = 189 SDRAM cycles.
This means that VO requests can remain at low priority
for 189 - 169 = 20 SDRAM cycles.
If the CPU clock speed is 100 MHz (ratio is 5 / 4) then the
ARB_RAISE register can be programmed to
floor(20 * (5 / 4) / 16) = 1.
VO requests will stay at low priority for 16 cycles allowing
slightly better average CPU performance.
19.6.4
Conclusion
There is no obvious way to set the best weights for laten-
cy or bandwidth allocation since the behavior of each
block cannot be easily described with equations.
Practical results obtained by running applications
showed that once the arbiter is weighted to meet laten-
cies the remaining weight settings do not allow much im-
provement.
The best way to tune the weights is by experiment, run-
ning the application.
The only accurate computation is the maximum worst
case latency, which ensures that the hard real-time units
work properly.
This computation gives an upper bound and can be too
pessimistic - but it still gives the right order of magnitude.
Refer to
Table 19-5 for the recommended allocation
method.
Table 19-5. Recommended Allocation Method
Video In
allocate required latency
Video Out
allocate required latency
Audio In
allocate required latency
Audio Out
allocate required latency
ICP
allocate bandwidth
PCI
allocate bandwidth
VLD
allocate bandwidth/latency
DVDD
allocate bandwidth/latency