与时钟频率不同的源同步数据如何约束？

我要做的是仅限制最接近输入时钟边沿的数据窗口。
如果你相信
一个4倍频率倍增器正常工作，然后其他三个数据窗口应该排队
也是。
例如：
TIMEGRP“sdr_c_0”OFFSET = IN 0 ns有效4.0 ns，在“P”上升之前;
请注意，这意味着有效期从上升沿开始并持续
持续4 ns。
如果它实际上在边写入后1 ns开始：
TIMEGRP“sdr_c_0”OFFSET = IN -1 ns有效4.0 ns在“P”上升之前;
最后你真正想要的是确保所有的输入寄存器都在
IOB（如果你使用DDR寄存器或ISERDES就是这种情况）。
然后用
适当的时钟阶段，真的没有任何地方和＆amp;
路线可以改变
时机和一切都应该工作。
然后约束变成了一个
检查构建是否满足时序要求的方法，而不是强制执行它的方法。
顺便说一句，如果你使用DDR输入寄存器，你不需要倍增时钟
4，仅为2.如果由于某些其他原因不需要160 MHz，则可能会减少
整体设计的力量。
-  Gabor
-  Gabor



以下为原文

What I would do is constrain only the data window nearest the input clock edge.  If you believe
that a 4x frequency multiplier works correctly, then the other three data windows should line
up as well.
 
For example:
 
TIMEGRP "sdr_c_0" OFFSET = IN 0 ns VALID 4.0 ns BEFORE "P<0><24>" RISING;
 
Note that this means that the valid period starts right at the rising edge and lasts
for 4 ns.  If it actually starts 1 ns after the edge write:
 
TIMEGRP "sdr_c_0" OFFSET = IN -1 ns VALID 4.0 ns BEFORE "P<0><24>" RISING;
 
In the end what you really want is to make sure that all of the input registers are in the
IOB (this would be the case if you use DDR registers or the ISERDES).  Then with
the proper clock phase, there is realy nothing that place & route can do to change
the timing and everything should just work.  The constraint then just becomes a
way to check that the build meets the timing requirements, not a way to enforce it.
 
By the way, if you use DDR input registers you don't need to multiply the clock
by 4, only by 2.  If you don't need 160 MHz for some other reason this could reduce
the power of the overall design.
 
-- Gabor
-- Gabor

嗨Gabor，谢谢你的建议 - 我仍然有点困惑。
在该方案中，您建议如何处理160MHz时钟的第2个第3和第4个“滴答”？
（我在40MHz时钟的上升沿之后立即标记为'1st'上升沿）。
这些工具是否会尝试在160MHz时钟的所有上升沿上放置组件（和/或检查）以使数据在输入FF上有效？
（显然，如果我只指定一个有效窗口，则不可能满足。）关于在IOB中放置输入寄存器 - 这是必要的吗？
目前我没有使用IDDR或ISERDES。
我只需要一个由160MHz时钟提供时钟的进程，其输入连接到IODELAY输出。
我认为从IODELAY到FF的路径延迟实际上可以帮助满足约束 - 因为FF可以放在IODELAY和MMCM之间的“中间路径”。
我在这里误导了吗？如果您认为需要我可以选择“-pr”选项将Map“打包I / O寄存器/锁存器插入IOB”吗？做到了吗？感谢您的帮助，Wojtek



以下为原文

Hi Gabor,
Thank you for your suggestion - I am still a bit confused though.
In the scheme you are suggesting how is the 2nd 3rd and 4th 'tick' of the 160MHz clock treated? (where I labeled as the '1st' the rising edge right after the rising edge of the 40MHz clock). Won't the tools try to place components (and/or check) such that  data is valid on input FF on all rising edges of the 160MHz clock? (clearly this is not possible to satisfy if I specify only one valid window).

About the placement of input registers in the IOB - is this necessary? Currently I am not using IDDR or ISERDES. I simply have a process clocked by the 160MHz clock whose inputs are connected to the IODELAY outputs. I would think that the path delay from the IODELAY to the FF could actually help to satisfy the constraint - since the FF can be placed 'mid way' between the IODELAY and MMCM. Am I misguided here?
If you think it is needed I could select "-pr" option for Map "Pack I/O Registers/Latches into IOBs" do it?

