Decades ago, one could integrate a CAN-based product using either a standard controller chip, a standard microcontroller with a built-in CAN interface, or even an ASIC with CAN interface. Today, a better solution is added to the ones mentioned above which are the FPGA-based CAN modules [61]. So far, there have been many studies on IP-based CAN interfaces, however, researchers are still finding new solutions to improve the overall performance of the CAN interface module. We also developed our CAN-module as an IP block for a variety of reasons of whichfull compatibility with our target processor (COFFEE) is one of the most prominent ones. The main reason is that the COFFEE processor is made by our research group, hence, we know how the core behaves in different situations. We will further investigate the compatibilities later on. Nevertheless, designing a fully compatible CAN interface is one of the main interests. In addition to that, integrating the IP-based CAN module is not only limited to the COFFEE core. It is integrable with any other standard RISC processor, as well. Another advantage of the CAN module is that it can be (loosely) coupled with the COFFEE core via a dedicated co-processor slot. Therefore, there will be no additional overhead on the memory-mapped data bus since the co-processors are connected to the core via the co-processor bus.
Henceforth, we refer to the CAN module by using the term"CAN co-processor".
4.5. Design Considerations 55 SOF Arbitration Field RTR
Control Data Node 1
ID: 11100101XXX Node 2 ID: 11100100100
Node 3, ID: 1110011XXXX
Node 4, ID: 111001001XX
CAN Bus Level 11100100100
10 9 8 7 6 5 4 3 2 1 0
Figure 4.3: How the CAN nodes are prioritized to access the media.
4.5.1 Arbitration
In a CAN system, each node can simultaneously transmit data while listening to the media.
Figure 4.3 presents how each node accesses the shared media based on the prioritized arbitration field. The identifications of the nodes are assigned by the system designer.
The highest priority is defined in the LSB bits of the arbitration field. It means that a node with a dominant bit in the LSBs has the priority over the other ones with recessive bits. For example, consider the ID of the Node 2 "11100100100", alongside the Node 1
"11100101XXX" in the same figure. Since Node 2 transfers a dominant bit in the fourth LSB (ID[3]), it overrides Node 1 whose ID[3] is a recessive bit. Accordingly, Node 1 learns that another node with higher priority is transmitting at the same time, hence, it immediately stops its transmission. Henceforth, nodes with lower priorities, as well as the silent ones are the receivers of the message. The CAN bus is always granted to a node with the highest priority message.
4.5.2 Data Management
The COFFEE processor exploits four co-processors which share 64 numbers of 32-bit registers (4×16). In addition, we studied that the length of a CAN message varies between 0 to 8 bytes. In this implementation, the co-processor always provides the core with 8-byte data (64 bits), irrespective to the data length. Hence, the processor should refer to the co-processor in two consecutive attempts to obtain the entire data. On the other hand, there is a possibility that the processor is interrupted between the first and second attempts to the corresponding co-processor. Therefore, the co-processor is designed to enter the standby mode to prevent register overwriting in case the core is interrupted.
Hence, the second reference from the processor to the co-processor is returned with the appropriate portion of the data. Data coherency is guaranteed by the co-processor as follows.
When the processor refers to the co-processor to fetch the data, it should read two specific registers from the co-processor shared register bank. Hence, the processor keeps the signal cop_rd set for two consecutive clock cycles. In case the processor is exactly interrupted at
56 Chapter 4. Reconfigurable IP-Based Controller Area Network Module
Farid Shamani
Shared Register Bank
clk rst_n cop_rd cop_wr r_index (4:0) cop_exe (3:0) data (31:0)
C O F F E E
CAN_clk data_bus
ack error
C A N
c_index (1:0) CAN
Co-Processor
ack error
Figure 4.4: The integration of the co-processor with the COFFEE core, as well as the CAN system [P. VI] © IEEE, 2016.
the second reference, the processor will clearcop_rd. Instantly, the co-processor is alerted about the cause and it changes the state to standby mode. In this mode, any permission to write to the destination registers in the register bank is denied by the co-processor.
Instead, the co-processor starts buffering the incoming packet. Once the internal buffer of the co-processor is about to overflow, the co-processor immediately interrupts the core in case the processor has not referenced the co-processor yet.
4.5.3 Error Handling
There are four types of errors that can occur in a CAN-based transmission. The co-processor is designed to detect and broadcast to all nodes when one of the following fault containments occurs.
• bit error: happens when the transmitted bit differs from what the receiving node expects, e.g. the data length is more than 8 bytes.
• form error: When the general format of the frame is altered (e.g. wrong logic value in delimiters).
• bit stuffing error: occurs when 6 consecutive bits of the same type have been found by the receiver (excluding the EOF).
• Acknowledge error: happens when the transmitter never receives an acknowledge from the receiver.
• CRC error: is detected by the receiver when the computed value in the CRC field is different from the received CRC.
The transmitter is able to detect the bit error, along with the acknowledge error, whereas the receiver detects the form error, bit stuffing error, and CRC error. As soon as an error is found by a node, an error frame is broadcast to the network, thus, all other nodes will be notified about the cause.