Communication control device, semiconductor device, vehicle, and communication control method
The communication control device with a transfer protection unit addresses resource interference by controlling data transfer based on process identifiers, ensuring valid data transmission and efficient resource management in shared communication networks.
Patent Information
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- RENESAS ELECTRONICS CORP
- Filing Date
- 2022-09-13
- Publication Date
- 2026-06-24
Smart Images

Figure 0007879771000001 
Figure 0007879771000002 
Figure 0007879771000003
Abstract
Description
Technical Field
[0001] The present invention relates to a communication control device and a communication control method.
Background Art
[0002] Communication control devices such as CAN (Control Area Network) controllers and Ethernet controllers can usually process transmissions from different initiators (CPU cores, operating systems, processes, etc.) by providing independent transmission resources. The transmission resource is a hardware element that holds data for transmission, either directly as a transmission object or indirectly as a pointer to a transmission object in memory.
[0003] Normally, transmission resources are protected at the system level. For example, CPU memory management unit (CPUMMU), input / output memory management unit (IOMMU) access control or content guard is used.
[0004] The CPUMMU protects access to memory or special functional registers (SFRs) by the CPU. The operating system sets the MMU table according to the currently executing process.
[0005] The IOMMU (Input Memory Management Unit) is located in front of the DMA (Direct Memory Access) controller. This type of memory management unit protects memory access performed by the DMA controller. Because the DMA controller can operate on behalf of different processes, it informs the IOMMU which process is currently running instead of using an identifier. The IOMMU has a set of tables (usually 1 to 8 tables) for all processes, and the active table is selected by the identifier. An example of an IOMMU is the IPMMU, an implementation of the IOMMU compatible with ARM's VMSA (Virtual Memory System Architecture) page tables. For example, there are first and second processes and first and second transmit resources, and the first process has physical access to the first transmit resource, while the second process has physical access to the second transmit resource. Protection can be achieved by the second process not having physical access to the first transmit resource, which is achieved by IOMMU access protection or guarding. Thus, there is no interference between the first and second processes on the first transmit resource.
[0006] However, there are times when it is not possible or undesirable to permanently assign one resource to a single process. For example, a particular resource may have a large silicon footprint and therefore be costly to replicate. Another example is when the order of transfers needs to be preserved, in which case a resource may be provided as a single instance, such as a first-in, first-out (FIFO) buffer or traffic shaper. Finally, processes may interfere with each other.
[0007] Existing, commonly used memory management systems typically allow a memory region to be allocated to one or more specific processes. While this protects the memory region itself, it does not protect how the allocated processes use the resources. Furthermore, it does not protect shared resources from out-of-bounds use by the allocated processes.
[0008] Data rate limiters (such as credit-based shapers) and filters can be used for forwarding resources such as exit queues on the forwarding path to the network. However, if multiple DMA controller channels can add data to the same queue, such queue-based limiters only protect the network, rather than the resource itself.
[0009] Patent Document 1 discloses a communication device and communication method that can easily implement restrictions on the transmission of communication messages in accordance with the communication load of the network. A CAN controller is connected to a communication bus that constitutes an in-vehicle network and transmits and receives communication messages. The CAN controller is equipped with a bus load measurement unit and calculates the bus load ratio based on the communication messages flowing through the network. A method for restricting the transmission of communication messages based on the load ratio during the measurement period is disclosed. [Prior art documents] [Patent Documents]
[0010] [Patent Document 1] International Publication No. 2013 / 136496 [Overview of the project] [Problems that the invention aims to solve]
[0011] The objective of this invention is to avoid transmitting inappropriate data. [Means for solving the problem]
[0012] According to a first aspect of the present invention, a communication control device is provided comprising a data transfer unit and a protocol engine. The communication control device further comprises a transfer protection unit configured to control the transfer of data from the data transfer unit to the protocol engine in accordance with a process identifier that identifies a process entity that requests the protocol engine to transmit data for that process entity. The transfer protection unit preferably controls the transfer of data according to the process identifier based on bandwidth, transmission management data, and / or payload content.
[0013] Therefore, the transfer protection unit can help prevent process entities from blocking transfer elements and transmitting inappropriate data.
[0014] A process identifier is either an operating system identifier (OSID) or a context ID.
[0015] The transfer protection unit may include an acceptance filter, a commit count limiter, and a data rate limiter.
[0016] The data transfer unit may be a DMA controller with multiple independent channels, and access to the channels may be configured to be based on process identifiers, including process identifiers.
[0017] The data transfer unit may include a buffer (or data transfer buffer) for storing data, and the buffer may be used in place of a DMA controller. An external CPU or DMA controller of the communication control device can store data in the buffer, and the protocol engine can retrieve data from the buffer.
[0018] The protocol engine may be a CAN protocol engine. The protocol engine may comply with the CAN2.0 specification, CAN Flexible Data Rate, CAN-FD specification, or CAN-XL specification.
[0019] The protocol engine may also be an Ethernet protocol engine.
[0020] The transfer protection unit may be configured to control the flow of data based on credits, the number or rate of past requests, or available resources.
[0021] The forwarding protection unit may include filters to inspect the data content (such as management data and / or payload data) to determine whether the data content is valid (or appropriate). The filters may be configured to allow the data to pass to the protocol engine when they determine the data is valid. The filters may be configured to block and / or discard the data when they determine the data is invalid.
[0022] The transfer protection unit may include a first limiter for determining whether a process entity is committing data to one or more transfer elements at a commit rate (i.e., the rate at which transfer elements are committed) that exceeds a threshold. A single commit may send one or more frames to a transfer element. The first limiter may be configured to block and / or discard the data, or to limit the commit rate, if it determines that the commit rate exceeds a threshold commit time rate.
[0023] The transfer protection unit may include a second limiter for determining whether a process entity is committing data at a bandwidth (i.e., data rate) exceeding a threshold bandwidth. The second limiter may be configured to block and / or discard the data, or to limit the bandwidth through which the data passes to the protocol engine, if it is determined that the bandwidth exceeds the threshold bandwidth.
[0024] In response to determining that data transfer to the protocol engine should be restricted, the transfer protection unit issues a first command to discard data to the data transfer unit and / or a second command to discard downlink data. For example, it may be operable to send a signal to a transfer element or a temporary buffer between a circuit and a transfer element.
[0025] The transfer protection unit may be operable to signal backpressure to the data transfer unit.
[0026] The communication control device may further include at least one transfer element for storing data between the transfer protection unit and the protocol engine. The at least one transfer element may be inserted into the data transmission path between the transfer protection unit and the protocol engine. The communication control device may further include a buffer between the transfer protection unit and the at least one transfer element.
[0027] According to a second aspect of the present invention, there is provided a semiconductor device including the processor and the communication control device of the first aspect. The processor is operable to execute a process (process entity) that requires the communication control device to transmit data.
[0028] The semiconductor device may further include an on-chip interconnect for enabling the processor to access the memory, and / or a communication control device and a memory protection circuit for controlling access to the on-chip interconnect. The memory protection circuit may take the form of a memory management unit, such as a CPU MMU, and / or an IOMMU such as an IPMMU.
[0029] The semiconductor device may further include a memory for storing data for transfer.
[0030] The semiconductor device may be a microcontroller or a SoC (System on Chip).
[0031] According to a third aspect of the present invention, an automobile is provided comprising a bus and at least two nodes configured to communicate via the bus, wherein at least one of the at least two nodes comprises a semiconductor device according to the second aspect.
[0032] The vehicle may be a motorcycle, minibus, bus, truck, or lorry. The vehicle may be powered by an internal combustion engine and / or one or more electric motors.
[0033] A fourth aspect of the present invention provides a hardware implementation method that includes controlling the transfer of data from a data transfer unit to a protocol engine in accordance with a process identifier that identifies a process entity that requests the protocol engine to transmit data for that process entity. The transfer of data is controlled according to the process identifier, preferably based on bandwidth, transfer management data, and / or payload content.
[0034] In the following, the present invention will be further described with respect to embodiments shown in the accompanying figures. [Brief explanation of the drawing]
[0035] [Figure 1] This is a schematic block diagram of a semiconductor device including a communication control device comprising a data transfer unit, a transfer protection unit, and a protocol engine. [Figure 2] This is a schematic diagram illustrating the flow of transfer protection. [Figure 3] This is a schematic block diagram of the transfer protection unit. [Figure 4] This is a schematic diagram showing a transfer protection unit that can signal back pressure to the data transfer unit based on the pressure received from the transfer element and the limiter or filter. [Figure 5] This is a schematic block diagram of a data transfer unit having a data transfer channel. [Figure 6] This is a schematic diagram showing an example of a lookup table used in the data transfer section. [Figure 7] This is summary data showing the management data used to describe and / or transfer the payload data. [Figure 8] This is a schematic diagram showing a vehicle equipped with a network including nodes. [Modes for carrying out the invention]
[0036] Referring to Figure 1, a semiconductor device 1 in the form of a microcontroller is shown. The semiconductor device 1 can take the form of an SoC or other form of processor-based device. In this example, the semiconductor device 1 provides CAN controller functionality in node 102 (Figure 8), which is capable of operating according to CAN2.0, CAN-FD, and / or CAN-XL. However, other forms of communication protocols, such as Ethernet, can also be used.
[0037] The semiconductor device 1 includes at least one central processing unit (CPU) subsystem 2, which includes at least one CPU 3 and a CPU-side memory protection circuit 4, a system memory 5, and an I / O-side memory protection circuit 6 connected via an on-chip interconnect 7 such as an AXI interconnect. The CPU-side memory protection circuit 4 may take the form of a memory management unit (MMU). The I / O-side memory protection circuit 6 may take the form of an IOMMU such as an IPMMU. The system memory 5 may be provided off-chip, for example, by a separate memory semiconductor device.
[0038] The semiconductor device 1 includes a communication control device 8 for accessing bus 9. The PHY is not explicitly specified. In this case, the communication control device 8 is a CAN controller, and bus 9 is a CAN bus. The CPU 3 can access the system memory 5 and SFR 10 in the communication control device 8 via the CPU-side memory protection circuit 4 and the on-chip interconnect 7. The communication control device 8 can access the system memory 5 via the I / O-side memory protection circuit 6.
[0039] The communication control device 8 includes a controller subsystem 12 which includes a data transfer unit 11, an optional temporary buffer 13, a message handler 14, and a protocol engine 15. In this case, the message handler 14 includes a transfer element 16. The transfer element 16 is a hardware element for holding data for transmission. The data transfer unit 11 is used to transfer data 17 (e.g., one frame at a time) to the protocol engine 15. The data 17 may include transfer management data 18, such as header data 19 (Figure 7), and payload data 20. The data transfer unit 11 may take the form of a DMA controller that receives a request to transfer data 17 and transfers the data 17. However, the data transfer unit 11 may take the form of a buffer or other form of storage that receives data 17 (e.g., from a CPU, DMA controller, or another DMA controller) and stores the data 17 for retrieval by the protocol engine 15. Such a data transfer unit is called a "passive data transfer unit". This allows the CPU 3 to store frames in the data transfer unit 11 (instead of the system memory 5) and set a flag in the SFR 10 to trigger the transfer of frames from the data transfer unit 11. The CPU-side memory protection circuit 4 ensures that the process 21 running on the CPU 3 can only access the allocated DMA channel 45 (Figure 5).
[0040] The communication control device 8 includes a transfer protection unit 22 between the data transfer unit 11 and the protocol engine 15. The transfer protection unit 22 is implemented in hardware. As will be described in more detail below, the transfer protection unit 22 controls the transfer of data 17 from the data transfer unit 11 to the protocol engine 15 in accordance with a process identifier 23, which can take the form of, for example, an operating system identifier (OSID) or a context ID.
[0041] The same process identifier 23 can be sent from the data transfer unit 11 to the transfer protection unit 22 and the I / O-side memory protection circuit 6. However, the format and size of the identifier may differ. For example, since the transfer protection unit 22 can use 16 tables, the communication control device 8 can use a 4-bit identifier. However, the I / O-side memory protection circuit 6 can only have 4 tables and therefore requires only 2 bits. Nevertheless, it is possible to use finer granularity within the communication control device 8, for example, by using only 4 levels for the operating system (providing the highest level of protection) and 4 sublevels for processes within the operating system for the transfer protection unit 22 (providing a lower level of protection).
[0042] Referring to Figure 2, the process identifier 23 identifies a process entity 24 that requests the protocol engine 15 to transmit data 17. The process entity 24 causes the data 17 to be transferred from system memory 5 to the protocol engine 15 via the data transfer unit 11, which can directly or indirectly play an active role (in the case of a DMA controller) or a passive role (in the case of a buffer). For example, the process entity may send a transmit request 26 to the data transfer unit 11 and send a signal 25 that sets a flag in the SFR 10, for example, to trigger the data transfer unit 11 to retrieve the data 17 and pass it to the protocol engine 15. The transfer protection unit 22 uses the process identifier 23 to control the transfer of the data 17 based on the payload content, bandwidth, and / or transfer management data 18. The transfer management data 18 is data used to transfer (or in connection with) the payload data 20. For example, the transfer management data 18 may include header data 19 (Figure 7). However, the transfer management data 18 does not have to be data intended to be carried in the header. For example, the forwarding management data 18 may include instructions to the protocol engine 15, such as instructions to create a timestamp, or other logical blocks in the data path that perform actions such as MACsec or IP checksum calculation.
[0043] The process identifier 23 is an identifier provided in parallel with the address / data information and can be used by CPU3 to access the peripheral. The peripheral uses the process identifier 23 to grant permission for the requested operation and to identify the source.
[0044] Referring further to Figures 1 and 2, the data 17, including the transfer payload data 20, is typically stored in a chain 27 in system memory 5, transferred to and stored in the transfer element 16. The transfer element 16 takes the form of storage between the transfer protection unit 22 and the protocol engine 15. As previously described, the transfer element 16 is a hardware element that holds data for transmission. The transfer element 16 can store data directly as an object to be transmitted, or indirectly as a pointer to an object in memory. The transfer element 16 can take the form of a first-in, first-out (FIFO) buffer, a one-entry FIFO buffer, or a transmission queue. The transfer element 16 or logic associated with the transfer element 16 (not shown) can signal back pressure 28 or other status-related information (e.g., resource available, resource full, no credit) to the transfer protection unit 22.
[0045] The transfer protection unit 22 can signal back pressure (BP) 29 and discard (DC) 30 to the data transfer unit 11. The back pressure (BP) 29 is used to notify the data transfer unit 11 in the form of a DMA controller not to initiate data fetching for a particular process identifier 23. When used, there are N back pressure (BP) 29 and N discard (DC) 30, one for each identifier, where N is a positive non-zero integer.
[0046] The communication control device 8 is configured via the SFR 10. In particular, the SFR 10 constitutes the data transfer unit 11 by providing information 31 for the lookup table 32 (Figure 5) and can be used to generate a transmission request 26 (Figure 5). Access to the SFR 10 can be protected by the process identifier 23, for example, by restricting access to the memory area within the SFR 10 by the CPU-side memory protection circuit 4.
[0047] The communication control device 8 can process the data 17 in different ways.
[0048] The data transfer unit 11 can fetch the complete frame of data 17 and store the data 17 in a temporary buffer 13, for example, to enable filtering of the frame's contents. The protocol engine 15 retrieves the frame from the temporary buffer 13 after the frame transfer is complete. Thus, the temporary buffer 13 can have a size corresponding to the size of the frame. This method can be used in Ethernet communication. The transfer protection unit 22 analyzes the data on the fly during fetching. If the data transfer unit 11 can handle only one channel at a time, one temporary buffer 13 is sufficient. The temporary buffer 13 can be implemented as a double-sided shadow buffer, with one side filled by the data transfer unit 11 and the other side (previously filled) transferred to the protocol engine 15.
[0049] Alternatively, the data transfer unit 11 may retrieve the data and store it in the temporary buffer 13. However, in this case, the protocol engine 15 may begin retrieving data from the temporary buffer 13 after receiving the first part of the frame (i.e., before the entire frame is transferred). This approach can also be used for Ethernet communication, such as jumbo frame transfer. The transfer protection unit 22 analyzes the data on the fly during fetching. If the temporary buffer 13 is used, the transfer protection unit 22 may signal the discard 33 to notify the temporary buffer 13 that the frame should not be used for transfer, even if the transfer element 16 has started retrieving data from the temporary buffer 13.
[0050] In another case, for example in the case of CAN, information from many frames may be required for proper bus arbitration (Tx-scan). In this case, some header portions are pre-fetched, and the transmission protection unit 22 analyzes the pre-fetched information. In this case, the main portion of the frame is acquired on the fly while it is being transmitted from the system memory 5. In this case, the communication control device 8 may include logic (not shown) to trigger the fetching of data from the data transfer unit 11.
[0051] The transfer protection unit 22 provides a communication interface, i.e., a mechanism for the communication control device 8, to enable different process entities 24 to participate in network communication without interfering with communication from other process entities 24 within the same node 102 (Figure 8) or communication from other nodes within the same network 101 (Figure 8).
[0052] The process entity 24 may be part of software or process 21 executed by the CPU 3, such as an operating system, a virtual machine or function call, or a part of hardware such as a DMA controller. The transfer protection unit 22 manages resources within the semiconductor device (communication IP) and network access by enhancing system-level protection of memory access (provided, for example, by IPMMU, content guard, and other forms of memory protection).
[0053] The transfer protection unit 22 enhances the communication control device 8 by providing a rate / event limiter (or meter) for a single transfer resource, a rate / event limiter (or meter) for multiple transfer resources such as each process, CPU, OS, etc., and / or content restrictions for each process, CPU, OS, etc. In relation to content restrictions, messages can be classified by (deep) package checking (e.g., by looking at the CAN-ID) and / or granted access based on a filter table, and their access can be restricted or monitored by process-specific meters (e.g., messages with CAN-IDs in the range of 80 to 100 are allowed, but only 1% of the bus load is permitted).
[0054] Furthermore, restricting use and / or content can help improve the effectiveness of using communication control devices (e.g., CAN controllers) equipped with data transfer units (e.g., DMACs), and can help avoid bus blocking by irregular nodes or processes within nodes. While other forms of networks, such as Ethernet, are more tolerant, forward protection can help improve safety and security. It also reduces the effort and CPU load of the software used for sanity checks. Additionally, it can provide a degree of freedom for interference between independent processes, which is important for functional safety.
[0055] Referring to Figure 3, one or more forms of transfer protection can be used, which utilize the process identifier 23 and the transfer management data 18 contained in the data 17.
[0056] A first form of forwarding protection, in the case of CAN, can prevent a process entity 24 from committing data 17 with unexpected attributes, such as Ethernet-related attributes like frame ID, source MAC address, VLAN, or other forwarding management data 18. Knowing the transmission attributes, an acceptance filter 41 based on the process identifier 23 is used in front of the protocol engine 15. The acceptance filter 41 may have multiple tables 42 (e.g., whitelists and / or blacklists) selected based on the process identifier 23. In addition to, or instead of, ingress metering to forwarding elements 16 can be used for streams from processes.
[0057] The reception filter 41 can be used to cover situations where a process entity 24 or system is compromised and attempts to send something on behalf of another (unauthorized) process entity 24. This approach can also be used to provide an additional level of protection for unshared transfer elements 16.
[0058] A second form of forwarding protection can prevent the process entity 24 from committing an excessive number of forwarding elements 16. Knowing the bandwidth requirements of the process, a commit count limiter 44 based on the process identifier 23 is used in front of the protocol engine 15. The commit count limiter 44 can be based on time-based credits, pending transmit requests, and / or free resources. Parameters such as credit-based shaper parameters are provided via the SFR 10 (Figure 1).
[0059] The commit count limiter 44 can be used to cover situations where a process entity 24 commits too many forwarding elements 16 within a defined time, causing too many messages to be introduced into the send queue (i.e., forwarding elements) which negatively impacts the latency of other process entities 24.
[0060] A third form of transmission protection can prevent process entity 24 from committing transmission elements 16 for an extended period, i.e., from committing too much data so that transmission elements 16 are occupied for an extended period to exclude other process entities. Again, knowing the bandwidth requirements of the process, a data rate limiter 43 based on process identifier 23 is used in front of the protocol engine 15. The data rate limiter 43 may be based on time-based credits, pending transmission requests, and / or free resources signaled via back pressure 28 or other status indicator signals.
[0061] The data rate limiter 43 can be used to cover situations where the process entity 24 commits an excessive payload within a defined period, causing unexpected delays or causing the transfer element 16 to run out of memory.
[0062] The transfer protection unit 22 does not need to include all forms of protection. Furthermore, the reception filter 41, commit count limiter 44, and data rate limiter 43 can be executed in different orders. In this case, the reception filter 41 performs filtering first, and then the commit count limiter 44 and / or data rate limiter 43 perform limit-based protection. In some cases, different forms of protection can be performed simultaneously.
[0063] The operation of the data transfer unit 11 in the form of a DMA controller will be described in more detail with reference to Figures 5 and 6.
[0064] SFR10 issues a transmit request 26 on behalf of process entity 24 for payload data 20 to be transmitted by protocol engine 15.
[0065] The forwarding element 16 takes the form of a FIFO shared by the DMA channel 45. In some cases, the forwarding element 16 can define eight priority queues for different traffic classes, for example, using PCP (Priority Code Point) in Ethernet. When a transmit request 26 is made to send one or more frames or to empty the chain 27, the data transfer unit 11 loads the data 17 into the DMA channel 45. The DMA channel 45 is a control structure for forwarding data. The DMA channel 45 can be selected based on priority level, based on the availability of the forwarding element 16, or using selection mechanisms such as strict round robin or weighted round robin. The number of DMA channels 45 is greater than the number of forwarding elements 16 (for example, there may be only 16 to 256 DMA channels and eight FIFOs), so the forwarding element 16 may have data 17 written to it from multiple different DMA channels 45. Furthermore, different process entities 24 can share two or more forwarding elements 16.
[0066] The data transfer unit 11 retrieves the data 17 from the chain 27 in the system memory 5, passes the data 17 using the identifier-based lookup table 32 to select the transfer element 16, i.e., the FIFO. The data transfer unit 11 then outputs the data 17, along with the process identifier 23, to the transfer protection unit 22, which performs process entity-specific shaping based on the process identifier 23.
[0067] If process entity 24 requests to send too much data 17, or requests to send it too frequently, or if the data 17 is incorrectly formatted, the transfer protection unit 22 will restrict forward transmission to the shared resource 15 (i.e., the protocol engine) or discard the data 17.
[0068] The transfer protection unit 22 can be located within the data transfer unit 11, between the data transfer unit 11 and the protocol engine 15, or on the data transfer unit 11. The transfer protection unit 22 can check the contents of the data before it is added to the transfer element 16, and can check the payload size and / or rate when the payload is removed from the transfer element 16 for forward transfer to the protocol engine 15, or vice versa.
[0069] Next, we will show two examples using different communication protocols.
[0070] The first example is an Ethernet interface (i.e., the communication controller 8 is an Ethernet port) in which eight priority queues are defined corresponding to eight PCPs within a VLAN tag (not shown). A forwarding traffic shaper (such as a time-aware shaper or credit-based shaper within the Ethernet interface) is connected to these queues, and at the Ethernet endpoint, the queues are typically addressed directly by software (e.g., by different DMA channels) using descriptor chains.
[0071] Without forwarding protection, some software can only use its assigned DMA chain and, therefore, its assigned shaper. When software writes a frame with PCP=7 (high priority) to a DMA chain connected to PCP=2 (low priority), local shaping (i.e., at the sending endpoint) is still satisfactorily achieved according to PCP=2 (low priority). However, on the network side, the frame uses the PCP=7 (high priority) queue, thus interfering with genuine high-priority traffic.
[0072] When forwarding protection is used at the endpoint, the DMA chain can only initiate PCP=2 traffic, and forwarding protection extends across the entire network.
[0073] Traditional protections achieve a fixed relationship between software processes and hardware resources, but they do not check what the software is doing to the hardware resources. One solution is for the software to perform additional checks for unintended behavior, such as simply using the wrong PCP in a given example, or (in the case of virtualization) sending data to the wrong destination MAC. However, this solution is slow.
[0074] The second example is a CAN controller.
[0075] Bus access via CAN is controlled by the CAN-ID. Based on the CAN-ID, the transfer of data between different processes within a single microcontroller and the transfer of data between all MCUs (Micro Controller Units) connected to the CAN bus are coordinated.
[0076] If a process configures an incorrect CAN-ID, it can affect not only communication by the local MCU (i.e., the MCU on which the process is running) but also the entire CAN bus.
[0077] Furthermore, CAN does not provide standardized mechanisms for stream filtering and policing to deal with unplanned traffic on the network. Therefore, there is no mechanism to protect CAN bus frames from malicious frames created by software, etc.
[0078] The transfer protection circuits described herein can be used to provide protection through the contents of a transfer buffer (or FIFO) and / or through the use of a transfer buffer (or FIFO).
[0079] For example, with respect to content, the transfer protection unit 22 can check that the CAN-ID is valid for the resource, that the frame size is appropriate for the resource (e.g., the payload is between 0 and 120 bytes), and / or that the protocol is appropriate for the resource (i.e., CAN 2.0, CAN-FD, or CAN-XL). For example, if two process entities 24 share the same transfer element 16, the first process entity 24 can add identifiers in the range of 1 to 120, and the second process entity 24 can add identifiers in the range of 100 to 1000 (i.e., a wider range). Thus, the resource can be used for identifiers 100 to 1000. However, the second process cannot use it in the range of 0 to 99. With respect to usage, the transfer protection unit 22 can check the event rate (e.g., a threshold of 1000 frames / second) and the data rate (e.g., 100kbps or less).
[0080] As described above, the transfer protection unit 22 can control the transfer of data 17 based on the transfer management data 18 used to describe the payload data 20 and / or to transfer the payload data 20.
[0081] Referring to Figure 7, the transport management data 18 can include data 18L7-5, 18L4, 18L3, and 18L2 generated by the respective protocol engines below the application or stack 48. The payload data 20 generally remains unchanged from one OSI layer to the next. In some situations, the payload data may change from one OSI layer to another, for example when the protocol engine includes MACsec. At OSI layer 1, the transport management data 18 is header data 19 that can be encapsulated in the header 48, with a trailer 49 added. Required fields can be specified in the transport management data 18.
[0082] For example, in the context of a Layer 2 Ethernet frame, examples of management data include source information in the form of a MAC source address, destination information in the form of a MAC destination address, data content type in the form of an Ethernet type, priority in the form of a PCP, and virtual network information in the form of a VLANID.
[0083] In the context of CAN, particularly CAN-XL, examples of management data include payload size information in the form of a Data Length Code (DLC), destination information in the form of a Frame ID, data content type in the form of a Payload Type and / or Secure Content Indicator, and virtual network information in the form of a VCAN-ID.
[0084] Referring to Figure 8, a vehicle 100 is shown to be equipped with a communication network 101 including nodes 102, 102-1, and 102-2 connected to a bus 9. At least the first connection point 102-1 includes a semiconductor device 1 as described above, protected by a transfer protection unit 22. One or more of nodes 102, 102-1, and 102-2 may include a semiconductor device 107 equipped with a communication control device 108 that does not have transfer protection. For simplicity, only two nodes are shown.
[0085] It will be understood that various modifications can be made to the embodiments described above. Such modifications may include equivalent and other features that are already known in the design, manufacture, and use of semiconductor devices and communication control devices and their components, and which may be used in place of or in addition to the features already described herein. Features of one embodiment may be replaced or supplemented by features of another embodiment.
[0086] Forward protection can be used not only in multi-CPU and hypervisor systems, but also in single-CPU, non-virtualized systems. For example, it can be useful to limit the amount of traffic a node can generate on a communication interface. In CAN, for instance, a failure could cause a node to consume all available bandwidth, thereby halting all other communications. Forward protection in the form of a data rate limiter on the forwarding entry side can help improve the situation. In another example, ensuring that only expected forwarding elements are committed can also benefit reserved resources.
[0087] The transfer protection circuit can also perform DMA channel-specific operations. For example, it can limit the operating system bandwidth to 5 Mbps and further limit the channel bandwidth to 1 Mbps.
[0088] The transfer protection circuit can check the content when the data transfer unit 11 fetches a frame for the transfer element. For example, the transfer protection circuit can perform a content check when the data transfer unit 11 fetches a frame, but the protocol engine side of the transfer buffer checks the rate.
[0089] The shared resource does not need to be the protocol engine; it may be a separate unit. The forwarding element can be located within the forwarding protection unit. The message handler and protocol engine can be integrated into a single unit.
[0090] While the claims are formulated in this application to specific combinations of features, the scope of the disclosure of the present invention should be understood to include any novel features or any novel combination of features disclosed herein, either explicitly, implicitly, or as a generalization thereof, whether relating to the same invention as currently claimed in any claim and whether mitigating any or all of the same technical problems as the present invention. The applicant hereby notifies that, in the course of proceedings of this application or any further application derived therefrom, new claims may be formulated for such features and / or combinations of such features. [Explanation of symbols]
[0091] 1,107 Semiconductor Equipment 2 subsystems 3 CPU 4. Memory protection circuit 5 System Memory 6. Memory protection circuit 7. On-chip interconnects 8, 108 Communication control device 9 buses 10 SFR 11. Data Transfer Section 12 Controller Subsystem 13 Temporary buffer 14 Message handlers 15 Protocol Engine 16 Transfer elements 17 Data 18 Transfer Management Data 19 Header data 20 Payload Data 21 Processes 22 Transfer protection section 23 (Process) Identifier 24 Process Entities 25 signal 26. Request to send 27 Transfer Chain 28, 29 Back pressure (BP) 30, 33 Discard (DC) 31 Information 32 Look-up Tables 39 Header 40 Trailer 41 Reception Filter 42 tables 43. Data Rate Limiter 44 Commit Count Limiter 45 DMA channels (CH) 48 stacks 101 Network 102 nodes
Claims
1. Data transfer unit, Protocol engine and A communication control device comprising a transfer protection unit, The transfer protection unit controls the transfer of data from the data transfer unit to the protocol engine, depending on a process identifier located within the communication control device that identifies a process entity that the protocol engine requires to transmit data. The data transfer unit is a DMA controller having multiple channels, and the DMA controller is configured such that access to the multiple channels is based on the process identifier. Communication control device.
2. The communication control device according to claim 1, wherein the transfer protection unit controls the transfer of the data based on bandwidth, transmission management data, and / or payload data.
3. The communication control device according to claim 1, wherein the process identifier is an operating system identifier or a context ID.
4. The communication control device according to claim 1, wherein the data transfer unit includes a buffer for storing the data.
5. The communication control device according to claim 1, wherein the protocol engine is a CAN protocol engine or an Ethernet protocol engine.
6. A data transfer unit, Protocol engine and A communication control device comprising a transfer protection unit, The transfer protection unit controls the transfer of data from the data transfer unit to the protocol engine, depending on a process identifier located within the communication control device that identifies a process entity that the protocol engine requires to transmit data. The transfer protection unit is configured to control the flow of data based on credits, the number or rate of past requests, or available transmission resources. Communication control device.
7. A data transfer unit, Protocol engine and A communication control device comprising a transfer protection unit, The transfer protection unit controls the transfer of data from the data transfer unit to the protocol engine, depending on a process identifier located within the communication control device that identifies a process entity that the protocol engine requires to transmit data. The transfer protection unit is operable to signal a command to discard data to the data transfer unit when it is determined that data transfer to the protocol engine should be restricted. Communication control device.
8. A data transfer unit, Protocol engine and A communication control device comprising a transfer protection unit, The transfer protection unit controls the transfer of data from the data transfer unit to the protocol engine, depending on a process identifier located within the communication control device that identifies a process entity that the protocol engine requires to transmit data. The transfer protection unit is operable to send a back pressure signal to the data transfer unit requesting a temporary suspension of data transmission or a reduction in bandwidth. Communication control device.
9. The communication control device according to claim 1, wherein the transfer protection unit comprises at least one transmission element for storing the data with the protocol engine.
10. Processor and The communication control device is as described in claim 1, The processor is a semiconductor device that performs a process that requires the communication control device to transmit the data.
11. The semiconductor device according to claim 10, wherein the processor further comprises an on-chip interconnect for enabling access to memory and / or the communication control device, and a memory protection circuit for controlling access to the on-chip interconnect.
12. The semiconductor device according to claim 10, wherein the semiconductor device is a microcontroller or a system on a chip (SoC).
13. bus and, At least two nodes that communicate via the bus, A vehicle comprising a semiconductor device according to claim 10 as one of the at least two nodes.
14. A communication control method using a communication control device comprising a data transfer unit, a protocol engine, and a transfer protection unit, The data transfer unit is a DMA controller equipped with multiple channels, The transfer protection unit controls the transfer of data from the data transfer unit to the protocol engine, depending on a process identifier located within the communication control device that identifies a process entity for which the protocol engine requires data to be transferred. The DMA controller accesses the multiple channels based on the process identifier. Communication control method.