
Architecture of the eTPU Channel
Understanding the eTPU Channel Hardware, Rev. 0
Freescale Semiconductor
11
2.5.1
Requests to the Scheduler
Service requests from any source are made to the eTPU Scheduler. When the Scheduler grants a service
request for a channel, it selects an entry vector according to the conditions that are present when the request
is granted. Details of this operation are covered elsewhere, but the following points are important to
understand the response of the eTPU engine to a channel service request:
Regardless of the order of the requests, multiple service requests from a channel are granted
according to the conditions that exist at the time of granting.
The entry vector selected as a result of a service request grant is statically determined by the
selected entry vector table (see the Reference Manual). It is clear that if an HSR is asserted at the
time of request grant, that will uniquely determine the vector, because where HSR bits are
non-zero, channel and link bits are “don’t Care”.
If there are no HSR bits asserted, a channel request or a link is required to raise a service request.
Additional bits such as pin state or flags may be used to further qualify the state.
The assertion of a match recognition latch in Action Unit A is ORed with the assertion of a
transition detect latch in Action Unit B. Likewise, the assertion of a match recognition latch in
Action Unit B is ORed with the assertion of a transition detect latch in Action Unit A. In many
cases this will be sufficient to resolve the exact thread that needs to be executed, but if not, the
software must further resolve the uncertainty.
All service requests remain until the source is cleared. HSRs are cleared by execution of an end
statement in the software, which is usually caused by closing the final brace in the C source for
the entry. Link, match and transition flags must be explicitly cleared in the software. If they are
not cleared, the scheduler will re-schedule the request after the thread is complete.
If multiple sources have requested action, the software may execute one thread, clearing one
source and exit and leaving the rest of the requests to their own schedule and execute cycle. If
time is critical, the software can be designed to test the additional service request sources before
the original thread is ended, and execute additional code to service those requests.
Any thread can clear any or all pending request conditions.
Example 3.
...
else if (matchB_transA) // Here on Match 2 (stall) or Transition 1 (Tooth edge)
{
if (IsTransALatched()) //If the Tooth edge is detected
{
/* Here we do the routine to capture and process the input transition. This
lengthy thread from the Automotive Reference Design is not quoted here except to
illustrate the handling of multiple service request sources.
*/
ClearTransLatch(); // Clears the Transition latches
SetupMatch_B((EdgeCaptureTime + StallPeriod), Mtcr1_Ctcr1_ge,
match_no_change); //this also clears a MatchB latch