ADCU data transmission method and device based on FPGA gateway and vehicle

Abstract

The application provides an ADCA data transmission method and device based on an FPGA gateway and a vehicle, and the method comprises the following steps: the FPGA gateway acquires a data stream output by an ADCA; a built-in hardware protocol analysis engine is used to analyze the data stream and generate a structured data object; a timestamp is assigned to the data object, and the data object is aligned to generate a spatiotemporal unified fusion data packet; a built-in programmable hardware preprocessing pipeline is used to perform preprocessing calculation on the fusion data packet, and output structured data that can be used for rendering; the structured data is written into a shared memory area, and the shared memory area is established by using a PCIe memory mapping technology between the FPGA gateway and a cockpit SOC; and position information of the structured data in the shared memory area is sent to the cockpit SOC. Through hardware parallel calculation and zero-copy transmission, the data processing delay is significantly reduced, and the real-time performance of data transmission between the ADCA and the cockpit SOC is ensured.

Description

Technical Field

[0001] This application relates to vehicle display technology, and more particularly to an ADCU data transmission method, apparatus, and vehicle based on an FPGA gateway. Background Technology

[0002] In the domain-centralized architecture of modern intelligent vehicles, the Advanced Driver Assistance Unit (ADCU) serves as the core perception and decision-making hub, undertaking the critical task of fusing multi-source sensor data (such as forward-facing cameras and millimeter-wave radar) and generating high-precision driving environment information (such as object lists, lane line parameters, and vehicle status). This data needs to be transmitted in real time to the cockpit domain controller to drive display devices such as the instrument panel, central control screen, and AR-HUD (Augmented Reality Head-Up Display), providing the driver with intuitive driving assistance information (such as collision warnings, lane departure warnings, and navigation route projection). For example, in high-speed driving scenarios, the ADCU needs to transmit real-time detected data such as the trajectory of vehicles ahead, lane line curvature, and traffic sign recognition results to the cockpit system with millisecond-level latency to ensure that the driver can respond to potential risks in a timely manner.

[0003] However, existing in-vehicle network communication technologies (such as CAN / CAN FD bus and SOME / IP protocol) have significant bottlenecks in terms of bandwidth, real-time performance, and data processing efficiency, making it difficult for cockpit display systems to present high-precision, low-latency perception information, thereby affecting driving safety and user experience.

[0004] Therefore, there is an urgent need for a high-efficiency, low-latency and highly compatible data transmission solution to meet the requirements of real-time interaction of large-scale perception data between the ADCU and the cockpit domain controller. Summary of the Invention

[0005] This application provides an ADCU data transmission method, apparatus, and vehicle based on an FPGA gateway to reduce the latency between the ADCU and the cockpit SOC.

[0006] In a first aspect, this application provides an ADCU data transmission method based on an FPGA gateway, applied to a Field Programmable Gate Array (FPGA) gateway, the method comprising:

[0007] Acquire the data stream output by the Advanced Driver Assist Control Unit (ADCU) in the vehicle network;

[0008] The data stream is parsed using a built-in hardware protocol parsing engine to generate structured data objects;

[0009] A timestamp is assigned to the data object, and the data object is aligned based on the timestamp to generate a spatiotemporally unified fused data packet;

[0010] The fused data packets are preprocessed and calculated using a built-in programmable hardware preprocessing pipeline to output structured data that can be used for rendering.

[0011] The structured data is written into a shared memory region, which is a contiguous physical memory region established by the FPGA gateway and the cockpit SOC through PCIe memory mapping technology.

[0012] The location information of the structured data in the shared memory region is sent to the cockpit SOC.

[0013] Furthermore, sending the location information of the structured data in the shared memory region to the cockpit SOC includes:

[0014] When the structured data is written to the shared memory region, a lightweight descriptor is generated and filled into the production descriptor ring; wherein, the lightweight descriptor includes the starting physical address of the structured data in the shared memory, the data length, and the data type identifier;

[0015] An MSI-X interrupt is sent to the cockpit SOC via the PCIe link, indicating that a new descriptor is available.

[0016] Furthermore, the fused data packet is preprocessed and calculated using a built-in programmable hardware preprocessing pipeline to output structured data suitable for rendering, including:

[0017] Select the target preprocessing pipeline based on the data type in the fused data packet;

[0018] In the target preprocessing pipeline, the vehicle coordinate data in the fused data packet is subjected to coordinate transformation to obtain screen coordinate data;

[0019] The screen coordinate data is organized into structured data in a rendering buffer format.

[0020] Furthermore, the hardware protocol parsing engine includes a CAN FD frame hardware protocol parsing engine and an Ethernet frame hardware protocol parsing engine.

[0021] Furthermore, the method also includes:

[0022] Receive parameter configuration information for the preprocessing pipeline sent by the cockpit SOC;

[0023] Update the parameters of the preprocessing pipeline based on the parameter configuration information.

[0024] Secondly, this application provides an ADCU data transmission method based on an FPGA gateway, applied to a cockpit SOC, the method comprising:

[0025] Receive the location information of structured data sent by the FPGA gateway in the shared memory region;

[0026] Based on the location information, access the shared memory region to obtain the structured data;

[0027] Rendering data is obtained by performing rendering processing on the structured data.

[0028] The rendering data is sent to the display device.

[0029] Furthermore, the method also includes:

[0030] Get the display mode selected by the user;

