XST はかなり信頼できます。
私が XST で見た唯一の本物の間違ったハードウェア バグは、プロセス内のプロシージャに OUT パラメータとして渡されたシグナルに関するものです... シグナルは、変数代入 (即時代入) セマンティクスを使用して代入されました!
ISE14 では、Spartan-3 以前のデバイスをターゲットにしている場合はこのバグが残っていますが、Spartan-6 以降のデバイスをターゲットにしている場合はありません。XST には 2 つの異なる VHDL パーサーがあり、新しい方が優れているようです。
そのため、他のパーサーを使用して (ターゲット ファミリを変更するか、「use_new_parser」設定またはコマンド ライン オプションを使用して) 再試行できます。詳細については、ザイリンクスのドキュメントを参照してください。
また、合成後のネットリストをテストベンチに接続して、シミュレーションでエラーを再現 (または再現しない) することもできます。(IMO では、合成後および PAR 後のシミュレーションの唯一の実用的な用途は、ツールのバグの可能性を確認または排除することです!)
そして、フィリップが言うように、小さなデモンストレーターを手に入れるか、本当の問題が何であるかを見つけるまで、デザインを分割して征服してください!
編集 :
いくつかのポイントを示すために追加されました...
l,n の正しい整数値が与えられると、この問題をより詳細に特徴付けることができます... 上記の主張から、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年以降)
2) 一般的な神話に反して、条件が静的に決定可能であれば、asserts は合成可能です。したがって、上記のコードでは、l,n は定数、XST 合成、レポート ...
Spartan-3 をターゲットにすると、次のようになります。
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 を返しました!
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 を減算すると、残差 (丸めによって導入された) を確認できることです。そして、小さいながらもポジティブであることがわかります。
したがって、Ceil() は 2.0 を返す際に正しく動作しており、これは合成ツールのバグではありません。
シミュレーションで同じことを試すと、おそらく同様に小さいが負の数が見つかるため、それも正しいです...
浮動小数点に関するKahan 教授によるこの論文およびその他の論文を参照してください。これはツールの問題でも VHDL の問題でもありませんが、はるかに大きなワームの缶詰です...
したがって、最後の言葉は次のとおりです。整数演算で同じタスクを達成する方法を見つけることができれば、それがより良い解決策になります。