Thank you for your help,
Wojtek

Gabor可能正在假设在160MHz处只有一个触发器对数据输入进行采样（这是“正确”的方式）。
由于只涉及一个FF，第二，第三和第四窗口中时钟边沿和数据窗口之间的数据关系将与第一个相同 - 有一个时钟路径和一个到采样触发器的数据路径。
因此约束第一个窗口就足够了。
当然，这假设4个数据眼中的每一个都是相同的（都是40MHz时钟周期的1/4）。
指定时钟引脚和数据引脚之间引脚的时序关系的一个UCF约束将定义（仅）第一个数据眼的特性。
至于使用ISERDES或IOB FF而不是片FF，你的观点是有效的（不强迫IOB进入FF可以帮助你的内部时序路径），但通常是I / O时序是最关键的 - 你
可以通过额外的流水线来固定内部路径。
使用IOB FF的好处是，一旦您创建了采样机制以在数据眼中间采样（使用MMCM的相移或数据上的IDELAY），时钟/数据关系将由
FPGA的体系结构 - 每次PAR运行都会为接口提供相同的时序结果。
使用内部FF，时间会随着运行而变化，因此您必须确保您的约束完全正确，并考虑所有可能的因素（抖动，符号间干扰，边沿速率等）......
）
Avrum



以下为原文

Gabor is probably working on the assumption that there will be one and only one flip-flop at 160MHz sampling the data input (which is the "right" way to do this).
 
Since there is only one FF involved, the data relationship between the clock edges and data windows in the 2nd, 3rd and 4th window will be the same as the first - there is one clock path and one data path to the sampling flip-flop. So constraining the first window should be sufficient. This, of course, assumes that each of the 4 data eyes are identical (are all exactly 1/4 of the 40MHz clock period). One UCF constraint that specifies the timing relationship at the pins between the clock pin and the data pin will define the characteristics of (only) the first data eye.
 
As for using the ISERDES or IOB FF instead of a slice FF, your point is valid (not forcing the IOB into the FF can help your internal timing path), but generally it is the I/O timing that is the most critical - you can always fix an internal path by additional pipelining. The nice thing about using the IOB FF is that once you create your sampling mechanism to sample in the middle of the data eye (either using phase shifting of the MMCM or the IDELAY on the data), the clock/data relationship will be guaranteed by the architecture of the FPGA - every PAR run will have identical timing results for the interface. Using an internal FF, the timing will vary run-to-run, so you will have to make sure your constraints are exactly correct, taking in to account all possible factors (jitter, inter-symbol interference, edge rates, etc...)
 
Avrum

您好Avrum，我试过这个： - 我添加FF，每个周期（160MHz时钟）正好对输入端口进行一次采样（无时钟使能） - 我启用了Map的开关：“将I / O寄存器/锁存器打包到IOB中
“ - >”仅用于输入“（我在FPGA编辑器中看到后来我看到这些FF确实放在”ILOGIC“站点中） - 我应用了Gabor建议的约束（仅在第一只眼睛上） - 我还放置了MMCMs
大多数逻辑位置都有BUF（R / G） - 因此PAR可以使用的路径实际上只有几乎相同。
（即不同的时钟线 - 但每个应具有几乎相同的延迟）。
所以我真的依靠约束告诉我是否调整了160MHz时钟的相位，以便我在所有输入的数据有效眼内（如果不是多少）。
当我在大约一分钟的跑步后像这样运行时说：警告：路线：466  - 在562个连接中检测到异常高的保持时间违规。
前20个这样的实例打印在下面。
路由器将继续并尝试修复它P：I  - > CMX_input_inst / Inst_CMX_data_delay / iodelgen_chan [6] .iodelgen_bit [10] .IODELAYE1_inst_data：IDATAIN -6934 CMX_input_inst / Inst_CMX_data_delay / iodelgen_chan [6] .iodelgen_bit [10] .IODELAYE1_inst_data：DATAOUT
- > CMX_input_inst / DELAYED_DATA24_reg_6：DDLY -6934 P：I  - > CMX_input_inst / Inst_CMX_data_delay / iodelgen_chan [6] .iodelgen_bit [15] .IODELAYE1_inst_data：IDATAIN -6927 P：I  - > CMX_input_inst / Inst_CMX_data_delay / iodelgen_chan [6] .iodelgen_bit [12]
] .IODELAYE1_inst_data：IDATAIN -6927 ...我让它一夜之间运行> 11小时！
但后来我的耐心耗尽......所以似乎PAR在某种程度上试图满足相互排斥的约束 - 即在160MHz时钟的所有周期上IOB上的数据的有效性（这是不可能满足的，因为如果数据在
第1个周期它在2号无效。你看到有什么解决方案吗？谢谢！Wojtek



