A communication system and method between in-vehicle heterogeneous SoCs based on PCIe non-transparent bridge

Abstract

The application discloses a kind of communication systems and methods between vehicle-mounted heterogeneous SoC based on PCIe non-transparent bridge, including vehicle-mounted first SoC and vehicle-mounted second SoC connected physically by PCIe interface, wherein vehicle-mounted first SoC is configured as RC end NTB equipment driver, responsible for discovery, mapping and using the memory window and doorbell interrupt presented by EP side vNTB EPF function driver virtualization;Vehicle-mounted second SoC is configured as EP end vNTB EPF function driver based on EPF framework, responsible for virtualization and presentation of its local memory window and doorbell interrupt mechanism, for RC end access. Through shared memory window and doorbell interrupt mechanism, efficient, low-delay bidirectional data transmission is realized between vehicle-mounted heterogeneous processors. The application constructs the infrastructure of vehicle-mounted gigabit-level communication, solves the data throughput and real-time bottleneck in vehicle-mounted ADAS, automatic driving and other applications, and is suitable for vehicle-mounted multi-domain fusion architecture.

Description

Technical Field

[0001] This invention relates to communication technology between in-vehicle multi-domain controllers, and more particularly to a communication system and method for in-vehicle heterogeneous SoCs based on a PCIe non-transparent bridge. Background Technology

[0002] With the rapid development of technologies such as in-vehicle intelligent driving, advanced driver assistance systems (ADAS), and smart cockpits, in-vehicle electronic systems are evolving towards a multi-domain convergence architecture. This architecture typically includes multiple System-on-Chips (SoCs) with different functions and architectures, such as high-performance intelligent driving chips and general-purpose computing chips. These heterogeneous SoCs need to exchange massive amounts of data in real time with high bandwidth, such as high-resolution in-vehicle video streams, LiDAR point cloud data, radar data, sensor fusion results, and various control commands.

[0003] However, commonly used communication buses in the automotive field (such as CAN, FlexRay, 100BASE-T1 Ethernet, and 1000BASE-T1 Ethernet) are gradually failing to meet the requirements of automotive multi-domain converged architectures in terms of bandwidth, latency, and real-time performance. Traditionally, high-speed interconnection between heterogeneous chips may use dedicated interfaces or bridging via FPGAs, but these solutions either lack versatility or increase system complexity and cost. PCIe, as a high-speed serial bus, is widely used in the server and desktop fields for heterogeneous device interconnection. Its non-transparent bridge (NTB) characteristic enables memory sharing and interrupt notification between multiple hosts, theoretically making it very suitable for solving the communication challenges of heterogeneous SoCs in automotive applications. However, in the automotive environment, applying NTB technology to communication between general-purpose heterogeneous SoCs (non-FPGAs), especially virtualizing NTB functions on the EP side through vNTB EPF function drivers and integrating it stably and efficiently into the automotive operating system (such as Linux), still faces many challenges. Moreover, there is currently no mature solution in the automotive industry for directly implementing PCIe bridging between general-purpose SoCs through this virtual NTB method.

[0004] Therefore, there is an urgent need for a system and method that can effectively utilize the advantages of PCIe non-transparent bridges in automotive environments and achieve high-bandwidth, low-latency, and high-reliability communication between general heterogeneous SoCs through the virtual NTB (vNTB) mechanism. Summary of the Invention

[0005] To address the shortcomings of existing technologies, the present invention aims to provide a communication system and method for heterogeneous SoCs in vehicles based on a PCIe non-transparent bridge, thereby solving the deficiencies of existing vehicle communication solutions in terms of bandwidth, latency, and heterogeneous SoC compatibility, and providing a high-performance underlying communication foundation for vehicle multi-domain fusion architecture.

[0006] To achieve the objectives of this invention, the technical solution adopted is as follows:

[0007] A communication system between heterogeneous automotive SoCs based on a PCIe non-transparent bridge includes:

