UCF中的时序约束在组合设计中被忽略了？

嗨，
我正在使用ISEon纯粹的AES密码编码器组合实现（仅用于与其他流水线/迭代实现进行比较）。
设计绝对没有时钟：只是明文和
键输入（2 x 128b）和密文输出（128b）。
在xc6slx75-3fgg676设备中实现顺利（23％切片利用率）但是我不能在UCF文件中使用FROM ... TO约束来优化组合pad-to-pad传播。
UCF看起来像这样：
NET“P”TNM =“TNM_P”;
#brintext输入
NET“C”TNM =“TNM_C”;
#ciphertext输出
tiMESPEC TS1 =从“TNM_C”到“TNM_P”75 ns;
＃75 ns是一个合理的目标
然后，在实现过程中，我从map，par和trce中收到以下警告：
警告：时序：3223  - 时序约束TS1 =从TIMEGRP“TNM_C”到TIMEGRP“TNM_P”的MAXDELAY在时序分析期间忽略75 ns。
现在答案AR＃29290说明了这一点：
“如果具有更高优先级的其他约束覆盖它或者时间组中没有元素，则将忽略约束。警告也可能是由于引用的时序组中的元素之间没有同步数据路径引起的。”
在我的情况下，显然设计中没有同步数据路径，所以我的问题是......
即使在纯粹的组合设计中，如何覆盖此警告并强制约束？
（在流程中找不到任何选项）
如果没有，是否还有其他方法对组合单位进行时序分析？
任何评论将不胜感激！
标记
PS。
我记得几年前我用这种方式成功地使用了约束，ISE 9和Spartan-3EI相信。



以下为原文

Hi,

I am working with ISE on a purely combinatorial implementation of the AES cipher encoder (just for comparison with other pipelined/iterative implementations). The design has absolutely no clocks: just plaintext & key inputs (2 x 128b) and ciphertext output (128b).

The implementation goes smoothly in xc6slx75-3fgg676 device (23% slice utilization) BUT I cannot use the FROM...TO constraint in UCF file to optimize combinatorial pad-to-pad propagation. The UCF looks just like this:

NET "P<*>" TNM="TNM_P";     # plaintext inputs
NET "C<*>" TNM="TNM_C";     # ciphertext outputs
TIMESPEC TS1=FROM "TNM_C" TO "TNM_P" 75 ns;    # 75 ns as a reasonable goal

Then, during implementation, I get the following warnings from map, par and trce:

WARNING:Timing:3223 - Timing constraint TS1 = MAXDELAY FROM TIMEGRP "TNM_C" TO TIMEGRP "TNM_P" 75 ns ignored during timing analysis.

Now the answer AR#29290 says about this:

"The constraint will be ignored if other constraints with higher priority override it or there is no element in the timegroup. The warning can also be caused by there being no synchronous data paths between the elements in the referenced timing group."

In my case obviously there are no synchronous data paths in the design so my questions are...

How can I override this warning and force the constraint even in purely combinatorial designs? (can't find any option in the processes)

If not, is there any other way of timing analysis of combinatorial units?

Any comments will be greatly appreciated!

Mark

PS.
I can remember that I was using the constraint in this way successfully few years ago, with ISE 9 and Spartan-3E I believe.