can

iCC 2005 CAN in Automation

09-13

Design and verification of a CAN controller for customASIC

Namsub Kim (speaker), Dawi Kim, Kyuhyung Cho, Jinsang Kim, and Wonkyung Cho

This paper presents a novel architecture and verification model of the CAN protocolcontroller for ASIC implementation. The key features of the proposed CAN controllerare flexibility in terms of interfacing with host processors and smaller chip size. Also,the architecture is efficient for Intellectual Property (IP) reuse because of its flexibilityand synthesis efficiency. For verification of the designed controller, we developed averification model for fast verification during the design phase. The gate counts of thecore logics in the proposed CAN controller are 3189 gates which are much smallerthan other controllers. After successful verification, the CAN controller was fabricatedby using 0.35_CMOS process.

1. Introduction

The Controller Area Network (CAN) is datacommunication protocol widely used invarious application areas such asautomobile, medical equipments, andmany industrial applications [9]. Typically,one CAN system needs many CANcontrollers and the CAN controller isindispensable for each CAN node, so thatit is desirable to implement CAN controlleras inexpensive as possible. There is anapproach to make a low-costcommunication controller called LIN (LIN:Local Interconnect Network) in conjunctionwith CAN. LIN operates at data rates up to20 Kbit/s and is based on a commonUART/SCI interface hardware [11]. Themethod for making low cost silicon in LINis mainly focused on using simplifiedprotocol and low cost physical layerdevice. Therefore, its usage is restrictedonly to low cost communication systemand it could not be replaced to all CANcontrollers.

There have been many CAN controllerswidely used in commercial market andsome of them are provided as an IP. Fromthe viewpoint of IP, it is important for thedesign to be reusable, flexible, reliable,and easy to implement [13]. Since thedesign methodology and implementationof the CAN controller have been mainlydepended on the designers experience, itis required to make efficient architecturewhich satisfies the aforementionedfeatures.

Moreover, since the upper serviceboundary of CAN implementation is notstandardized, the development of efficientverification method is required [8].

In this paper we propose a CAN controllerwhich makes low cost silicon and efficientfor IP reuse. Also, efficient verificationprocess of the CAN controller for rapidprototyping is presented.

This paper is organized as follows:

Section 2 describes the proposed CANcontroller architecture and its operation.Section 3 describes the verificationmethod of the CAN controller. Section 4describes ASIC implementation detailsand comparisons with previous CANcontrollers. Finally, concluding remarksand future work are given in section 5.

2. Proposed CAN Controller Architecture

CAN controller can be classified by itsmailbox structure [9]. Looking at themailbox structure, basically there are twoforms of structure type that are calledBasicCAN and FullCAN. BasicCAN can beimplemented with smaller size thanFullCAN. However, the main disadvantageof BasicCAN is that it might give a hostprocessor large load when the controllerneeds to gather large amount of data.FIFO Buffer CAN controller such as PhilipsSJA1000 could solve the problem ofBasicCAN structure, but the chip size waslarge because of large amount of FIFO[10]. There had been an approach to useexternal memory which is operating similar


09-14

to FIFO [2]. This CAN controller couldreduce the size of CAN core, but it has anadditional burden of implementation ofexternal memory and is not good for usingas an IP.

Typically, the CAN protocol controller canbe implemented as shown in Figure 1 [12].

BitTimingLogic

BitStream

Processor

Shift -Register

BaudratePrescaler

Control

Status

Send

Receive

HostProcessor

RX

TX

BitTimingLogic

BitStream

Processor

Shift -Register

BaudratePrescaler

Control

Status

Send

Receive

HostProcessor

RX

TX

Figure 1. Basic architecture of CANprotocol controller

This architecture describes well the dataflow of signals and components neededfor implementation. However, because BitTiming Logic and Bit Stream Processorare heavily related, it is very hard to debugthe hardware during the design phase.Moreover, because the error handling andcontrol mechanism in CAN protocol is verycomplex, the complexity of Bit StreamProcessor is very high. Therefore, theimplementation depends heavily on thedesigners technique and the design is notsuitable for IP reuse. Moreover, in orderfor the design to change the interface withhost processor, the whole design must bere-designed.

