完善资料让更多小伙伴认识你,还能领取20积分哦, 立即完善>
嗨,
我有一个实施OOC的模块。 现在我有一个顶级模块,其中此OOC实现的模块作为检查点导入。 在顶层生成了这些OOC模块的许多实例。 现在甚至,顶级模块不是精确的顶级,我的意思是我想运行OOC合成和这个伪顶级模块的实现。 这可能吗? 我正在OOC检查点读取并使用模式out_of_contex和top作为顶部运行synth_design。 我不希望IO缓冲区插入顶部。 我这样做是为了对正常合成和上下文合成之间的时间进行比较研究。 我为重用的ooc模块设置了dont_touch属性。 是否应该为顶级模块设置dont_touch? 接下来的问题是,底层ooc实现中已经读取了约束文件。 顶级重用相同。 我相信没有必要再次读取xdc文件。 另外,在运行top ooc合成之前,是否应该创建一个pblock并将底部ooc模块添加到其中? 最后,是否应将black box属性设置为顶层模块中生成的实例? 这是一个示例代码: //底层OOC实现模块 (* dont_touch =“true”*)module qpe_dummy( clk_dnoc_i, reset_n_dnoc_i, clk_ref_i, reset_n_ref_i, ...... ); //重新生成/生成的顶级: 模块qpe_mesh( clk_dnoc_i, reset_n_dnoc_i, clk_ref_i, reset_n_ref_i, scan_mode_i ); .... genvar i; 生成 for(i = 0;我请帮忙。 问候 一个热切的学生 以上来自于谷歌翻译 以下为原文 Hi, I have module which is implemented OOC. Now I have a top level module where this OOC implemented module imported as a checkpoint. A number of instances of these OOC modules are generated at the top level. Now even, the top level module is not the exact top level, I mean i want to run OOC synthesis and implementation of this pseudo top module. Is this possible? I am reading in the OOC checkpoint and running synth_design with mode out_of_contex and top as top. I dont want IO Buffers to be inserted at the top. I am doing this for a comparison study for the time it takes between normal synthesis and out of context synthesis. I have dont_touch property set for the reused ooc module. Should dont_touch also be set for the top module? Next question is, a constraints file is already read in the bottom ooc implementation. The top level reuses the same. I believe there is no need to read the xdc file again. Also, should a pblock be created and the bottom ooc module be added to this before running top ooc synthesis? Lastly, should black box attribute be set to the instances being generated in the top module? Here is a sample code: //Bottom level OOC implemented module(*dont_touch = "true"*) module qpe_dummy(clk_dnoc_i,reset_n_dnoc_i, clk_ref_i,reset_n_ref_i,......);//Top level in which it is resued/generated:module qpe_mesh(clk_dnoc_i,reset_n_dnoc_i, clk_ref_i,reset_n_ref_i,scan_mode_i);....genvar i;generatefor(i = 0; i < 5; i=i+1)begin:l_top_mesh(*black_box*)qpe_dummy i_qpe_dummy(....ports);end//l_top_meshendgenerate);endmodulePlease help with this. Regards An eager student |
|
相关推荐
9个回答
|
|
你好@ prateekj212
我有一个实施OOC的模块。 现在我有一个顶级模块,其中此OOC实现的模块作为检查点导入。 在顶层生成了这些OOC模块的许多实例。 现在甚至,顶级模块不是精确的顶级,我的意思是我想运行OOC合成和这个伪顶级模块的实现。 这可能吗? 我相信只要您在OOC模块的较低级别的OOC模式下没有任何Xilinx IP,您就可以运行伪顶模块(根据您的说法,它不是精确的顶部)。 此外,如果OOC模块上没有参数,或者OOC模块的端口是用户定义的类型。 请参阅以下链接,第25页: https://www.xilinx.com/support/documentation/sw_manuals/xilinx2017_4/ug901-vivado-synthesis.pdf 接下来的问题是,底层ooc实现中已经读取了约束文件。 顶级重用相同。 我相信没有必要再次读取xdc文件。 ooc运行xdc是作用域xdc,即它们只有在设置为ooc的模块中有范围。 您能否验证这些模块(ooc)xdc文件是否在其上设置了SCOPED_TO_CELLS和SCOPED_TO_REF属性。 您还可以检查.runs / synth_1文件夹中的tcl文件,以查看顶部运行是否已读取ooc xdc。 仅供参考还可以选择设置块级综合以在项目中设置特定层次结构的属性,策略。 请参阅上面的链接更多信息。 问候 罗希特 RegardsRohit ------------------------------------------------- ---------------------------------------------请注意 - 请注明 答案为“接受为解决方案”,如果提供的信息是有帮助的。给予您认为有用并回复导向的帖子。感谢K-- -------------------------------------------------- ---------------------- 以上来自于谷歌翻译 以下为原文 Hi @prateekj212 I have module which is implemented OOC. Now I have a top level module where this OOC implemented module imported as a checkpoint. A number of instances of these OOC modules are generated at the top level. Now even, the top level module is not the exact top level, I mean i want to run OOC synthesis and implementation of this pseudo top module. Is this possible? I believe you can run the pseudo top module (which is not exact top as per you) as ooc as long as you don't have any Xilinx IP in OOC mode in the lower-levels of the OOC module. Also if there are no parameters on the OOC module, or the ports of the OOC module are user-defined types. Refer the link below, page 25: https://www.xilinx.com/support/documentation/sw_manuals/xilinx2017_4/ug901-vivado-synthesis.pdf Next question is, a constraints file is already read in the bottom ooc implementation. The top level reuses the same. I believe there is no need to read the xdc file again. ooc runs xdc are scoped xdc i.e they have there scope only in the module which is set as ooc. Can you verify whether these modules(ooc) xdc file have SCOPED_TO_CELLS and SCOPED_TO_REF property set on them. You can also check for the tcl file in <>.runs/synth_1 folder to see if the ooc xdc been read by top run. Just FYI There is also option to set block level synthesis to set property, strategy on particular hierarchy in the project. Refer the above link more info on that. Regards Rohit Regards Rohit ---------------------------------------------------------------------------------------------- Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful. Give Kudos to a post which you think is helpful and reply oriented. ---------------------------------------------------------------------------------------------- |
|
|
|
ooc模块中有参数被合成和实现。
这是否意味着使用它的最高级别不能再次作为OOC运行? 我正在努力理解(因为我是Vivado的新手),synth_design和link_design之间的区别以及使用它们的正确上下文。 我通常有一个tcl脚本流程: read_verilog文件.. read_verilog头文件.. read_xdc约束.. synth_design -mode out_of_context -part some_part -flatten_hierarchy rebuilt -top ooc_module_to_be_resued #optional opt_design place_design #optional phys_opt_design route_designwrite_checkpoint ooc_moduleNow在顶层: read_checkpoint ooc_module.dcp#我相信这里也可以使用open_checkpoint ...那么哪个更好? #the文件说ooc检查点不会自动加载设计...以便于在设计中添加更多ooc .dcp文件.... add_files top.v 要么 read_verilog top.v link_design -top pseudo_top -mode out_of_context -part somepart 或者synth_design -top top.v flatten same ... .same ... part 又来了 再次路线 #what应该在重用流程中使用?请帮忙。 谢谢 热切的学生 以上来自于谷歌翻译 以下为原文 There are parameters in the ooc module which is synthesised and implemented. Does that mean the top level in which it is used cannot be run as OOC again? I am struggling with understanding( Since I am new to Vivado) the difference between synth_design and link_design and the correct context in which to use them. I have a tcl script flow typically: read_verilog files..read_verilog header files..read_xdc constraints ..synth_design -mode out_of_context -part some_part -flatten_hierarchy rebuilt -top ooc_module_to_be_resued#optional opt_designplace_design#optional phys_opt_designroute_design write_checkpoint ooc_moduleNow in the top level: read_checkpoint ooc_module.dcp # i believe here open_checkpoint also can be used... So which is better? #the document says ooc checkpoints dont automatically load a design... in order to facilitate adding more ooc .dcp files in to the design....add_files top.vorread_verilog top.vlink_design -top pseudo_top -mode out_of_context -part somepartor synth_design -top top.v flatten same.. .same... partagain placeagain route#what should be used in the reuse flow? Please help. Thanks Eager student |
|
|
|
你好@ prateekj212
ooc模块中有参数被合成和实现。 这是否意味着使用它的最高级别不能再次作为OOC运行? 我建议全局合成ooc模块而不是ooc,因为这样做可能会导致流程的后续部分出错。 对于顶级,应使用open_checkpoint命令而不是read_checkpoint命令,因为open_checkpoint将读取检查点,在内存设计中创建并初始化项目中的设计。 如果您希望使用read_checkpoint,那么您还需要在脚本中包含link_design。 请参阅以下链接,第49页: https://www.xilinx.com/support/documentation/sw_manuals/xilinx2017_4/ug904-vivado-implementation.pdf 问候 罗希特 RegardsRohit ------------------------------------------------- ---------------------------------------------请注意 - 请注明 答案为“接受为解决方案”,如果提供的信息是有帮助的。给予您认为有用并回复导向的帖子。感谢K-- -------------------------------------------------- ---------------------- 以上来自于谷歌翻译 以下为原文 Hi @prateekj212 There are parameters in the ooc module which is synthesised and implemented. Does that mean the top level in which it is used cannot be run as OOC again? I would suggest to synthesize the ooc module globally and not as ooc as doing this can cause errors in later part of the flow. For your top level, open_checkpoint command should be used over read_checkpoint command as open_checkpoint will read the checkpoint, create in memory design and initialize the design in the project. If you wish to use read_checkpoint then you need to include link_design as well in your script. Refer the link below, page 49: https://www.xilinx.com/support/documentation/sw_manuals/xilinx2017_4/ug904-vivado-implementation.pdf Regards Rohit Regards Rohit ---------------------------------------------------------------------------------------------- Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful. Give Kudos to a post which you think is helpful and reply oriented. ---------------------------------------------------------------------------------------------- |
|
|
|
我不确定你在全球的意思。
你的意思是正常合成吗? 如果我进行正常的合成,它将插入IO缓冲区,这是我不想要的。 问候 一个热切的学生 以上来自于谷歌翻译 以下为原文 I am not sure what you mean by globally. Do you mean normal synthesis? If I do normal synthesis, it will insert IO buffers, which I do not want. regards an eager student |
|
|
|
你好@ prateekj212
我不确定你在全球的意思。 你的意思是正常合成吗? 是 我要求你正常合成你的ooc模块(根据你的命名约定),它有参数。 但您可以将读取ooc模块检查点的模块设置为ooc。 问候 罗希特 RegardsRohit ------------------------------------------------- ---------------------------------------------请注意 - 请注明 答案为“接受为解决方案”,如果提供的信息是有帮助的。给予您认为有用并回复导向的帖子。感谢K-- -------------------------------------------------- ---------------------- 以上来自于谷歌翻译 以下为原文 Hi @prateekj212 I am not sure what you mean by globally. Do you mean normal synthesis? Yes I asked you to do the normal synthesis of your ooc module (naming convention as per you) which has parameters. But you can set the module which reads ooc module checkpoint as ooc. Regards Rohit Regards Rohit ---------------------------------------------------------------------------------------------- Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful. Give Kudos to a post which you think is helpful and reply oriented. ---------------------------------------------------------------------------------------------- |
|
|
|
我在这里面临一个问题。
通过正常读取verilog文件,然后第二次通过读取设计检查点文件进行预合成和路由设计,我用完了顶层的上下文合成。 我的问题是第二种情况不应该比第一种情况更快吗? 我得到运行时结果,其中第二种情况比第一种情况花费的时间加倍。 为什么会这样? 我需要证明使用上下文合成。 请帮忙 以上来自于谷歌翻译 以下为原文 I am facing an issue here. I ran out of context synthesis for the top level by normally reading verilog files and then a second time by reading in a design checkpoint file for a presynthesised and routed design. My question is shouldnt the second scenario be faster than the first one? I am getting runtime results where second scenario takes double the time taken than the first. Why is this happening? I need to justify using out of context synthesis. Please help |
|
|
|
嗨@ prateekj212。
我想在你的上一篇文章中澄清“我用完顶部的上下文合成”。 设计的顶层需要IO连接,因为非上下文合成,因此不清楚为什么使用OOC流。 在上下文之外使用的运行时优势是将设计的较低级别部分合成一次,而不是在运行全局(顶级)合成时合成这些部分。 Synthesis将OOC部分视为黑盒子,只读取没有逻辑的存根文件。由于存根文件不包含逻辑,因此不应该有与之关联的运行时。 如果要将read_checkpoint时间与OOC合成时间进行比较,那么如果运行时间相似,则OOC流可能不会有益。 较大的read_checpoint / open_checkpoint通常与读取运行时的约束相关。 运行report_methodology并在结果中搜索“runtime”可能会提供有关如何改进约束语法的建议。 如果OOC合成与read_checkpoint时间相似,则使用全局合成可能是要走的路,因为合成期间的跨边界优化可能会导致时序改进。 -------------------------------------------------- -----------------------不要忘记回答,kudo,并接受为解决方案.------------- -------------------------------------------------- ---------- 以上来自于谷歌翻译 以下为原文 Hi @prateekj212. I wanted to clarify on your last post with "I ran out of context synthesis for the top". The top-level of a design would need IO connectivity from a non-out of context synthesis, so it is not clear why the OOC flow is being used. The run time benefit of using out of context is having lower-level portions of a design synthesized once, and not synthesizing these when running global (top-level) synthesis. Synthesis sees the OOC portion as a black box, and only reads a stub file with no logic. As the stub file does not contain logic, there should be no run time associated with it. If you are comparing the read_checkpoint time with the OOC synthesis time, then the OOC flow might not be beneficial if the run times are similar. A larger read_checpoint/open_checkpoint typically is related to constraints reading run time. Running a report_methodology, and searching the result for "runtime" might give suggestions on how to improve constraint syntax. If the OOC synthesis vs. read_checkpoint times are similar, using global synthesis might be the way to go, as cross-boundary optimization during synthesis might result in timing improvements. ------------------------------------------------------------------------- Don’t forget to reply, kudo, and accept as solution. ------------------------------------------------------------------------- |
|
|
|
我想在你的上一篇文章中澄清“我用完了顶层的上下文综合”。设计的顶层需要IO连接,因为非上下文合成,所以不清楚为什么OOC流是
正在使用。 这样做是因为顶部本身是较大设计中的子块。 在上下文之外使用的运行时优势是将设计的较低级别部分合成一次,而不是在运行全局(顶级)合成时合成这些部分。 Synthesis将OOC部分视为黑盒子,只读取没有逻辑的存根文件。由于存根文件不包含逻辑,因此不应该有与之关联的运行时。 是的,较低级别的设计被合成一次(超出上下文)并存储为设计检查点。 这是在我的另一个模块(顶部)中导入的生成块(多个这样的模块)中,每个模块都设置了black_box属性。 我正在为每个black_box模块一次又一次地读取检查点。 此外,我将设计锁定到保存级别路由。 这有助于减少运行时间吗? 这是实际目的或目标。 如果要将read_checkpoint时间与OOC合成时间进行比较,那么如果运行时间相似,则OOC流可能不会有益。 较大的read_checpoint / open_checkpoint通常与读取运行时的约束相关。 运行report_methodology并在结果中搜索“runtime”可能会提供有关如何改进约束语法的建议。 如果OOC合成与read_checkpoint时间相似,则使用全局合成可能是要走的路,因为合成期间的跨边界优化可能会导致时序改进。 我可以试试这个。 以上来自于谷歌翻译 以下为原文 I wanted to clarify on your last post with "I ran out of context synthesis for the top".The top-level of a design would need IO connectivity from a non-out of context synthesis, so it is not clear why the OOC flow is being used. This is done because the top itself is a subblock in a larger design. The run time benefit of using out of context is having lower-level portions of a design synthesized once, and not synthesizing these when running global (top-level) synthesis. Synthesis sees the OOC portion as a black box, and only reads a stub file with no logic. As the stub file does not contain logic, there should be no run time associated with it. Yes the lower level design is synthesised once(Out-of-context) and stored as a design checkpoint. This is imported in my another module(top) in a generate block(mutiple such modules) each having a black_box attribute set. I am reading the checkpoint again and again for each black_box module. Also I am locking down the design to the preservation level routing. Does this help in reducing runtime? This is the actual purpose or goal. If you are comparing the read_checkpoint time with the OOC synthesis time, then the OOC flow might not be beneficial if the run times are similar. A larger read_checpoint/open_checkpoint typically is related to constraints reading run time. Running a report_methodology, and searching the result for "runtime" might give suggestions on how to improve constraint syntax. If the OOC synthesis vs. read_checkpoint times are similar, using global synthesis might be the way to go, as cross-boundary optimization during synthesis might result in timing improvements. I can try this. |
|
|
|
嗨@ prateekj212。
谢谢你的澄清。 我肯定会权衡OOC与全球流量的运行时选项,看看这个设计哪个最好的套件。 通常,子模块合成运行时间远大于open_checkpoint,这将使OOC流程成为更好的选择。 lock_deisgn命令并不意味着改善运行时,并且可能会根据设计的不同而影响运行时间。 但是,增量编译流程的主要目标之一是减少运行时间。 该流程将在不同版本的设计之间重用尽可能多的布局和布线信息。 -------------------------------------------------- -----------------------不要忘记回答,kudo,并接受为解决方案.------------- -------------------------------------------------- ---------- 以上来自于谷歌翻译 以下为原文 Hi @prateekj212. Thanks for the clarification. I would definitely weigh the run time options of the OOC vs global flow to see which best suites this design. Typically, the sub-module synthesis run time is much greater than the open_checkpoint, which would make the OOC flow a better option. The lock_deisgn command is not meant to improve runtime, and might affect run time differently depending on the design. However, one of the main goals of the incremental compile flow is to reduce run time. This flow would reuse as much of the placement and routing information as possible between differing versions of the design. ------------------------------------------------------------------------- Don’t forget to reply, kudo, and accept as solution. ------------------------------------------------------------------------- |
|
|
|
只有小组成员才能发言,加入小组>>
2215 浏览 7 评论
2640 浏览 4 评论
Spartan 3-AN时钟和VHDL让ISE合成时出现错误该怎么办?
2119 浏览 9 评论
3188 浏览 0 评论
如何在RTL或xilinx spartan fpga的约束文件中插入1.56ns延迟缓冲区?
2243 浏览 15 评论
有输入,但是LVDS_25的FPGA内部接收不到数据,为什么?
491浏览 1评论
1569浏览 1评论
在使用xc5vsx95T时JTAG扫片不成功,测量TDO无信号输出
2217浏览 0评论
543浏览 0评论
1703浏览 0评论
小黑屋| 手机版| Archiver| 电子发烧友 ( 湘ICP备2023018690号 )
GMT+8, 2024-6-26 12:40 , Processed in 1.232533 second(s), Total 63, Slave 57 queries .
Powered by 电子发烧友网
© 2015 bbs.elecfans.com
关注我们的微信
下载发烧友APP
电子发烧友观察
版权所有 © 湖南华秋数字科技有限公司
电子发烧友 (电路图) 湘公网安备 43011202000918 号 电信与信息服务业务经营许可证:合字B2-20210191