UG973 2025.1 安装避坑指南：目录重构与 Flexera 许可证升级全解析

简介：UG973中英文对照版是Xilinx官方《Vivado设计套件用户指南：发行说明、安装指南和许可》（v2025.1，2025年5月29日发布）的双语资源，面向FPGA/SoC设计工程师、验证人员及需要在双语环境下查阅官方文档的开发者。 Vivado设计套件本身集成了逻辑综合、布局布线、设计仿真与分析等功能，文档按章节完整覆盖What's New最新动态、Known Issues已知问题、Important Information重要信息，并通过“通过设计流程导航内容”章节指导用户按设计阶段快速定位对应功能，其中Known Issues列表可帮助工程师提前规避设计流程中的风险，重要信息则突出对用户影响较大的变更。 后续“要求和设置”章节详细列出了支持的操作系统、支持的设备、兼容第三方工具、系统需求以及检查所需库等环境准备要点，为软硬件选型和环境搭建提供了可对照查阅的直接依据。 资源仅含1个PDF文件，压缩包大小5.11MB，由于原始文档由OCR扫描生成，个别文字可能存在识别误差，阅读时可结合上下文合理推测补全。 这份双语对照版尤其适合在安装配置、许可获取和版本升级时查漏补缺，能帮助读者高效掌握UG973中的关键概念与操作要点，目前已有125人学习下载。

1. 先读 UG973 再装 Vivado：一份中英对照的 2025.1 避坑地图

上个月我帮同事排一个 Vivado 启动故障，装的是 2025.1，界面一直卡在许可证握手，查到的教程却全指向 2024 年的老目录结构。折腾半天才意识到，2025.1 的安装目录从 Vivado/ 改成了 /Vivado，网上大部分安装教程根本没跟上。UG973 就是 AMD 官方发布的 Vivado Design Suite 用户指南，覆盖发行说明、安装指南和许可证管理三大块，2025.1 版本发布于 2025 年 5 月 29 日。手上这份中英文对照版特别适合双语环境工作的团队，英文术语和中文翻译逐行对应，读起来不用来回切翻译软件。要注意它是 OCR 扫描生成的，个别单词存在识别误差，遇到明显不通顺的句子要以英文列为准。做 FPGA 和自适应 SoC 开发的工程师，只要涉及装工具、配许可、查版本兼容，都建议先翻这份文档再动手。

2. 发行说明里的关键变更：Flexera 升级、目录重构与库改名

2.1 新功能和已知问题：官网页面比 PDF 更新更快

UG973 的发行说明部分由三块组成：What's New 列出新功能、Known Issues 列出已知问题、Important Information 汇总对用户有影响的变更。文档里写得很明确，What's New 的完整内容放在 AMD 官网的 AMD Vivado 2025.1 What's New 页面，已知问题集中在答复记录 000037546 里。换句话说，这份 PDF 给的是入口和摘要，真正细看还是要到 AMD 站点翻对应页面。我的习惯是下载安装包之前先把这两块扫一遍，确认自己用到的器件和 IP 没有被已知问题命中，免得装完才发现踩雷。

Important Information 里有几条值得记下来的长期规则。第一条是 Versal 项目一旦迁移到 Vivado 2024.2，就与所有先前版本不兼容，细节在答复记录 000036830。这对多版本并存、需要来回切项目的团队影响很大，升级前必须先想清楚回退路径。第二条是 AMD IP 配置文件格式从 XML 改成了 JSON，官方说法是改善修订控制能力和加载时间。用 Git 管 IP 的团队会明显感觉 diff 友好很多，但以前针对 XML 写的解析脚本全部要重写，这一点容易被忽略。

2.2 Flexera 许可证管理工具升级到 11.17.2.0

从 2025.1 开始，许可证管理工具 Flexera 升级到 11.17.2.0，所有使用浮动许可证的用户都被要求把许可工具升级到这个版本。文档里有一句容易被忽略的话：Flex 版本升级不影响有效的许可证文件。意思是原有的 .lic 继续有效，不需要重新向渠道申请，只要把 lmgrd、lmutil 这些工具换成新版就能配合 2025.1 使用。实际工作中我见过不少同事以为大版本升级等于许可证作废，先重新走了一遍申请流程，白白等了两三天。

升级 Flex 工具的常规做法是到 AMD 下载网站获取新的 licensing utilities，替换服务器端和客户端同名工具，然后重启 license 服务。切换到新版本后，用 lmutil lmstat 确认服务端显示 Flex 11.17.2.0 再跑 Vivado，不然客户端会一直报版本不匹配。这里要特别留意 PATH 环境变量里是否残留旧路径，很多诡异报错的根源是工具换了、PATH 没跟着换，这个坑我会在第 5 章展开讲。

