ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

Vivado工程复制后报错17-1294:目录创建失败排查与修复全攻略

Vivado工程复制后报错17-1294:目录创建失败排查与修复全攻略 前阵子帮同事排查了一个Vivado工程问题现象很简单他从服务器上把整个工程文件夹拷到本地Windows电脑双击.xpr文件打开工程Vivado闪一下弹窗报错内容大致是[Common 17-1294] Unable to create directory /path/to/project/project.runs/synth_1然后工程管理界面直接退出来连工程面板都没加载完整个人就卡在开始页面上。他琢磨了半天也没明白明明文件都拷贝完整了为什么“无法创建目录”这个报错其实非常典型凡是做过工程迁移、换机器、从压缩包解压工程甚至是从Git仓库拉代码后直接打开工程的人大概率都撞见过。我把完整的排查过程和解决方案整理出来顺便把Vivado工程复制后容易踩的坑一起说清楚希望能帮你省下半天折腾时间。这个报错的本质不是“你的工程坏了”而是Vivado在打开工程时需要按照它内部的路径描述在磁盘上重建或者确认某些目录存在一旦路径失效、权限受限或者目录残留异常它就直接抛出17-1294。这篇文章适合刚接触FPGA开发、经常接收别人工程的新手也适合在团队协作中频繁交换工程的老手看完你不仅能解决这个报错还能理解Vivado工程文件体系是怎么组织的以后复制工程才不会再出幺蛾子。1. 报错信息基本认知Common 17-1294到底在说什么1.1 Vivado的工程目录结构——为什么要“创建目录”要理解这个报错先得搞清楚Vivado打开工程时在做什么。一个标准Vivado工程打开时会看见一堆文件夹和文件核心几个是.xpr文件工程描述文件记录所有源文件路径、约束文件路径、器件型号、综合实现策略等。.srcs目录存放源代码和约束文件实体。.runs目录综合、实现、仿真等每一步运行产生的过程文件比如synth_1、impl_1、sim_1等子目录。.cache目录工程缓存里面有Vivado生成的中间数据一般体积较大。.hw目录硬件管理器相关比如硬件平台文件。.sim目录仿真相关文件。打开工程时Vivado先解析.xpr文件然后去对应的磁盘位置找这些目录。它不只是“找”还会尝试“准备”——比如加载综合运行配置时如果发现synth_1对应的目录不存在或者目录里缺了某些文件就会去创建。这个“创建”动作是写操作需要当前用户对该路径有创建目录的权限。Common 17-1294报错的字面含义就是Vivado想建目录但建不出来。我见过很多新人把工程目录拷过来后直接在某个分区根目录下双击打开结果Vivado尝试创建的路径和实际路径对不上报错也正常。这就是典型的路径描述和物理位置不一致。1.2 从报错字符串看工程复制的两大拦路虎仔细看报错字符串Unable to create directory后面会跟着一个具体路径常见的有三种形态路径指向一个根本不存在的父目录比如E:\old_project_path\project.runs\synth_1而实际工程放在了D:\new_project。路径存在但父目录是只读的或者当前Windows用户没权限写入比如工程从服务器共享盘拷过来后NTFS权限把写入锁死了。路径存在且可写但目录里已经有一份“坏掉”的锁文件或者残留状态Vivado在创建子目录时被干扰。不管是哪一种方向都很聚焦路径和权限。这两个就是工程复制后报错的拦路虎。理清这个后面排查就有章法了不用靠玄学。2. 核心原因排查为什么工程复制后第一次打开就报错2.1 最典型的场景只读属性与文件系统权限我在帮同事排查时第一步不是看工程文件而是直接看整个工程目录的属性。果不其然他拷过来之后整个文件夹带上了“只读”属性。这个现象在Windows上特别常见从压缩包解压出来的文件或者从共享盘、U盘、服务器直接拖拽复制到本地磁盘文件系统经常会继承一些奇怪的属性。Vivado在启动合成运行synthesis run或者实现运行implementation run时会产生大量中间文件如果.runs目录或上级目录是只读的任何写操作都会失败报错就是17-1294。Linux上也一样甚至更明显。如果你用cp命令复制工程但是当前用户对复制后的目录没有写权限Vivado打开后同样会报错。我遇到过一种更隐蔽的情况整个家目录用了SELinux或AppArmor策略工程没放在自己的用户目录下而是放到了系统目录虽然能打开但是综合时写tmp文件失败。排查方法很简单Windows右键工程目录 → 属性 → 检查“只读”复选框是否勾选。注意“只读”在目录上可能是灰色状态需要用命令彻底清理。Linux用ls -l看目录权限重点看drwxrwxr-x里有没有w如果没有写权限就是问题所在。2.2 绝对路径“写死”导致的目录失效第二个典型原因是.xpr文件内部记录的路径和工程实际所在位置不对应。Vivado工程文件在保存时会按照设置决定使用相对路径还是绝对路径。默认情况下如果工程是新建的Vivado在.xpr里写入的路径有可能是绝对路径也就是类似C:/Users/xxx/project/project.srcs/sources_1/new/top.v这种。一旦你把工程从C:\Users\old_name复制到D:\FPGA_work路径就全变了。Vivado打开时还按老路径去找源文件和运行目录找不到它在创建缺失目录时也会触发Unable to create directory。这里有个很多人忽略的细节这个报错不一定在双击打开工程时报也可能是后续执行综合时突然出现。因为打开工程时Vivado只加载工程描述真正需要创建.runs目录的时间点是在启动综合/实现时。所以如果你打开工程成功但一跑综合就报17-1294大概率也是内部路径有问题。2.3 工程残留的锁文件与临时文件还有一种情况是工程目录里残留了上一次运行时的锁文件。Vivado在打开工程时有时会在.runs目录里生成.lock文件或者某些临时状态文件。如果原来的工程没有正常关闭比如强杀进程、蓝屏、直接关机这些锁文件会留在那里。复制到新位置后Vivado检测到这些残留文件尝试覆盖或重建时出现问题也会报无法创建目录。我自己实际遇到过一次同事把工程放在U盘里拷给我U盘拔下来之前他直接关掉了Vivado跑过来拷工程。结果我解压打开后报了17-1294而且报错路径指向.runs/impl_1下面的一个.log文件。后来全删掉工程目录重新解压才正常。就是那个文件状态不一致惹的祸。这类问题不常见但排查成本高因为你只看属性是看不出问题的。3. 实操解决流程从简单到彻底的三种方法3.1 方法一一行命令清理只读属性先说最直接的暴力清除方案。不管你是Windows还是Linux先做这一步90%的权限类问题能解决。Windows下以管理员身份打开命令提示符或PowerShell进入工程目录的上级目录执行attrib -R -S /s /d 工程目录名这条命令会把该目录下所有文件、子目录的只读属性、系统属性全部去掉。注意/s是递归处理子目录/d是处理目录本身两个参数都要带上。如果工程目录特别大命令可能需要跑一会儿耐心等命令执行完再打开工程。执行完建议看一眼属性对话框确认“只读”未被选中。Linux下进入工程目录的父目录执行chmod -R uw 工程目录名这条命令给当前用户递归添加写权限。如果工程文件是从别人那里拷过来的大概率owner不是自己必要的时候可以加上-R同时修改属主chown -R 用户名:用户组 工程目录名不过chown要看环境单机使用没必要服务器共享环境下建议先确认团队约定。3.2 方法二重置工程路径或删除.runs目录如果清理权限后依然报错那就把方向转向路径问题。操作思路是把可能导致路径失效的中间目录删掉让Vivado重新生成。具体做法先备份整个工程目录别嫌麻烦后面万一删错了还有后悔药。进入工程目录找到.runs文件夹整个删掉。也建议删除.cache文件夹可选建议删。用文本编辑器打开.xpr文件确认里面记录的路径是不是指向当前工程位置。再打开Vivado工程让它重新生成.runs目录。为什么删掉.runs能解决因为.runs里保存的是上一次综合/实现的全部产物包括中间网表、报告、日志、checkpoint文件。这些文件在复制过程中容易出现路径关联问题。Vivado加载工程时如果发现运行目录没有它会在需要时重新创建并执行综合。所以删掉不是偷懒是从机制上绕开老路径。用编辑器看.xpr文件时可以搜索工程里的源文件路径关键词如果发现路径指向的是一个已经不存在的盘符或目录说明源文件路径也废了。这时极大概率还要打开工程后重新添加源文件。这种情况下更彻底的方案是第三种。3.3 方法三重建工程最彻底的方案删除中间目录还不行的或者源文件路径已经彻底乱掉的直接重建工程最省心。步骤也简单新建一个空工程器件型号选择和原来一致。不勾选“Create File”之类的模板选项直接建空工程。在Sources窗口右键 → Add Sources → 把原来的.srcs目录里的源文件添加进去。添加约束文件Add Constraints把原来的.xdc文件加进去。设置器件型号和其他属性保持和原始工程一致。保存工程重新综合实现。这个方法看起来笨但胜在干净彻底。它能彻底摆脱原来工程里所有奇怪的路径、锁文件、缓存问题。我处理过不少“复制后打不开”的工程有三分之一最后都是靠这种方法解决的特别是那种从老版本Vivado迁移到新版本的工程。补充一个技巧如果你手头没有原始源文件只是在Vivado工程里看到文件列表也可以在Tcl控制台输入以下命令快速列出当前工程的所有源文件路径get_files -all能拿到路径列表就能去磁盘上找实际文件然后在新工程里手动添加。4. 路径相对化与复制规范从源头规避报错4.1 在Vivado中开启相对路径保存我一直建议团队里的同事统一使用Vivado的“Archive Project”功能来备份和移交工程。这个功能会把工程打包成.prj文件旧版或者直接把整个工程归档成zip压缩包。最关键的是归档时Vivado会尽量使用相对路径保存工程信息这样恢复到任意路径都能正常打开不会出现绝对路径失效问题。操作路径File → Project → Archive Project然后选择保存位置。归档完成后你拿到这个归档文件在任意路径解压双击.xprVivado会按相对路径找到源代码和约束文件打开通常不会报17-1294。如果你不想归档只是想让当前工程切换到相对路径模式可以打开工程的Settings在Project相关选项里找Use relative paths for file references这类选项勾选后再保存一次工程。这样以后复制工程路径问题会大大减少。4.2 Linux下同款问题的额外坑Linux环境下复制工程除了文件权限还要注意符号链接问题。很多人习惯在工程里用ln -s把源文件软链到工程目录但复制工程时如果没有加-a参数保留符号链接软链就会失效Vivado打开工程后找不到实际文件有时表现也是无法创建目录。复制工程时建议用cp -a 工程目录/ 新位置/工程目录/-a参数保留权限、时间戳、符号链接。这样能避免大量莫名其妙的路径问题。另外注意如果工程原路径下存在/tmp或/var/tmp相关的临时文件引用这些在复制后一定会失效。Vivado在综合时会在临时目录生成脚本文件如果默认临时目录不可写也会表现成一种奇怪的“无法创建目录”报错。可以在Vivado的Settings里把临时目录改成当前用户有权限写的路径比如~/vivado_tmp。4.3 团队协作的高效做法如果你在团队里经常要共享工程我强烈建议别直接拷贝整个工程文件夹。Vivado工程的.runs、.cache动辄几GB拷贝起来慢而且容易不稳定。更高效的做法是只共享源代码、约束文件和TCL脚本。用TCL命令一键重建工程例如create_project project_name ./project -part xc7a35tcsg324-1 add_files -norecurse 源文件列表 add_files -fileset constrs_1 约束文件.xdc set_property top top_module [current_fileset]把这个脚本保存成.tcl文件放到版本库里。同事拉到代码后在Vivado Tcl控制台执行source create_project.tcl一条命令就把工程建好了永远不会出现复制后路径问题。我在实际项目里养成的习惯是任何时候要转交工程要么发归档文件要么发TCL脚本加源码。只有在自己机器上临时备份时才直接拷贝整个文件夹。这个习惯帮我省了无数争执时间。5. 常见问题速查表与排查清单5.1 常见问题速查表现象可能原因解决方法打开工程即报17-1294目录只读、无写权限attrib清除只读 / chmod加写权限打开工程正常综合时报17-1294.xpr路径失效、.runs残留状态删除.runs目录、检查路径指向报错路径指向旧盘符绝对路径被写死Archive Project重建或TCL重建工程报错路径指向.runs下某个文件锁文件残留删整个.runs目录后重跑综合U盘/共享盘直接打开工程报错NTFS权限或文件未拷完整先复制到本地再清属性打开Linux下复制后报错符号链接失效、权限不对cp -a复制chmod加权限5.2 排查顺序口诀我总结了一个排查口诀基本照着走不会错先权限、再路径、后重建。先权限检查目录和文件是否可写把只读属性清干净。这一步能解决一半以上的工程无法打开问题。再路径确认.xpr文件里记录的路径确认源文件、约束文件是否都在。这个步骤重点是看编译、综合之前的准备工作是否能完成。后重建以上两步都解决不了的就不要恋战直接重建工程或者用TCL脚本方式重建。Vivado工程本身就是一个描述性文件集合重建成本远低于一直报错排查的时间成本。还有个小细节Windows上如果工程目录所在的磁盘满了也可能报“Unable to create directory”。这个坑很隐蔽有一次我排查了半天权限和路径最后发现D盘只剩下100MBVivado想写综合日志都写不进去。所以排查时顺手看一眼磁盘剩余空间能节约不少时间。6. 一个建议把“复制后打开工程”变成“复制后重建工程”回到文章开头那个同事的案例他最后的解决方案其实很简单我把他的工程用Archive Project重新归档他拿回去解压后就正常打开了。权限、路径全部失效的问题被归档操作消解掉了。这里再分享一个我个人发现的小习惯当我要把工程从A机器复制到B机器除非两台机器环境完全一致比如都是同一用户名、同一安装路径、同一工程根目录否则我从来不会直接双击.xpr文件。我会在B机器上新建工程再把源文件和约束文件加进去。这个习惯看起来多花了10分钟但几乎从没被工程打开类问题卡过。做FPGA开发的人都知道环境问题有时候比代码问题还磨人。Vivado的Common 17-1294这类报错本质上是工程描述和实际环境不匹配的信号。理解了它背后的原理解决起来一点也不难。如果你的工程也出现了这个报错按上面的步骤排查一遍大多数情况都能在20分钟内搞定。
返回列表