企业官网建设流程全解析

简介：面向使用Cadence Allegro进行高速PCB设计的工程师与学习者，这份文档聚焦高速信号约束中PIN_delay的添加流程，重点解决FPGA引脚延时数据从Vivado导出后如何换算、导入并显示于约束管理器的问题，适合具备一定约束基础、希望补齐器件延时处理技能的中级读者。资源以单份docx交付，压缩包约805KB，仅1个文件，便于随查随用。内容按获取PIN_delay文件、数据整理、导入PCB、SIGXplorer拓扑设置与验证组织，给出Excel求平均值、ps转mil（约1ps=6mil）、建立match group及VLOOKUP回读比对等做法，并配实例截图说明多路径信号的处理差异。目前已有9089人浏览学习。读者可据此掌握一套可照做的操作路径，理解多路径信号不能直接建立match group、拓扑需更新、PIN_delay显示开关等易错点，并通过导入后校验减少等长约束偏差。

1. 从一块回板眼图闭合的板子说起：PIN_delay 没导进去的代价

前年冬天一块高速背板回板，示波器上眼图几乎闭成一条缝，约束管理器里等长组做得干干净净，长度偏差卡在 5mil 以内，时序报告看着也漂亮。查了两天才发现问题不在走线，在 PIN_delay：Allegro 里那份从 Vivado 导出的封装延迟数据压根没导进去，工具默认按零处理，芯片封装内部那几百 mil 的飞行时间被整段吞掉，等长匹配等于白做。

这类问题在 FPGA 加高速连接器的板子上极其常见，尤其是并行总线、DDR 和多 Lane SerDes。PIN_delay 的本身并不难，难点在于它跨了两套工具、一层单位换算和一次数据清洗，任何一环出问题，导入时不会报错，只会安静地给你一份错的数据。下面这套流程，是我自己反复装、反复翻车之后固定下来的顺序。

2. 版本与器件先对齐：Vivado 里导出 xcvu440flga2892 的 pin_delay

2.1 两套工具各自的版本门槛和器件名一致性

这条链路两头各站一个工具：一头是 Vivado，负责把 FPGA 封装内部从 die pad 到 ball 的延迟导出来；另一头是 Allegro PCB Editor，负责把这份延迟吃进约束系统。两头的版本倒不需要严格一一对应，但有两个前置条件必须先确认，否则后面全是无用功。

第一个条件是 Vivado 侧装了对应的器件库。link_design -part这条命令的本质是让工具加载器件模型，不是加载你的工程。如果安装 Vivado 时只勾了某几个器件系列，执行时会直接提示找不到该 part。常见做法是回到安装器，在 Device Family 里把 UltraScale 系列补勾上，装完不需要重装整个工具。

第二个条件是 part number 必须和 PCB 上实际器件完全一致。xcvu440flga2892拆开来看：xcvu440是器件型号，flga2892是封装加引脚数。工程里如果用的是带速度等级的完整型号，导出时给的 part 也要能对上，少一段、封装写错一个字母，link_design都会报 part 不存在。我一般会先从原理图器件属性里把 part number 原样复制，不去手敲。

Allegro 这一侧的门槛低一些，能打开 Constraint Manager、菜单里有File -> Import -> Pin Delay就行。这个菜单路径在近几个版本里没挪过位置，都在 File 下面，找不到多半是打开的并不是 PCB Editor 本体，而是某个查看器。

提示：导出前先把 Vivado 的当前工作目录确认一遍，write_csv默认往当前目录写文件，很多人导出后找不到文件，其实是落在了安装目录或者用户目录下。

2.2 link_design 加 write_csv：两条 Tcl 命令的完整执行过程

打开 Vivado，不需要新建工程，也不需要综合，直接在最下面的 Tcl Console 里敲。整个导出只有两条命令，但顺序不能颠倒。

