“布局成本表”会影响路由器吗？

成本表仅通过在早期注入一些随机性来影响放置。
完全没有对路由器的影响。
在原帖中查看解决方案



以下为原文

Cost tables only affect placement by injecting some randomness early on. There is no affect on the router at all.
View solution in original post

成本表仅通过在早期注入一些随机性来影响放置。
完全没有对路由器的影响。



以下为原文

Cost tables only affect placement by injecting some randomness early on. There is no affect on the router at all.

谢谢，bwade！
这使我免于花时间（和金钱）进行一项无法奏效的实验。



以下为原文

Thank you, bwade!  That saved me from spending time (and money) on an experiment which wouldn't have worked.

“PPS：这是一个非常密集的设计;如果没有放置限制，它甚至不能以10mhz路由。所以可能是我在par工具的预期使用模式之外操作。”
您是否已在MAP阶段实施了所有可用选项以减少逻辑拥塞（例如全局优化，等效寄存器删除等）以帮助在设备中创建一些空间？
您是否以最佳方式使用设备资源（例如，将同步resetFSM移动到本地BRAM而不是在切片中占用LUT等）？
我正在努力缩小从LX45T到LX25T的设计，坦率地说，我正在通过利用Spartan 6架构产生一些惊人的结果（无论如何我都很惊讶）。
如果您还没有，我完全建议您使用UG687 v13.3的大部分内容来帮助优化设计。
问候，
霍华德
----------“我们必须学会做的事情，我们从实践中学习。”
- 亚里士多德



以下为原文

"PPS: this is an insanely dense design; it won't even route at 10mhz without the placement constraints.  So it might be that I'm operating outside the intended usage model for the par tools."
 
Have you implemented all of the available options at the MAP stage to reduce logic congestion (e.g. global optimisation, equivalent register removal, etc.) to help create some space in the device?
 
Are you utilising the device resources in the most optimal way (e.g. moving synchronously reset FSMs into local BRAM rather than taking up LUTs in slices, etc.)?
 
I'm working with shrinking a design from an LX45T to an LX25T and, frankly, I'm producing some amazing results (amazing to me, anyway) by taking advantage of the Spartan 6 architecture.
 
If you haven't already, I thoroughly recommend working through most sections of UG687 v13.3 to help optimise the design.
 
Regards,
 
Howard
 
----------
"That which we must learn to do, we learn by doing." - Aristotle

嗨hgleamon1，
您是否已在MAP阶段实施了所有可用选项以减少逻辑拥塞（例如全局优化，等效寄存器删除等）以帮助在设备中创建一些空间？
这些都没有效果;
我的设计不仅是手工放置，也是手工绘制的。
它完全由FDCE，LUT6_2和SRL16构建。
我不在自动工具有用的制度之外，但不幸的是没有任何合理的方法来手动进行路由。
您是否以最佳方式使用设备资源（例如，将同步resetFSM移动到本地BRAM而不是在切片中占用LUT等）？
是的，当然，虽然我的设计没有状态机 - 但它是一个高度流水线的数据路径。
我正在努力缩小从LX45T到LX25T的设计，坦率地说，我正在通过利用Spartan 6架构产生一些惊人的结果（无论如何我都很惊讶）。
恭喜。
如果您还没有，我完全建议您使用UG687 v13.3的大部分内容来帮助优化设计。
我认为你的意思是UG384--这就是所有好吃的东西。
UG389也很有用;
如果你盯着它足够长的时间，你就可以弄清楚如何将DSP48变成一个16x6的移位寄存器 - 一旦你用完SLICEM就非常方便了。



以下为原文

Hi hgleamon1,
 
Have you implemented all of the available options at the MAP stage to reduce logic congestion (e.g. global optimisation, equivalent register removal, etc.) to help create some space in the device?
 
These have no effect; my design is not only hand-placed, but hand-mapped as well.  It is built entirely from FDCE's, LUT6_2's, and SRL16's.  I am outside of the regime where the automatic tools are useful, but unfortunately there isn't any reasonable way to do the routing manually.
 
Are you utilising the device resources in the most optimal way (e.g. moving synchronously reset FSMs into local BRAM rather than taking up LUTs in slices, etc.)?
 
Yes, of course, though my design has no state machines -- it's one big highly-pipelined data path.
 
