[问答]

Vivado综合工具结果可以简单地依赖于实例的字符串名称吗？

2508 Zynq

问答对人有帮助，内容完整，我也想知道答案 0 嗨，大家好，我正在使用TCL脚本合成基于Zynq的系统，我发现只需更改实例的字符串名称（在我的情况下为axi_interconnect），输出结果就不同了。通常差异很小（但它们应该是空的!!!）但我刚刚发现它们变得很大的情况。例如，如果我替换这一行脚本 set processing_system7_0_axi_periph [create_bd_cell -type ip -vlnv xilinx.com:ip:axi_interconnect:2.1 processing_system7_0_axi_periph] 带有“aaaprocessing_system7_0_axi_periph”的字符串名称“processing_system7_0_axi_periph”（显然在这一行以及脚本中所有出现的字符串）我有@75MHz的第一选择所有的时序约束都被满足，而另一个时序失败了（见附图）。我有相同类型的问题，但在数字上略有不同，版本2016.4和Vivado的旧版本（2015.4.2）也是如此。简单地，一个实例的字符串名称可以导致实现逻辑的不同性能，面积和功耗？我可以想象一下原因，但我很难接受它。谢谢 V-意大利语以上来自于谷歌翻译以下为原文 Hi guys, I'm synthesizing a Zynq based system with a TCL script and I have discovered that simply changing the string name of an instance (an axi_interconnect in my case) the output results are different. Usually the differences are very small (but they should be null !!!) but I just discovered a case where they become substantial. For example if I replace in this row of script set processing_system7_0_axi_periph [ create_bd_cell -type ip -vlnv xilinx.com:ip:axi_interconnect:2.1 processing_system7_0_axi_periph ] the string name "processing_system7_0_axi_periph" with "aaaprocessing_system7_0_axi_periph" (obviously in this row and in all occurrences of this string inside the script) I have that @75MHz with the first choice all timing constraints are met, instead with the other one timing fails (see the attached image). I have the same type of issue, but numerically a little bit different, with version 2016.4 and with an older version (2015.4.2) of Vivado too. Can simply a string name of an instance leads to different performances, area and power consumptions of an implemented logic? I can maybe imagine the reason but I find hard to accept it. Thanks V-italiano 0
2019-4-23 10:40:29　　评论淘帖0 邀请回答您可以邀请以下用户，快速回答问题 × asd008 该类别下有 32 个回答。邀请回答 aaaa321 该类别下有 27 个回答。邀请回答 doublelove 该类别下有 26 个回答。邀请回答 vynywrwr 该类别下有 21 个回答。邀请回答 hgjhgd 该类别下有 19 个回答。邀请回答 bwerwer 该类别下有 18 个回答。邀请回答 hanyan533 该类别下有 18 个回答。邀请回答 Jaionm 该类别下有 18 个回答。邀请回答 wang2222222 该类别下有 17 个回答。邀请回答 handsomelchcpp 该类别下有 17 个回答。邀请回答 ningee 该类别下有 16 个回答。邀请回答 binro 该类别下有 16 个回答。邀请回答 wznnzw 该类别下有 15 个回答。邀请回答 myf888 该类别下有 15 个回答。邀请回答 guotong1984 该类别下有 14 个回答。邀请回答 yhxc 该类别下有 14 个回答。邀请回答 armortech 该类别下有 14 个回答。邀请回答 60user25 该类别下有 14 个回答。邀请回答 zcy615 该类别下有 14 个回答。邀请回答 wanglinhua2627 该类别下有 14 个回答。邀请回答举报钱敏相关推荐 • 物联网依赖于旧技术的原因是什么？ 1920 • 如何将字符串按输入顺序连接到字符串数组中？ 3588 • LABVIEW 字符串转数值 9563 • 如何把字符串公式并得出结果？ 4291 • （字符串公式求值） 4700 • 字符串数组与数值比大小？ 4675 • 搜索/替换字符串 5917 • 如何将16进制的字符串，利用循环进行自动加1，结果也必须也是16进制字符串 11156 • labview往excel存字符串000000，结果显示0 8610 • 如何去掉前面板字符串控件的边框？ 26048 1个回答