2.3 安装目录结构重构：Vivado/ 变成 /Vivado

从 2025.1 起，AMD 工具的目录结构做了调整，之前的 Vivado/ 改成 /Vivado，同时一些公共文件夹被提升到与产品平行的层级，用来减少多产品间的重复文件、压缩整体安装体积。这个变动的直接后果是：所有写死路径的脚本、Makefile、CI 流程全部要改。以前常见的 /opt/Xilinx/Vivado/2025.1，现在应该是 /opt/Xilinx/2025.1/Vivado。

还有一点容易忽略：改动只针对安装目录，用户配置目录的路径保持不变，Windows 下仍是 C:\Users<username>\AppData\Roaming\Xilinx，Linux 下仍是 /home/ /.Xilinx。换版本安装不会影响已有工程配置，但反过来也不能靠卸载工具来清理这些用户配置。另外，HLS 从 2025.1 开始集成进 AMD Vivado，即使是只装 Vivado 的安装包也会出现 Vitis 文件夹，这是为了优化文件夹结构依赖，不是装错了。以前为 Vitis 单独写的自定义安装脚本需要检查更新，AMD 自带的 settings.sh 会自动处理目录变化，自定义脚本不会，升级时这里容易翻车。

2.4 XSI 内核库改名：从 librdi_simulator_kernel 到 libxv_simulator_kernel

Vivado 2025.1 还把 Xilinx Simulator Interface（XSI）调用函数所需的内核共享库改了名，文件位置在 <Vivado 安装根目录>/lib/ ，其中 platform 是 lnx64.o 或 win64.o。Linux 下旧名 librdi_simulator_kernel.so 改为 libxv_simulator_kernel.so，Windows 下 librdi_simulator_kernel.dll 改为 xv_simulator_kernel.dll。

这个改名对一般用 Vivado IDE 跑仿真的用户没有影响，但如果你写过 C 程序直接调 XSI 的 API，Makefile 或 CMake 里的链接库名必须同步更新。我见过同事升级后仿真编译一直报找不到共享库，查了半天才发现是 Makefile 里写死了旧库名。改名的同时要注意 2025.1 之后多产品共享目录的情况增多，链接路径如果写得太死，很容易被这种改名收割。

2.5 通过设计流程导航内容：按阶段快速定位

UG973 第一章里还有一节叫 Navigating Content by Design Process，这是很多人会跳过但实际很有用的部分。它把整个文档的内容按设计流程重新组织，比如你正在做综合，就去看综合相关的章节；正在做仿真，就到仿真相关的条目里找。我一般会把它当目录的补充索引用，因为官方目录是按文档结构排的，而这节是按使用场景排的，两者对照着查效率高不少。

中英文对照版在这里的优势比较明显，英文术语比如 Navigating、Supported Devices、Known Issues 和中文翻译逐行对应，读研的时候遇到拿不准的术语直接看原句就行。不过因为 OCR 存在识别误差，个别词可能对不上，遇到这种情况优先以英文为准，这是我读这份文档养成的第一个习惯。

3. 要求和设置：操作系统、设备支持和库检查实操

3.1 支持的操作系统和设备列表：先对表再选型

UG973 第二章给出完整的支持矩阵，包括支持的操作系统、支持的设备、兼容的第三方工具和系统资源要求。选型时最容易犯的错是拿一个差不多的操作系统版本去装，官方只对列表里列出的版本提供认证和支持，列表之外的版本可能能跑，也可能在某个仿真步骤悄悄出问题，这就成了玄学现场。我一般把文档里的操作系统表格截图存到团队共享文档，新机器装配前先核对一遍再动手。

设备支持列表同样重要，2025.1 对 Versal、UltraScale+、Zynq-7000 等系列的支持情况在表格里列得很清楚。如果你的项目用的是较新的 Versal 器件，还要结合发行说明里的迁移提醒一起看，Versal 项目迁到 2024.2 后不再兼容旧版本，这个约束在 2025.1 里继续有效。设备列表里没列到的型号不代表完全不能跑，只是出问题官方不提供支持，评估生产项目时建议严格按列表走。

文档在系统资源要求一节给出了运行大型工程时的硬件建议，包含磁盘空间、内存和处理器的参考配置。我的看法是，如果项目里用到 Versal 这类大器件，规格不要踩着最低线配，综合和布局布线阶段内存吃紧会直接拖慢整个流程。文档里的 System Requirements 表格是底线，不是舒适区。

