Transcript Mid Semester Presentation - High Speed Digital Systems Laboratory

‫ מכון טכנולוגי לישראל‬- ‫הטכניון‬
‫הפקולטה להנדסת חשמל‬
Technion - Israel Institute of Technology
Department of Electrical Engineering
High Speed Digital Systems Laboratory
‫המעבדה למערכות ספרתיות מהירות‬
Reliable CAN Bus
Midterm Presentation
Performed by : Rivka Cohen and Sharon Solomon
Instructor : Walter Isaschar
Duration : Year
Spring 2004
General Background
Why Micro Satellites ?
Micro satellites will
weight much less than
regular satellites,
thus reducing the cost
of the lunch drastically
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 here
Traditional Computer Design
Error !
PPC405
Arbiter
OPB
Custom
Logic
Memory
Controller
I/O
Memory
The problem :
Single damaged component
jeopardizes the entire system
NOT RELIABLE !
Possible Solutions
Network topology
Redundancy
Using network creates several
paths between each two
devices, which helps error
handling
CPU
Memory
CPU
Router
Router
Custom
Logic
Using multiple buses helps
recognizing and overcoming
bus errors
I/O
Memory
Custom
Logic
I/O
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
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
The Development Environment - Software
HDL Designer 2003 (by Mentor) :
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
The Development Environment - Software
HDL Designer 2003
The Development Environment - Software
ModelSim
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.
The Development Environment - Software
Signals
ModelSim
Waveform
The Development Environment - Software
EDK (Embedded Development Kit) 6.2
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…)
The Development Environment - Software
EDK (Embedded Development Kit) 6.2
The Development Environment - Software
ChipScope Pro :
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
The Development Environment - Software
ChipScope Pro
The Development Environment - Hardware
The Development Board
(by Memec Design)
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
PPC405 : PLB and OPB buses
First Semester – Final Plan
Memory
PPC405
Arbiter
OPB
OPB
to
CAN
Custom
Logic
Second
Step
UART
CAN devices
First Step
I/O
I/O
First Semester - Summery of work

 Study VHDL & HDL Designer, Modelsim, Edk 6.2,
Chipscope Pro, Synplify Pro and Leonardo

 Study the VirtexII Pro development board by
writing simple applications with and without the
CPU, and testing them with ChipScope Pro Analyzer

 Study the CAN Protocol and IPIC Core
(Intellectual Property InterConnect)
First Semester - Summery of work
First Semester - Summery of work
The Results… (please click on images)
First Semester Timeline – Review
8th
week
 Write a simple application that uses the IPIC
 Design a small system, containing three devices on one
channel, that can “talk” CAN protocol with each other
9th-10th
week
11-12th  Design the OPB2CAN device, which
translates PPC405 PLB protocol to CAN
week
13th
week
14th
week
 Design a complete CAN based computer
by connecting the PPC405 via OPB2CAN
to other devices on the CAN channel
 Final corrections and debugging
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.
IP InterConnect (continued)
Block Diagram – First Step
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<0> for device #1, LED<1> for device #2)
LED<0>
LED<1>
CAN Device
#3
CAN
Controller
Push_Button<0>
LED<1> CAN Device
#2
GO !
CAN Bus
CAN Device
#1
LED<0>
GO !
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
Our Solution :
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
Block Diagram – Second Step
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).
OPB
to
CAN
Second
Step
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
3
Second Semester Goals (continued)
Redundancy
Network topology
Using multiple buses helps
recognizing and overcoming
bus errors
CPU
Memory
Custom
Logic
I/O
Using network creates several
paths between each two
devices, which helps error
handling
CPU
Memory
Router
Router
Custom
Logic
I/O
The End