企业官网建设流程全解析

1. 为什么“清理工程”这件事比想象中更容易翻车

做过几年FPGA项目的人，大概都经历过这种场景：工程跑得好好的，综合、实现、生成比特流一条龙没问题，结果硬盘空间告急，想着把工程目录里那些“看起来没用”的文件夹删一删，顺手把中间产物清一清。删完之后重新打开工程，Vivado直接报错——找不到某个IP的.xci文件，或者约束文件路径失效，再或者Block Design的bd文件打不开。更离谱的是，有些文件明明还在，但工程就是认不出来，因为工程内部记录的路径和实际文件位置对不上了。

这就是“清理工程”这件事的坑：Vivado的工程目录结构不是简单的“源码+输出”两层关系，而是由工程文件（.xpr）、运行目录（.runs）、IP缓存、Block Design封装、约束集、仿真集等多个子系统交织在一起的一套状态机。你删掉的任何一个看似冗余的文件，都可能是某个子系统正常运转的必要条件。

我见过太多人清理工程的方式就是“把.runs文件夹整个删掉”，觉得反正重新综合一遍就回来了。这个做法在纯RTL工程里确实问题不大，但一旦工程里包含IP核、Block Design、或者自定义的仿真/约束集，直接删.runs就可能触发一连串的重新生成问题。更稳妥的思路是：先搞清楚哪些文件是“可再生的中间产物”，哪些是“不可再生的源文件”，然后只清理前者，并且用Vivado自己提供的机制来清理，而不是手动去删文件夹。

这篇内容就是围绕这个核心问题展开的。我会从工程目录的构成讲起，把每个文件夹和文件类型的角色说清楚，然后给出几种不同场景下的清理方案——包括工程内清理、工程归档、以及手动清理时的安全边界。适合所有用Vivado做FPGA开发的人，不管你是刚接触Vivado的新手，还是已经做过几个项目但每次清理工程都心里没底的老手。

2. Vivado工程目录里到底放了些什么

2.1 工程根目录下的关键文件与文件夹

一个典型的Vivado工程目录，根目录下通常能看到这些东西：

很多人清理工程时只盯着.runs，但实际上.gen和.cache往往才是占空间的大头。一个中等规模的工程，.runs可能几个GB，但.gen里的IP生成产物加上.cache里的综合缓存，加起来可能超过10GB。所以清理策略要分层次，不能一刀切。

2.2 .srcs目录的内部结构

.srcs是工程的核心，里面按类型分了几个子目录：

• sources_1：存放RTL源码、IP的.xci文件、Block Design的.bd文件
• constrs_1：存放XDC约束文件
• sim_1：存放仿真源文件，包括testbench和仿真脚本
• utils_1：存放一些辅助文件

这里要特别注意：IP核在.srcs里通常只存一个.xci文件（IP配置文件），真正的IP生成产物在.gen目录里。这意味着如果你删了.gen，IP的.xci还在，Vivado可以通过“Generate Output Products”重新生成。但如果你删了.srcs里的.xci，那这个IP的配置就彻底丢了，只能重新配置一遍。

Block Design也是类似的逻辑：.srcs里存的是.bd文件（Block Design的源描述），.gen里存的是根据.bd生成的实际RTL和IP产物。删了.gen可以重新生成，删了.bd就麻烦了。

2.3 .runs目录里各子目录的含义

.runs下面通常有这些子目录：

• synth_1：综合运行目录，包含综合日志、网表文件等
• impl_1：实现运行目录，包含布局布线结果、时序报告、比特流等
• 如果有多个综合或实现策略，还会有synth_2、impl_2等

每个运行目录里又有大量中间文件，比如.dcp（设计检查点）、.vds（Vivado设计数据库）、各种报告文件等。其中.dcp文件是关键——它是综合或实现结果的快照，可以用来恢复设计状态。如果你删了.dcp，那这个运行的结果就没了，只能重新跑。

但.dcp文件通常很大，一个中等设计的实现后.dcp可能几百MB到几个GB。所以清理时要不要保留.dcp，取决于你是否需要在不重新跑综合/实现的情况下恢复设计状态。

2.4 .gen和.cache的角色区分

.gen目录存放的是IP和Block Design的生成产物，包括：

• IP的RTL源码（根据.xci配置生成的）
• IP的仿真模型
• Block Design展开后的RTL
• 相关的约束文件

.cache目录存放的是综合和实现过程中的缓存数据，比如：

• 综合时的中间网表
• 实现时的布局布线缓存
• 各种编译缓存

