FPGA 项目交付时，应该交付哪些东西？

先说一个挺常见的场面。

板子在供应商手里跑通了，视频输出正常，客户来看演示也点头。三个月后他们自己的工程师想改一个滤波系数，打开交付压缩包，里面只有一个 .bit 文件和两页说明。改不了，只能重新找人。

这类事在 FPGA 行业里不算少。问题往往不在技术难度，而在项目启动时没人把 “交付边界” 讲清楚。等到验收那天再谈，双方都难受。

一、”能跑” 和 “能改” 是两件事

很多项目验收的标准是 “功能演示通过”。这个标准对一次性产品够用，对需要长期维护的设备就不够。

判断标准其实很简单：拿到交付物的人，能不能在一台干净的电脑上，不看你的注释、不问你的同事，重新生成一个行为一致的 bit 文件。能做到，才算真交付；做不到，交付的其实是一个黑盒。

二、第一层：能重新生成 bit 的那套东西

这一层是最容易被砍掉的，也是最贵的。

• RTL 源码：模块划分、命名、注释要能撑住半年后的阅读。顶层要有清晰的接口说明，不要把所有逻辑塞进一个 top.v。
• 仿真环境：testbench、激励文件、回归脚本。至少覆盖主要功能路径和异常分支。
• 约束文件：XDC 或 SDC，跟源码同版本管理，不能是工程师本地目录里那份 “最新版”。
• IP 与授权：用了哪些 IP、什么版本、是否加密、License 怎么续。加密 IP 要在交付清单里单独标注，否则接手方连综合都过不去。
• 工程与构建脚本：器件型号、速度等级、Vivado/Quartus 版本、综合与实现策略。建议用 Tcl 脚本把整个流程串起来，一条命令出 bit：

# build.tcl —— 换台机器也能复现同一个结果
set part xc7a100tcsg324-2
read_verilog [glob ./rtl/*.v]
read_xdc ./constr/top.xdc
synth_design -top top -part $part
opt_design -directive Explore
place_design
route_design
write_bitstream -force ./output/top.bit

三、约束文件不是附属品

我见过不少交付包里，约束只有几条引脚绑定，时钟靠工具自动推断。这种工程换一块板子就崩，而且崩得莫名其妙。

约束至少要写清楚三件事：时钟从哪来、周期多少；跨时钟域哪些路径是异步的；外部器件接口的输入输出延时。

# 系统时钟 100MHz，来自晶振 U18
create_clock -name sys_clk -period 10.000 [get_ports clk_in]

# 复位信号异步，跨域前不做时序分析
set_false_path -from [get_ports rst_n]

# 外部 ADC 数据线，板级走线延时约 1.2ns
set_input_delay -clock [get_clocks adc_clk] -max 1.2 [get_ports adc_data*]
set_input_delay -clock [get_clocks adc_clk] -min 0.3 [get_ports adc_data*]

约束写得对不对，直接反映在时序报告上。交付时把最差裕量（WNS/WHS）一并给出，比一句 "时序收敛了" 有用得多。

四、第二层：能烧、能生产

• bit 文件，以及用于量产烧录的 .mcs 或 .bin。注意区分调试版和发布版，命名别用 final_v2_真final。
• 烧写流程说明：JTAG 还是 Flash 启动、配置模式引脚怎么接、用哪版下载工具。
• Flash 型号与容量，以及量产治具、批量烧录的工装要求。
• 上电时序与复位行为：FPGA 配置完成前，下游器件应该处于什么状态。这一条在整机上出过太多问题。

五、第三层：硬件对齐

FPGA 项目很少只交逻辑。硬件侧至少要给：

• 原理图（PDF 与源文件），标注 FPGA 的 Bank 电压、参考时钟来源、关键端接。
• 引脚分配表，跟约束文件一一对应，注明哪些引脚预留、哪些禁止使用。
• BOM 关键器件，特别是时钟芯片、配置 Flash、电源芯片这类影响时序和上电的物料。
• PCB 叠层与阻抗，如果接口速率较高（DDR、高速串行），这一项不能省。

六、第四层：验证证据

测试报告不是走流程的文档，它要能让别人判断 “这个设计在什么条件下可靠”。

一份能用的报告至少包含：测试用例与预期结果、实际结果、测试环境（板号、温度、供电）、资源占用率、时序裕量、已知问题与规避方式。做了高低温或长时间老化的，把条件和时长写上；没做的，就明确写 “未验证”，不要留白让人猜。

七、验收时看三条

拿到东西，别急着签字，先做三个动作：

1. 换一台没装过这个工程的电脑，按文档重跑一遍，比对 bit 的时序报告和资源占用。
2. 打开时序报告，看最差裕量是多少，正还是负。
3. 随便抽两个测试用例，照报告的描述复现一遍。

三条都过，交付质量基本靠谱。过不了的，问题通常不在能力，在流程。

八、关于交付标准的一点说明

这类清单在行业里没有统一模板，各家做法差别很大。我们由你创科技做 FPGA 开发项目时，交付范围是写进合同的：100% 源码交付，配套 bit 文件、约束文件、原理图、测试报告，验收前按上面那三条自检一遍。这么做一方面是减少后期扯皮，另一方面，客户团队能自己接手迭代，项目才算真正结束。

回到开头那个场景。判断一个 FPGA 项目交付得好不好，不看演示那天板子亮不亮，看半年后别人打开压缩包时，是叹气还是能直接干活。