1
完善资料让更多小伙伴认识你,还能领取20积分哦, 立即完善>
喜
我有一个在virtex6设备上使用ISE 14.1实现的设计。 当我查看最终设计摘要时,我有2个不符合的约束。 clk1,约束到150MHz(6.66ns) - ISE表示最坏情况松弛(设置)= -7.858ns,最佳情况可实现= 14.46ns(即6.66ns + 7.8ns) clk2,约束到150MHz(6.66ns) - ISE表示最坏情况松弛(设置)= -4.3ns,最佳情况可实现= 16.31ns 没有保留时间违规(即时间报告中的+松弛) 对于clk1,可以看出,设置松弛和周期相加可以得到最佳的可实现频率。 但是对于clk2,设置松弛和clk约束没有添加给16.31ns ...我想知道该工具如何设法达到16.31ns? 事实上,最坏情况下的松弛和最佳案例在时期方面不可匹敌 - 这是一个工具问题或与代码本身有关吗???? 我应该更重视哪个价值? 设置松弛或最佳案例可实现? 谢谢你的投入, ž。 以上来自于谷歌翻译 以下为原文 hi, i have a design which ive implemented using ISE 14.1 on a virtex6 device. when i look at the final design summary, i have 2 constraints that are not met. clk1, constrained to 150MHz (6.66ns) - ISE says Worst case slack (setup) = -7.858ns, best case achievable = 14.46ns (i.e. 6.66ns + 7.8ns) clk2, constrained to 150MHz (6.66ns) - ISE says Worst case slack (setup) = -4.3ns, best case achievable = 16.31ns there are no hold time violations (i.e. +ve slack in the timing report) for clk1, as can be seen, the setup slack and the period add up to give the best achievable freq. but for clk2, the setup slack and clk constraint donot add to give 16.31ns ... i was wondering how the tool is managing to get to 16.31ns? The fact that worst case slack and best case achievable in terms of period dont match - is this a tool issue or somthing to do with the code itself???? and which value should i give more importance to? the setup slack or the best case achievable? thanks for inputs, z. |
|
相关推荐
8个回答
|
|
你能发布clk2的最坏情况路径吗?
首先要解释的是差异。 也许两个不同的数字属于内部时钟和时钟间时序。 检查时钟交互。 - 如果提供的信息有用,请将答案标记为“接受为解决方案”。给予您认为有用且回复的帖子。 以上来自于谷歌翻译 以下为原文 can you post the worst case path for clk2? First thing would be to explain the difference. Maybe the two different numbers belong to intra vs inter clock timings. Check for clock interaction. - 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. |
|
|
|
一些可能性:
1)clk2使用正边缘和负边缘,并且松弛处于从一个边缘到另一个边缘的路径上。 2)clk2驱动PLL,MMCM或DCM,然后产生其他频率。 松弛在下游时钟之一上,并且与导出的时序约束相反。 然后,导出约束的最佳频率乘以PLL,MMCM或DCM中的频率比。 - Gabor 以上来自于谷歌翻译 以下为原文 Some possibilities: 1) clk2 uses both positive and negative edges, and the slack is on a path going from one edge to another. 2) clk2 drives a PLL, MMCM or DCM that in turn generates other frequencies. The slack is on one of the downstream clocks and is against a derived timing constraint. Then the best frequency for the derived constraint gets multiplied up by the frequency ratio in the PLL, MMCM or DCM. -- Gabor |
|
|
|
嗨gabor,
是的......你对理由#1是正确的。 clk2正在使用上升沿和下降沿(我只是看着代码并注意到了这一点) 我猜下一个问题是如何限制这样的路径? 在有关模块中发生的是 - 数据/控制信号输入@ 150MHz(6.66ns),即clk2。 它们在clk2的上升沿和下降沿被计时。 然后在clk2的上升边缘进一步发出。 对于这样一个模块/设计的限制是什么,因为我现在只是把时间段放在一边。 clk2上一条失败路径的示例时序报告 - Slack(设置路径):-1.983ns(要求 - (数据路径 - 时钟路径偏差+不确定性))来源:rgmii_2_gmii / gmii_rxd_d0_neg [7](FF)目的地:NTN_FPGA_TOP / NTN_TOP / emac_wrp / ip_toplevel / rxd_d [3](FF )要求:3.330ns数据路径延迟:5.355ns(逻辑电平= 2)时钟路径偏移:0.077ns(1.965 - 1.888)源时钟:clk2_c下降至3.330ns目标时钟:clk2_c上升至6.660ns时钟不确定度:0.035ns 以上来自于谷歌翻译 以下为原文 hi gabor, yes ... you are correct about reason #1. clk2 is using both rising and falling edge (i was just looking at the code and noticed this) i guess the next question is how to constraint such a path? whats happening in the module in question is that - data/control signals come in @ 150MHz (6.66ns), which is clk2. they are clocked at the rising and falling edge of clk2. And then sent out further at just the rising edgeof clk2. what would be the constraint for such a module/design as i am just putting the period consrtaint for now.? example timing report for one failing path on clk2 - Slack (setup path): -1.983ns (requirement - (data path - clock path skew + uncertainty)) Source: rgmii_2_gmii/gmii_rxd_d0_neg[7] (FF) Destination: NTN_FPGA_TOP/NTN_TOP/emac_wrp/ip_toplevel/rxd_d[3] (FF) Requirement: 3.330ns Data Path Delay: 5.355ns (Levels of Logic = 2) Clock Path Skew: 0.077ns (1.965 - 1.888) Source Clock: clk2_c falling at 3.330ns Destination Clock: clk2_c rising at 6.660ns Clock Uncertainty: 0.035ns |
|
|
|
时钟的周期是已知的,工具可以从时钟周期的上升沿到下降沿的时间是您的条件所需的全部(如果您有50%的占空比;如果没有,则需要定义下降沿的位置
)。 显然,只有上升沿到上升沿才能报告最佳时序,因此在这种情况下不适用。 - 如果提供的信息有用,请将答案标记为“接受为解决方案”。给予您认为有用且回复的帖子。 以上来自于谷歌翻译 以下为原文 The period of the clock is known and the tool can time from rising edge to falling edge so the clock period is all you need for your condition (if you have a 50% duty cycle; if not, you need to define where the falling edge is). Apparently best possible timing is reported only for rising edge to rising edge so it's not applicable in this case. - 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. |
|
|
|
喜
是的,我的期限约为50%。 那么我应该把它放进去并与失败的道路一起生活吗? 或者我可以添加任何其他约束吗? 是否有一些约束告诉工具对于特定模块,将时钟视为双边和约束或PAR是相应的? ž。 以上来自于谷歌翻译 以下为原文 hi, yes, i have the period constrained as 50%. so should i just leave that in and live with the failing paths? or is there any other constraint i can add? is there some constraint that tells the tool that for a particular module, consider the clock as dual edged and constrain or PAR is accordingly? z. |
|
|
|
不可以。除非它们不是真正的单时钟路径或者可以异步处理,否则你不能“忍受失败的路径”。
您需要修复这些路径。 从您发布的路径中,您在从一个时钟边缘到另一个时钟边缘的路径中有2个逻辑级别。 如果这不是假路径,则应考虑将逻辑移动到一个时钟边沿域或另一个时钟边缘域,而不是跨时钟边沿路径。 - Gabor 以上来自于谷歌翻译 以下为原文 No. You can't "live with the failing paths" unless they are not really single-clock paths or can be treated asynchronously. You need to fix these paths. From the path you posted, you have 2 levels of logic in a path going from one clock edge to another. If this is not a false path, you should consider moving the logic to exist in one clock-edge domain or the other, rather than in the cross-clock-edge path. -- Gabor |
|
|
|
嗨gabor,谢谢。
所以我只是简单地说你所说的 - 我猜你的意思是逻辑应该只是上升沿时钟或下降沿为时钟路径故障被移除。 这将带来逻辑上的变化。 根据你所说的,我的理解是否正确? 如果是,那么我面临的问题是逻辑无法改变,因为这是芯片的RTL。 所以有了这个限制,我有哪些其他选择? 我已经在SmartXplorer中尝试了xilinx多个位置和路由,我发布的路径是16次运行时间改进策略的最佳结果。 那么可以应用任何其他约束吗? 还有其他的尝试吗? ž。 以上来自于谷歌翻译 以下为原文 hi gabor, thanks. so i simplyfy what you said - i guess you mean the logic should be only rising edge clocked or falling edge clocked for the path failure to be removed. and this would entail a logic change. is my understanding correct based on what you said? if yes, then the constaint i am facing is that the logic cannot be changed because this is RTL for a chip. so with that restriction, what are the other options I have? I have already tried xilinx multiple place and route in SmartXplorer and the path i posted is the best result from 16 runs with timing improvement strategy. so any other constraint that can be applied? any other things to try? z. |
|
|
|
而且 - 看着路径,我看到rgmii_rxd_d [0]是源,但目的地是rgmii_rxd_d [3]。
所以我在想为什么从位d [0]到位d [3]的路径失败? 这是一条失败之路的特征吗? ž。 以上来自于谷歌翻译 以下为原文 and also - looking at the path, i see that the rgmii_rxd_d[0] is the source but the destination is rgmii_rxd_d[3]. so im thinking why is the path from bit d[0] to bit d[3] failing? is this the characteristics of a failing path? z. |
|
|
|
只有小组成员才能发言,加入小组>>
2420 浏览 7 评论
2823 浏览 4 评论
Spartan 3-AN时钟和VHDL让ISE合成时出现错误该怎么办?
2294 浏览 9 评论
3374 浏览 0 评论
如何在RTL或xilinx spartan fpga的约束文件中插入1.56ns延迟缓冲区?
2461 浏览 15 评论
有输入,但是LVDS_25的FPGA内部接收不到数据,为什么?
1175浏览 1评论
请问vc707的电源线是如何连接的,我这边可能出现了缺失元件的情况导致无法供电
587浏览 1评论
求一块XILINX开发板KC705,VC707,KC105和KCU1500
451浏览 1评论
2005浏览 0评论
731浏览 0评论
小黑屋| 手机版| Archiver| 德赢Vwin官网 ( 湘ICP备2023018690号 )
GMT+8, 2024-12-23 18:55 , Processed in 1.493567 second(s), Total 91, Slave 75 queries .
Powered by 德赢Vwin官网 网
© 2015 bbs.elecfans.com
关注我们的微信
下载发烧友APP
德赢Vwin官网 观察
版权所有 © 湖南华秋数字科技有限公司
德赢Vwin官网 (电路图) 湘公网安备 43011202000918 号 电信与信息服务业务经营许可证:合字B2-20210191 工商网监 湘ICP备2023018690号