第2章硬件架构基础

2. 硬件架构基础：SoC与GPU选型分析、显示接口与带宽计算、内存与存储规划

好，咱们进入第二章。这一章是硬件的底子，说白了就是选芯片、算带宽、配存储。很多朋友觉得软件定义汽车嘛，硬件差不多就行了。我告诉你，这个想法很危险。我在项目里见过太多因为硬件选型失误，导致后期多屏方案推倒重来的案例。今天咱们就把这几个硬骨头啃下来。

选SoC，大家第一反应是看TOPS（算力）。嗯，这没错，但做多屏异显异触，光看算力远远不够。我个人习惯，先看三个关键指标：

显示控制器数量：你的SoC能独立驱动几路显示？比如高通SA8155P，它内部集成了3个Display Processing Unit（DPU），理论上可以支持3路独立显示。如果你要做4屏，那就得外挂桥接芯片或者用GPU去合成。
GPU的“多上下文”能力：GPU能不能同时为多个屏幕渲染不同的内容？这涉及到GPU的硬件虚拟化。我在一个项目中用过某款国产芯片，GPU号称支持多屏，但实际跑起来，一个屏幕切导航，另一个屏幕就掉帧。后来查了手册，发现它的GPU上下文切换是软件模拟的，不是硬件原生支持。
视频编解码通道数：现在哪个车没个360环视？如果SoC只能同时解码2路视频流，你要做4路环视+1路DVR，那就得外挂视频处理器。这个坑，我踩过。

核心建议：选型时，直接找芯片原厂要“多屏显示参考设计”的文档。如果对方支支吾吾，或者给你看的是单屏Demo，那就要小心了。

接口选型，直接决定了你的布线成本和信号质量。咱们一个一个说。

这是车载用得最多的接口，尤其是仪表和中控。它走的是MIPI协议，特点是功耗低、线束少。但有个致命弱点——传输距离短。一般不超过30cm。如果你要把屏幕放在副驾或者后排，DSI基本就废了，得转成其他接口。

避坑指南：我曾经在一个项目中，为了省成本，用DSI线缆走了50cm。结果屏幕在高温下出现雪花点，最后不得不加了一颗MIPI Re-driver（重驱动器）。成本没省下来，反而多了一颗芯片。

DP接口在车载上越来越流行，尤其是高分辨率屏幕。它的优势是带宽大、支持长距离传输（通过线缆可达3-5米）。eDP是嵌入式版本，常用于仪表和HUD。我个人比较推荐用eDP做仪表，因为它的自刷新功能可以降低GPU负载。

HDMI在车载上主要用于后排娱乐或者外接设备。但要注意，车载环境对HDMI的EMC（电磁兼容）要求很高。我见过一个项目，HDMI线缆没做屏蔽，导致收音机在特定频率下出现杂音。所以，能用DP就别用HDMI，除非你有充分的EMC设计经验。

带宽计算是基本功，但很多人算错。我给大家一个公式，直接套用：

单屏带宽 = 分辨率（宽 × 高） × 色彩深度（bit） × 帧率（fps） × 1.5（开销系数）

举个例子，一块1920x720的仪表屏，30bit色深，60fps刷新：

带宽 = 1920 × 720 × 30 × 60 × 1.5 = 3.73 Gbps

注意，这是单屏。如果你要做三屏异显，总带宽就是三个屏幕相加。然后你再去对比SoC的显示接口总带宽。比如SA8155P的DPU总带宽是24Gbps，理论上够用，但实际还要考虑内存带宽的竞争。

警告：别只看理论带宽。实际项目中，内存控制器会有仲裁延迟，GPU和CPU会抢带宽。我建议留出30%的余量。否则，一旦开启导航动画，中控屏就可能出现撕裂。

内存和存储，是很多人容易忽略的“隐形杀手”。

多屏异显对内存带宽的要求极高。你想想看，每个屏幕都有自己的帧缓冲区（Framebuffer），GPU要同时渲染多个图层，然后合成输出。如果内存带宽不够，GPU就会“等数据”，导致掉帧。

我建议：

存储主要看两点：读写速度和寿命。多屏系统通常要预装多个操作系统（比如仪表用QNX，中控用Android），还要存地图数据、音视频文件。我建议：

个人经验：我曾经在一个项目中，为了省几块钱，用了消费级eMMC。结果跑了半年，存储出现坏块，导致系统频繁重启。最后全量召回更换，成本是省下来的几十倍。嗯，从那以后，我再也不敢在存储上省钱。

总结一下，做多屏异显异触的硬件选型，我总结了三看：

下一章，咱们聊聊软件架构。硬件是骨架，软件才是灵魂。到时候我会讲讲怎么用虚拟化技术把多个屏幕“管”起来。