# 第一步：按器件型号加载封装模型，不需要打开工程 # part number 必须和 PCB 上的实际器件一致 link_design -part xcvu440flga2892 # 第二步：把当前设计的引脚延迟导出成 CSV # 默认写到 Vivado 的当前工作目录，文件名固定为 pin_delay.csv write_csv pin_delay

link_design执行成功后会打印一段器件信息，说明器件模型已经加载进内存，此时工具里有一个"空设计"，只有封装和引脚定义，没有逻辑。这正是导出 pin delay 需要的状态，因为延迟数据来自封装本身，和你的 RTL 无关。

write_csv后面跟的是文件名，不给路径就落在当前工作目录。如果目录下已存在同名文件，命令会报错退出，这时加-force覆盖，或者换个名字。有一点容易被忽略：这条命令的参数在不同版本里做过调整，敲之前按一下 Tab 补全，看当前版本接受的参数列表，比照抄旧教程稳。

导出完成后，先在命令行里确认文件真的生成了，别急着开 Excel。

# 看文件落在哪个目录，避免在错误的路径下找文件 pwd # 确认文件存在以及大小是否合理 ls -lh pin_delay.csv # 看前三行，确认表头字段对不对 head -3 pin_delay.csv

head这一步的价值在于提前发现两个问题：一是文件是不是空的，二是表头字段名和你后面 Excel 公式里引用的列是否一致。不同版本导出的列名可能有细微差别，比如Max Trace Delay (ps)中间带不带空格，直接决定你后面写公式时列号从哪一列开始数。

2.3 打开 CSV 先认清字段：哪些列是 ps，哪些列是封装引脚

把文件拖进 Excel，你会看到一张很朴素的表：一列是引脚编号（Pin Number），一列是引脚名（Pin Name），后面跟着最大延迟和最小延迟，单位是 ps。这里的 ps 是皮秒，指的是信号从芯片内部焊盘走到封装焊球上所花的时间，和板上走线长度没有关系。

这张表的每一行对应一个引脚，不是一对引脚。也就是说，你现在拿到的是"点"的数据，而 Allegro 需要的是"点对点"的数据，中间差的这一步配对，是导入之后由工具完成的，所以导入后你才会看到 PIN_PAIR 这种对象。理解这一点很重要：数据处理阶段不要试图自己把两个引脚拼成一对，那是导入之后才做的事。

另外一个常见误解是这张表可以当走线长度用。不能。它只反映封装内部延迟，板上走线的延迟要由叠层和介电常数算，两者在 Allegro 里是相加的关系。把 pin delay 当成走线长度去卡等长，约束会整体偏掉一截。

3. ps 换算成 mil：Excel 里把原始表洗成 Allegro 认得的格式

3.1 最大最小延迟取平均：一列公式加下拉

原始表给了最大延迟和最小延迟两列，Allegro 导入时一般只需要一个代表值，工程上的习惯是取两者的平均。这一步用一列公式就能做完。

=(E6+F6)/2

公式本身简单，坑全在列号上。假设 E 列是Max Trace Delay (ps)、F 列是Min Trace Delay (ps)、第 6 行是第一条数据，那么这一行公式就落在 G6。写完回车，选中 G6 右下角的小方块往下拉，整列填充完成。

如果不想手数行号，用=AVERAGE(E6:F6)效果一样，可读性更好，不容易在插入列之后错位。这里有个血泪经验：不要在原始数据表里直接插列插行，先复制一份到新工作表再加工，原始表留着后面验证用，一旦改动就再也对不上账了。

提示：下拉填充之后抽查两行，把公式栏点开看看引用的行号有没有跟着变。出现过整列都引用第 6 行的情况，原因是在公式里加了$绝对引用，导致填充失效。

3.2 169.5ps/in 的换算依据与 1ps=6mil 的取整取舍

ps 要变成 mil 才能和 PCB 走线长度放在一起比较。换算系数来自 FPGA 手册里给出的信号传播速度：169.5ps/in，含义是信号在封装介质里走 1 英寸需要 169.5 皮秒。因为 1in 等于 1000mil，所以 1ps 对应1000/169.5 ≈ 5.8997mil，工程上取整成 6mil 使用。

