1 / 24

PowerPC based reliable computer

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

Download Presentation

PowerPC based reliable computer

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

  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. 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: Synplify Pro

  5. Project Assumptions 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.

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

  7. PLB Monitor master PLB Monitor master P1 P1 M1 P2 P2 M2 M3 P3 P3 Memory-fault Monitor Transparent Corrector Transparent Corrector PLB #2 PLB #1 Memory-fault Monitor Transparent Corrector Transparent Corrector PLB Monitor slave PLB Monitor slave Arbiter #2 Arbiter #1 System Overview (cont.) PLB MUX

  8. PLB Monitor (master) Transparent Corrector Transparent Corrector P1 P2 P3 Memory-fault Monitor PLB Monitor (slave) M1 M2 M3 General block diagram PPC405 PLB Arbiter

  9. 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. Countdown Read_Even Read_Odd Reset_Bus ALL TESTS:3 consequent failures  Interrupt to CPU. PLB Monitor - Master

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

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

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

  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(0x55555555); }

  14. lwait2 lwait1 1 lAddrAck eDataXfer ecomp slAddrAck 2 erdAck 1 3 5 idle 4 2 ordAck 2 shAddrAck hAddrAck 1 oDataXfer ocomp hwait2 hwait1 PLB Monitor – Slave:implementation

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

  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. Transparent Corrector Mem Con 1 Mem Con 2 Mem Con 3 Transparent Corrector Coherency Handler M1 M2 M3 Memory-Fault Monitor Schematics: PPC405 PLB Arbiter

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

  19. Project Schedule – Qtr. II (cont.) Implemented transparent correctors. Developed an initial approach in memory coherency handling system 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 memory management strategies and select one. (~1 week) • Study interaction protocol between memory fault monitor and memory controllers.(~1 week)

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

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

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

More Related