1. Performed by : Rivka Cohen and Sharon Solomon Instructor : Walter Isaschar המעבדה למערכות ספרתיות מהירות High Speed Digital Systems Laboratory הטכניון - מכון טכנולוגי לישראל הפקולטה להנדסת חשמל Technion - Israel Institute of Technology Department of Electrical Engineering Duration : Year Reliable CAN Bus Spring 2004 Midterm Presentation

2. General Background Why Micro Satellites ? Micro satellites will weight much less than regular satellites, thus reducing the cost of the lunch drastically

3. General Background (continued) The problem in space is that the computer inside the satellite is exposed to great amount of cosmic radiation.This may result in bitflips, or dysfunctional components. Bitflips can damage data in memory, bus transactions and CPU operations. Damaged components can stuck the system, as shown herehere

4. Traditional Computer Design The problem : Single damaged component jeopardizes the entire system NOT RELIABLE ! PPC405 OPB Arbiter Memory Controller Memory I/O Custom Logic Error !

5. Possible Solutions Redundancy CPU I/O Memory Custom Logic Using multiple buses helps recognizing and overcoming bus errors Network topology CPU Memory Custom Logic I/O Router Using network creates several paths between each two devices, which helps error handling

6. The Solution – CAN Protocol  CAN protocol, originally designed by BOSCH for vehicle control system, is now widely used due to its high reliability  Single Channel : the bus consists of a single serial channel that carries bits  Based on four massages types : Data frame, Remote frame, Error frame and Overload frame  Flexible : adding new components is simple  Smart Error Management : faulty components can be recognized and ignored - improves reliability

7. CAN Protocol (continued)  The typical bandwidth of CAN is ~100Kbits/sec, but speed varies between 10Kbits/sec to 1Mbit/sec, according to the CAN wire length

8. The Development Environment - Software Provides graphical tools for designing block diagrams, state machines, flow charts, and truth tables. HDL Designer takes the graphical design and generates VHDL ore Verilog Code for simulation and shynthesis HDL Designer 2003 (by Mentor) :

9. The Development Environment - Software HDL Designer 2003

10. The Development Environment - Software Provides graphical simulation tools in order to check the VHDL implementations written in HDL Designer.The Signals windows shows the internal and external signals in the project,and the Waveform window enables monitoring the chosen signals. ModelSim

11. The Development Environment - Software ModelSim Waveform Signals

12. The Development Environment - Software EDK is a program for designing embedded systems on FPGA. It provides software development (C language) for PPC405 along with pin connection configuration. EDK uses Synplify Pro for synthesis. EDK runs the flow (synthesis, P&R, downloding) in one easy step (given there are no errors…) EDK (Embedded Development Kit) 6.2

13. The Development Environment - Software EDK (Embedded Development Kit) 6.2

14. The Development Environment - Software ChipScope Pro provides real-time bit monitoring of the data on the board, via the JTAG cable. By examining it’s output, we know exactly what happens on the board, and can verify our design ChipScope Pro :

15. The Development Environment - Software ChipScope Pro

16. The Development Environment - Hardware The Development Board (by Memec Design)

17. The Development Environment - Hardware The Development Board (by Memec Design) is equipped with : - Xilinx ViretexII Pro which icludes : - PowerPC (PPC405) RISC proccesor - FPGA area - 44KByte on-chip RAM memory - 8M X 32 SDRAM memory - Four RocketIO trancivers (2.5 Gbits/sec) - 2X16 LCD screen, LEDs, Dips, Push buttons and debug ports

18. PPC405 : PLB and OPB buses

19. First Step Second Step First Semester – Final Plan PPC405 OPB Arbiter Memory OPB to CAN I/O UART Custom Logic CAN devices

20. First Semester - Summery of work  Study the VirtexII Pro development board by writing simple applications with and without the CPU, and testing them with ChipScope Pro Analyzer  Study VHDL & HDL Designer, Modelsim, Edk 6.2, Chipscope Pro, Synplify Pro and Leonardo  Study the CAN Protocol and IPIC Core (Intellectual Property InterConnect)

21. First Semester - Summery of work

22. The Results… (please click on images)

23. First Semester Timeline – Review  Design a small system, containing three devices on one channel, that can “talk” CAN protocol with each other  Design the OPB2CAN device, which translates PPC405 PLB protocol to CAN  Design a complete CAN based computer by connecting the PPC405 via OPB2CAN to other devices on the CAN channel  Final corrections and debugging 8 th week 9th-10th week 11-12th week 13th week  Write a simple application that uses the IPIC 14th week

24. IP InterConnect IP InterConnect is a bus interface core provided by Xilinx, which simplify the user connection to the OPB bus. The IPIC provides only the necessary signals for communication with the bus. The bus protocol, signals and timing issues are taken care of by the IPIF (Intellectual Property InterFace). If we want to transfer our design to a different CPU, all we have to do is to change the IPIF.

25. IP InterConnect (continued)

26. LED Push_Button Block Diagram – First Step LED CAN Bus CAN Device #1 CAN Device #2 CAN Device #3 LED GO ! LED GO ! Simple CAN application : The user pushes a button. the CAN controller decides which of the two CAN devices (#1 or #2) gets to send a massage on the bus, and the result is shown in the LEDs (LED for device #1, LED for device #2) CAN Controller

27. Block Diagram ( continued ) The problem with CAN protocol : CAN is based on on the ability of multiple devices to drive a value on the same channel simultaneously AND Connecting all devices on the bus thru an AND gate. This allows the devices to “talk” simultaneously on the bus without causing an electrical violation. It is also required to add a read line for each device, because AND gate is not bi-directional Our Solution :

28. Block Diagram – Second Step Second Step OPB to CAN The OPB to CAN is an interface between our CAN bus and the OPB bus. It will use the IPIC to transmit signals between the CAN bus and the CPU (through the OPB).

29. 3 Second Semester Goals  Examine various bus architectures such as redundancy and network (with routers)  Final Goal: Fully operative system, based on CAN Protocol, including simulation of error management and correct operation in case of a faulty device

30. Second Semester Goals (continued) Redundancy CPU I/O Memory Custom Logic Using multiple buses helps recognizing and overcoming bus errors Network topology CPU Memory Custom Logic I/O Router Using network creates several paths between each two devices, which helps error handling

31. The End