这两个目录的共同特点是：都可以通过Vivado的重新生成机制恢复，但恢复需要时间。.gen的重新生成通常比较快（几分钟），.cache的重新生成取决于综合/实现的复杂度（可能几十分钟到几小时）。

3. 用Vivado自带机制清理工程才是正路

3.1 Project菜单下的Cleanup选项

Vivado的Project菜单里有一个“Project Cleanup”选项，这是最安全的清理入口。它提供了几个清理级别：

• Cleanup Project：清理工程中的临时文件和缓存，保留运行结果
• Reset Project：重置工程到初始状态，删除所有运行结果
• Remove Runs：删除指定的运行结果

我一般推荐用“Cleanup Project”，它会自动识别哪些文件是安全的可清理项，不会误删源文件。具体操作路径是：Project → Project Cleanup → 选择清理范围 → OK。

这个机制的好处是，Vivado自己知道哪些文件是“可再生”的，哪些是“不可再生”的。它不会去动.srcs里的源文件，只会清理.runs、.gen、.cache里的中间产物。

3.2 通过Reset Project实现“轻量级归档”

如果你想把工程恢复到“刚创建完、还没跑过综合”的状态，可以用“Reset Project”。这个操作会：

• 删除所有运行结果（.runs下的内容）
• 删除.gen和.cache下的生成产物
• 保留.srcs下的所有源文件
• 保留.xpr工程文件

执行完Reset Project之后，工程目录会变得很小，基本上只剩下源文件。下次打开工程时，需要重新生成IP产物、重新跑综合和实现。这个方式适合在项目交接或归档时使用——把工程瘦身到最小，只保留必要的源文件。

但要注意：Reset Project之后，之前的所有运行结果都没了，包括时序报告、比特流等。如果你还需要这些结果，先备份再Reset。

3.3 用Write Project Tcl实现“可重建的归档”

Vivado支持把整个工程导出为一个Tcl脚本，这个脚本包含了重建工程所需的所有信息：源文件列表、IP配置、约束文件、工程设置等。操作方式是：File → Write Project Tcl → 指定输出路径。

生成的Tcl脚本可以在另一台机器上通过source命令重建整个工程。这个方式的优势是：

• 归档体积小（Tcl脚本通常只有几十KB到几MB）
• 可重建（只要有源文件和Tcl脚本，就能恢复工程）
• 版本控制友好（Tcl脚本是文本文件，方便diff）

但前提是：源文件本身要单独保存。Tcl脚本只记录文件路径和工程配置，不包含源文件内容。所以归档时需要把.srcs目录和Tcl脚本一起保存。

3.4 三种清理方式的适用场景对比

选择哪种方式，取决于你的目的：如果只是想释放一些空间但不想重新跑综合，用Project Cleanup；如果想把工程瘦身到最小用于归档，用Reset Project；如果想把工程纳入版本控制或迁移到另一台机器，用Write Project Tcl。

4. 手动清理时的安全边界在哪里

4.1 可以放心删除的目录和文件

如果你不想用Vivado的清理机制，而是想手动删文件夹，那以下这些是可以安全删除的：

• .cache目录：综合/实现缓存，删了之后重新跑会自动重建
• .hw目录：硬件管理器数据，不影响工程本身
• .sim目录：仿真运行数据，删了之后重新跑仿真会重建
• .runs下的synth_*和impl_*目录：运行结果，删了之后需要重新跑
• .gen目录：IP和Block Design生成产物，删了之后可以通过“Generate Output Products”重建

但要注意：删.runs和.gen之后，重新打开工程时Vivado可能会提示“找不到某些文件”，需要手动触发重新生成。具体操作是：在Sources窗口中右键点击IP或Block Design，选择“Generate Output Products”，然后重新跑综合和实现。

4.2 绝对不能删的文件和目录

以下这些是工程的“命根子”，删了之后工程就废了：

• .xpr文件：工程主文件，删了工程就打不开了
• .srcs目录下的所有源文件：RTL、约束、仿真、IP的.xci、Block Design的.bd
• .srcs目录下的.xci文件：IP配置文件，删了IP配置就丢了
• .srcs目录下的.bd文件：Block Design源描述，删了Block Design就没了
• .srcs目录下的.xdc文件：约束文件，删了约束就丢了

这里有一个容易踩的坑：有些人看到.srcs里有一些看起来像“生成产物”的文件，比如IP的仿真模型或者Block Design展开后的RTL，就顺手删了。这些文件虽然看起来像生成产物，但它们实际上是在.srcs目录下，属于工程源文件的一部分。删了之后，Vivado可能无法正确识别IP或Block Design。

