# SerDes-whitepaper
Author Profile: The Project Lead for this White Paper is based at Geely Auto Group; we warmly welcome you to visit Geely for further exchange and discussion.

We are deeply grateful for the professional support we have received from everyone involved. Since its inception on February 9, 2026, the project has undergone several months of intensive collaborative effort, culminating in the official finalization of this White Paper on April 30. We extend our sincere thanks to all participating organizations and team members for their professional dedication and unwavering support, which enabled us to collectively achieve this significant milestone amidst a fast-paced and demanding schedule. We offer our heartfelt appreciation and look forward to continuing our collaboration to jointly drive the advancement of the industry.

https://zhuanlan.zhihu.com/p/2034255037212406518

During the 2026 Beijing Auto Show, the Geely Automobile Research Institute—in collaboration with a national-level center, dozens of global chip manufacturers, the SerDes public protocol alliances (802.3dm, ASA, APHY, HSMT, OPENGMSL), and various universities—released the *White Paper on the Development of Automotive SerDes Technology*.

With the gradual proliferation of intelligent vehicles, high-speed data communication plays a pivotal role. High-speed data communication is generally categorized into two main types:
 **Symmetric Communication:** The theoretical bandwidth in both directions is equal. In the automotive domain, commonly used symmetric communication technologies include:
o **PCIe:** Typically applied for inter-chip communication within a domain controller.
o **Ethernet:** Widely used for communication between domain controllers, as well as between domain controllers and zone controllers.
o **CAN:** ​​Used for communication between ECUs.
 **Asymmetric Communication:** The theoretical bandwidth in the two directions is unequal; typically, the forward channel is utilized for high-speed data transmission, while the reverse channel is used for control signals. The forward bandwidth is significantly greater than the reverse bandwidth. Typical applications in the automotive domain include:
o **Sensor Networks:** Such as the transmission of raw data from cameras and cascaded radars.
o **Video Streaming:** Used for low-latency video data transmission between domain controllers, as well as for video output from domain controllers to display devices.
SerDes solutions are based on asymmetric communication principles. To enable bidirectional communication, there are typically two implementation methods:
 **Full-Duplex Mode:** Two distinct frequency bands—one high and one low—are utilized on the same communication line to facilitate communication in the forward and reverse directions simultaneously. The advantage of this approach is that communication in both directions can occur concurrently, thereby minimizing link latency and allowing for the full utilization of available bandwidth. However, a drawback is that the receiver may be required to cancel out reflection signals generated by the transmitter due to simultaneous transmission. This is particularly challenging in scenarios where the transmission and reception spectra partially overlap, leading to relatively complex analog circuit designs and a negative impact on the signal-to-noise ratio (SNR). Furthermore, since the frequency range of the reverse channel is lower, robust design is required to mitigate interference originating from the PDOC's DC/DC converters.
 **Half-Duplex Mode:** Communication is permitted in only one direction at any given time. Bidirectional communication is achieved through time-division multiplexing. Evidently, this design introduces greater latency; moreover, since the total bandwidth is shared between the forward and reverse channels, the effective forward bandwidth is slightly lower than the total available bandwidth. However, a key advantage of this design is that the receiver circuitry is relatively simpler, as there is no need to cancel out reflections caused by simultaneous transmission; theoretically, this allows for a higher SNR. Conversely, since the modulation frequency for the reverse transmission is identical to that of the forward transmission, the analog circuit design requirements for the reverse channel are relatively stringent. Finally, because the operating frequency of the PDOC's DC/DC converters is significantly lower than the modulation frequency, it is unlikely to cause interference to the communication link. For current use cases, the resulting additional latency typically falls within an acceptable range.
The network topologies supported by SerDes are of critical importance to the applications utilizing them. Common topological forms employed in these applications include:
 Link Aggregation: The consolidation of data originating from multiple links; this typically requires the simultaneous transmission of this aggregated data to the next node.
 Link Splitting: The separation of data—originally multiplexed within a single link—back into multiple distinct links, which are then transmitted individually to different nodes.
 Daisy-Chaining: The aggregation of data from multiple links onto a single shared link, thereby connecting multiple nodes in a serial chain; each node processes either the data intended for itself or the data associated with one or more of its constituent sub-links.
Development Trends:
 High Bandwidth Demand: This demand stems primarily from the requirements of video data transmission. As the number and size of in-vehicle displays continue to increase, a correspondingly higher bandwidth becomes necessary. Furthermore, the requirement to support high refresh rates places even greater demands on available bandwidth.
 Enhanced Functional Safety and Cybersecurity: With the advancement of Level 3 (L3) and Level 4 (L4) autonomous driving technologies, increasingly stringent requirements are being imposed on the functional safety of SerDes systems. Due to the use of sensor redundancy, a system is typically expected to maintain its performance without significant degradation even in the event of a single sensor failure at any given time. However, a critical issue arises from the widespread adoption of "link aggregation" in SerDes applications: the failure of a single SerDes component can simultaneously result in the failure of multiple sensors. Currently, almost all SerDes solutions on the market face this inherent vulnerability. Similarly, the integrity of certain data streams is absolutely paramount; although some protocols incorporate mechanisms such as CRC (Cyclic Redundancy Check) to validate specific data, these measures are often insufficient to provide comprehensive and robust protection.
 I3C Support: In traditional solutions where the SoC features an integrated ISP (Image Signal Processor), the sensor typically requires configuration on a per-frame basis. If simultaneous configuration of multiple cameras is required, the resulting communication bandwidth demand may exceed the upper limits of the standard I2C interface. A potential solution to this challenge lies in enabling I3C interface support at the deserializer end of the system.
For a considerable period, SerDes protocols have predominantly been proprietary in nature; this implies that the serializer and deserializer components must be sourced from the same manufacturer. Furthermore, these serializer/deserializer pairs are often deployed within systems provided by different vendors. This situation severely restricts system flexibility, limits the ability of sensor chip manufacturers to integrate SerDes IP directly into their products, and ultimately results in end-users having to bear relatively high costs. However, as an increasing number of manufacturers begin to publish and open-source their standards, this issue is expected to see significant improvement in the near future. A primary objective of this white paper is to compare the distinct characteristics, performance capabilities, and applicable domains of various protocols, thereby enabling application developers to make more informed choices tailored to their specific requirements.
Furthermore, this initiative serves as an opportunity to forge close ties among protocol alliances, chip vendors, end-users, and research institutions. By fostering mutual collaboration, we aim to collectively drive technological advancement and ultimately benefit the end-users.
The publication of this white paper marks merely a starting point; we are confident that, as requirements evolve and technologies advance, future revisions will be continuously released—thereby establishing this document as a vital platform and connective link within the ecosystem.