Live-Too-Long Issues
6-104
6.10.4 Determining the Minimum Iteration Interval
Table 6–22 shows the functional unit resources for the loop. Based on the re-
source usage, the minimum iteration interval is 2 for the following reasons:
-
No specific resource is used more than twice, implying a minimum itera-
tion interval of 2.
-
A total of five non-.M units on each side also implies a minimum iteration
interval of 2, because three non-.M units can be used on a side during each
cycle.
Table 6–22. Resource Table for Live-Too-Long Code
(a) A side
(b) B side
Unit(s)
Instructions
Total/Unit
Unit(s)
Instructions
Total/Unit
.M1
MPY
1
.M2
MPY
1
.S1
B and SHR
2
.S2
SHR
1
.D1
LDH
1
.D2
LDH
1
.L1, .S1, or .D1
2 ADDs
2
.L2, .S2, or .D2
2 ADDs and SUB
3
Total non-.M units
5
Total non-.M units
5
However, the minimum iteration interval is determined by both resources and
data dependency. A loop carry path determined the minimum iteration interval
of the IIR filter in section 6.7,
Loop Carry Paths, on page 6-77. In this example,
a live-too-long problem determines the minimum iteration interval.
6.10.4.1 Split-Join-Path Problems
In Figure 6–19, the two split-join paths from a0 to a3 and from b0 to b3 create
the live-too-long problem. Because the ADD a3 instruction cannot be sched-
uled until the SHR a1 and MPY a2 instructions finish, a0 must be live for at least
four cycles. For example:
-
If MPY a0 is scheduled on cycle 5, then the earliest SHR a1 can be sched-
uled is cycle 7.
-
The earliest MPY a2 can be scheduled is cycle 8.
-
The earliest ADD a3 can be scheduled is cycle 10.
