当MAP进入阶段10.8时分频器就会挂断

我在这里发现了这个问题。
10小时映射发生在我使用Divider Generator 3.0和Virtex6器件的时候我选择了Radix-2,1个时钟每个结果的实现。
如果我改为“高基数”或每个结果2个时钟，映射在一分钟内完成。
希望能帮助别人。
干草堆
在原帖中查看解决方案



以下为原文

I discovered the problem here.  The 10-hour mapping occurs when I used Divider Generator 3.0 with the Virtex6 device IF I selected the Radix-2, 1 clock per result, implementation.  If I changed to either "High Radix" or 2 clocks per result, the mapping finished in a minute.
Hope that helps somebody else.
 
Rick
View solution in original post

我在这里发现了这个问题。
10小时映射发生在我使用Divider Generator 3.0和Virtex6器件的时候我选择了Radix-2,1个时钟每个结果的实现。
如果我改为“高基数”或每个结果2个时钟，映射在一分钟内完成。
希望能帮助别人。
干草堆



以下为原文

I discovered the problem here.  The 10-hour mapping occurs when I used Divider Generator 3.0 with the Virtex6 device IF I selected the Radix-2, 1 clock per result, implementation.  If I changed to either "High Radix" or 2 clocks per result, the mapping finished in a minute.
Hope that helps somebody else.
 
Rick

我知道这篇文章很老，但我要感谢你解决它。
我一直试图解决这个问题。
我甚至再次写了我的模块只共享一个分频器，看看是否可以由ISE映射。
我正在使用Spartan6，因此对于Spartan6用户来说这篇文章是有效的！
ThnxRegards



以下为原文

I know this post is old, but I needed to thank you for solving it. I've been trying to solve this for days. I even wrote again my modules sharing only 1 divider to see if that could be mapped by the ISE.
 
I'm working with a Spartan6 , so for Spartan6 user this post is valid to!
 
Thnx
Regards

rikraf写道：
我在这里发现了这个问题。
10小时映射发生在我使用Divider Generator 3.0和Virtex6器件的时候我选择了Radix-2,1个时钟每个结果的实现。
如果我改为“高基数”或每个结果2个时钟，映射在一分钟内完成。
希望能帮助别人。
干草堆
听起来它试图装入一个大的组合块并使其符合时间要求。
添加第二个寄存器使分隔符流水线化，因此工具更容易使其工作。
----------------------------是的，我这样做是为了谋生。



以下为原文

rikraf wrote:
I discovered the problem here.  The 10-hour mapping occurs when I used Divider Generator 3.0 with the Virtex6 device IF I selected the Radix-2, 1 clock per result, implementation.  If I changed to either "High Radix" or 2 clocks per result, the mapping finished in a minute.
Hope that helps somebody else.
 
Rick

Sounds like it was trying to fit a large combinatorial block and make it meet timing. Adding the second register pipelined the divider, so the tools are more easily able to make it work.
----------------------------Yes, I do this for a living.

我遇到了同样的问题。
在Virtex 5上运行的Divider Generator 3.0花费了大约10个小时来映射Virtex 6.我正在运行ISE 13.2。
分频器设置：radix2,32位被除数/商，16位除数，16位小数余数，无符号，每格1个时钟。
我通过在新的XC6VLX75T项目中单独实例化分隔符来验证此错误。
Divider Generator 4.0也存在同样的问题。
每个分区切换到2个时钟可以修复它（但会破坏我现有的设计）。
我现在正在下载ISE 14.2以查看错误是否仍然存在。
-Greg



以下为原文

I've run into the same problem.  A Divider Generator 3.0 that worked on a Virtex 5 took > 10 hours to map on a Virtex 6.  I'm running ISE 13.2.  Divider settings: radix2, 32 bit dividend/quotient, 16 bit divisor, 16 bit fractional remainder, unsigned, 1 clock per division.  I verified this bug by instantiating the divider alone in a fresh XC6VLX75T project.  Divider Generator 4.0 has the same problem.  Switching to 2 clocks per division fixes it (but breaks my exisiting designs).  I'm downloading ISE 14.2 now to see if the bug still exists.
 