3.2 检查所需的系统库：用 ldd 提前排雷

UG973 在系统需求部分专门讲了如何检查所需库，这一步很多人会跳过，直到启动 Vivado 报缺少共享库才回头补。Linux 上最直接的手段是用 ldd 检查 Vivado 主程序可执行文件的依赖，看有没有 not found。2025.1 装完后路径要按新目录结构写：

# 确认操作系统发行版和 CPU 架构，避免装错安装包 cat /etc/os-release uname -m # 检查 2025.1 的 Vivado 主程序是否缺少共享库 # 注意新目录结构：<root>/<Version>/Vivado，不是老的 <root>/Vivado/<Version> ldd /opt/Xilinx/2025.1/Vivado/bin/unwrapped/lnx64.o/vivado | grep "not found"

ldd 输出里如果出现 not found，说明对应库没装上。常见的缺库包括 libncurses、libtinfo、libcrypt 这类基础库，逐一用发行版的包管理器安装即可。如果想一次配到位，可以在 Ubuntu 上先装 build-essential、libncurses-dev、libxt-dev 这类基础套件再装 Vivado。更全面的办法是把 bin/unwrapped/lnx64.o 目录下的二进制逐个扫一遍：

# 循环检查 unwrapped 目录下的可执行文件，集中找缺失依赖 for f in /opt/Xilinx/2025.1/Vivado/bin/unwrapped/lnx64.o/*; do miss=$(ldd "$f" 2>/dev/null | grep "not found") [ -n "$miss" ] && echo "== $f ==" && echo "$miss" done

循环里的 2>/dev/null 把非可执行文件的报错吞掉，$miss 不为空才打印文件名和缺失项。这段脚本可以存到本地，每次新装系统后跑一遍，比等到启动 Vivado 报错再搜解决方案快得多。注意示例里的目录结构已经按 2025.1 新规范写，老版本用户照搬时要把路径改回 Vivado/ 。

3.3 第三方工具兼容性：版本锁死，升级前先比表

UG973 列出的兼容第三方工具，主要是仿真器、综合工具和配套工具的版本要求。这里的坑在于 Vivado 每个大版本对第三方工具的兼容版本都不一样，升级 Vivado 后第三方仿真器可能还在用旧版本，导致仿真启动阶段直接报错。我一般会在升级前把团队在用的第三方工具版本和文档表格逐项对比，版本不一致就先升或降第三方工具，再动 Vivado。

3.4 系统资源要求：最小配置和实际体验差别很大

文档里的系统需求章节给出了磁盘和内存的建议值，但实际使用中，同样的工程在最小配置和推荐配置上的运行时间差距很大，尤其是布局布线阶段。如果机器同时跑多个 Vivado 实例，磁盘空间还会因为多版本共存翻倍占用。我的做法是给每个版本预留独立空间，结合 2.3 节的目录结构变化，新版本路径变短了，但总占用并不一定变小。

4. 许可证获取与管理：从 License Key 生成到浮动许可排查

4.1 许可证类型与生成流程：先搞清 node-locked 还是 floating

UG973 第三章的标题很直白：获取和管理许可证。它把流程分成两大部分，创建并生成许可证密钥文件，以及管理许可证。第一步是申请 .lic 文件，AMD 官方站点会根据你的授权类型生成许可证，这一步要填的是本机 hostid，也就是网卡 MAC 地址的某种编码。手工操作时先在命令行查 hostid，再拿这个值去申请：

# Linux 下用 lmutil 查询本机 hostid，申请 node-locked 许可证时必填 lmutil lmhostid

Windows 上同样可以在命令行执行 lmutil lmhostid，或者从 Vivado License Manager 界面里复制。拿到 .lic 文件后放到固定目录，例如 /tools/Xilinx/licenses/2025.1.lic，然后用环境变量告诉工具去哪里读许可证。常见做法是配置 XILINXD_LICENSE_FILE 而不是 LM_LICENSE_FILE，前者是 Xilinx 工具的专用变量，冲突更少：

# 临时生效的写法，适合单次验证 export XILINXD_LICENSE_FILE=/tools/Xilinx/licenses/2025.1.lic # 验证是否读到许可证，用 Vivado 批处理模式跑 Tcl 脚本 vivado -nolog -nojournal -batch -source check_license.tcl

