ILA存在时实施失败

300 MHz是默认值：它不会查看您的设计以确定时钟频率。
丹尼尔
在原帖中查看解决方案



以下为原文

300 MHz is the default: it does not look into your design to determine what the clock frequency is.
 
Daniel
 
View solution in original post

ILA为您的设计添加了更多逻辑，这可能导致失败。
我经常做的是获取感兴趣的信号，通过几个寄存器计时，然后将它们运行到VIO模块中。
然后我让ILA探测VIO模块输入端的信号。
这将允许实现将感兴趣的逻辑从关键时序路径移动到不会影响您的设计的区域。
是的，您需要分配调试时钟并设置实际频率。
如果右键单击设计中的dbg_hub并获取单元属性：
然后你会看到你可以在哪里设置时钟频率和其他选项。
丹尼尔



以下为原文

ILA adds more logic to your design, and that can be causing the fail.  What I will often do is take the signals of interest, clock them through a few registers and then run them into a VIO module.  Then I get ILA to probe the signals at the input to the VIO module.  That will allow the implementation to move the logic of interest out of the critical timing paths into an area where it will not effect your design.
 
And yes, you need to assign a debug clock and set the actual frequency.  If you right click on the dbg_hub in your design and get cell properties:
 

 
Then you see where you can set the clock frequence and other options.
 

 
Daniel
 

嗨，如果您试图通过将它们连接到ILA来探测设计中的任何时钟，这可能会影响保持时序，因为它会在时钟路径中插入luts。
请检查这是否是问题。谢谢，Deepika。
谢谢，迪皮卡.----------------------------------------------
---------------------------------------------- Google之前的问题
张贴。
如果某人的帖子回答了您的问题，请将帖子标记为“接受为解决方案”。
如果你看到一个特别好的和信息丰富的帖子，考虑给它Kudos（左边的明星）



以下为原文

Hi,

In case if you are trying to probe any clocks in your design by connecting them to ILA this may affect hold timing as it inserts luts in the clock path. Please check if this is the problem.

Thanks,
Deepika.Thanks,
Deepika.
--------------------------------------------------------------------------------------------
Google your question before posting. If someone's post answers your question, mark the post as answer with "Accept as solution". If you see a particularly good and informative post, consider giving it Kudos (the star on the left)

插入ILA时的时序故障可以是两种类型1. ILA本身的故障路径2. dbg_hub中的故障路径
在第一种情况下，确保探头宽度小于200
在第二节，上面提到的约束将会出现。
让我们举两个例子1.只有一个ILA @ 300Mhz
在这种情况下，dbg_hub时钟和ILA时钟将是相同的
所以你必须使用下面的约束来消除dbg_hub中的任何计时故障
set_property C_CLK_INPUT_FREQ_HZ 300000000 [get_debug_cores dbg_hub]
set_property C_ENABLE_CLK_DIVIDER true [get_debug_cores dbg_hub]
此值“300000000”应与freq（以hz为单位）相同，与连接到dbg_hub块的时钟相同
现在是第二个例子，有两个ILA的1 @ 300＆amp;
2 @ 250
在这种情况下，dbg_hub时钟也会获得上述时钟之一（300或250）
现在对dbg_hub使用相同的约束，并根据连接到dbg_hub模块的时钟正确设置hq中的freq值
上面提到的两个约束是通过使用MMCM来降低dbg_hub模块的频率
内部set_property C_ENABLE_CLK_DIVIDER true [get_debug_cores dbg_hub]
如果此属性设置为false，则不会对任何MMCM进行实例化...
希望这可以帮助。
问候
Sikta



以下为原文

The timing failures when ILA is inserted can be of two types
1. The failure paths in ILA itself
2. The failure paths in dbg_hub
In 1st case make sure your probe width is less 200
In 2nd the constraint mentioned above will come into picture.
lets take two examples 
1. Only one ILA @ 300Mhz
In this case the dbg_hub clock and ILA clock will be same
so you have to use below constraints to eliminate any timing failures in dbg_hub
set_property C_CLK_INPUT_FREQ_HZ 300000000 [get_debug_cores dbg_hub]
set_property C_ENABLE_CLK_DIVIDER true [get_debug_cores dbg_hub]
This value "300000000" should be same as the freq (in hz) as that of clock connected to dbg_hub block
 