I'm working with shrinking a design from an LX45T to an LX25T and, frankly, I'm producing some amazing results (amazing to me, anyway) by taking advantage of the Spartan 6 architecture.
 
Congratulations.
 
If you haven't already, I thoroughly recommend working through most sections of UG687 v13.3 to help optimise the design.
 
I think you meant  UG384 -- that's where all the goodies are.
 
UG389 is useful too; if you stare at it long enough you can figure out how to turn a DSP48 into a 16x6 shift register -- something that's really handy once you run out of SLICEM's.

这些都没有效果;
我的设计不仅是手工放置，也是手工绘制的。
它完全由FDCE，LUT6_2和SRL16构建。
我不在自动工具有用的制度之外，但不幸的是没有任何合理的方法来手动进行路由。
这听起来像是一项糟糕的工作。
我可以问一下你在做什么，以及你的目标设备是什么？
- 阿德里安
请在询问之前先查询您的问题。如果有人回答您的问题，请在“接受为解决方案”标记该帖子。
如果你看到一个特别好的和信息丰富的帖子，考虑给它Kudos（左边的星）。



以下为原文

These have no effect; my design is not only hand-placed, but hand-mapped as well.  It is built entirely from FDCE's, LUT6_2's, and SRL16's.  I am outside of the regime where the automatic tools are useful, but unfortunately there isn't any reasonable way to do the routing manually.

That sounds like an awful amount of work. May I ask what you're working on, and what device you target?
 
– Adrian

Please google your question before asking it.
If someone answers your question, mark the post with "Accept as solution". If you see a particularly good and informative post, consider giving it Kudos (the star on the left).