取整这件事值得单独说一句，因为它直接决定精度。6 和 5.8997 之间差了约 1.7%，看着不多，但延迟数值越大误差越明显。

我自己的做法是：器件是低速并行接口，直接用 6 换算，图快；一旦涉及高速串行或者余量吃紧的链路，就在公式里写完整系数，保留一位小数。两种写法在 Excel 里各占一列也不冲突，先用 6 出一版给 layout 参考，等约束细化时再切到精确值。

# 精确换算，保留一位小数，适合高速链路 =ROUND(G6*1000/169.5,1) # 快速换算，口算友好，适合常规并行总线 =G6*6

两个公式里的 G6 都是上一步算出来的平均延迟，单位 ps。ROUND(...,1)是保留一位小数，避免出现十几位小数的脏数据；数值列本身不需要拼接单位，单位统一写在表头里（例如Delay(mil)），这一点下一节还会再说。

3.3 单位列合并与冗余列清理：留数值还是留 "mil" 后缀

很多人习惯把单位和数字拼在一起，写成35.4mil这种形式，看着直观。这一步要慎重。

Allegro 导入 pin delay 时是按数值解析的。如果那一列变成了带字母的文本，轻则该列被当成 0，重则整个文件解析失败，而导入过程不一定给你明确的报错，最后表现为约束管理器里 PIN_DELAY 列全是零，你还以为数据没导进去，反复重导。常见的做法是：数值列保持纯数字，单位只写在表头。

# 不推荐：把单位拼进单元格，导入时可能被解析成文本导致取值为 0 =H6&"mil" # 推荐：只保留数值，单位写在表头，如 Delay(mil) =ROUND(H6,1)

如果出于汇报需要确实想要一个带单位的展示列，就单独放一列，放在最右边，导入时选列不要选它。清理阶段删掉中间过程列（原始 ps、平均值、换算中间值）时也要注意，删之前先把最终要导入的那几列复制成数值粘贴一遍，避免带着公式保存，别人打开时引用失效变成#REF!。

整理完成后的表应该只剩三列左右：引脚编号、引脚名、延迟值（mil）。列越少，导入时选错列的概率越低。

3.4 另存 CSV 的编码、分隔符与表头

最后一步是保存格式。Excel 的"另存为 CSV"有几个变体，选错就会出现中文乱码或者整行挤在一列的情况。

我一般选「CSV UTF-8（逗号分隔）」。不要选带"MS-DOS"字样的老格式，也不要用某些本地化版本导出的分号分隔 CSV，Allegro 那边默认按逗号切分，分号会让整行变成一列。表头保留英文原样，别翻译成中文，也别加合并单元格——合并单元格导出后会产生空列，列号整体后移一位，导入就对不上了。

保存前顺手做三件事：取消所有筛选、取消隐藏列、确认第一行就是表头。这三件事任意一件没做，导出的 CSV 都可能少行或者错列。

4. 导入与约束：Allegro 里让 PIN_DELAY 真正参与等长匹配

4.1 File->Import->Pin Delay 的导入动作与前置检查

打开 PCB 文件，菜单走File -> Import -> Pin Delay，选中刚才存好的 CSV，工具会要求指定目标器件。这里匹配的依据通常是器件位号或者器件名，选错器件的后果是数据导进去了但挂在了另一个器件上，表现和没导一样。

导入前有两个前置检查值得养成习惯。第一，确认该器件已经放置在板上，没放器件的封装没有引脚可以匹配，导入会失败或者只进去一部分。第二，确认器件的引脚编号规则和 CSV 里的一致，有些封装在原理图里用的是逻辑引脚号，PCB 里用的是物理球号，两边对不上时导入的数据会错位。

导入成功后不会有很明显的提示，你要自己去约束管理器里看。这时候如果 PIN_DELAY 列是空的，先别怀疑文件，往下看第五章的排查条目。