and now 2nd example
with two ILA's 1 @ 300 & 2 @ 250
In this case also dbg_hub clock gets one of above clocks (either 300 or 250)
now use same constraints above for dbg_hub and properly set the freq value in hz based on the clock connected to dbg_hub module
above mentioned two constraints are to reduce frequency for dbg_hub module by using an MMCM
internally set_property C_ENABLE_CLK_DIVIDER true [get_debug_cores dbg_hub]
if this property is set to false there wont be any MMCM instantiated...
 
Hope this helps.
 
Regards
Sikta

Sikta，
感谢您的回复。
我有一个ILA连接到100 MHz网络，另一个ILA连接到10 MHz网络。
为什么dbg_hub会选择300 MHz的频率？
所以，我所做的就是将setC_ENABLE_CLK_DIVIDER设置为true，然后根据Daniel的评论手动将C_CLK_INPUT_FREQ_HZ更改为100 MHz。
这听起来合理吗？



以下为原文

Sikta,
Thanks for your reply. I have one ILA hooked up to a 100 MHz net and another ILA hooked up to a 10 MHz net. Why would the dbg_hub choose a frequency of 300 MHz?
 
So, what I've done is gone ahead and set C_ENABLE_CLK_DIVIDER to true and then manually changed the C_CLK_INPUT_FREQ_HZ to 100 MHz per Daniel's comment. Does this sound reasonable?

300 MHz是默认值：它不会查看您的设计以确定时钟频率。
丹尼尔



以下为原文

300 MHz is the default: it does not look into your design to determine what the clock frequency is.
 
Daniel
 

哦哇，谢谢。
那是我正在寻找的神奇信息！



以下为原文

oh wow, thanks. That was the magic information I was looking for!

感谢更新。
恩，那就对了。
问候
Sikta



以下为原文

Thanks for the update. Yes thats right.
 
Regards
Sikta

还有一个关于这个主题的想法。
我的设计不符合ILA的时序，但我无法定位设计的ILA部分，因为它们是在实现的最后阶段创建的，而且在XDC文件中引用太迟了。
因此，我将ILA移动到一个新的时钟区域，远离我的设计，使我想要监视的所有内容都转到VIO输入。
VIO有两个优点可以解决这个问题：它从一开始就在设计中，它的输出是BSCAN端口，这意味着它不需要靠近寄存器和它正在监视的信号。
因此，在将所有ILA输入转到VIO输入后，我将VIO（左侧的蓝色组件）和dbg_hub（左侧的红色组件）定位到新的时钟区域。
然后按照ILA（左边的绿色组件），我的设计再次满足时间要求。
这是我将再次使用的策略。
丹尼尔



以下为原文

One more thought on this topic.  I have a design that was not meeting timing with ILA present, but I could not location the ILA portions of the design because they are created very late in the implementation, and too late to reference in an XDC file.  So instead I moved the ILA into a new clock region, away from my design by making everything I wanted to monitor go to a VIO input.
 
VIO has two virtues for solving this problem: it is in the design from the beginning and its output is the BSCAN port, which means it has no need to stay close to the registers and signals it is monitoring.  So after making all of my ILA inputs go to VIO inputs, I located the VIO (the blue components to the left) and dbg_hub (the red components to the left) to a new clock region.  The ILA (the green components to the left) then followed and my design met timing again.
 
This is a strategy I will use again.
Daniel
 

