CAN FD chips: different buffer features and capabilities

Several IP core vendors have announced CAN FD products. Some of these CAN FD cores are already implemented in micro-controllers. They differ especially regarding the message buffer capabilities and other dedicated features.

By Annegret Emerich, Holger Zeltwanger April 30, 2017

The ISO 11898-1:2015 standard specifies the CAN FD protocol. All implementations have to follow this standard to conform to ISO CAN FD. Conformity testing will be standardized in ISO 16845-1:2016. On the TXD and RXD lines, all controllers behave alike. Of course, some optional features are not supported by all implementations. Also, some older implementations are not consistent with the ISO standard. The CAN community has agreed to term these non-ISO CAN FD.

The first implementation, the M_CAN module by Bosch, has been updated to comply with ISO 11898-1:2015. Several micro-controller manufacturers have adapted it, but none—including Bosch—offers the M_CAN module as a stand-alone CAN FD controller yet. 

M_CAN: The “grandmother” of implementations

Bosch’s M_CAN module has passed several improvement steps. Originally, it implemented the original CAN FD protocol (non-ISO CAN FD). Today, the IP core supports both the ISO CAN FD and the non-ISO CAN FD protocols. Theoretically, it can be realized as a stand-alone device, as part of an ASIC, or as an FPGA. Of course, it can also be integrated in a micro-controller. The CAN module is described in VHDL on RTL level, and is prepared for synthesis. It needs two clock domains: CAN and host clock, which are synchronized internally. Due to the synchronization mechanism between the two clock domains, there may be a delay until the value written to INIT can be read back. Therefore, the programmer has to assure that the previous value written to INIT has been accepted by reading INIT before setting INIT to a new value.

According to Bosch, the message storage is intended to be a single- or dual-ported RAM outside of the module. It is connected to the M_CAN via the generic master interface. Depending on the chosen integration, multiple CAN controllers can share the same message memory. The external Rx and Tx message memories can be organized as buffer or FIFO. If the data field size of an accepted CAN frame exceeds the configured size for the matching Rx buffer or Rx FIFO, only the configured number of bytes is stored. The rest of the frame’s data field is ignored.

If the data length code of a Tx memory element is configured to a value higher than the Tx data field size, the undefined bytes are transmitted as CC16 (padding bytes). Like most implementations, the M_CAN does not check for erroneous configurations of the message memory. Especially the configuration of the start addresses of the different sections and the number of elements of each section has to be done carefully to avoid falsification or loss of data.

The Rx and the Tx handler implement all functions concerning the management of messages. The Rx handler is responsible for the message acceptance filtering, the transfer of received messages from the CAN core to the message memory, and provides receive message status information. The Tx handler manages the transmission of messages from the message memory to the CAN core and provides transmit status information. Acceptance filtering is implemented by a combination of up to 128 filter elements, each of which can be configured as a range, as a bit-mask, or as a dedicated ID-filter.

The M_CAN module is delivered with a 32-bit CPU interface. For FPGAs, an exemplary interface converter is provided (e.g. to an Avalon interface). It can be replaced by a user-defined module interface. The module provides interrupt control functionality and 16-bit CAN bit time counters for receive and transmit timestamp generation. An externally generated 16-bit vector may substitute the integrated counter. The M_CAN requires about 31 000 gates and about 17 KiB of RAM for message buffering. Additional logic for the host controller interface and message arbitration is needed. 

Other CAN FD cores

Besides Bosch, several companies provide CAN FD cores: Fraunhofer/Cast, IFI, Inicore, Kvaser, and Peak. The CAN controller offered by Cast has already undergone a second round of real-world-like testing at the CAN FD plugfest run by CAN in Automation. Sourced from Fraunhofer IPMS, the CAN-CTRL CAN/CAN FD controller core is one of the ASIC RTL and FPGA netlist IP cores to support all current and proposed specifications (CAN, ISO and non-ISO CAN FD, and TTCAN).

