Anlogic Synthesis

Anlogic FPGA Synthesis Flow Skill

把 TD 工程从 RTL 推进到综合交付物 *_gate.db，并只对 read_design -> opt_rtl -> opt_gate 三个阶段负责。

依据 TD 6.2.1 官方脚本：

• DefaultFlow.tcl 的完整流程是 read_design -> opt_rtl -> opt_gate -> opt_place -> opt_route -> bitgen
• SynIpFlow.tcl 只覆盖 read_design -> opt_rtl -> opt_gate
• MultiSeed.tcl 从 opt_place 才开始，直接消费上游生成的 *_gate.db

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

• 上游交付进来的是工程、器件上下文、源列表、约束和可执行的综合 run
• 本阶段交付出去的是可验证的 *_gate.db、面积/时序摘要和综合阶段状态结论
• 本阶段不拥有 place、route、bitgen、下载和板级调试

核心边界

本 skill 负责

• 确认 read_design、opt_rtl、opt_gate 是否真正闭环
• 判断综合失败点属于工程入口、顶层/源列表、约束、IP/primitive，还是 gate 阶段资源映射
• 输出是否生成了本轮有效的 *_gate.db
• 输出面积报告、gate 时序摘要、marker、flow.status 的一致性结论
• 判断是否允许把结果交给 anlogic-place-route 或其他下游流程

本 skill 不负责

• 不负责修 place/route 造成的拥塞、hold、时钟树或 DRC 问题
• 不负责等待 .place.end.f、.route.end.f、.bitgen.end.f
• 不负责 bit 生成、AJE/SVF、Flash/SRAM 下载
• 不负责把“综合已完成”误写成“实现已完成”

默认停止线

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

• 日志已出现明确失败，且当前阶段缺少 .end.f
• flow.status 已表明综合阶段失败
• *_gate.db 未生成或时间戳没有更新
• 问题已经落到下游物理实现或 bit 生成领域

上游输入与下游交付

上游最小输入

• 工程入口：.prj、.al 或 syn_1 run 目录
• 器件上下文：device_name、package_name、可选 speed
• 设计入口：top_model_name
• 源与约束：RTL/IP/netlist、ADCList、IpADCList、SDCList、IpSDCList
• 当前 run 的日志、marker、数据库和 flow.status

本阶段最小交付

• *_elaborate.db
• *_rtl.db
• *_gate.db
• *_rtl.area
• *_gate.ts
• *_gate.timing 或至少 *_gate.ts
• flow.status
• 阶段级结论：卡在哪个阶段、能否放行、最小修复动作是什么

下游如何消费

• anlogic-place-route 从 *_gate.db 开始，不应重新承担综合阶段诊断
• MultiSeed.tcl 在 prepare 中直接 import_db $parent/${prj_name}_gate.db
• PRFlow.tcl 的 opt_place 也依赖上游综合产物或静态 PR 数据库
• bitgen 依赖的是 route 后的 pr.db，不是综合阶段的 gate.db

这意味着：

• 只要目标是 place / route / bitgen 的结果，就不能继续在综合 skill 里等待
• 只要 gate.db 还不可信，就不能把问题推给下游

官方脚本对应的真实边界

DefaultFlow.tcl

综合阶段的真实命令顺序是：

1. prepare
   • import_device
   • open_project / open_project ... -noanalyze
   • 必要时 import_db
2. read_design_fun
   • commit_param -step design
   • elaborate -top
   • read_adc / read_ip_adc
   • read_sdc / read_sdc -ip
   • export_db ${prj_name}_elaborate.db
3. opt_rtl_fun
   • commit_param -step rtl
   • insert_debugger
   • optimize_rtl
   • report_area
   • export_db ${prj_name}_rtl.db
4. opt_gate_fun
   • commit_param -step gate
   • optimize_gate
   • legalize_phy_inst
   • update_timing
   • report_timing_status
   • report_timing_summary
   • flow_status -file flow.status
   • export_db ${prj_name}_gate.db

关键结论：

• flow_status -file flow.status 在 opt_gate 内就写出，是综合阶段自带的闭环证据
• export_db ${prj_name}_gate.db 是综合交付动作，不是 place-route 的预动作
• opt_place 之后才会产出 place_flow.status、*_place.db

SynIpFlow.tcl

这是最清晰的综合边界旁证：

• stepList 只有 read_design opt_rtl opt_gate
• opt_gate 里会额外执行
  • export_sdc_target
  • optimize_gate -ip ...
  • create_syn_ip
  • legalize_phy_inst
  • update_timing
  • report_timing_status
  • export_db ${prj_name}_gate.db

关键结论：

• 就算是 IP 综合流，边界也停在 gate.db
• 如果用户的问题是“IP 综合是否已经完成”，判断依据仍然是 opt_gate 闭环和 gate.db

PRFlow.tcl

它证明了“综合完成”不等于“物理实现开始/完成”：

• 仍然有 read_design -> opt_rtl -> opt_gate
• 但 opt_place 才会导入重配置模块或静态数据库并继续放置
• opt_route 才会导出 static_pr.db

关键结论：

• PR 模式下也不能把 place/route 的等待塞回综合 skill
• 如果问题出现在 import_db -link -mode ooc -inst ... _gate.db 之后，已进入下游物理实现领域

MultiSeed.tcl

它证明 multi-seed 是综合下游，而不是综合的一部分：

• stepList 只有 opt_place opt_route bitgen
• prepare 直接 import_db $parent/${prj_name}_gate.db

关键结论：