4.3 那些“看起来像垃圾”但实际不能删的文件

除了上面说的.srcs里的生成产物，还有几类文件容易被误删：

• .xpr同目录下的.jou和.log文件：这些是Vivado的日志文件，虽然不影响工程功能，但删了之后如果工程出问题，就没有日志可查了。建议保留最近几次的日志。
• .srcs下的.prj文件：这是工程源文件的索引文件，删了之后Vivado可能无法正确加载源文件。
• .gen下的.xci文件：有些人会混淆.srcs下的.xci和.gen下的.xci。.srcs下的.xci是IP配置源文件，不能删；.gen下的.xci是生成产物，可以删。

4.4 手动清理后的验证清单

如果你手动清理了工程，重新打开时建议按以下清单验证：

1. 打开工程，检查Sources窗口是否正常显示所有源文件
2. 检查IP目录下是否有IP显示为“未生成”状态
3. 检查Block Design是否能正常打开
4. 检查约束文件是否正常加载
5. 跑一次综合，看是否有报错
6. 如果综合通过，跑一次实现，看时序是否正常

如果以上任何一步出问题，说明清理时误删了必要文件，需要从备份恢复。

5. 工程归档与迁移时的清理策略

5.1 归档前应该保留哪些文件

如果你要把工程归档（比如项目结题、交接给同事），建议保留以下内容：

• .xpr工程文件
• .srcs目录下的所有源文件（RTL、约束、仿真、IP的.xci、Block Design的.bd）
• 一个Write Project Tcl生成的Tcl脚本
• 一份README说明工程的基本信息和重建步骤

.runs、.gen、.cache这些目录可以全部删掉，因为它们都可以通过重新生成来恢复。这样归档出来的工程体积最小，通常只有几十MB到几百MB，而不是几个GB。

5.2 跨机器迁移时的路径问题

Vivado工程里记录的文件路径可能是绝对路径，迁移到另一台机器后路径就失效了。解决方法是：

• 在Write Project Tcl时，Vivado会自动把路径转换为相对路径
• 或者在工程设置里把路径改为相对路径（Tools → Settings → Project → General → 勾选“Use relative paths”）

如果迁移后打开工程发现文件找不到，可以用“Report IP Status”检查IP状态，或者手动重新指定文件路径。

5.3 用Tcl脚本重建工程的完整流程

假设你有一个归档的Tcl脚本rebuild.tcl和源文件目录srcs_backup，重建工程的流程是：

# 在Vivado Tcl Console中执行 cd /path/to/archive source rebuild.tcl

执行完Tcl脚本后，Vivado会自动创建工程、添加源文件、配置IP。然后你需要手动触发IP生成和综合：

# 生成所有IP的输出产物 generate_target all [get_ips] # 重新跑综合 reset_run synth_1 launch_runs synth_1 -jobs 8 wait_on_run synth_1

这个流程的好处是：工程重建过程完全可脚本化，适合自动化流程。如果你在CI/CD环境里跑FPGA构建，这种方式比直接拷贝工程目录更可靠。

5.4 归档后的目录结构建议

一个推荐的归档目录结构是这样的：

project_archive/ ├── rebuild.tcl # 工程重建脚本 ├── srcs_backup/ # 源文件备份 │ ├── sources_1/ │ ├── constrs_1/ │ └── sim_1/ ├── README.md # 工程说明 └── docs/ # 相关文档

这个结构清晰明了，任何人拿到这个归档都能快速重建工程。

6. 几个我踩过的坑和对应的解法

6.1 删了.gen之后IP报错“未生成”

有一次我为了省空间，把.gen目录整个删了。重新打开工程后，Vivado提示“IP output products are missing”。我当时的做法是右键点击IP，选择“Generate Output Products”，但生成完之后综合还是报错，说找不到某个IP的RTL文件。

后来发现原因是：删.gen之后，Vivado的IP状态没有自动更新，需要先“Reset Output Products”再“Generate Output Products”。具体操作是：右键点击IP → Reset Output Products → 然后再Generate Output Products。这样Vivado会重新识别IP状态并正确生成产物。

6.2 手动删.runs后工程无法综合

还有一次，我手动把.runs下的synth_1和impl_1目录删了，想着重新跑一遍就行。结果重新打开工程后，综合按钮是灰色的，点不了。原因是：Vivado的工程状态记录在.xpr文件里，手动删.runs目录不会更新.xpr里的运行状态。解决方法是：在Flow Navigator里右键点击“Synthesis” → “Reset Synthesis Run”，然后再重新跑综合。

