191、NPU的编译器开发：量产测试与良率分析凌晨三点，产线反馈回来一批NPU芯片在跑某个特定卷积层时，输出结果全部偏移了2个LSB。我盯着示波器上的波形，发现MAC阵列的某个乘法器在输入为0x7F时，输出总是比理论值少1。这不是算法问题，是芯片物理缺陷在特定数据模式下的“显影”。量产测试，本质上就是一场和物理世界的不完美性进行的博弈。从“坏片”反推编译器测试策略那批芯片的失效模式很诡异——只在INT8量化模式下出错，FP16完全正常。排查了三天，发现是某个SRAM bank的地址译码器在特定地址范围存在建立时间违例。编译器在生成代码时，恰好把那个卷积层的权重映射到了这个bank的“雷区”。这件事让我意识到：NPU的编译器测试，不能只盯着功能正确性。你得把芯片的物理特性当成测试用例的一部分。我们后来在编译器里加了一个“物理感知”的测试模式——强制编译器生成能覆盖所有SRAM bank、所有MAC单元、所有数据路径的指令序列。这不是为了跑分，是为了让每个晶体管都在量产测试中“亮个相”。测试向量的“毒性”设计量产测试向量和普通benchmark有本质区别。普通benchmark追求性能，测试向量追求“暴露问题”。我见过最狠的测试向量，是专门让MAC阵列的进位链产生最长路径延迟的——把输入数据设计成0x7F和0x80交替，让加法器在正负边界反复横跳。写测试向量时有个血泪教训：别用随机数。随机数会掩盖很多边界情况。我们团队早期用随机数据做测试，良率虚高，到了客户手里批量出问题。后来改成“结构化毒性数据”——每个测试向量都针对一个已知的物理
191、NPU的编译器开发：量产测试与良率分析
191、NPU的编译器开发：量产测试与良率分析凌晨三点，产线反馈回来一批NPU芯片在跑某个特定卷积层时，输出结果全部偏移了2个LSB。我盯着示波器上的波形，发现MAC阵列的某个乘法器在输入为0x7F时，输出总是比理论值少1。这不是算法问题，是芯片物理缺陷在特定数据模式下的“显影”。量产测试，本质上就是一场和物理世界的不完美性进行的博弈。从“坏片”反推编译器测试策略那批芯片的失效模式很诡异——只在INT8量化模式下出错，FP16完全正常。排查了三天，发现是某个SRAM bank的地址译码器在特定地址范围存在建立时间违例。编译器在生成代码时，恰好把那个卷积层的权重映射到了这个bank的“雷区”。这件事让我意识到：NPU的编译器测试，不能只盯着功能正确性。你得把芯片的物理特性当成测试用例的一部分。我们后来在编译器里加了一个“物理感知”的测试模式——强制编译器生成能覆盖所有SRAM bank、所有MAC单元、所有数据路径的指令序列。这不是为了跑分，是为了让每个晶体管都在量产测试中“亮个相”。测试向量的“毒性”设计量产测试向量和普通benchmark有本质区别。普通benchmark追求性能，测试向量追求“暴露问题”。我见过最狠的测试向量，是专门让MAC阵列的进位链产生最长路径延迟的——把输入数据设计成0x7F和0x80交替，让加法器在正负边界反复横跳。写测试向量时有个血泪教训：别用随机数。随机数会掩盖很多边界情况。我们团队早期用随机数据做测试，良率虚高，到了客户手里批量出问题。后来改成“结构化毒性数据”——每个测试向量都针对一个已知的物理
