Figure 1: Comparison of the protocol frames

© esd electronics

- Retention of the classic CAN concepts in the arbitration and confirmation phase as well as in error handling.

- Increasing the bit rate in the data phase from the previous maximum of 1 Mbit/s to up to 8 Mbit/s and more.

- Increase in the number of data bytes transmitted in a CAN message from the previous maximum of 8 to 64 bytes.

The new protocol has been published as an international standard since 2015, although all CAN FD controllers are downward compatible and continue to support the classic CAN protocol. There is now a wide range of dedicated CAN FD controllers, microcontrollers with integrated CAN FD interfaces and FPGA-based solutions.

The protocol details

In classic CAN, the transmission of a message can be roughly divided logically into the bus arbitration, data and acknowledgement phases. The bits are transmitted at the identical bit rate in all phases, with all bus participants continuously post-synchronizing them in order to compensate for phase noise and drift of the independent local oscillators. This is particularly necessary during the arbitration and confirmation phase, as several nodes transmit simultaneously on the bus and each individual node must be able to compare its transmitted bit with those of other bus participants. This characteristic of the classic CAN protocol determines the physical limits for the maximum possible bit rate or cable length.

Table 2: The CAN to CAN FD bit ratio

© esd electronics

A statement about the expected gain in throughput or the reduction in latency when switching from CAN to CAN FD is not easy to determine directly due to the type of implementation and depends heavily on the protocol used and other boundary conditions.

For a better estimate, Table 2 shows the bits required for the transmission of messages with 11-bit identifiers with different data lengths and different ratios between the bit rate in the arbitration and data phase for CAN FD. The number of message bits refers to bit times of the arbitration phase.

Based on Table 2, two extremes are to be considered with regard to the effort involved in a changeover from CAN to CAN FD.

Conversion from CAN to CAN FD

without changing the protocol

In the best case scenario, the (software) effort is reduced to setting the increased bit rate in the data phase in addition to the purchase of CAN FD-capable hardware. With a ratio between arbitration and data phase bit rate of 1:4 and a protocol that is mainly based on messages with 8 data bytes, an improvement in throughput by a factor of more than 2 or a corresponding halving of latency times can be expected.

with change of protocol

Figure 3: The ratio of arbitration to data phase bit rate in performance optimization with CAN FD payloads of 8/64 bytes with different bit rate ratios.

© esd electronics

If, in addition to increasing the data rate, the protocol is adapted with additional software effort so that the higher number of possible data bytes with CAN FD is utilized, even greater increases in performance are possible. Based on the previous example, a protocol (e.g. for updating a device) that was previously based on 8-byte CAN messages is to be converted to 64-byte CAN FD messages. Figure 3 looks at blocks of 64 bytes.

The diagram shows that with an unchanged protocol and a ratio of arbitration to data phase bit rate of 1:4, the data throughput is more than doubled, as in the previous example. Utilizing the full 64 bytes of CAN FD user data, the data throughput increases fivefold and with a further increase in the bit rate ratio to 1:8, it increases more than ninefold. In the latter case, the transmission of the 64-byte CAN FD message requires even less time than the transmission of a single 8-byte CAN message in the original version of the protocol, so that an additional reduction in latency is achieved under these boundary conditions.

Migration to CAN FD

for hardware developers

Supporting CAN FD for new hardware developments is now comparatively simple. As with classic CAN, driven by the automotive industry, one or more CAN FD interfaces are replacing the classic CAN interfaces in current microcontrollers. Up to a certain ratio of the bit rate of the arbitration phase to the data phase, CAN FD accepts the same oscillator tolerance as CAN, but it is advisable to use a transceiver specified for CAN FD, whose advantages benefit the customer, even when used exclusively with classic CAN. Adding a CAN FD connection to existing designs is also easy to implement with standalone controllers that are now available or by using an FPGA IP core.

For software developers

The effort involved in migrating an application to CAN FD depends heavily on the API previously used for classic CAN. If this remains available unchanged for the CAN FD hardware, migration can take place in three steps.