-Greg

该错误仍然存​​在于ISE 14.2中。
将目标设备更改为Virtex 5也可以解决问题。
我打开了一个网络案例来试图压制这个特定的bug。



以下为原文

The bug still exists in ISE 14.2.  Changing the target device to a Virtex 5 also solves the problem.  I've opened a web case to try to squash this particular bug.

Webcase的结果是这确实是工具中的一个错误。
它被标记为在未来的ISE版本中得到纠正。



以下为原文

The result of the webcase was that this is indeed a bug in the tools.  It's been flagged to be corrected in a future ISE version.

有谁知道这个bug是否已修复？
我已经测试过ISE 14.5但它似乎仍然存在。
问候，
本



以下为原文

Does anyone know if this bug has been fixed?
 
I've tested ISE 14.5 and it still seems to exist.
 
Regards,
Ben

我认为它没有得到纠正。
我刚刚在V6上用ISE 14.6和Divider Generator 4.0进行了测试，它仍然挂起。
在K7上使用Divider Generator 5.0的Vivado 2013.2实现成功，但这对您没有帮助。
祝你好运，修复这个bug真好！
也许打开另一个网络案例？在此期间，我一直在opencores.org使用硬件部门核心。
它不完全相同，但足够接近我的用途。-Greg



以下为原文

I don't think it has been corrected.  I just did a test with ISE 14.6 and Divider Generator 4.0 on a V6, and it still hangs.  Vivado 2013.2 with Divider Generator 5.0 on a K7 implements successfully, but that doesn't help you.  Good luck, it would be nice for this bug to be fixed!  Maybe open another web case?

In the interim, I've been using the Hardware Division Unit core at opencores.org.  It's not identical, but was close enough for my uses.

-Greg

Xilinx已经联系过我，说这仍然是ISE中的一个突出的错误，包括14.6。
我目前的解决方案是使用Vivado HLS为固定点分区生成系统生成器IP块。
这可以在几分钟而不是几小时内完成。
同样，HLS可用于生成VHDL / Verilog以用于标准设计，即不需要沿着System Generator路线运行。
本



以下为原文

I've been contacted by Xilinx to say that this is still an outstanding bug in ISE, inlcuding 14.6.
 
My solution at the moment is to use Vivado HLS to generate a System Generator IP block for a fixed point division.
 
This goes through map in a matter of minutes not hours.
 
Equally HLS could be used to generate VHDL/Verilog for use in a standard design, i.e. without going down the System Generator route.
 
Ben

我的一个S6项目总是花费10到12个小时进行映射，但看到这个线程后我去检查了，果然，它使用的是每个结果带有radix-2 1个时钟的分频器。
我把它改为每个结果2个时钟（幸运的是我有足够的备用周期来容纳这个）并且它现在在几分钟内映射！
杰夫



以下为原文

One of my S6 projects has always taken 10 to 12 hours to map, but after seeing this thread I went and checked, and sure enough, it's using the divider with radix-2 1 clock per result. I changed it to 2 clocks per result (fortunately I had enough spare cycles to accomodate this) and it now maps in minutes!
 
Jeff

嗨，在ISE 14.7中，有人知道这个问题是否已在这个新版本中得到修复？
我问，因为我的设计每个时钟周期需要一个结果，因此将其配置为“每个时钟的时钟”> 1将不遵守我的设计中的约束。目前我正在使用ISE 14.6，我想在更新之前知道
到这个14.7.Thanks提前。



以下为原文

Hi,

and what about in ISE 14.7, does anybody knows if this problem has been fixed in this newer version? I am asking, because my design needs one result per clock cycle, therefore configuring it to "Clocks per division">1 will not obey the constraints in my design.