@siktapI具有与上述相同的错误（无法满足ILA存在时的时间），但是您上面建议的步骤对我不起作用。
当我将调试内核的输入时钟频率更改为125 MHz（我使用ps7 FCLK1计时）时，设计仍然无法满足时序要求。
当我还检查C_ENABLE_CLK_DIVIDER时，设计无法实现，并显示以下失败消息：
在place_design：
严重警告：[DRC 23-20]规则违规（AVAL-46）v7v8_mmcm_fvco_rule1  - 当前计算的目标频率FVCO超出了单元dbg_hub / inst / USE_DIVIDER.U_GT_MMCM的范围。
计算出的FVCO为1600.000 MHz。
速度等级-1的有效FVCO范围是600MHz至1200MHz。
用于计算FVCO的单元属性值是CLKFBOUT_MULT_F = 8.000，CLKIN1_PERIOD = 5.00000，并且DIVCLK_DIVIDE = 1（FVCO = 1000 * CLKFBOUT_MULT_F /（CLKIN1_PERIOD * DIVCLK_DIVIDE））。
违规行为可以通过以下方式更正 
1.定时器使用时钟周期或时钟频率的时序约束来影响CLKIN1以设置单元属性CLKIN1_PERIOD，覆盖任何先前的值。
这可能已经到位，如果是这样，一旦运行Timing，这个违规将被解决。
否则，请考虑修改时序约束以调整CLKIN1_PERIOD并将FVCO置于允许的范围内。 
2.在没有影响CLKIN1的时序约束的情况下，考虑修改单元CLKIN1_PERIOD以使FVCO进入允许的范围。 
3.如果CLKIN1_PERIOD令人满意，请修改CLKFBOUT_MULT_F或DIVCLK_DIVIDE单元属性以使FVCO进入允许的范围。
在route_design中：
[DRC 23-20]规则违规（PDRC-34）MMCM_adv_ClkFrequency_div_no_dclk  -  MMCME2_ADV站点MMCME2_ADV_X1Y1（单元dbg_hub / inst / USE_DIVIDER.U_GT_MMCM）的VCO工作频率的计算值1600.000 MHz（CLKIN1_PERIOD，净FCLK_CLK1）超出了运行范围
该器件的MMCM VCO频率范围（600.00002122251317  -  1200.0000424450263 MHz）。
计算值为（CLKFBOUT_MULT_F * 1000 /（CLKINx_PERIOD * DIVCLK_DIVIDE））。
请运行update_timing以更新MMCM设置。
如果不起作用，请调整输入周期CLKINx_PERIOD（5.000000），倍增系数CLKFBOUT_MULT_F（8.000000）或分频因子DIVCLK_DIVIDE（1），以便在此器件的额定工作范围内实现VCO频率。
我试图遵循route_design错误消息的建议，改变MMCM中的分割因子，但我无法弄清楚如何做到这一点，因为它在合成设计中不存在。
我怎么能这样做？
此外，@ dwisehartI也试图按照你的建议，但我无法弄清楚如何将ILA核心移动到一个单独的时钟区域。
我是否应该使用内置PLL在结构中生成新时钟，还是可以在约束文件中或使用平面规划工具执行此操作？
任何帮助将不胜感激！
谢谢



以下为原文

@siktap I have the same error as above (failing to meet timing when ILA present), however the steps you suggested above did not work for me. When I change the input clock frequency of the debug core to 125 MHz (I am clocking with ps7 FCLK1) the design still fails to meet timing. When I also check C_ENABLE_CLK_DIVIDER, the design fails implementation with the following failure messages: 
 
In place_design:
CRITICAL WARNING: [DRC 23-20] Rule violation (AVAL-46) v7v8_mmcm_fvco_rule1 - The current computed target frequency, FVCO, is out of range for cell dbg_hub/inst/USE_DIVIDER.U_GT_MMCM. The computed FVCO is 1600.000 MHz. The valid FVCO range for speed grade -1 is 600MHz to 1200MHz. The cell attribute values used to compute FVCO are CLKFBOUT_MULT_F = 8.000, CLKIN1_PERIOD = 5.00000, and DIVCLK_DIVIDE = 1 (FVCO = 1000 * CLKFBOUT_MULT_F/(CLKIN1_PERIOD * DIVCLK_DIVIDE)).This violation may be corrected by:  1. The timer uses timing constraints for clock period or clock frequency that affect CLKIN1 to set cell attribute CLKIN1_PERIOD, over-riding any previous value. This may already be in place and, if so this violation will be resolved once Timing is run.  Otherwise, consider modifying timing constraints to adjust the CLKIN1_PERIOD and bring FVCO into the allowed range.  2. In the absence of timing constraints that affect CLKIN1, consider modifying the cell CLKIN1_PERIOD to bring FVCO into the allowed range.  3. If CLKIN1_PERIOD is satisfactory, modify the CLKFBOUT_MULT_F or DIVCLK_DIVIDE cell attributes to bring FVCO into the allowed range.In route_design: 
[DRC 23-20] Rule violation (PDRC-34) MMCM_adv_ClkFrequency_div_no_dclk - The computed value 1600.000 MHz (CLKIN1_PERIOD, net FCLK_CLK1) for the VCO operating frequency of the MMCME2_ADV site MMCME2_ADV_X1Y1 (cell dbg_hub/inst/USE_DIVIDER.U_GT_MMCM) falls outside the operating range of the MMCM VCO frequency for this device (600.00002122251317 - 1200.0000424450263 MHz). The computed value is (CLKFBOUT_MULT_F * 1000 / (CLKINx_PERIOD * DIVCLK_DIVIDE)). Please run update_timing to update the MMCM settings. If that does not work, adjust either the input period CLKINx_PERIOD (5.000000), multiplication factor CLKFBOUT_MULT_F (8.000000) or the division factor DIVCLK_DIVIDE (1), in order to achieve a VCO frequency within the rated operating range for this device.I am trying to follow the route_design error message's suggestion of changing the division factor in the MMCM, but I cannot figure out how to do it, as it is not present in the synthesized design. How might I do this? 
 
