此Vivado 2023.1版本笔者亲身加以实测, 遭遇过网表导入之后始终出现报错ERROR: [Synth 8-439]该状况, 还碰到黑盒未能被识别如此这般的问题隐患, 新手照着下边步骤逐个去……
此Vivado 2023.1版本笔者亲身加以实测, 遭遇过网表导入之后始终出现报错ERROR: [Synth 8-439]该状况, 还碰到黑盒未能被识别如此这般的问题隐患, 新手照着下边步骤逐个去操作, 便能够轻易避开这类常见的相关问题。
第一步 确认网表文件格式与版本匹配
将Vivado工程开启, 于左侧之中, 把Flow Navigator里的PROJECT MANAGER予以点击, 接着作出选择Settings, 在弹出的窗口里, 于左侧栏寻觅Synthesis, 在右侧栏目More Options那里, 填入-mode out_of_context。请注意, 网络表文档一定要跟你正在运用的Vivado版本以及目标器件系列相适配, 举例来说, 针对7系列器件来讲,使用Vivado 2020以上版本或许存在不兼容的情况。
【新手避坑】
出现较为常见的报错情况, 在进行导入操作之后, 系统提示为不支持的文件格式。
缘由在于, 网表有可能是经由以往版本的ISE所生成的.ngc格式,然而Vivado 2523这个版本此时此刻已经不再直接予以支持了。
应对之道为, 先借由Vivado自身所带的write_edif指令把.ngc转变为.edf, 或者径直于工程里面换用.dcp网表格式, 而后者的兼容性更为优良。
第二步 正确设置网表的顶层模块与约束
于Sources面板里头, 以右键点击方才导入的那个网表文件, 选取Set as Top, 要保证顶层模块名称跟网表内部所定义的顶层保持一致。随后于Constraints文件夹之下添加.xdc约束文件, 得明确声明所有IO引脚, 像:
set_property PACKAGE_PIN T8 [get_ports {clk}]
set_property IOSTANDARD LVCMOS33 [get_ports {clk}]
假若不进行约束, 那么在综合过程里, 默认的引脚分配就会陷入混乱状态, 进而会直接在布局阶段卡死。
【新手避坑】
常见出现的报错情况是, ERROR, 冒号后面显示, [Place 30 – 574], 存在这样的状况, 即对于在一个IO引脚与BUFG之间进行的路由, 其布局放置情况不佳。
原因:约束文件中时钟引脚没指定全局时钟缓冲器。
解决的一种办法是, 于约束文件当中添加这样的内容, 即set_property CLOCK_DEDICATED_ROUTE FALSE [get_nets {clk_IBUF}], 以此来强制实现绕开BUFG限制的操作, 或者去重新分配一个能够支持全局时钟的引脚, 像Bank 35那儿的专用时钟引脚这般。
第三步 运行综合时处理黑盒与未连接信号
于Flow Navigator里点击Run Synthesis, 待综合完毕之后, 开启Schematic视图, 双击以查看网表内部结构。若见到灰色方框标注呈Unknown, 那就表明此模块未被确切识别作黑盒。此情况下, 得手动于顶层文件里对黑盒模块进行实例化, 借助Verilog或者VHDL去撰写一份空壳宣告, 情形如下:
module u_black_box (
input clk,
input rst,
output reg [7:0] data_out
);
endmodule
然后重新运行综合,网表就会自动连接上。
【新手避坑】
常见出现的报错内容为, CRITICAL WARNING, 也就是[Netlist 29 – 345], 存在未连接的内部端口, 名为’data_in’, 此端口位于块’u_black_box’之上。
其一, 网表内部端口未曾连接, 其二, 存在典型场景, 此场景乃是IP核网表欠缺外部驱动, 二者构成原因。
所需的解决化解之方法是: 去将IP Catalog予以打开, 随后双击与之相对应的IP核, 紧接着到Output Products标签页面当中去挑选Generate从而重新生成网表, 又或者是在顶层模块那里给data_in直接赋予一个默认的值, 举例来说像wire [7:0] data_in = 8’b0;。
关键参数推荐最优值
针对Xilinx 7系列器件而言, 建议把综合策略的-flatten_hierarchy设定为rebuilt, 原因在于此种模式能够在维持网表完整性之际, 自行优化无连接的悬空引脚, 防止后续布局布线时出现大量Unrouted nets错误。
两种实操方案对比
方案一是将.edf网表直接予以导入, 方案二乃是运用.dcp网表再配合read_checkpoint命令。二者区别体现于: .edf其体积较小然而无法留存内部调试信息, 适宜用于最终交付;.dcp涵盖完整网表以及约束, 导入之后能够直接于Vivado之中查看内部节点波形, 适宜用于前期联调验证。要是你的目标属快速定位问题范畴, 那就选用.dcp;要是目的在于减小工程体积方面, 那就选择.edf。
完整报错及一站式解决
常见完整报错: 报错内容为ERROR, 其具体为[Common 17 – 69]Command failed, 也就是Failed to read netlist file ‘xxx.edf’ – No such file or directory, 同时还伴随WARNING, 即[Netlist 29 – 160]Could not find module ‘xxx’ in library ‘work’。解决流程是这样的: 首先, 要在工程目录那里确认.edf文件是不是存在, 要是缺失了, 那就从原始IP核目录复制一份过来;接着, 把read_edif命令的路径改成为绝对路径, 以此防止相对路径失效;最后, 在Settings里勾选Write incremental checkpoint, 强行让Vivado重建网表索引缓存。
本方法, 对于那种网表文件本身就损坏了, 或者编码被加密的场景, 是不适用的, 像第三方厂商给出的.edf加密版, 就没法直接进行编辑。在这个时候, 可以换用write_verilog -mode synth_stub去生成一个纯端口声明的.v文件, 用来替代原来的网表接入工程, 然后再配合约束, 手动去对接信号, 这样同样能够绕过导入失败的问题。
微信扫一扫
还没有评论呢,快来抢沙发~