End of First Semester Presentation DigiSat Reliable Computer – Multiprocessor Control System. Niv Best, Shai Israeli Instructor: Oren Kerem HS-DS Lab, Technion, Winter 2003 This presentation will probably involve audience discussion, which will create action items. Use PowerPoint to keep track of these action items during your presentation In Slide Show, click on the right mouse button Select “Meeting Minder” Select the “Action Items” tab Type in action items as they come up Click OK to dismiss this box This will automatically create an Action Item slide at the end of your presentation with your points entered.

Project Goals Design & implement a hardware mechanism for multiprocessor monitoring & control. Part of the DigiSat reliable computer project.

The DigiSat Computer PowerPC based. Implemented upon the Virtex II-pro platform. Hardware redundancy throughout the entire system. Our project handles processor redundancy & control.

Description Satellites contain redundant hardware since servicing in space is not applicable. A monitoring system is required to identify & handle malfunctions. Must be implemented in hardware.

DigiSat Computer PPC1 PLB1 DATA ROUTE M1 M2 S1 S2 PPC2 PLB2 Our Project

Technology Virtex II-pro FPGA with embedded PowerPC cores.

PowerPC bit RISC core. Low power consumption. Used in various system-on-chip (SoC) applications (PDAs, network routers, cellular phones…). Embedded within the Virtex II-pro platform.

PowerPC Interfaces RST EIC CPU CPM DBG ISPLB DSPLB

Software Used

Current Status Simulated a PowerPC system using ModelSim 5_6d. Built autonomic monitoring sub-systems that survey PowerPC hardware outputs. Studied Assembler programming of the PowerPC. Built state-machine for controller.

The Processor Controller

Controller State Machine (General) PPC_1 Online PPC_2 Online Switch 1  2 Switch 2  1 Error detected

Controller State-Machine Diagram

Signals Involved SignalI/OAffectsComments c405cpmtimerresetreqOCPM Timer Reset Request c405xxxmachinecheckOCPU Machine Check Error c405dbgstopackOEIC Stop Acknowledge c405rstchipresetreqORST Chip Reset Request c405plbdcuwritethruODSPLB Write Thru c405rstcoreresetreqORST Core Reset Request C405rstsysresetreqORST System Reset Request Bus_error_DetOPLBBus Error Dbgc405debughaltIDBG Debug Halt cpmc405clockICPMInput clock rstc405resetcoreIRST Reset Core sys_rstIPLBPLB RST plb_clkIPLBPLB CLK

Controller Implementation CPU1 CPU2 PLB1 PLB2 Controller + Arbiter MUX P_Sel To/From Peripherals External Signals

Controller Implementation

Controller Sub-Modules Core/Chip/System reset requests monitor. Timer reset request monitor. Write-thru monitor. Machine check error monitor. PLB error monitor.

Reset Requests Monitor Monitored signals: 1. Chip reset request (c405rstchipresetreq) 2. Core reset request (c405rstcoreresetreq) 3. System reset request (c405rstsysresetreq) If asserted, the required reset action is performed. Processors switch upon core reset request.

Timer Reset Monitor Monitored signal: c405cpmtimerresetreq The signal is the logical “OR” of the reset request signals. Serves as another way for resetting the system. Monitored along with the regular reset request signals – checks the watchdog functionality.

Timer Monitor Diagram Wt_to_chkr Chip reset request Watchdog timer Error C405rstchipresetreqC405rstcoreresetreqC405rstsysresetreqc405cpmtimerresetreqWt_to_err Timer reset request System reset request Core reset request

Write-Thru Monitor Write-back policy is unreliable in space. Monitored signal: c405plbdcuwritethru. Should remain high during normal operation. Low state – error in MMU.

Write-Thru Monitor Diagram writethruChecker PPC write-thru policy Write-thru Error c405plbdcuwritethruwritethru_err

Bus Error Monitor PPC core & PLB are “tightly coupled”. Monitored signal: bus_error_det Asserted when a bus error interrupt occurs. Implies an error has occurred within the PLB arbiter. Preliminary inspection of the PLB arbiter.

Bus Error Monitor Diagram BusErrorChecker Bus_error_detect Bus_err

Monitor Arbiters Our system consists of 3 identical monitoring sub-systems and an arbiter that uses majority voting to decide if an error signal is reliable. There are 2 ways of using the arbiters:

“ One Monitor to Rule Them All …” 1.Each signal is monitored thrice, passed on to an arbiter, then checked by ERR_Mon. M1 ARB M3 ARB M2 ARB Err_Mon Controller M1 ARB M3 ARB M2 ARB Err_Mon

“ The Fellowship of The Signals ” 2.Each signal batch is monitored by Err_Mon, results are passed onto an arbiter. Controller M1 M3 M2Err_Mon M1 M3 M2Err_Mon M1 M3 M2Err_Mon ARB M1 M3 M2Err_Mon M1 M3 M2Err_Mon M1 M3 M2Err_Mon ARB

Monitor Arbiters err1err2err3Err_out

Controller Demonstration

Schedule Find a way to initiate CoreReset on PPC. (3 weeks) Find more ways to monitor the PPC. (5 weeks) Write WatchDog software to check internal parts of PPC. (8 weeks) Download hardware to chip and run tests on single PPC. (11 weeks) Wait for chip with dual cores. (T.B.D)