Vivado在set_clock_groups之后无法应用ASYNC_REG属性

嗨@ avrumw，
谢谢您的意见。
你是对的。
我不应该使用get_cells，因为我需要一个网络而不是一个单元格！
我将约束更改为以下格式：-from＆amp; -to。
在这种情况下，您必须使用get_cells。
但是，命名问题仍然存在。
偶然的机会，我学会了在实现的设计中搜索它，发现它已经扩展到像sOverFlow_reg！
然后我在这个名字之前使用了组件标签和'/'，看到它运作良好。
就像是：
[get_cells ADC_Module_INST / sOverFlow_reg]
谢谢，
Hossein Moradi Sarvandi
在原帖中查看解决方案



以下为原文

Hi @avrumw,
 
Thank you for your comments. Yes, you're right. I shouldn't have used get_cells for -through because I need a net not a cell!. I changed my constraint to this format: -from&-to. In this case you have to use get_cells. However, the naming problem still existed. By chance, I learned to search it inside implemented design and found out it has been extended to something like sOverFlow_reg!.
Then I used component label and '/' before this name and saw it worked well. something like:
[get_cells ADC_Module_INST/sOverFlow_reg]
 
Thanks,
Hossein Moradi Sarvandi
 
View solution in original post

@embeddeddont'使用set_false_path在最后一个翻牌圈的q之间使用set_max_delay -datapath_only;
目标时钟域中第一个触发器的d。
至于这个问题，你能说明你如何推断​​失败者？
- 如果提供的信息有用，请将答案标记为“接受为解决方案”。给予您认为有用且回复的帖子。



以下为原文

@embedded dont' use set_false_path use set_max_delay -datapath_only between the q of the last flop & d of the first flop in the target clock domain. As to the issue can you show how you infer the flops?
- 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.

时序约束和ASYNC_REG并没有真正相互干扰。
因此，工具没有将两个同步器FF打包到同一切片中的事实与约束无关......
该错误表示“约束或不匹配的控制信号”。
这里所指的约束是放置约束（LOC或BEL约束），而不是时序约束。
因此，除非你有LOC约束，否则问题很可能是第二部分 - 不匹配的控制信号。
为了将两个触发器打包到同一个切片中，它们必须具有相同的控制集。
这意味着他们必须使用相同的时钟，重置和ce。
由于它们应该是同步器，因此它们可能共享相同的时钟。
此外，应始终启用同步器，因此它们可能共享相同的CE（常量为“1”）。
所以最后一个是重置 - 他们都使用相同的重置吗？
如果ASYNC_REG触发器不能放在同一个切片中（并且你得到这个消息），那么工具会将它们放在相邻的切片中，这就是他们所做的（X7Y152和X7Y153）。
这不一定是个问题 - 两个FF仍然很接近，因此可能很好地作为同步器链，但我们总是希望它们在一起（如果可能的话）（所以看看控制集）。
至于set_clock_groups  - 正如@muzaffer所提到的，我总是避免使用set_clock_groups（或者时钟之间的set_false_path，这基本上是一回事）。
很明显，域之间有时钟交叉 - 如果要交叉的数据不是“没有延迟要求的缓慢变化的单比特信号”，那么您的时钟域交叉（CDC）电路需要约束。
使用set_clock_groups（或时钟之间的set_false_path）声明域false之间的所有路径。
由于这些限制是最高优先级，因此现在不可能限制您的CDC。
Avrum



以下为原文

The timing constraints and the ASYNC_REG do not really interfere with each other. So the fact that the tools are not packing the two synchronizer FFs into the same slice has nothing to do with the constraints...
 
The error says "constraints or mismatched control signals". The constraints it is referring to here is placement constraints (LOC or BEL constraints), not timing constraints. So unless you have LOC constraints, the problem is likely the second part - mismatched control signals.
 
In order for two flip-flops to be packed into the same slice, they must have the same control set. This means they must use the same clock, reset and ce. Since these are supposed to be synchronizers, they presumably share the same clock. Furthermore, synchronizers should always be enabled, so they probably share the same CE (which is the constant '1'). So the last one is the reset - do they both use the same reset?
 
If the ASYNC_REG flip-flops cannot be placed in the same slice (and you get this message), then the tools will place them in adjacent slices, which is what they have done (X7Y152 and X7Y153). This is not necessarily a problem - the two FFs are still close together and hence are probably fine as a synchronizer chain, but we always prefer them to be together if possible (so take a look at the control set).
 
