请问如何在CPLD中引入延迟

我按原样尝试了你的代码。
这是我看到的：
TP1到TP4按预期将Dummy1替换为Dummy4（这只是一个名称更改）。
按预期使用了5个宏单元。
但是，连接不会根据需要串行通过5个宏单元。
优化结果来自fitter报告中的以下等式：
TP1 TP2 TP3 TP4 clkOUT
所以我尝试更改代码，以便Dummy1到Dummy4节点改为INOUT端口，并且仍然使用相同的方程式。
（这种综合优化很难）。
最后我添加了一个三态控制输入引脚，使合成器认为Dummy端口真的可以输入并最终得到：
-  Gabor
在原帖中查看解决方案
cpld_dly.vhd 2 KB



以下为原文

I tried your code as is.  Here's what I see:
 
TP1 through TP4 replace Dummy1 through Dummy4 as expected (this is just a name change).  There are 5 macrocells used as expected.  However the connections don't go serially through the 5 macrocells as desired.  Optimization results in the following equations from the fitter report:
 
TP1 <= clkIN;
TP2 <= clkIN;
TP3 <= clkIN;
TP4 <= clkIN;
clkOUT <= clkIN;


So I tried changing the code so that the Dummy1 through Dummy4 nodes were INOUT ports instead, and still got the same equations.  (This synthesis optimization is tough).  So finally I added a tristate control input pin, to make the synthesizer think that the Dummy ports could really be inputs and ended up with this:
 
-- GaborView solution in original post
            cpld_dly.vhd ‏2 KB   

这听起来很合理。
但是，我得不到它的工作。
我就是这样设置的：
实体主要是 
端口（CLKIN：IN STD_LOGIC;
TP1：OUT STD_LOGIC;
TP2：OUT STD_LOGIC;
TP3：OUT STD_LOGIC;
TP4：OUT STD_LOGIC;
clkOUT：OUT STD_LOGIC：='0'）;
结束主;
建筑行为主要是
SIGNAL Dummy1：STD_LOGIC：='0';
SIGNAL Dummy2：STD_LOGIC：='0';
SIGNAL Dummy3：STD_LOGIC：='0';
SIGNAL Dummy4：STD_LOGIC：='0';
属性keep：string;
属性保持Dummy1：信号为“true”;
属性保持Dummy2：信号为“true”;
属性保持Dummy3：信号为“真”;
属性保持Dummy4：信号是“真”;
开始
Dummy1
当我检查fitter报告时，我没有看到任何Dummy信号，只看到TP1-4。我也有一个单独的.ucf约束文件。
我是否还必须提供一些保留限制？
如果是这样我该怎么办？
任何猜测为什么这不起作用？



以下为原文

That sounds reasonable. However, I get not get it to work. This is how I set it up:
entity main is    Port(clkIN:INSTD_LOGIC;TP1:OUTSTD_LOGIC;TP2:OUTSTD_LOGIC;TP3:OUTSTD_LOGIC;TP4:OUTSTD_LOGIC;clkOUT:OUTSTD_LOGIC:= '0');end main;architecture Behavioral of main isSIGNALDummy1:STD_LOGIC:= '0';SIGNALDummy2:STD_LOGIC:= '0';SIGNALDummy3:STD_LOGIC:= '0';SIGNALDummy4:STD_LOGIC:= '0';attribute keep : string;attribute keep of Dummy1: signal is "true"; attribute keep of Dummy2: signal is "true";attribute keep of Dummy3: signal is "true";attribute keep of Dummy4: signal is "true";beginDummy1<= clkIN;Dummy2<= Dummy1;Dummy3<= Dummy2;Dummy4<= Dummy3;clkOUT<= Dummy4;-- I also added pin assignmentsTP1<= Dummy1;TP2<= Dummy2;TP3<= Dummy3;TP4<= Dummy4;end Behavioral;When I check the fitter report, I do not see any of the Dummy signals, only the TP1-4. I also have a separate .ucf constraint file. Do I have to provide some keep constraints there too? If so how do I do it? Any guesses why this is not working?

我按原样尝试了你的代码。
这是我看到的：
TP1到TP4按预期将Dummy1替换为Dummy4（这只是一个名称更改）。
按预期使用了5个宏单元。
但是，连接不会根据需要串行通过5个宏单元。
优化结果来自fitter报告中的以下等式：
TP1 TP2 TP3 TP4 clkOUT
所以我尝试更改代码，以便Dummy1到Dummy4节点改为INOUT端口，并且仍然使用相同的方程式。
（这种综合优化很难）。
最后我添加了一个三态控制输入引脚，使合成器认为Dummy端口真的可以输入并最终得到：
-  Gabor
cpld_dly.vhd 2 KB



以下为原文

I tried your code as is.  Here's what I see:
 
TP1 through TP4 replace Dummy1 through Dummy4 as expected (this is just a name change).  There are 5 macrocells used as expected.  However the connections don't go serially through the 5 macrocells as desired.  Optimization results in the following equations from the fitter report:
 
TP1 <= clkIN;
TP2 <= clkIN;
TP3 <= clkIN;
TP4 <= clkIN;
clkOUT <= clkIN;


So I tried changing the code so that the Dummy1 through Dummy4 nodes were INOUT ports instead, and still got the same equations.  (This synthesis optimization is tough).  So finally I added a tristate control input pin, to make the synthesizer think that the Dummy ports could really be inputs and ended up with this:
 
-- Gabor            cpld_dly.vhd ‏2 KB   

这很有效。
非常感谢。
我希望我不必使用外部引脚。



以下为原文

This works. Thank you so much. I wish I did not have to use external pins.

有趣的是，在我发布代码之后，我查看了“PADS”到“PADS”的时间，并注意到时序分析器没有看到反馈路径是clkIN路径的延续。
我给出了28 ns的最大延迟时间，并且工具表示它达到3.8 ns，但是查看详细报告它只显示从每个输入到下一个输出的路径，而不是通过反馈后的输出路径的延续
。
我假设您可以通过将各个延迟相加来计算通过该部分的最大延迟，但是从clkIN到clkOUT的路径未被约束覆盖似乎很奇怪。
-  Gabor



以下为原文

It's interesting that after I posted that code I looked at the timing for "PADS" to "PADS" and noticed that the timing analyzer doesn't see the feedback paths as a continuation of the clkIN path.  I gave a max delay time of 28 ns, and the tools said it met 3.8 ns, however looking at the detailed report it only showed paths from each input to the next output, not the continuation of the path to the output after that via feedback.  I presume that you could calculate the axtual max delay through the part by just adding up the individual delays, but it did seem odd that the path from clkIN to clkOUT was not covered by the constraint.
-- Gabor