Currently I'm using ISE 14.6, and I would like to know before updating to this 14.7.

Thanks in advance.

根据我的经验，这个问题仍然存在于ISE 14.7中，我正在为Zynq-7020创建一个设计，并且在使用CPD = 1的分频器时遇到48小时+映射时间。



以下为原文

To my expereince this problem still exists in ISE 14.7, I am creating a design for the Zynq-7020 and am experincing 48hr+ mapping times when using dividers with CPD = 1.

您好rikraf，我在ISE 14.5中遇到过这个问题，感谢这篇文章，我知道在哪里看，因为我在sysgen设计中有分频器。
但是，当我遇到问题时，我无法提出具体的调试计划来确定问题。
我很想知道你如何将它缩小到分频器？
您在分频器上看到了哪些文件？
你调试策略是什么？非常感谢你好



以下为原文

Hello rikraf,
I have run  into this issue in ISE 14.5 and thanks to this post, I know where to look as I have divider in my sysgen design.
However, when I was grappling with issue, I could not come up with a concrete debug plan to identify the problem.

I am very interested to know how you narrowed it down to the divider? What files did you look at to zero in on the divider? What was you debug strategy?

Thank you very much

Rohit

罗希特，
我或许可以帮助你解决这个问题。
我把它缩小到分隔符，因为我在开发阶段通过map / place和routeat几个点设置设计，以获得准确的资源使用数据。
我能够注意到构建时间已经增加了很多，并且看看最近在设计中添加了什么。
然后我继续将具有与我设计中相同设置的分隔符放入其自己的测试平台中。
这给出了相同的症状。
在这一点上，我用Google搜索并找到了这篇文章并与确认该错误的XIlinx支持团队进行了交谈，
据我所知，这个问题还没有解决。
正如之前的文章中所讨论的，一种解决方案是使用在每个时钟周期都不提供输出的分频器。
如果你绝对需要全部吞吐率（我做过），那么我看到两个主要选项，即使用两个相同的分频核心，每个核心具有半速率吞吐量。
或者我采用的选项是使用Vivado HLS生成分割核心，然后可以将其导入sysgen。
这被证明是一项足够简单的任务。
祝你好运！
本



以下为原文

Rohit,
 
I might be able to help you out wth this. I narrowed it down to the divider because I put the design through map/place and route at serveral points during the development phase in order to get accurate resource usage figures. I was therfore able to notice the build time had increased a vast amount and look at what had recently been put into the design.
 
I then proceeded to put a divider with the same settings as in my design into a testbench on it's own. This gave the same symptoms. t this point I googled around and found this post and spoke to the XIlinx Support team who confirmed the bug,
 
As far as I know this issue hasn't ben fixed yet. As discussed in previous posts one solution is to use a divider that does not provide an output on every clock cycle. If you absolutely require the full throughput rate (I did) then I see the two main options as to either use two identical divide cores each with the half rate throughput. Or the option I took which is to use Vivado HLS to generate a divide core which can then be imported to sysgen. This proved to be an easy enough task.
 
Good luck!
 
Ben

我发现问题是蛮力的方式：我在早期版本的工具中有一个工作设计，在升级之后映射永远，所以我开始删除东西，看看它加速了。
不优雅，但它让我在那里。
干草堆



以下为原文

I found the problem the brute-force way:  I had a working design in an earlier version of the tools, after upgrade the mapping took forever, so I just started removing things to see when it sped up.  Not elegant, but it got me there.
 
Rick

谢谢你



以下为原文

Thank you Ben

谢谢里克！



以下为原文

Thank you Rick!

非常感谢。
我对zynq设备有同样的问题，我尝试通过将ise设计导入Vivado来修复它。
非常难过，xilinx没有告知客户这个问题。
亨氏



以下为原文

Thanks a lot.
 
I have the same proble with a zynq device, I try to fix it by importing the ise design to Vivado.
 
It is really sad, that xilinx does not inform its customers about this problem.
 
Heinz