一、课程导论：什么是硬件加速器？为什么需要性能建模？瓶颈分析的核心目标
1.1 硬件加速器到底是什么？
先问大家一个问题：你手头的手机、电脑里，CPU 是不是什么活都干？
其实不是。CPU 是个「通才」，什么都能做，但做什么都不算快。真正让视频解码、AI 推理、图像渲染飞起来的，是那些藏在芯片里的专用模块——硬件加速器。
硬件加速器，说白了就是为特定任务量身定做的计算引擎。它不像 CPU 那样需要取指令、译码、乱序执行，而是直接用硬连线把算法「固化」下来。
举个例子：
- GPU：为图形渲染和矩阵运算而生
- NPU：专门跑神经网络推理
- 视频编解码器：硬解 H.264/H.265
- 加密加速器：AES/RSA 运算比 CPU 快几个数量级
核心观点：硬件加速器的本质是「用面积换效率，用专用换性能」。
我个人习惯把加速器比作「特种兵」。CPU 是普通步兵，什么仗都能打；加速器是爆破专家、狙击手，只干一件事，但干得又快又好。
1.2 为什么需要性能建模？
你想想看，一个加速器从设计到流片，周期少则半年，多则两年。如果等到 RTL 写完了才发现性能不达标，那代价就太大了。
性能建模，就是在芯片还没造出来之前，先用数学模型或软件模拟器估算它的性能。
为什么要做这件事？三个理由：
- 早期决策：架构选型阶段，用模型跑一遍，就知道方案行不行
- 设计空间探索：缓存多大？并行度多高？一拍脑袋不如跑模型
- 瓶颈预判：哪里会成为瓶颈，模型会提前告诉你
我的经验：我曾经在一个 AI 加速器项目中，建模阶段发现内存带宽是瓶颈。如果等到 RTL 完成再改，至少要多花 3 个月。模型帮我省了这 3 个月。
嗯，这里要注意：性能模型不是万能的。它只能给出「近似值」，但足够指导架构决策。
1.3 瓶颈分析的核心目标
瓶颈分析，说白了就是找「最短的那块木板」。一个加速器的性能，往往被最慢的环节拖死。
常见的瓶颈有哪些？
| 瓶颈类型 | 典型表现 | 影响 |
|---|---|---|
| 计算瓶颈 | ALU 利用率 100%，其他单元空闲 | 吞吐量上不去 |
| 存储瓶颈 | 缓存 miss 率高，数据供不上 | 计算单元空等 |
| 通信瓶颈 | 总线带宽打满，延迟飙升 | 多核扩展性差 |
| 控制瓶颈 | 调度器成为串行点 | 并行度受限 |
瓶颈分析的核心目标就三个：
- 定位：找到限制性能的具体模块
- 量化：这个瓶颈让性能损失了多少？
- 消除：给出改进方案，并验证效果
避坑指南：我曾经犯过一个错误——只盯着计算单元优化，结果发现存储带宽才是真瓶颈。优化了半天计算，性能纹丝不动。记住：先找对瓶颈，再动手优化。
1.4 知识体系总览
下面这张图，是我梳理的本章知识结构。它把硬件加速器、性能建模、瓶颈分析三者的关系串了起来。
这张图想表达的是：硬件加速器是对象，性能建模是手段，瓶颈分析是方法。三者形成一个闭环——你设计一个加速器，建模仿真，找到瓶颈，优化设计，再建模验证。
1.5 一个真实案例
我记得有一次做视频编码加速器。团队一开始觉得计算单元越多越好，堆了 64 个处理单元。
结果呢？
建模一跑，发现内存带宽只能喂饱 32 个单元。剩下 32 个单元大部分时间在空转。
这就是典型的「计算与存储不匹配」瓶颈。后来我们把处理单元减到 32 个，省下来的面积做了更大的缓存，整体吞吐量反而提升了 40%。
教训：性能建模不是事后诸葛亮，而是事前诸葛亮。没有模型，你就是在黑暗中开枪。
1.6 小结
这一章我们聊了三件事：
- 硬件加速器是专用计算引擎，用面积换效率
- 性能建模让你在流片前就能预知性能
- 瓶颈分析帮你找到真正的短板，而不是瞎优化
嗯，内容不多，但都是基本功。后面的章节，我们会深入每个环节，从建模方法到工具使用，再到实战案例。
准备好了吗？我们开始吧。