# Anlogic Synthesis

> 安路 FPGA 综合 flow skill。Use when: 需要执行、排查或审阅 TD 综合阶段的 read_design、opt_rtl、opt_gate，确认综合阶段的输入、边界、交付物和放行条件，判断问题属于工程入口、RTL/IP、约束还是 primitive 映射，并避免把 place、route、bitgen 的等待和动作误塞进综合阶段。

- Skill: `folsie/anlogic-synthesis` (Agent Skill, multi-file: 10 files)
- Install (CLI): `npx skillmds@latest add folsie/anlogic-synthesis`
- Raw SKILL.md: https://api.skillmd.com/api/skills/folsie/anlogic-synthesis/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: folsie (https://skillmd.com/u/folsie)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/folsie/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 处理