AI 如何自动通过 PDF 原理图生成管脚映射，简化 FPGA 开发

以一块 Zynq7010/7020 核心板原理图（12 页、400+ 管脚条目）为例，复盘 AI Agent 从「PDF 原理图」到「可复用的管脚映射知识库」的完整实践，以及它如何改变 FPGA 约束编写与核对的工作方式。

在此之前1个月，曾经尝试过类似的工作，效果很不理想，目前测试结果表明，AI已经完全胜任了这个工作，进步神速，我们距离全流程自动化指日可待。

要点是：

1、要告诉他1-2个正确的，用户期望的映射；
2、使用付费模型，推荐阿里Qwen3.8-Max，推荐Qoder；
3、结果输出到skill 避免下次重复；

一、痛点：管脚约束是 FPGA 开发里最「手工」的环节

做过 FPGA 载板开发的人都熟悉这一幕：硬件原理图定稿后，工程师要把成百上千条这样的约束写进 XDC：

set_property PACKAGE_PIN U14 [get_ports {adc_data_p}]

这类工作的难点不在技术，而在誊抄：从原理图上的「网络名 B34_L11_P」到「封装管脚 U14」，每一个管脚都要人眼查、人手敲。一块 Zynq 核心板加载板的系统，这个数量轻松达到三四百：

• PL 侧 Bank34 / Bank35 / Bank13 的差分对与单端 IO；
• PS 侧 54 个 MIO（QSPI、UART、RGMII、USB、SD、eMMC）；
• DDR3 的地址、数据、控制线 70 余根；
• 两个 100 引脚板对板连接器的 200 个引脚定义。

手工誊抄有三个固有问题：慢（半天到一天）、易错（P/N 看反、数字抄错一位，上板后轻则时序异常、重则烧片）、难沉淀（映射关系散落在个人 Excel 和脑子里，新人接手、原理图升版都要从头再来）。

二、挑战：PDF 原理图对机器并不「可读」

最直觉的方案是让 AI 直接读 PDF。但原理图和普通文档完全不同，实践中会踩到这些坑：

1. 文本顺序 ≠ 阅读顺序。pdfplumber 提取出来的是这样的乱序混合体：

   B34_IO0 R19 U14 B34_L11_P 4 3 R7 33R PL_GCLK
   B34_IO0 B34_IO25 T19 IO_0_34 IO_L11P_T1_SRCC_34 U15 B34_L11_N ...
   

   同一页里 FPGA 左列管脚、右列管脚、旁边晶振电路的文本按行交错，无法直接判断哪个管脚号属于哪个网络。

2. 图框字符特效。EDA 图纸标题栏的文字逐字符绘制，提取后变成 DDDeeesssiiigggnNNNaaammmeee 这样的重叠串，甚至 51DNG（实为 GND5 的反序）。

3. 关键信息靠视觉对齐。B34_L10_P → V15、B34_L10_N → W15 这种对应关系完全依赖图中的水平对齐，文本流稍有偏移就会错配。

结论：单纯 OCR 或文本提取不可靠，必须让 AI 像工程师一样「看」原理图，并用工程手段校验。

三、实践：四步流水线

第 1 步：文本层提取做粗筛

用 pdfplumber 把 12 页文本全部导出。目的不是采信，而是定位：哪一页是哪个 Bank、关键网络（B34_L11、Header_2X50）出现在哪，先建立全局地图。

第 2 步：高清矢量渲染 + 视觉识读

用 pypdfium2 把每页渲染成 2526×1785 的位图（矢量渲染，不是扫描件），让 AI 视觉模型像工程师看图纸一样直接读表：网络名、封装管脚、IO 功能名三列对照，一次读全。原理图矢量渲染线条干净，识读准确率远高于扫描件 OCR。

第 3 步：三层交叉校验

• 锚点标定：用户提供一个已知正确的例子（B34_L11_P ↔ U14、B34_L11_N ↔ U15），用它校准「哪列是网络、哪列是管脚」的识读逻辑，确认整张表按同一规则读取；
• 局部放大：对可疑点（如 B34_L10_P 是 V15 还是 W15）按 6 倍分辨率渲染并裁剪局部重新识读，消除歧义；
• 工程交叉核对：与仓库中已有的 Constraints/*.xdc 对比，顺带发现一个关键事实——旧工程 XDC 的管脚与这块核心板并不一致（载板用的是另一款 FPGA 封装）。若不做这层对比，很容易误以为旧约束可以照搬。

第 4 步：沉淀为 Skill，而不是一次性表格

最终产物不是 Excel，而是代码仓库里的一个目录：

.qoder/skills/zynq-core-pinmap/
├── SKILL.md        # 入口：何时使用、如何查询、关键结论
├── pinmap.md       # 网络名 ↔ 封装管脚 ↔ IO 功能名，按 Bank 分表
└── connectors.md   # X3/X4 两个 100 引脚连接器的完整引脚定义

这是「简化 FPGA 开发」的关键一步：映射表从此成为 AI 上下文的一部分。之后——

• 写约束时，只需说「把 AD7606C 的数据线约束到 Bank34」，AI 自动查表生成正确的 PACKAGE_PIN；
• 核对约束时，AI 自动把 XDC 与映射表逐条比对，报告不一致；
• 原理图升版时，重跑仓库里的 extract_pdf.py / render_pages.py 两个小脚本即可快速复核更新。

四、效果

更重要的是，交叉核对暴露了旧工程里潜伏的管脚不一致问题——映射表的价值不只是「生成」，还是「审查」。

五、经验与展望

1. 把 PDF 原理图当「图像 + 文本层」双通道输入，任何单一通道都不可全信；
2. 一定要用少量「锚点管脚」标定，由用户提供一个已知正确的映射，成本几乎为零，却能兜住整张表的系统性错误；
3. 产物必须是结构化知识（Skill/知识库），而不是一次性回答，这样后续的约束编写、约束审查、载板设计都能复用；
4. 该流水线可推广到任何「PDF 原理图 → 管脚/网络表」场景，电源域、电平标准、上下拉配置等信息都可以顺带识读沉淀。

当 AI 能把原理图自动变成机器可读的管脚知识库，FPGA 工程师才能真正把时间花在设计本身，而不是誊抄上。