For solving the foregoing problems, weseparated bit timing operation asindependent block. The role of Bit StreamProcessor is divided into Field Manager,Error Checking, and Data Generationblocks according to the specification ofCAN protocol. Because error managementscheme in CAN protocol is complex, weseparated each error management blocksand it could lead our architecture to becompact in size. Also, we used FIFO thatcan be variable in size in order to preventproblem known as inner priority inversion[6]. The proposed architecture is shown inFigure 2.

This architecture is a BasicCAN with FIFObuffer, someone called it as intermediateCAN controller, which is compatible to

CAN version 2.0A. The functionaldescription of each block is as follows

Figure 2. Proposed architecture

Synchronizer synchronizes RXdata with bit timing.

ID Checker checks incoming IDand determines valid frame.

Register Group stores bit timingparameters and host parameters.

Interface Logic controls betweenhost and CAN core.

RX FIFO stores valid incomingdata.

Field Manager controls errors.

Error Checkers consist of checkingblocks for each type of errorsspecified in ISO 11898-1 andinforms errors to Error Counter.

Error Counter counts errors

Data & Remote Frame Generatorgenerates frame.

Error & Overload Frame Generatorgenerates frame whenever error oroverload condition occurs.

Serializer serializes parallel data.

In this architecture, ID Checker isoperating similar to acceptance filter ofprevious designs. Error checking blocksare separated. These separated blocksmake the architecture easy to modify andtest.

Our architecture can be easily upgraded toCAN version 2.0B and interface logic canbe realized with simple structure as shownin Figure 3. Figure 3 shows synthesisresult of Interface Logic targeting to 8051microcontroller. It can be adapted to anysystems with small modifications ofInterface Logic and FIFO size.

Field Manager

CRCError

Checker

FormError

Checker

BitError

Checker

StuffChecker Synchronizer

Error Counter

Error & Overload Frame Generator

Data & Remote

Serializer

Stuff

ReceiveBuffer

ReceiveFIFO

ID Checker

CRCCalculator

InterfaceLogic

TransmitBuffer

RegisterGroup

ACKError

Checker

TX

RX

HostProcessor


09-15

Figure 3. Synthesis result of InterfaceLogic

3. Verification Methodology

Verification is an important topic indesigning VLSI circuits. There has been aprevious paper work for verifying CANprotocol by using a verification systemcalled Mur [6]. The paper usesverification structure composed of onetransmitter and many receivers, where thereceiver can be varied according to theparameter N. Since Mur uses Murcompiler and Mur description language,it needs additional work during HardwareDescription Language (HDL) simulation.

The proposed method we used consists ofthree steps. In the first step, we developeda simulation model for verifying the CANcontroller as shown in Figure 4.

Node A Node B Node C

Tx Rx

Virtual HostModel

CAN Controller

Tx Rx

CAN Controller

Tx Rx

CAN Controller

Bus Model

Design Under Test

Virtual CAN

Controller

Tx Rx

Virtual HostModel

Virtual HostModel

Figure 4. Verification Model

The Virtual Host Model is operatingindependently and handles transmission ofdata or remote frames. It also checkswhether host interfacing is workingcorrectly. The Virtual CAN Controllertransmits error frames which can not be

generated by the Design Under Test(DUT). Bus Model can force the CAN busto be erroneous and monitor theverification results. In this simulationmodel, each CAN controller sends orreceives messages. This means any ofCAN controller can be a master. Also, thissimulation model can not only test thecontrollers behavior but also check theinterface to the host processor

Since the verification model shown in theFigure 4 was written in verilog HDL, wecould test our CAN controller during anytime of the design phase. As a result, theprototyping time has been greatly reduced.Figure 5 shows simulation example usingthe verification model.

Figure 5. Example of simulation

The second step of our verification is theISO conformance test specified in ISO16845. Conformance test is necessary fortesting interoperability between differentimplementations. In this test, we used thearchitecture of test plan (TP) described inISO 16845 and tested our design step bystep according to ISO 16845 document.

ISO 16845 is not perfect as mentioned inthe previous paper [6]. Therefore, as athird step of our verification, we made aFPGA verification system to check thedesign feasibility for real time applicationas shown in Figure 6.

For the prototyping of the design, AlterasExcalibur Development Board was used.We made two other test boards that cansend temperature and motor speed data.8051 microcontrollers were used as hostprocessors. Temperature and motor speeddata generation boards are designed byusing commercial CAN controller.


