The time between the freezing of the PMA counter and the
instruction which caused the exception may depend on the
number of Root Board hierarchies involved.
These times have to be determined for all types of
exceptions and on each machine configuration. I.e. the
table below should be completed some time ...
Note that in case of Tz exceptions the corresponding PMA
is frozen instantaneously, while the freezing of the other
Tz has to propagate via the Root hierarchy. Hence, PMAs may
be disalligned in case of Tz exceptions, and the time delay
beteween generation of the exception in the freezing of the
PMA is small.
In case case of Jn exceptions, the exception is always propagated
via the Root hierarchy. Hence, the all Tz PMAs should be frozen
at the same time and after certain delay (at least O(0x22=34)
cycles??? [Piero]).
Note: If a masked exception was encountered, the corresponding
bit remains set (and hence is shown in the exception message
when an unmasked exception is encountered).
Note: The PMA shown in the status registes (usually) seems to
not take into account the mirroring of the PM banks (i.e.
usually the address of the lower bank is shown)
EXC MC PMA-t(MC) [cycles]
board unit crate rack
------------------------------------------------------------
HALT HALT 0 0 ??? ???
BREAK BREAK 0 0 ??? ???
ADD OVF TADD 1 1 ??? ???
DM MER MEMTOT ??? ??? ??? ???
PM MER JMP ??? ??? ??? ???
...
------------------------------------------------------------
SOFTEX JEX even 27 31 ??? ???
JEX odd 26 30 ??? ???
FILU JSNORM even 35 39 ??? ???
JSNORM odd 34 38 ??? ???
LUT LUTINV even 27 31 ??? ???
LUTINV odd 26 30 ??? ???
BPE MCI even 35,37 41 ??? ??? *)
BPE MCO even ??? ??? ??? ???
BND VIOL MCI even 35 41 ??? ???
BND VIOL JTOMEM
DM MER MEMTOJ ??? ??? ??? ???
*) Not strictly reproducible even on same board!!!
