MPC563XM Reference Manual, Rev. 1
926
Freescale Semiconductor
Preliminary—Subject to Change Without Notice
NOTE
All eTPU input clocks must pulse during reset so that both engines are reset,
even if they are in Module Disable or Stop mode.
23.5.2.2
Software Reset
eTPU has no Software reset. To abort infinite microcode loops, the Force END mechanism must be used
(see field FEND in
Section 23.3.2.5, “ETPUECR - eTPU Engine Configuration Register
”).
23.5.3
Multiple Parameter Coherency Methods
Follows a description of two methods for coherent transfer of multiple parameters between Host and
eTPU. Both methods involve the use of two parameter areas: the Transfer Parameter Area (hereafter called
TPA), which is the SPRAM area directly accessed by the Host for reads and writes, and the Permanent
Parameter Area (hereafter called PPA), which are the SPRAM positions where channel parameters are
normally accessed by the Function microcode. Note that parameters in either TPA or PPA do not have to
be in sequential addresses. TPAs and PPAs allocation are completely defined by the application, and there
may be any number of them, independently of the channels.
The methods described here are not the only solutions for the coherent transfer problem, and both can
coexist in eTPU and even used in combination. Also note that for transfers of a pair of parameters, the
Coherent Dual-parameter Controller is faster and have less impact on both eTPU and Host performance.
That said, the methods are:
•
Transfer Service
: a microengine thread transfers, upon Host Service Request, data from/to a TPA
to/from a PPA.Coherency is guaranteed by the fact that a thread is atomic with respect to other
threads in the same Engine, and so are its transfers. If parameters in PPA are shared by both
Engines, hardware semaphores have to be used to access them.
•
Mailbox
: for Host to eTPU transfers, the microcode checks a flag, set by the host, indicating the
existence of new parameter data in the TPA. It can, then, either access TPA data directly or copy it
to the PPA. For eTPU to Host transfers, when microcode changes PPA, it copies them to the TPA
and flags updated TPA data to Host, possibly using an Interrupt or a Data Transfer Request. The
Mailbox flag is reset when data is copied: by the eTPU microcode, when it transfers TPA to PPA
(possibly followed by an Interrupt); by the Host, when it reads data from the TPA. This indicates
that TPA is free for another transfer.
Transfer Service has the advantage of separating the task of data transfer from the functional service thread
that accesses the parameters, with less impact to the latter. Compared to the Mailbox method, however, it
has bigger average latency, because the Transfer Service thread has to contend for a time slot to execute.
This latency can be minimized if Transfer Service thread is assigned to a separate channel with higher
priority, but even so it does not guarantee that PPA is updated before the next execution of the functional
thread that uses it.
Mailbox method, on the other hand, makes the functional thread check for the existence of new data (Host
to eTPU). It does not have to be responsible for the transfer, though: it may access the TPA directly, and a
Transfer Service can then be used to copy data from TPA to PPA.