4.2 单路径信号：Relative Propagation Delay 里直接建 match group

数据进来之后，它只是躺在那里，不会自动参与约束。要让 PIN_DELAY 生效，得在 Constraint Manager 的Relative Propagation Delay里建 match group。

对于一个只有单一路径的信号，操作很直接：新建 match group，把信号加进去，工具会自动把引脚延迟算进总延迟。这时候你在约束管理器里看到的长度，已经是"走线长度 + 封装延迟"的合成值，等长才有意义。

需要强调的是，建组之前最好先把 PIN_DELAY 列显示出来核对几个值，确认数量和量级合理。一个 2892 球的器件，引脚延迟分布在几十到几百 mil 之间都正常，如果整列都是 0 或者都是同一个数，说明导入环节就有问题，这时候建组只是把错误数据固化下来。

4.3 多路径信号：SIGXplorer 建拓扑、UPDATE CM、再挂进 match group

多路径信号是这条流程里最容易翻车的地方。所谓多路径，就是一个信号从 FPGA 出来之后分成两支甚至多支，分别走到不同的接收端。这种信号不能像单路径那样直接拉进 match group，因为工具不知道你要约束的是哪一条路径的组合。

正确做法是先定义拓扑。打开 SIGXplorer，进入拓扑设置界面，按实际连接关系设置三样东西：拓扑的名字、路径的选择、误差范围。名字建议带上信号名和用途，后面在约束管理器里一堆 PPR 里找起来不至于抓瞎；路径选择就是把实际走的那几条支路勾出来；误差范围对应你允许的偏移量。

填完点 Add，再点 OK，此时拓扑已经建立，但还没生效。回到拓扑设置的第一页，点一下UPDATE CM，这一步是把拓扑推送到约束管理器，很多人卡在这里——拓扑建得漂漂亮亮，约束管理器里就是什么都没有，原因就是漏了这一次更新。

更新完成之后，在约束管理器里会多出对应的 PPR 对象。这时候把 PPR 加进需要约束的 match group，注意不要直接选信号名，因为多路径信号本身对应的不是一条确定路径，直接选会选到不完整的一组。

4.4 把 PIN_DELAY 列打开才看得见

最后一步纯属显示问题，但每年都有人问：数据明明导进去了，怎么约束管理器里看不到 PIN_DELAY。答案是那一列默认没显示出来。

在 Constraint Manager 的列头区域右键，进列显示设置，把 Pin Delay 相关的列勾上，包括 Pin Pair 这类衍生对象。勾上之后刷新一下，数值就出来了。另外，直接生成的 PIN_PAIR 需要引脚之间已经建立了连接关系才能看到，如果某个网络还没连线或者连接关系不完整，对应的 PIN_PAIR 不会出现，这也是"看不到数据"的常见原因之一。

5. 避坑与排查：六个真实翻车点，现象、原因、解决

5.1 数据与导入环节的三个坑

第一个坑：导入后 PIN_DELAY 整列是 0。现象是导入过程没有报错，约束管理器里能看到列，但值全是零。原因基本可以锁定在 CSV 的数值列上——要么数字后面拼了mil后缀变成了文本，要么整份文件用的是分号分隔导致列错位，要么存成了带 BOM 的编码让第一列解析异常。解决办法是回到 Excel，把延迟列改成纯数值，另存为「CSV UTF-8（逗号分隔）」，重新导入一次。

第二个坑：write_csv执行后找不到文件。现象是命令回显正常，但目录里搜不到pin_delay.csv。原因是link_design失败或者根本没执行成功，工具里没有加载设计，write_csv导出的是一份空内容或者压根没生成；还有一种情况是文件生成在了 Vivado 的默认工作目录而不是你以为的路径。解决办法是先pwd看当前目录，再ls确认文件存在，如果文件大小为 0，回头检查 part number 是否拼写正确、器件库是否装全。

