MPC563XM Reference Manual, Rev. 1
Freescale Semiconductor
797
Preliminary—Subject to Change Without Notice
23.4.4.4
Hardware Semaphores
eTPU provides Hardware Semaphores accessible by the Microengine only. It is the responsibility of the
application to ensure proper use of the semaphores (i.e., agree upon a specific semaphore and use it
properly, to ensure coherency).
The eTPU microinstruction set has support for locking and freeing the semaphores, described in
Section 23.4.9.1.7, “Semaphore Operations
,” and this is the only way to access them.
There are four semaphores available, which reduces the amount of collisions by assigning unrelated data
transfers to different semaphores. Semaphores are used for parameters which can be shared by channels in
different Engines, and for Engine-to-Engine synchronization. Semaphores are also the only way to ensure
coherent access to parameters shared between the two Microengines.
Attempting to lock one semaphore (even not successfully) frees the other locked by the same Engine,
ensuring one can lock just one semaphore at a time. That prevents deadlock conditions between the two
Engines.
Microcode END command or Engine being in idle state (no thread executing) automatically releases all
semaphores from one Engine side, even if a semaphore lock is done in parallel. However, it is
recommended to write the microcode in a way which locks semaphores for the shortest required period,
and frees them without waiting for the END command, to improve the performance of the other
microengine. Semaphores are free after reset. An Engine can only free a sempaphore locked by itself.
Semaphore lock requests are always
non-blocking
, in the sense that they do not suspend the requester in
case the semaphore is already locked. The semaphore status after the lock request - indicating if it was
successfully locked or not - must be tested through the SMLCK microengine branch condition (see
Section 23.4.8.4, “Branch Conditions
).
23.4.4.5
SPRAM Arbitration
Up to four entities can access SPRAM:
•
two Microengines (in a dual eTPU Engine system)
•
the Coherent Dual-parameter Controller (CDC)
•
the Host CPU (direct memory-mapped access)
The following rules specify the access priorities for contended access. They keep compatibility with the
TPU3 dual parameter access atomicity, but only between the microengine and CDC (not Host accesses
through Skyblue bus).
1. Microengine accesses from the two eTPU Engines are interleaved between each other, but not with
Host or CDC accesses;
2. The eTPU microengine(s) gives priority for SPRAM accesses to either the Host CPU or the CDC
under any of the following conditions:
a.
the microengine has completed accessing the second parameter in a back-to-back SPRAM
access
1
.
1.
if microengine tries to access the SPRAM in the following microcycles, the third and fourth consecutive accesses are
considered the first and second of a new back-to-back dual access.