VHDL XST 没有正确合成 [英] VHDL XST not synthesizing correctly

问题描述

我一直在使用 Xilinx ISE 14.2 在 VHDL 中开发数据包排序管道.为了使结构通用，我在一个包中编写了一些算法来确定如何连接排序节点.有趣的是，当我围绕这些功能设计一个测试台时，结果是正确的.当我使用生成和函数的组合在项目中模拟我的设计时，硬件连接正确.(使用 'assert false report " & integer'image(layer);' 在模拟中验证)但是，当我生成 RTL 原理图时，我可以看到 某些 节点未正确连接.

I've been working on a packet sorting pipeline in VHDL using Xilinx ISE 14.2. In order to make the structure generic I wrote a few algorithms in a package that will determine how to connect sorting nodes. Interestingly when I design a test bench around the functions the results are correct. When I simulate my design in the project using a combination of generates and functions the hardware is wired correctly. (used 'assert false report " & integer'image(layer);' to validate in simulation) However when I generate the RTL schematic I can see that some nodes AREN'T connected correctly.

我 90% 确定这是一个错误，但我说我不是这个软件的老手.函数正常工作，在这个阶段可能已经使用了 2% 的可用资源.是否有任何人知道的秘密标志或特性?

I'm 90% sure this is a bug but saying that I'm no veteran with this software. Functions works, at this stage maybe 2% of the available resources have been used. Are there any secret flags or peculiarities anyone knows of?

谢谢大家.问候，史蒂夫

Thanks a mil' everyone. Regards, Steve

推荐答案

XST 非常可靠.

我在 XST 中看到的唯一真正的错误硬件错误与作为 OUT 参数传递给进程内的过程的信号有关……信号是使用变量赋值(立即赋值)语义分配的！

The only genuine wrong-hardware bug I have seen in XST has to do with signals passed as OUT parameters to procedures within a process... the signals were assigned using variable assignment (immediate assignment) semantics!

在 ISE14 中，此错误仍然存​​在 - 在针对 Spartan-3 和较旧设备时，但在针对 Spartan-6 和较新设备时不存在.事实证明，XST 有两种不同的 VHDL 解析器，新的似乎更好.

In ISE14 this bug is still present - when targeting Spartan-3 and older devices, but not when targeting Spartan-6 and newer devices. It turns out that XST has two different VHDL parsers, the newer one seems to be better.

因此您可以再次尝试，使用其他解析器(通过更改目标系列，或use_new_parser"设置或命令行选项)- 有关详细信息，请参阅 Xilinx 文档.

So you can try again, using the other parser (either by changing target family, or the "use_new_parser" setting or command line option)- see Xilinx docs for details.

您还可以将合成后网表插入您的测试平台并重现(或不重现！)模拟中的错误.(IMO 后合成和后 PAR 模拟的唯一实际用途是确认或消除可能的工具错误！)

You can also plug the post-synth netlist into your testbench and reproduce (or not!) the errors in simulation. (IMO the only practical use for post-synth and post-PAR simulation is confirming or eliminating possible tool bugs!)

而且 - 正如菲利普所说 - 分而治之，直到你有一个小小的演示者 - 或者找出真正的问题！

And - as Phillippe says - divide and conquer the design until you either have a tiny demonstrator - or find out what the real problem is!

添加来演示几点...

给定 l,n 的正确整数值，我们可以更仔细地描述这个问题......从上面的断言，我们可以推导出 n=8，l=3.

Given the correct integer values for l,n we can characterise this problem more closely... From the asserts above, we can deduce that n=8, l=3.

    library IEEE;
    use ieee.math_real.all;

    entity count is
    end count;

    architecture Behavioral of count is

    constant n : integer := 8;
    constant l : integer := 3;

    begin

       report "n: " & integer'image(8) severity Note;
       assert false report "r: " & real'image(8.0) severity Note;
       report "Border a: " & real'image(real(n) + ( real(n) mod 2.0)) severity Note;
       report "Border b: " & real'image(2.0**(real(l+1) - 1.0)) severity Note;
       report "Border a/b: " & real'image((real(n) + ( real(n) mod 2.0))/(2.00 ** (real(l+1) - 1.0))) severity Note;
       report "Ceil a/b: " & real'image(ceil((real(n) + ( real(n) mod 2.0))/(2.00 ** (real(l+1) - 1.0)))) severity Note;
       report "Residual a/b: " & real'image((real(n) + ( real(n) mod 2.0))/(2.00 ** (real(l+1) - 1.0)) - 1.0 ) severity Note;

    end Behavioral;

1) 不需要Assert False"(自 1993 年以来)

1) "Assert False" is not necessary (since 1993)

2) 与流行的神话相反，断言可以被综合，前提是它们的条件是静态可确定的.因此在上面的代码中，其中 l,n 是常数，XST 合成，报告 ...

2) Contrary to popular myth, asserts CAN be synthesised provided their conditions are statically determinable. Thus in the above code, where l,n are constants, XST synthesises, reporting ...

以 Spartan-3 为目标:

Targetting Spartan-3 we get:

INFO:Xst:1749 - "count.vhd" line 15: note: n: 8
INFO:Xst:1749 - "count.vhd" line 16: note: r: 0

所以使用旧的解析器，在综合中使用 Math.Real 并没有得到很好的支持.具体来说，real'image 返回 0！

so using the old parser, using Math.Real in synthesis was not well supported. Specifically, real'image returned 0!

针对 Spartan-6，

Targetting Spartan-6,

Elaborating entity <count> (architecture <Behavioral>) from library <work>.
Note: "n: 8"
Note: "r: 8.0"
Note: "Border a: 8.0"
Note: "Border b: 8.0"
Note: "Border a/b: 1.0"
Note: "Ceil a/b: 2.0"
Note: "Residual a/b: 2.22044604925031E-16"

所以我们重现了错误".但至关重要的是，如果我从表达式中减去 1.0 而不是取其上限，我们可以看到残差(通过四舍五入引入).我们可以看到，虽然它很小，但它是积极的.

so we have reproduced the "error". But crucially, if I subtract 1.0 from the expression instead of taking its ceiling, we can see the residual (introduced through rounding). And we can see that, though it is tiny, it is positive.

因此，Ceil() 在返回 2.0 时表现正确，这绝对不是综合工具错误.

Therefore Ceil() is behaving correctly in returning 2.0 and this is definitively NOT a synthesis tool bug.

在模拟中尝试相同的方法，您可能会发现一个同样小但为负的数字，因此它也是正确的...

Try the same in simulation and you will probably find a similarly small but negative number, therefore it is also correct...

参见 this 和 Professor Kahan 关于浮点 - 这不是工具问题，甚至不是 VHDL 问题，而是一个更大的蠕虫罐...

See this and other papers by Professor Kahan about floating point - this isn't a tool problem or even a VHDL problem but a much much bigger can of worms...

所以最后一句话是:如果你能在整数运算中找到任何完成相同任务的方法，那将是一个更好的解决方案.

So the final word is : if you can find any way of accomplishing the same task in integer arithmetic, it will be a better solution.

这篇关于VHDL XST 没有正确合成的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！