Anlogic Create Bitstream

Anlogic FPGA Bitstream Generation Skill

把已放行的 *_pr.db 推进到 bitstream 阶段交付物，并只对 bitgen 及其紧邻的 debugger/参数导出收尾负责。

依据 TD 6.2.1 官方脚本：

• DefaultFlow.tcl 的最后阶段是 bitgen_fun
• PRFlow.tcl 也是在 opt_route 后才进入 bitgen
• MultiSeed.tcl 同样把 bitgen 放在 opt_route 之后

因此，本 skill 的边界固定为：

• 上游输入是已放行的 *_pr.db、route 状态和可选 probe/debugger 配置
• 本阶段交付是 .bit、可选 .bid、.bitgen_param.f 以及 debugger/probe 相关可复用产物
• 本阶段不负责重新证明 route 成功，不负责 Flash/SRAM 下载、SVF、AJE 或板级 bring-up

核心边界

本 skill 负责

• 确认 bitgen 阶段是否真正闭环
• 判断失败点属于前置 *_pr.db、bitgen 参数、外部文件、probe/debugger 还是权限/路径
• 输出 .bit、.bid、.bitgen_param.f 是否为本轮有效交付
• 输出 bitgen marker、日志与产物的一致性结论
• 判断是否允许把结果交给 anlogic-download 或后续调试流程

本 skill 不负责

• 不负责重新证明 opt_route 是否健康收敛，除非上游 *_pr.db 明显失效
• 不负责等待下载结果、SVF/AJE 产物或板上行为
• 不负责把“bit 文件存在”误写成“已经成功下载并板上可用”
• 不负责替 BitWriter、ChipLinker、Flash/SRAM 下载背锅

默认停止线

满足下面任一条件，就应停在 bitstream 阶段给出结论，而不是继续无效等待：

• 当前阶段日志或 .error.f 已表明 bitgen / debugger 收尾失败
• 关键交付 .bit、.bitgen_param.f 或本轮 .bitgen.end.f 缺失
• 问题已经越界到下载、SVF、AJE、Flash/SRAM 或板级现象

上游输入与下游交付

上游最小输入

• 来自 anlogic-place-route 的有效 *_pr.db
• route_flow.status 与关键 route 时序结论
• 工程入口：.prj 或当前 phy_1 run
• 可选 cpcList / probe 配置
• 当前 run 的日志、marker 和 bitgen 目录产物

本阶段最小交付

• *.bit
• 可选 *.bid
• .bitgen_param.f
• 若启用调试：cw/compiled.cwc 或同类 debugger/probe 产物
• 阶段级结论：bit 是否为本轮新产物、是否具备进入下载/调试的前提

下游如何消费

• anlogic-download 消费的是 bitstream 及其下载交付需求，不负责生成 .bit
• anlogic-debug 消费的是下载后或在线调试阶段现象，不负责替 bitgen 产物补齐

这意味着：

• 只要目标是 SVF、AJE、SRAM/Flash 下载，就不能继续停在 bitstream skill
• 只要 .bit 或 .bitgen_param.f 还不可信，就不能把问题推给下载阶段

官方脚本对应的真实边界

DefaultFlow.tcl

bitstream 阶段真实命令顺序是：

1. bitgen_fun
   • commit_param -step bitgen
   • 条件式 import_chipprobe_config
   • 条件式 compile_probe
   • bitgen -bit $prj_name.bit
   • setup_debugger
   • export_bitgen_param -file .bitgen_param.f

关键结论：

• bitgen 是 bit 文件的核心生成动作
• setup_debugger 与 export_bitgen_param 是 bitstream 阶段内部收尾动作，不是下载阶段动作
• route 之前的任何产物都不属于本阶段交付

PRFlow.tcl

PR bitgen 流说明：

• bitgen 仍在 export_db ${prj_name}_pr.db 之后执行
• export_bitgen_param -file .bitgen_param.f 仍在本阶段导出

关键结论：

• PR 场景下，bitstream 的输入仍是 route 之后的数据库
• 如果 static_pr.db、*_pr.db 或 route 交付不完整，不应直接推进 bitgen

MultiSeed.tcl

它说明 bitgen 是 seed 物理实现的下游而不是其一部分：

• opt_place、opt_route 后才 bitgen -bit
• 随后 setup_debugger

关键结论：

• 即便 multi-seed 有多个结果，bitstream 仍只消费已确定的 route 结果
• 不应因为还在比较 seed 结果就混淆 bitgen 的输入基线

工作流程

1. 先确认是不是 bitstream 问题

只有当问题仍落在下面几类时，才留在本 skill：

• bitgen
• setup_debugger
• export_bitgen_param
• export_bid
• import_chipprobe_config
• compile_probe

如果用户已经在问：

• Flash / SRAM 下载
• SVF / AJE
• BitWriter / ChipLinker
• 板卡上电后行为