Kvaser’s CAN FD IP core also passed the bit-rate tests at the second CAN FD plugfest. The company has developed a complete set of IP blocks for CAN FD, primarily for integration into its own FPGAs. By partnering with Synective Labs, Kvaser’s IP modules will be made available for FPGA and ASICs for any non-strategic customers. The CAN FD implementation complies with both ISO and non-ISO CAN FD. Often such IP cores are implemented in FPGAs with additional circuitry to be used in interface boards for PC-based and other tools including data recorders. In general, these IP cores are very flexible regarding the acceptance filtering and message buffering functions. 

Other CAN FD implementations

Several chipmakers have started to develop their own CAN FD controllers integrated in micro-controllers. They provide dedicated functions regarding message buffering and gateway functionality. The hardware filtering for messages uses the acceptance-filtering list (AFL) with up to 384 entries. Each entry is a reception rule (which (set of) messages to accept, which HRH handle of Autosar shall be assigned, which minimum length of accepted messages is required, and where to store these accepted messages). Received CAN FD frames can be filtered based on IDs (11-bit and 29-bit) and DLC value.

The transmission of messages depends on the priority or the buffer number. Each message can be disabled individually. The transmit history list with 16 entries per channel is organized as FIFO. This list records the successfully transmitted messages optionally with Autosar references (HTH or soft-ID). For multi-purpose FIFO units, transmission interval timers are available. There is no delay when the FIFO is enabled. The interval between messages continues even if the FIFO becomes temporarily empty during the delay time. Transmission stops and resets the delay when the FIFO is empty.

The RS-CAN FD implementation by Renesas is scalable from one to six CAN FD modules. Multiple module implementations provide dedicated routing functions. This includes a message routing; signal routing is not supported. The AFL filters the received messages from any channel. In gateway mode, one AFL storage target is a multi-purpose FIFO, which is bound to a channel in TX direction. The assigned channel of the this FIFO transmits the received messages via one of its message buffers. These CAN FD modules are already used in the RH850/F1K micro-controller family by Renesas. In the current version, this is based on FIFO hardware without priorities. In the next version, prioritized queues will be supported. They will provide a significantly larger message buffer size.

Microchip has not yet disclosed details on its CAN FD implementation, which is based on Kvaser’s IP core. The chipmaker plans a CAN FD stand-alone controller and micro-controllers with on-chip CAN FD modules. By the end of this year, samples should be available. The prototypes of the stand-alone controller has been used successfully in the CAN FD plugfests organized by CiA.

Additional features and modes

Time stamping of messages is a requirement of several OEMs. CiA is working on the CiA 603 specification standardizing the frame time stamping for the network time management. This is independent of the employed CAN protocol (Classical CAN or CAN FD). Nevertheless, CAN FD implementations need to support this function. Current implementations do not provide this time stamping functionality because it is not yet specified in all details. The CiA Interest Group (IG) CAN FD intends to release the specification at the end of this year. The RS-CAN FD module supports time capturing at SOF sample-point and FDF-res edge and in the future it will also support EOF time-stamping (32 bit) as specified in CiA 603.

Most of the available CAN FD implementations support additional modes. Besides the normal operation mode as specified in ISO 11898:2015, nearly all CAN FD controllers provide a listen-only mode and a low-power (sleep) mode. Other special-purpose modes include a non-automatic re-transmission mode (single-shot transmission), a test mode, as well as external and internal loop-back mode. The external loop-back mode (M_CAN) is intended for hardware self-testing. In the internal loop-back mode, the M_CAN is not connected to the bus, so that the self-test has no effect on other nodes connected to the network. 

Summary and outlook

CAN FD implementations differ in their add-on functionality. Selecting one is not that easy; you need to look at the requirements of the application. The host controller interface is not highly standardized. In CiA 601-2, some recommendations and guidelines are given. Software engineers have to design the low-level driver programs properly, in order to avoid lost messages and other unwanted behavior. 

CAN FD interfaces will be increasingly implemented in micro-controllers and the majority will be based on M_CAN. Like in the past, increasingly ASIC and FPGA solutions will be developed for special-purpose applications. For them, the user has the choice of enough CAN FD cores offered by different companies.

Annegret Emerich is technical director at CAN in Automation (CiA), Holger Zeltwanger is CiA Managing Director. CAN in Automation is a CFE Media content partner. Edited by Chris Vavra, production editor, Control Engineering, CFE Media,

ONLINE extra

See additional stories from CAN in Automation linked below.