Presentation is loading. Please wait.

Presentation is loading. Please wait.

Students:Guy Derry Gil Wiechman Instructor: Isaschar Walter Winter 2003 Students:Guy Derry Gil Wiechman Instructor: Isaschar Walter Winter 2003 טכניון.

Similar presentations


Presentation on theme: "Students:Guy Derry Gil Wiechman Instructor: Isaschar Walter Winter 2003 Students:Guy Derry Gil Wiechman Instructor: Isaschar Walter Winter 2003 טכניון."— Presentation transcript:

1 Students:Guy Derry Gil Wiechman Instructor: Isaschar Walter Winter 2003 Students:Guy Derry Gil Wiechman Instructor: Isaschar Walter Winter 2003 טכניון – מכון טכנולוגי לישראל הפקולטה להנדסת חשמל PowerPC based reliable computer Part A presentation

2 Problem: In space, VLSI devices are exposed to large amounts of cosmic radiation, since there is no atmosphere to filter it out. Therefore, the MTBF of electronic equipment in space is greatly reduced. Problem: In space, VLSI devices are exposed to large amounts of cosmic radiation, since there is no atmosphere to filter it out. Therefore, the MTBF of electronic equipment in space is greatly reduced. Solution: Design of redundant devices to be used in space systems, hence increasing overall system reliability. Solution: Design of redundant devices to be used in space systems, hence increasing overall system reliability.

3 Project goals Develop a working prototype of a satellite computer, implementing the peripheral device monitoring and operation algorithm. Examine policies of managing redundant peripherals and select one. Implement the chosen algorithm on the Virtex II Pro FPGA board

4 Implementation tools The project is implemented using the following tools:

5 Project Assumptions In this project, we assume correct operation of the software, on a correctly operating single processor. In this project, we assume correct operation of the software, on a correctly operating single processor. The issue of multiple processors handling is examined under a different project, running concurrently to ours. The issue of multiple processors handling is examined under a different project, running concurrently to ours.

6 PPC405 PLB PLB MUX PPC405 PLB Bus System Overview Arbiter #1 PLB MUX PLB #1 PLB #2 Arbiter #2 Peripheral redundancy project Processor redundancy project PPC405 PLB PLB MUX PPC405 PLB Bus

7 System Overview (cont.) PLB MUX PLB #1 PLB #2 Arbiter #1Arbiter #2 Memory-fault Monitor Memory-fault Monitor M1M2M3 P1P2P3P1P2P3 Transparent Corrector Transparent Corrector Transparent Corrector Transparent Corrector PLB Monitor master PLB Monitor slave PLB Monitor master PLB Monitor slave

8 PPC405 General block diagram P1P2P3 PLB Arbiter M1M2M3 Memory-fault Monitor PLB Monitor (master) PLB Monitor (slave) Transparent Corrector Transparent Corrector

9 PLB Monitor - Master Read_Odd Countdown Reset_Bus Read_Even State description: Countdown: count N clock cycles Read_Even / Read_Odd : Read from slave unit address #1/2. If expected value is not received, try again until success or three consequent failures. Reset_Bus: Reset the bus, and read it. If bus is not reset to zero, try again until success or three consequent failures. State description: Countdown: count N clock cycles Read_Even / Read_Odd : Read from slave unit address #1/2. If expected value is not received, try again until success or three consequent failures. Reset_Bus: Reset the bus, and read it. If bus is not reset to zero, try again until success or three consequent failures. ALL TESTS: 3 consequent failures  Interrupt to CPU.

10 PLB Monitor – Master: implementation (1/3) Read Even / Odd: Request #1 Ack. #1 Request #2 Ack. #2 Request #3 Ack. #3 Next checkup Fault interrupt Prev. checkup

11 PLB Monitor – Master: implementation (2/3) Bus reset: Reset request Check #7 Check #1 Check #6 Check #2 Check #5 Next checkup Fault interrupt Prev. checkup

12 PLB Monitor – Master: implementation (3/3) Watchdog: start_dog watchdog = (2**11)-1 reset_dog= '1' 2 1 watchdog<=0; Count 2 3 reset_dog='1' 1 watchdog < (2**11)-1 watchdog<=watchdog+1; Bark dog_fail <= '1' ;

13 PLB Monitor - Slave While (1) { While ( Addr_On_Bus != Addr1 && Addr_On_Bus != Addr2 ); If ( Addr_On_Bus == Addr1 ) Write_To_Bus(0xAAAAAAAA); Else /* Addr_On_Bus == Addr2 */ Write_To_Bus(0x ); }

14 PLB Monitor – Slave: implementation

15 Transparent Corrector Maj(P1,P2,P3) = P1  P2 + P1  P3 + P2  P3 Bus / Outside World Peripheral1 Peripheral2 Peripheral3

16 Memory-Fault Monitor Description: Sits between the PLB bus and memory controllers. On a write, performs a write to four different addresses, the writes are checked (reads are performed) and thus each of the four memory blocks is graded. On a read performs a read from all four memory addresses and a bit wise majority vote on the top ranked three. All wrong memory addresses are corrected. When Idle, performs auto majority votes and correction on the most recently used addresses.

17 Memory-Fault Monitor Schematics: PPC405 PLB Arbiter M1M2M3 Coherency Handler Mem Con 1 Mem Con 2 Mem Con 3 Transparent Corrector Transparent Corrector

18 Project Progress Report – Qtr. II Learned PPC programming Implemented a test design with a PLB UART. Implemented a test design on the board working with the PPC, OPB UARTlite, and an OPB GPIO.

19 Project Schedule – Qtr. II (cont.) Implemented transparent correctors. Developed an initial approach in memory coherency handling system Implemented Master & Slave PLB monitors. Implemented Master & Slave PLB monitors.

20 Project schedule - First Semester Summary Synthesized a system on the FPGA including use of redundant peripherals and non redundant memory. Multiple peripheral unit operation ability Basically all the theoretical study is completed, and the bumpy start was overcome.

21 Project schedule - Second Semester Incorporate PLB monitoring implementations into design. (~2 weeks) Study interaction protocol between memory fault monitor and memory controllers. (~1 week) Study memory management strategies and select one.(~1 week)

22 Implement memory fault monitor. (~2 weeks) Connect memory monitor to memory controllers and test on simulation tool. (~1 week) Build a test bench for memory monitor. (~1 week) Project schedule - Second Semester (cont.)

23 Incorporate memory unit into the design and test it.(~2 weeks) Build the PLB-MUX. (~1 week) Project schedule - Second Semester (cont.) Overall debugging. (~2 weeks)

24 Final goal: fully operative system incl. a simulation of an identification and correct operation in case of a faulty device. Project schedule - Second Semester (cont.)


Download ppt "Students:Guy Derry Gil Wiechman Instructor: Isaschar Walter Winter 2003 Students:Guy Derry Gil Wiechman Instructor: Isaschar Walter Winter 2003 טכניון."

Similar presentations


Ads by Google