那已经越过本 skill 边界，应切到 anlogic-download 或 anlogic-debug。

2. 找到真实 bitgen run 入口

• 优先读取 phy_1 目录里的 Tcl、bat、日志、marker 与 bitgen 产物
• 优先相信 run 目录中的实际执行脚本，而不是 GUI 名称
• 若存在多个 run，先用时间戳和日志增量锁定当前 run

3. 先判前置，再判阶段，再判交付

固定检查顺序：

1. 前置是否正确
   • *_pr.db 是否来自本轮 route、route 结论是否允许 bitgen
2. 阶段是否闭环
   • bitgen
   • setup_debugger
   • export_bitgen_param
3. 交付是否成立
   • .bit
   • .bid
   • .bitgen_param.f
   • compiled.cwc

4. 给出放行或停线决定

最终结论必须显式二选一：

• 允许放行到 anlogic-download / 后续下载调试
• 停留在 anlogic-create-bitstream 修复

不要给模糊说法，例如“bit 看起来应该能用”。

阶段判断规则

bitgen 前置检查

重点确认：

• *_pr.db 是否为本轮 route 产物
• route_flow.status 是否支持放行
• 若目标包含在线调试，probe 配置是否齐全

常见失败归因：

• route 虽然导出了 db，但未真正放行
• 旧 *_pr.db 被重复使用
• probe 配置与本轮设计不匹配

bitgen

重点确认：

• bitgen -bit <name>.bit
• 是否显式启用 -compress、-security、-cfg_file、-dispersed 等选项
• .bit 是否为本轮新产物

常见失败归因：

• bitgen 参数与器件/模式不匹配
• 输入文件、RAM 初始化文件或设备数据异常
• 路径或权限问题

交付要求：

• .bitgen.end.f 存在
• .bit 为本轮有效产物

debugger / 参数收尾

重点确认：

• import_chipprobe_config
• compile_probe
• setup_debugger
• export_bitgen_param -file .bitgen_param.f

常见失败归因：

• probe 配置指向旧文件
• compile_probe 没有执行或输出不完整
• setup_debugger 被跳过
• 只生成了 .bit，但调试复用链路缺失

交付要求：

• .bitgen_param.f 存在
• 若启用调试，相关产物存在且与本轮一致

Marker、错误与等待规则

关注这些文件：

• .bitgen.begin.f
• .bitgen.end.f
• .bitgen.error.f

等待规则：

• 若出现 .bitgen.error.f，直接按当前阶段失败处理
• 若日志出现 ERROR、FATAL、failed、cannot、unable to、minidump，且 .bitgen.end.f 未生成，不继续等
• 若只有 .bitgen.begin.f 没有 .bitgen.end.f，并且日志、.bit、.bid、.bitgen_param.f 连续两轮都无变化，按卡住或异常中断处理
• 不因为“后面还要下载验证”而延长 bitgen 阶段等待

明确禁止的无效动作

• 因为板上还没验证就继续停在 bitstream skill
• 因为下载失败就直接回头否定 bitgen 成功，除非 bitstream 交付本身缺失
• 只看目录里有旧 .bit 就宣告本轮 bitgen 成功
• 只保留 .bit，忽略 .bitgen_param.f、.bid 或 debugger/probe 产物
• 把 BitWriter / ChipLinker 的职责混进 bitgen 结论

输出要求

完成任务时至少给出：

• 当前问题属于 bitgen、debugger/probe 收尾，还是已经越界到下载/调试
• .bit、.bid、.bitgen_param.f 是否已生成且是否为本轮有效交付
• marker 是否闭环，是否存在 .bitgen.error.f
• 是否具备进入 anlogic-download 或后续调试的前提
• 若不具备，最小修复动作是什么

与其他 skills 的联动

• 上游通常来自 anlogic-place-route
• 若问题回溯到 route 未放行或 pr.db 无效，回切 anlogic-place-route
• 若进入 SRAM/Flash 下载、SVF、AJE、BitWriter/ChipLinker，切到 anlogic-download
• 若进入板级下载、在线调试或 bring-up 现象排查，联动 anlogic-debug
• 若确认了稳定的 bitgen 参数模板、器件特有限制或 debugger 约束，联动 anlogic-learnings

需要时再读取的 references

• 读取 references/td-bitstream-flow.md
  • 当需要查看官方脚本里的命令顺序、产物定义、上下游关系和停线规则时
• 读取 references/td-bitstream-warning-playbook.md
  • 当日志出现 BIT-*、RAM 初始化、权限/路径、PCIe bit 配置等高频告警时

约束

• 不要把 route、下载动作写进 bitgen 结论
• 不要把“有 bit 文件”直接等同于“板上已成功运行”
• 不要只报现象，必须给阶段、证据、交付状态和最小修复动作
• 对 -compress、-security、-cfg_file、probe/debugger 相关选项要显式标注，不要凭习惯假设已启用