## 4 Hardware Implementation of CPU-SPU Collaborative SoC
### Hardware Implementation of Instruction Monitor  
After we complete the offline preparation works of the program BB partition and the BB's \(INF_{ref}\) extraction from the instruction codes (InsCodes), our following phase is the hardware implementation of the instruction monitor to provide a high-efficiency instruction violation detection relying on the proposed fine-grained BB integrity monitoring. As the instruction codes will be executed in the five-stage pipeline processor in a sequential order, the instruction monitor will verify the BB integrity signatures according to the sequential order of program execution. The hardware architecture details of the proposed instruction monitor connecting with the CPU are illustrated in Figure 6.  
The CPU exports the physical addresses of instructions from the PC, the instruction codes from the ID stage, and the delayed tags from a synchronizer logic, respectively. These three parameters are the input signals of our hardware-implemented instruction monitor. Then, a finite state machine (FSM) IP is configured to keep track of the branch and jump instruction executions with their control-state transitions, which can also identify the BB boundary of the start address (also being the target address of previous transfer instructions) and end address with a delay slot instruction after the branch or jump operation.  
Under the control of FSM IP, when the start address (\(ADD_{start}\)) of each BB is input into the LHash engine as an activated signal, the InsCode streams will be continuously  
Figure 5: Example of instruction tampering attack and fault recovery aim at the benchmark of OpenECC.  
pumped into the LHash engine to recalculate a 96-bit LHash digest after following the BB's InsCodes executions. Moreover, we provide a selection logic of 16-bit RNG bit-selected numbers to generate the 16-bit LHash digest (\(DIG_{cal}\)).  
In another path, an additional monitor cache (M-Cache) is configured to buffer parts of \(INF_{ref}\) blocks from the monitor memory. The instruction monitor searches the cache lines of M-Cache according to the received \(ADD_{start}\) of each BB. If the M-Cache hits, the corresponding \(INF_{ref}\) block is input an intercept logic for obtaining the 16-bit BB integrity digest of \(INF_{ref}[15:0]\) as the golden LHash (\(DIG_{llash}\)); if M-Cache misses, the instruction monitor starts to search the \(ADD_{start}\) in the monitor memory. If it succeeds, a two-input multiplexer (MUX) controlled by the states of hit/miss receives the \(INF_{ref}[15:0]\) after the intercept logic; if it fails to search, the monitor asserts an invalid signal of BB absence to the processor.  
When M-Cache hits or memory hits, the recalculated \(DIG_{cal}\) will be compared with the prestored \(DIG_{llash}\) in the integrity checker. The instruction monitor asserts the BB as a valid status when their compared result is equal. Otherwise, the instruction monitor asserts the BB as an invalid status, and we preset the LHash value error with the invalid status \"01\", and the start address error with the invalid status \"10\" (BB absence).  
Ultimately, the BB's invalid signal will be sent not only to the Exception module of the CPU when the instruction monitor detects a violation of BB integrity but also to the FSRM in the SPU to activate checkpoint-rollback operation, and hold the CPU_Stall signal to suspend the execution pipeline. In the CPU-SPU collaborative SoC architecture, the exception signal is nonmaskable to trigger both a fast-response and the self-repairing mechanisms of the CPU and FSRM. While FSRM repairs the instruction fault, the rollback recovery logic still asserts the CPU_Stall signal until the successful checkpoint-rollback operation. It is noteworthy that the above delayed tag signal is configured to improve the checking efficiency of BB integrity; it helps to reduce the performance overhead of the instruction monitor.