09-16

TemperatureMotor Speed

CAN BUSCAN BUS

FPGAPrototype

FPGAPrototype SJA1000

SJA1000 SJA1000SJA1000

8051?-controller

8051?-controller

8051?-controller

8051?-controller

FPGAPrototype

FPGAPrototypeSJA1000


FPGAPrototype


SJA1000SJA1000SJA1000

PCA82C250PCA82C250 PCA82C250PCA82C250 PCA82C250PCA82C250

8051?-controller

8051?-controller

TemperatureMotor Speed

CAN BUSCAN BUS

FPGAPrototype

FPGAPrototype SJA1000


8051?-controller

8051?-controller

8051?-controller

8051?-controller

FPGAPrototype



FPGAPrototype


SJA1000SJA1000SJA1000

PCA82C250PCA82C250 PCA82C250PCA82C250 PCA82C250PCA82C250

8051?-controller

8051?-controller

Figure 6. FPGA Verification System

The FPGA Verification System canchange the CAN protocol controller fromour design to commercial product.Therefore, we could test interoperabilitybetween our design and existing CANcontrollers in board level. The hostcomputer monitors and controls datacommunications on the CAN BUS usingRS-232 serial port. The clock frequencyused in this system was 24MHz and theCAN transmission rate was 1Mbit/s.

4. ASIC Implementation and Comparisons

The overall ASIC implementation flow ofthe designed CAN controller is depicted inFigure 7.

Figure 7. Implementation flow

Implementation process consists of front-end design and back-end design. In thefront-end design phase, proposedarchitecture was modeled using verilog

HDL and simulated the CAN functions withour verification model.

In the back-end design phase, synthesizedgate level netlist was translated into siliconlayout after placement and routingprocess. Because of parasitic capacitanceand resistance of interconnection of eachgate, we extracted Standard Delay Format(SDF) file and simulated once again withthis SDF information. After overallverification had been completed, wegenerated the final layout as shown inFigure 8 and the layout was fabricated byusing Hynix 0.35 _ CMOS process.

Figure 8. Layout of the designed chip

For the comparison of our design resultwith various other designs, weinvestigated previous papers which aresimilar to our work [1, 2, 4]. For faircomparison, only the core gate counts arecompared as shown in Table 1.

Table 1. Comparison of gate counts

Gate count of each block as shown inTable 2 has been obtained usingSynopsys Design Compiler and Hynixlibrary. Because we used timing


09-17

optimization options, the result ofsynthesis contains additional buffers andinterconnection area. As shown in Table 2,each block of the proposed CAN controllercould be implemented below 1000 gates,which means the design is efficient onsynthesis and easy to modify. Because thememory implementation is not relevant tosynthesis, we excluded memorycomparisons on both sides.

Table 2. Block synthesis comparisonFunction Blocksof the ProposedCAN Controller

#gates FunctionalBlocks of thepaper [2]

#gates

Interface Logic 100

ID Checker 62

Field Manager 627

bit timing 302

Synchronizer 594

Serializer 176

bit stuffing 212

Data & RemoteFrame Gen.

364

Error & OverloadFrame Gen.

207

message proc. 3368

CRC Calculator

(Including CRCError Checker)

325 transmission 1098

Error Counter 552

Stuff Checker &Stuff Generator

132

errormanagement

1186

Error Checkers(Ack, Bit, Form)

50 CRC 674

TOTAL 3189 TOTAL 6840

5. Conclusions

In this paper, we designed a stand-aloneCAN controller which is compatible to CANVersion 2.0A. The gate counts of corelogic of the designed CAN controller was3189 gates which is much smaller thanother CAN controllers. Also, theimplemented CAN controller can be easilyupgraded to Version 2.0B and has theflexible interface logic in order to make itpossible for interfacing with various hostcontrollers. Because the proposedcontroller is flexible and easy to modify, itis suitable for IP. Furthermore, we testedthe CAN controller with various methodsand the results were successful. Theproposed architecture was fabricated byusing 0.35 _Hynix CMOS process andpackaged with 100 Pin MQFP. The resultchip has 38.3712mW dynamic power andmaximum 25MHz operating frequency.

Since the need for System On a Chip(SoC) has been increased, the proposedCAN controller can be embedded into aSoC. Therefore, a further study andtechnology development is necessary inorder to harness the potential of CANprotocol.