[0008] The first SoC in the vehicle is configured in RC mode and loads the NTB device driver;

[0009] The second SoC in the vehicle is configured in EP mode and implements the vNTB EPF function driver based on the EPF framework;

[0010] The first on-board SoC and the second on-board SoC are interconnected via a PCIe physical interface;

[0011] The vNTB EPF function driver is virtually configured and provides a shared memory window and doorbell interrupt register on the second SoC side of the vehicle;

[0012] The NTB device driver discovers, maps, and utilizes the shared memory window and doorbell interrupt register virtually provided by the vehicle-mounted second SoC through the vNTB EPF function driver on the vehicle-mounted first SoC side.

[0013] Furthermore, the NTB device driver is responsible for configuring the PCIe controller to support non-transparent bridge mode; discovering and mapping the memory window virtually exposed by the vehicle second SoC through the vNTB EPF driver; discovering and utilizing the doorbell interrupt virtually provided by the vehicle second SoC through the vNTB EPF driver; and writing to the doorbell register on the EP side when the vehicle first SoC needs to send a notification to the vehicle second SoC.

[0014] Furthermore, the vNTB EPF function driver is responsible for managing the local memory of the second in-vehicle SoC and virtualizing a portion of it as a shared memory window, making it accessible to the first in-vehicle SoC.

[0015] Furthermore, the vNTB EPF function driver is responsible for virtually configuring and providing a doorbell interrupt register on the second onboard SoC, which the first onboard SoC can write to trigger an interrupt, and responding to and handling the doorbell interrupt.

[0016] A communication method between heterogeneous automotive SoCs based on a PCIe non-transparent bridge includes the following steps:

[0017] (1) Load the NTB device driver on the first SoC in the vehicle and configure it as a PCIe RC terminal;

[0018] (2) Implement and load the vNTB EPF function driver on the second SoC of the vehicle based on the EPF framework, and configure it as a PCIe EP terminal;

[0019] (3) Establish a hardware connection between the vehicle-mounted first SoC and the vehicle-mounted second SoC through the PCIe physical interface;

[0020] (4) The vNTB EPF function driver virtually configures and exposes the shared memory region and doorbell interrupt register on the second SoC of the vehicle to simulate the NTB function;

[0021] (5) The NTB device driver discovers, maps and utilizes the shared memory region and doorbell interrupt mechanism virtually provided by the vehicle-mounted second SoC through the vNTB EPF function driver on the vehicle-mounted first SoC;

[0022] (6) Through the discovered and utilized shared memory region and doorbell interrupt mechanism, bidirectional data transmission between the vehicle-mounted first SoC and the vehicle-mounted second SoC is realized.

[0023] Furthermore, the bidirectional data transmission includes in-vehicle video streams, sensor data, and control commands.

[0024] Furthermore, the specific steps involved in the NTB device driver discovering and utilizing vNTB virtual resources at the RC end include:

[0025] (1) PCIe bus enumeration and EP device discovery, reading device information through the PCIe configuration cycle;

[0026] (2) Read the configuration space BARs of the EP device and identify the memory address range of the virtual configuration of the vNTB EPF driver;

[0027] (3) Map EP BARs to the address space of RC, and RC CPU directly accesses the shared memory area provided by the vNTB EPF driver.

[0028] (4) Identify and register the vNTB virtual doorbell interrupt register address, and write to the vNTB virtual doorbell register on the EP side to trigger a notification;

[0029] (5) Perform read and write operations on the mapped vNTB virtual shared memory to realize data exchange between the RC end and the EP end;

[0030] (6) Write a value to the vNTB virtual doorbell register to notify the EP end that new data or events have occurred.

[0031] Furthermore, the vNTB EPF function drives the process of virtually configuring and providing NTB resources on the EP side, and its specific implementation steps are as follows:

[0032] (1) EPF framework initialization and vNTB function registration: enable EPF in the Linux kernel and create vNTB virtual devices;