[0031] When the display mode is different from the current display mode, the parameter configuration information of the preprocessing pipeline is generated according to the display mode;

[0032] The parameter configuration information is sent to the FPGA gateway.

[0033] Thirdly, this application provides an ADCU data transmission device based on an FPGA gateway, the device comprising:

[0034] The acquisition module is used to acquire the data stream output by the Advanced Driver Assistance Unit (ADCU) in the vehicle network;

[0035] The protocol parsing module is used to parse the data stream using the built-in hardware protocol parsing engine and generate structured data objects.

[0036] The data alignment module is used to assign timestamps to the data objects and align the data objects based on the timestamps to generate spatiotemporally unified fused data packets.

[0037] The data preprocessing module is used to perform preprocessing calculations on the fused data packets through a built-in programmable hardware preprocessing pipeline, and output structured data that can be used for rendering.

[0038] A shared write module is used to write the structured data into a shared memory region, which is a contiguous physical memory established between the FPGA gateway and the cockpit SOC through PCIe memory mapping technology.

[0039] The output module is used to send the location information of the structured data in the shared memory area to the cockpit SOC.

[0040] Fourthly, this application provides an ADCU data transmission device based on an FPGA gateway, the device comprising:

[0041] The receiving module is used to receive the location information of structured data in the shared memory area sent by the FPGA gateway;

[0042] A shared acquisition module is used to access the shared memory region and acquire the structured data based on the location information;

[0043] The rendering module is used to perform rendering processing on the structured data to obtain rendering data;

[0044] The output module is used to send the rendered data to the display device.

[0045] Fifthly, this application provides an electronic device, including: a memory and a processor;

[0046] The memory stores computer-executed instructions;

[0047] The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any of the first aspects, or to perform the method as described in the second aspect.

[0048] Sixthly, this application provides a vehicle, the vehicle comprising: a vehicle body, a cockpit domain SOC, an FPGA gateway, an ADCU, and a display device;

[0049] The FPGA gateway is used to perform the method as described in any of the first aspects;

[0050] The cockpit domain SOC is used to perform the method described in the second aspect.

[0051] In a seventh aspect, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible embodiments of the first aspect.

[0052] Eighthly, this application provides a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.

[0053] This application provides an ADCU data transmission method, apparatus, and vehicle based on an FPGA gateway. The method includes: acquiring the data stream output by the ADCU in the vehicle network; parsing the data stream using a built-in hardware protocol parsing engine to generate structured data objects; assigning timestamps to the data objects and aligning them based on the timestamps to generate spatiotemporally unified fused data packets; performing preprocessing calculations on the fused data packets using a built-in programmable hardware preprocessing pipeline to output structured data that can be used for rendering; writing the structured data into a shared memory area, where the shared memory area is a contiguous physical memory established between the FPGA gateway and the cockpit SOC via PCIe memory mapping technology; and sending the location information of the structured data in the shared memory area to the cockpit SOC. The FPGA gateway utilizes the parallel computing capabilities of the FPGA to replace the serial processing of the traditional software protocol stack for protocol parsing, time synchronization, and preprocessing tasks, freeing up the cockpit SOC's resource computing. Shared memory eliminates the overhead of multiple memory copies in the cockpit SOC. Hardware parallel computing and zero-copy transmission significantly reduce data processing latency, ensuring real-time data transmission between the ADCU and the cockpit SOC. Attached Figure Description

[0054] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0055] Figure 1 The system architecture diagram provided for this application;

[0056] Figure 2 A flowchart illustrating an ADCU data transmission method based on an FPGA gateway provided in this application;

[0057] Figure 3 This is a schematic diagram of the data processing pipeline inside the FPGA gateway provided in this application;

[0058] Figure 4 This application provides a schematic diagram of an FGPA and cockpit SOC system for establishing a shared memory system.

[0059] Figure 5 This is a schematic diagram of the data flow in the AR-HUD application scenario provided in this application.

[0060] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0061] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0062] First, let me explain the terms used in this application:

[0063] Advanced Digital Control Unit (ADCU): Used in intelligent driving systems to generate rich driving environment information (including object list, lane lines, drivable area, vehicle status, etc.) and transmit it to the cockpit domain controller in real time.

[0064] Currently, data interaction between the ADCU and the cockpit domain controller SOC is mainly achieved through the following two methods, both of which have significant performance bottlenecks.

[0065] Method 1: Limited transmission based on traditional in-vehicle control networks (CAN / CAN FD bus as the core). The ADCU encodes the processed structured perception data (such as the position, speed, and type of the target object) into standard CAN or CAN FD signals for broadcast. The CPU of the cockpit domain controller receives these signals through the CAN controller and parses and reassembles them. High signal parsing overhead: The cockpit-side application needs to reassociate and combine signals scattered across multiple CAN messages (such as target ID, X coordinate, Y coordinate, and status) into meaningful objects. This process relies on a complex signal database (DBC) and a large amount of software logic, resulting in high CPU involvement, low processing efficiency, and difficulty in maintenance. Simultaneously, real-time performance is constrained by the bus arbitration mechanism: The CAN bus uses a non-destructive arbitration mechanism of carrier sense multiple access / collision avoidance. Under high bus load, low-priority data messages (some non-critical ADAS status information) may experience significant and uncertain transmission delays, failing to guarantee deterministic, low-latency transmission of critical warning information (such as forward collision warning).