1. All participants use the CAN FD interfaces as before with the classic CAN protocol.
2. All participants in the data phase switch to using a higher bit rate, which immediately leads to a reduction in latency and bus utilization or an increase in throughput if the protocol remains unchanged. The developer must first check whether his protocol requires the sending of RTR messages, as this is no longer supported with CAN FD.
3. Modification/extension of the protocol by transmitting more than 8 bytes of user data.

In addition to a further gain in data throughput, the last step facilitates in particular the solution of problems in connection with data consistency of more than 8 bytes of user data as well as the implementation of protocols, for example in the area of safety and security, which are often difficult or impossible to realize with only 8 bytes of user data. In step 3 in particular, however, the developer must check whether the desired real-time properties of his implementation (latency times) have been retained.

For system integrators

The advantage for system integrators when migrating to CAN FD is that the bus devices with a classic CAN controller can initially be replaced - even in several stages - with bus devices with a CAN FD controller. Due to the downward compatibility, the classic CAN protocol can initially continue to be used. If there is a need for more bus bandwidth and/or lower latency at a later date, the application can be converted accordingly, with the advantage of being able to switch back to the classic CAN status at any time if there are problems with CAN FD communication, as the wiring remains unchanged. The only disadvantage of migration is that a changeover to CAN FD can only take place when all bus nodes support the CAN FD protocol, as classic CAN controllers interpret CAN FD messages as protocol errors.

Higher layer protocols

The author: Oliver Thimm is Head of System Design at esd electronics.

© esd electronics

Following the publication of the standard in 2015, a number of classic CAN-based higher layer protocols from various industrial domains have now also been adapted to the CAN FD extensions or are about to be published. Examples include ISO TP and J1939 (automotive industry), CANopen FD (automation) and ARINC825 (aviation).

Short interview: Why migrate to CAN FD?

Dirk Flege is Sales Manager at esd electronics.

© esd electronics

The CAN FD protocol with a higher and more flexible data rate has been standardized for a good four years. Thanks to the downward compatibility of this technology, classic CAN applications can be migrated to CAN FD or used as the basis for new applications. Dirk Flege, Sales Manager at esd electronics, explains the benefits of migrating to CAN FD.

The CAN protocol is characterized by its great robustness against interference. How is this characteristic of the CAN protocol maintained with CAN FD?

Dirk Flege: The CAN FD protocol is designed in such a way that classic CAN concepts can be retained in the arbitration and confirmation phase as well as in error handling. In order to achieve the same robustness against communication errors in the longer data phase, the protocol uses a 17-bit checksum (messages with up to 16 bytes of user data) or a 21-bit checksum (messages with more than 16 bytes of user data) instead of the usual 15-bit checksum.

The CAN FD protocol is downwards compatible with the classic CAN protocol. What opportunities does this offer for industrial automation?

Flege: Thanks to the backwards-compatible design, CAN applications can be easily converted to the more powerful CAN FD communication without having to change the existing wiring. Alternatively, CAN FD components can also be used as a basis in current CAN applications and simply converted to CAN FD communication at a later date.

In addition to standard CAN FD controllers, FPGA-based CAN FD controllers are also available on the market, which offer greater flexibility in terms of performance and functional density. What advantages do FPGA-based CAN controllers offer?

Flege: Write and especially read access to standard controllers is rather slow compared to the cycle time of modern CPUs. We have therefore developed an FPGA-based CAN controller, which now forms the basis of our CAN interfaces. The Advanced CAN Controller (esdACC) has an up to 32-bit wide interface, supports a 64-bit timestamp and can generate a 100 percent bus load. The CAN FD controller for FPGA, which supports the CAN FD protocol in accordance with ISO11898-1:2015, is derived from this.

What are the specific advantages of the FPGA for CAN FD interfaces?

Flege: The CAN interface "CAN-PCIe/402-FD", for example, is a universally applicable board that was developed for the PCIe bus and has one or two CAN FD interfaces in accordance with ISO 11898-2. It uses bus mastering for data transfer to the host memory. This reduces the latency time during I/O transactions, in particular due to the higher data rate and the reduction of the CPU load. By using MSI (Message Signaled Interrupts), the PC board can work in hypervisor environments, for example. It also supports high-resolution hardware timestamps.