CONTROLLER AREA NETWORK PROTOCOL; DESIGN …ethesis.nitrkl.ac.in/4057/1/Final_Thesis_Tapas.pdf · Cadence SoC encounter is used for automatic place and route and cadence icfb is used

CONTROLLER

PROTOCOL;

A THESIS SUBMITTED IN PARTIAL FULFILLMENT

OF THE REQUIREMENTS FOR THE DEGREE OF

VLSI Design & Embedded Systems

Department of Electronics & Communication Engineering

National Institute of Technology,

CONTROLLER AREA NETWORK

PROTOCOL; DESIGN TO TAPEOUT



Master of Technology

in


Submitted By

TAPAS RANJAN JENA

Roll # 210EC2310



Rourkela – 769008

NETWORK

TAPEOUT


CONTROLLER

PROTOCOL;




Prof. A. K. Swain and Prof. K. K. Mahapatra



CONTROLLER AREA NETWORK

PROTOCOL; DESIGN TO TAPEOUT



Master of Technology in


Submitted By

TAPAS RANJAN JENA

Roll # 210EC2310

Under the guidance of




Rourkela – 769008

NETWORK

TAPEOUT



National Institute o

This is to certify that the thesis entitled,

PROTOCOL; DESIGN TO

(210EC2310) in partial fulfilment of the requirements for the award of Master of Technology

degree in Electronics and Communication Engineering

and Embedded System” during session 2011

Rourkela (Deemed University) and is an authentic work

guidance.

To the best of our knowledge, the matter embodied in the thesis has not been submitted to

any other university/institute for the award of any Degree or Dipl

Date: Prof.

National Institute of Technology

Rourkela

CERTIFICATE

This is to certify that the thesis entitled, “CONTROLLER AREA

TO TAPEOUT” submitted by TAPAS RANJAN JENA

in partial fulfilment of the requirements for the award of Master of Technology

Electronics and Communication Engineering with specialization in

during session 2011-2012 at National Institute of Technology,

and is an authentic work done by him under our

knowledge, the matter embodied in the thesis has not been submitted to

any other university/institute for the award of any Degree or Diploma.

Prof. A.K. SWAIN Prof. K. K. Mahapatra

Dept. of Electronics & Communication


Rourkela

AREA NETWORK

TAPAS RANJAN JENA

in partial fulfilment of the requirements for the award of Master of Technology

with specialization in “VLSI Design

2012 at National Institute of Technology,

our supervision and

knowledge, the matter embodied in the thesis has not been submitted to

Prof. K. K. Mahapatra

ommunication Engineering


Rourkela-769008

Dedicated to My Parents

And

My Teachers

Submitted by TAPAS RANJAN JENA [210EC2310] Page iv

ACKNOWLEDGEMENT

I would like to express my gratitude to my thesis guide Prof.A. K. SWAIN and Prof. K. K.

Mahapatra for his guidance, advice and constant support throughout my thesis work. I would

like to thank him for being my advisor here at National Institute of Technology, Rourkela.

Next, I want to express my respects to Prof.D.P.Acharya, Prof. P. K. Tiwari, Prof.N. Islam,

Prof. S.K. Patra, for teaching me and also helping me how to learn. They have been great

sources of inspiration to me and I thank them from the bottom of my heart.

I would like to thank all faculty members and staff of the Department of Electronics and

Communication Engineering, N.I.T. Rourkela for their generous help in various ways for the

completion of this thesis.

I would like to thank all my friends and especially my classmates for all the thoughtful and mind

stimulating discussions we had, which prompted us to think beyond the obvious. I’ve enjoyed

their companionship so much during my stay at NIT, Rourkela.

I am especially indebted to my parents for their love, sacrifice, and support. They are my first

teachers after I came to this world and have set great examples for me about how to live, study,

and work.

TAPAS RANJAN JENA [email protected]

Submitted by TAPAS RANJAN JENA [210EC2310] Page v

CONTENTS

ACKNOWLEDGEMENT ………………………………………………………………… - iv -

ABSTRACT ……………………………………………………………………………….. - xi -

Chapter 1 .................................................................................................................................... - 1 -

1.1 INTRODUCTION ....................................................................................................... - 2 -

1.2 HISTORY .................................................................................................................... - 2 -

1.3 NECESSITY OF COMMUNICATION PROTOCOL LIKE CAN ............................ - 3 -

1.4 CAN APPLICATIONS ............................................................................................... - 4 -

1.5 CAN-IN-AUTOMATION (CiA) ................................................................................ - 4 -

1.6 INTERNATIONAL STANDARD ISO 11898 ........................................................... - 5 -

1.7 MOTIVATION ............................................................................................................ - 5 -

1.8 PROBLEM BEING ADDRESSED ............................................................................ - 6 -

1.9 ORGANIZATION OF THE THESIS ......................................................................... - 7 -

Chapter 2 ......................................................................................................................................... 8

2.1 INTRODUCTION ............................................................................................................ 9

2.2 ISO/OSI MODEL ........................................................................................................... 10

2.3 BUS ARBITRATION .................................................................................................... 12

2.4 CAN MESSAGE FRAME ............................................................................................. 13

2.5 DATA FRAME .............................................................................................................. 13

2.5.1 Start of Frame (SoF) ................................................................................................ 14

Submitted by TAPAS RANJAN JENA [210EC2310] Page vi

2.5.2 Arbitration Field ...................................................................................................... 14

2.5.3 Control Field ........................................................................................................... 15

2.5.4 Data Field ................................................................................................................ 15

2.5.5 CRC Field ................................................................................................................ 15

2.5.6 Acknowledgement Field ......................................................................................... 15

2.5.7 End of Frame Field .................................................................................................. 15

2.5.8 Inter Frame Space (IFS) .......................................................................................... 16

2.6 REMOTE FRAME ......................................................................................................... 16

2.7 ERROR FRAME ............................................................................................................ 17

2.8 OVERLOAD FRAME ................................................................................................... 18

2.9 BIT REPRESENTATION .............................................................................................. 18

2.10 BIT ENCODING ............................................................................................................ 19

2.11 BIT STUFFING .............................................................................................................. 20

2.11.1 Selective Xor Masking ........................................................................................ 20

2.11.2 Software Bit Stuffing (SBS) .................................................................................... 20

2.11.3 Eight-To-Eleven Modulation (EEM)................................................................... 21

2.11.4 Implementation of EEM Algorithm ........................................................................ 22

Chapter 3 ....................................................................................................................................... 24

3.1 INTRODUCTION .......................................................................................................... 25

3.2 DESIGN DESCRIPTION .............................................................................................. 25

Submitted by TAPAS RANJAN JENA [210EC2310] Page vii

3.3 GENERAL DESIGN FLOW ......................................................................................... 27

3.4 SPECIFICATION AND RTL CODING ........................................................................ 28

3.5 SIMULATION AND VERIFICATION ......................................................................... 28

3.6 SYNTHESIS ................................................................................................................... 29

3.7 FORMAL VERIFICATION........................................................................................... 30

3.8 STATIC TIMING ANALYSIS ...................................................................................... 30

3.9 PHYSICAL DESIGN ..................................................................................................... 30

Chapter 4 ....................................................................................................................................... 32

4.1 DESIGN DESCRIPTION .............................................................................................. 33

4.1.1 Host CPU: ............................................................................................................... 33

4.1.2 Parameter Register: ................................................................................................. 33

4.1.3 Transmitter Buffers: ................................................................................................ 34

4.1.4 Data/Remote Frame Generator: .............................................................................. 34

4.1.5 Parallel- to-Serial: ................................................................................................... 34

4.1.6 Tx CRC Generator: ................................................................................................. 34

4.1.7 Bit Stuff Unit: .......................................................................................................... 35

4.1.8 Overload / Error frame Generator: .......................................................................... 35

4.1.9 Serialized Frame Transmitter: ................................................................................. 35

4.1.10 Message Processor: ................................................................................................. 35

4.1.11 Arbitration Control: ................................................................................................. 35

Submitted by TAPAS RANJAN JENA [210EC2310] Page viii

4.1.12 Synchronizer: .......................................................................................................... 36

4.1.13 Bit De-stuff Unit: .................................................................................................... 36

4.1.14 Error Checker: ......................................................................................................... 36

4.1.15 Acceptance Checker: ............................................................................................... 36

4.1.16 Receive Buffer: ....................................................................................................... 36

Chapter 5 ....................................................................................................................................... 37

5.1 RTL SIMULATION ....................................................................................................... 38

5.1.1 Parameter register .................................................................................................... 38

5.1.2 Transmission buffer................................................................................................. 39

5.1.3 Data Remote Frame Generator ................................................................................ 39

5.1.4 Parallel to serial converter ....................................................................................... 40

5.1.5 Transmission CRC Generator ................................................................................. 41

5.1.6 Bit stuffing............................................................................................................... 41

5.1.7 Serialized Frame Transmitter .................................................................................. 42

5.1.8 CAN Wire-ending Results ...................................................................................... 42

5.1.9 Comparison of SBS and EEM ................................................................................. 44

5.2 COVERAGE ANALYSIS .............................................................................................. 45

5.2.1 Condition Coverage................................................................................................. 45

5.2.2 Line Coverage ......................................................................................................... 46

5.3 SYNTHESIS REPORT .................................................................................................. 46

Submitted by TAPAS RANJAN JENA [210EC2310] Page ix

5.3.1 Power Report ........................................................................................................... 47

5.3.2 Timing Report ......................................................................................................... 48

5.3.3 Area Report ............................................................................................................. 51

5.4 GATE LEVEL SIMULATION RESULTS .................................................................... 51

5.5 PLACE AND ROUTE ................................................................................................... 52

5.5.1 Gate Count Report ................................................................................................... 53

