4. 数据总线与传输延迟：车载网络拓扑
好，咱们进入第四章。这一章聊的是数据怎么在芯片之间、板卡之间、甚至整车之间跑来跑去。说白了，就是数据总线与传输延迟。
你想想看，ADAS系统里，摄像头每秒产生几十帧图像，激光雷达点云数据更是海量。这些数据如果不能及时送到计算单元，那延迟就上去了。我见过不少项目，算法优化得挺好，结果卡在数据传输上，真是可惜。
4.1 车载网络拓扑：CAN、CAN-FD、车载以太网
先说说车上的老熟人——CAN总线。CAN总线在车上用了二十多年，可靠性没得说。但它的带宽只有1Mbps，传个方向盘转角、刹车信号还行。你要是拿它传摄像头数据？嗯，想都别想。
后来有了CAN-FD，带宽提到了8Mbps左右。我参与过一个项目，用CAN-FD传一些雷达的预处理数据，勉强够用。但说实话，对于ADAS这种需要大量原始数据的系统，还是不够。
真正能扛大梁的是车载以太网。100BASE-T1、1000BASE-T1，带宽从100Mbps到1Gbps。我个人习惯，在设计域控架构时，传感器数据回传一定走以太网。为什么？因为延迟可控，带宽够大。
关键点： 车载网络选型，本质是带宽与成本的博弈。CAN-FD适合控制信号，以太网适合数据流。别搞混了。
4.2 PCIe与CXL在ADAS域控中的应用
到了域控内部，情况又不一样了。传感器数据进了域控，怎么送到SoC或GPU？这时候PCIe就登场了。
PCIe Gen3/Gen4在ADAS域控里很常见。一条PCIe Gen4 x4通道，带宽约8GB/s，足够传多路4K摄像头数据。我在设计某款域控时，用了PCIe Switch来扩展接口，把多个传感器的数据汇聚到主芯片。
但PCIe有个问题——它是树形拓扑，CPU必须参与数据搬运。这就带来了延迟。后来CXL（Compute Express Link）出现了。CXL基于PCIe物理层，但支持缓存一致性。说白了，就是让加速器（比如NPU）可以直接访问CPU的内存，不用来回拷贝。
我的建议： 如果你在设计下一代域控，可以关注CXL。它能让数据共享更高效，尤其适合多芯片协同的场景。不过目前生态还在完善，别急着大规模用。
4.3 DMA（直接内存访问）与零拷贝技术
聊到数据传输，就绕不开DMA。DMA的作用，就是让外设（比如以太网控制器）直接把数据写到内存，不用CPU插手。你想想看，如果没有DMA，CPU得一条条指令去搬数据，那还干不干别的了？
零拷贝技术更进一步。传统的数据传输，数据要从内核空间拷贝到用户空间，再拷贝到应用层。零拷贝技术通过mmap或sendfile，让数据直接从内核缓冲区送到网卡，省掉中间拷贝。
我在一个项目中，用零拷贝技术把图像数据的传输延迟降低了30%。效果非常明显。
// 伪代码示例：零拷贝 vs 传统拷贝
// 传统方式
char *buffer = malloc(size);
read(socket, buffer, size); // 内核 -> 用户空间
write(file, buffer, size); // 用户空间 -> 文件
// 零拷贝方式
sendfile(file, socket, NULL, size); // 内核直接搬运
核心思想： 减少数据拷贝次数，就是减少延迟。DMA和零拷贝，都是这个思路。
4.4 我曾经踩过的DMA配置坑
说到DMA，我得分享一个亲身经历的坑。有一次，我在调试一个摄像头数据采集模块，发现图像总是出现撕裂。查了三天，最后发现是DMA描述符配置错了。
怎么回事呢？DMA传输需要配置描述符链表，告诉DMA控制器从哪里读、写到哪里、传多少字节。我当时配置的描述符长度和实际数据长度不匹配，导致DMA传输到一半就停了，数据没写完。
更坑的是，有些DMA控制器支持链式传输，但要求描述符必须对齐到特定地址。我没注意这个，结果描述符被DMA读错了，直接死机。
避坑指南：
- DMA描述符的地址对齐要求，一定要看芯片手册。别想当然。
- 描述符链表要保证完整性，最后一个描述符要设置中断或循环标志。
- 调试时，先跑单次DMA传输，确认没问题再开循环模式。
嗯，这些坑踩过之后，我现在设计DMA配置时，都会先画一个描述符链表的流程图，确保每个环节都正确。你想想看，硬件设计就是这样，一个小细节没注意，可能就要花好几天去排查。
好了，这一章的内容就到这里。下一章我们会聊聊内存架构与缓存一致性，这也是延迟优化的重头戏。