同步过程中频繁的随机错误

E，
您的时序报告是什么样的（特别是失败位的路径）？
你有多松弛？
Austin Lesea主要工程师Xilinx San Jose



以下为原文

e,
 
What does your timing report look like (specifically the paths for the bit that is failing)?
 
How much slack do you have?
 
 
Austin Lesea
Principal Engineer
Xilinx San Jose

这提出了另一个问题。
我对twx不太熟悉，但是twx没有显示来自此模块的实例0或1的任何内容。
它确实显示了实例2和3，它们在某些路径上具有> 2.6ns的松弛。
我也找不到实例2和3的所有信号。
我一直在测试实例0。
这些是不受限制的路径吗？
我认为如果你通过输入时钟进行约束，那么从该时钟得到的所有内容都会受到整个设计的约束，包括通过DCM。
在顶层模块中，i_ema_clk转到DCM，它发送ema_clk，它连接到dsmspi_clk_i和每隔一个时钟。
dsmspi_sclk_base_i也派生自fromema_clk / 25。
NET“i_ema_clk”TNM_NET =“i_ema_clk”; TIMESPEC“TS_ema_clk”= PERIOD“i_ema_clk”10 ns HIGH 50％; OFFSET = IN 3 ns有效4 ns“i_ema_clk”上升之前; INST“io_ema_d”TNM =“TG_io_ema_d”; TIMEGRP
“TG_io_ema_d”OFFSET =在“i_ema_clk”上升后8 ns;
OL760_top.twx 132 KB



以下为原文

That brought up another question.
I'm not familiar enough with the twx, but the twx does not show anything from instance 0 or 1 of  this module.
It does show instances 2 and 3, which have >2.6ns slack on certain paths.
I also can't find all the signals of instances 2 and 3.
I have been testing on instance 0.
 
Could these be unconstrained paths?
 
I thought that if you constrain by the input clock, everything derived from that clock is constrained through the entire design, including through DCMs.
In the top module, i_ema_clk goes to a DCM, which sources ema_clk, which is connected to dsmspi_clk_i and every other clock.
dsmspi_sclk_base_i is also derived from ema_clk / 25.
 
NET "i_ema_clk" TNM_NET = "i_ema_clk";
TIMESPEC "TS_ema_clk" = PERIOD "i_ema_clk" 10 ns HIGH 50 %;
OFFSET = IN 3 ns VALID 4 ns BEFORE "i_ema_clk" RISING;
INST "io_ema_d<*>" TNM = "TG_io_ema_d";
TIMEGRP "TG_io_ema_d" OFFSET = OUT 8 ns AFTER "i_ema_clk" RISING;
            OL760_top.twx ‏132 KB

E，
附加的.twx对我（至少对我来说）没用，我需要查看报告。
确实，您可能拥有无约束路径，这些路径将出现在最终报告中。
Austin Lesea主要工程师Xilinx San Jose



以下为原文

e,
 
The attached .twx is not useful (to me, at least), I need to see the reports.  It is true that you may have unconstrained paths, and these will appear in the final reports.
 
 
Austin Lesea
Principal Engineer
Xilinx San Jose

twr是唯一需要的吗？
OL760_top.twr 96 KB



以下为原文

Is the twr the only one needed?
            OL760_top.twr ‏96 KB

一个约束没有达到，57个错误......
我认为你应该仔细阅读，并修复不符合hte约束的路径，并解决57个错误......
是的，这是正确的文件。
Austin Lesea主要工程师Xilinx San Jose



以下为原文

One constraint not met, and 57 errors....

I think you should read it carefully, and fix the path that doesn't meet hte constraint, and resolve the 57 errors...
 
Yes, that is the correct file.
Austin Lesea
Principal Engineer
Xilinx San Jose

我正在与电路板供应商Critical Link讨论OFFSET约束问题。
那些时序违规发生在EMIF总线上。
这应该对不相关的模块产生影响吗？



以下为原文

I'm working on the OFFSET constraint issue with the board vendor, Critical Link.
Those timing violations are on the EMIF bus.
Should that have an effect on unrelated modules?

我遇到了所有的时序限制。
我也升级到ISE 14.5。
我仍然有移位寄存器的原始问题，随机地锁定m***的错误值。
有任何想法吗？
OL760_top.twr 100 KB



以下为原文

I have all timing constraints met.
I also upgraded to ISE 14.5.
 
I still have the original problem of the shift register randomnly latching the wrong valuur for the m***.
Any ideas?
 
            OL760_top.twr ‏100 KB

？
您是否注意到第一个周期约束分析了0个路径？
那是对的吗？
与之无关的约束？
Austin Lesea主要工程师Xilinx San Jose



以下为原文

?
 
Did you notice the first period constraint has 0 paths analyzed?
 
Is that correct?
 
A constraint that has nothing associated with it?
Austin Lesea
Principal Engineer
Xilinx San Jose

我认为那是因为它直接转向DCM而不是其他地方。
“派生约束报告”表示DCM输出分析了18681个路径。



以下为原文

I think that's because it goes directly to a DCM and nowhere else.
The "Derived Constraint Report" says there are 18681 paths analyzed by the DCM output.

我最初发送的IP dsm_spi_iface.vhd只有一个时钟，它是DCM的输出，通过该时钟约束（到10ns周期约束）。
该错误是该模块的内部错误。
我怀疑这是一个时间限制问题。
请看我原来的帖子，以及随附的vhd。
我可以在逻辑分析仪上看到，从模块内部的测试点，设置时间非常充足，但仍然会发生错误。
必须有一些我看不到的东西。



以下为原文

The IP that I initially sent, dsm_spi_iface.vhd, has only one clock, which is the output of the DCM, by which it is constrained (to the 10ns period constraint).
 
The error is internal to that module.
I doubt it's a timing constraint issue.
Please look at my original post, and the attached vhd.
 
I can see on my logic analyzer, from testpoints from within the module, extremely ample setup time and still the error occurs.
There must be something that I cannot see.