5.6 SYMBOL AND SCHEMATIC GENERATION ........................................................... 55

5.7 LAYOUT VERIFICATION ........................................................................................... 57

5.8 INTEGRATION FOR TAPE-OUT ................................................................................ 58

Chapter 6 ....................................................................................................................................... 59

6.1 CONCLUSION .............................................................................................................. 60

Chapter 7 ....................................................................................................................................... 61

7.1 FUTURE WORK ........................................................................................................... 62

Submitted by TAPAS RANJAN JENA [210EC2310] Page x

List of Figure

Figure 1-1 : Automobile subsystems without CAN ................................................................... - 3 -

Figure 1-2 : Automobile subsystems with CAN ........................................................................ - 4 -

Figure 1-3 : CAN controller interconnection ............................................................................. - 7 -

Figure 2-1 : Distributed CAN network ........................................................................................... 9

Figure 2-2 : ISO/OSI Model.......................................................................................................... 10

Figure 2-3 : CAN Physical Layer .................................................................................................. 11

Figure 2-4 : Layered ISO 11898 Standard Architecture ............................................................... 12

Figure 2-5 : CAN Bus Arbitration ................................................................................................ 13

Figure 2-6 : Data Frame Architecture ........................................................................................... 13

Figure 2-7 : Detailed Data frame Architecture .............................................................................. 14

Figure 2-8 : End of Frame Field .................................................................................................... 15

Figure 2-9 : Inter-frame Space ...................................................................................................... 16

Figure 2-10 : Remote Frame Architecture .................................................................................... 17

Figure 2-11 : Error Frame Architecture ........................................................................................ 17

Figure 2-12 : Overload Frame Architecture .................................................................................. 18

Figure 2-13 : CAN Bit Representation .......................................................................................... 19

Figure 2-14 : CAN Bit encoding (a) Manchester encoding (b) NRZ encoding ............................ 19

Figure 2-15 : Bit Stuffing .............................................................................................................. 20

Figure 2-16 Encoding data byte in EEM method (SB stands for “stuffed bit”) ........................... 22

Figure 2-17 EEM Algorithm Implementation[5] .......................................................................... 23

Figure 3-1 : Traditional ASIC Design Flow [9] ............................................................................ 26

Figure 3-2 : Test-bench and Design under verification................................................................. 28

Figure 3-3 : Design Compiler Flow .............................................................................................. 29

Figure 3-4 : Physical Design Flow [9] .......................................................................................... 31

Figure 4-1 : CAN Architecture...................................................................................................... 33

Figure 5-1 Simulation Results for Parameter register ................................................................... 38

Figure 5-2 Simulation Results for Transmission Buffer ............................................................... 39

Figure 5-3 Simulation Results for Data Remote frame Generation .............................................. 40

Figure 5-4 Simulation Results for Parallel to Serial Converter .................................................... 40

Submitted by TAPAS RANJAN JENA [210EC2310] Page xi

Figure 5-5 Simulation Results for Transmission CRC Generation ............................................... 41

Figure 5-6 Simulation Results for Bit Stuffing ............................................................................. 41

Figure 5-7 Simulation Results for Serilized Frame Transmitter .................................................. 42

Figure 5-8 Simulation Results for CAN Wire-Anding using EEM .............................................. 42

Figure 5-9 Simulation Results for CAN Wire-Anding using SBS................................................ 43

Figure 5-10 Comparision of SBS with EEM ................................................................................ 44

Figure 5-11 Condition Coverage Analysis .................................................................................... 45

Figure 5-12 Line Coverage Analysis ............................................................................................ 46

Figure 5-13 Synthesis using VCS Design Vision ......................................................................... 47

Figure 5-14 Synthesized Gate level Simulation result .................................................................. 52

Figure 5-15 Place and Route in SoC Encounter ............................................................................ 53

Figure 5-16 CAN Symbol Generated from Gate level Netlist ...................................................... 56

Figure 5-17 CAN Schematic Generated from Gate level Netlist .................................................. 56

Figure 5-18 CAN Layout Generated from GDSII ........................................................................ 57

Figure 5-19 CAN Final Integration with PAD Ring ..................................................................... 58

Figure 7-1 CAN in Real time Application .................................................................................... 62

Submitted by TAPAS RANJAN JENA [210EC2310] Page xii

ABSTRACT

Control area network (CAN) is a two- wired, half duplex, high-speed network system, that is far

superior to conventional serial communication protocol such as RS232, with regards to

functionality and reliability and yet CAN implementations are more cost effective. CAN is a

serial network technology that is widely used in real-time automobile control. It is a multi-master

serial bus that uses broadcast to transmit to all CAN nodes. It is good for short message transfer.

Its data transfer size is limited to 8 bytes with 1 Mbps speed. It provides a significant reduction

in wiring complexity and additionally makes it easy to connect with several devices using a

single bus. CAN provides an effective mechanism for clock synchronization known as “bit-

stuffing”. It is very difficult to predict the precise transmission time of message which leads to an

adverse impact on many time critical applications. To mitigate above problem different “bit-

stuffing” techniques such as XOR masking and Software Bit Stuffing (SBS) are available in the

literature. In this thesis a novel alternative method known as Eight-to-Eleven Modulation (EEM)

technique is used for “bit-stuffing” and a comparison is brought with existing SBS technique and

the superior features of EEM is derived. The proposed technique is validated through FPGA

implementation.

In this thesis, design to tape out is perform for a CAN controller. The Register Transfer Level

(RTL) coding is done by Verilog HDL (Hardware Description Language). Synopsys VCS

simulator is used to simulate the RTL code. Synthesized netlist is created by using Synopsys

Design Vision. Cadence SoC encounter is used for automatic place and route and cadence icfb is

used for final integration of the design with the pad ring. Final GDS II file is created for tape-out.

UMC 180 mixed mode library is used for implementing the system with six metal layers and one

poly layer.

Keywords:

RTL, GDS, Simulation, Test bench, Verilog, CAN, Tape-out, Synthesis, I/O PAD, EEM,

SBS, Bit stuffing.

Chapter 1

Overview

1. INTRODUCTION

2. HISTORY

3. NECESSITY OF COMMUNICATION PROTOCOL

LIKE CAN

4. CAN APPLICATIONS

5. CAN-IN-AUTOMATION (CiA)

6. INTERNATIONAL STANDARD ISO 11898

7. MOTIVATION

8. PROBLEM BEING ADDRESSED

9. ORGANIZATION OF THE THESIS

Chapter 1 Overview

Submitted by TAPAS RANJAN JENA [210EC2310] Page - 2 -

1.1 INTRODUCTION

Controller Area Network (CAN) is a serial communication network technology that was

originally designed for the automotive industry, especially for European cars, but has become a

popular bus in industrial automation as well as other applications. CAN is a two-wire, high-

speed, half duplex network system, that is far superior to conventional serial technology like

RS232 and TCP/IP. It provides better ease of use than any other serial bus system and operates at

data rates of up to 1 Megabit per second [1].

A CAN system transferred information between the sub-system with the help of a commonly

shared central bus. CAN is a multi-master communication protocol. At any instant of time any

node can be a master and others can be a slave. It follows bus topology, it reduces the wiring of

the system and the damage of one sub-system will not affect the performance of other sub-

systems [2].

CAN networks can be used as an embedded communication system for intelligent device. Some

users, for example in the field of medical engineering used CAN because they have to meet

particular stringent safety requirements. Similar requirements had to be considered by

manufacture of other equipment with very high safety or reliability requirements (e.g. robots,

lifts and transportation systems) [1]-[4] .

1.2 HISTORY

The idea of Controller Area Network (CAN) was developed by Robert Bosch GmbH of

Germany in the early 1980s. The investigation for a suitable field-bus technology for use in

automobiles enables to add further functionality. The main focus was a communication system

between a number of ECUs (electronic control units) in vehicles.

The involvement of several universities in Germany, the vehicle manufacturer like Mercedes-

Benz and the semiconductor manufacturer like Intel, Philips helped to make CAN a triumphant

story. The CAN standard was first introduced in 1986. The first CAN controller chips, the Intel

82526 and the Philips 82C200, were introduced in 1987.

Chapter 1 Overview


1.3 NECESSITY OF COMMUNICATION PROTOCOL LIKE CAN

Figure 1-1 : Automobile subsystems without CAN

It is the prime requirement of a system to exchange the data among their sub-systems for

improving the functionality and maintaining the accuracy. The easier way is to connect the sub-

systems individually with point to point wiring as shown in the Figure 1-1. Due to modular

design and increasing the sub-system the complexity of interconnection increased a lot to

maintain the accuracy in functionality. This hampers the reliability, production time and material

cost. To overcome this situation a new protocol like CAN is developed. In this protocol all the

subsystems are connected through each other with the help of a commonly shared serial bus as

shown in the Figure 1-2. This system architecture reduces the system wiring complexity, reduces

the material cost and also increases the reliability of the overall system.

In this protocol only one sub-system can transmit at a time and the others can listen. The sub-

systems have got the access of the bus time slice basis. The first requested subsystem will get the

bus access first. It is good for short message transfer. CAN protocol can transfer up to 8 bytes of

data at a time.

Chapter 1 Overview


Figure 1-2 : Automobile subsystems with CAN

1.4 CAN APPLICATIONS

One frequently asked question about CAN is that, where CAN is successfully used. There is no

special place for CAN; its use is universal from any industrial application, maritime, space and

aviation, household applications such as washing machine, dryers, coffee maker and also in

medical application.

The main advantage of a field bus system like CAN is that it reduces the wiring expanses and

also reduces the maintenance. It also increases the performances of a distributed system [13].

CAN is best suitable for serial bus communication.

1.5 CAN-IN-AUTOMATION (CiA)

CAN in Automation (CiA) is the international organization by manufacturer and user. The prime

