GR740-UM-DS, Nov 2017, Version 1.7
304
www.cobham.com/gaisler
GR740
The core has support for specifying the processor reset start address dynamically. Please see section
21.2.10 for further information.
21.2.5 Interrupt broadcasting
An incoming interrupt request that has its bit set in the Broadcast Register is propagated to the force
register of
all
CPUs instead of to the Pending Register. This can be used to implement a timer that
fires to all CPUs with that same IRQ.
21.2.6 Interrupt timestamping description
Interrupt timestamping is controlled via the Interrupt Timestamp Control registers. Each Interrupt
Timestamp Control register contains a field (TSTAMP) that contains the number of timestamp regis-
ters sets that the core implements. A timestamp register sets consist of one Interrupt Timestamp
Counter register, one Interrupt Timestamp Control register, one Interrupt Assertion Timestamp regis-
ter and one Interrupt Acknowledge Timestamp register.
Software enables timestamping for a specific interrupt via a Interrupt Timestamp Control Register.
When the selected interrupt line is asserted, software will save the current value of the interrupt time-
stamp counter into the Interrupt Assertion Timestamp register and set the S1 field in the Interrupt
Timestamp Control Register. When the processor acknowledges the interrupt, the S2 field of the Inter-
rupt Timestamp Control register will be set and the current value of the timestamp counter will be
saved in the Interrupt Acknowledge Timestamp Register. The difference between the Interrupt Asser-
tion timestamp and the Interrupt Acknowledge timestamp is the number of system clock cycles that
was required for the processor to react to the interrupt and divert execution to the trap handler.
The core can be configured to stamp only the first occurrence of an interrupt or to continuously stamp
interrupts. The behavior is controlled via the Keep Stamp (KS) field in the Interrupt Timestamp Con-
trol Register. If KS is set, only the first assertion and acknowledge of an interrupt is stamped. Soft-
ware must then clear the S1 and S2 fields for a new timestamp to be taken. If Keep Stamp is disabled
(KS field not set), the controller will update the Interrupt Assertion Timestamp Register every time
the selected interrupt line is asserted. In this case the controller will also automatically clear the S2
field and also update the Interrupt Acknowledge Timestamp register with the current value when the
interrupt is acknowledged.
For controllers with extended ASMP support, each internal controller has a dedicated set of Interrupt
timestamp registers. This means that the Interrupt Acknowledge Timestamp Register(s) on a specific
controller will only be updated if and when the processor connected to the controller acknowledges
the selected interrupt. The Interrupt Timestamp Counter is shared by all controllers and the DSU timer
is used as the time source. The same timer source can also be read via the processors’ internal up-
counter described in section 6.10.4.
21.2.7 Interrupt timestamping usage guidelines
Note that KS = ‘0’ and a high interrupt rate may cause the Interrupt Assertion Timestamp register to
be updated (and the S2 field reset) before the processor has acknowledged the first occurrence of the
interrupt. When the processor then acknowledges the first occurrence, the Interrupt Acknowledge
Timestamp register will be updated and the difference between the two Timestamp registers will not
show how long it took the processor to react to the first interrupt request. If the interrupt frequency is
expected to be high it is recommended to keep the first stamp (KS field set to ‘1’) in order to get reli-
able measurements. KS = ‘0’ should not be used in systems that include cores that use level interrupts,
the timestamp logic will register each cycle that the interrupt line is asserted as an interrupt.
In order to measure the full interrupt handling latency in a system, software should also read the cur-
rent value of the Interrupt Timestamp Counter when entering the interrupt handler. In the typical case,
a software driver’s interrupt handler reads a status register and then determines the action to take.
Adding a read of the timestamp counter before this status register read can give an accurate view of
the latency during interrupt handling.