[0066] Method 2: Complex Transmission Based on In-Vehicle Ethernet and Middleware (with SOME / IP Protocol as the Core) To transmit richer data, newer ADCUs generally support in-vehicle Ethernet communication based on TCP / UDP and SOME / IP protocol stacks. Sensing data is serialized into byte streams and transmitted via Ethernet frames. The disadvantages of this method are a heavy burden on the protocol stack processing and severe CPU resource consumption: the cockpit domain controller (typically running general-purpose operating systems such as Linux and QNX) needs to run the complete TCP / IP protocol stack as well as SOME / IP service discovery, serialization / deserialization modules. Processing each data packet involves multiple kernel-to-user mode switches, memory copies, and context switches. This severely strains the computing power intended for core cockpit functions such as graphics rendering and speech recognition. Furthermore, it introduces high latency and jitter: the operating system's task scheduling, the page table translation of the memory management unit, and the buffering and retransmission mechanisms of the network protocol stack all introduce unpredictable latency and jitter.

[0067] There is a slight time difference when the data output by different processing modules (such as vision and radar) within the ADCU is sent via SOME / IP. The poor accuracy and complex logic of time synchronization at the application layer of the cockpit SOC lead to a logical misalignment in the spatial position of "perceived vehicles" and "perceived lane lines" during fusion display.

[0068] The ADCU data transmission link consists of: ADCU, CAN / SOME-IP, and SOC software processing. Specifically, it includes:

[0069] Data Acquisition and Protocol Parsing: The cockpit SOC's CPU runs the network protocol stack software (CAN driver, TCP / IP stack, SOME / IP library) within the operating system kernel, parsing packets one by one via interrupts and polling. This consumes a large number of CPU cycles, resulting in high latency and significant jitter due to system scheduling.

[0070] Data time synchronization and alignment: Data from various modules within the ADCU is timestamped by software before being sent out, introducing additional latency in network transmission and SOC software processing. The cockpit application performs software alignment upon receiving the data, with millisecond-level accuracy, resulting in poor fusion and a tendency for misalignment.

[0071] Data preprocessing and format conversion: The CPU or GPU of the cockpit SOC needs to convert the raw signals or serialized byte streams received from the network into a format that can be directly used by graphics APIs (such as OpenGL ES, Vulkan) (such as vertex arrays, texture data). This conversion calculation consumes a lot of SOC computing power.

[0072] During data transfer to the cockpit SOC, the data undergoes multiple memory copies, including those to the network interface buffer, kernel space buffer, user space application buffer, and graphics API buffer (such as GPU memory). Each copy consumes bus bandwidth and CPU / DMA resources.

[0073] System compatibility and flexibility: It heavily relies on the pre-defined static communication matrix, signal list, and SOME / IP service interface between the ADCU and the cockpit SOC. Any change in data format or communication protocol requires simultaneous upgrades on both sides, resulting in high costs and long development cycles.

[0074] This application constructs a data gateway based on FPGA (Field-Programmable Gate Array), achieving efficient acquisition, preprocessing, and distribution of perception data between ADCU (Advanced Driver Assistance Unit) and cockpit domain controller through hardware acceleration and zero-copy transmission technology. It transfers all high-latency, resource-intensive tasks (such as protocol parsing, data time synchronization, format conversion, and memory copying) that traditionally rely on software protocol stacks and CPU processing to the FPGA hardware logic in parallel, completely freeing up SOC computing power. Direct data access and zero-copy transmission are achieved through PCIe shared memory technology, avoiding multiple memory copies (network interface → kernel space → user space → graphics API buffer), reducing bus bandwidth consumption and CPU / DMA resource usage. This solution not only solves the problems of bandwidth bottlenecks, poor real-time performance, and CPU resource encroachment in existing in-vehicle network communication, but also achieves compatibility and dynamic configuration of multiple protocols (CAN / CAN FD / SOME / IP) through hardware programmability, providing a deterministic, low-latency, and highly compatible solution for data interaction between intelligent vehicle domains.

[0075] Figure 1 The system architecture diagram provided for this application is as follows: Figure 1 As shown, it includes ADCU, FPGA gateway, cockpit SOC, instrument / central control screen / AR-HUD.

[0076] ADCU: As a data producer, it broadcasts the perception and decision data it processes and generates via CAN FD bus and / or vehicle Ethernet (supporting SOME / IP) in accordance with established standards (such as AUTOSAR).

[0077] FPGA Gateway: Serving as the core processing and forwarding hub. It connects to the vehicle network via a multi-channel CAN FD controller and an in-vehicle Ethernet MAC supporting time-sensitive networking. Simultaneously, it is directly connected to the cockpit SOC via a high-speed PCIe link (operating in endpoint mode).

[0078] The internal logic of the FPGA is divided into four key functional subsystems:

[0079] Protocol front-end and hardware parsing subsystem: This includes the physical layer interface, the link layer controller, and the hardware protocol parsing core. This core is a pure digital logic circuit capable of parallel processing of data streams from different buses, enabling real-time extraction of CAN message signals and hardware decapsulation and deserialization of SOME-IP / UDP / IP messages, directly outputting application layer data objects.

[0080] The data processing and fusion subsystem includes a high-precision time synchronization module (integrating a PTP slave clock to uniformly time-stamp the input data), a data alignment and fusion engine (for data association based on hardware timestamps), and a reconfigurable hardware preprocessing pipeline (consisting of a series of configurable processing units that can load different hardware acceleration IP cores to execute specific algorithms).