以下为原文

Hello Avrum,
So I tried this:
- I add FF which samples the input port exactly once per cycle (of the 160MHz clock) (no clock enable)
-I enabled the switch of Map: "Pack I/O Registers/Latches into IOBs" -> "For Inputs Only" (I looked in the FPGA editor laterand I see that these FFs are indeed placed in "ILOGIC" sites)
-I applied constraint as suggested by Gabor (on the first eye only)
-I also place MMCMs and BUF(R/G) in most logical locations - so that there are really only few almost equivalent routes PAR can use. (i.e. different clock lines - but each should have almost identical delay). So I am really relying on the constraint to tell me if I have adjusted phase of the 160MHz clock so that I am within the data valid eye for all inputs (and if not by how much).

When I run like this PAR after about a minute of running says:
WARNING:Route:466 - Unusually high hold time violation detected among 562 connections. The top 20 such instances are printed below. The
   router will continue and try to fix it
P<6><10>:I -> CMX_input_inst/Inst_CMX_data_delay/iodelgen_chan[6].iodelgen_bit[10].IODELAYE1_inst_data:IDATAIN -6934
CMX_input_inst/Inst_CMX_data_delay/iodelgen_chan[6].iodelgen_bit[10].IODELAYE1_inst_data:DATAOUT ->
CMX_input_inst/DELAYED_DATA24_reg_6<10>:DDLY -6934
P<6><15>:I -> CMX_input_inst/Inst_CMX_data_delay/iodelgen_chan[6].iodelgen_bit[15].IODELAYE1_inst_data:IDATAIN -6927
P<6><12>:I -> CMX_input_inst/Inst_CMX_data_delay/iodelgen_chan[6].iodelgen_bit[12].IODELAYE1_inst_data:IDATAIN -6927
...

I kept it running overnight >11hrs!!! but then my patience run out...
So It seems that PAR is somehow trying to satisfy mutually exclusive constraints - i.e. validity of data on the IOB on all cycles of the 160MHz clock (which is impossible to satisfy since if data is valid on the 1st cycle it can not be valid on the 2nd)

Do you see any solution?
Thank you!
Wojtek