[0033] (2) Local memory allocation and virtual shared memory settings, from the EP local memory allocation buffer, as a shared memory window accessible to the RC;

[0034] (3) Configure PCIe BARs to expose virtual resources, write the address / size of the virtual shared memory to the BAR register of the EP, and present it to the RC;

[0035] (4) Virtual doorbell interrupt register implementation: simulate doorbell function through software logic or register, and listen for RC writes;

[0036] (5) Listen for and respond to RC writes to the virtual doorbell register, capture RC write events, and convert them into software interrupts or callback functions for processing;

[0037] (6) Handle RC's read and write requests to virtual shared memory, manage RC's direct access to local memory, and ensure data consistency and protection;

[0038] (7) Send an interrupt request to the RC through the PCIe interrupt mechanism to realize the active event notification from the EP end to the RC end.

[0039] The beneficial effect of this invention lies in its innovative application to high-speed interconnection between general-purpose heterogeneous SoCs in automotive applications. Compared to existing technologies, this invention combines PCIe non-transparent bridge (NTB) technology with the virtual NTB (vNTB EPF) function under the EPF framework, pioneering its use. Unlike previous solutions that directly use NTB hardware in the PC server field or implement it through custom FPGAs, this invention utilizes the built-in PCIe controller of mainstream automotive processors (such as RK3588 and TDA4 mentioned in specific implementations). Specifically, the EP side (e.g., TDA4) virtually configures and exposes its internal memory as a memory window accessible to the RC side through its vNTB EPF driver, and virtually implements a doorbell interrupt register; the RC side (e.g., RK3588) discovers, maps, and utilizes these resources virtually provided by the EP side through its NTB device driver. This establishes a general-purpose, high-bandwidth, low-latency physical communication link between heterogeneous SoCs for the first time in the automotive field, effectively circumventing potential patent barriers associated with direct NTB hardware implementations in existing technologies.

[0040] This invention provides a solid underlying communication foundation for in-vehicle multi-domain fusion architecture. Through the shared memory window of NTB, two SoCs can directly access each other's designated memory areas, avoiding the complex copying process of traditional network protocol stacks and ensuring extremely low latency and high throughput at the hardware level. The doorbell interrupt mechanism provides an efficient event notification mechanism.

[0041] This invention supports transmission rates of 10 Gigabit Ethernet and above. This underlying physical link provides upper-layer automotive applications with data transmission capabilities exceeding 10 Gigabit Ethernet, far surpassing the limitations of traditional automotive gigabit Ethernet. This invention is highly adaptable to the automotive environment. The system design considers the resource constraints and real-time requirements of the automotive embedded environment. Through customized optimization of the Linux kernel driver, it ensures the stable operation of the NTB / vNTB mechanism on the automotive SoC.

[0042] This invention significantly reduces data transmission latency between heterogeneous SoCs in vehicles compared to traditional in-vehicle gigabit Ethernet communication, with transmission bandwidth reaching over 10 gigabits per second. This greatly improves data processing and transmission efficiency in scenarios with extremely high real-time requirements, such as in-vehicle ADAS and autonomous driving, laying the foundation for the collaborative work of future in-vehicle central computing platforms and domain controllers. Attached Figure Description

[0043] Figure 1 This is a schematic diagram of the overall architecture of the communication system between heterogeneous SoCs in vehicles based on a PCIe non-transparent bridge, as described in this invention.

[0044] Figure 2 This is a schematic diagram of the process by which the NTB device driver discovers and utilizes vNTB virtual resources at the RC end, as described in this invention.

[0045] Figure 3 This is a schematic diagram illustrating the process of virtual configuration and provision of NTB resources on the EP side by the vNTB EPF function driver described in this invention. Detailed Implementation

[0046] The technical solution of the present invention will be further described below with reference to the accompanying drawings and embodiments. The following embodiments are only used to more clearly illustrate the technical solution of the present invention, and should not be used to limit the scope of protection of this application.

