Controller Area Network (CAN) Core - iCAN

October 23, 2003 Product Datasheet v1.3

Intelliga Integrated Design Ltd

Suite 3, The Boys British School East Street, Saffron Walden, Essex UK, CB10 1LS Phone: Fax: E-mail: URL: +1 44 (0)1799 528501 +1 44 (0)1799 528502 companioncore@intelliga.co.uk www.intelliga.co.uk
Technical Overview

What is CAN ?

CAN is a serial bus system with multi-master capabilities, that is, all nodes are able to transmit data and several CAN nodes can request the bus simultaneously. The serial bus system with real-time capabilities is the subject of the ISO 11898 international standard and covers the lowest two layers of the ISO/OSI reference model. In CAN networks there is no addressing of subscribers or stations in the conventional sense, but instead, prioritized messages are transmitted. CAN networks can be used as an embedded communication system for microcontrollers as well as an open communication system for intelligent devices. The CAN serial bus system, originally developed for use in automobiles, is increasingly being used in industrial systems. www.can.bosch.com

Product Summary
Applications Numerous automotive and Industrial uses

Automotive telemetry, comfort, security, entertainment and climate control CAN gateway nodes and diagnostic equipment

Key Features Supports ISP and OTP versions of Actel ProASIC

PLUS

, Axcelerator, RTSX-S and SX/SX-A family FPGAs

Standalone CAN Rev 2.0B compliant ASIC/FPGA design with flexible, segregated system interface that allows the user to decide the split between compile time configurability and software programmability Performs all MAC functions using extended identifiers supporting automatic insertion of overload and error frames and bus arbitration Low core gate count with transport buffers and acceptance filters conveniently accommodated in the system interface Noise immune sampler with configuration options, programmable digital synchronizer and baud rate prescaler Basic CAN supplied as standard with two reference design interfaces, one modeled on ARMs 16-bit APB style interface, the other a standard 8-bit MCU style interface Full hardware solution that may be implemented in FPGA devices without the need for a connected mircocontroller in basic sensor/actuator applications Reference designs uses a split clock architecture that enables simple integration and provides additional power saving features

General Description
Intelliga has designed a CAN core specifically for integration within both ASIC and FPGA based integrated circuits. Its uncomplicated interface and well-partitioned design makes it easily adoptable within systems that require either a full message handling CAN interface or a basic CAN implementation. As standard, Intelligas CAN core, the iCAN, is supplied as a basic CAN controller with a 16-bit APB or 8-bit MCU style bus interface, transmit and receive FIFOs and a single message acceptance filter. System interfaces supporting either full and/or basic CAN functionality can easily be configured to support a wide range of programming interfaces using Intelligas register bank compiler. In summary, iCAN is a fully featured hardware interface that contains all of the functionality expected from a CAN 2.0B compliant core that helps keep the software overhead to a minimum.

October 23, 2003

Controller Area Network Core iCAN

Intelliga Integrated Design Ltd

Core Deliverables
Netlist Version Compiled RTL simulation model, compliant with Actel Libero environment Netlist compatible with the Actel Designer place and route tool, with VHDL and Verilog Instantiation templates

RTL Version Source code (full design database, Verilog language)

All Versions Reference design source code (8-bit MCU and 16-bit APB interfaces with register set and split clock domains) Documentation pack (user guides for CAN core and reference designs) Self checking regression test bench with test vectors

Synthesis and Simulation Support Simplicity for synthesis, other tools supported on request Modelsim for simulation, other tools supported on request

Device Requirements
Family
PLUS

Device (-speed grade)

Utilization (Cells or Tiles) SEQ 152 153 153 153 COMB 1467 1237 1282 1282 Total 1619 (26%) 1390 (69%) 1435 (50%) 1435 (50%) RAM 0 0 0 0

Performance

Throughput

ProASIC

APA150-STD AX125-3 RT54SX32S-1 A54SX32A-3

16 MHz 28 MHz 16 MHz 22 MHz

1 Mbps 1 Mbps 1 Mbps 1 Mbps

Axcelerator RTSX-S SX/SX-A

Table 1: Device Utilization and Performance

Functional Description
The CAN core is divided into four main sections. A controller module lies at the centre of the design and is responsible for operating the main CAN protocol state machines. A sampler module over-samples the receive data stream and a synchroniser module extracts the asynchronous clock and data information. Finally, a fault confinement module performs error detection and reporteding tasks. The top level of the CAN core is a structural block that instantiates the sub-modules. Controller Module This module provides all of the main state machine control aspects of the core. It maintains a bit counter that is used to count the number of bits in each field so that message packets can be created and decoded. The main state machine contains individual states for each message field that are navigated according to the requirements of the CAN protocol. A transceiver mode bit is maintained which stores the current mode of the transceiver (ie transmit or receive) that is modified when a transmitter (master) looses arbitration against another device transmitting simultaneously. The main controller module also includes the CRC generation and check function, the bit stream coding function (bit stuffing), management of error and overload frames, and the 8-bit transmit and receive shift registers. For maximum flexibility, the controller module exports a selection of well-defined handshaking signals and data strobes that allow a variety of system interfaces to be easily integrated. On the transmit side, message
October 23, 2003 2