这听起来像是一项糟糕的工作。
不;
我用比Verilog更高级的语言编写我的代码，具有极深的层次结构（以及“底层”的Xilinx原语）。
我的很多工作建立在Satnam Singh开创的创意之上，他是第一个真正开发这种方法的人之一：
http://raintown.org/lava/ 
http://doi.ieeecomputersociety.org/10.1109/FPGA.2000.903401
http://research.microsoft.com/apps/pubs/default.aspx?id=143636
用Xilinx原语构建东西真的不像听起来那么困难！
问题不是原语，而是Verilog语言。
Verilog根本不具备您需要的强大的抽象机制，以使这种事情变得愉快和容易。
如果我曾试图在Verilog中“直接”这样做，那么是的，这将是“非常多的工作”。
我可以问一下你在做什么，以及你的目标设备是什么？
该设备是Spartan-6 LX150。
我已经远远高于150mhz，在-2速度等级上注册利用率为63％，并朝着200mhz的目标努力。
再一次，这一切都非常好用，除非路由器出于某种原因决定将我的路线发送到街区一杯咖啡。
我对它的行为感到非常困惑。
我几乎总能在fpga_editor中手动修复其不良路线，只需将一条路线取消路由，然后手动重新路由它，这样路由器就可以俯瞰更好的路线了。
我不知道如何以一种让它“注意到”更好路径的方式戳它。
:(通常更好的路线涉及长线...也许帕尔被编程为不使用这些除非绝对必要？似乎在我的设计中根本没有使用它们，但这可能是因为手放置意味着
在xy网格术语中，每个信号的源和负载都不会很远（在任一方向上不超过24个切片，通常比这少得多）。



以下为原文

That sounds like an awful amount of work.
 
Nope; I write my code in a much-higher-level language than Verilog with extremely deep hierarchies (and Xilinx primitives at the "bottom level").  A lot of my work builds on ideas pioneered by Satnam Singh, who was one of the first to really develop this approach:
 
  http://raintown.org/lava/
  http://doi.ieeecomputersociety.org/10.1109/FPGA.2000.903401
  http://research.microsoft.com/apps/pubs/default.aspx?id=143636
 
Building stuff out of Xilinx primitives really is not as difficult as it sounds!  The problem isn't the primitives, it's the Verilog language.  Verilog simply doesn't have the kind of powerful abstraction mechanisms you need in order to make this kind of thing pleasant and easy.  If I had tried to do this "directly" in Verilog then yes, it would have been "an awful amount of work".
 
May I ask what you're working on, and what device you target?
 
The device is a Spartan-6 LX150.  I'm already well above 150mhz with 63% register utilization on the -2 speed grade and working towards a goal of 200mhz.
 
Again, it all works really nicely except when the router for some reason decides to send my routes around-the-block for a cup of coffee.  I am pretty baffled by its behavior.  I can almost always fix its bad routes by hand in fpga_editor by unrouting just the one route and then manually re-routing it, so clearly the router is overlooking a better route.  I don't know how to poke it in a way that gets it to "notice" the better path. :(  Often the better route involves long-lines... maybe par is programmed to refrain from using these unless absolutely necessary?  It seems to not be using them at all in my design, but that's probably because the hand-placement means that the source and load of each signal are never very far away in x-y grid terms (no more than 24 slices in either direction and usually a lot less than that).
 

您可以选择使用定向路由约束来控制路由。
如果您的设计具有重复的BEL放置模式，则可以在共享相同精确相对引脚位置的网络上重复使用DIRT约束。
在FPGA编辑器中，工具 - >直接路由约束。
使用生成的窗口提取现有手动路由的路由数据。
在UCF中插入生成的约束。
有添加LOC或RLOC约束的选项，但您不需要这些。



以下为原文

You have the option of controlling the routing with Directed Routing constraints. If your design has repeated patterns of BEL placement, you can reuse the DIRT constraints on nets that share the same exact relative pin locations.
 
In FPGA Editor, Tools--> Direct Routing Constraints. Use the resulting window to extract routing data for existing manual routing. Insert the resulting constraints in your UCF. There are options for adding LOC or RLOC constraints, but you don't need these.

嗨bwade，
如果您的设计具有重复的BEL放置模式，则可以在共享相同精确相对引脚位置的网络上重复使用DIRT约束。
哇，你是说DIRT字符串指定相对于网络驱动程序的路由资源位置序列而不是路由资源的绝对位置序列？
我一直认为DIRT字符串就像LOC约束而不是RLOC约束！
我希望我错了！
听起来你说如果我有一个DIRT字符串，例如，SLICE_X10Y10中的B6LUT到SLICE_X20Y10中C6LUT的A0输入，我可以重复使用该字符串从SLICE_X10Y30的B6LUT到A0输入
SLICE_X20Y30中的C6LUT。
有没有办法“切断”从切片到切换盒的DIRT字符串部分，反之亦然？
这样我就可以为给定切片中的任何BEL重复使用相同的DIRT字符串。
从你上面写的内容来看，它听起来就像是路径的一部分让你从驱动程序的切片（并进入开关盒），并在负载的开关盒（和切片）之外由DIRT字符串固定。
在实践中，PAR总是在路线的那一部分做正确的事情......它从交换机最接近驱动器到交换机最接近负载，事情进展不顺利。
有没有办法锁定路由的switchbox-switchbox部分？
如果我有这个，我可以从少量的DIRT字符串中获得大量的重用。
感谢您指出了这一点！



以下为原文

Hi bwade,
 
If your design has repeated patterns of BEL placement, you can reuse the DIRT constraints on nets that share the same exact relative pin locations.
 
Woah, are you saying that DIRT strings specify a sequence of routing resource positions relative to the net driver rather than a sequence of absolute positions of routing resources?
 
I had always assumed DIRT strings were like LOC constraints rather than RLOC constraints!  I hope I was wrong about that!
 
It sounds like you're saying that if I have a DIRT string from, say, the B6LUT in SLICE_X10Y10 to the A0 input of the C6LUT in SLICE_X20Y10 I can re-use that string to get from the B6LUT of SLICE_X10Y30 to the A0 input of the C6LUT in SLICE_X20Y30.
 
Is there a way to "chop off" the part of the DIRT string that goes from a slice to a switchbox and vice versa?  That way I could re-use the same DIRT string for any BEL within a given slice.  From what you wrote above it sounds like the part of the route that gets you out of the slice (and into the switchbox) at the driver and out of the switchbox (and into the slice) at the load are fixed by the DIRT string.  In practice PAR always does the right thing with that part of the route... it's getting from the switchbox-closest-to-the-driver to the switchbox-closest-to-the-load where things aren't turning out well.  Is there some way to lock down just the switchbox-to-switchbox part of the route?  If I had that I could get a whole lot of re-use out of a small number of DIRT strings.
 
Thanks for pointing this out!

是的，DIRT约束是相对约束。
不，您无法手动编辑它们。



以下为原文

Yes, DIRT constraints are relative constraints. No, you can't manually edit them.