[0081] Shared memory and zero-copy management subsystem: includes a shared memory controller (DDR storage unit), a descriptor ring queue manager (maintaining the state of the producer and consumer rings), and a high-performance DMA write engine (used to efficiently move processed data to a specified location in shared memory).

[0082] Host Interface and Interrupt Subsystem: Includes PCIe endpoint controller (responsible for link layer communication with cockpit SOC) and multi-vector interrupt generation logic (used to send precise MSI-X interrupts to cockpit SOC based on event type).

[0083] Cockpit SOC: As a data consumer, it runs the cockpit operating system and graphics applications. Its PCIe root complex maps the FPGA's shared memory region to its own physical / virtual address space and manages synchronization with the FPGA through drivers.

[0084] The instrument panel / central control screen / AR-HUD are projected and displayed.

[0085] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0086] Figure 2 A flowchart illustrating an ADCU data transmission method based on an FPGA gateway provided in this application is shown below. Figure 2 As shown, using an FPGA gateway as the execution entity, this method includes the following steps:

[0087] S101. Obtain the data stream output by the Advanced Driver Assistance Unit (ADCU) in the vehicle network.

[0088] In this step, massive amounts of perception data are collected in real time from the Advanced Driver Assistance Unit (ADCU). The ADCU typically integrates multiple sensors (cameras, millimeter-wave radar, lidar, ultrasonic sensors, IMU, high-precision positioning, etc.) and processes the data stream through preliminary fusion, perception, object detection, lane marking, semantic segmentation, drivable area, occupancy grid, trajectory prediction, etc.

[0089] S102: The built-in hardware protocol parsing engine parses the data stream and generates structured data objects.

[0090] The FPGA gateway incorporates a dedicated hardware protocol parsing engine (such as supporting IEEE 1588 / PTP). Operations such as CAN FD signal extraction, SOME-IP message decapsulation, and UDP / IP checksum verification are all performed in parallel at line speed within the FPGA's hardware logic. This completely bypasses the cockpit SOC's operating system protocol stack and software interrupt handling.

[0091] In the traditional approach, the cockpit SoC (usually running Linux / QNX / Android and other OSs) needs to receive CAN FD or Ethernet messages through software drivers, and then go through the protocol stack layer by layer (SocketCAN → TCP / IP → SOME / IP unpacking), which introduces a lot of CPU interrupts, context switching and copy overhead. Especially under high load (such as multiple cameras + radar + ultrasonic + body CAN bus coming in at the same time), the latency and jitter are difficult to control.

[0092] Through the FPGA gateway, the lowest-level and most time-consuming protocol parsing is all offloaded to hardware. For CAN FD frames, a hardware state machine (FSM) and a parallel comparator are used to parse CAN FD frames in real time (including bit stuffing, CRC check, and ACK bit processing). For SOME / IP, the FPGA implements hardware-level Some / IP header parsing and header stripping. Specifically, the FPGA gateway continuously monitors the connected vehicle network. When a data packet (CAN frame or Ethernet frame) from a target ADCU arrives, the data stream is fed into the hardware parsing engine driven by the FPGA's fixed-frequency clock. For example, a SOME-IP message containing a list of targets is pipelined through header stripping, deserialized into a structure object in memory, and output to the next-level buffer queue within tens to hundreds of clock cycles. This process is entirely implemented by hardware logic, independent of the cockpit SOC's software state, and the processing latency is deterministic and predictable.

[0093] In this way, the cockpit SoC subsequently receives the parsed net data, reducing CPU load and making it suitable for high real-time cockpit rendering / fusion scenarios.

[0094] S103. Assign timestamps to data objects and align data objects based on timestamps to generate spatiotemporally unified fused data packets.

[0095] The FPGA gateway integrates a high-precision hardware time synchronization unit. Data objects output from the parsing engine immediately enter the time synchronization module. This module, based on a precise clock synchronized from the vehicle's time master node, assigns a nanosecond-level resolution hardware timestamp to each data object. Subsequently, the fusion engine, based on this timestamp, associates and packages data from different processing modules within the ADCU that describe the environmental state at the same moment (such as lane lines recognized by vision and targets detected by radar), forming a spatiotemporally unified fusion data packet.

[0096] This step ensures that the rendering engine / fusion algorithm on the cockpit SOC side acquires time-aligned structured data, significantly simplifying the complexity of upper-layer software. The FPGA gateway replaces traditional software synchronization algorithms with hardware logic, eliminating misalignment issues caused by network transmission jitter and software processing delays, and significantly improving data fusion accuracy. Furthermore, hardware time synchronization avoids complex software synchronization logic at the cockpit SOC application layer, reduces CPU resource consumption, and ensures that the data received by the cockpit display system is highly consistent in spatiotemporal dimensions, avoiding logical errors such as mismatches between perceived targets and lane line positions due to timestamp differences.

[0097] S104. The built-in programmable hardware preprocessing pipeline performs preprocessing calculations on the fused data packets and outputs structured data that can be used for rendering.

