2

ghdlDebianでコンパイルできる VHDL ファイルがいくつかあります。同じファイルが、ASIC 実装用に一部変更されています。アルゴリズムには、1 つの「大面積」実装と 1 つの「コンパクト」実装があります。もう少し実装を書きたいと思いますが、それらを評価するには、さまざまな実装がどれだけの領域を占有するかを比較できる必要があります。

独自のコンパイラをインストールしたり、ハードウェアを入手したりせずに、評価を行いたいと考えています。十分な評価基準は、GE (ゲート等価) 面積の見積もり、または一部の FPGA 実装に必要なロジック スライスの数です。

4

2 に答える 2

7

フリップフロップ (FF) を数えることから始めます。それらの数は、作成した RTL コードによって (ほぼ) 一意に定義されます。ある程度の経験があれば、コードを調べてこの番号を取得できます。

通常、#FF と全体の面積の間には良好な相関関係があります。古い経験則では、多くの設計では、組み合わせ領域はシーケンシャル領域とほぼ同じになります。たとえば、フリップフロップの面積カウントがゲート アレイ テクノロジで 10 ゲートであると仮定すると#FFs * 20、最初の見積もりが得られます。

もちろん、デザインの特性は大きな影響を与えます。データパス指向の設計の場合、組み合わせ領域は比較的大きくなります。コントロール指向の設計の場合、その逆が当てはまります。スタンダード セル デザインの場合、FF の方が効率的であるため、シーケンシャル エリアが小さくなる場合があります。タイミングが重要なデザインの場合、合成ツールによるタイミング最適化の結果として、組み合わせ領域が大幅に大きくなる場合があります。

したがって、残りの問題は、設計の種類とターゲット テクノロジに適した増倍率を見つけることです。戦略は、いくつかの実験を実行するか、以前の設計結果を調べるか、または他の人に尋ねることです。それ以降、見積もりは、コードから既知の #FF にその係数を掛けることの問題です。

于 2011-05-30T20:41:17.553 に答える
3

独自のコンパイラをインストールしたり、ハードウェアを入手したりせずに、評価を行いたいと考えています。

検査により大まかなアイデアが得られますが、合成中に発生するすべての最適化により、このレベルの精度が最終結果からかけ離れていることに気付く場合があります。

評価を実行するために「独自のコンパイラ」を避ける理由を再検討することをお勧めします。私は、VHDL 用の非独占的な合成ツールを知りません (議論されていますが)。一般的な FPGA ベンダーは、リソース使用量の正確なカウントを取得するために使用できる Windows および Linux 用のソフトウェアの無料バ​​ージョンを提供しています。FPGA リソースの使用量を、ターゲット テクノロジにとってより意味のあるものに変換することは実行可能です。

私は ASIC の世界にあまり詳しくありませんが、無料の (ただしプロプライエタリな) ツールを使用できる場合があります。

于 2011-05-31T13:52:44.600 に答える