[0047] like Figure 1 As shown, the communication system between heterogeneous SoCs in the vehicle based on a PCIe non-transparent bridge according to the present invention mainly includes a first vehicle SoC and a second vehicle SoC, which are physically connected through a high-speed PCIe bus.

[0048] The first automotive SoC, serving as the PCIe Root Complex (RC side), can be, for example, Rockchip RK3588; the second automotive SoC, serving as the PCIe Endpoint (EP side), can be, for example, Texas Instruments TDA4-VH.

[0049] The first in-vehicle SoC, RC side, sets up the in-vehicle application, in-vehicle transport layer, NTB device driver, and PCIe controller; the second in-vehicle SoC, EP side, sets up the in-vehicle application, in-vehicle transport layer, vNTB function driver, and PCIe controller.

[0050] The first SoC in the vehicle (RC side) is usually a SoC with stronger management capabilities, such as the RK3588, whose PCIe controller is configured in RC mode. The RC side is responsible for enumerating and configuring all devices on the PCIe bus, and discovering and mapping the memory address space virtually provided by the EP side.

[0051] The second onboard SoC (EP side) is typically selected as the SoC that needs to be controlled or exchange data with the RC side, such as the TDA4-VH, whose PCIe controller is configured in EP mode. The EP side is responsible for configuring and providing its own memory resources and interrupt mechanisms to the outside world through software virtualization of the NTB's functions.

[0052] The two are interconnected via physical PCIe slots or internal SoC-to-SoC PCIe buses (such as Chip-to-Chip PCIe).

[0053] like Figure 2 As shown, the NTB device driver for the first SoC (RC side) in the vehicle is implemented and loaded in the Linux kernel of the first SoC in the vehicle.

[0054] This driver is responsible for: configuring the PCIe controller to support non-transparent bridge mode; discovering and mapping memory windows virtually exposed by the vehicle's second SoC via the vNTB EPF driver. These memory windows are part of the vehicle's second SoC's local memory and are mapped into the address space of the vehicle's first SoC, thus enabling the vehicle's first SoC to directly access the memory of the vehicle's second SoC; and discovering and utilizing doorbell interrupts virtually provided by the vehicle's second SoC via the vNTB EPF driver. When the vehicle's first SoC needs to send a notification to the vehicle's second SoC, it writes to the doorbell register on the EP side.

[0055] The process by which NTB device drivers discover and utilize vNTB virtual resources at the RC end includes the following specific steps:

[0056] PCIe bus enumeration and EP device discovery, reading device information through the PCIe configuration cycle;

[0057] Read the configuration space BARs of the EP device and identify the memory address range of the vNTB EPF driver virtual configuration;

[0058] Map EP BARs to the RC address space, allowing the RC CPU to directly access the shared memory region provided by the vNTB EPF driver.

[0059] Identify and register the vNTB virtual doorbell interrupt register address, and prepare to write to the EP terminal vNTB virtual doorbell register to trigger a notification;

[0060] Perform read and write operations on the mapped vNTB virtual shared memory to realize data exchange between the RC and EP ends;

[0061] Write a value to the vNTB virtual doorbell register to notify the EP that new data or an event has occurred.

[0062] like Figure 3 As shown, the vNTB EPF function driver for the second SoC (EP side) is implemented and loaded within the Linux kernel of the second SoC based on the PCIe EPF (Endpoint Function) framework. The EPF framework allows the creation of multiple virtual PCIe functions on the EP device. The vNTB EPF function driver virtually implements the NTB functions and interfaces on the second SoC, enabling it to: virtually configure and expose a portion of the first SoC's local memory as a shared memory window for access. This "exposure" is not a direct NTB hardware mapping; rather, the vNTB EPF driver manages these memory regions at the software level and presents them to the RC in accordance with the NTB interface specification. It also virtually configures and exposes the doorbell interrupt register to the first SoC, allowing the first SoC to write to it to trigger an interrupt. Simultaneously, the vNTB EPF driver is also responsible for responding to and handling these virtual doorbell interrupts and may send its own interrupt requests to the RC via other PCIe interrupt mechanisms (such as MSI / MSI-X).