验证脚本里可以用 Vivado 的 Tcl 命令直接查 license 状态，我的做法是写一个极简 Tcl 文件，内容一行 report_license -list，然后看输出里有没有对应版本的特性。注意 XILINXD_LICENSE_FILE 是临时环境变量，重启终端就失效，正式环境要么写进 .bashrc，要么在 Vivado 的 License Manager 里配置成永久项。

4.2 浮动许可证配置与 Flex 11.17.2.0 升级

浮动许可证是团队多人共用的主要方式，服务器上运行 lmgrd 守护进程，客户端通过环境变量指向服务器的端口和主机名。2025.1 对浮动许可证的强制要求是升级 Flex 工具到 11.17.2.0，具体做法是到 AMD 下载网站获取新的 licensing utilities，替换服务器端的 lmgrd、lmutil，再重启服务。重启后先用 lmstat 确认服务端信息：

# 查看 license 服务器状态，27000 是默认端口，换成实际配置 lmutil lmstat -a -c 27000@license-server

lmstat -a 会列出服务器版本、功能特性、当前占用用户数。第一行输出能看到 lmgrd 版本，确认是 11.17.2.0 再继续。如果显示的还是旧版本，多半是 PATH 里的 lmutil 指向了旧路径，要么更新符号链接，要么把新工具目录放到 PATH 最前面。lmstat 连不上服务器时，输出会提示 cannot connect to license server，这时先查端口通不通，再查防火墙，最后才怀疑 license 文件本身。

升级 Flex 工具不影响现有有效的 .lic 文件，文档里把这点说得很明确，新工具读旧文件没有问题。但有一种常见翻车：客户端机器上残留旧版 lmutil，Vivado 2025.1 启动时会调用系统的 lmutil 去握手，版本太老导致握手失败。解决方法是把客户端工具一并升级，而不是只升服务器端。

4.3 许可证报错速查表

配许可证的过程中，最省时间的是把报错分成三类：连不上、不授权、被暂停。下面这张表是我几年排查许可问题整理出来的最小速查表，配合 UG973 第三章的详细说明用：

连不上服务器是最常见的，依次检查网络、端口、XILINXD_LICENSE_FILE 三个变量；不授权通常是装错版本，比如装了标准版却申请的是另一类 license；被暂停则大概率是许可文件本身出了问题。这些排查手段在文档的 Managing Licenses 章节里都有展开，对照着逐条走，比满网搜报错靠谱。

4.4 许可证日常维护：多机切换和备份

多机切换时最容易踩的坑是 node-locked 许可证绑定 hostid，换机器后必须重新申请。浮动许可证则要注意服务器端的 license 文件路径不能变，客户端环境变量里的端口和主机名要一致。我一般会把 .lic 文件纳入备份范围，连同 lmutil 工具版本一起记录，换机器时先核对版本再配环境。许可证日志文件会持续增长，定期轮转日志也能避免服务器磁盘被占满。

5. 下载与安装避坑：目录结构变化、卸载风险和验证环节

5.1 安装包下载与校验：别跳过哈希验证

UG973 第四章讲下载与安装，第一步是选择安装程序下载选项。AMD 为 FPGA 和自适应 SoC 提供统一的安装程序，下载页面上会区分在线安装和离线完整安装包，生产环境我建议直接用离线包，避免安装过程中网络波动导致装到一半失败。下载完成后最关键的一步是验证文件完整性，文档里有专门的 Download Verification 章节。Linux 上用 sha256sum，Windows 上用 certutil，算出来的哈希值和 AMD 官网公布的对比，一致再执行安装：

# Linux 下校验安装器完整性，替换为实际文件名 sha256sum Vivado_2025.1_<build>_Lin64.bin # Windows 下用 certutil 做同样校验 certutil -hashfile Vivado_2025.1_<build>_Win64.exe SHA256

sha256sum 后面直接跟文件名，输出一串 64 位哈希值，肉眼对比官网值即可。certutil 的 SHA256 参数大写，输出格式和 Linux 略有差异但内容一致。我见过有人跳过这步直接装，结果安装到 80% 报安装包损坏，重下重装折腾了一天。哈希校验成本只有一分钟，是安装流程里性价比最高的动作。

5.2 安装目录选择与卸载风险：一个版本一个根目录

安装过程中设置目标目录时，多想想第 2 章讲的目录结构变化。2025.1 以后安装路径变成 / /Vivado，公共文件夹提升到平行层级，多产品间共享文件变多，整体体积变小，但卸载逻辑变得更激进。文档里明确写了一句重要提醒：

注意：从目标文件夹卸载产品，会删除该位置安装的所有产品。

