赛灵思
直播中

罗敏

7年用户 222经验值
私信 关注
[问答]

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.

回帖(3)

潘晶燕

2018-10-10 11:22:47
Mark,在电路的输出端添加一些寄存器,然后从BUFG中为它们计时,然后更简单的PERIOD约束解决了所有问题。在为同步逻辑设计的设备中,尝试做任何事情只是浪费时间。
Austin Lesea主要工程师Xilinx San Jose
在原帖中查看解决方案

以上来自于谷歌翻译


以下为原文

Mark,

Add some registers at the outputs of your circuit, and clock them from a BUFG, and then a simpler PERIOD constraint solves all your problems.

In a device designed for synchronous logic, trying to do anything else is just a waste of time.
Austin Lesea
Principal Engineer
Xilinx San JoseView solution in original post
举报

潘晶燕

2018-10-10 11:29:10
Mark,在电路的输出端添加一些寄存器,然后从BUFG中为它们计时,然后更简单的PERIOD约束解决了所有问题。在为同步逻辑设计的设备中,尝试做任何事情只是浪费时间。
Austin Lesea主要工程师Xilinx San Jose

以上来自于谷歌翻译


以下为原文

Mark,

Add some registers at the outputs of your circuit, and clock them from a BUFG, and then a simpler PERIOD constraint solves all your problems.

In a device designed for synchronous logic, trying to do anything else is just a waste of time.
Austin Lesea
Principal Engineer
Xilinx San Jose
举报

何夏庄

2018-10-10 11:44:23
奥斯汀,
非常感谢您的回答,我会按照您的建议使用解决方法。
我只是向我保证,我对情况的解释是正确的。
是的,coursethis设计是一个学术范例,仅用于与其他_synchronous_ architecture进行比较。
问候!
标记

以上来自于谷歌翻译


以下为原文

Austin,
 
Thank you very much for your answer, I will use the workaround as you suggested. It just reassured me that my interpretation of the situation was correct.
 
And yes, of course this design is an academic example, just for comparison with other _synchronous_ architectures.
 
Regards!
 
Mark
 
举报

更多回帖

发帖
×
20
完善资料,
赚取积分