As for the set_clock_groups - as @muzaffer mentioned, I always avoid set_clock_groups (or set_false_path between clocks, which is essentially the same thing). It is clear that you have clock crossing between the domains - if the data to be crossed is anything other than a "slow changing single bit signal with no latency requirement" then your clock domain crossing (CDC) circuit needs constraints. Using the set_clock_groups (or set_false_path between clocks) declares all paths between the domain false. Since these constraints are the highest priority, it is now impossible to constrain your CDCs.
 
Avrum

嗨@ muzafferand @ avrumw，
谢谢你们的帮助。
首先，到@ muzaffer：我在Vivado用户指南中搜索过，但我找不到一个明确的例子，说明如何使用“set_max_delay”专门用于我的情况！
如果你能在这一点上给我一些线索，我真的很感激。
我不知道如何计算这种约束的“-from”，“ -  through”和“-to”延迟？！
第二，到@ avrumw：你是对的。
此警告消息与我的时序约束无关。
我发现即使在评论出这个约束之后它也存在。
无论如何，警告说它无法将这两个dbg_hub模块的FF放在同一个SLICE中！
我在设计中使用了ILA核心，我对核心属性和约束没有任何控制权？
我不知道是否有办法修复这些错误。
关于这个问题的有用建议也将受到高度赞赏。
感谢你们，
侯赛因



以下为原文

Hi @muzaffer and @avrumw,
 
Thank you guys for your helpful comments. First, to @muzaffer: I searched in Vivado user guide but I couldn't find a clear example of how to use "set_max_delay" specifically for my case!. I really appreciate if you can give me some clue on this point. I don't know how to calculate "-from", "-through" and "-to" delays for such constraint?!.
 
Second, to @avrumw: You were right. This warning message had nothing to do with my timing constraint. I saw that it exists even after commenting out that constraint. Anyway, the warning says that it couldn't place those two FFs of dbg_hub module in the same SLICE!. I have used an ILA core inside my design and I do not have any control on the core properties and constraints?!. I don't know if there is a way for fixing such bugs. Helpful advice on this issue would also be highly appreciated.
 
Thank you guys,
Hossein

@ embedded-from，-to，-through不是为了延迟而是为了描述路径（即路径从起点开始，经过等）。
您只需要一个延迟值，通常是设置中较快时钟的周期。
路径应该从源时钟域中的最后一个触发器的输出到目标时钟域中的第一个触发器的输入，这是您使用-from和-to选项的位置。
在这种情况下，您不需要-through选项。
- 如果提供的信息有用，请将答案标记为“接受为解决方案”。给予您认为有用且回复的帖子。



以下为原文

@embedded -from, -to, -through are not for delays but to describe the path (ie path start from, goes through etc). You need only one delay value which is usually the period of the faster clock in your setup. The path should from the output of the last flop in the source clock domain to the input of the first flop in the target clock domain which is where you use -from and -to options. In this case you don't need the -through option.
- 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.

嗨@ muzaffer，
谢谢您的回答。
我上次发帖已经很久了。
但是，我仍然无法解决这个问题。
我不知道为什么xilinx在Vivado中如此努力。
我尝试了各种模式的set_max_delay但我总是收到同样的错误，指出它无法找到该对象！
下图显示了Vivado严重警告信息：
我在两种情况下测试了set_max_delay：
set_max_delay -from [get_cells ...] -to [get_cells ...] 5 -datapath_only
set_max_delay -through [get_cells ...] 5 -datapath_only
它们都不起作用。
我还测试了两个组件和组件输出名称之间的两个信号名称。
但是，它无法检测到它。
请给我一个线索，我怎么能找到合适的物体？
提前致谢，
侯赛因



以下为原文

Hi @muzaffer,
 
Thank you for your answer. It's been a long time since my last post. However, I still couldn't fix the issue. I don't know why xilinx made everything so hard in Vivado. I tried various modes of set_max_delay but I always receive the same error pointing that it couldn't find that object!. Below picture shows Vivado Critical warning message in this regard:
 

I have tested set_max_delay in two cases:
set_max_delay -from [get_cells ...] -to [get_cells ...] 5 -datapath_only
set_max_delay -through [get_cells ...] 5 -datapath_only
 
None of them works. I also tested both signal names between two components and component output names. But, it can't detect it. Would please give me a clue how I can find the right object?
 
Thanks in advance,
Hossein