Controller Area Network Core iCAN

Intelliga Integrated Design Ltd

transfers are requested and acknowledged using a pair of handshaking signals. The required data bytes are supplied when the load data strobe is asserted according to the address provided. The receive data pipe is symmetrical. Received message data is signalled as ready and accepted by the system interface using a pair of handshaking signals. Data is unloaded across the byte wide receive data port whenever the data strobe is asserted. The data type is indicated according to the address given. This interface allows data bytes to be transferred to and from external FIFOs and memories using sequential addresses if the system interface can decode the length of the message at load or unload time. Alternatively, the message data ports can be used to source and sink information from specific memory addresses using the address busses provided.
APB Software Interface Basic CAN Interface APB Register Bank
Configuration, Control and Status clock reset enable silent active sampler_select[1:0] sampler_latency[1:0] sampler_duration[5:0] sampler_rate rx_error_count[8:0] prop_seg_duration[3:0] tx_error_count[8:0] phase_seg1_duration[3:0] error phase_seg2_duration[3:0] error_level[1:0] resyn_jump_width[2:0] error_type[2:0] error_level_warning_threshold[8:0] error_level_warning

Flow Control

can_core.v

Optional Async TX / RX FIFOs

CAN Bus Controller

CAN Core

Fault Confinement

rx_serial_data rx_serial_data_sense tx_message_request tx_message_load_data[7:0] rx_message_accept

Serial Bit Streams

tx_serial_data tx_serial_data_sense

Synchroniser TX Shift Register Sampler RX Shift Register

Message Data Ports

tx_message_acknowledge tx_message_load_address[3:0] tx_message_load_strobe rx_message_ready rx_message_unload_address[3:0] rx_message_unload_strobe rx_message_unload_data[7:0]

CAN Bus Drivers

Figure 1: CAN Core Block Diagram and Pinout

Sampler The sampler performs three basic functions. Firstly it synchronises the received serial data stream to the local peripheral clock domain using a metastable resolver. Secondly it samples the data stream at a defined over-sampling rate and optionally performs an integration function for glitch suppression. Lastly it captures the sampled data at the capture point defined by the segment durations for processing by the controller. The synchroniser module generates the over-sampling rate strobe internally together with a capture strobe which defines the point at which the incoming data is captured. Four integration options are supported; no integration, integrate 2 of 2 sample, integrate 3 of 3 samples and majority detect 2 of 3 samples. The synchroniser module is designed to compensate for the integration latency according to a given delay specification. Synchroniser This block is responsible for recovering the bit timing from the over-sampled receive data stream. It works according to the synchroniser requirements outlined in the CAN 2.0B specification, which is based upon a hard synchronisation to the start of a frame and subsequent resynchronisations so that small frequency offsets and phase errors can be tolerated. This implementation also includes an over-sampling rate prescaler, which is programmed to produce a strobe at twice the CAN quantisation rate. In addition to the sample strobe, a capture strobe is also generated so that the incoming data can be captured at the desired sampling point. A bit strobe, with programmable compensation for sampler latency is also produced which is asserted to signal the start of each bit period. Fault Confinement Module Errors detected in a CAN system are kept local to device controller by the mechanism of fault confinement detailed in the protocol specification. Five types of errors may be detected, a bit error, stuff error, CRC error form error and acknowledgement error. This module is responsible for detecting all of the error conditions
October 23, 2003 3

Controller Area Network Core iCAN

Intelliga Integrated Design Ltd

(except the stuff error) and acting upon them. Two fault confinement counters are maintained, one for transmit errors and the other for receiver errors. Depending on the errors detected the counters are incremented by different amounts. All twelve fault confinement rules are decoded, together with their exceptions so that the counters can be incremented, decremented and cleared down when required. Both error counts and an error level signal are outputted so that the controller can act on the error active, error passive and bus off states and so that software can read the current value of the error counts.

Offset Register

Description

Size

0x00 0x02 0x04 0x06

general_conf synchroniser_conf fifo_conf rx_id_filter_mask

Holds configuration parameters for the sampler and serial data sense conversion logic Synchroniser configuration parameters that define the segmented durations within the bit period Configuration register used to set the water marks for the transmit and receive FIFOs Configuration register is used to specify the receive message acceptance mask Configuration register is used to specify the receive message acceptance code Real time control register used to enable the controller Read only register used to communicate real time status information to the software Byte wide transmit data load port Byte wide receive data unload port Used to communicate the accumulated weighting of the detected transmit errors Used to communicate the accumulated weighting of the detected receive errors Programmable threshold for the error level warning interrupt Reports interrupt status for transmit and receive port flow control and error reporting. Enables for various interrupt sources. Disables for various interrupt sources. Clears for various interrupt sources.

