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-flow.md) - 当需要查看官方脚本里的命令顺序、阶段交付、上下游数据库关系和停线规则时 - 读取 [references/td-synthesis-warning-playbook.md](./references/td-synthesis-warning-playbook.md) - 当日志出现 `SYN-*`、PLL、时钟结构、multi-driver、SerDes/IOCLK 等高频告警时 ## 约束 - 不要把 place-route、bitgen、下载动作写进综合阶段结论 - 不要把“日志还在滚动”直接等同于“综合健康进行中” - 不要只报现象，必须给阶段、证据、交付状态和最小修复动作 - 对厂家 primitive、RAM/ROM、PLL、PCIe/SerDes IP 要显式标注，不要笼统当普通 RTL 处理