Compaq EV68A specifications Restriction 11 Ibox IPR Update Synchronization, Restriction 14 Hwret

Restriction 11: Ibox IPR Update Synchronization

D.8 Restriction 11: Ibox IPR Update Synchronization

When updating any Ibox IPR, a return to native (virtual) mode should use the HW_RET instruction with the associated STALL bit set to ensure that the updated IPR value affects all instructions following the return path. The new IPR value takes effect only after the associated HW_MTPR instruction is retired.

For update to some IPR fields with propagation delay, such as I_CTL[SDE] and PCTX[FPE], synchronization as described in Section D.32 is the preferred method of synchronization.

D.9 Restriction 12: MFPR of Implicitly-Written IPRs EXC_ADDR, IVA_FORM, and EXC_SUM

Implicitly written IPRs are non-renamed hardware registers that must be available for subsequent traps. After any trap to PALcode, hardware protects the values from a sec- ond implicit write by locking these registers and delaying subsequent traps for a safe (limited time). Their values can be read reliably by a HW_MFPR within the first four instructions of a PALcode flow and prior to any taken branch in that PALcode flow, whichever is earlier. These instructions should not include PALmode trapping instruc- tions. After the delimiting instruction defined above retires, these registers are unlocked and may change due to new exception conditions.

If a second exception occurs before the registers are unlocked, it will be either delayed or forced to replay trap (a non-PALmode trap) until the register has been unlocked. After being unlocked, a subsequent new path exception condition will be allowed to reload the register and trap to PALcode. The 21264/EV68A may complete execution of the first PALcode flow, encountering the second exception condition before the delimit- ing instruction is retired, hence the need for the locking mechanism to ensure visibility of the initial register value.

The VA_FORM, VA, and MM_STAT registers are not included in this list of protected IPRS. See Section D.24 for a description of how to protect these IPRs from subsequent implicit writers.

D.10 Restriction 13 : DTB Fill Flow Collision

Two DTB fill flows might collide such that the HW_MTPR’s in the second fill could be issued before all of the HW_MTPR’s in the first PALcode flow are retired. This can be prevented by putting appropriate software scoreboard barriers in the PALcode flow.

D.11 Restriction 14 : HW_RET

There can be no HW_RET in the first fetch block of a PALcode routine, other

than CALL_PAL routines. With a HW_RET in the first fetch block of a PALcode rou- tine, the HW_RET will be mispredicted and the JSR/RETURN stack could lose its syn- chronization.

21264/EV68A Hardware Reference Manual PALcode Restrictions and Guidelines D–11