假设我有一个设计，其中每个最后的BEL都定位到固定位置，因此放置器基本上没有自由度。问题：改变成本表会影响路由器的行为吗？为了记录，我正在使用大约95％固定位置的设计，因此更改成本表肯定会影响我的设计。最后5％的位置很好，但是我从路由器得到了一些不理想的结果 - 它在LOC'd单元之间做了一些愚蠢的事情路由路径。我想知道是否值得花时间在Amazon EC2上购买所有100个成本表的详尽探索。不幸的是，现在我无法判断更改成本表是否会影响路由器，因为它正在改变最后5％的位置（对LOC'd区域的拥塞产生“连锁反应”）或是否更改成本表实际上导致路由器行为明显不同。在后一种情况下，尝试所有100个表格对我来说可能是值得的。PS：设备是Spartan-6，它放置在地图阶段，所以我在这里添加了成本表标志。我假设成本表选择被隐藏在ncd的某处，以便路由器可以检索它...PPS：这是一个疯狂密集的设计;如果没有放置限制，它甚至不会以10mhz路由。因此，我可能在par工具的预期使用模型之外运行。以上来自于谷歌翻译以下为原文Suppose I have a design in which every last BEL is LOC'd to a fixed location, so that the placer has essentially zero freedom. Question: will changing the cost table influence the behavior of the router? For the record, I am working with a design that is about 95% fixed-placement, so changing the cost table definitely affects my design.The placement of the last 5% is just fine, but I'm getting some suboptimal results from the router -- it's doing some kind of dumb things routing paths between LOC'd cells.I'd like to know if it's worth buying time on Amazon EC2 for an exhaustive exploration of all 100 cost tables.Unfortunately right now I can't tell if changing the cost table is affecting the router because it's changing the placement of that last 5% (which has a "ripple effect" on congestion in the LOC'd areas) or whether changing the cost table actually results in significantly different router behavior.In the latter case it's probably worth it for me to try all 100 tables. PS: the device is Spartan-6, which does placement in the map stage, so that's where I'm adding the cost-table flag.I assume the cost table choice gets stashed somewhere in the ncd so that the router can retrieve it... 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.
2018-10-11 14:42
嗨，我正在使用UltraScale器件（vu095）并且有一些关于分区引脚的问题，因为它与部分重配置有关。我正在引用UG909（v2018.1，4月27日）1. UG909给人的印象是，RM和静态区域之间的接口上的每个有源引脚都应该有一个由放置器自动插入的分区引脚（第72页）。但是，我正在查看我的界面，并非所有引脚都有分区引脚。一些具有有源驱动器和接收器（完全有效数据通路）的引脚没有插入分区。这种设计以及多种配置在电路中工作。为什么会这样？我使用get_pplocs -pin [get_pins -hier *]获取分区引脚信息。2.似乎如果我决定更新静态区域的rtl（而不是接口引脚）并重做我的所有配置，则与rtl更新之前的先前配置相比，partpins的数量发生了变化。这给我带来了麻烦。因为我的最终目标是手动放置我所有的分区引脚。为什么工具不能以一致的方式沿接口插入partpins？谢谢以上来自于谷歌翻译以下为原文Hi, I am using an UltraScale device (vu095) and have a few questions about partition pins as it relates to partial reconfiguration. I am referencing UG909 (v2018.1, April 27) 1. UG909 gives the impression that every active pin on my interface between the RM and static region should have a partition pin automatically inserted by the placer (pg 72). However, I am looking at my interface and not all pins have partition pins. Some pins which have active drivers and receivers (full active datapath) have no partpins inserted. This design along with multiple configurations works in-circuit. Why is this? I get partition pin information by using get_pplocs -pin [get_pins -hier *]. 2. It seems that if I decide to update the rtl of the static region (not the interface pins) and redo all my configurations the number of partpins changes compared to the previous configurations before the rtl update. This causes problems for me. Because my ultimate goal is the manually place all my partition pins. Why is the tool not inserting partpins along the interface in a consistent manner? Thanks
2018-11-12 14:45
最近碰到了让我困惑一段时间的事情。从某种意义上说，我有一个非常规则的设计，基本上它是一个小的 块沿着一条线复制粘贴。如同，长（192位）进位链带解码阶段。解码块是12位的块，所以那里 是沿着整个进位链处理的16个解码块中的16个全部192位。我有RLOC，LOC和BEL的所有元素，所以它是关于我可以得到它。现在大多数设计都符合时间要求限制。然而路径2确实失败了。失败的路径是其中的一部分解码块。由于进位链跨越多个时钟区域，起初我认为它可能与这些时钟区域有关。但经过一番 在fpga编辑器中更多的挖掘我注意到它的失败路径 与其他路由相比，路由有点不同。请参阅随附的fpga编辑器截图...所以这些是两片，都在同一个CLB中。弹跳的红线跨越是失败的道路。正如你可以看到从下面的4条路线切片都有一个3的扇出，一个用于上部切片中的每个LUT它路由到。所以你在截图中看到的是12条彩色路径总数，其中只有1个失败。我仍然没有发现为什么这条路线决定反弹 （并且不符合时间），而对于所有其他人在相同的块中没有问题。知道这可能是什么？我此刻的猜测是路由饥饿（不再是特定类型的路由），但是那么为什么在这两个解码块中只有2条路由失败而且为所有 其他14个街区没有问题？与此相关，是否有办法获得有关路由资源的报告用于ISE？如果我能得到每个切片的报告，总结了如何使用了每种类型的大部分路由资源，我可以找到它更快的事情，没有花费一个小时+在fpga编辑器追踪下行路径。以上来自于谷歌翻译以下为原文recently ran into something that had me puzzled for a while. I had a very regular design in the sense that essentially it was a small block copy-pasted along a line. As in, a long (192 bit) carry chain with a decode stage. The decode block was in chunks of 12 bits, so there were 16 of those decode blocks along the entire carry chain to handle all 192 bits. I had all elements in place with RLOCs, LOCs and BELs, so it was about as regular as I could get it. Now most of that design met the timing constraints. However paths 2 did fail. The failing paths were parts of the decode blocks. Since the carry chain spans multiple clocking regions, at first I thought it it might be related to these clocking regions. But after some more digging in fpga editor I noticed that for the failing paths it did the routing a bit different compared to the rest. See the attached fpga editor screenshot... So these are 2 slices, both in the same CLB. The red line that bounces across is the failing path. As you can see the 4 routes from the lower slice all have a fanout of 3, one for each LUT in the upper slice that it routes to. So what you see in the screenshot is 12 colored paths total, of which only 1 is failing. I still haven't found out why for this route it decides to bounce across (and not meet timings) while for all the others in identical blocks there is no problemo. Any idea what this can be? My guess at the moment was routing starvation (as in no more routes of a particular type), but then why do only 2 routes fail in 2 of these decode blocks while for all the other 14 blocks there is no problem? And related to that, is there a way to get a report on routing resource usage in ISE? If I could get a report for each slice that summed up how much of the routing resources of each type was used I could find this sort of thing quicker, without spending an hour+ in fpga editor tracing down paths.
2018-10-09 15:31
实现顶层设计是不可能的，因为我想生成一个时钟来驱动FPGA逻辑和使用DCM的OPAD。以下是ERROR消息。错误：位置：1206- 此设计包含一个全局缓冲区实例，驱动网络，驱动以下（前30个）非时钟源引脚片外。在Spartan-6中，这种设计实践可能由于全局布线的限制而导致不可预测的情况。如果设计确实存在路线，则该网络可能存在过度延迟或倾斜。建议使用时钟转发技术来创建可靠且可重复的低偏斜解决方案：实例化ODDR2组件;将.D0引脚连接到Logic1;将.D1引脚连接到Logic0;将时钟网连接到.C0;将倒置时钟连接到.C1。如果您希望覆盖此建议，可以使用.ucf文件中的CLOCK_DEDICATED_ROUTE约束（如下所示）将此消息降级为警告并允许您的设计继续。虽然网络可能仍未路由，但您将能够分析FPGA_Editor.ERROR中的故障：放置：1136- 此设计包含一个全局缓冲区实例，驱动网络，驱动以下（前30个）非时钟源引脚。这不是Spartan-6中推荐的设计实践，因为全局布线的限制可能导致过度延迟，歪斜或不可路由的情况。建议仅使用BUFG资源来驱动时钟负载。如果您希望覆盖此建议，可以使用.ucf文件中的CLOCK_DEDICATED_ROUTE约束（如下所示）将此消息降级为警告并允许您的设计继续。错误：包装：1654- 时序驱动的放置阶段遇到错误。谁能告诉我该怎么办？非常感谢。以上来自于谷歌翻译以下为原文It's impossible to implement the top design because I want to generate a clock to drive both FPGA logic and OPAD using DCM. the ERROR message following.ERROR:Place:1206 - This design contains a global buffer instance,, driving the net, , that is driving thefollowing (first 30) non-clock source pins off chip.< PIN: clk_98m.O; >This design practice, in Spartan-6, can lead to an unroutable situation dueto limitations in the global routing. If the design does route there may beexcessive delay or skew on this net. It is recommended to use a ClockForwarding technique to create a reliable and repeatable low skew solution:instantiate an ODDR2 component; tie the .D0 pin to Logic1; tie the .D1 pin toLogic0; tie the clock net to be forwarded to .C0; tie the inverted clock to.C1. If you wish to override this recommendation, you may use theCLOCK_DEDICATED_ROUTE constraint (given below) in the .ucf file to demotethis message to a WARNING and allow your design to continue. Although the netmay still not route, you will be able to analyze the failure in FPGA_Editor.ERROR:Place:1136 - This design contains a global buffer instance,, driving the net, , that is driving thefollowing (first 30) non-clock source pins.< PIN: clk_98m.O; >This is not a recommended design practice in Spartan-6 due to limitations inthe global routing that may cause excessive delay, skew or unroutablesituations.It is recommended to only use a BUFG resource to drive clockloads. If you wish to override this recommendation, you may use theCLOCK_DEDICATED_ROUTE constraint (given below) in the .ucf file to demotethis message to a WARNING and allow your design to continue.< PIN "cw_0/clkout1_buf.O" CLOCK_DEDICATED_ROUTE = FALSE; >ERROR:Pack:1654 - The timing-driven placement phase encountered an error. Who can tell what should I do? Thanks a lot.
2019-07-03 09:33
