完善资料让更多小伙伴认识你,还能领取20积分哦, 立即完善>
我正在使用Vivado 2018.1在spartan 7(xc7s50csga324-1)中实现一个设计。
我有一个有效的设计,并计划逐步添加功能。 但是,正如我所做的那样,我偶尔会得到在硬件中没有按预期工作的构建。 起初,我认为这只是错误。 当我深入研究它时,这个问题似乎与逻辑无关 - 我通过稍微修改逻辑,删除逻辑和/或添加逻辑来进行实验 - 有时候构建会在考虑到变化的情况下按预期工作,有时它不起作用。 举个例子:我修改了设计,将寄存器A绑定到一个常量 - 设计工作。 当一个简单的控制信号被断言(即寄存器写入发生)时,我修改了设计以更新寄存器A - 设计没有按预期工作。 我修改了设计,根据更复杂的控制信号断言更新寄存器A(即在一系列事件之后设置控制) - 设计工作。 对于没有按预期工作的构建,破坏的构建似乎表现出相同的方式。 似乎与设计没有任何关联。 我尝试了多次迭代插入调试探针(除了sims也没有显示任何问题),没有任何运气找到问题。 但是,我尝试了一个奇怪的结果的实验是当我将调试探针添加到工作版本时。 没有探针,构建工作。 使用探针,构建不起作用。 我也尝试过增量版本,但这似乎也没有任何区别。 所有构建都已通过计时(即使使用调试探针)。 该设计具有一个时钟域(100MHz)。 所有io路径(除了一些不关心)都受到限制。 LUT利用率仅为5%左右,但是使用率超过70%。 没有意外的syn或par警告。 brams上有一些drc错误(1839/1840错误用于brams上的异步/同步复位)但是,据我所知,这些并不是意料之外的(即使ram控制信号同步复位,我也无法摆脱它们) 。 是否有任何关于导致这些不一致结果的建议? 以上来自于谷歌翻译 以下为原文 I am implementing a design in a spartan 7 (xc7s50csga324-1) using Vivado 2018.1. I have a design that worked and was planning on gradually adding functionality. However, as I did this, I was occasionally getting builds that did not work as expected in hardware. At first, I thought it was just bugs. As I dug into it, the problem does not seem to be related to logic - I experimented by slightly modifying the logic, removing logic, and/or adding logic - sometimes the build worked as expected considering the changes and sometimes it did not work. As an example: I modified design to tie register A to a constant - the design worked. I modified design to update register A when a simple control signal asserted (i.e. register write occurred) - the design did not work as expected. I modified design to update register A based on a more complicated control signal assert (i.e. control is set after a series of events) - the design worked. For the builds that did not work as expected, the broken builds all seemed to behave the same way. There does not seem to be any correlation to the design. I tried numerous iterations of inserting debug probes (besides sims which also did not show any issue) without any luck finding the issue. However, one experiment I tried with odd results was when I added debug probes to a working build. Without the probes, the build worked. With the probes, the build did not work. I also tried doing incremental builds but that did not seem to make any difference either. All builds have passed timing (even with the debug probes). The design has one clock domain (100MHz). All io paths (except for some don't cares) are constrained. LUT utilization is only around 5%, but bram utilization is over 70%. There are no unexpected syn or par warnings. There are some drc errors on the brams (1839/1840 errors for async/sync resets on brams) but, as I understand it, these are not unexpected (nor can I get rid of them even though the ram control signals are reset synchronously). Are there any suggestions on what can be causing these inconsistent results? |
|
相关推荐
4个回答
|
|
@addnamehere
由于这是单时钟域设计,我认为这不应该是任何CDC问题,这是设计在硬件上失败的常见原因,即使它们满足时序。 我建议检查/修复与BRAM相关的可能导致此问题的drcmessages。 还运行report_methodology并查看结果。 --Syed -------------------------------------------------- -------------------------------------------请注意 - 请标记答案 如果提供的信息有用,请“接受为解决方案”。给予您认为有用并回复导向的帖子。感谢Kudos .------------------------ -------------------------------------------------- ------------------- 以上来自于谷歌翻译 以下为原文 @addnamehere Since this is single clock domain design I believe this shouldn't be any CDC issue which is the common reason for design failing on hardware even if they met timing. I would suggest to check/fix on the drc messages related to BRAM which could be causing this issue. Also run report_methodology and see the result. --Syed --------------------------------------------------------------------------------------------- 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. --------------------------------------------------------------------------------------------- |
|
|
|
谢谢你的建议。
我试图摆脱bram drc并打破类似于所有其他破坏版本的构建。 方法报告除了我已经提到的那些问题之外,没有任何其他问题。 我准备用调试探针重新做我的所有构建,看看我是否错过了什么。 所以,我做了一些改变,我知道会破坏设计 - 它做到了。 然后我插入探针,然后设计工作 - 这是唯一的变化 - 添加探针。 然后我保留了探针并做了许多改变,以前总是打破了设计。 但是,设计仍然有效。 我很难绕过这个结果。 我拿出所有这些变化的探针,设计再次破裂。 然后我重新添加了探针,设计工作正常。 添加探针的任何想法似乎解决了一切? 以上来自于谷歌翻译 以下为原文 Thanks for your suggestions. I tried getting rid of the bram drc and that broke builds similar to all the other broken builds. The methodology report did not contain any other issues other than the bram ones I already mentioned. I was about to re-do all my builds again with debug probes to see if I missed something. So, I made changes I know would break the design - which it did. I then inserted probes and then the design worked - that was the only change - adding probes. I then kept the probes in and made numerous changes that always broke the design before. However, the design still worked. I have a hard time wrapping my head around this result. I took the probes out with all these changes and the design broke again. I then re-added the probes and the design worked. Any ideas why adding probes seems to fix everything? |
|
|
|
你好@ addnamehere。
有没有关于设计如何失败的更多信息? 具体来说,是否存在可以使用Debug Core在上游跟踪的错误值? 在错误的时间看到正确的数据吗? 添加探针的行为可能与时间相关。 两个版本之间的差异主要是路径具有不同延迟的布局和布线。 设计基线是验证时间的好方法。 http://www.xilinx.com/support/documentation/sw_manuals/xilinx2018_2/ug949-vivado-design-methodology.pdf -------------------------------------------------- -----------------------不要忘记回答,kudo,并接受为解决方案.------------- -------------------------------------------------- ---------- 以上来自于谷歌翻译 以下为原文 Hi @addnamehere. Is there any more information on how the design is failing? Specifically, is there an incorrect value that can be traced upstream with the Debug Core? Is the correct data seen at the wrong time? The behavior surrounding adding probes could be timing related. The difference between the two versions would mainly be placement and routing where paths would have different delays. Baselining the design would be a good way to verify the timing. http://www.xilinx.com/support/documentation/sw_manuals/xilinx2018_2/ug949-vivado-design-methodology.pdf ------------------------------------------------------------------------- Don’t forget to reply, kudo, and accept as solution. ------------------------------------------------------------------------- |
|
|
|
该设计连接到几个LED字符串。
当设计失败时,指示灯未正确点亮。 有趣的是,只要设计失败,不正确的led模式就是一致的。 不确定什么基线会有所帮助 - 设计完全同步,逻辑也很复杂。 检查时机是好的。 关于io的错误路径约束有一些评论 - 但这些都没关系。 此外,我将数据表报告与工作和非工作设计进行了比较,并且io时序是相同的。 这是时间总结(对不起,难以阅读)...... -------------------------------------------------- ---------------------------------------------- | 设计时序摘要| -------------------------------------------------- -------------------------------------------------- ----------------- WNS(ns)TNS(ns)TNS失败端点TNS总端点WHS(ns)THS(ns)THS失败端点THS总端点WPWS(ns)TPWS(ns)TPWS失败端点TPWS总端点------- - ------ --------------------- ------------------- ---- --- ------- --------------------- ------------------- -------- -------- ---------------------- ------------ -------- 1.517 0.000 0 13695 0.015 0.000 0 13679 3.750 0.000 0 4923 满足所有用户指定的时序约束。 我同意这个问题可能与时间有关,但设计受到限制,所以我希望报告违规行为。 也许事实上,设计使用如此多的bram而不是luts引起了一个问题? 以上来自于谷歌翻译 以下为原文 The design is connected to a couple of led strings. When the design fails, the leds are not lit correctly. Interestingly, the incorrect led pattern is consistent whenever the design fails. Not sure what baselining would help with - the design is completely synchronous nor is the logic that complicated. Check timing is good. There are some comments about the false path constraints on the io - but those are okay. Further, I compared datasheet reports against a working and non-working design and the io timings are identical. Here is the timing summary (sorry hard to read)... ------------------------------------------------------------------------------------------------ | Design Timing Summary | --------------------- ------------------------------------------------------------------------------------------------ WNS(ns) TNS(ns) TNS Failing Endpoints TNS Total Endpoints WHS(ns) THS(ns) THS Failing Endpoints THS Total Endpoints WPWS(ns) TPWS(ns) TPWS Failing Endpoints TPWS Total Endpoints ------- ------- --------------------- ------------------- ------- ------- --------------------- ------------------- -------- -------- ---------------------- -------------------- 1.517 0.000 0 13695 0.015 0.000 0 13679 3.750 0.000 0 4923 All user specified timing constraints are met. I agree that the issue could be related to timing, but the design is constrained so I would expect violations to be reported. Maybe the fact that the design uses so much bram compared to luts is causing an issue? |
|
|
|
只有小组成员才能发言,加入小组>>
2379 浏览 7 评论
2794 浏览 4 评论
Spartan 3-AN时钟和VHDL让ISE合成时出现错误该怎么办?
2261 浏览 9 评论
3335 浏览 0 评论
如何在RTL或xilinx spartan fpga的约束文件中插入1.56ns延迟缓冲区?
2427 浏览 15 评论
有输入,但是LVDS_25的FPGA内部接收不到数据,为什么?
754浏览 1评论
请问vc707的电源线是如何连接的,我这边可能出现了缺失元件的情况导致无法供电
543浏览 1评论
求一块XILINX开发板KC705,VC707,KC105和KCU1500
364浏览 1评论
1960浏览 0评论
681浏览 0评论
小黑屋| 手机版| Archiver| 电子发烧友 ( 湘ICP备2023018690号 )
GMT+8, 2024-11-21 21:52 , Processed in 1.169889 second(s), Total 52, Slave 45 queries .
Powered by 电子发烧友网
© 2015 bbs.elecfans.com
关注我们的微信
下载发烧友APP
电子发烧友观察
版权所有 © 湖南华秋数字科技有限公司
电子发烧友 (电路图) 湘公网安备 43011202000918 号 电信与信息服务业务经营许可证:合字B2-20210191 工商网监 湘ICP备2023018690号