“阶段2.7设计可行性检查”占用了95％的构建时间从哪里开始寻找改进？

您的设计中有多少个时钟域？
通常问题不会那么多
LUTS和flops的数量需要映射多少个时钟区域。
这个事实
你只有80％占用切片，似乎暗示你的设计部分需要打包
很紧，可能适合某个时钟区域。
全球时钟没有这个问题。
如果你是
仍处于进行小改动和重建的设计阶段，你可能会得到一些缓解
使用引导放置，或锁定所有非结构组件，如时钟缓冲器，
PLL，DCM，Block RAM，DSP48等。另一种可能性是你使用很大的百分比
可用的分布式内存/ SRL切片。
在Spartan 6中，只有一部分切片可以
用于分布式内存或SRL。
-  Gabor
-  Gabor



以下为原文

How many clock domains do you have in your design?  Usually the issues would not be so much
with the number of LUTS and flops as how many clock regions need to be mapped.  The fact that
you have only 80% occupied slices, seems to imply that parts of your design need to be packed
quite tightly, possibly to fit within a certain clock region.  Global clocks don't have this issue.  If you're
still in the design stages of making small changes and re-building, then you might get some relief
using a guided placement, or by locking down all of the non-fabric components like clock buffers,
PLLs, DCMs, Block RAMs, DSP48s, etc.  Another possibility is that you are using a large percentage
of the available distributed memory / SRL slices.  In Spartan 6 only a subset of the slices can be
used for distributed memory or SRL.
 
-- Gabor
-- Gabor

你在这个设计中使用硬宏吗？



以下为原文

Are you using hard macros in this design?

gszakacs，只有两个时钟域，其中一个是2mhz时钟（STARTUP_SPARTAN6内部振荡器），在所有路径上都有大量的松弛。
bwade，不，我还没有使用硬宏......
但我正朝那个方向前进。
但是，我设计中> 95％的BEL是针对特定切片的LOC（有时是切片内的特定BEL）。
您是否建议将我的设计分解成碎片（分别映射它们并创建硬宏）将是处理此问题的最佳方法？
或者你是否指出硬宏有时会导致映射器花费很长时间？



以下为原文

gszakacs, there are only two clock domains, and one of them is a 2mhz clock (the STARTUP_SPARTAN6 internal oscillator) that has massive amounts of slack on all paths.
 
bwade, no, I'm not using hard macros... yet.  But I'm moving in that direction.  However, >95% of the BELs in my design are LOC'd to specific slices (and sometimes to specific BELs within the slice).
 
Were you suggesting that breaking up my design into pieces (mapping them separately and creating hard macros) would be the best way to deal with this?  Or were you indicating that hard macros can sometimes lead to the mapper taking a long time?

不，我不推荐硬宏，我认为这可能是你问题的根源。
我现在怀疑它是大量的LOC限制。
您可以通过在没有LOC的情况下运行设计来测试该理论，以查看运行时间是否有所改善。
大型RPM宏可能会更容易地处理所有LOC，但这只是一个想法，而不是已知的事实。



以下为原文

No, I'm not recommending hard macros, I thought that might be the source of your problem. I now suspect it's the large quantity of LOC constraints. You can test that theory by running the design without the LOCs to see if the run time improves. It's possible that a large RPM macro would be processed more easily the all the LOCs but that's just an idea, not a known fact.

哦，实际上，我已经这样做了 - 我应该更清楚这一点。
我有大约150个HU_SET（RPM宏）;
我设计中95％的BEL属于这些组中的一个。
150个HU_SET中的每一个都有一个带有RLOC_ORIGIN的代表元素，因此放置器在决定放置这些BEL的位置时没有自由。
但这并不像我有100,000个单独的LOC约束！
那么....还有其他想法吗？
感谢您提出的任何建议！



以下为原文

Oh, actually, I'm already doing that -- I should have been more clear about this.
 
I have about 150 HU_SETs (RPM macros); 95% of the BELs in my design belong to one of these groups.  Each of the 150 HU_SETs has a representative element with an RLOC_ORIGIN, so the placer has zero freedom in deciding where to put these BELs.  But it's not like I have 100,000 individual LOC constraints!
 
So.... any other ideas?  Thanks for any suggestions you can come up with!