Also, @dwisehart I tried to follow your suggestion as well, but I can't figure out how to move the ILA core to a separate clock region. Should I be generating a new clock in the fabric using a built-in PLL, or can you do this in a constraints file or using the floorplanning tools?
 
Any help would be GREATLY appreciated!
 
Thanks

ILA组件布局很晚，因此您无法直接为它们指定位置，但我注意到ILA组件已连接到dbg_hub组件。
因此，我将dbg_hub组件放置在远离设计的其余部分的位置，从而将ILA组件与它们一起拉出。
我通过在XDC文件中放置手动约束来完成此操作：
设置PB [create_pblock DbgHub]
add_cells_to_pblock $ PB [get_cells -hier -filter [list NAME = ~dbg_hub *]]
resize_pblock $ PB -add {SLICE_X214Y175：SLICE_X221Y224}
用英语：
创建一个新的PBlock;
查找以dbg_hub *开头的所有组件，并将它们分配给这个新的PBlock;
将PBlock及其所有组件移动到我选择的FPGA的一部分，因为我的设计没有使用它。
我实际上为dbg_hub和这个切片生成一个单独的时钟，但并不总是需要：
设置DBG [get_debug_cores dbg_hub]
set_property C_CLK_INPUT_FREQ_HZ 250000000 $ DBG
set_property C_ENABLE_CLK_DIVIDER false $ DBG
set_property C_USER_SCAN_CHAIN 1 $ DBG
设置ILA [create_debug_core mILA ila]
设置NET_CLK [get_nets $ DBG / wVioClk]
set_property port_width 1 [get_debug_ports $ ILA / clk]
connect_debug_port dbg_hub / clk $ NET_CLK



以下为原文

ILA components are laid out very late, so you cannot specify locations for them directly, but I noticed that ILA components are connected to dbg_hub components.  So I place the dbg_hub components away from the rest of the design, which pulls the ILA components with them.  I do this by placing manual constraints in an XDC file:
 
 
set PB [create_pblock DbgHub]add_cells_to_pblock $PB [get_cells -hier -filter [list NAME =~ dbg_hub*]]resize_pblock $PB -add {SLICE_X214Y175:SLICE_X221Y224} 
In English:
Create a new PBlock;
Find all components that start with dbg_hub* and assign them to this new PBlock;
Move the PBlock and all of its components to a portion of the FPGA I picked because it wasn't being used by my design.
 
I actually do generate a separate clock for dbg_hub and this slice, but that is not always required:
 
set DBG [get_debug_cores dbg_hub]set_property C_CLK_INPUT_FREQ_HZ 250000000 $DBGset_property C_ENABLE_CLK_DIVIDER false $DBGset_property C_USER_SCAN_CHAIN 1 $DBGset ILA [create_debug_core mILA ila]set NET_CLK [get_nets $DBG/wVioClk]set_property port_width 1 [get_debug_ports $ILA/clk]connect_debug_port dbg_hub/clk $NET_CLK