[0098] The output of the autonomous driving domain is often parametric results (such as polygons, center points / sizes / orientation / velocity vectors in a BEV bird's-eye view), while cockpit rendering requires formats that OpenGL / Vulkan / Mali GPUs can directly consume (such as vertex buffers (VBOs), index buffers (IBOs), texture coordinates, etc.). The FPGA acts as a hardware pre-rendering front-end, performing coordinate transformations on the data in the fused data package: vehicle coordinate system → body coordinate system → camera coordinate system → screen pixel coordinates. It supports format conversion, transforming semantic-level targets into GPU-friendly formats such as triangle lists, point clouds, and wireframes.

[0099] The FPGA gateway has a built-in programmable hardware preprocessing pipeline. This pipeline can be configured to perform operations such as coordinate transformation (from vehicle coordinate system to screen pixel coordinate system), data format conversion (parametric representation to vertex buffer), and data compression / filtering. The pipeline directly outputs "render-ready" structured data.

[0100] Specifically, based on cockpit application requirements (such as AR-HUD, 3D instruments, and panoramic imaging), the corresponding pipeline is selected to process the fused data in a targeted manner. Computationally intensive tasks originally performed on the SOC are moved to FPGA hardware for execution. This reduces the amount of data transmitted and improves bandwidth efficiency.

[0101] For example, when configured in "AR-HUD Enhanced Display Mode," the pipeline executes sequentially: 3D to 2D projection transformation based on the current vehicle posture, real-time fitting of lane line parameters to a smooth Bézier curve, and generation of a control point set. All mathematical operations are performed in parallel by dedicated hardware resources within the FPGA, such as multipliers, adders, and function lookup tables.

[0102] S105. Write the structured data into the shared memory area, which is a continuous physical memory area established between the FPGA gateway and the cockpit SOC through PCIe memory mapping technology.

[0103] The FPGA has an internal contiguous physical memory pool, which can be an external DDR. Through PCIe memory mapping technology (such as PCIe Resizable BAR / big page mapping), the entire memory pool is mapped to the kernel virtual address space of the cockpit SoC (ARM architecture), resulting in a contiguous virtual address segment (e.g., 0xE000_0000 ~ 0xF000_0000). This mapping is established once; all subsequent data accesses are based on the physical address and offset, eliminating the need for remapping.

[0104] By using a physical shared memory pool, direct data writing and zero-copy transmission are achieved, completely eliminating multiple memory copies in the traditional software protocol stack (such as network interface buffer → kernel space → user space), significantly reducing bus bandwidth consumption and resource usage.

[0105] S106. Send the location information of the structured data in the shared memory area to the cockpit SOC.

[0106] The cockpit SoC can now access the entire FPGA DDR and no longer needs to write to shared memory via DMA, but it still needs to notify the location of new data.

[0107] There are two ways to notify the cockpit SOC:

[0108] 1. Producer-Consumer Ring. In the FPGA, the high-performance DMA engine writes data directly to specific locations in the shared memory pool managed by the FPGA, based on addresses pre-allocated by the memory management unit. Simultaneously, a lightweight descriptor is generated and populated into the producer descriptor ring. This descriptor key includes: the starting physical address of the data block in shared memory, the data length, and the data type identifier. Subsequently, the FPGA sends an MSI-X interrupt to the cockpit SoC via the PCIe link, with the interrupt message indicating that a new descriptor is available. The high-performance driver running in kernel or user mode on the cockpit SoC side captures this interrupt. The driver retrieves the latest descriptor from the producer descriptor ring. Because the entire shared memory pool of the FPGA is mapped to a contiguous virtual address space of the cockpit SoC through the PCIe address mapping mechanism during system initialization, the driver or upper-layer graphics application can directly use the physical address offset recorded in the descriptor to access data in memory via pointer dereference, without any copying. After the data consumption is complete, the driver writes a completion confirmation to the consumption descriptor ring, and the resource management logic on the FPGA side then reclaims the corresponding memory block for subsequent data writing.

[0109] 2. Doorbell Register: The FPGA writes a 32-bit register, and the register value is the slot number / offset of the latest buffer. The cockpit side reads the register after polling or interruption.

[0110] This technical solution introduces an FPGA-based gateway between the ADCU and the cockpit domain controller. This gateway node is connected in series within the in-vehicle network and plays three core roles: a multi-protocol ADCU data acquisition and hardware parser; a hardware-accelerated data preprocessing and optimizer; and a zero-copy, high-efficiency distributor for the cockpit SOC. The FPGA hardware logic replaces the software protocol stack, eliminating CPU interrupt and context switching overhead, ensuring that end-to-end data transmission latency meets hard real-time requirements. The cockpit SOC does not need to participate in protocol parsing, data synchronization, and format conversion, allowing CPU computing power to focus on core functions such as graphics rendering and speech recognition. The FPGA gateway front-end adapts to multiple versions of ADCU interfaces, and the back-end preprocessing logic and shared memory data structures can be dynamically configured through the cockpit SOC, supporting cross-vendor and cross-protocol data interaction. Hardware time synchronization and data alignment logic ensures accurate synchronization of ADCU multi-source data in both timestamp and spatial dimensions, preventing logical misalignment in the cockpit display system. Hardware preprocessing reduces the amount of data transmitted (e.g., converting parameterized data into vertex arrays), improving the utilization rate of the in-vehicle network bandwidth.

[0111] Figure 3This is a schematic diagram of the data processing pipeline inside the FPGA gateway provided in this application. Data starts from the input buffer and sequentially passes through hardware protocol parsing, time synchronization and alignment, and configurable preprocessing (containing multiple parallel processing units).

[0112] Input data buffer: Solves the problem of cross-clock domain data synchronization, synchronizing CAN / Ethernet data with different transmission rates to the FPGA's internal clock domain. Cross-clock domain data transmission can be achieved by calling IP cores or designing an asynchronous FIFO using Gray code counters.

[0113] Protocol parsing: Identifies whether the input data is a CAN FD frame or a SOME-IP / Ethernet frame, performing multi-layer protocol parsing within the hardware logic to avoid software overhead. Simultaneously, a high-precision hardware timestamp is added to the data during protocol parsing.

[0114] Time synchronization and data alignment: Correlating data from different ADCUs that describe the physical world at the same moment. Handling out-of-order arrival issues caused by network latency jitter. Packaging time-aligned multi-source data for subsequent processing.

[0115] Data preprocessing: Based on cockpit application requirements (such as AR-HUD, 3D instrument panel, panoramic imaging), data is processed in a targeted manner. Computationally intensive tasks that were originally performed on the SOC are transferred to FPGA hardware for execution. This reduces the amount of data transmitted and improves bandwidth efficiency.

[0116] Data Output: The processed data is encapsulated into a uniform format expected by the cockpit SOC driver. The complete data packet is placed in the output queue, awaiting writing to shared memory by the DMA engine.

[0117] Figure 4 This application provides a schematic diagram of a shared memory system between an FPGA and a cockpit SOC. An efficient data sharing bridge is established between the two independent hardware systems (FPGA and cockpit SOC) via PCIe memory mapping technology. This architecture reduces the overhead of numerous copy operations caused by data transmission and reception on the bus.

[0118] The descriptor area contains two independent circular buffers, the producer descriptor ring and the consumer descriptor ring, serving as the control and status communication channel between the FPGA and the SOC. It does not transmit actual data, only metadata about the data (data location, size, type, etc.). Each ring maintains its own read / write pointers, using the pointer position to determine if new data or acknowledgment information is available, achieving lock-free and efficient asynchronous communication.

[0119] Driver Buffer: During system initialization, the driver, through PCIe configuration, determines which physical address range of the FPGA memory is mapped to on the SOC and performs the translation from the physical address on the FPGA to the virtual address on the cockpit SOC. To avoid conflicts between SOC data reading and FPGA data writing, it also maintains production data pointers and consumption data pointers. Simultaneously, it must handle interrupt requests sent by the FPGA.

[0120] PCIe memory mapping exposes the DDR physical addresses on the FPGA to the SOC. This makes this memory part of the host's physical address space (achieved by the PCIe root complex and IOMMU hardware). When the CPU issues a memory access command, the hardware automatically translates it.

[0121] Figure 5 This is a schematic diagram of the data flow in an AR-HUD application scenario provided in this application. For example... Figure 5 As shown, the CAN / SOME-IP data stream (such as lane lines, objects ahead, traffic signs, etc.) from the ADCU first enters the FPGA's multi-protocol interface. Protocol parsing, coordinate transformation, and data preprocessing are completed within the FPGA. After data encapsulation, it is written to shared memory via DMA technology. Subsequently, it is directly accessed and processed by the cockpit SOC via PCIe zero-copy technology, and the HUD directly projects and displays the data. This method demonstrates its technical value in AR-HUD applications: through hardware acceleration of the FPGA gateway and a zero-copy transmission architecture, it solves core problems such as latency, accuracy, and resource consumption that traditional solutions cannot overcome.

[0122] The FPGA contains multiple preprocessing pipelines. The FPGA selects and activates the target preprocessing pipeline based on the current scene / mode (e.g., AR-HUD enhanced mode, normal HUD mode, pure instrument display, entertainment mode, etc.) and the type of input data (pure lane lines, navigation arrows, fused target list, ADAS overlay information, etc.). In the target preprocessing pipeline, the vehicle coordinate data in the fused data package undergoes coordinate transformation to obtain screen coordinate data. This screen coordinate data is then organized into structured data in a render buffer format. The format includes: a structured list: {object ID, screen coordinates (x, y), depth / priority, color / style attributes, Bezier control points or polyline point sets, etc.}; or directly generating a vertex buffer + attribute buffer for subsequent use by the GPU rendering engine.

[0123] In AR-HUD scenarios, the vertex array generated by the FPGA can directly drive graphics rendering, avoiding additional calculations by the cockpit SOC and improving the real-time performance and data quality of the display system.

[0124] The specific functions of the pipeline are dynamically configured by the cockpit SOC during power-on initialization or runtime. This can be achieved through the following methods:

[0125] In one implementation, the pipeline itself is static, but internally contains multiple functional units with bypass or selectable paths. The cockpit SOC writes a set of configuration registers to the FPGA via registers or a dedicated control bus. The configuration includes: enable / bypass selection for each processing module, key parameters (such as projection matrix, distortion correction coefficients, number of control points for Bézier curve fitting, smoothing factor α, threshold, etc.), data flow routing selection, computational precision / truncation bit width, etc.

[0126] For example: when the cockpit SOC detects "entering AR-HUD enhanced mode" (e.g., the user turns on navigation, the vehicle speed is >60km / h, and clear lane lines are detected), the SOC writes a configuration package of tens to hundreds of bytes at once, and the control state machine inside the FPGA updates all parameter registers to complete the switch.

[0127] This approach controls the hardware data path through software, resulting in zero reconfiguration latency and low resource overhead.

[0128] Specifically, during the cockpit system power-on / initialization phase, the cockpit SoC completes its own startup. The SoC writes an initial default configuration package to the FPGA's control register space, including the default enable / bypass states of all modules, the default projection matrix, distortion coefficients, various thresholds, alpha smoothing factor, number of Bezier control points, and default data flow routes. After receiving the write operation, the FPGA's internal configuration state machine stores the data in the initial default configuration package into the corresponding registers. Users can trigger the desired display mode through mode switching operations such as the central control screen, voice, and physical buttons. The application layer (or middleware) on the cockpit SoC determines the user's selected display mode. For example: if the user turns on navigation, it enters AR-HUD enhanced mode; if the vehicle speed is >60 km / h and the lane lines are clear, it switches to high-precision lane enhancement mode; at night / in rain / in tunnels, it switches image enhancement parameters. If the current display mode is different from the user's selected display mode, the SoC decision layer prepares parameter configuration information according to the user's selected display mode. The FPGA interface receives the parameter configuration information, and the internal configuration state machine synchronizes the received parameter configuration to the registers, updating the parameters of the preprocessing pipeline.

[0129] For the cockpit SOC side, the data transmission steps are as follows:

[0130] Step 1: Receive the location information of the structured data sent by the FPGA gateway in the shared memory area.

[0131] In one implementation, the FPGA notifies the SoC of the specific location of new data written to shared memory via an MSI-X interrupt or a Doorbell register polling method. Upon receiving the interrupt / polling of the flag, the SoC immediately reads the descriptor or metadata structure written by the FPGA. The descriptor or metadata structure contains specific information indicating the location of the structured data.

[0132] Step 2: Access the shared memory region based on the location information to obtain structured data.

[0133] The cockpit SoC has completed PCIe enumeration during the startup phase, mapping the FPGA's BAR space to the SoC's CPU address space. The SoC directly uses virtual addresses to read the structured data that was just written to the FPGA. The entire reading process does not involve any additional copying, and the latency is typically in the range of a few microseconds to tens of microseconds.

[0134] Optionally, after acquiring the structured data, you can check if the length and frame sequence number are consecutive, perform CRC or simple consistency checks, and check if the timestamp is within a reasonable window. If an anomaly is found, the frame can be discarded or the FPGA can be requested to retransmit it.

[0135] Step 3: Perform rendering processing on the structured data to obtain the rendering data.

[0136] During the rendering process, drawing can be performed directly through the GPU, or the structured data can be processed before rendering; there are no restrictions on this.

[0137] Step 4: Send the rendering data to the display device.

[0138] This application also provides an ADCU data transmission device based on an FPGA gateway, the device comprising:

[0139] The acquisition module is used to acquire the data stream output by the Advanced Driver Assistance Unit (ADCU) in the vehicle network;

[0140] The protocol parsing module is used to parse data streams using the built-in hardware protocol parsing engine and generate structured data objects.

[0141] The data alignment module is used to assign timestamps to data objects and align data objects based on timestamps to generate spatiotemporally unified fused data packets;

[0142] The data preprocessing module is used to preprocess and calculate the fused data packets through a built-in programmable hardware preprocessing pipeline, and output structured data that can be used for rendering.

[0143] The shared write module is used to write structured data into a shared memory region, which is a contiguous physical memory established between the FPGA gateway and the cockpit SOC through PCIe memory mapping technology.

[0144] The output module is used to send the location information of structured data in the shared memory area to the cockpit SOC.

[0145] Furthermore, the output module is also used for:

[0146] When structured data is written to a shared memory region, a lightweight descriptor is generated and filled into the production descriptor ring; the lightweight descriptor includes the starting physical address of the structured data in the shared memory, the data length, and the data type identifier.

[0147] An MSI-X interrupt is sent to the cockpit SOC via the PCIe link, indicating that a new descriptor is available.

[0148] Furthermore, the data preprocessing module is specifically used for:

[0149] Select the target preprocessing pipeline based on the data type in the fused data packet;

[0150] In the target preprocessing pipeline, the vehicle coordinate data in the fused data packet is transformed to obtain screen coordinate data;

[0151] Organize screen coordinate data into structured data in a render buffer format.

[0152] The hardware protocol parsing engine includes a CAN FD frame hardware protocol parsing engine and an Ethernet frame hardware protocol parsing engine.

[0153] The device also includes a dynamic update module for:

[0154] Receive parameter configuration information for the preprocessing pipeline sent by the cockpit SOC;

[0155] Update the parameters of the preprocessing pipeline based on the parameter configuration information.

[0156] The device provided in this embodiment can execute the method provided by the FPGA gateway in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0157] This application also provides an ADCU data transmission device based on an FPGA gateway, the device comprising:

[0158] The receiving module is used to receive the location information of structured data in the shared memory area sent by the FPGA gateway;

[0159] The shared acquisition module is used to access the shared memory region and obtain structured data based on location information;

[0160] The rendering module is used to perform rendering processing on structured data to obtain rendering data;

[0161] The output module is used to send the rendered data to the display device.

[0162] The device also includes a dynamic update module, used to: obtain the display mode selected by the user; and when the display mode is different from the current display mode, generate parameter configuration information for the preprocessing pipeline according to the display mode selected by the user.

[0163] The output module is also used to send parameter configuration information to the FPGA gateway.

[0164] The device provided in this embodiment can execute the method provided by the cockpit SOC side in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0165] This application also provides a schematic diagram of an electronic device. The electronic device can be an FPGA gateway or a cockpit SOC. The electronic device provided in this embodiment includes at least one processor and a memory. Optionally, the device further includes a communication component. The processor 501, the memory, and the communication component are connected via a bus.

[0166] In a specific implementation, at least one processor executes computer execution instructions stored in memory, causing at least one processor to perform the above-described method.

[0167] The specific implementation process of the processor can be found in the above method embodiments, and its implementation principle and technical effect are similar, so it will not be repeated here.

[0168] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0169] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0170] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0171] This application also provides a vehicle, which includes a vehicle body, a cockpit domain SOC, an FPGA gateway, an ADCU, and a display device;

