赛灵思
直播中

许莹

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

MAP成本表90个变体中的哪一个对应于CT2?

我在某处读到前10个MAP成本表提供了最广泛的变化算法,而剩下的90个是它们的微妙变化。我的设计非常复杂(如下所述),我在过去的会议时间里取得了很大的成功
通过改变CT来实现。
但是,在为设计添加另一个DSP路径(与先前使用的路径相同)之后,我无法满足前10个CT的任何时序。
然而,其中一些非常接近。
我正在寻找的是,如果有人知道更多关于成本表的信息。
进一步来说:
1)我在第一句中所作的陈述是真的吗?
2)如果是这样,90个变体中的哪一个对应于CT2?
设计细节:
* Virtex 6  -  SX475(最大可用)
*设计中至少30个时钟域(BUFG / BUFR)
*使用系统生成器创建的DSP子系统
* 16驱动器SATA RAID子系统
* QDR子系统(Xilinx核心)
* PlanAhead用于从多个单独的网表中实现设计
*为DSP和RAID子系统生成的分区,以便在实现定时时锁定路由

以上来自于谷歌翻译


以下为原文

I read somewhere that the first 10 MAP cost tables provide the most widely varying placement algorithm, while the remaining 90 are subtle variations on them.  My design is extremely complex (described below), and I've had a lot of success in the past meeting timing by varying the CT's.  However,  after adding another DSP path (which is identical to a previously used path) to the design, I'm not able to meet timing with any of the first 10 CT's.  A few of them are very close, however.  What I'm looking for is if anybody knows more information about the cost tables.  More specifically:

1) Is the statement I made in the first sentence true?
2) If so, which of the 90 variations correspond to CT2?

Design details:
* Virtex 6 - SX475 (largest available)
* At least 30 clock domains in the design (BUFG/BUFR)
* DSP subsystem created with system generator
* 16 drive SATA RAID subsystem
* QDR subsystem (Xilinx Core)
* PlanAhead used to implement design from a number of individual netlists
* Partitions generated for DSP and RAID subsystems to allow locking down routing when timing achieved

回帖(4)

李富才

2018-10-10 11:06:45
使用-t开关访问的所有成本表都只是随机种子,并且没有可归因于它们中的任何特定行为。
http://www.xilinx.com/support/answers/35534.htm
使用-xt访问的所谓额外成本表是不同的,旨在通常以牺牲时序QOR为代价来减少拥塞。
您可以使用的一种策略是到目前为止获取最佳结果并锁定时钟位置和大块(BRAM,DSP等),然后使用它来迭代成本表以尝试关闭时序。
您将在.map文件中找到时钟约束。
在原帖中查看解决方案

以上来自于谷歌翻译


以下为原文

All of the cost tables accessed with -t switch are just random seeds and there is no specific behavior that can be attributed to any of them.
http://www.xilinx.com/support/answers/35534.htm
 
The so called extra cost tables accessed with -xt are something different and are intended for congestion reduction usually at the expense of timing QOR.
 
One strategy that you could use would be to take your best result so far and lock down the clock placement and big block (BRAM, DSP, etc.) and then iterate cost tables with that to try to close timing. You'll find the clock constraints in the .map file.
View solution in original post
举报

李富才

2018-10-10 11:25:12
使用-t开关访问的所有成本表都只是随机种子,并且没有可归因于它们中的任何特定行为。
http://www.xilinx.com/support/answers/35534.htm
使用-xt访问的所谓额外成本表是不同的,旨在通常以牺牲时序QOR为代价来减少拥塞。
您可以使用的一种策略是到目前为止获取最佳结果并锁定时钟位置和大块(BRAM,DSP等),然后使用它来迭代成本表以尝试关闭时序。
您将在.map文件中找到时钟约束。

以上来自于谷歌翻译


以下为原文

All of the cost tables accessed with -t switch are just random seeds and there is no specific behavior that can be attributed to any of them.
http://www.xilinx.com/support/answers/35534.htm
 
The so called extra cost tables accessed with -xt are something different and are intended for congestion reduction usually at the expense of timing QOR.
 
One strategy that you could use would be to take your best result so far and lock down the clock placement and big block (BRAM, DSP, etc.) and then iterate cost tables with that to try to close timing. You'll find the clock constraints in the .map file.
举报

李玉梅

2018-10-10 11:44:04
很高兴知道我的信息不正确。
我的时钟位置已被锁定,但我可以尝试用于BRAM和DSP实例。

以上来自于谷歌翻译


以下为原文

Good to know that my information was incorrect.  My clock placement is already locked down, but I can try that for the BRAM and DSP instances. 
举报

李玉梅

2018-10-10 11:56:19
我添加了pblocks tomy DSP子系统来指导只放置DSP48和BRAM实例,而不是将它们锁定。
这很好。
这两个版本我尝试使用不同的成本表完成,没有计时错误。
谢谢。

以上来自于谷歌翻译


以下为原文

I added pblocks to my DSP subsystem to guide placement of only DSP48 and BRAM instances rather than locking them down.  This worked out great.  Both builds I tried with different cost tables completed with no timing errors.  Thanks.
举报

更多回帖

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