• multi-seed 的输入就是综合产出的 gate.db
• 一旦用户问题落在 seed、place、route、fix_hold、route.qor，就该切到 anlogic-place-route

工作流程

1. 先确认是不是综合问题

只有当问题仍落在下面三段之一时，才留在本 skill：

• read_design
• opt_rtl
• opt_gate

如果用户已经在问：

• place
• route
• fix_hold
• report_qor
• bitgen
• setup_debugger
• export_bitgen_param

那已经越过综合边界，应切到对应 skill。

2. 找到真实 run 入口

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

3. 先判入口，再判阶段，再判交付

固定检查顺序：

1. 入口是否正确
   • 工程、器件、顶层、源列表、约束是否指向本轮设计
2. 阶段是否闭环
   • read_design
   • opt_rtl
   • opt_gate
3. 交付是否成立
   • flow.status
   • *_gate.db
   • *_gate.timing
   • *_gate.ts

4. 给出放行或停线决定

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

• 允许放行到 anlogic-place-route
• 停留在 anlogic-synthesis 修复

不要给模糊说法，例如“看起来差不多可以继续”。

阶段判断规则

read_design

重点确认：

• elaborate -top <top_module> 是否对准真实顶层
• .prj 与 run 脚本是否包含最新 RTL/IP/netlist
• read_adc、read_ip_adc、read_sdc、read_sdc -ip 是否读到正确对象

常见失败归因：

• 顶层名错误
• 新文件未入工程
• 约束文件路径错误或未执行
• family 不匹配，导致 primitive 入口即失效

交付要求：

• *_elaborate.db 生成
• .read_design.end.f 存在

opt_rtl

重点确认：

• insert_debugger 是否引用了有效配置
• wrapper、厂家 primitive、综合所需 netlist 是否成套存在
• 黑盒问题究竟来自普通漏文件还是器件/IP 依赖缺失

常见失败归因：

• debugger 配置缺失
• wrapper 在、底层原语不在
• 引入了错误 family 或错误版本的模块

交付要求：

• *_rtl.db 生成
• *_rtl.area 可读
• .opt_rtl.end.f 存在

opt_gate

重点确认：

• optimize_gate
• legalize_phy_inst
• update_timing
• report_timing_status
• report_timing_summary
• flow_status -file flow.status
• export_db ${prj_name}_gate.db

常见失败归因：

• legalize_phy_inst 暴露 primitive 落地或资源映射非法
• gate 阶段时序已明显失控
• flow.status 已给出失败态
• export_db 没有得到本轮新的 *_gate.db

交付要求：

• flow.status 存在且可解释
• *_gate.db 为本轮有效产物
• *_gate.ts / *_gate.timing 存在
• .opt_gate.end.f 存在

Marker、错误与等待规则

关注这些文件：

• .read_design.begin.f
• .read_design.end.f
• .read_design.error.f
• .opt_rtl.begin.f
• .opt_rtl.end.f
• .opt_rtl.error.f
• .opt_gate.begin.f
• .opt_gate.end.f
• .opt_gate.error.f

等待规则：

• 若出现 .error.f，直接按当前阶段失败处理
• 若日志出现 ERROR、FATAL、failed、cannot、unable to、minidump，且 .end.f 未生成，不继续等
• 若只有 .begin.f 没有 .end.f，并且日志、flow.status、*_gate.db、*_gate.timing 连续两轮都无变化，按卡住或异常中断处理
• 不因为“后面可能还会继续 place/route”而延长综合阶段等待

明确禁止的无效动作

• 为了等 bit 文件而继续停在综合 skill
• 因为没有 pr.db 就认定综合失败
• 因为 place/route 的 WNS、拥塞或 hold 问题而回头重判综合成功状态
• 在已经进入 opt_place 之后继续拿综合 marker 解释全部问题
• 把 open_project ... -noanalyze 当成默认安全选项
• 只看控制台输出，不看 flow.status、marker 和数据库时间戳

输出要求

完成任务时至少给出：

• 当前问题属于 read_design、opt_rtl、opt_gate 还是已经越界到下游
• *_gate.db 是否已生成且是否为本轮有效交付
• *_rtl.area、*_gate.ts、*_gate.timing、flow.status 分别在哪里
• marker 是否闭环，是否存在 .error.f
• 是否允许放行到 anlogic-place-route
• 若不允许，最小修复动作是什么

与其他 skills 的联动

• 上游通常来自 anlogic-design
• 若问题还停留在工程创建、器件选择、源文件组织，切到 anlogic-project-creation
• 若需要先做编译/仿真预检，联动 anlogic-modelsim
• 综合成功后，下一步进入 anlogic-place-route
• 若问题已到 bitgen、下载、AJE/SVF、Flash/SRAM，切到 anlogic-create-bitstream 或 anlogic-download
• 若确认了新的 primitive、wrapper 或稳定修复路径，联动 anlogic-learnings

需要时再读取的 references

• 读取 references/td-synthesis-flow.md
  • 当需要查看官方脚本里的命令顺序、阶段交付、上下游数据库关系和停线规则时
• 读取 references/td-synthesis-warning-playbook.md
  • 当日志出现 SYN-*、PLL、时钟结构、multi-driver、SerDes/IOCLK 等高频告警时

约束

• 不要把 place-route、bitgen、下载动作写进综合阶段结论
• 不要把“日志还在滚动”直接等同于“综合健康进行中”
• 不要只报现象，必须给阶段、证据、交付状态和最小修复动作
• 对厂家 primitive、RAM/ROM、PLL、PCIe/SerDes IP 要显式标注，不要笼统当普通 RTL 处理