CAN Newsletter magazine
Bosch has improved its M-CAN. The added functions include a DMA interface unit (DMU) and a time stamping unit (TSU).
This article originally appeared in the June issue of the CAN Newsletter magazine 2019. This is just an excerpt.
The DMU add-on allows the reduction of the host controller load by off-loading the transport of CAN frames to a DMA controller. The TSU expansion module enables hardware-based and Autosar-compatible time synchronization. When exchanging CAN data frames between the host controller and the M_CAN protocol controller, there are some issues to consider, especially for complex SoCs (system-on-chip). Due to the high complexity of modern SoC architectures, the on-chip communication paths are divided into several domains of different performance. The bridging between domains additionally slows down performance, e.g. due to clock-domain crossings.
The heat-map (red = fast, blue = slow) in Figure 1 illustrates the speed of data transfers initiated by the host controller in the processor domain. Thus, the connection of the host controller core to the dedicated caches is the fastest, followed by the TCM within the cluster. When creating the software, it must be ensured that these memories can be used efficiently. In extreme contrast to this, single accesses to components in the peripheral domain can be up to 30 times slower. If, for example, the continuous exchange of CAN frames between the host controller and a M_CAN unit is considered, the following interactions are typically required:
If the cores in the processor domain would perform these interactions, they would be significantly slowed down by the NoC (network on chip). For example, such interactions can also be done via a processor core within the peripheral domain, if available. However, this article focuses on a different approach that does not allocate computational resources of any processor core.
Bosch offers an add-on for the M_CAN called DMU. With this, the continuous exchange of CAN data frames can be completely outsourced to a DMA controller. The add-on unit is based on the concept of virtualizing the FIFO (firstin, first-out) head elements (Figure 2). The M_CAN has an associated message RAM (MRAM), which i.a. contains the elements (CAN data frames) organized in FIFOs. To access the memory segment of the current message (head element) within these FIFOs by the host controller, the respective pointers (read/write pointer) from the M_CAN must previously be queried. To avoid this, accesses to fixed address areas are virtualized. The DMU dynamically redirects these accesses to the head elements in the MRAM. The redirection is controlled invisibly within the DMU by the FIFO pointers in the M_CAN.
The size of the reserved areas corresponds to the largest possible frame elements, which are 18 words (32-bit) for the TX, RX0, and RX1 elements and two words (32-bit) for the TX Event element (three words, if the TSU timestamp is also transferred). The transfer of a last element word activates a process in the DMU, in which for TX elements the transmit request is set in M_CAN, or for the other elements (RX0, RX1, TXE) the dedicated FIFO acknowledge is set in the M_CAN unit. Thus, writing or reading the CAN data frames via DMU elements completes the whole queuing/de-queuing process in the M_CAN unit. The DMU supports data frame transfers from the CRAM to the TX-FIFO/Queue and vice versa, from the RX-FIFOs respectively the TX-event FIFO to the CRAM. The block diagram in Figure 3 shows the M_CAN unit with the add-ons DMU and TSU. The host controller accesses to the M_CAN are routed through both add-on modules.
News and reports