1. 课程导入与全景认知
在FPGA与ASIC设计领域，高层次综合（High-Level Synthesis, HLS）让设计者可以用C/C++/SystemC描述算法，再自动生成可综合的RTL。然而，从算法到硬件的“翻译”并非无损：接口时序、流水线深度、数据类型位宽、存储器访问冲突，都可能让HLS生成的RTL与算法预期产生偏差。因此，HLS算法到RTL综合与C/RTL协同验证成为保证设计正确性的关键环节。
本课程围绕一条完整链路展开：算法建模 → HLS综合 → C仿真 → RTL仿真 → 协同验证 → 性能与资源评估。第1章先建立全景认知，明确学习目标、流程框架、典型场景与工具链，为后续深入各环节打下基础。
一、为什么需要HLS与RTL协同验证
HLS工具（如Vitis HLS、Catapult、Stratus）能把C函数综合为RTL，但综合结果受指令（pragma/directive）、目标时钟、接口协议影响极大。仅做C仿真只能验证算法功能，无法发现RTL层面的问题；仅做RTL仿真又难以快速定位是算法错误还是综合约束不当。协同验证的价值在于：
- 功能一致性：确认C仿真与RTL仿真结果一致，避免“算法对、硬件错”。
- 接口正确性：验证AXI4、AXI-Stream、ap_hs等接口的握手、时序与数据顺序。
- 性能可预测：通过II（Initiation Interval）、Latency、吞吐率判断是否满足设计指标。
- 资源可控：对比LUT、FF、DSP、BRAM消耗，指导指令调优。
- 早期发现缺陷：在RTL综合前用C/RTL联合仿真暴露位宽溢出、数组分区冲突等问题。
二、整体流程框架
下图给出本课程贯穿的流程框架：从C/C++算法出发，经过HLS综合生成RTL，再通过C仿真、RTL仿真与协同验证形成闭环。图中同时标出关键产物与判断节点。
三、典型应用场景与工具链概览
HLS与RTL协同验证广泛应用于图像处理、通信基带、AI推理加速、金融计算等领域。不同场景对吞吐率、延迟、资源的要求不同，验证侧重点也不同。
| 应用场景 | 典型算法 | 验证重点 | 常用工具链 |
|---|---|---|---|
| 图像处理 | 卷积、滤波、边缘检测 | 行缓存、数据流接口、吞吐率 | Vitis HLS + Vivado + OpenCV参考模型 |
| 通信基带 | FFT、LDPC、调制解调 | 定点精度、II、时序收敛 | Catapult + ModelSim/Questa |
| AI推理加速 | 矩阵乘、激活、量化 | 数组分区、DSP映射、带宽 | Vitis HLS + Vitis Analyzer |
| 金融计算 | 期权定价、风险模型 | 浮点/定点一致性、延迟 | Stratus + Incisive/Xcelium |
工具链通常包含三部分：HLS综合器（生成RTL与报告）、RTL仿真器（验证时序与接口）、协同验证框架（自动比对C与RTL结果）。以Vitis HLS为例，常用命令如下：
# 运行C仿真
vitis_hls -f run_csim.tcl
# 运行C/RTL协同仿真
vitis_hls -f run_cosim.tcl
# 查看综合报告
cat solution1/syn/report/csynth.rpt四、常见误区与复盘要点
初学者在HLS协同验证中常陷入以下误区：
- 只跑C仿真就认为万事大吉：C仿真通过不代表RTL正确，接口握手、位宽截断、数组分区都可能引入错误。
- 忽略接口协议：AXI-Stream的TREADY/TVALID握手若未正确建模，RTL仿真会出现死锁或丢数。
- 盲目追求II=1：过度展开循环会导致资源爆炸，需在吞吐率与面积之间权衡。
- 不做定点精度分析：浮点算法直接综合为定点后，误差可能超出系统容忍范围。
- 协同验证激励覆盖不足：边界值、随机激励、背压场景缺失，导致漏测。
复盘时建议记录：每次综合的指令配置、II/Latency/资源数据、协同验证通过率、失败用例的根因。这些数据是后续章节调优的重要依据。
五、本章学习目标
- 理解HLS与RTL协同验证在芯片设计流程中的位置与价值。
- 掌握从C算法到RTL生成的完整流程框架与关键产物。
- 熟悉典型应用场景与主流工具链的对应关系。
- 识别常见误区，建立“功能一致 + 性能达标 + 资源可控”的验证思维。
- 为后续章节的指令调优、接口建模、协同仿真脚本编写做好准备。