VENUS 2.0 LDPC 仿真复现学习记录

一、今天完成了什么

跑通 LDPC 的编译、L1 打包、RTL Cluster 仿真和 gem5 仿真，并验证两边的输出及执行时间。但具体流程原理，还不是很清楚

flowchart TD
    A["LDPC 源码：C + BAS"] --> B["DSL 调用定制 LLVM"]
    B --> C["dag1.bin + dag1.json"]
    C --> D["L1 工程：make venus"]
    D --> E["C 数组 + l1.elf"]
    E --> F["生成 SVH"]
    F --> G["VCS 编译 RTL 与 testbench"]
    G --> H["运行 simv"]
    E --> I["解析 ELF，生成 manifest"]
    I --> J["运行 gem5"]
    H --> K["比较完整输出与执行时间"]
    J --> K

二、各工程和文件的作用

工程／文件	作用
`VEMU/5g_lite/tasks/Venus2p0_LDPC`	存放 LDPC 的 C/BAS 源码
`VEMU/dsl`	组织源码处理、编译、打包和资源检查
`LLVM_PATH`	指向已编好的定制 LLVM 工具
`2psim-LDPC`	将任务数据转换为 C 数组并构建 L1 程序
`venus_soc`	RTL 硬件设计和测试平台
`ace-echo/components/gem5`	gem5 硬件模型
BIN / JSON	任务二进制内容／任务及数据描述
ELF	包含程序、数据和符号信息的链接产物
SVH	testbench 使用的 SystemVerilog 数据数组

关键区别： - venus-llvm-project 是编译器源码；LLVM_PATH 指向可执行工具。 - 本次没有重编 LLVM 或 gem5，使用了现有工具。 - 本次两条仿真路线都没有实际运行 L1 CPU：RTL 由 AXI BFM 加载数据，gem5 解析 ELF 中的任务信息。

三、关键操作与配置

flowchart LR
    A["准备 C/BAS 和头文件"] --> B["DSL 中 make"]
    B --> C["复制 BIN/JSON 到 L1"]
    C --> D["make venus"]
    D --> E["generate_cluster_case_svh.py"]
    E --> F["编译 RTL → simv"]

本次配置：

项目	配置
DAG	`Venus2p0_LDPC`
Tile 数	4
每个 Tile	16 lanes、128 rows
编译调度模式	`hazard`
Tile 时钟	500 MHz
AXI／Scheduler 时钟	250 MHz

原 DSL 默认值为 512 rows、chain_credit；本次通过 make 参数覆盖为学长已验证的配置。

四、VCS 环境与构建问题

flowchart TD
    A["RTL 构建失败"] --> B{"错误属于哪一类？"}
    B --> C["找不到 vcs/vlogan：检查工具路径"]
    B --> D["许可证错误：检查地址、服务、具体授权"]
    B --> E["找不到源码：检查文件位置和 SRC_DIR"]
    B --> F["缺少 MBIST：检查工具或生成缓存"]

本次设置了 VCS、许可证和 DesignWare/VIP 环境变量：

VCS_HOME、PATH：定位工具。
LM_LICENSE_FILE、SNPSLMD_LICENSE_FILE：指定 27000@localhost。
DESIGNWARE_HOME、SLI_USER_SLISERV_PATH：定位 VIP 组件和服务程序。

RTL 构建在独立副本中进行，并调整了旧文件列表路径、复制了学长保留的 MBIST 缓存，没有修改 RTL 设计逻辑。

五、复现结果与时间含义

指标	RTL	gem5
任务执行时间	67.520 μs	67.100 μs
500 MHz Tile 周期数	33,760	33,550
返回数据	384 字节	384 字节

RTL 日志出现 STRICT_TEST_PASS。
两边输出逐字节一致，比较结果 PASS。
gem5 比 RTL 少 210 周期，时间偏差约 −0.622%。
输出哈希和执行时间与学长记录一致。

flowchart LR
    A["分配任务"] --> B["搬入数据"]
    B --> C["开始执行"]
    C --> D["执行完成"]
    D --> E["返回 DMA"]
    E --> F["释放 Tile"]
    C -. "本次 runtime 的比较范围" .-> D

三个时间不能混淆：

任务 runtime：任务执行区间，不包含返回 DMA。
仿真结束时间：包含初始化、加载和结果读取等过程。
服务器耗时：现实中等待仿真完成的秒数。

六、产物保存在哪里

VEMU/dsl/                         ← LDPC 编译产物
2psim-LDPC/                       ← C 数组、L1 ELF/BIN
venus_soc/sim/model/L1_cluster_test/
                                  ← 生成的 SVH

bringup/ldpc-manual-20261013-195742/
├── rtl/                          ← RTL 副本、simv、仿真日志
├── semantic/                     ← gem5 输入
├── gem5/                         ← gem5 输出与统计
├── logs/                         ← 阶段日志
├── rtl-result.json               ← RTL 时间和结果
├── rtl-output.bin                ← RTL 返回数据
└── comparison.json               ← 最终对比报告

并非所有产物都在新目录中：前面的 DSL 和 L1 构建仍发生在原工程目录。

七、下一步：理解多 Tile 并行

四个 Tile 不代表四个都在工作。当前报告中的 LDPC Task 分配到了 Tile 0，后续要结合完整分配日志分析。

flowchart TD
    A["查看 task 分配日志"] --> B["确认任务数和依赖"]
    B --> C["确认每个任务使用哪个 Tile"]
    C --> D["观察执行区间是否重叠"]
    D --> E["固定工作量，对比 1/2/4 Tile"]
    E --> F["分析总完成时间与吞吐量"]

一个 Task 通常不会因增加 Tile 而自动拆分。
多个任务存在串行依赖时，也难以并行。
多个独立任务才有机会同时使用多个 Tile。
多核优势可能体现为吞吐量提高，而非单任务延迟降低。