objectives of the organization are to supports and develop CAN standard and CAN-based higher

layer protocol. CiA representatives actively support international standardization of CAN

protocols and represents the members interests in national and international standardization

committees, such as ISO and IEC. CiA members develop the specifications as CiA standards.

Chapter 1 Overview


These specifications include physical layer definitions as well as application layer and device

description [7].

1.6 INTERNATIONAL STANDARD ISO 11898

ISO (International Organization for Standardization) is a worldwide federation. ISO provides

international standards which are decided and enlisted by the technical committees. Each

member of the ISO has the rights to participate in the process of standardization of the

corresponding subject.

The ISO 11898 standard is meant for Road vehicles – Controller area network (CAN). It was

first published in 1993. ISO 11898 consists of the following parts:

• Data link layer and physical signaling

• High speed medium access unit

• Low speed, fault tolerant medium dependent interface

• Time triggered communication

1.7 MOTIVATION

We realize that CAN is an important communication protocol that finds extensive use in

automotive and other industrial sectors. There are a few publications in the literature on ASIC for

CAN protocol. The design details are also not quite available. Therefore, we make an attempt to

come up with IC design with maximum possible details and with proposed EEM. The complete

CAN module is divided into several sub-modules. We develop FSM for each case. Integrate

these sub-modules to work as a single unit that can work as CAN protocol controller.

In this thesis the main objective is to design an ASIC for Control Area Network protocol

controller. Verilog HDL is used to develop the Register Transfer Level (RTL) models for a CAN

controller. The functional simulation of the model is obtained. Reception and transmission of the

CAN controller are verified by taking two and four CAN controller connected together in a

network.

Chapter 1 Overview


Coverage analysis is done to describe the degree to which the source code of a program has been

tested and also to measure how well the program is exercised by a test case.

After RTL simulation synthesis is done for the designed model and the dynamic simulation is

performed on the Gate Level Netlist to verify the further functionality of the CAN protocol

controller. The timing constraints specified for the system is verified by using static timing

analysis.

By using the gate level netlist automatic routing is done to obtain the final layout of the systems.

The violations of Design Rule is Checked and finally GDSII (Graphic Data System II) is

extracted from the system layout.

1.8 PROBLEM BEING ADDRESSED

Here the problem is going to discuss about the design and development of an application specific

integrated circuit for a CAN controller. Sensor and actuator are used to interface a CAN

controller with an application. Sensor and actuator both are carrying analog signals. As all the

input to the CAN controller is digital, system needs an ADC (Analog to Digital Converter) to

interface the sensor and actuator. The output of the ADC is fed into a microprocessor to process

the data before giving to the CAN controller.

The un-formatted message from the microprocessor is converted into the protocol specific

formatted data with the help of the CAN controller. CAN transceiver is used to convert the

digital signal from CAN controller to electrical pulses and gives to the CAN bus. The detail

signal flow is shown in the Figure 1-3.

Chapter 1 Overview


Figure 1-3 : CAN controller interconnection

1.9 ORGANIZATION OF THE THESIS

The organization of the thesis is described as follows.

Chapter 2 gives the general overview of the standard format Controller Area Network protocol

specification. This includes different frames and their structures.

Chapter 3 discussed the Application Specific Integrated Circuit (ASIC) design flow in brief.

The CAD (Computer Added Design) tools and the library used during tape-out processed also

discussed in brief.

Chapter 4 gives the general overview of the Controller Area Network Architecture.

Chapter 5 shows the different result obtained in different stages of the ASIC design flow.

Chapter 6 brings out the conclusion of the thesis and Chapter 7 define the future work of the

thesis

Chapter 2

Specification

1. INTRODUCTION

2. ISO/OSI MODEL

3. BUS ARBITRATION

4. CAN MESSAGE FRAME

5. DATA FRAME

6. REMOTE FRAME

7. ERROR FRAME

8. OVERLOAD FRAME

9. BIT REPRESENTATION

10. BIT ENCODING

11. BIT STUFFING

Chapter 2 Specification

Submitted by TAPAS RANJAN JENA [210EC2310] Page 9

2.1 INTRODUCTION

Different communication protocols are designed based on their application in different field.

Based on uses they are differ from one another as “higher end “ and “lower end” protocols.

Higher end protocols are used for overall factory system information, known as factory bus.

Lower end protocols are used for inter-processor communication, known as field bus [2].

Now day’s automobile industries develop different electronic systems to maintain the

growing demand for more comfort, safety and efficient fuel reduction technology. So the

whole system is divided into several subsystems. Each subsystem is connected with each

other with a dedicated wire line which increases the complexity of the wiring. To overcome

this type of wiring complexity new protocol like Controller Area Network (CAN) protocol

developed. In CAN network all the subsystems are connected through each other by a

commonly shared central bus. CAN bus is consists of two wire serial data bus and the speed

is up to 1MBits/s [6].

An example of CAN network is shown in the Figure 2-1. Each node in the network represents

a CAN controller. Each node is connected with each other by commonly connected CAN bus.

The nodes are exchange data to the processor through their sensors and actuators. The

controller first job is to be formatted the message received from the sensor and give to CAN

bus, the second job is to filter the received message from the CAN bus and give back to the

actuator.

Figure 2-1 : Distributed CAN network



2.2 ISO/OSI MODEL

CAN is an International Standardization Organization (ISO) defined serial communications

bus for the automotive industry to replace the complex wiring with a two-wire bus [4].

Open Systems Interconnection is a standard reference model for how messages should be

sent between any two points in a telecommunications network. Engineers follow OSI

standards to make sure that the products they develop will communicate properly with other

products [3].

In the OSI model, data communications are organized into a hierarchy of seven different

functions. Each function is a separate layer in the model. The top layer relates directly to the

software application or hardware device that seeks to send messages across a network, while

the bottom layer refers to the actual bit traffic.

Layer 7 Application Defines communications partners, type of service and

security

Layer 6 Presentation Converts data from one format to another, such as from a

text file to a popup window display that text

Layer 5 Session Opens, coordinates and ends conversations and exchanges

of data between two applications

Layer 4 Transport Manages error checking and verifies that packets are

delivered

Layer 3 Network Routes and forwards data to the proper destination

Layer 2 Data Link Builds data packets and synchronizes network traffic

Layer 1 Physical Conveys the actual bit stream across the network. Manages

the hardware and the mechanical process for sending and

receiving data

Figure 2-2 : ISO/OSI Model

Many communication systems do not use all seven OSI layers in their system design. The

Controller Area Network system involves the transmission of simple, short messages to

trigger event and it does not need to account for system security, presentation or monitoring



network logins or sessions. Hence only Physical and Data link layers are included in the

ISO/OSI 11898 specification [3].

Figure 2-3 : CAN Physical Layer

Physical layer of CAN manages the connection between the nodes in a network and the

actual transmission of electrical impulses across a connecting media. It translates message

receive from the data link layers into an electronic signal. On the same way in the receiving

end, physical layer converts the electronic signals back into a message format. Thus it

provides standards for bit timing, bit representation and bit synchronization [3].

Data link layer builds messages or packets or data frame to hold data and control information.

Control information helps to determine access to bus, identify frames and detect errors. Part

of the control information is used to avoid conflicts when two messages try to access the

CAN bus at a time, a function is known as Medium Access Control (MAC). The main

function of the MAC in CAN protocol is to determine which message having a higher

priority, and will get the bus access first.

During transmission sometimes messages are corrupted by the external noise. To detect this

situation Control information is also contained some code for the receiving node to determine

whether the message is corrupted during transmission or not [3].

Figure 2-4 shows the different functionality of the CAN protocol in different layer.



Figure 2-4 : Layered ISO 11898 Standard Architecture

2.3 BUS ARBITRATION

Since a serial communication system such as CAN is based on a two-wire connection

between nodes in the network, that is all nodes are sharing the same physical communication

bus, a method of message/frame collision avoidance is compulsory to assure a safe data

transfer and to avoid delays resulting from the necessary restoration of proper bus condition

after the collision.

A collision may occur when two or more nodes in the network are trying to access the bus at

virtually the same time, which may result in unwanted effects, such as bus access delays or

even destruction or damage of message [7].

CAN provide a non-destructive bus arbitration, which means no message gets lost. The

higher priority message will get the bus access first, while low priority message wait until the

bus is free.

Figure 2-5 shows an example of the non-destructive bus arbitration. Node 1 and Node 2

trying to access the bus same time, but the priority of the message transmitted by node 1 is

more than the priority of the message transmitted by node 2. So node 1 got the access of the

bus first and node 2 has to wait till node 1 finished transmission.



Figure 2-5 : CAN Bus Arbitration

2.4 CAN MESSAGE FRAME

A frame is a packet of information that contains a complete message from a transmitter to a

receiver. Control area network systems have four different types of frame.

A standard message frame used to transmit data over the network known as Data Frame.

Remote Frame is used by the receiver to request data from the transmitter. The receiver

sends the Error Frame to re-transmit the last received message. An Overload Frame is

similar to an error frame. A receiver would typically send out an Overload Frame to ask a

transmitter to delay the next message sent [2].

2.5 DATA FRAME

A data frame broadcasts the actual message to the CAN bus. A data frame is uniquely

identified by a unique message ID. A data frame can be received by any number of nodes

based on the application structure, but can transmit by only one node. A data frame has a

fixed format and capable of transmitting variable data length up to 8 bytes. The frame

structure of a data frame is given in the Figure 2-6. A data frame consists of eight different

fields, they are Start of Frame (SoF), Arbitration Field, Control Field, Data Field, CRC Field,

Acknowledgement Field, End of Frame (EoF) and Inter Frame Space (IFS).

Figure 2-6 : Data Frame Architecture

The total frame as shown in Figure 2-7 has variable length between 47 bits to 111bits, based

