简介：这份安霸Ambarella SOC规格资料面向嵌入式视觉与智能相机开发者，聚焦CV28、CV22S、CV25S等系列芯片的选型与方案评估，帮助读者在TensorFlow、Caffe等框架下规划AI推理与视频处理硬件平台。压缩包仅含1个PDF文件，体积约73KB，以表格形式集中呈现各型号的CPU架构、视频输入带宽、ISP功能、编码规格、NPU、内存与接口配置，便于横向对比。目前已有1486人学习下载，说明其在嵌入式AI硬件选型场景中具备一定参考价值。文档按芯片系列逐项列出双核或四核A53主频、200至720MPixel/s输入能力、多路SLVS/MIPI CSI-2/LVMOS输入与HDMI、MIPI DSI等输出组合，并覆盖AE、AWB、HDR、3DMCTF等ISP模块及HEVC、MJPEG编码参数，同时给出LPDDR4x容量、NAND上限、SD控制器、USB、以太网与GPIO等外设明细，以及TrustZone安全特性和10nm工艺、工作温度范围，适合用于方案对比、接口核对与快速查阅。
1. 从一张规格表说起：CV 系列选型为什么不能只看算力数字
去年帮一个做多路智能相机的团队做硬件评审，他们最初拍板选了 CV22S88，理由很直接：720MPixel/s 输入、9Mp30 编码，参数最漂亮。结果样机跑到第三路 sensor 接入时，ISP 的 3D 降噪和 HDR 同时开，帧率掉得厉害，最后不得不回头换成 CV2S66 重新打板。这件事让我印象很深——安霸 CV 系列的规格表看着像一排数字，真正决定项目成败的往往是输入路数、内存位宽、编码组合和温度区间这些“不显眼”的列。这篇就按选型决策的思路，把 CV28、CV22、CV25、CV2 四个系列横向拆开，讲清每个维度怎么比、比完怎么落到具体型号，顺带把嵌入式 AI 里 TensorFlow、Caffe 模型部署时和 NPU、内存的配合关系说透。新手能直接照着结论圈型号，熟手能看到我判断的依据。
2. 选型第一刀：先按视频输入路数和像素吞吐定系列
2.1 输入路数是最硬的约束，先砍掉一半候选
选型我一般不从 CPU 主频开始看，而是从“你要接几路 sensor、每路多大分辨率、总像素吞吐多少”倒推。CV 系列在这件事上分层非常清楚：
| 系列 | 典型输入路数 | 像素吞吐范围 | 适合的场景形态 |
|---|---|---|---|
| CV28 | 3 路（SLVS/MIPI CSI-2/LVMOS） | 200MPixel/s | 单主摄加少量辅助，成本敏感 |
| CV22 | 2 路（SLVS/MIPI CSI-2/LVMOS） | 400～720MPixel/s | 高分辨率单路或双路，编码质量优先 |
| CV25 | 3 路（1 主 + 2 PIP） | 200～504MPixel/s | 主画面加画中画，多画面输出 |
| CV2 | 6 路（全部支持串行 sensor，2 路支持并行） | 640～840MPixel/s | 多路环视、多目拼接 |
这张表是我实际做方案时的第一道筛子。比如做行车记录仪前装，主摄 4K 加一路倒车后视，CV22S66 的 540MPixel/s 和 2 路输入刚好够，没必要上 CV2。反过来，做六路环视或者多目拼接，CV2S55 起步，因为只有 CV2 系列给到 6 路输入，CV25 的 3 路怎么凑都差一口气。这里有个容易翻车的点：像素吞吐是“总输入能力”，不是“每路都能跑满”。CV2S88 的 840MPixel/s 分到 6 路，平均每路 140MPixel/s，如果你其中一路要 4Kp30，剩下的路就得降分辨率或降帧，规划时要把每路的实际像素需求列出来加总，别拿总数除以路数拍脑袋。
2.2 像素吞吐和编码能力要成对看，别被单项参数带偏
输入能力决定“能不能接”，编码能力决定“能不能存和传”。CV 系列的编码组合差异比输入差异更隐蔽，我把它整理成对照：
| 型号 | 主编码 | 副编码 | 附加编码 |
|---|---|---|---|
| CV28S33M | 3Mp30 HEVC | 720p30 HEVC | 3Mp1 MJPEG |
| CV22S55 | 5Mp30 HEVC | 1080p30 HEVC | 5Mp4 MJPEG |
| CV22S66 | 4Kp30 HEVC | 1080p30 HEVC | 4Kp4 MJPEG |
| CV22S88 | 9Mp30 HEVC | 720p30 HEVC | 9MP 鱼眼视图 HEVC |
| CV25S33 | 3Mp30 HEVC | 720p30 HEVC | 3Mp4 MJPEG |
| CV25S88 | 4Kp30 HEVC | 480p30 HEVC | 4Kp1 MJPEG，鱼眼编码至 9MP |
| CV2S55 | 5Mp30 HEVC | 1080p30 HEVC | 5Mp4 MJPEG |
| CV2S66 | 4Kp30 HEVC | 1080p30 HEVC | 4Kp4 MJPEG |
| CV2S88 | 4Kp60 / 8Kp15 | — | 鱼眼编码至 9MP |
看这张表要抓两个细节。第一，副编码的规格决定了你能否同时出主码流和子码流，做远程预览和本地存储分离的方案，副码流至少 1080p30 才够用，CV25S88 的副码流只有 480p30，做双流产品就要掂量。第二，MJPEG 的帧数（那个 p4、p1）是抓拍和事件回传用的，CV22S66 的 4Kp4 MJPEG 意味着 4K 分辨率下每秒能出 4 帧 JPEG，做报警抓拍够用；CV25S88 只有 4Kp1，抓拍场景就得降分辨率。我见过有团队只看 HEVC 主编码参数下单，结果产品要求“事件触发时 4K 抓拍连拍”，样机阶段才发现 MJPEG 帧数不够，这就是没成对看编码能力的代价。
2.3 内存位宽和容量：AI 模型部署的真正天花板
嵌入式 AI 这块，TensorFlow 和 Caffe 训练出来的模型最终要量化、裁剪后跑在 CVflow NPU 上，而 NPU 的算力发挥受内存带宽制约非常明显。CV 系列的内存配置分三档：
| 内存档位 | 位宽/频率 | 容量 | 代表型号 |
|---|---|---|---|
| 16-bit 1.296GHz | 窄位宽 | 1GB | CV28S33M |
| 32-bit 1.6～1.8GHz | 中位宽 | 2GB | CV22 全系、CV25 全系 |
| 64-bit 1.269～1.56GHz | 宽位宽 | 4GB | CV2 全系 |
我的经验是：跑轻量检测模型（比如 mobilenet 级别的分类或小目标检测），2GB/32-bit 够用；一旦要跑多模型并行、或者模型输入分辨率上到 1080p 以上，64-bit 位宽的 CV2 系列优势就出来了，因为特征图和权重搬运的带宽压力摆在那。CV28S33M 的 16-bit 1GB 是入门配置，适合单一轻量模型加基础 ISP 功能，别指望它扛复杂网络。这里提醒一句，Flash 全系都是 NAND 最大 128GB，SD 控制器 CV28 和 CV25 是 3 个、CV22 和 CV2 是 2 个，做本地大容量循环录像的产品，SD 控制器数量会影响你能不能做双卡冗余。
3. 逐项对比：ISP、接口、安全特性怎么拉开差距
3.1 ISP 功能全系一致，差异在“同时开启时的余量”
CV 系列的 ISP 功能列表看起来高度统一：AE、AWB、GC、IS、Dewarp、HDR、3DMCTF，四个系列都有。但功能“有”和“能同时开且不掉帧”是两回事。我的判断方法是看像素吞吐余量：ISP 的 HDR 和 3D 降噪都是吃带宽的大户，CV28S33M 只有 200MPixel/s，接 3Mp30 主摄时余量本就不大，HDR 加 Dewarp 再叠 3DMCTF，基本就是贴着上限跑；CV22S66 的 540MPixel/s 接 4Kp30，余量明显宽裕，多开几个 ISP 模块更从容。
具体到调试，我一般会这么验证：先把目标分辨率、帧率、所有要开的 ISP 模块列成清单，在 EVB 上逐项叠加开启，用帧率计数和内存占用做记录，找出第一个掉帧的组合点。这个“叠加测试”比看规格表可靠得多，因为规格表不会告诉你 HDR 和 Dewarp 同时开时的实际吞吐折损。Dewarp 对鱼眼校正很关键，CV22S88 和 CV25S88、CV2S88 都标了 9MP 鱼眼编码能力，做鱼眼产品的直接锁定这几个型号，别在低吞吐型号上硬做。
3.2 视频输出接口：多屏和模拟输出的分水岭
输出这块差异比输入更影响产品形态。CV28S33M 是 1 路输出（MIPI DSI / MIPI CSI-2 / FPD / 模拟输出四选一），CV22 是 2 路（1 路 HDMI VOUT + 1 路 MIPI DSI），CV25 是 2 路（1 路并行/MIPI DSI/FPD-Link + 1 路模拟/MIPI CSI-2/HDMI/SLVS OUT），CV2 是 2 路（1 路数字/MIPI DSI/FPD + 1 路模拟/MIPI CSI-2/HDMI/SLVS OUT）。
差别在哪？做带本地屏回显的产品，CV22 的 HDMI VOUT 是现成的；做需要模拟视频输出的老设备兼容场景，CV25 和 CV2 那路模拟输出就派上用场；CV28 只有一路且要在四种里选，接了 DSI 屏就没法再出模拟信号。我踩过的坑是早期用 CV28 做双屏方案，以为能一路 DSI 一路模拟，翻规格才发现是四选一，只能改单屏。选型时把“要同时出几路、每路什么类型”写死，再对表，能省一轮改板。
3.3 通用接口与 GPIO 数量：外设扩展的隐性成本
UART、I2C、SPI、PWM、GPIO 这些看着琐碎，但外设一多就见真章。CV28S33M 是 UARTx4、I2Cx5、GPIOx93；CV22 是 UARTx5、I2Cx4、GPIOx160；CV25 各型号在 UARTx3～x5、I2Cx3～x4、GPIOx74～x108 之间浮动；CV2 是 UARTx5、I2Cx4、GPIOx166。
做多 sensor 加补光灯、云台、雷达、报警输入输出的产品，GPIO 数量直接决定要不要外加 IO 扩展芯片。CV25S55M 只有 GPIOx74，接三路 sensor 的复位、时钟使能、补光灯、云台电机控制，很快就见底；CV22 和 CV2 的 160 以上就宽裕很多。我的做法是画一张外设引脚预算表，把每个外设占用的 UART/I2C/GPIO 数量列出来，留 20% 余量，再对型号。这个表在原理图评审时能直接堵住“引脚不够临时加扩展芯片”的返工。
3.4 安全特性和工艺温度：全系同底，别在这上面纠结
安全特性四个系列完全一致：OTP、ARM TrustZone、I/O Virtualization。做需要安全启动、密钥存储、外设隔离的产品，这套组合是够用的，选型时不用在系列间比这块。工艺全是 10nm，工作温度全是 -25～85℃（原文写作 25~85，按工业级惯例理解为含负温区间，实际以规格书为准）。这意味着温度等级不构成系列间的选择差异，如果你的产品要更宽温，那不是换系列能解决的，得走专门的车规或工业级料号，规格表里没有的不要自己脑补。
4. 避坑与排查：选型阶段最容易翻车的五件事
4.1 把像素吞吐当“每路都能跑满”
现象：按总吞吐除以路数规划每路分辨率，样机跑多路时帧率不达标。原因：像素吞吐是 ISP 和输入通道的总处理能力，多路并发时还有调度和带宽竞争开销。解决：列出每路实际像素需求加总，留 15%～20% 余量，并在 EVB 上做多路并发实测，别用除法估算。
4.2 忽略副码流和 MJPEG 帧数
现象：双流产品远程预览卡顿，或事件抓拍连拍不够。原因：只看了主编码 HEVC 参数，没核对副码流分辨率和 MJPEG 帧数。解决：把主码流、副码流、抓拍三组需求分别对表，CV25S88 这类副码流 480p30 的型号要提前评估是否够用。
4.3 内存位宽没跟上模型规模
现象：NPU 利用率上不去，推理延迟比预期高。原因：选了 16-bit 1GB 的入门配置却跑较大模型，带宽成为瓶颈。解决：按模型输入分辨率和是否多模型并行选内存档，1080p 以上输入或多模型并行优先 64-bit 的 CV2 系列。
4.4 输出接口“四选一”当成“全都能出”
现象：双屏或屏加模拟输出方案无法实现。原因：CV28 的输出是四选一，不是四路并行。解决：把输出路数和类型写进需求表，CV28 只适合单路输出场景，多路输出看 CV22/CV25/CV2。
4.5 GPIO 和外设引脚预算不足
现象：原理图后期发现引脚不够，临时加扩展芯片增加成本和面积。原因：没做引脚预算表，低估了多 sensor 加外设的占用。解决：立项时做外设引脚预算，留 20% 余量，GPIO 低于 100 的型号（如 CV25S55M）要重点核对。
5. 落到结论：按场景圈型号，附一份可抄的决策顺序
把上面的维度收拢，我给一套可以直接照着走的决策顺序，这也是我每次做 CV 系列选型时强制自己走一遍的流程。
第一步，定输入。几路 sensor、每路分辨率和帧率、总像素吞吐，先按第 2 章那张输入表砍掉不满足的系列。六路环视直接锁 CV2；主摄加画中画锁 CV25；高分辨率单双路锁 CV22；成本敏感的简单三路看 CV28。
第二步，定编码。主码流要 4K 就看 CV22S66、CV25S88、CV2S66、CV2S88；要 9Mp 鱼眼就看 CV22S88、CV25S88、CV2S88；双流产品核对副码流，避开副码流过低的型号。
第三步，定内存。轻量单模型 2GB/32-bit 够，多模型或高分辨率输入上 4GB/64-bit 的 CV2。
第四步，定接口。输出路数和类型、GPIO 预算、SD 控制器数量，逐项对表，留余量。
第五步，上 EVB 做叠加实测。把 ISP 模块全开、多路并发、目标模型跑起来，看帧率和内存，这一步不能省。
按这个顺序，几个典型场景的结论很清晰：多路环视和拼接选 CV2S66 或 CV2S88，前者 4Kp30 够用，后者要 4Kp60/8Kp15 才上；高分辨率单主摄加 AI 检测选 CV22S66，540MPixel/s 加 4Kp30 编码加 2GB 内存是均衡点；主画面加画中画的多画面产品选 CV25S66 或 CV25S88，三路输入加双路输出是它的主场；成本敏感的入门智能相机选 CV28S33M，但要把 ISP 叠加和模型规模控制在它的余量内。
最后说个具体技巧：把这份规格表转成一张自己的“需求-型号”矩阵，行是输入路数、主编码、副编码、内存位宽、输出路数、GPIO 数量，列是候选型号，每个需求格填硬性门槛，超门槛的标红。这张矩阵我每次评审都带着，比翻原始规格表快得多，也能当场堵住“这个参数应该够吧”的模糊判断。回过头看，那次 CV22S88 换板的教训，根子就是没把 ISP 叠加余量放进矩阵里。从那以后我每次选型都强制走一遍“需求矩阵加 EVB 叠加实测”，再漂亮的单项参数也先放一放。希望帮到你。
本文还有配套的精品资源，点击获取
