🔀 第3课:为什么搞两条线?—— Target B vs Target D

MiniCpm5 最聪明的工程决策:两条并行推进的验证主线,一条"快糙猛"验证概念,一条"精细深"推进真实实现。

🎯 本课目标

理解渐进式开发的智慧——为什么先做小词表 RTL 再做 VU19P HLS,两条线各自验证了什么,各自有什么局限性。

一、双线策略全景

Target B 和 Target D 的分工

flowchart TB SW["🎯 软件模型评估
balanced_ff2_kv2配置
9.18M参数, 512KB KV cache"] --> B["🔧 Target B: 小词表RTL
hidden=512, vocab=256
手写Verilog + Icarus仿真"] SW --> D["🚀 Target D: VU19P HLS
hidden=1536, window=1024
Vitis HLS + C/RTL Cosim"] B --> B1["验证: 控制形状
token-step bridge
top-select overlay
fallback安全切换"] B --> B2["局限: toy规模
非生产量化
未接入dispatch"] D --> D1["验证: INT4量化
32路并行MAC
完整证据链闭环
Python→CSim→Cosim→IP drop"] D --> D2["局限: 窗口化
cosim仅部分通过
未上真实板卡"] style SW fill:#3987e5,color:#fff style B fill:#c98500,color:#000 style D fill:#199e70,color:#fff

二、Target B —— "快糙猛"验证概念

思路:把模型缩到最小(hidden=512, vocab=256),用最简单的方式(手写 RTL)验证"从 hidden 到 token"这个核心链路能不能走通。规模小 → 仿真快 → 可以快速迭代。

验证了什么:

三、Target D —— "精细深"推进真实实现

思路:用接近真实模型的规模(hidden=1536),VU19P FPGA 上跑 INT4 量化的 HLS——这才是真正要交付的东西。但规模大 → 仿真慢 → 需要更严格的验证流程。

Target D 的完整证据链

flowchart LR A["🐍 Python Golden
参考基准: token=10"] -->|"一致"| B["🔧 HLS CSim
C++仿真: token=10"] B -->|"通过"| C["🏗️ HLS CSynth
综合: DSP=64, FF=15431"] C -->|"通过"| D["⚡ C/RTL Cosim
周期精确: 59781 cycles"] D -->|"通过"| E["📦 IP Drop
封装: 源码+RTL+报告"] E -->|"通过"| F["🔗 ichip2 wrapper
集成: AXI-Lite+BRAM"] style A fill:#3987e5,color:#fff style F fill:#0ca30c,color:#fff

四、对比总结

维度Target B (RTL)Target D (HLS)
规模hidden=512, vocab=256hidden=1536, window=1024
实现手写 VerilogVitis HLS C++
量化INT8 toyINT4 weights + INT8 hidden
Goldentoken=4, logit=8047token=10, logit=-5483
仿真速度131,073 cycles (Icarus)59,781 cycles (Cosim)
主要价值控制形状验证量化精度验证
当前阻塞dispatch 未接入Cosim 部分通过, 板卡不可见

五、ZCU106 板级状态

bitstream(WNS=4.414ns, TNS=0ns)、ELF、BOOT.BIN、SD payload 全部就绪。但因 JTAG 不可见(no_jtag_targets_enumerated)无法 program 真实板卡。板级验收(board_pass_claim_allowed)仍为 false。