Signal
L1_Instr_DF[31:7] 3 6
L2_Instr_DF[31:7] 1 2
L3_Instr_DF[31:7] 2 3
Delay caused by TU load
t1 t2
LRP
Frame
Request
t3
t4
t5 t6 t7
Request
Quiet Request
Quiet Request
Signal
L1_Instr_DF[31:7] 3 6
L2_Instr_DF[31:7] 1 2
L3_Instr_DF[31:7] 2
t1 t2
LRP
Frame
3
Request
t3 t4 t5 t6
Request
LRP
t7
Delay caused by TU load
Quiet Request Quiet Request
www.ti.com
Module Operation
1141
SPNU563A–March 2018
Submit Documentation Feedback
Copyright © 2018, Texas Instruments Incorporated
High-End Timer Transfer Unit (HTU) Module
24.2.4.1 Requests and Quiet Requests
In addition to generating too many transfer requests and thus overloading the HTU and not being able to
transfer data at all, it can happen that inconsistent data is transferred. The following examples illustrate
such scenarios.
In the examples below, the HTU reads a frame of three elements from the datafield of three different
instructions. In Figure 24-10, the L3-Instruction generates the HTU request at time t2, t7, and so on. and
the according frame (at t3). The frame is delayed because of the HTU load. However, as shown in
Figure 24-10, the delay still allows the frame to complete before the datafield of instruction L1 is updated
again. However, when the delay is longer (as shown in Figure 24-11), then the frame could fall into the
N2HET loop (LRP), in which the N2HET updates the data fields of the L1, L2 and L3 instructions. In this
case, the HTU could read inconsistent data as shown in the diagram. A wrong (new) value is read from L1
(at time t3), but correct ("old") values are read from L2 and L3 (at times t4 and t5).
Figure 24-10. Timing that Generates No Request Lost Error
Figure 24-11. Timing that Generates a Request Lost Error
To prevent sending inconsistent data, the N2HET instructions are able to generate a quiet request, which
does not originate a transfer but is only used by the HTU for consistency check. If a frame has not
completed since the last request (or has not even started) at the time the quiet request occurs, then the
HTU signals a request lost error. All instructions, which allow to generate a request can be configured to
generate a quiet request instead. So in the examples of Figure 24-10 and Figure 24-11, instruction L1
should be configured to generate a quiet request and instruction L3 to generate a normal request. In the
case of Figure 24-11, the corresponding bit in the RLOSTFL register will be set.
It is the responsibility of the N2HET software to enable a quiet request for the first instruction of an
instruction block, which is addressed by DCP x, and to enable a normal request only for the last
instruction of this block. Since enabling the quiet request should enable a proper request lost detection for
DCP x, both N2HET instructions need to specify the same DCP x (reqnum=x).
To Next Page
Loading...
Need help?
General