@dwisehartthanks非常感谢信息，我现在就试试吧。
一个快速跟进的问题，我自己的好奇心：如何重新定位到一个新的pblock，而不是生成自己的时钟做任何事情除了使时间违规更严重？
除非我弄错了，设置/保持松弛都应该随着线长而减少，不是吗？



以下为原文

@dwisehart thanks so much for the info, I'll try it out now. 
 
A quick follow up question for my own curiosity: how would relocating to a new pblock and NOT generating your own clock do anything except make timing violations worse? Unless I'm mistaken, setup/hold slack should both decrease with wire length, no? 

它比最初出现的更复杂，@ bigbrett
当你进入一个新的时钟域时，即使你没有要求，你也会自动为你带来的每个时钟获得一个新的BUFH。
第二部分是时间违规经常发生，因为路由区域过于拥挤。
即使您移动到新的时钟域时路径延迟会增加，但是您有足够的路由资源来直接连接门，这可以减轻时间压力。



以下为原文

It is more complicated than it initially appears, @bigbrett 
 
When you move into a new clock domain you automatically get a new BUFH for every clock you bring in, even though you do not ask for them.
 
The second part is that timing violations often happen because routing areas are overly crowded.  Even though the path delays go up when you move to a new clock domain, the fact that you have enough routing resources to connect gates in a straight forward way, can relieve the timing pressure.
 

非常感谢@ dwisehart的帮助，感谢它。
不幸的是，重新定位到不同的时钟区域似乎没有解决任何问题。
您（或任何人）可以想到为什么插入ILA核心会破坏时间的任何其他原因？
我觉得这不是设计的疯狂，所以我一定做错了。
但是由于一些令人讨厌的时钟域交叉，我无法在模拟中进行调试，因此我现在对选项感到茫然。
我已经链接了该项目的档案（在干预布局规划之前），以供参考。
任何洞察力或正确方向的推动都将非常感激。
我怀疑我的设计限制有问题，因为这样的设计不应该像这样失败，但我似乎无法确切地确定在哪里。
项目可以在这里找到：https：//www.dropbox.com/s/2vkuel6k1lshm0t/network_tap_archive.xpr.zip？dl = 0
布雷特



以下为原文

Thanks so much for the help @dwisehart I appreciate it.
 
Unfortunately, relocating to a different clock region didn't seem to fix anything. Could you (or anybody) think of any other reason why insertion of an ILA core would break timing? 
 
I don't feel like this is that crazy of a design, so I must be doing something wrong. But I'm not able to debug in simulation given some nasty clock domain crossing, and so I'm at a loss for options right now. 
 
I've linked an archive of the project (before meddling w/ floorplanning) for reference below. Any insight or a nudge in the right direction would be greatly appreciated. I have a suspicion that I'm doing something wrong with my design constraints, as this design shouldn't be failing timing like this, but I can't seem to nail down exactly where. 
 
Project can be found here: https://www.dropbox.com/s/2vkuel6k1lshm0t/network_tap_archive.xpr.zip?dl=0
 
Brett

很抱歉听到Brett，
在我搬迁ILA之后，我还没有完成。
我查看了添加ILA后的时间失败的区域，无论是否有ILA。
我经常发现的是通过在原始时钟域中放置一个寄存器来消除拥塞，但是使用约束移动到边缘，然后在ILA时钟域内移动第二个寄存器。
这解决了我的问题了一段时间，但后来我不得不回去再推广一些设计，因为默认情况是将门关闭得太紧，造成路由周围的路由。
通过扩展逻辑，我可以在每次有或没有ILA的情况下命中时间。
丹尼尔



以下为原文

Sorry to hear that Brett,
 
After I moved the ILA, I was still not done.  I looked at the areas that failed timing after the ILA was added, both with and without the ILA.  What I often found is congestion that I eliminated by putting a register in the original clock domain, but moved to the edge using constraints, and then a second register inside the ILA clock domain.
 
This solved my problem for a while, but then I had to go back and spread the design out some more because the default was to pack gates too close together, causing routing congesting around them.  By spreading out the logic, I could hit timing every time with or without ILA.
 
Daniel