Acknowledgement

This work was supported by Kyunghee-Davan ASIC Center at Kyung HeeUniversity.

References

[1] Kirschbaum A., Renner F. M., WilmesA., Glesner M., Rapid-Prototyping of aCAN-Bus Controller: A Case Study,Rapid System Prototyping, 1996.Proceed ings . , Seventh IEEEInternational Workshop on, 19-21 June1996

[2] J. de Lucas, M. Quintana, T. Riesgo, Y.Torroja, J. Uceda, Design of a CANinterface for custom circuits, IndustrialElectronics Society, 1999. IECON 99Proceedings. The 25t h AnnualConference of the IEEE, Volume:2, 29Nov.-3 Dec.1999 Pages:662-667 vol.2

[3] Guerrero C., Rodriguez-Navas G.Proenza J., Design and implementationof a redundancy manager for tripleredundant CAN controllers, IECON 02[Industrial Electronics Society, IEEE2002 28th Annual Conference of the],Volume:3, 5-8 Nov. 2002, Pages:2294-2299 vol.3

[4 ] Donchev B. , Hr is tov M. ,Implementation of CAN controller withFPGA structures, CAD Systems inMicroelectronics, 2003. CADSM 2003.Proceedings of the 7th InternationalConference. The Experience ofDesigning and Application of, 18-22Feb. 2003, Pages:577-580

[5] Winter A., Bittruf D., Tanurhan Y.,Muller-Glaser K. D., Rapid prototypingof a communication controller for theCAN bus, Rapid System Prototyping,1996. Proceedings., Seventh IEEEInternational Workshop on, 19-21 June1996 Pages:152-157


09-18

[6] Van Osch M., Smolka S. A., Finite-State Analysis of the CAN BusProtocol, High Assurance SystemsEngineering, 2001. Sixth IEEEInternational Symposium on, 22-24 Oct.2001 Pages:42-52

[7] ISO 11898-1, Road vehicles Controller area network (CAN), Part1:Data link layer and physical signaling,International Standard ISO 11898-1,2003

[8] ISO 16845, Road vehicles Controllerarea network (CAN) Conformancetest plan, International Standard ISO16845, 2004

[9] Wolfhard Lawrenz, CAN SystemEngineering From Theory to PracticalApplications, Springer, 1997

[10] Philips Semiconductors, SJA1000Stand-alone CAN controller DATASHEET, 2000

[11] Local Interconnect Network (LIN),http://www.can.bosch.com/LIN/LIN.html

[12] Florian Hartwich, Armin Bassemir,The Configuration of the CAN BitTiming, 6t h In ternat iona l CANConference, iCC, November 1999.

[13] Hoi Jun Yoo, IP Authoring and SoCDesign Methodology, TechnicalDocument at SIPAC, May 2003

About the author:

Namsub Kim received B.S and M.Sdegree in electronic engineering from theUniversity of Kyung Hee, Korea, in 1990and 1992. From 1994 to 1996, he was aprofessor in engineering department atKorea Naval Academy. From 1996 to1998, he worked at Hynix SemiconductorCorporation. He is at present a seniorresearcher at Davan-Kyunghee ASICCenter, and part-time instructor inelectronic engineering at the University ofKyung Hee.

Namsub KimDavan-ASIC Center at Kyung Hee Univ.Giheung, Yongin, Gyeonggi, South KoreaTel. +82-19-640-8698Fax [email protected]://asic.kyunghee.ac.kr

Dawi Kim

Kyung Hee UniversityGiheung, Yongin, Gyeonggi, South KoreaTel. +82-31-201-2196Fax [email protected]://asic.kyunghee.ac.kr

Kyuhyung ChoKyung Hee UniversityGiheung, Yongin, Gyeonggi, South KoreaTel. +82-31-201-2196Fax [email protected]://asic.kyunghee.ac.kr

Jinsang KimKyung Hee UniversityGiheung, Yongin, Gyeonggi, South KoreaTel. +82-31-201-2996Fax [email protected]://csvlsi.kyunghee.ac.kr

Wonkyung ChoDavan-ASIC Center at Kyung Hee Univ.Giheung, Yongin, Gyeonggi, South KoreaTel. +82-31-201-2195Fax [email protected]://csvlsi.kyunghee.ac.kr

can

Documents