[0172] The FPGA gateway is used to execute the methods in the above method embodiments;

[0173] The cockpit domain SOC is used to execute the methods described in the above method embodiments.

[0174] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0175] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0176] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0177] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0178] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0179] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0180] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0181] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0182] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0183] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. A data transmission method for an ADCU based on an FPGA gateway, characterized in that, The method, applied to a Field-Programmable Gate Array (FPGA) gateway, includes: Acquire the data stream output by the Advanced Driver Assist Control Unit (ADCU) in the vehicle network; The data stream is parsed using a built-in hardware protocol parsing engine to generate structured data objects; A timestamp is assigned to the data object, and the data object is aligned based on the timestamp to generate a spatiotemporally unified fused data packet; The fused data packets are preprocessed and calculated using a built-in programmable hardware preprocessing pipeline to output structured data that can be used for rendering. The structured data is written into a shared memory region, which is a contiguous physical memory region established by the FPGA gateway and the cockpit SOC through PCIe memory mapping technology. The location information of the structured data in the shared memory region is sent to the cockpit SOC.

2. The method according to claim 1, characterized in that, Sending the location information of the structured data in the shared memory region to the cockpit SOC includes: When the structured data is written to the shared memory region, a lightweight descriptor is generated and filled into the production descriptor ring; wherein, the lightweight descriptor includes the starting physical address of the structured data in the shared memory, the data length, and the data type identifier; An MSI-X interrupt is sent to the cockpit SOC via the PCIe link, indicating that a new descriptor is available.