on the length of the data field, which can be 0 to 8 bytes (i.e. 0 to 64 bits).



2.5.1 Start of Frame (SoF)

Start of Frame (SoF) bit is a dominant bit which represents the start of start of data frame. A

CAN node gets the access of the bus when the bus is ideal. An ideal bus is detected by a

sequence of consecutive 11 recessive bits.

Figure 2-7 : Detailed Data frame Architecture

2.5.2 Arbitration Field

There are two types of arbitration field, one is Standard Format having 12 bit length and the

other is Extended Format having 32 bit length. We are here using standard format arbitration

field. The arbitration field has two components.

• 11 bit Message identifier

• 1 bit RTR (Remote Transmission Request)

The first bit of the message identifier bit is taken as MSB for determining the message id.

This is the unique identification id of a particular message. Lower the message ID more the

priority of the message. RTR field indicates whether the transmitted data frame is a Data

Frame (RTR=0) or Remote Frame (RTR=1). A Data Frame is always having higher priority

than a Remote Frame. A 11 bit identifier allows a total of 211 (2048) different message id [7].



2.5.3 Control Field

The length of the control field is 6 bits long. The 4 LSB bits of the control field is known as

Data Length Code (DLC) which specify the length of the data block. The MSB bit is 0 for

Standard Format and is 1 for the Extended Format message frame.

The Data Length Code (DLC) is usually set to a value between “0” to “8” indicates a data

field contains data of “0” to “8” byte length. Any DLC value greater than “8” will be

considered as “8” byte data length.

2.5.4 Data Field

The size of the data field in both Standard Frame and Extended Frame is 8 bytes.

2.5.5 CRC Field

The Cyclic Recovery Check (CRC) Field consists of the CRC Sequence and a CRC delimiter

bit. CRC Field is 15 bits long, which contain the frame check sequence covering from Start of

Frame (SoF) to the data field. The CRC delimiter bit is always set as recessive.

2.5.6 Acknowledgement Field

The size of the acknowledgement field is 2 bits. This consists of acknowledgement slot (1 bit)

and acknowledgement delimiter (1 bit). The acknowledgement field gives the confirmation

about the successful CRC check by the receiving nodes in the network.

2.5.7 End of Frame Field

Each data or remote frame is terminated by a sequence of 7 consecutive recessive bits.

Figure 2-8 : End of Frame Field



As shown in the Figure 2-8 there are 11 recessive bits at the end of a message frame. These

bits are not subjected to bit stuffing error detection as the bit stuffing applies only between

the Start of Frame bit and the CRC Sequence.

2.5.8 Inter Frame Space (IFS)

IFS define the minimum space between any frame of any type (remote, data, overload, error).

During IFS no frame is node is allowed to transmit any bit. Only overload signaling condition

is allowed. For data frame the size of IFS is 3 bits. There is no IFS between error and

overload frame.

Figure 2-9 : Inter-frame Space

2.6 REMOTE FRAME

A Remote Frame is requested by a receiving node to transmit the desired data from

transmitted node. On the response to the remote frame the transmitter node sends the data

frame. Remote frame and the requested data frame use the same message identifier. Both the

frames are distinguished by the remote transmission request bit of the arbitration field. When

a data frame and a remote frame both having same message id trying to get the access of the

bus same time, the data frame will get the bus access, first since the data frame uses the

dominant RTR bit.

The structure of a Remote Frame is same as Data Frame, but the only difference is that

Remote Frame does not have a data field and it uses high RTR (Remote Transmission

Request) bit. The detailed structure of the Remote frame is shown in the Figure 2-10 [7].



Figure 2-10 : Remote Frame Architecture

2.7 ERROR FRAME

An error frame initiates the termination of a damaged data or remote frame. This is actually

done by violating the CAN standard. According to CAN standard for maintaining the

synchronization there should not be more than 5 consecutive same polarity bit. One extra bit

i.e. Minimum 6 consecutive bits of the same polarity bit initiates the error frame. When the

error frame is detected the transmitter stop transmitting the current frame and start

retransmitting the frame again.

Figure 2-11 : Error Frame Architecture

As shown in the Figure 2-11 the error frame consists of error flag of 6 size bit and error

delimiter of size 8 bits. The error flag is to violate CAN standard by transmitting same

polarity bit. The bits can be dominant or recessive based on this it is called active error flag

(dominant bit) or passive error flag (recessive bit). The error delimiter is represented by a

sequence of 8 recessive bits. An error detecting node, after completing the error flag, will

send the first recessive bit to the bus. The node will continue sending a recessive level until

the bus actually turns recessive.



2.8 OVERLOAD FRAME

An overload frame is a special version of an error frame, but unlike an error frame is does not

cause the retransmission of the previous frame. It contains an overload flag of 6 bits and an

overload delimiter of 8 bits. The overload frame structure is shown in the Figure 2-12.

Figure 2-12 : Overload Frame Architecture

An overload frame is used by a node to request a delay between two data or remote frame.

That means an overload frame can only occur between data or remote frame transmissions.

The overload frame is transmitted by a node that is temporarily overloaded and will not be

able to participate in any CAN bus communication. As a result the transmission of the data or

remote frame by a node in the network will be delayed until the end of the overload frame

[7].

2.9 BIT REPRESENTATION

The physical media used by CAN bus is a differentially driven pair of wires. These two wires

are commonly known as CAN_L and CAN_H. It provides very reliable signal transmission

despite of low signal level and common mode errors. It uses bus topology which is easy to

connect and less affected by the network failures.

There are two bit representations used in the CAN protocol. CAN protocol define logic “0” as

a dominant bus state and logic “1” as a recessive bus state. The bit representation is shown in

the Figure 2-13. Recessive state occurs when both CAN_L and CAN_H are at the same

potential (CAN_L =CAN_H = 2.5V). Dominant state occurs when there is a difference in

potential (CAN_L = 1.5V and CAN_H = 3.5V).



Figure 2-13 : CAN Bit Representation

2.10 BIT ENCODING

There are various ways to encode bits in digital systems. We describe two here, Non-Return

to Zero and Manchester. Both methods have advantages and disadvantages.

Figure 2-14 : CAN Bit encoding (a) Manchester encoding (b) NRZ encoding

The Manchester encoding scheme represents the bits as transitions from ‘0’ to ‘1’ or ‘1’ to

‘0’. Even if a frame has a string of ‘1’s or ‘0’s the transition is always necessary. The

Manchester encoding scheme is very useful in asynchronous communication systems since

there is always a signal transition for bit synchronization. The primary disadvantage of

Manchester encoding is that it requires more bandwidth because each bit must have two time

slots to be encoded.

Non-return to zero (NRZ) encoding does not require signal transitions to represent each bit.

The signal remains ‘0’ or ‘1’ for the entire time slot. If a frame has a string of ‘1’s or ‘0’s, the

signal will remain constant for as many bit times as necessary. The disadvantage of NRZ is

that there is no easy way to tell where each bit starts or ends when there are more than two

‘1’s or ‘0’s in a row. The only way to know where a bit starts or ends is for the receiver to

have a clocking source that is identical to the transmitter so that it can decipher the bit stream.

This is called synchronous communication. However, it is very difficult to keep two clocking

source exactly synchronized for very long at the bit rates used by CAN. To overcome this

CAN uses a technique called bit stuffing.



2.11 BIT STUFFING

Control Area Network protocol standard allows only 5 consecutive bits of same polarity

between Start of Frame and the CRC field of a message frame. Bit stuffing is the process of

adding one opposite polarity bit whenever a consecutive 5 bits of the same polarity are

transmitting. Figure 2-15 shows a simple example of bit stuffing.

Figure 2-15 : Bit Stuffing

The sender node needs to add the “stuff bit” (opposite polarity bit) before transmission and

the receiver eliminate the “stuff bit” to get the original message. The advantage of bit stuffing

is that, it provides additional signal edges for data transfer synchronization after 5 bits.

There are Different bit stuffing technique are present. Few of them are discussed below.

2.11.1 Selective Xor Masking

XOR masking was first proposed by Nolte and colleagues. In this technique transmitted bytes

are XOR-ed with the masking bit “101010…” for removing stuff-bits in particular sets of

data (which tend to have long sequences of 1s and 0s). Again the received bytes are XOR-ed

with the same masking bit to get the original data bytes. This technique reduces CAN

message-length variations (i.e. jitter [11]-[20]) to low levels and also reduces large

computational or memory overheads. These techniques are described in-detail in [21] and

[22].

2.11.2 Software Bit Stuffing (SBS)

In selective XOR masking the levels of message length variation was reduces significantly,

but few conditions remain unsolved like the boundaries of the adjacent bytes are processed



individually. So the continuous 0 or 1 at the end of one frame and the same continuous 0 or 1

at the start of the next frame give a long sequence of 0 or 1. To eliminate this type of

condition “Software Bit Stuffing” (SBS) technique was proposed [20] and was implemented

in [10].

In this technique data frames are checked before transmitting. If a sequence of four

consecutive bits is detected, SBS adds an additional bit of opposite polarity. Here at most five

consecutive bit of same polarity is allowed (one stuff bit and four in coming data bits).

2.11.3 Eight-To-Eleven Modulation (EEM)

In SBS data encoding / decoding are performed at run-time (while the system is operating)

using a function call approach [20]. Due to run time processing the CPU overheads of the

processor are increased.

To achieve the high processor utilization as well as to reduce the effect of bit stuffing a new

X-to-Y modulation approach is used. In X-to-Y modulation approach “X” signifies the

number of original data bits and “Y” signifies the number of encoded data bits. A most

known example of X-to-Y modulation is Eight-to-Fourteen Modulation (EFM) which is used

in compact discs (CDs) [23].

Eight-to-Eleven Modulation (EEM) [5] is another type of X-to-Y modulation where “X”