这个坑的教训是：清理.runs最好用Vivado的“Remove Runs”功能，而不是手动删文件夹。Remove Runs会同时更新工程状态，避免出现“运行状态不一致”的问题。

6.3 约束文件路径失效的排查过程

有一次同事把工程从一台机器拷贝到另一台机器，打开后发现约束文件加载失败。排查过程是这样的：

1. 打开工程，看到Constraints窗口里XDC文件显示为灰色
2. 右键点击XDC文件 → “Report File Path”，发现路径指向的是原机器的绝对路径
3. 手动重新添加XDC文件，路径改为相对路径
4. 重新跑综合，约束正常生效

这个问题的根源是：工程创建时如果用了绝对路径，迁移后路径就会失效。预防措施是在工程设置里勾选“Use relative paths”，或者在Write Project Tcl时让Vivado自动处理路径。

6.4 Block Design的.bd文件和.gen产物不一致

Block Design有一个容易出问题的地方：.srcs里的.bd文件和.gen里的生成产物可能不一致。比如你修改了Block Design，但忘记重新生成产物，那综合时用的还是旧的产物。

解决方法是：每次修改Block Design后，右键点击.bd文件 → “Generate Output Products”，确保产物和源描述一致。如果清理工程时删了.gen，重新生成后也要检查Block Design的状态是否正常。

6.5 清理后仿真跑不起来的常见原因

仿真相关的文件分布在.srcs/sim_1、.sim、.gen等多个目录。清理时如果删了.sim目录，仿真结果会丢失，但重新跑仿真会重建。如果删了.srcs/sim_1里的testbench文件，那就麻烦了——testbench是源文件，删了就得重写。

另外，如果工程里用了IP的仿真模型，这些模型通常在.gen目录下。删了.gen之后，需要重新生成IP产物，仿真才能正常跑。

7. 一套可复用的工程清理检查清单

7.1 清理前的备份确认

在清理任何工程之前，先确认以下内容已经备份：

• .srcs目录完整备份
• .xpr文件备份
• 如果有自定义的Tcl脚本或约束文件，单独备份
• 如果需要保留运行结果，备份.runs下的.dcp文件

备份完成后，再执行清理操作。

7.2 分步骤清理流程

推荐的清理流程是：

1. 关闭Vivado工程
2. 用Project Cleanup做一次轻量清理
3. 如果还需要更多空间，用Reset Project做中度清理
4. 如果需要归档，用Write Project Tcl导出重建脚本
5. 手动删除.cache、.hw、.sim等目录
6. 重新打开工程，验证源文件、IP、Block Design、约束是否正常
7. 跑一次综合，确认工程可正常构建

7.3 清理后的功能验证要点

清理后重新打开工程，重点检查：

• Sources窗口是否显示所有源文件
• IP目录下IP状态是否正常（不是“未生成”状态）
• Block Design是否能正常打开
• 约束文件是否正常加载
• 综合是否能正常启动

如果以上任何一项有问题，说明清理时误删了必要文件，需要从备份恢复。

7.4 团队协作时的工程清理规范

如果是团队协作，建议制定统一的清理规范：

• 每个人在提交代码前，用Write Project Tcl导出重建脚本
• 归档时只保留.srcs和Tcl脚本，不提交.runs、.gen、.cache
• 在README里说明工程重建步骤
• 定期用Reset Project清理本地工程，保持工程目录整洁

这样既能保证工程可重建，又能避免因为清理不当导致的问题。

8. 关于工程清理这件事的个人体会

我做了这么多年FPGA项目，最大的体会是：工程清理的核心不是“删什么”，而是“知道什么可以重建”。只要你能清楚地判断一个文件是“源文件”还是“生成产物”，清理就不会出大问题。源文件必须保留，生成产物可以删但需要知道怎么重建。

另一个体会是：尽量用Vivado自带的清理机制，少手动删文件夹。Vivado的Project Cleanup、Reset Project、Write Project Tcl这三个功能覆盖了绝大多数清理场景，而且它们会同步更新工程状态，避免出现“文件删了但工程状态没更新”的问题。

最后分享一个小技巧：如果你不确定某个文件能不能删，可以先把它移到工程目录外面（比如移到桌面），然后重新打开工程跑一次综合。如果综合通过，说明这个文件确实可以删；如果综合报错，把它移回来就行。这个“移出测试法”虽然笨，但很稳妥，适合对工程结构不太熟悉的时候用。