[0063] The process of virtually configuring and providing NTB resources on the EP side using the vNTB EPF function driver, and its specific implementation steps:

[0064] EPF framework initialization and vNTB function registration, enabling EPF in the Linux kernel, and creating vNTB virtual devices;

[0065] Local memory allocation and virtual shared memory settings, from EP local memory allocation buffer, as a shared memory window accessible to RC;

[0066] Configure PCIe BARs to expose virtual resources, write the address / size of virtual shared memory to the EP's BAR register, and present it to the RC;

[0067] The virtual doorbell interrupt register is implemented by simulating the doorbell function through software logic or a specific register, and monitoring RC writes.

[0068] Listen for and respond to RC writes to the virtual doorbell register, capture RC write events, and convert them into software interrupts or callback functions for processing;

[0069] Handle RC's read and write requests to virtual shared memory, manage RC's direct access to local memory, and ensure data consistency and protection;

[0070] By sending an interrupt request to the RC through the PCIe interrupt mechanism (MSI / MSI-X), the EP end can actively notify the RC end of events.

[0071] The communication mechanism for shared memory data transfer is as follows: Once a memory window is discovered and mapped by the RC (Regulator-Controller), the first onboard SoC can send data by writing to the shared memory region virtually provided by the second onboard SoC, while the second onboard SoC can directly read data from this memory region. Conversely, the second onboard SoC can also configure a shared region in its local memory for the first onboard SoC to access, enabling data transfer from the second onboard SoC to the first onboard SoC. This mechanism avoids data copying at the operating system kernel level, establishing the foundation for efficient zero-copy data transfer in the automotive field.

[0072] The communication mechanism for doorbell interrupt event notification is as follows: When the first onboard SoC writes data to the shared memory virtually provided by the second onboard SoC, or needs to notify the second onboard SoC to complete an operation, an interrupt can be triggered by writing to the doorbell interrupt register virtually provided by the second onboard SoC. The vNTB EPF driver of the second onboard SoC will capture the virtual interrupt and notify the upper-layer driver or application to handle it. Conversely, when the second onboard SoC needs to notify the first onboard SoC, it can send an interrupt request to the first onboard SoC through its own PCIe interrupt mechanism (such as MSI / MSI-X). This two-way notification mechanism ensures the real-time performance and coordination of onboard data transmission.

[0073] This invention provides an unprecedented high-speed PCIe NTB-level interconnect solution based on a general heterogeneous SoC for in-vehicle multi-domain fusion architecture through the above-described system and method, which has significant advantages in terms of bandwidth, latency and adaptability to specific in-vehicle scenarios.

[0074] The applicant of this invention has provided a detailed description of the embodiments of the invention in conjunction with the accompanying drawings. However, those skilled in the art should understand that the above embodiments are merely preferred embodiments of the invention. The detailed description is only intended to help readers better understand the spirit of the invention and is not intended to limit the scope of protection of the invention. On the contrary, any improvements or modifications made based on the inventive spirit of the invention should fall within the scope of protection of the invention.

Claims

1. A communication system between heterogeneous automotive SoCs based on a PCIe non-transparent bridge, characterized in that, include: The first SoC in the vehicle is configured in RC mode and loads the NTB device driver; The second SoC in the vehicle is configured in EP mode and implements the vNTB EPF function driver based on the EPF framework; The first on-board SoC and the second on-board SoC are interconnected via a PCIe physical interface; The vNTB EPF function driver is virtually configured and provides a shared memory window and doorbell interrupt register on the second SoC side of the vehicle; The NTB device driver discovers, maps, and utilizes the shared memory window and doorbell interrupt register virtually provided by the vehicle-mounted second SoC through the vNTB EPF function driver on the first SoC side. The vNTB EPF function driver is responsible for managing the local memory of the second in-vehicle SoC and virtualizing a portion of it as a shared memory window, making it accessible to the first in-vehicle SoC. The vNTB EPF function driver is responsible for virtually configuring and providing a doorbell interrupt register on the second onboard SoC, which the first onboard SoC can write to trigger an interrupt, and responding to and handling the doorbell interrupt.

