
TM1300 Data Book
Philips Semiconductors
20-8
PRODUCT SPECIFICATION
speed) was 122 MHz. After the new allocation 100 MHz
is fine. Note that here DVO remains equal to ‘5’.
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 that
4 requests be 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 54 MHz (pro-
gressive scan) the SDRAM must 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.
20.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
20.5.1 for VO is:
LVO,sc = (ceil[(1 + 1) / 1] + ceil[(3 + 1) / 1] + 1) * 20 + 10
+ 19 = 169 SDRAM cycles (assumes RVO = ‘0’).
The latency for VO is 1 request in 64 VO clock cycles. If
SDRAM is running at 80 MHz, then the maximum latency
tolerated by VO is floor(64 / (27 / 80)) = 189 SDRAM cy-
cles.
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.
20.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. Practi-
cal results obtained by running applications showed that
once the arbiter is weighted to meet latencies the re-
maining weight settings do not allow much improvement.
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 or-
der of magnitude. Refer to Table 20-5 for the recom-
mended allocation method.
Table 20-5. Recommended Allocation Method
Video In
allocate required latency
Video Out
allocate required latency
Audio In
allocate required latency
Audio Out
allocate required latency
SPDIF Out
allocate required latency
ICP
allocate bandwidth
PCI
allocate bandwidth
VLD
allocate bandwidth/latency
DVDD
allocate bandwidth/latency