0x02 0x02 0x02 0x04 0x04 0x01 0x01

0x0A rx_id_filter_code 0x0E control 0x0F status 0x10 0x11 0x12 0x14 0x16 0x18 tx_message_port rx_message_port tx_error_count rx_error_count error_warning_thresh interrupt_status

0x02 0x02 0x02 0x02 0x02 0x02 0x02

0x1A interrupt_enable 0x1C interrupt_disable 0x1E interrupt_clear

Table 2: CAN Core with 8-bit MCU Style System Interface Register Set

Reference Design Two reference designs instantiate the CAN core together with register banks and a system interface modules. The first one is modelled on a 16-bit AMBA APB style interface, the second a simple 8-bit microcontroller architecture.

October 23, 2003

Controller Area Network Core iCAN

Intelliga Integrated Design Ltd

Core I/O Signals

The core signal I/O have not been fixed to specific device pins to provide flexibility for interfacing with user logic. Descriptions of the 62 I/O signals for a fixed timing configuration are provided in Table 3.

Signal

I/O

Description

clock reset rx_serial_data tx_serial_data tx_message_req tx_messag_ack tx_message rx_message_ready rx_messag_accept rx_message tx_load_addr[3:0] tx_load_strobe tx_load_data[7:0] rx_unload_addr[3:0] rx_unload_strobe rx_unload_data[7:0] overload error error_type[2:0] error_level[1:0] warning tx_error_count[8:0] rx_error_count[8:0]

input input input output input output output output input output output output input output output output output output output output output output output

CAN core clock CAN core reset Receive serial bit stream Transmit serial bit stream Asserted by the system interface to initiate a new transmit message Handshake for the transmit request line Signals that a transmit message has been successfully encoded Asserted by the core to signal that a new receive message is ready Handshake for the receive ready line Signals that a receive message has been successfully decoded Identifier for transmit load byte, valid when transmit load strobe is asserted Transmit data load stobe, asserted for identifier, control and data bytes. Data/idenitifer/control byte provided for transmition over the CAN bus Identifier for receive unload byte, valid when receive unload strobe is asserted Receive data unload stobe, asserted for identifier, control and data bytes. Data/idenitifer/control byte received from the CAN bus Asserted to report the detection of the CAN overload condition Asserted to report the detection of a CAN bus error Valid when the error line is asserted to indicate the type of error detected. Reports the current error level (error passive, active, bus off) Asserted when the either the transmit or receive error counts reach the warning threshold Report of the current transmit error counter Report of the current receive error counter

Table 3: Core I/O Signals (Fixed Timing Configuration).

A number of configuration settings are required to set the baud rate and frame spacings. These signals may be tied off for fixed configuration implementations or connected via register banks if programmability is desired. The 8-bit MCU reference design provides an example of how such programmability may be acheieved. The pinout for the MCU reference design is shown in table 4.

October 23, 2003

Controller Area Network Core iCAN

Intelliga Integrated Design Ltd

Signal can_clock can_reset rx_serial_data tx_serial_data interrupt clock reset select write_strobe read_strobe address[4:0] write_data[7:0] read_data[7:0]

I/O Input Input Input Output Output Input Input Input Input Input Input Input Output

Description Synchronous clock for the CAN peripheral clock domain Synchronous reset for the CAN peripheral clock domain Receive serial bit stream Transmit serial bit stream Local MCU interrupt Synchronous clock for the MCU system clock domain Synchronous reset for the MCU system clock domain Select line for register read/write access Register write strobe Register read strobe Register access address Register write data Register read data Table 4: Reference Design I/O Signals.

Core Modifications
Intelligas CAN core is a generic module that is ideally suited to all CAN applications. However, it may be desirable to implement an alternative system interface that is suited to a particular application. On request, Intelliga can supply alternative interfaces that support a wide range of programming models using their inhouse register bank compiler. Alternatively, the customer may modify the reference design provided or construct a new one according to their requirements.

Verification Methods
The CAN core has been implemented sucessfully on a number of programmable logic development platforms including Intelligas iDEV2 automotive development kit. A self checking regression test bench is also included that performs detailed low-level tests of the CAN core.

Recommended Design Experience

The user must be familiar with HDL design methodology and have a basic understanding of the features of the CAN protocol.

Ordering Information
This product is available directly from Actel CompanionCore member Intelliga Integrated Design Ltd under the terms of Intelligas IP license. Please contact Intelliga for pricing and additional information about the iCAN core. Intelligas contact details are printed on the front page of this datasheet.

October 23, 2003