equals to 8 (the number of bits per byte) and “Y” equals to 11 (the number of encoded data

bits).

As given in [21], the number of stuffed bits necessary to avoid CAN bit-stuffing is found as

follows:

�� = � �� !"#$�� %� �� #&&�'�� !(

(1)

Where the symbol └ ┘ denotes the floor function to make the number of stuffed bit to

integer. In our case we have 8 bits that are subjected to bit-stuffing and maximum 4

consecutive bits are allowed for a bit-stuffing, then the number of stuffed bits required in

each byte is 2 bits.

The worst case “bit-stuffing” for a CAN controller will be five consecutive bits followed by

an opposite polarity bit and so on [21]. In software level to avoid hardware “bit-stuffing”



consecutive bit with same polarity should not be more than four. The worst case condition for

8 bits of data will be four “0” followed by three “1” and one“0” (i.e. 00001110). From the

previous discussed formula the number of required stuff bit will be two. After addition of

these two stuff bit we found that the sequence will be like “0000111100”. Here the bold bits

are the stuffed bits. When two bit pattern of the above type transmitted consecutively, we

found five consecutive same polarity bit at the boundary.

To avoid such boundary condition we need to add another extra stuff bit. After adding the

extra stuff bit the total number of stuff bit will be three for a set of 8 bit data. So the total

number of bit encoded bits will be 11 bits. Figure 2-16 shows the 11 bit encoded format of

the 8 bit input data, where we have one stuff bit in the middle of the input data sequence, one

near most significant bit and one near the least significant bit.

Figure 2-16 Encoding data byte in EEM method (SB stands for “stuffed bit”)

In Figure 2-16 SB are the stuff bit, bit 1 to 8 are the original 8 bit input data. Stuff bits values

are the negation of the previous bit. In this encoding format the worst case data frame will not

exceed 4 consecutive same polarities. For example let the input sequence will be

“11110001”. After encoding the result will be “10111000011” that satisfy the “bit-stuffing”

condition and also solve the boundary condition problem.

However the implementation of this bit stuffing approach is not addressed in the paper [5].

We use this concept for CAN. We verify the designed model in FPGA. We also verify this

structure for 2 node and 4 node structure experimentally.

2.11.4 Implementation of EEM Algorithm

EEM technique can be implemented by Lookup table approach or by Function call approach

[5]. Look up table approach again can be implemented by Explicit EEM table or by Implicit

EEM tables. Function call approach again can be implemented by Algorithmic coding or by

Mathematical coding.

Here we are following algorithmic approach to implement EEM technique. The flow chart of

the coding is presented in the Figure 2-17 and is self-explanatory.



Logical operators like SHIFT, OR, AND are used to convert the 8 bit raw data to 11 bit

encoded format by adding three stuff bit in proper position. “in_index” indicates the bit order

in the original data byte, while “out_index” indicates the bit order in the EEM code.

Figure 2-Error! Bookmark not defined. EEM Algorithm Implementation[5]

Chapter 3

ASIC Design Flow

1. INTRODUCTION

2. DESIGN DESCRIPTION

3. GENERAL DESIGN FLOW

4. SPECIFICATION AND RTL CODING

5. SIMULATION AND VERIFICATION

6. SYNTHESIS

7. FORMAL VERIFICATION

8. STATIC TIMING ANALYSIS

9. PHYSICAL DESIGN

Chapter 3 ASIC Design Flow


3.1 INTRODUCTION

Very large scale integration (VLSI) is a technology that can be used for various applications

like analog, digital and mixed signal electronics. Millions of transistors are put together on a

single piece of silicon in designing microprocessors, along with internal memory and

arithmetic units. The current design motive is to reduce the entire system design to a single

chip solution called System on Chip (SoC).

An application-specific integrated circuit (ASIC) is an integrated circuit designed for a

particular use, instead of general-purpose use. Processors, ROM, RAM, etc. are examples of

ASICs [8].

The three major categories of ASIC Technology are :

Full custom

Gate Array-Based

Standard Cell-Based

In our design we are using Standard Cell-Based Technology where the ASIC designer defines

only the placement of the standard cells and their interconnections. Standard cells are the

basic building element of the design which is constructed using a full - custom design. The

design style gives the same performance and flexibility. The advantage of this design is that it

saves time, money, and reduce risk by using a predefined, pre-characterized and

pretested standard-cell library [8].

3.2 DESIGN DESCRIPTION

Semicustom ASIC design Flow mostly follows three domains of design description.

• The behavioral, for describing the functional design.

• The structural, for describing the form of the implementation.

• The physical, for describing the physical description of the design.



Figure 3-1 : Traditional ASIC Design Flow [9]

There are different possibility representations of a circuit in each description, and thoughtful

of representations are more important in tool design.

Concept + Market Research

Architectural Specs & RTL

Coding

RTL Simulation

Logic Synthesis, Optimization

& Scan Insertion

Formal Verification

(RTL Vs Gates)

Pre-layout STA

Transfer Clock Tree to DC

Formal Verification

(Scan Inserted Netlist Vs OT

Inserted Netlist)

Post Global Route STA

Timing

OK?



Timing

OK?

Timing

OK?

Floor planning, Placement,

CT Insertion & Global

Routing

Tape out

No

No

No

Yes

Yes

Yes



3.3 GENERAL DESIGN FLOW

A simplified view of design flow is shown in the Figure 3-1. Few steps are briefly explained

as below.

1. It is important to specify the requirements at the beginning of a design. From the

requirements and specification, architecture of the design is decided.

2. The whole module is divided into smaller sub module for easy development. Based on

the architecture of the design RTL coding is done by using Hardware Description

Language (HDL).

3. To verify the functionality of the design, dynamic simulation of the design is done.

4. In this step it needs to decide the technology information that we are going to use and

design environment setting along with environmental attributes.

5. Constraining and synthesizing the design with scan insertion using Design Compiler.

6. Block level static timing analysis is done using Design compiler’s built-in static

timing analysis engine.

7. Formal verification of the design is performed for comparing the RTL coding against

the synthesized netlist using Synopsys Formality.

8. Pre-layout static timing analysis on the full design is done using Prime time.

9. Forward annotation of timing constraints is fed to the layout tool.

10. With Cadence SoC encounter floor planning with timing driven placement of the

cells, clock tree insertion and global routing is done.

11. Transfer of clock tree to the original design (netlist) residing in Design Compiler.

12. Using Design Compiler in-place optimization of the design is performed.

13. Cadence conformal is used for formal verification between the synthesized netlist and

clock tree inserted netlist.

14. Estimated timing parameter is extracted after the global routing of the design.

15. Back annotation of estimated data from the global routing design, to Prime Time.

16. In Prime Time static timing analysis is done by using the estimated timing parameter.

17. Detailed routing of the design is performed.

18. Real time delay is extracted from the detailed routing design.

19. Back annotation of real extracted timing parameter to prime time.

20. Post layout static timing analysis is performed using Prime Time.

21. Functional gate level simulation of the design is done using post layout timing

parameter.



22. Final GDS-II creation for tapeout after Design rule violation checking [9].

3.4 SPECIFICATION AND RTL CODING

ASIC design begins with the conception of an idea demand by the market. Ideas are then

converted into architectural specifications which define the functionality and partitioning of

the chip into several blocks. The specifications define the relationship between the blocks in

terms of signal timing information. The implementation of these specifications is then

performed. For large design drawing the schematic manually by using the standard cell is not

possible or time taking. Hardware description languages (HDL) were developed to overcome

this problem. Today there are two types of HDLs used, VHDL and Verilog.

There are three levels of abstraction used to represent the design; Behavioral, Register

Transfer Level (RTL) and Structural. The Behavioral level code is at a higher level of

abstraction used primarily for translating the architecture specification to a code that can be

simulated. This type of coding is used to describe the functionality of the design and is

synthesized to form a structural netlist. This netlist comprises of the components from a

target library and their respective connections; very similar to the schematic based approach

[9].

3.5 SIMULATION AND VERIFICATION

The functionality of the design is verified by simulating the RTL code. The simulators are

used to simulate the RTL code and also used to map the design into the gate - level design.

The RTL module used to generate the input sequence for testing a design is known as “Test-

bench”.

Figure 3-2 : Test-bench and Design under verification



Figure 3-2 shows the test-bench and Design under test/verification (DUT/DUV) module. The

test-bench provides inputs to the design and observes the output. This is totally a closed

system; no input or outputs go in or out from the system. The main objective while designing

the test-bench is that it needs to choose a proper input pattern and it needs to observe that

whether desired output is coming or not. The coverage of the design is totally dependent on

the number of test pattern provides and the quality of test-bench.

3.6 SYNTHESIS

Synthesis is the process of generating the Structural gate-level netlist from the behavioral

RTL code. Synthesis reads the RTL source code, optimizes the design and finally generates

the gate-level netlist. The Synopsys Design compiler is used in this project to synthesize the

RTL code.

Figure 3-3 : Design Compiler Flow

Synthesizing a design is an iterative process and begins with defining timing constraints for

each block of the design. Timing constraints define the relationship of each signal with

respect to the clock input for a particular block. The design constraints are usually defined in

Synopsys Design Constraints (SDC) file. The constraint definition includes clock definition,

Input / Output timing definition and the timing exceptions. In addition to the constraint file it

also needs an environment file which specifies the technology cell libraries and other



necessary information that Design Compiler uses during synthesis. Design Compiler reads

the RTL code of the design and uses the timing constraints file to synthesize the behavioral

RTL code to the structural gate level netlist. This is shown in the Figure 3-3 [9].

3.7 FORMAL VERIFICATION

Formal verification checks the logical functions of a design by comparing it against the

reference design without any technological consideration. It verifies the structure and

