关注公众号，点击公众号主页右上角“ · · · ”，设置星标，实时关注旺材芯片最新资讯
芯片 Bring-up 是 Tapeout 之后，团队基于真实硅片、封装、板卡和底层软件，完成首次系统启动、状态确认和故障定位的过程。它的目标不是立即证明芯片完全正确，而是先建立一个可供控制、观察和继续验证的基础环境。
一、Bring-up 发生在什么阶段？
芯片研发通常会经历架构定义、RTL 设计、流片前验证、综合实现、物理设计、Tapeout、晶圆制造、封装测试、板级集成、硅后验证和量产导入。Bring-up 发生在芯片回片早期。此时团队面对的已经不是仿真模型、Emulation 平台或 FPGA Prototype，而是真实硅片。
在仿真环境中，工程师可以查看大量内部波形，逐拍分析信号变化。FPGA Prototype 能够提前运行部分系统路径和软件栈，但在频率、电气特性、PHY、功耗和工艺行为上，仍然与真实芯片存在明显差异。到了 Bring-up 阶段，设计假设会第一次同时受到真实物理条件的检验。电源质量、参考时钟、封装连接、PCB、温度、噪声、工艺偏差和软件初始化顺序，都可能影响芯片是否能够正常启动。
二、Bring-up 和其他验证活动有什么区别？
芯片项目中，流片前验证、FPGA Prototype、Bring-up、硅后验证和量产测试经常被放在一起讨论，但它们关注的问题并不相同。
Bring-up 通常是硅后验证的起点。它不会一开始就覆盖所有性能和可靠性指标，而是先打通继续验证所需的基础条件。如果 JTAG 无法访问、BootROM 没有执行、片上 SRAM 不可用，或者 DDR 初始化完全失败，后续的接口验证、性能测试和系统软件调试都无法正常展开。不同公司的流程划分可能略有差异，但 Bring-up 的核心任务基本一致：先让真实芯片进入一个可以继续工作的状态。
三、Bring-up 通常怎样展开？
真实项目中的 Bring-up 很少完全按照流程图推进，但整体上都会遵循一条相似的主线：从风险最低、最容易观察的部分开始，逐步建立对芯片状态的信任。
1. 确认电源和板级状态
Bring-up 通常从电源开始。工程师需要检查各条电源轨的电压、上电顺序和电流曲线，观察是否存在异常漏电、短路或局部过热。这个阶段常用到电源分析仪、万用表、示波器和板级控制脚本。
在确认基本状态之前，团队通常不会直接让芯片进入全速运行。先在受控条件下观察电流、温度和复位状态，可以降低损坏芯片或板卡的风险。
2. 检查时钟和复位
电源状态基本可信后，下一步通常是确认参考时钟、PLL 和复位流程。PLL 是否锁定，复位是否在正确条件下释放，各个时钟域是否进入预期状态，都会影响芯片能否执行第一条有效指令。很多看起来像软件卡死的问题，最后会回到时钟或复位上。例如某个电源域尚未稳定，相关模块的复位却已经解除；或者参考时钟出现抖动，导致 PLL 偶发失锁。
3. 打通调试入口
JTAG、SWD、UART 和 trace 接口是 Bring-up 阶段最重要的入口。JTAG 无法连接时，问题未必出在 TAP 控制器本身。电源域、复位、管脚复用、板级连接和安全配置都需要排查。一旦调试入口可用，团队就可以读取芯片 ID、检查状态寄存器、访问片上存储，并逐步确认芯片内部已经运行到哪个阶段。
4. 建立最小执行路径
调试入口可用后，下一步是确认 BootROM、片上 SRAM 和最小固件是否能够执行。启动模式是否正确，strap 或 eFuse 配置是否生效，异常向量是否有效，片上存储能否读写，这些问题共同决定芯片能否从静态硬件状态进入软件控制状态。
串口打印出第一行日志，通常是一个重要节点，但距离完整启动还很远。它至少说明处理器、部分时钟、复位、存储和 UART 路径已经具备基本工作条件。
5. 打通启动介质、DDR 和基础外设
最小代码能够执行后，团队才会进一步处理片外 Flash、DDR 或 HBM、内存映射、中断控制器和基础外设。DDR training 通过并不代表存储子系统已经完全稳定。后续还要验证不同地址范围、访问宽度、突发传输、DMA、缓存一致性和长时间压力。GPIO、I2C、SPI、UART、timer 等基础外设通常会较早进入测试，因为它们可以帮助团队建立更多观测和控制手段。
6. 启动系统软件和关键数据路径
基础硬件路径稳定后，Bring-up 才会逐步进入 bootloader、RTOS 或 Linux 阶段。此时需要确认 device tree、内存映射、中断路由、驱动初始化和固件配置是否与真实硬件一致。之后再逐步打开 PCIe、Ethernet、USB、MIPI、SerDes、NPU、DSP 或视频处理链路等关键模块。
Bring-up 不要求所有模块一次性全部工作。更常见的做法是逐项启用，每增加一个子系统，就确认它没有破坏此前已经稳定的路径。
四、为什么 Bring-up 难？
Bring-up 最麻烦的地方，是一个简单现象可能对应完全不同的根因。例如：串口没有输出，可能是 BootROM 根本没有执行，也可能是时钟或复位异常，还可能只是管脚复用、波特率或板级连接配置错误。
在仿真环境中，这些状态通常可以通过波形区分；真实芯片默认没有这样的可见性。工程师只能依赖电流变化、JTAG 状态、启动进度码、错误寄存器和有限的 trace，一层层缩小范围。
问题跨层也是常态。PCIe 无法枚举时，根因可能来自控制器状态机、SerDes、参考时钟、复位、寄存器配置或主机兼容性。DDR training 失败，也可能与 PHY 参数、板级走线、供电、温度、固件配置和初始化顺序有关。这类问题很难由单个团队独立闭环。硬件、验证、固件、驱动、板级、封装、电源和测试团队通常需要同时参与。
另一个难点是问题不一定稳定复现。有些故障只会在特定电压、温度、频率或负载下出现；有些问题与上电间隔、初始化顺序或前一次运行状态有关。跑通一次只能说明在某次条件下成功，不能说明路径已经稳定。
因此，Bring-up 不只追求“能跑”，还要建立可复现、可记录、可解释的证据链。
五、Bring-up 的准备工作要在回片前完成
Bring-up 虽然发生在回片后，但调试能力往往在芯片设计阶段就已经决定。如果芯片缺少状态寄存器、错误记录、启动进度码、恢复模式和关键路径的观测能力，那么回片后即使问题出现，团队也很难快速判断故障范围。
可观测性
关键模块的状态寄存器； sticky error bit 和错误码； BootROM 和固件启动进度码； trace、事件计数器和性能计数器； 总线错误、中断状态和超时记录。
可控制性
安全启动模式和恢复模式； 最小启动路径； 对时钟、复位和电源域的调试控制； 可选择的启动介质和启动配置； 可在异常状态下保留的诊断信息。
测试与诊断能力
MBIST、LBIST、scan 等 DFT 机制； 固件诊断接口和寄存器访问工具； 板级自动化脚本； 可复用的启动测试； 日志收集和结果归档机制。
这些能力平时并不显眼，回片后却直接决定问题是几小时收敛，还是几周都停留在猜测阶段。
一个有效的调试设计，能够把“系统不工作”缩小为“某个电源域未进入状态”“某条总线访问超时”“某个启动阶段没有完成”或“某个 IP 报告协议错误”。范围缩小，才是真正的调试效率。
六、FPGA Prototype 能提前暴露哪些问题？
FPGA Prototype 无法复现真实硅片的 PLL、SerDes、DDR PHY、功耗、工艺和封装效应，但可以提前打通大量软件与系统路径。在回片前，团队可以通过原型平台验证：
启动流程是否完整； 固件和驱动对寄存器模型的理解是否正确； 中断、DMA 和内存映射是否能够跑通； Linux bring-up 是否存在明显阻塞； 基础运行负载是否能够执行； 日志格式、调试脚本和诊断工具是否可用。
这些工作不能消除真实硅片风险，但可以减少 Bring-up 阶段同时存在的未知数。如果启动流程、驱动初始化和基础软件路径已经在 FPGA Prototype 上跑通过，回片后遇到问题时，团队可以优先排查真实硅片特有的电气、时钟、PHY、封装和板级因素，而不必重新从整个软件栈开始怀疑。
最后总结一下，芯片 Bring-up 是在回片早期围绕真实硅片、板卡和底层软件展开的首次系统启动与故障定位。它通常从电源、时钟和复位开始，随后打通调试入口、最小执行路径、存储、基础外设、操作系统和关键数据链路。每完成一个阶段，团队就多一组可信状态，也能把后续问题限制在更小的范围内。
Bring-up 暴露的不只有 RTL 缺陷。电源、时钟、封装、PCB、固件、驱动、验证覆盖和调试规划，都可能在这个阶段接受检验。一次 Bring-up 的结果也会反过来影响下一版芯片：哪些状态需要增加观测点，哪些启动步骤需要加入进度码，哪些软件和系统路径应该提前放到 FPGA Prototype 上验证。
芯片能跑起来，只是第一步。能够稳定复现问题、快速缩小范围，并为后续硅后验证和软件开发提供可靠环境，才说明 Bring-up 真正取得了进展。
来源：芯语
专心 专业 专注