没有看到更多的信息（理想情况下，PAR之后的失败路径 - 即使没有完成修复保持时间，也要查看“smartPreview”以暂停PAR）。
但是，我不认为警告消息来自数据的4个阶段。
我担心你关于将BRFG / BUFR和MMCM“置于最合理的位置”的声明。
时钟捕获机制的结构必须设计为做两件事 
- 从输入引脚捕获数据 
- 将此数据提供给内部系统的其余部分
使用IBUFG-> MMCM-> BUFG可能是正确的方法，但由于你正在进行时钟倍增，你需要使用两个BUFG 
-  CLKFBOUT上的一个BUFG返回CLKFBIN（为MMCM提供偏移校正阶段以便能够控制时钟数据眼图） - 这将是一个40 MHz时钟（因为您的输入时钟为40 MHz） 
-  CLKOUT0上的一个BUFG（160MHz时钟） - 该时钟将用于捕获IOB FF上的数据
需要调整160MHz时钟的相位以与电路板提供的相一致，这也需要与约束条件一致 - 如果数据是“边沿对齐”（第一个窗口在40MHz的上升沿开始）
然后，Gabor的约束是正确的 - 但是，您需要调整CLKOUT0的相位以捕获数据。
在此配置中。
但是，相移量是可以知道的，因为在这种配置中，您需要满足Tpsmmcmcc和Tphmmcmcc的数据表约束（当您使用MMCM作为时钟和时钟输入时的设置和保持时间）。
实际值取决于您的设备，但您需要将时钟向前移动至少足以满足Tpsmmcmcc。
使用这种机制，您不需要IDELAY  -  MMCM相移可以处理您需要的任何相位偏移。
接下来的问题是，您如何处理这些数据。
如果所有剩余的逻辑都在由CLKOUT0上的BUFG产生的时钟上运行，那么一切都很好。
但是，如果将此数据移动到另一个时钟，则需要 
- 确保此“其他”时钟与捕获时钟同步 - 通常这意味着来自MMCM的另一个时钟具有相同的缓冲区（即BUFG），具有“合理的”相位差（有些组合不起作用）
） 
- 如果不是这种情况，那么您将需要使用时钟交叉电路将数据从一个域传输到另一个域（这可能需要TIG或FROM：TO约束来覆盖正常的PERIOD约束）。
更有可能的是，您的保留失败来自于丢失传入的数据眼（您已定义的那个），或者更可能是将此数据传输到另一个域（特别是因为该工具抱怨了562个连接......）
Avrum



以下为原文

Without seeing more information (ideally the failing path after PAR - look into "smartPreview" to halt PAR even if it hasn't finished fixing the hold times).
 
However, I don't think the warning messages are coming from the 4 phases of the data.
 
I am concerned about your statement about placing BUFG/BUFR and MMCM "in the most logical location". The structure of the clock capture mechanism has to be designed to do two things
  - capture the data from the incoming pin and
  - make this data available to the rest of the internal system
 
Using an IBUFG->MMCM->BUFG is probably the right way to do this, but since you are doing clock multiplication, you will need to use two BUFGs
  - one BUFG on CLKFBOUT back to CLKFBIN (to provide the deskewing phase for the MMCM in order to be able to control the clock data eye) - this will be a 40 MHz clock (since your input clock is 40 MHz)
  - one BUFG on CLKOUT0 (which is the 160MHz clock) - this clock will be used to capture the data at the IOB FFs
 
The phase of the 160MHz clock will need to be adjusted to be consistent with what your board provides, which needs to also be consistent with the constraints - if the data is "edge aligned" (the first window starts at the rising edge of the 40MHz clock), then Gabor's constraints are right - however, you will need to adjust the phase of the CLKOUT0 to capture the data. In this configuration. The amount of phase shift is knowable, though, since, in this configuration, you need to satisfy the datasheet constraints of Tpsmmcmcc and Tphmmcmcc (the setup and hold time when using an MMCM for your clock and clock capable inputs). The actual values depend on your device, but you will need to shift your clock forward by at least enough to satisfy Tpsmmcmcc. Using this mechanism, you shouldn't need the IDELAY - the MMCM phase shift can take care of any phase offset you need.
 
The next question, is what do you do with this data. If all the remaining logic is running on the clock generated by the BUFG on the CLKOUT0 then everything is fine. However, if you move this data to another clock, then you need to either
  - ensure this "other" clock is in phase with the capturing clock - generally this means another clock coming from the MMCM with an identical buffer (i.e. a BUFG), with a "reasonable" phase difference (there are combinations that won't work)
  - if this is not the case, then you will need to use a clock crossing circuit to transfer data from one domain to the other (which will likely require a TIG or FROM:TO constraint to override the normal PERIOD constraints).
 
Its more likely that your hold failures are coming from missing the incoming data eye (the one that you have defined) or, more likely, in transferring this data to another domain (particularly since the tool is complaining about 562 connections...)
 
Avrum