functionality of two designs whether they are logically equivalent of not. It consumes less

amount of the as compared to dynamic simulation.

The use of formal verification in the design flow is to compare the RTL with RTL, RTL with

its gate level netlist, one gate level netlist with another gate level netlist; for verifying the

functionality; whether they are correct or not.

3.8 STATIC TIMING ANALYSIS

Static timing analysis is one of the import steps in the ASIC design process. This analysis

allows the detailed analysis of all possible critical paths of the design. The reports also

contain other debugging information like the capacitive load or fan-out of each net. Synopsys

Prime Time is used for static timing analysis of Controller Area Network controller

implementation. Static timing analysis is performed for both pre and post layout gate-level

netlist. In per layout mode, it uses the wire load models specified in the library to estimate

total delay where as in the post layout mode it uses the actual extracted delay like net

capacitance and interconnect RC delays.

3.9 PHYSICAL DESIGN

The physical design is a process of making the layout of the design from the RTL coding by

considering the specification of power, timing and area. Most of the physical design tool

supports placement, routing and optimization. Figure 3-4 shows the general physical design

flow [9].



Figure 3-4 : Physical Design Flow [9]

VERIFICATION AND BACK

ANNOTATION

DESIGN FINISHING AND

ITERATIVE CHANGES

POSTROUTING

OPTIMIZATION

ROUTING

CLOCK TREE SYNTHESIS AND

OPTIMIZATION

PLACEMENT AND PLACEMENT

OPTIMIZATION

TIMING SETUP AND ANALYSIS

FLOORPLANNING

LIBRARY SETUP AND DATA

INPUT

Chapter 4

CAN Architecture

1. DESIGN DESCRIPTION

Chapter 4 CAN Architecture


Figure 4-1 : CAN Architecture

4.1 DESIGN DESCRIPTION

For easy and modularize development, the total functionality of the CAN controller is divided

into different sub-modules or blocks. Functional block diagram of the CAN controller is

shown in the Figure 4-1. Individual functionality of each block is described as follows.

4.1.1 Host CPU:

Host CPU converts the digital data from analog to digital converter to CAN controller input

format data. Generally microprocessor is used to perform the work of host CPU in small

processor application [10].

4.1.2 Parameter Register:

There are three different registers inside the parameter register of CAN controller to store the

basic functional data. The three registers are code parameter, mask parameter and

synchronous jump width. Each of code parameter and mask parameter register is 11 bits, but

the size of synchronous jump width register is 2 bits. Code parameter and mask parameter

values are required to check the validation of the incoming receiving message. Synchronous

jump width value is required to bit synchronization. There is a 8 bit input bus to load the

register with a status signal. To load the register, status signal needs to make high and data is



provided through 8 bit data bus. The total size of the register is 24 bits so we need to provide

3 times 8 bit data to load it. First 8 least significant bits of the mask parameter follower by 3

most significant bits; next the 5 least significant bits of code parameter followed by 6 most

significant bit. At last 2 bits synchronous jump width is loaded. A reset signal is used to clear

the value from the register.

4.1.3 Transmitter Buffers:

Transmitter Buffer is used to store the incoming message from the host CPU. The size of the

transmitter buffer is 10 bytes. When the host CPU wants to send some data to CAN

controller, the data are first store the transmitter buffer before changing to proper protocol

format frame. There are 8 bit data bus which is used to load the Transmitter Buffer. One

status signal is used to make high before loading. One busy signal is used by the controller to

notify the status of Transmitter Buffers, whether the buffer is full or not.

4.1.4 Data/Remote Frame Generator:

The function of Data / Remote Frame Generator is to generate the message frame according

to the CAN protocol specification. For generating message frame it takes data from the

Transmitter Buffer. As defined in the CAN protocol, message frame is generated by

appending start bit with message identifier, followed by control field, data field, CRC field,

ACK field and End of frame field. CRC is generated from the data field after converting the

parallel data into serial. The host CPU generally filled the Transmitter Buffer according to the

sequence of different field of message frame.

4.1.5 Parallel- to-Serial:

For calculating the cyclic redundancy checksum of a data, it needs to serialize. The data field

used for making a message frame is parallel, so parallel to serial module is used to convert

the parallel data to serialize. It takes 8 bit input data, make it serialized and give back one bit

in each cycle by shifting one bit at a time. Different status signals are used to notify the status

of beginning and end of parallel to serial conversion.

4.1.6 Tx CRC Generator:

Cyclic redundancy check (CRC) is used in the messaged frame to detect the presence of error

in the message frame during transmission. Before transmitting the message frame, at the

transmitter end Cyclic Redundancy Checksum is calculated and appended to the message

frame. Cyclic Redundancy Checksum is calculated by using a CAN polynomial. The



serialized frame has divided with the CAN polynomial repeatedly at last leaves remainder as

the Cyclic Redundancy Checksum.

4.1.7 Bit Stuff Unit:

As CAN sequence used NRZ encoding format, when a long sequence of same polarity bit

transmitted, transmitter and receiver may fail to maintain synchronization among them. To

avoid this condition bit stuffing is done. The main job of this module is to insert an opposite

polarity stuff bit when a sequence of consecutive 5 bits of same polarity is transmitted. Bit

stuffing is done only for data and remote frame. Due to the addition of stuff bit there is

always a variation of data length in case of data and remote frame. Bit stuffing is done to start

of frame, message identifier, control field, data field and CRC sequence only. Bit stuffing is

not applied to CRC Delimiter, Acknowledgement field, end of frame field and intermission

field.

4.1.8 Overload / Error frame Generator:

Overload / Error frame Generator generates the overload frame when it detects the overload /

error conditions. The overload condition arises when both the received buffers are full and

there is no space to keep the incoming data. To indicate this situation receiver generates an

overload frame. Overload frame signifies the delaying of transmission in the bus. Similarly

error frame is generated when an error condition is arises.

4.1.9 Serialized Frame Transmitter:

Serialized transmitter is the last module before data transmit into the CAN bus. Based on the

prevailing condition, this unit transmits the data/ remote frame or the error/ overload frame or

a dominant bit during the acknowledgement slot.

4.1.10 Message Processor:

This unit provides all the control and the status signal to the various blocks. This unit is also

routes the different signals generated in various blocks to the necessary target blocks.

4.1.11 Arbitration Control:

Arbitration status of the node is indicated by Arbitration Control. There is a status signal in

Arbitration control to indicate the arbitration status. When the status signal high indicates that

the node is a transmitter and status low indicates the receiver node.



4.1.12 Synchronizer:

Synchronizer is responsible for maintaining the synchronization of the input received data

stream from the can bus by configuring the timing parameter. For calculating the timing

parameter it takes the value of Synchronous jump width (SJW) and calculated the smallest

time quanta.

4.1.13 Bit De-stuff Unit:

This unit performs the bit de-stuffing operation for the incoming received message frame. It

eliminates the extra added stuffed bit from the received message frame to get the original

message frame. Along with de-stuffing operation this unit also extracts some necessary

information from the received data frame for checking the correctness of the received data

frame.

4.1.14 Error Checker:

This unit compares the received CRC Value with the calculates one and notify if any

mismatch found. Bit stuff error and acknowledgement error in the receiving data also

observed by this module and raise an error condition when required.

4.1.15 Acceptance Checker:

The main job of this module is to validate the incoming message by verifying message ID. As

we know CAN uses broadcast communication. Whenever any node transmits any data

through CAN bus all other nodes can able to receive it. But the actual receiving node can able

to filter the message by its receiving message ID. The code parameter and the mask

parameter are used to filter the received message along with the incoming message ID. One

status signal is used to define the Acceptance status of the incoming message, that is whether

the message is relevant to a particular node or not.

4.1.16 Receive Buffer:

These are two 10 byte buffer is used to store the received data from the CAN bus. They are

used alternatively to store the receiving data. This facilitates the Host CPU to process some

data when another message is being received by the controller. There are status signals to

indicate the state of the buffer whether it is full or empty [10].

Chapter 5

Results and Analysis

1. RTL SIMULATION

2. COVERAGE ANALYSIS

3. SYNTHESIS REPORT

4. GATE LEVEL SIMULATION RESULTS

5. PLACE AND ROUTE

6. SYMBOL AND SCHEMATIC GENERATION

7. LAYOUT VERIFICATION

8. INTEGRATION FOR TAPE-OUT

Chapter 5 Results and Analysis


5.1 RTL SIMULATION

It is important to verify the functionality of the individual sub-module before integrating to

make them a complete system. The individual sub - module is verified by giving different test

cases or designing the test bench for them. In the below section few modules and their

simulation results are discussed. After verifying the individual module complete system is

designed by integrating them and verified by designing a test bench for it.

5.1.1 Parameter register

Figure 5-1 Simulation Results for Parameter register

Figure 5-1 shows the simulation result for parameter register. Parameter register takes the

input through 8 bit data input port. The total size of the parameter register is 3 bytes or 24 bits

which consist of 11 bit mask parameter, 11 bit code parameter and 2 bit synchronous jump

width (sjw) register. For loading the data, param _ld signal needs to make high and it takes 3

consecutive clock cycles to complete the loading starting from mask parameter than code

parameter at last sjw.



5.1.2 Transmission buffer

Figure 5-2 Simulation Results for Transmission Buffer

Figure 5-2 shows the simulation results for transmission buffer. To load the transmission

buffer tx_buff_ld signal needs to make high. The total size of the transmission buffer is 10

bytes. As it takes input through 8 bits input data ports so it needs maximum 10 consecutive

clock cycles to load completely. After loading is complete frame_gen_intl signal is high for a

moment to initialize the next process and tx_buff_busy goes high to indicate that

transmission buffer is full.

5.1.3 Data Remote Frame Generator

Figure 5-3 shows the simulation result for Data remote frame generation. This module takes