答案对人有帮助，有参考价值 0 嗨syedz，不幸的是我无法分享剧本，但我已经做了你建议我的检查; 日志文件是不同的，但是以与实例的不同实现兼容的方式。我确定两个脚本是相同的，只是对于这些字符串。请记住： 1）我使用文本编辑器的查找/替换工具进行了更改（不是手动）; 如果我尝试手动进行错误更改，例如忘记进行一些真正的连接，则Vivado合成失败 2）我发布的图片来自post_route_timing_summary.rpt，这两种情况非常不同; 而不是两个post_synth_timing_summary.rptfiles几乎是相同的，只有在初始日期信息（明显）和单排，两个脚本里面，我可以复制/粘贴在这里：低脉冲宽度快速RAMD32 / CLK N / A 1.250 6.666 5.416 axi_mem_intercon / s00_couplers / auto_pc /安装/ gen_axi4_axi3.axi3_conv_inst / USE_WRITE.write_addr_inst / USE_BURSTS.cmd_queue /安装/ fifo_gen_inst / inst_fifo_gen / gconvfifo.rf / grf.rf / gntv_or_sync_fifo.mem / gdm.dm_gen.dm / RAM_reg_0_31_0_5 / RAMA / CLK 低脉冲宽度快速RAMD32 / CLK不适用1.250 6.666 5.416 axi_mem_intercon / s00_couplers / auto_pc / inst / gen_axi4_axi3.axi3_conv_inst / USE_READ.USE_SPLIT_R.read_addr_inst / USE_R_CHANNEL.cmd_queue / inst / fifo_gen_inst / inst_fifo_gen / gconvfifo.rf / grf.rf / gntv_or_sync_fifo .MEM / gdm.dm_gen.dm / RAM_reg_0_31_0_0 / DP / CLK 3）如果我在同样的字符串名称但“zzzprocessing_system7_0_axi_periph”取代，而是以“aaaprocessing_system7_0_axi_periph”，该post_synth_timing_summary.rpt是相同的情况下，当我使用字符串“processing_system7_0_axi_periph”（在我的系统还有另一个名为axi_connect” axi_mem_intercon“），但其他两个报告（post_place和post_route）之间的差异......也许这是最奇怪的事情我的第一个假设是工具有一种字母数字解析实例来为它们分配结构资源/原语，在某些情况下，这些资源中的一些根据实现顺序结束实例或另一个实例。看起来更好看两个post_synth_timing_summary.rpt差异，而不是推断，可能会有不同的推断，总是出于alfabetic原因，但如果没有，那么资源/原语就会短缺。谢谢 V-意大利语以上来自于谷歌翻译以下为原文 Hi syedz, unfortunally I can't share the script, but I already made the checks that you suggest me; log files are different but in a compatible way with a different implementation of the instances. I sure that two scripts are identical except that only for these strings. Keep in mind that: 1) I made the change with find/replace tool of my text editor (not manually); if I try to make a wrong changing manually, for example forgetting to make some true connections, Vivado synthesis fails 2) image that I posted is taken from post_route_timing_summary.rpt that are very different in the two cases; instead two post_synth_timing_summary.rpt files are almost identical, except for initial date informations (obviously) and for a single row, inside two scripts, that I can copy/paste here: Low Pulse Width Fast RAMD32/CLK n/a 1.250 6.666 5.416 axi_mem_intercon/s00_couplers/auto_pc/inst/gen_axi4_axi3.axi3_conv_inst/USE_WRITE.write_addr_inst/USE_BURSTS.cmd_queue/inst/fifo_gen_inst/inst_fifo_gen/gconvfifo.rf/grf.rf/gntv_or_sync_fifo.mem/gdm.dm_gen.dm/RAM_reg_0_31_0_5/RAMA/CLK Low Pulse Width Fast RAMD32/CLK n/a 1.250 6.666 5.416 axi_mem_intercon/s00_couplers/auto_pc/inst/gen_axi4_axi3.axi3_conv_inst/USE_READ.USE_SPLIT_R.read_addr_inst/USE_R_CHANNEL.cmd_queue/inst/fifo_gen_inst/inst_fifo_gen/gconvfifo.rf/grf.rf/gntv_or_sync_fifo.mem/gdm.dm_gen.dm/RAM_reg_0_31_0_0/DP/CLK 3) if I replace in same way the string name but with "zzzprocessing_system7_0_axi_periph", instead that with "aaaprocessing_system7_0_axi_periph", the post_synth_timing_summary.rpt is identical to the case when I use the string "processing_system7_0_axi_periph" (in my system there's another axi_connect called "axi_mem_intercon"), but the other two reports (post_place and post_route) are yet differents between them...and perhaps it is the strangest thing My first hypothesis was that there is a sort of alphanumeric parsing of instances by the tool to assign them fabric resources/primitives and in some cases some of these resources end for an instance or for another one depending on the implementing order. Looking better the two post_synth_timing_summary.rpt differences it seems me instead that something is maybe differently inferred, always for alfabetic reasons, but without that there is a shortage of resources/primitives. Thanks V-italiano

2019-4-23 11:09:15 评论举报吕钢格