实操上我的习惯是一个版本分配一个独立根目录，例如 /tools/Xilinx/2025.1、/tools/Xilinx/2024.2，坚决不把两个版本放到同一个根目录，避免卸载一个版本时把另一个也带走。如果要保留老版本共存，更安全的做法是把旧版本目录整体重命名存档，而不是通过卸载程序清理空间。另外，即使只装 Vivado，2025.1 也会包含 Vitis 文件夹，这是为了优化文件夹结构依赖，不是装错了。

5.3 五个翻车现场：现象、原因和解决

下面五条都是真实发生过的踩坑记录，按现象、原因、解决的顺序写，方便遇到同类问题时直接对照。

翻车一：安装了 2025.1，启动脚本报找不到路径。现象是 source 老脚本里的 settings64.sh 时报错，路径指向 /opt/Xilinx/Vivado/2025.1。原因是安装目录结构从 Vivado/ 改成了 /Vivado。解决是把脚本里的路径改成新结构 /opt/Xilinx/2025.1/Vivado，或者让脚本用 find 动态定位 settings 文件，别写死。

翻车二：卸载 2025.1 时把同目录的 2024.2 删光了。现象是卸载程序运行后，目标目录下所有版本全部消失。原因是从目标文件夹卸载会删除该位置全部产品，而我把两个版本装在了同一个根目录。解决是今后一个版本一个独立根目录，卸载前三确认目标目录里没有其他版本。

翻车三：浮动许可证升级后 lmstat 仍显示旧版本。现象是服务端和客户端都换了 Flex 11.17.2.0 工具，lmstat 输出里 lmgrd 版本还是旧的。原因是 PATH 环境变量里旧工具目录排在新目录前面，系统实际调用的还是老版本 lmutil。解决是调整 PATH 顺序，或删除旧工具目录，然后重启 license 服务再验证。

翻车四：Windows 上工程路径超长导致 Vivado 静默失败。现象是综合到一半报各种莫名其妙的文件错误，有些甚至不报错直接闪退。原因是 Windows 路径 260 字符限制，工程目录嵌套太深被截断。解决是工程顶层目录尽量短，文件命名按文档要求只使用字母、数字和下划线，省下的字符可能就决定工程能不能顺利跑完。

翻车五：装完 Vivado 2025.1 启动卡在许可证握手。现象是打开 IDE 后长时间停在 license 初始化界面，日志里提示 Flex 版本不匹配。原因是 2025.1 要求 Flex 工具升级到 11.17.2.0，新装机器上还带着旧工具。解决是先到 AMD 下载网站拿新的 licensing utilities，替换后再启动，同时确认 XILINXD_LICENSE_FILE 没有被旧工具路径覆盖。

这五条的共同点，是问题根源几乎都在文档的发行说明部分明确写过。先读文档再动手，能省掉后面大半的排查时间。

6. 装完后的三件小事：settings 脚本、命名规范与版本共存

6.1 加载 settings 并验证版本

安装完成后第一步是加载环境脚本并确认版本号。2025.1 的 settings.sh 会自动处理 Vitis 目录变化等问题，但如果你有自定义启动脚本，要删掉以前手动 source Vitis 的部分，避免重复加载：

source /tools/Xilinx/2025.1/Vivado/settings.sh vivado -version

settings.sh 按新目录结构加载，vivado -version 输出应显示 2025.1 及具体 build 号，与安装包一致才能说明环境正常。

6.2 命名规范与 260 字符限制

文档对源文件、输出文件、项目名有硬性命名约定：必须以字母开头，只能包含字母数字和下划线，目录名额外允许波浪号。不支持的字符包括 ! # $ % ^ & * 反引号、分号、尖括号、问号、逗号、方括号、花括号、单双引号和竖线。另外点不能作为目录名终止字符，@ 不能用于 IDE 新建文件名，但可以在 Tcl 控制台创建。配合 Windows 260 字符限制，工程目录越短越好，这条规范在 2025.1 环境下依然生效，目录结构变化后路径更长，更要注意。

6.3 版本共存与回滚习惯

多个大版本共存时，按第 5 章说的一个版本一个根目录，靠 settings.sh 切换，互不干扰。跨版本回滚时，因为 Versal 项目迁移后不兼容旧版本，没有后悔药，所以升级前一定要留完整备份。我现在每装一个新版本，流程已经固化成：先读发行说明里的 Important Information，再查 Known Issues 的答复记录，最后验证安装包哈希再动手。这个习惯是从那次卸载一个版本清掉全部产品之后养成的，从那以后我每次换大版本都强制走一遍这三步，再没被路径或许可问题卡过。希望帮到你。

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