the input data from transmission and is initialized by the frame_gen_intl signal of

transmission. Parallel data bytes are converted into 83 bit serial data by parallel to serial

converter which is indicated by par_ser_data. The CRC value is calculated from the CRC

generator from the serialized data. Final data or remote frame is generated after appending

the CRC value and is fed to the bit stuff unit as de_rm_frm signal.



Figure 5-3 Simulation Results for Data Remote frame Generation

5.1.4 Parallel to serial converter

Figure 5-4 Simulation Results for Parallel to Serial Converter

Figure 5-4 shows the parallel to serial converter simulation results. Par_ser_intl signal send

by data remote frame generator block initializes the serialization block. Parallel data are

given as input through par_ser_data and the serialized data is coming out through

tx_serial_out signal



.

5.1.5 Transmission CRC Generator

Figure 5-5 Simulation Results for Transmission CRC Generation

Figure 5-5 shows the CRC Generation simulation results. Serialized data are given as input to

this module. After CRC calculation output is coming out through crc_frm port.

5.1.6 Bit stuffing

Figure 5-6 Simulation Results for Bit Stuffing

Figure 5-6 shows the bit stuffing simulation results. The input to the module is taken from

data remote frame generator block through dt_rm_frm and is initialized by bit_stf_intl signal.

This module checks the bit stuffing condition and adds the stuff bit when required. Final

output is coming out through dt_rm_out port.



5.1.7 Serialized Frame Transmitter

Figure 5-7 Simulation Results for Serilized Frame Transmitter

Figure 5-7 shows simulation results for serialized frame transmitter. The input to the module

is taken from bit stuff module and error overload frame generator module. Based on the status

signal it decides whether it needs to transmit data remote frame or error overload frame.

When act_err_frm_tx or psv_err_frm_tx or ovld_frm_tx is high error or overload frame is

transmitted. When dt_rm_frm_tx signal is high data or remote frame is transmitted. The

arbitration status is indicated by arbtr_sts signal. When arbtr_sts signal is high, the node is

acting as transmitter; but when the status is low, it indicates the node losses arbitration and

act as receiver.

5.1.8 CAN Wire-ending Results

Figure 5-8 Simulation Results for CAN Wire-Anding using EEM



Figure 5-9 Simulation Results for CAN Wire-Anding using SBS

Figure 5-8 and Figure 5-9 Shows the RTL simulation results for CAN wire-anding structure.

Figure 5-9 shows the result where software bit stuffing technique is used and Figure 5-8

shows the results where Eight to Eleven modulation technique. Can_bus_out_0, 1, 2, 3 are

indicated the output of the four can connected through the CAN bus. All nodes start

transmitting the message frame same time but the node sending higher priority message

frame will get the bus access first. Here node 2 is in an ideal state. Node 1 sends a message

frame having less priority as compared to other so it stops transmitting first. Node 0 and

Node 3 both are sending the message frame having same message id but node 0 is a data

frame and node 3 is a remote frame. So node 0 get the access of the bus as the data frame has

a higher priority as compared to the remote frame.



5.1.9 Comparison of SBS and EEM

Bit-Stuffing Technique SBS EEM

No. of Slices 184 191

No. of Slice Flip Flops 139 146

No. of 4 input LUTs 359 374

No. of Bonded IOBs 122 122

Max. Frequency 223.330MHz 237.225MHz

Figure 5-10 Comparision of SBS with EEM

From the Figure 5-10, it is observed that by using EEM technique Frequency

of operation increases due to reducing the jitter. The logic utilization of this

technique is little more as compared to SBS technique.



5.2 COVERAGE ANALYSIS

Coverage analysis is an important step in the VLSI design flow. Code coverage analysis is

one of the coverage analysis which is used to test the quality of the test bench for a particular

design. Code coverage is applied to the design under test to check how thoroughly it is tested

by the test bench.

5.2.1 Condition Coverage

Figure 5-11 Condition Coverage Analysis

There are different types of tools are available in the market for coverage analysis. Verilog

Compiled Simulator (VCS) coverage analysis tool is used here for code coverage analysis.

Figure 5-11 shows the conditional analysis report. Figure 5-12 shows the line coverage



report. When the coverage report percentage is above 80 it is indicated by the green color,

when the coverage report percentage is between 20 to 80 it is indicated with yellow color and

any coverage percentage below 20 is indicated by red color.

5.2.2 Line Coverage

Figure 5-12 Line Coverage Analysis

5.3 SYNTHESIS REPORT

Synopsys Design Vision is used for performing the synthesis of the design. Standard cell

library and symbol library are taken from Faraday 180 libraries. In design vision first the

standard cell and symbol library setup is done. Secondly the design that's going to

synthesized is given as input; along with this the design constraint of the design. For

extracting synthesized netlist the loaded design needs to compile. After successful

compilation gate level synthesized netlist is saved. The synthesized netlist contain the



standard cell which is given in input as a standard cell library. Figure 5-13 shows the design

symbol generated after importing the design into Design vision. Different reports like area

report, power report and timing report are generated from the Design Vision after successful

compilation.

DESIGN VISION

Figure 5-13 Synthesis using VCS Design Vision

5.3.1 Power Report

****************************************

Report : power -analysis_effort low

Design : can

Version: B-2008.09

Date : Fri May 25 12:17:13 2012

****************************************

Library(s) Used: fsa0m_a_generic_core_tt1p8v25c



Operating Conditions: TCCOM

Library: fsa0m_a_generic_core_tt1p8v25c

Global Operating Voltage = 1.8

Power-specific unit information :

Voltage Units = 1V

Capacitance Units = 1.000000pf

Time Units = 1ns

Dynamic Power Units = 1mW (derived from V,C,T units)

Leakage Power Units = 1pW

Cell Internal Power = 60.2757 uW (62%)

Net Switching Power = 37.1613 uW (38%)

---------

Total Dynamic Power = 97.4370 uW (100%)

Cell Leakage Power = 528.8107 nW

5.3.2 Timing Report

****************************************

Report : timing

-path full

-delay max

-max_paths 1

-sort_by group

Design : can



Version: B-2008.09

Date : Fri May 25 12:24:20 2012

****************************************

Operating Conditions: TCCOM Library:

fsa0m_a_generic_core_tt1p8v25c

Wire Load Model Mode: enclosed

Startpoint: can_bus_in (input port clocked by osc_clk)

Endpoint: synchro/ph_seg1_cnt_reg[2]

(rising edge-triggered flip-flop clocked by osc_clk)

Path Group: osc_clk

Path Type: max

Des/Clust/Port Wire Load Model Library

------------------------------------------------

can enG30K fsa0m_a_generic_core_tt1p8v25c

synchronizer enG5K fsa0m_a_generic_core_tt1p8v25c

Point Incr Path

------------------------------------------------------

clock osc_clk (rise edge) 0.00 0.00

clock network delay (ideal) 3.00 3.00

input external delay 50.00 53.00 f

can_bus_in (in) 0.00 53.00 f

synchro/can_bus_in (synchronizer) 0.00 53.00 f

synchro/U39/O (XOR2HS) 0.09 53.09 f



synchro/U57/O (AO12) 0.21 53.30 f

synchro/U22/O (MOAI1S) 0.18 53.48 f

synchro/U42/O (AOI22S) 0.17 53.64 r

synchro/U40/O (MOAI1) 0.11 53.75 f

synchro/U14/O (NR3) 0.24 54.00 r

synchro/U8/O (INV1S) 0.12 54.11 f

synchro/U58/O (NR2) 0.16 54.28 r

synchro/U32/O (AO12) 0.14 54.42 r

synchro/U54/O (MOAI1S) 0.16 54.58 r

synchro/ph_seg1_cnt_reg[2]/D(QDFFRBN)0.00 54.58 r

data arrival time 54.58

clock osc_clk (rise edge) 125.00 125.00

clock network delay (ideal) 3.00 128.00

clock uncertainty -0.50 127.50

synchro/ph_seg1_cnt_reg[2]/CK(QDFFRBN)0.00 127.50 r

library setup time -0.11 127.39

data required time 127.39

------------------------------------------------------

data required time 127.39

data arrival time -54.58

------------------------------------------------------

slack (MET) 72.80



5.3.3 Area Report

****************************************

Report : area

Design : can

Version: B-2008.09

Date : Fri May 25 12:15:05 2012

****************************************

Library(s) Used: fsa0m_a_generic_core_tt1p8v25c

Number of ports: 20

Number of nets: 531

Number of cells: 31

Number of references: 24

Combinational area: 77982.508525

Non-combinational area: 66505.118927

Total cell area: 144487.627452

……………

5.4 GATE LEVEL SIMULATION RESULTS

After the gate level synthesized netlist is created; the functional verification is done by

simulating the synthesized netlist. Both the RTL code for the design and the synthesized

netlist of the design tested with same test bench. On comparing the simulation result; it shows

whether the gate level synthesized netlist created properly or not. While simulating the gate

level synthesized netlist standard cell library is given to the simulator to define the standard



cell. Previously Figure 5-9 shows the RTL coding simulation result; Figure 5-14 shows the

gate level simulation result.

Figure 5-14 Synthesized Gate level Simulation result

5.5 PLACE AND ROUTE

Cadence SoC encounter is used for place and route of the design. For importing the design

into Cadence SoC encounter, standard lib (library), lef (Library Exchange Format) and

synthesized netlist of the design is given as basic input. Input output (.io) file is used to

defining the orientation of the input output and SDC (synopsys design constraint) file is used

for defining the constraint of the design. Faraday 180 standard cell library file is used here for

place and route the design. Figure 5-15 shows the detailed layout of the design after place and

route.



Figure 5-15 Place and Route in SoC Encounter

All violation like connectivity error, drc error, design error are checked before generating the

