FET^2 | Info Church X.

验证的开销已经超过设计的开销，比例可能已经达到7:1（1个设计工程师配7个验证工程师）

PPA+Productivity（我们用了多少精力去设计芯片）

84%的通过FPGA验证的设计都有各种未被发现的错误

静态验证：用数学推理穷尽所有可达状态

动态验证：用特定测试激励遍历部分状态

大规模CPU芯片仿真，1s只能仿真400-500 cycles。大规模GPU仿真1s只能仿真80cycles。按此计算，仿真1G cycles需要25d/3m。

Memory Access是瓶颈。打破仿真周期，用ILP建模（会有变量爆炸的问题）

硬件调试工具，允许加入断点、单步调试等

大模型发展：attention → decoder only自回归解码 → Scaling Law → MoE → 长上下文

KV cache：在自回归存储中，需要记录之前所有token的信息

访存带宽需求=(模型参数+KV cache)*tokens/s

MoE：总参数量变大，激活的参数量变小，总的访存带宽需求如何变化不太确定

假设Qwen3-14B 32K VLM需要每秒生成50 tokens，则需要1200GB/s的访存带宽

不再一次生成1个token，而是一次生成多个tokens

先预测出多个tokens的draft，然后去并行验证。如果运气好，可以增加并行度。

用较小的模型去生成draft

云端和边端任务异构，边端计算能力异构

用同态加密同时保护用户数据和模型参数

在MoE中，不同专家激活频率不同，其中可能包含用户隐私，需要加密保护

平衡各专家激活次数。对激活次数较多的专家，舍弃一部分不重要的token

垂直电流，源漏电极在上下，Gate环绕在沟道周围

energy efficiency = freq / pwr

需要在双边布设电源轨

关键问题：低功耗逻辑器件+低功耗存储器件+CMOS兼容工艺

TP(tensor parallel)：在单GPU中，每个专家被拆分到不同核中，并行运算。问题：同专家通信开销太大

EP(expert parallel)：一个专家放在一个core中。负载不平衡

在offline中进行硬件映射的优化

长上下文推理中的KV cache是稀疏的。不同attention head呈现出不同的稀疏性，3D异构集成（垂直集成memory和logic）一旦出现负载不均很难调整