1. 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 Part A Final Presentation

2. Micro satellites - General Background  Micro satellites will weight much less than regular satellites, thus reducing the cost of the lunch drastically Why Micro Satellites ?  In addition, less design area means lower vulnerability from cosmic radiation  And of course, more units put in one chip, means major expenses reduction for the design and manufacturing

3. Micro satellites - General Background  The problem in space is that the computer inside the satellite is exposed to great amount of cosmic radiation. This may result in bit flips, or dysfunctional components.  Bit flips can damage data in memory, bus transactions and CPU operations. Damaged components can stuck the system, as shown on the next slide.  We wish to develop satellites that will weight much less but will still have all the functionality of today’s satellites

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

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

6. Our Solution CAN Redundancy Memory Using multiple OPB2CAN units. When one unit fails, we switch to the other unit. CPU CAN Device #1 CAN Device #2 CAN Device #3 OPB2CAN (Default) OPB2CAN (Backup)

7. The Solution – CAN Protocol  Single Channel : the bus consists of a single serial channel that carries bits  Based on four messages 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  CAN (Controller Area Network) protocol, originally designed by BOSCH for vehicle control system, is now widely used due to its high reliability

8. 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

9. CAN Protocol (continued) Arbitration and Dominant/Recessive bits 0’ is the dominant bit, therefore Module 1 lost the arbitration to Module 2

10. 10 First Step Second Step Our Approach to Part A PPC405 OPB Arbiter Memory OPB to CAN I/O UART Custom Logic CAN devices

11. Simultaneous Writing Issue 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 through 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 :

12. 12 CAN Device Connector Can Device Connector is a unit that connects CAN devices to the CAN bus. CAN Device Connector CAN Device No. 1 CAN Device No. 2 CAN Device No. 3 C A N B u s UNIT 1UNIT 2 UNIT 3 CAN Device Connector CAN Device Connector

13. 13 CAN Device Connector – Block Diagram External device sideCAN Bus side Top of Design

14. 14 CAN Device Connector – Block Diagram Top of Design External device side CAN Bus side  This is the top level of the CAN Device Connector, as shown in HDL Designer  We applied changes to the design, mainly to the control unit. Inside the control unit lies the error handling unit, which we designed almost from scratch  We acquired this design from a finished project named “Communication unit based on CAN protocol”, done by Ohad Gidon and Ilan Dgani

15. 15 CAN Device Connector– Block Diagram External device side CAN Bus side

16. 16  If a unit detects an error on the bus, it starts to transmit error messages. Those error messages have higher priority on the bus than regular messages. CAN Error Handling - Overview  If the unit Transmitter/Receiver Error Counter (TEC, REC) reaches 128 the unit switches itself to Error Passive mode (lower priority).  If the unit transmitter error counter (in passive mode) reaches 256, (the unit might be damaged),the unit turns itself off (Bus Off mode).

17. 17 CAN Error Handling – Disconnecting a device  As explained in previous slide, when TEC (Transmitter Error Counter) reaches 256, the unit shuts itself down.  We obviously can’t rely on a faulty device to shut itself down. Therefore, this is done by the CAN Device Connector that connects the external device to the CAN Bus.  Assuming that the CAN Device Connector is much simpler than the external devices connected to it, we can claim that errors are much less likely to effect it. CAN Device Connector Faulty CAN Device! CAN Bus Responsible for disconnecting the faulty device

18. 18 CAN Error Handling – State Diagram  When a unit is in Bus Off state, it waits 128 cycles of 11 dominant bits on the bus until returning to Error Active Mode.  1’ is the recessive bit on the bus so we get an effect of Time Out, giving the unit time to recover.

19. 19 OPB2CAN  OPB2CAN is an interface between the CAN Device Connector and the OPB Bus in the VirtexII Pro chip. OPB2CAN IPIF Our User Logic (VHDL) IPIC To OPB To CAN Connector

20. 20 The Development Environment - Software HDL Designer 2003 (by Mentor) ModelSim EDK (Embedded Development Kit) 6.2 ChipScope Pro

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

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

23. 23 PPC405 : PLB and OPB buses

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. 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)

27. First Semester - Summary of work  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  Write a simple application that uses the IPIC

28. 3 Second Semester Goals  Examine multiple OPB2CAN architecture which can lead to higher level of fail-proof system  Final Goal: Fully operative system, based on CAN Protocol, including simulation of error management and correct operation in case of a faulty device

29. Second Semester Goals – Block Diagram CAN Redundancy Using multiple OPB2CAN units. When one unit fails, we switch to the other unit. Memory CPU CAN Device #1 CAN Device #2 CAN Device #3 OPB2CAN (Default) OPB2CAN (Backup)

30. Second Semester Goals – Demonstration Memory CPU CAN Device #2 CAN Device #3 OPB2CAN (Default) OPB2CAN (Backup) CAN Device #1 I will switch to bus #2 I will switch to backup OPB2CAN OPB2CAN (Backup)

31. Second Semester Goals (continued) LAN2CAN  We wish to connect our design to PC through LAN. We then can use commands from the PC to control our design and receive detailed information on the working units  The VirtexII Pro board is equipped with the P160 Expansion Module which allow connectivity to LAN, USB, monitor, etc. P160 Expansion Module LAN connector

32. Second Semester - Timeline  Defining the system : the topology of the system, the OPB2CAN units and error handling Week 1-2Week 3-7  Design the units to meet the requirements that we specified, and enable CPU access to the handling information on the OPB2CAN units Week 8-10  Design the error handling techniques we agreed on Week 11-13  Implement a LAN2CAN interface, so we can control and monitor the entire system from a PC Week 14  Final corrections and debugging

33. Part A Demonstration PPC405 OPB OPB2CAN C A N Bus Device 1 Dip-switches Device 2 LEDs Arbitration check Device 3 (winning) Device 4 (losing) \ Error handling check Device 5 Error generator Device 6 Error counter

34. Special Thanks  We would like to thank Ina for helping us with many problems we encounter during our work.  We also like to thank Konstantin Moiseev who helped us a lot during the learning process.  Also thanks to Zigi, who guided us through our work and helped us to find the right way when we where stuck  And finally, special thanks to Eli, who suggested us this interesting project, and gave us advices and ideas all along Thank You All Very Much

35. The End

36. Special Thanks  We would like to thank Ina for helping us with many problems we encounter during our work.  We also like to thank Konstantin Moiseev who helped us a lot during the learning process.  Also thanks to Zigi, who guided us through our work and helped us to find the right way when we where stuck  And finally, special thanks to Eli, who suggested us this interesting project, and gave us advices and ideas all along Thank You All Very Much