GDS II file from the layout.

5.5.1 Gate Count Report

The gate count report is generated from Cadence SoC encounter which is given below.



************************* Gate Count Report ******************************

Gate area 9.3744 um^2

Level 0 Module can Gates=13732 Cells=4944

Area=128732.4 um^2

Level 1 Module reg_file Gates=363 Cells=96

Area=3402.9 um^2

Level 1 Module tx_buffer Gates=939 Cells=262

Area=8802.6 um^2

Level 1 Module data_remote_frm Gates=2004 Cells=701

Area=18792.5 um^2

Level 1 Module parser Gates=928 Cells=237

Area=8702.6 um^2

Level 1 Module tx_crc Gates=150 Cells=51

Area=1412.4 um^2

Level 1 Module bt_stf Gates=1881 Cells=610

Area=17639.5 um^2

Level 2 Module bt_stf/eq_108 Gates=367 Cells=145

Area=3446.7 um^2

Level 1 Module msg_prsr Gates=288 Cells=127

Area=2703.0 um^2

Level 1 Module ovld_err Gates=897 Cells=365

Area=8415.1 um^2

Level 1 Module synchro Gates=286 Cells=109

Area=2681.1 um^2

Level 1 Module destuff Gates=3135 Cells=1322

Area=29391.9 um^2



Level 2 Module destuff/srl_646 Gates=375 Cells=264

Area=3521.6 um^2

Level 2 Module destuff/sll_642 Gates=442 Cells=249

Area=4149.7 um^2

Level 1 Module rx_crc Gates=152 Cells=52

Area=1431.2 um^2

Level 1 Module frm_error Gates=208 Cells=116

Area=1949.9 um^2

Level 1 Module rx_buffer Gates=1933 Cells=683

Area=18127.0 um^2

Level 1 Module Serial_out Gates=239 Cells=71

Area=2240.5 um^2

########################################################

From the above report total cell area is 128732.4 µm2

From umc 180 Standard cell libraries Area of ND2 (Nand Gate) is 9.3744 µm2

Total number of gate count is (128732.4 / 9.3744) = 13732.334

From the above report total number of gate count is 13732

Total number of transistor count = 4* total number of gate count ≈55k

5.6 SYMBOL AND SCHEMATIC GENERATION

After automatic routing in Cadence SoC encounter still some error exists; to fix the error, the

design needs to import into icfb for manually fixing the error.

Synthesized netlist is imported into the Cadence icfb for generating the symbol and schematic

for the design. While generating the symbol and schematic for the design, standard cell

library is given as a standard reference to icfb. After schematic and symbol generation the



detailed structure of the design can be visible up to gate level hierarchy. Figure 5-16 shows

the symbol and Figure 5-17 shows the schematic of the design.

Figure 5-16 CAN Symbol Generated from Gate level Netlist

Figure 5-17 CAN Schematic Generated from Gate level Netlist



5.7 LAYOUT VERIFICATION

Figure 5-18 CAN Layout Generated from GDSII

Figure 5-18 shows the Layout of the design after importing into icfb. GDS file which is

generating from SoC encounter is used for importing the design into icfb. While exporting

from SoC encounter and importing into icfb proper map file (contain layer map information)

is required to choose.



5.8 INTEGRATION FOR TAPE-OUT

Figure 5-19 CAN Final Integration with PAD Ring

Pad ring is designed by taking input output pin, power (vdd and gnd) pin, filler cell and

corner cell. For mini ASIC the size of the design is 1525 µm *1525 µm, the number of pin

count is 48. The minimum pad to pad distance is 90µm. The design is placed inside the ring

and routed with the corresponding pin. After final integration DRC is checked and GDS file

is created for final tape-out. Figure 5-19 shows the final integration of the design.

Chapter 6

Conclusion

1. CONCLUSION

Chapter 6 Conclusion


6.1 CONCLUSION

Controller Area Network (CAN) is a multi master broad cast serial communication bus

widely used in the real time automobile system. CAN network follow bus topology, due to

which on the damage of one functional block will not affect the whole network. For

maintaining the synchronization among the node in a network bit stuffing technique in CAN

plays an important role. A noble bit stuffing technique; Eight to Eleven Modulation (EEM) is

used in the place of old Software Bit Stuffing (SBS) technique for reducing the jitter due to

variable message length variation. By using Xilinx ISE tool logic utilization and frequency of

operation of both the module is verified and desired results are obtained.

CAN controller is designed for tape-out by using UMC 180 libraries with six metal layers

and 1 poly layer. RTL code for a CAN controller is designed and the behavioral simulation

result is verified by using Synopsys VCS simulator. Synthesized netlist is generated by using

Synopsys design vision by using Faraday 180 Standard cell library. For automatic place and

route Cadence Soc encounter is used. Pad ring is designed in Cadence icfb and integrated

with the module. After verifying the DRC (Design Rule Check) violation GDS II file is

created from the final integrated module for tape-out.

Chapter 7

Future work

1. FUTURE WORK

Chapter 7 Future Work


7.1 FUTURE WORK

• Set up an environment where different cases can be generated for testing the chip after

fabrication.

• Designing the system where it can be used.

Figure 7-1 shows the model how it can be used in real-time.

Figure 7-1 CAN in Real time Application

References


REFERENCES

[1] CAN Specification Version 2.0, Robert Bosch GmbH, Stuttgart, Germany, 1991.

[2] Wolfhard Lawrenz, CAN System Engineering: From Theory to Practical

Applications, Springer-Verlag, 1997, ISBN 0–387–94939-9.

[3] Daniel Mannisto, Mark Dawson, An Overview of Controller Area Network (CAN)

Technology, mBus, 2003.

[4] Steve Corrigan, Introduction to the Controller Area Network (CAN) – Texas

Instruments Application Report, SLOA101, 2002.

[5] Mouaaz Nahas, Applying EEM to reduce message length variations in distributed

embedded system using the CAN protocol, 2011.

[6] Peter B., An Introduction to CAN, I+ME ACTIA GmbH, ISO 7498, 1998.

[7] W. Voss, A Comprehensible Guide to CAN, Copperhill Media Corporation

[8] John Smith, Application Specific Integrated Circuit, LPE Pearson Education.

[9] Himanshu Bhatnagar, Advanced ASIC chip using Synopsys, Kluwer Academic

Publishers.

[10] Sreeram Krishnamoorthy, “Design an ASIC Chip for a Controlller Area Network

(CAN) Protocol Controller”.

[11] M. Short, and M.J. Pont, “Fault-Tolerant Time-Triggered Communication Using

CAN”, IEEE Transactions on Industrial Informatics, Vol. 3, No. 2, 2007, pp. 13-142.

[12] K.W. Tindell, A. Burns, and A.J. Wellings, “Calculating Controller Area Network

(CAN) Message Response Times”, Control Engineering Practice, Vol. 3, No. 8, 1995,

pp. 1163-1169.

[13] Navet, N. and Song, Y.Q. (1998) “Design of reliable real time applications distributed

over CAN (controller area network)”,Proceedings of INCOM’98, IFAC Symposium on

Information Control in Manufacturing, Metz 22–24 June, 1998, pp. 391-396.

[14] R. Rudiger, “Evaluating the temporal behaviour of CAN based systems by means of a

cost functional”, Proceedings of the Fifth International CAN Conference, San Jose, CA,

USA, November, 1998, pp. 10.09-10.26.

References


[15] A. Stothert, and I. MacLeod, “Effect of Timing Jitter on Distributed Computer

Control System Performance”. Proceedings of DCCS’98 –15th IFAC Workshop on

Distributed Computer Control Systems, September 1998.

[16] P. Verissimo, and L. Rodrigues, “A posteriori Agreement for Fault-Tolerant Clock

Synchronization on Broadcast Networks”, the 22ndInternational Symposium on Fault-

Tolerant Computing, Boston, USA,July, 1992.

[17] L. Rodrigues, M. Guimarães, and J. Rufino, “Fault-Tolerant Clock Synchronization in

CAN”, Proceedings of the 19th IEEE Real-Time Systems Symposium, Madrid, Spain,

December 2-4, 1998.

[18] J. Barreiros, E. Costa, J. Fonseca, and F. Coutinho, “Jitter reduction in a real-time

message transmission system using genetic algorithms”, Proceedings of the CEC 2000

– Conference of Evolutionary Computation, USA, July 2000.

[19] M. Nahas, and M.J. Pont, “Using XOR operations to reduce variations in the

transmission time of CAN messages: A pilot study”. In: Koelmans, A., Bystrov, A.,

Pont, M.J., Ong, R. and Brown, A. (Eds.),Proceedings of the Second UK Embedded

Forum, Birmingham, UK, October 2005, pp. 4-17. Published by University of

Newcastle uponTyne.

[20] M. Nahas, M. J. Pont, and M. Short, “Reducing message-length variations in

resource-constrained embedded systems implemented using the CAN protocol”, Journal

of Systems Architecture, Vol. 55, No.5-6, 2009, pp. 344-354.

[21] T. Nolte, H. Hansson, C. Norström, and S. Punnekkat, “Using Bit stuffing

Distributions in CAN Analysis”, IEEE/IEE Real-Time Embedded Systems Workshop

(Satellite of the IEEE Real-Time Systems Symposium) London, 2001.

[22] T. Nolte, H. Hansson. and C. Norström, “Minimizing CAN response time jitter by

message manipulation”, IEEE Real Time Technology and Applications Symposium

2002, pp. 197-206.

[23] J. Watkinson, Introduction to Digital Audio, Focal Press, 2002.

Documents

CONTROLLER AREA NETWORK PROTOCOL; DESIGN …ethesis.nitrkl.ac.in/4057/1/Final_Thesis_Tapas.pdf · Cadence SoC encounter is used for automatic place and route and cadence icfb is used