第三个坑：换算系数取整带来的累积偏差。现象是等长做完了，实测眼图还是不理想，时序余量对不上。原因是全程用 6mil/ps 口算，每条链路积累了几 ps 的偏差，在余量本就紧张的高速链路上被放大。解决办法是低速链路继续用 6，高速链路改用 5.8997 精确换算，并且把换算过程保留在 Excel 的独立列里，方便回溯是哪一版数据被导入了。

5.2 拓扑与验证环节的三个坑

第四个坑：SIGXplorer 里拓扑设好了，约束管理器没反应。现象是拓扑名字、路径、误差都填了，Add 和 OK 也点了，回到约束管理器找不到对应的 PPR。原因是漏了UPDATE CM这一步。解决办法是回到拓扑设置第一页，点一次更新，再回约束管理器刷新。

第五个坑：多路径信号直接建 match group 失败。现象是把这个信号拉进 match group 时工具报错或者约束不生效。原因是多路径信号对应的路径不唯一，必须先由拓扑定义出一条确定的组合。解决办法是按 4.3 的流程先建拓扑、更新、生成 PPR，再把 PPR 加进 match group，而不是直接选信号本身。

第六个坑：VLOOKUP 整列返回#N/A。现象是验证阶段明明两边数据看着一样，查出来全是找不到。原因是 Allegro 导出的文件里，第一列引脚编号前后带了空格，肉眼看不出来。解决办法是用查找替换把空格清掉，或者在公式里套一层TRIM()。这个问题我在三块板子上都遇到过，属于玄学级别的坑，但只要记住"先清空格再对比"，基本一次就过。

6. 装完怎么验证：导出反查加 VLOOKUP 对表

6.1 从 Allegro 反向导出 pin delay

数据导进去不等于导对了，尤其是中间经过 Excel 换算这一层，任何一步错了都不会有人提醒你。所以这套流程的最后一步，是从 Allegro 反向导出一次，和原始数据对账。

在导入过数据的 PCB 里走File -> Export -> Pin Delay，选中那颗芯片，指定导出路径和文件名，确认导出。这样得到的是一份 Allegro 视角下的引脚延迟数据，和当初导进去的那份理论上应该一一对应。

6.2 VLOOKUP 四参数写法与空格清理

把两份数据放到同一个工作簿的不同工作表里，用 VLOOKUP 按引脚编号把数据拉过来对比。四个参数的含义分别是：查找对象、查找区域、返回值在区域中的列号、匹配类型。

# A2 是引脚编号，Sheet2 是 Allegro 导出的数据区 # 第 4 列是延迟值，最后的 0 表示精确匹配 =VLOOKUP(TRIM(A2),Sheet2!$A:$D,4,0)

精确匹配的 0 不要省，也不要写成 1。近似匹配在引脚编号这种离散值上会给出完全无关的结果，而且不报错，比报错更危险。$A:$D用了绝对引用，方便整列下拉。TRIM()是保险动作，把编号前后的空格清掉，如果源数据空格问题严重，先在源表里做一次全局替换更彻底。

6.3 加一列差值，把误差卡在阈值内

拉过来之后再加一列差值，直接看偏差有多少，比肉眼比对可靠得多。

# 对比导入值和导出值，差值超过 1mil 就标记出来 =IF(ABS(D2-B2)>1,"超差","OK")

阈值取多少，取决于你的换算精度和工艺要求。用 6mil/ps 口算的，误差本身就有几个 ps 的量级，阈值放到 3 到 5mil 都合理；用精确系数换算的，1mil 以内应该全 OK，出现超差就说明数据在某一环被改过。筛出所有"超差"行，把引脚编号拿去约束管理器里定位，基本一眼就能看出问题在哪。

从那以后，我每次导完 PIN_delay 都强制走一遍反向导出加 VLOOKUP，不管当时多赶。这套对账只花十分钟，但能挡掉后面几天的调试。希望帮到你。

本文还有配套的精品资源，点击获取