完善资料让更多小伙伴认识你，还能领取20积分哦， 立即完善>
3天内不再提示
电子发烧友论坛|
我有几个时序错误，我无法在我的Spartan 6设计中删除。
我使用100 MHz时钟在外部地址/数据总线接口上注册信号。 我从IOB到第一个寄存器获取信号时出现时序错误，我无法解决这些时序错误。 以下是第一个计时错误的示例： 终点路径BUS_Interface_inst / Mshreg_s_BUS_AD_SR_2_13（SLICE_X34Y0.AI），1路径----------------------------------- --------------------------------------------- Slack（最慢的路径） ：-0.270ns（需求 - 数据路径）源：BUS_AD（PAD）目标：BUS_Interface_inst / Mshreg_s_BUS_AD_SR_2_13（FF）要求：10.270ns数据路径延迟：10.540ns（逻辑电平= 1）目标时钟：s_CLK_97o363最大值上升0.000ns 慢进程角的数据路径：BUS_AD到BUS_Interface_inst / Mshreg_s_BUS_AD_SR_2_13位置延迟类型延迟（ns）物理资源逻辑资源------------------------ ------------------------- ------------------- Y13.I tiopi 1.775 BUS_AD BUS_AD BUS_AD_13_IOBUF / IBUF ProtoComp375.IMUX.3 SLICE_X34Y0.AI net（扇出= 1）8.701 N182 SLICE_X34Y0.CLK Tds 0.064 BUS_Interface_inst / s_BUS_AD_SR_2 BUS_Interface_inst / Mshreg_s_BUS_AD_SR_2_13 ------------------- ------------------------------ -------------------- -------总计10.540ns（逻辑1.839ns，路线8.701ns） （17.4％逻辑，82.6％路线） 如您所见，路由延迟为8.7 ns。 这对我来说似乎异常高涨。 我已经尝试在使用之前将此信号再次注册3次，但这无助于定时错误。 我的想法是，这将使信号有更多时间到达目的地，工具将沿着注册路径分散路由延迟。 信号BUS_AD_13是引脚。 关于UCF的另一个可能重要的信息。 信号BUS_AD具有应用于其的约束IOB = FORCE。 此外，使用DATAPATHONLY，从pads到FFS的时间条件约束为10 ns。 也许这些约束会对路由产生负面影响？ 终点路径BUS_Interface_inst / Mshreg_s_BUS_AD_SR_2_13（SLICE_X34Y0.AI），1路径----------------------------------- --------------------------------------------- Slack（最慢的路径） ：-0.270ns（需求 - 数据路径）源：BUS_AD（PAD）目标：BUS_Interface_inst / Mshreg_s_BUS_AD_SR_2_13（FF）要求：10.270ns数据路径延迟：10.540ns（逻辑电平= 1）目标时钟：s_CLK_97o363最大值上升0.000ns 慢进程角的数据路径：BUS_AD到BUS_Interface_inst / Mshreg_s_BUS_AD_SR_2_13位置延迟类型延迟（ns）物理资源逻辑资源------------------------ ------------------------- ------------------- Y13.I Tiopi 1.775 BUS_AD BUS_AD BUS_AD_13_IOBUF / IBUF ProtoComp375.IMUX.3 SLICE_X34Y0.AI net（扇出= 1）8.701 N182 SLICE_X34Y0.CLK Tds 0.064 BUS_Interface_inst / s_BUS_AD_SR_2 BUS_Interface_inst / Mshreg_s_BUS_AD_SR_2_13 ------------------- ------------------------------ -------------------- -------总计10.540ns（逻辑1.839ns，路线8.701ns） （17.4％逻辑，82.6％路线） 以上来自于谷歌翻译 以下为原文 I have several timing errors that I am unable to remove in my Spartan 6 design. I am using a 100 MHz clock to register signals on an external Address/Data bus interface. I am getting timing errors in getting the signal from the IOB to the first register and I am unable to resolve these timing errrors. Here is an example of the first timing error: Paths for end point BUS_Interface_inst/Mshreg_s_BUS_AD_SR_2_13 (SLICE_X34Y0.AI), 1 path -------------------------------------------------------------------------------- Slack (slowest paths): -0.270ns (requirement - data path) Source: BUS_AD<13> (PAD) Destination: BUS_Interface_inst/Mshreg_s_BUS_AD_SR_2_13 (FF) Requirement: 10.270ns Data Path Delay: 10.540ns (Levels of Logic = 1) Destination Clock: s_CLK_97o363 rising at 0.000ns Maximum Data Path at Slow Process Corner: BUS_AD<13> to BUS_Interface_inst/Mshreg_s_BUS_AD_SR_2_13 Location Delay type Delay(ns) Physical Resource Logical Resource(s) ------------------------------------------------- ------------------- Y13.I Tiopi 1.775 BUS_AD<13> BUS_AD<13> BUS_AD_13_IOBUF/IBUF ProtoComp375.IMUX.3 SLICE_X34Y0.AI net (fanout=1) 8.701 N182 SLICE_X34Y0.CLK Tds 0.064 BUS_Interface_inst/s_BUS_AD_SR_2<12> BUS_Interface_inst/Mshreg_s_BUS_AD_SR_2_13 ------------------------------------------------- --------------------------- Total 10.540ns (1.839ns logic, 8.701ns route) (17.4% logic, 82.6% route) As you can see, there is 8.7 ns route delay. This seems unusually high to me. I have tried registering this signal 3 additional times before it is used, but this does not help the timing error. My thought was that this would allow the signal more time to reach its destination and the tools would spread out the routing delay along the registered path. The signal BUS_AD_13 is the pin. One other potentially important piece of information regarding UCF. The signal BUS_AD has the contraint IOB=FORCE applied to it. Additionally, there is a timespec constraint from the Pads to FFS of 10 ns with DATAPATHONLY. Maybe these constrains are negatively affecting the routing? Paths for end point BUS_Interface_inst/Mshreg_s_BUS_AD_SR_2_13 (SLICE_X34Y0.AI), 1 path -------------------------------------------------------------------------------- Slack (slowest paths): -0.270ns (requirement - data path) Source: BUS_AD<13> (PAD) Destination: BUS_Interface_inst/Mshreg_s_BUS_AD_SR_2_13 (FF) Requirement: 10.270ns Data Path Delay: 10.540ns (Levels of Logic = 1) Destination Clock: s_CLK_97o363 rising at 0.000ns Maximum Data Path at Slow Process Corner: BUS_AD<13> to BUS_Interface_inst/Mshreg_s_BUS_AD_SR_2_13 Location Delay type Delay(ns) Physical Resource Logical Resource(s) ------------------------------------------------- ------------------- Y13.I Tiopi 1.775 BUS_AD<13> BUS_AD<13> BUS_AD_13_IOBUF/IBUF ProtoComp375.IMUX.3 SLICE_X34Y0.AI net (fanout=1) 8.701 N182 SLICE_X34Y0.CLK Tds 0.064 BUS_Interface_inst/s_BUS_AD_SR_2<12> BUS_Interface_inst/Mshreg_s_BUS_AD_SR_2_13 ------------------------------------------------- --------------------------- Total 10.540ns (1.839ns logic, 8.701ns route) (17.4% logic, 82.6% route) 
0
|
|
相关推荐
16个回答
|
|
|
谢谢你的回复。
以下是Addr / Data总线的第一个引脚的UCF约束： NET“BUS_AD [0]”LOC = AA12 | IOSTANDARD = LVCMOS33 | IOB =力; INST“BUS_AD”TNM = TNM_BUS_Pads; #TIMESPEC TS_BUS_In = FROM TNM_BUS_Pads TO FFS 10.270 ns DATAPATHONLY; 有趣的是，当我评论出上面看到的TIMESPEC时，所有的时序错误都消失了！ 为什么这会产生影响？ 这两个约束在一起使用时是否会引起问题？ 以上来自于谷歌翻译 以下为原文 Thanks for the response. Here is the UCF Constraint for the first pin of the Addr/Data bus: NET "BUS_AD[0]" LOC = AA12 | IOSTANDARD = LVCMOS33 | IOB=FORCE; INST "BUS_AD<*>" TNM = TNM_BUS_Pads; #TIMESPEC TS_BUS_In = FROM TNM_BUS_Pads TO FFS 10.270 ns DATAPATHONLY ; Interestingly enough, all of the timing errors go away when I comment out the TIMESPEC seen above! Why might this have an effect? Are the two constraints causing problems when used together? |
|
|
|
|
|
首先，从某些焊盘到FFS的时序规范不是进行输入约束的正确方法。
通常，您需要使用OFFSET IN BEFORE约束来确保在检查设置和保持时序的输入时正确考虑时钟路径。 同样删除FROM TO约束将消除定时错误，因为现在输入不需要满足任何输入时序约束。 然后，第一个触发器可以整齐地放置在下一个内部逻辑附近，以减少内部路由长度并帮助满足任何PERIOD约束。 最后，最好将IOB = FORCE放在源代码或综合约束（XCF）而不是UCF中。 这可以防止合成器产生无法将触发器打包到IOB中的情况。 在任何情况下，它都不是你应用IOB = FORCE的垫网。 输入板显然总是在IOB中。 您需要将IOB = FORCE应用于输入寄存器。 在输入触发器之后，这将由网络名称调出。 还要注意，强制输入寄存器进入IOB可能会使您更难满足内部PERIOD约束。 如果在输入上使用正确的OFFSET IN BEFORE约束，则可以允许自动放置输入寄存器以平衡内部和外部时序要求。 - Gabor 以上来自于谷歌翻译 以下为原文 First of all, your timing spec from certain pads to FFS is not the right way to do an input constraint. Normally you'd use the OFFSET IN BEFORE constraint to ensure that the clock path is properly considered when checking the inputs for setup and hold timing. Also removing that FROM TO constraint will remove timing errors, because now the inputs don't need to meet any input timing constraint. Then the first flip-flop can be neatly placed near the next piece of internal logic to reduce internal route length and help meet any PERIOD constraints. Finally it's best to place the IOB = FORCE in your source code or synthesis constraints (XCF) rather than the UCF. This prevents the synthesizer from creating a situation where it's not possible to pack the flip-flop into the IOB. In any case it's not the pad net that you apply the IOB = FORCE to. The input pad is clearly always in the IOB. You need to apply the IOB = FORCE to the input register. That would be called out by the net name after the input flip-flop. Also be aware that forcing the input registers into the IOB will likely make it harder to meet your internal PERIOD constraints. If you use a proper OFFSET IN BEFORE constraint on your inputs, then you can allow the input register to be auto-placed to balance the internal and external timing requirements. -- Gabor |
|
|
|
|
|
谢谢你的回复。
这实际上是一个异步接口，被FPGA时钟过采样。 我只是希望有一个约束来确保从输入板到第一个寄存器的总路径不会非常长。 有没有比我做的更好的方法来实现这一目标？ 我不认为之前的OFFSET会在这里工作，因为我没有时钟。 只要地址/数据总线的所有行都在10ns以内，接口就可以正常工作。 我想避免焊盘和内部寄存器之间的100 ns路径路径，因为微控制器不能保持很长的信号。 以上来自于谷歌翻译 以下为原文 Thanks for the response. This is actually an asynchronous interface that is being oversampled by the FPGA clock. I just wanted to have a constraint that ensures that the total path from the input pad to the first register is not egregiously long. Is there a better way to achieve that than what I did? I don't think the OFFSET IN BEFORE will work here since I don't have a clock. As long as all of the lines of the address/data bus are within 10ns of eachother the interface should work fine. I want to avoid some 100 ns route path between the pad and the internal register, since the microcontroller doesn't hold the signals that long. |
|
|
|
|
|
正如其他人所指出的，你的约束是错误的。
我从未在输入板的路径上看到FROM：TO DATAPATH_ONLY约束，并且坦率地不知道它将做什么。 但是，这种错误约束可能导致长路由延迟。 如果该工具（出于任何原因）认为它必须修复保持时间违规（这可能由于不正确的约束而发生），那么它将故意在数据路径上添加延迟。 在FPGA中，这是通过工具有意地将捕获触发器从焊盘移开并插入大量路由延迟来完成的。 由于您声明这是一个异步路径，实际情况是您没有约束 - 它是一个错误的路径。 在ISE中，声明输入路径为false的最佳方法是简单地没有OFFSET IN约束（或其他约束）。 但是，正如您所说，您关注的是异步总线中不同位的采样之间的偏差。 处理此问题的最佳方法是为IOB FF中的所有输入计时。 由于IOB FF实际上是在输入/输出块中，因此从输入缓冲器到这些FF没有路由延迟。 如果它们都在相同的内部时钟（在全局，区域或I / O时钟网络上）上运行，那么这些FF的时钟偏差非常小，因此对总线中信号进行采样时的偏差是 非常小（小于几百皮秒）。 但有一点需要确定的是，您可以正确地同步您用作“频闪”的任何信号（即来自异步接口的RD或WR脉冲）。 这必须是亚稳态保护。 由于这些信号是缓慢变化的单比特信号，因此简单的“2背对背触发器”足以用于亚稳态保护。 但是，在计算RD和WR脉冲的最小长度时，需要考虑同步器的延迟（1-2个时钟周期），以及整个读/写周期必须保证多长时间以确保数据存在 完成同步后。 最后，一个很酷的技巧是利用IOB中的资源来保护亚稳态。 每个IOB都具有IDDR功能。 如果查看IDDR功能，它会在时钟的上升沿和下降沿采样输入信号。 但是，它也有不同的模式“OPPOSITE_EDGE”，“SAME_EDGE”或“SAME_EDGE_PIPELINED”。 在SAME_EDGE_PIPELINED中，负边缘样本（您不关心）和正边缘样本都在离开IOB之前再次计时。 因此，如果您在SAME_EDGE_PIPELINED模式下使用IDDR，那么IDDR的Q1输出就是您的输入信号，由两个背靠背触发器提供时钟！ 更好的是，这两个FF位于同一个单元中，因此它们之间没有路由延迟，这留下了亚稳态解析的最大时间。 因此，Q1输出是正确同步的信号。 Avrum 以上来自于谷歌翻译 以下为原文 As others have pointed out, your constraint is wrong. I have never see a FROM:TO DATAPATH_ONLY constraint on a path from an input pad, and frankly have no idea what it will do. However, its possible that the long routing delay is being caused by this errorneous constraint. If the tool (for whatever reason) thinks that it has to fix a hold time violation (which can happen due to an incorrect constraint), then it will intentionally add delay on the data path. In an FPGA this is done by the tool intentionally moving the capture flip-flop away from the pad and inserting lots of routing delay. Since you state that this is an asynchronous path, the reality is that you don't have a constraint for it - its a false path. In ISE, the best way to declare an input path false is simply to have no OFFSET IN constraint (or other constraint) for it. But, as you said, you are concerned with skew between the sampling of the different bits in the asynchronous bus. The best way to handle this is to clock all the inputs in IOB FFs. Since the IOB FFs are actually "in" the input/output block, there is no routing delay from the input buffer to these FFs. If they are all clocked on the same internal clock (on a global, regional, or I/O clock network), then the skew of the clock to these FFs is very small, and hence the skew in sampling the signals in your bus is very small (less than a few hundred picoseconds). One thing to be sure of, though, is that you properly synchronize whatever signal you use as your "strobe" (i.e. the RD or WR pulse from your asyncronous interface). This must be metastability protected. Since these signals are slow changing single bit signals, then the simple "2 back to back flip-flops" is sufficient for metastability protection. However, you need to account for the delay (1-2 clock periods) through the synchronizer when figuring out the minimum length of your RD and WR pulses, and how long your overall read/write cycle must be to ensure that your data is present once your synchronization is done. Finally, one cool trick is to take advantage of the resources within the IOB for your metastability protection. Each IOB has an IDDR capability. If you look at the IDDR functionality, it samples the incoming signal on both the rising and falling edge of the clock. But, it also has different modes "OPPOSITE_EDGE", "SAME_EDGE" or "SAME_EDGE_PIPELINED". In SAME_EDGE_PIPELINED, both the negative edge sample (which you don't care about) and the positive edge sample are both clocked once more before leaving the IOB. Thus, if you use an IDDR in SAME_EDGE_PIPELINED mode, then the Q1 output of the IDDR is your input signal clocked by two back to back flip-flops! Even better, these two FFs are in the same cell, so there is no routing delay between them, which leaves the maximum amount of time for metastability resolution. Thus, your Q1 output is your properly synchronized signal. Avrum |
|
|
|
|
|
avrumw：我不相信我能够使用您讨论的IDDR技巧...... Spartan 6的IDDR2具有DDR_ALIGNMENT属性，看起来不像IDDR那样具有PIPELINED模式。
无论如何，我会将寄存器打包到IOB中，以确保在这个异步接口上尽可能早地对它们进行采样。 这消除了我之前使用的时序约束的需要。 谢谢大家的帮助！ 以上来自于谷歌翻译 以下为原文 avrumw: I don't believe that I will be able to use the IDDR trick you discussed... Spartan 6's have IDDR2 which have a DDR_ALIGNMENT attribute that does not look like it has a PIPELINED MODE like the IDDR's have. Regardless, I will pack the registers into the IOB to ensure that they are all sampled as early as possible on this asynchronous interface. This removes the need for the timing constraint that I was using before. Thanks for the help all! |
|
|
|
|
|
最后，一个很酷的技巧是利用IOB中的资源来保护亚稳态。
每个IOB都具有IDDR功能。 如果查看IDDR功能，它会在时钟的上升沿和下降沿采样输入信号。 但是，它也有不同的模式“OPPOSITE_EDGE”，“SAME_EDGE”或“SAME_EDGE_PIPELINED”。 在SAME_EDGE_PIPELINED中，负边缘样本（您不关心）和正边缘样本都在离开IOB之前再次计时。 因此，如果您在SAME_EDGE_PIPELINED模式下使用IDDR，那么IDDR的Q1输出就是您的输入信号，由两个背靠背触发器提供时钟！ 更好的是，这两个FF位于同一个单元中，因此它们之间没有路由延迟，这留下了亚稳态解析的最大时间。 因此，Q1输出是正确同步的信号。 那是干嘛。 我从来没想过这点。 感谢分享。 除了...... SAME_EDGE_PIPELINED模式仅在Virtex设备中可用（我检查了V4用户指南，它就在那里）。 它不在斯巴达6中。 ----------------------------是的，我这样做是为了谋生。 以上来自于谷歌翻译 以下为原文 Finally, one cool trick is to take advantage of the resources within the IOB for your metastability protection. Each IOB has an IDDR capability. If you look at the IDDR functionality, it samples the incoming signal on both the rising and falling edge of the clock. But, it also has different modes "OPPOSITE_EDGE", "SAME_EDGE" or "SAME_EDGE_PIPELINED". In SAME_EDGE_PIPELINED, both the negative edge sample (which you don't care about) and the positive edge sample are both clocked once more before leaving the IOB. Thus, if you use an IDDR in SAME_EDGE_PIPELINED mode, then the Q1 output of the IDDR is your input signal clocked by two back to back flip-flops! Even better, these two FFs are in the same cell, so there is no routing delay between them, which leaves the maximum amount of time for metastability resolution. Thus, your Q1 output is your properly synchronized signal.That's WAY COOL. I never thought of that. Thanks for sharing. EXCEPT... the SAME_EDGE_PIPELINED mode is available only in Virtex devices (I checked the V4 user guide and it's there). It's not in Spartan 6. ----------------------------Yes, I do this for a living. |
|
|
|
|
|
我想知道你是否可以通过撒谎来为Spartan做同样的事情。
如果将DDR_ALIGNMENT设置为C0或C1，然后将C0和C1时钟连接到时钟的上升沿，那么（至少根据UG381中的描述），这应该可以得到两个背靠背触发器。 它绝对不是IDDR的预期使用模型，并且工具可能会将其声明为非法（甚至可能在结构上不可能将相同的时钟路由到C0和C1输入），但是如果工具不对它进行barf 那么它可能会奏效。 但是，正如我所说，它不是一个预期的使用模式...... Avrum 以上来自于谷歌翻译 以下为原文 I wonder if you can do the same thing with Spartan by lying to the tool. If you set the DDR_ALIGNMENT to either C0 or C1, and then tie both the C0 and C1 clocks to your rising edge of clock, then (at least according the description in UG381) this should get you the two back to back flip-flops. It is definitely not an intended usage model for the IDDR, and the tools may declare it illegal (and it might even be structurally impossible to route the same clock to the C0 and C1 inputs), but if the tools don't barf on it, then it probably would work. But, as I said, its not an intended usage model... Avrum |
|
|
|
|
|
无论如何，我会将寄存器打包到IOB中，以确保在这个异步接口上尽可能早地对它们进行采样。
这消除了我之前使用的时序约束的需要。 只是一个警告...如果你不能在IOB中对它进行双重采样，那么你将被迫在IOB中进行一次采样，然后在结构中进行第二次采样。 存在很大的风险，在没有额外约束的情况下，该工具将使第二FF相对远离第一触发器，这损害了该电路防止亚稳态的能力。 因此，为了确保工具不这样做，我通常在两个亚稳态触发器之间的网络上放置一个MAXDELAY约束。 这可以在您的UCF文件中完成 NET“signal_meta”MAXDELAY = 2; 或者它可以嵌入你的RTL中 （* MAXDELAY =“2ns”*）reg signal_meta; 其中signal_meta是应该打包到IOB中的推断FF的名称。 Avrum 以上来自于谷歌翻译 以下为原文 Regardless, I will pack the registers into the IOB to ensure that they are all sampled as early as possible on this asynchronous interface. This removes the need for the timing constraint that I was using before. Just a warning... If you can't double sample it in the IOB, then you are forced to sample it once in the IOB and a 2nd time in the fabric. There is a significant risk that, without additional constraints, the tool will place the 2nd FF relatively far away from the first flip flop, which impairs the ability of this circuit to protect against metastability. So, to make sure the tools don't do this, I usually put a MAXDELAY constraint on the net between the two metastability flops. This can be done in your UCF file NET "signal_meta" MAXDELAY = 2; or it can be embedded in your RTL (* MAXDELAY = "2ns" *) reg signal_meta; where signal_meta is the name of the inferred FF that should be packed into the IOB. Avrum |
|
|
|
|
|
当时钟周期为10 ns时，无需低至2 ns。
通常将松弛设置为2 ns（即最大延迟为8 ns）足以防止发生在您的生命周期中发生松弛的亚稳态事件。 当然，你给自己多少松懈可能取决于采取这种事件的后果。 此外，在100 MHz时，在相反的时钟边沿上使用IDDR以及C0对齐可能是有意义的，因此您可以在200 MHz处有效地对输入进行两次触发。 即使是5 ns也可能会给出足够的松弛来缓解第二次失败时出现的任何亚稳态事件。 当然，假设您的输入实际上是异步的，所以只要对所有输入执行相同的操作，就不要介意在时钟下降沿采集第一个样本。 - Gabor 以上来自于谷歌翻译 以下为原文 No need to go as low as 2 ns when the clock period is 10 ns. Normally setting the slack to 2 ns (i.e. max delay of 8 ns) is sufficient to prevent a metastability event that eats up that slack from happening in your lifetime. Of course how much slack you give yourself may depend on what the consequences are for taking such an event. Also, at 100 MHz it may make sense to use the IDDR on opposite clock edges with C0 alignment so you have effectively two flops at 200 MHz sampling the input. Even that 5 ns would probably give enough slack to mitigate any metastable event from showing up on the second flop. Of course that assumes that your inputs are really asynchronous so you don't mind taking the first sample on the falling clock edge as long as you do the same thing for all inputs. -- Gabor |
|
|
|
|
|
avrumw写道：
我想知道你是否可以通过撒谎来为Spartan做同样的事情。 如果将DDR_ALIGNMENT设置为C0或C1，然后将C0和C1时钟连接到时钟的上升沿，那么（至少根据UG381中的描述），这应该可以得到两个背靠背触发器。 它绝对不是IDDR的预期使用模型，并且工具可能会将其声明为非法（甚至可能在结构上不可能将相同的时钟路由到C0和C1输入），但是如果工具不对它进行barf 那么它可能会奏效。 但是，正如我所说，它不是一个预期的使用模式...... Avrum 我不明白为什么那种时钟路由不合法。 如果我得到一分钟，我会试试。 但是如果它确实有效，你会得到两个系列的触发器。 ----------------------------是的，我这样做是为了谋生。 以上来自于谷歌翻译 以下为原文 avrumw wrote:I don't see why that sort of clock routing wouldn't be legal. If I get a minute I'll try it. But if it does work, you will get two flip-flops in series. ----------------------------Yes, I do this for a living. |
|
|
|
|
|
gszakacs写道：
当时钟周期为10 ns时，无需低至2 ns。 通常将松弛设置为2 ns（即最大延迟为8 ns）足以防止发生在您的生命周期中发生松弛的亚稳态事件。 当然，你给自己多少松懈可能取决于采取这种事件的后果。 我不确定你为什么甚至关心这件事？ 为什么不让工具使用10 ns约束而不添加任何额外的松弛？ 只要从IOB触发器到结构FF满足10 ns，就应该没问题。 如果我不需要它，我宁愿不添加大量限制......跟踪所有事情会变得很头疼。 以上来自于谷歌翻译 以下为原文 gszakacs wrote: I'm not sure why you even care about this? Why not just let the tools use the 10 ns constraint and not add any additional slack? As long as that 10 ns is met from the IOB flip flop to the fabric FF, it should be fine. I prefer not to add tons of constraints if I don't need them... it becomes a headache to keep track of everything. |
|
|
|
|
|
rman12345写道：
gszakacs写道： 当时钟周期为10 ns时，无需低至2 ns。 通常将松弛设置为2 ns（即最大延迟为8 ns）足以防止发生在您的生命周期中发生松弛的亚稳态事件。 当然，你给自己多少松懈可能取决于采取这种事件的后果。 我不确定你为什么甚至关心这件事？ 为什么不让工具使用10 ns约束而不添加任何额外的松弛？ 只要从IOB触发器到结构FF满足10 ns，就应该没问题。 如果我不需要它，我宁愿不添加大量限制......跟踪所有事情会变得很头疼。 额外的松弛是用于减轻亚稳态。 当你有一个异步输入时，有一些小的 它会在输入触发器的亚稳态窗口期间切换。 与设置和保持时间相比，此窗口非常小，因此很少发生这种情况。 然而，当它发生时，结果是触发器将比发布的时钟稳定到Q最大值需要更长的时间。 在触发器和下一个触发器之间的路径上添加松弛使您可以“通过”大部分亚稳态事件，这些事件会在额外的松弛时间内解决。 如果没有任何额外的松弛，即使您符合静态时序分析标准，您实际上也会从第一次翻转到第二次翻牌失败。 这是因为在时序分析中没有考虑亚稳态（实际上不可能因为亚稳态事件没有上限或“最坏情况”的额外延迟）。 因此，当您知道触发器的异步输入时，您可以根据设计要求处理亚稳态。 - Gabor 以上来自于谷歌翻译 以下为原文 rman12345 wrote:The additional slack is for metastability mitigation. When you have an asynchronous input, there is some small chance that it will switch during the metastability window of the input flip-flop. This window is very small compared to the setup and hold time, so this happens very infrequently. However when it happens, the result is that the flip-flop will take longer to stabilize than the published clock to Q maximum. Adding slack to the path between that flip-flop and the next one allows you to "live through" the majority of metastable events that settle within that additional slack time. Without any additional slack, you essentially fail timing from the first to the second flop even though you met the static timing analysis criteria. That's because there is no accounting for metastability in the timing analysis (there really can't be because there is no upper bound or "worst case" additional delay from a metastable event). So when you know you have an asynchronous input to a flip-flop it's up to you to handle metastability based on the design requirements. -- Gabor |
|
|
|
|
|
我理解你对亚稳态的看法，但我不确定我是否相信。
首先，我有一个问题，你的假设是2 ns的额外松弛将足以处理IOB触发器上的任何慢速转换。 这似乎相当武断。 为什么不是5 ns？ 还是1 ns？ 其次，对输入信号进行双重记录的重点是消除亚稳态。 第二个触发器的输出应该是你看到的那个，那应该是稳定的。 因此，如果我的同步器在某个TX_ACTIVE信号上寻找下降沿，我可能需要等待一个额外的时钟周期来对地址/数据线进行采样，以确保地址/数据线在整个过程中100％稳定 并行总线。 以上来自于谷歌翻译 以下为原文 I understand what you are saying about metastability, but I'm not sure that I am convinced. For one, I have a problem with your assumption that the 2 ns of extra slack will be enough to handle any slow transition on the IOB flip flop. That seems rather arbitrary. Why not 5 ns? Or 1 ns? Secondly, the whole point of double-registering your input signal is to remove the metastability. The output of the second flip flop should be the one that you look at, and that should be stable. So if my synchonizer looks for a falling edge on some TX_ACTIVE signal, I might wait one extra clock cycle to sample the address/data lines just to be **bleep** sure that the address/data lines are 100% stable across the entire parallel bus. |
|
|
|
|
|
2 ns没有任何魔力。
正如我所说，mtastable事件的长度没有上限。 另一方面，持续特定时间的事件的概率随时间呈指数下降。 现代FPGA过程中2 ns的松弛通常足以使您在生命周期中发生事件的概率基本上为零，或者至少小于任何其他发生故障的事件发生破坏您的设计的概率。 至于完全减轻亚稳态的第二个触发器，那不是真的。 如果第一个触发器到第二个触发器路径没有松弛，则任何亚稳态事件都将导致定时失败，这意味着第二个触发器也可能具有亚稳态事件。 虽然这个概率已经非常低，但它不是零。 如果您正在使用第一个翻牌的输出以及第二个翻牌的输出，例如检测边缘，那么亚稳态并不是您的主要问题。 真正的问题是路径不符合设置时序，因此您可能会错过边缘检测。 如果你的设计没有使用第一个翻牌的输出而不是第二个翻牌的输出，那么你只需要考虑转移性，你就可以通过两个翻牌获得类似亚稳概率的方格。 另一方面，在该路径中添加松弛而不是平方概率。 通常，当你使用两个触发器来减轻亚稳态时，我们的假设是，由于两个触发器之间没有逻辑，因此它们之间会有很多松弛。 然而，您的原始帖子已经表明，在您的情况下，单独的路由延迟可能会消耗松弛。 - Gabor 以上来自于谷歌翻译 以下为原文 There's nothing magic about 2 ns. As I said, there is no upper limit on the length of a mtastable event. On the other hand the probability of an event lasting a particular time goes down exponentially with the time. 2 ns of slack in a modern FPGA process is generally enough that the probability of the event occuring during your lifetime is essentially zero, or at least less than the probability of any other catestrophic event happening to disrupt your design. As for the second flip-flop completely mitigating metastability, that's not true. If the first flip-flop to second flip-flop path has no slack, then any metastable event will cause the timing to fail, meaning that it is possible for the second flip-flop to also have a metastable event. While this probability is quite low already, it is not zero. And if you are using the output of the first flop as well as the second one, for instance to detect edges, then metastability isn't really your main problem. The real problem is that the path did not meet setup timing so you could miss an edge detection. If your design doesn't use the output of the first flop other than to feed the second one, then you only need to think of metastabiliy, and you do get something like a square of the probability of metastability by going through the two flops. On the other hand, adding slack in that path more than squares the probability. Generally when you use two flops to mitigate metastability, the assumption is that since there is no logic between the two flops, you'll have plenty of slack between them. However your original post already shows that in your case the routing delay alone is likely to eat up the slack. -- Gabor |
|
|
|
|
|
Gabor的解释是完全正确的。
双FF同步器的重点是确保在第二个FF采样之前为亚稳态事件留出时间。 如果您使用整个10ns进行布线，那么您还没有这样做 - 亚稳态值将传播到第二个FF，而第二个FF又可以转为亚稳态。 从那里，它可能搞乱你的系统。 正如Gabor所说，2ns没有什么神奇之处。 亚稳态事件解决所需的时间是概率性的 - 它可能需要0ps到无限的时间。 然而，概率分布是超指数的; 在2ns之后它仍然是亚稳态的概率比在1ns之后它仍然是亚稳态的概率低得多。 每个人都把MAXDELAY放在两个FF之间的路径上吗？ 不，它们没有，因此，当今的生产设备中存在亚稳态分辨率电路（那些是FPGA和ASIC），它们没有应有的亚稳态容差，或者设计师认为它们具有， 缺乏这种约束。 Avrum 以上来自于谷歌翻译 以下为原文 Gabor's explaination is completely correct. The whole point of the double FF synchronizer is to ensure that you leave time for the metastable event to resolve before it is sampled by the 2nd FF. If you use the entire 10ns for routing, then you haven't done this - the metastable value will propagate to the 2nd FF, which can, in turn, go metastable. From there, it can mess up your system. As Gabor said, there is nothing magic about 2ns. The amount of time taken for a metastability event to resolve is probabilistic - it can take anywhere from 0ps to an infinite amount of time. However, the probablility profile is super-exponential; the probability that it is still metastable after 2ns is more than exponentially lower than the probability that it is still metastable after 1ns. Does everyone put a MAXDELAY on the path between the two FFs? No, they don't, and consequently, there are metastability resolution circuits in production devices today (and those are both FPGA and ASIC) that don't have the metastability tolerance that they should have, or their designers think they have, due to the lack of this constraint. Avrum |
|
|
|
|
|
在具有24个adc（运行@ 250Mhz）的系统同步设计中，我遇到了与iodelay / iddr2类似的问题。
ddr是500Mhz。 第一个接收寄存器有时远离iddr2输出，使得路由不可能。 xst和map配置为将寄存器放入IOB，但似乎寄存器没有放在IOB中。 设计几乎是空的（使用率低于20％）。 有许多切片可用（更接近PAD）但寄存器位置很远。在第一个寄存器后，六个（附加）流水线寄存器被放置到达最终目的地。 它们中的大多数放置得非常靠近，第一个寄存器远离垫。 我的问题： 1.）为什么第一个寄存器离垫子太远？ 2.）为什么寄存器没有放入IOB？ 3.）是否有任何解决方案来自前面描述的问题？ 我附上了时间报告的片段！ - tk Slack（设置路径）： - 0.146ns（要求 - （数据路径 - 时钟路径偏差+不确定性）） 来源：adc_mpi250.DB [1] .channel [7] .bit [3] .ioddrin / ddrinput（FF） 目的地：adc_mpi250.DB [1] .channel [7] .bit [3] .ioddrin / d1（FF） 要求：4.000ns 数据路径延迟：3.410ns（逻辑电平= 1） 时钟路径偏差：-0.655ns（0.701 - 1.356） 源时钟：cti.clk在0.000ns上升 目标时钟：cti.clk上升至4.000ns 时钟不确定度：0.081ns 时钟不确定度：0.081ns（（TSJ ^ 2 + DJ ^ 2）^ 1/2）/ 2 + PE 总系统抖动（TSJ）：0.070ns 离散抖动（DJ）：0.144ns 相位误差（PE）：0.000ns 慢速过程角的最大数据路径：adc_mpi250.DB [1] .channel [7] .bit [3] .ioddrin / ddrinput to adc_mpi250.DB [1] .channel [7] .bit [3] .ioddrin / d1 位置延迟类型延迟（ns）物理资源 逻辑资源 ------------------------------------------------- - ------------------ ILOGIC_X34Y3.Q4 Tickq 1.220 adc_mpi250.DB [1] .channel [7] .bit [3] .ioddrin / q1out adc_mpi250.DB [1] .channel [7]。位[3] .ioddrin / ddrinput SLICE_X114Y17.B3 net（fanout = 1）1.977 adc_mpi250.DB [1] .channel [7] .bit [3] .ioddrin / q0out SLICE_X114Y17.CLK Tas 0.213 adc_mpi250.DB [1] .channel [7] .bit [3] .outpipe / n0005 adc_mpi250.DB [1] .channel [7]。位[3] .ioddrin / q0out_rt adc_mpi250.DB [1] .channel [7]。位[3] .ioddrin / D1 ------------------------------------------------- - -------------------------- 总计3.410ns（逻辑1.433ns，路线1.977ns） （42.0％逻辑，58.0％路线） - 以上来自于谷歌翻译 以下为原文 I have a similar problem with iodelay/iddr2 in a system synchronous design with 24 adc's ( running @ 250Mhz ). ddr is 500Mhz. the first receiving register is sometimes placed far from the iddr2 output, making a route impossible. xst and map were configured to place the registers into the IOB, but it seems the registers were not placed in the IOB. the design is almost empty (less than 20% usage). there are many slices free (much closer to the PAD) but the register is place far away. after the first register six (addtional) pipeline registers are placed to reach the final destination. most of them are placed very close together and the first register far from the pad. my questions: 1.) why the first register is placed so far away from the pad? 2.) why the registers are not placed into the IOB? 3.) was there any solution from the previously described problem? i have attached a snippet of the timing report! -- tk Slack (setup path): -0.146ns (requirement - (data path - clock path skew + uncertainty)) Source: adc_mpi250.DB[1].channel[7].bit[3].ioddrin/ddrinput (FF) Destination: adc_mpi250.DB[1].channel[7].bit[3].ioddrin/d1 (FF) Requirement: 4.000ns Data Path Delay: 3.410ns (Levels of Logic = 1) Clock Path Skew: -0.655ns (0.701 - 1.356) Source Clock: cti.clk rising at 0.000ns Destination Clock: cti.clk rising at 4.000ns Clock Uncertainty: 0.081ns Clock Uncertainty: 0.081ns ((TSJ^2 + DJ^2)^1/2) / 2 + PE Total System Jitter (TSJ): 0.070ns Discrete Jitter (DJ): 0.144ns Phase Error (PE): 0.000ns Maximum Data Path at Slow Process Corner: adc_mpi250.DB[1].channel[7].bit[3].ioddrin/ddrinput to adc_mpi250.DB[1].channel[7].bit[3].ioddrin/d1 Location Delay type Delay(ns) Physical Resource Logical Resource(s) ------------------------------------------------- ------------------- ILOGIC_X34Y3.Q4 Tickq 1.220 adc_mpi250.DB[1].channel[7].bit[3].ioddrin/q1out adc_mpi250.DB[1].channel[7].bit[3].ioddrin/ddrinput SLICE_X114Y17.B3 net (fanout=1) 1.977 adc_mpi250.DB[1].channel[7].bit[3].ioddrin/q0out SLICE_X114Y17.CLK Tas 0.213 adc_mpi250.DB[1].channel[7].bit[3].outpipe/n0005<14> adc_mpi250.DB[1].channel[7].bit[3].ioddrin/q0out_rt adc_mpi250.DB[1].channel[7].bit[3].ioddrin/d1 ------------------------------------------------- --------------------------- Total 3.410ns (1.433ns logic, 1.977ns route) (42.0% logic, 58.0% route) - |
|
|
|
|
只有小组成员才能发言，加入小组>>
2388 浏览 7 评论
2803 浏览 4 评论
Spartan 3-AN时钟和VHDL让ISE合成时出现错误该怎么办？
2270 浏览 9 评论
3338 浏览 0 评论
如何在RTL或xilinx spartan fpga的约束文件中插入1.56ns延迟缓冲区？
2438 浏览 15 评论
有输入，但是LVDS_25的FPGA内部接收不到数据，为什么？
767浏览 1评论
请问vc707的电源线是如何连接的，我这边可能出现了缺失元件的情况导致无法供电
551浏览 1评论
求一块XILINX开发板KC705，VC707，KC105和KCU1500
384浏览 1评论
1974浏览 0评论
691浏览 0评论
/6 
关注我们的微信
下载发烧友APP
电子发烧友观察
版权所有 © 湖南华秋数字科技有限公司
电子发烧友 （电路图） 湘公网安备 43011202000918 号 电信与信息服务业务经营许可证：合字B2-20210191
工商网监
湘ICP备2023018690号
2742
评论
淘帖
1364