2. The communication system between heterogeneous automotive SoCs based on a PCIe non-transparent bridge according to claim 1, characterized in that, The NTB device driver is responsible for configuring the PCIe controller to support non-transparent bridge mode; discovering and mapping the memory window virtually exposed by the vehicle second SoC through the vNTB EPF driver; discovering and utilizing the doorbell interrupt virtually provided by the vehicle second SoC through the vNTB EPF driver; and writing to the doorbell register on the EP side when the vehicle first SoC needs to send a notification to the vehicle second SoC.

3. A communication method between heterogeneous automotive SoCs based on a PCIe non-transparent bridge, characterized in that, Includes the following steps: (1) Load the NTB device driver on the first SoC in the vehicle and configure it as a PCIe RC terminal; (2) Implement and load the vNTB EPF function driver on the second SoC of the vehicle based on the EPF framework, and configure it as a PCIe EP terminal; (3) Establish a hardware connection between the vehicle-mounted first SoC and the vehicle-mounted second SoC through the PCIe physical interface; (4) The vNTB EPF function driver virtually configures and exposes the shared memory region and doorbell interrupt register on the second SoC of the vehicle to simulate the NTB function; (5) The NTB device driver discovers, maps and utilizes the shared memory region and doorbell interrupt mechanism virtually provided by the vehicle-mounted second SoC through the vNTB EPF function driver on the vehicle-mounted first SoC; (6) Through the discovered and utilized shared memory region and doorbell interrupt mechanism, bidirectional data transmission between the vehicle-mounted first SoC and the vehicle-mounted second SoC is realized; The process of virtually configuring and providing NTB resources on the EP side using the vNTB EPF function driver, and its specific implementation steps: EPF framework initialization and vNTB function registration, enabling EPF in the Linux kernel, and creating vNTB virtual devices; Local memory allocation and virtual shared memory settings, from EP local memory allocation buffer, as a shared memory window accessible to RC; Configure PCIe BARs to expose virtual resources, write the address / size of virtual shared memory to the EP's BAR register, and present it to the RC; The virtual doorbell interrupt register is implemented by simulating the doorbell function through software logic or registers, and listening for RC writes. Listen for and respond to RC writes to the virtual doorbell register, capture RC write events, and convert them into software interrupts or callback functions for processing; Handle RC's read and write requests to virtual shared memory, manage RC's direct access to local memory, and ensure data consistency and protection; By sending an interrupt request to the RC through the PCIe interrupt mechanism, the EP end can actively notify the RC end of events.

4. The communication method between heterogeneous automotive SoCs based on a PCIe non-transparent bridge according to claim 3, characterized in that, The bidirectional data transmission includes in-vehicle video streams, sensor data, and control commands.

5. The communication method between heterogeneous automotive SoCs based on a PCIe non-transparent bridge according to claim 3, characterized in that, The process by which NTB device drivers discover and utilize vNTB virtual resources at the RC end includes the following specific steps: (1) PCIe bus enumeration and EP device discovery, reading device information through the PCIe configuration cycle; (2) Read the configuration space BARs of the EP device and identify the memory address range of the virtual configuration of the vNTB EPF driver; (3) Map EP BARs to the address space of RC, and RC CPU directly accesses the shared memory area provided by the vNTB EPF driver. (4) Identify and register the vNTB virtual doorbell interrupt register address, and write to the vNTB virtual doorbell register on the EP side to trigger a notification; (5) Perform read and write operations on the mapped vNTB virtual shared memory to realize data exchange between the RC end and the EP end; (6) Write a value to the vNTB virtual doorbell register to notify the EP end that new data or events have occurred.

Images