3. The method according to claim 1, characterized in that, The fused data packet is preprocessed and calculated using a built-in programmable hardware preprocessing pipeline to output structured data suitable for rendering, including: Select the target preprocessing pipeline based on the data type in the fused data packet; In the target preprocessing pipeline, the vehicle coordinate data in the fused data packet is subjected to coordinate transformation to obtain screen coordinate data; The screen coordinate data is organized into structured data in a rendering buffer format.

4. The method according to any one of claims 1-3, characterized in that, The hardware protocol parsing engine includes a CANFD frame hardware protocol parsing engine and an Ethernet frame hardware protocol parsing engine.

5. The method according to any one of claims 1-3, characterized in that, The method further includes: Receive parameter configuration information for the preprocessing pipeline sent by the cockpit SOC; Update the parameters of the preprocessing pipeline based on the parameter configuration information.

6. A method for ADCU data transmission based on an FPGA gateway, characterized in that, Applied to cockpit SOC, the method includes: Receive the location information of structured data sent by the FPGA gateway in the shared memory region; Based on the location information, access the shared memory region to obtain the structured data; Rendering data is obtained by performing rendering processing on the structured data. The rendering data is sent to the display device.

7. The method according to claim 6, characterized in that, The method further includes: Get the display mode selected by the user; When the display mode is different from the current display mode, the parameter configuration information of the preprocessing pipeline is generated according to the display mode; The parameter configuration information is sent to the FPGA gateway.

8. An ADCU data transmission device based on an FPGA gateway, characterized in that, The device includes: The acquisition module is used to acquire the data stream output by the Advanced Driver Assistance Unit (ADCU) in the vehicle network; The protocol parsing module is used to parse the data stream using the built-in hardware protocol parsing engine and generate structured data objects. The data alignment module is used to assign timestamps to the data objects and align the data objects based on the timestamps to generate spatiotemporally unified fused data packets. The data preprocessing module is used to perform preprocessing calculations on the fused data packets through a built-in programmable hardware preprocessing pipeline, and output structured data that can be used for rendering. A shared write module is used to write the structured data into a shared memory region, which is a contiguous physical memory established between the FPGA gateway and the cockpit SOC through PCIe memory mapping technology. The output module is used to send the location information of the structured data in the shared memory area to the cockpit SOC.

9. An ADCU data transmission device based on an FPGA gateway, characterized in that, The device includes: The receiving module is used to receive the location information of structured data in the shared memory area sent by the FPGA gateway; A shared acquisition module is used to access the shared memory region and acquire the structured data based on the location information; The rendering module is used to perform rendering processing on the structured data to obtain rendering data; The output module is used to send the rendered data to the display device.

10. An electronic device, characterized in that, include: Memory, processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-5, or the method as described in claim 6 or 7.

11. A vehicle, characterized in that, The vehicle includes: a vehicle body, a cockpit domain SOC, an FPGA gateway, an ADCU, and a display device; The FPGA gateway is used to perform the method as described in any one of claims 1-5; The cockpit domain SOC is used to perform the method as described in claim 6 or 7.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-5, or the method as described in claim 6 or 7.

Images