我尝试了各种模式的set_max_delay，但我总是收到同样的错误，指出它无法找到该对象！
该消息告诉您它无法找到该对象。
这不会（至少直接）与set_max_delay有关（因此-datapath_only标志不会产生任何影响）。
它告诉你那个命令
get_cells [sOverFlow]
不会返回任何对象 - 换句话说，在您的设计中，此级别没有名为sOverFlow的单元格。 
我不知道为什么xilinx在Vivado中如此努力。
Vivado的限制因素不同 - 它们并不一定很难，而Xilinx也没有这么做。
XDC格式是行业标准Synopsys设计约束（SDC）的（非常可靠）实现。
就像任何新语言（和XDC是一种语言）一样，你不能只是通过戳它来学习它 - 如果你想使用它，你需要花一些时间来学习它。
这可以通过阅读手册来完成 - 主要是UG903，或者上课;
Xilinx虽然他们的ATP网络提供了教授这些东西的课程。
看看这篇关于可从ISE迁移到Vivado的类的帖子。
但回到你的问题。
如果要在时钟交叉路径上设置set_max_delay异常，则必须正确识别路径。
很明显，你使用的[get_cells ...]不是正确的语法;
get_cells将返回一个单元格 - 尝试使用单元格作为通过点是不常见的。
那你想做什么？
“sOverFlow”真的是一个“细胞”还是一个网。
如果它是一个网络（这是一个更常见的通过点），那么你需要使用“get_nets”，而不是“get_cells”。
具体来说，您必须正确识别要用于-from / -to / -through的对象的类型和名称。
它们还需要在设计层次的正确级别进行识别......
如果您不确定对象名称，您应该能够在GUI中的原理图查看器或层次结构浏览器中找到它（尽管名称应该始终可以直接从您的RTL确定）。
Avrum



以下为原文

I tried various modes of set_max_delay but I always receive the same error pointing that it couldn't find that object!
 
The message is telling you that it can't find the object. This doesn't (at least directly) have anything to do with the set_max_delay (so the -datapath_only flag won't make a difference).
 
It is telling you that the command
 
get_cells [sOverFlow]
 
doesn't return any objects - in other words, there is no cell named sOverFlow at this level in your design.
 
I don't know why xilinx made everything so hard in Vivado.
 
Constraints in Vivado are different - they are not necessarily hard, and Xilinx didn't make them so. The XDC format is a (very solid) implementation of the industry standard Synopsys Design Constraints (SDC). Like any new language (and XDC is a language) you can't just learn it by poking at it - if you want to use it you need to take some time to learn it. This can be done by reading the manuals - mostly UG903, or by taking a class; Xilinx, though their ATP network offers classes to teach this stuff. Take a look at this post on classes available for migrating from ISE to Vivado.
 
But back to your problem.
 
If you want to set a set_max_delay exception on clock crossing paths, then you have to identify the paths correctly. Clearly the -through [get_cells ...] you used is not the correct syntax; get_cells will return a cell - it is unusual to try and use a cell as a -through point. So what are you trying to do? Is "sOverFlow" really a "cell" or is it a net. If it is a net (which is a more common -through point), then you need to use "get_nets", not "get_cells". Specifically, you have to correctly identify the type and name of the object you want to use for the -from/-to/-through. They also need to be identified at the right level of design hierarchy...
 
If you are unsure of the object name, you should be able to find it in the schematic viewer or the hierarchy browser in the GUI (although the names should always be able to be determined directly from your RTL).
 
Avrum

嗨@ avrumw，
谢谢您的意见。
你是对的。
我不应该使用get_cells，因为我需要一个网络而不是一个单元格！
我将约束更改为以下格式：-from＆amp; -to。
在这种情况下，您必须使用get_cells。
但是，命名问题仍然存在。
偶然的机会，我学会了在实现的设计中搜索它，发现它已经扩展到像sOverFlow_reg！
然后我在这个名字之前使用了组件标签和'/'，看到它运作良好。
就像是：
[get_cells ADC_Module_INST / sOverFlow_reg]
谢谢，
Hossein Moradi Sarvandi



以下为原文

Hi @avrumw,
 
Thank you for your comments. Yes, you're right. I shouldn't have used get_cells for -through because I need a net not a cell!. I changed my constraint to this format: -from&-to. In this case you have to use get_cells. However, the naming problem still existed. By chance, I learned to search it inside implemented design and found out it has been extended to something like sOverFlow_reg!.
Then I used component label and '/' before this name and saw it worked well. something like:
[get_cells ADC_Module_INST/sOverFlow_reg]
 
Thanks,
Hossein Moradi Sarvandi