なぜこのVerilogは30のマクロセルと何百もの製品用語を使用しているのですか？

ザイリンクスCoolrunner IIの34個のマクロセルを消費するプロジェクトがあります。私はエラーに気づき、これを追跡しました：

assign rlever = RL[0] ? 3'b000 :
                RL[1] ? 3'b001 :
                RL[2] ? 3'b010 :
                RL[3] ? 3'b011 :
                RL[4] ? 3'b100 :
                RL[5] ? 3'b101 :
                RL[6] ? 3'b110 :
                        3'b111;

assign llever = LL[0] ? 3'b000 :
                LL[1] ? 3'b001 :
                LL[2] ? 3'b010 :
                LL[3] ? 3'b011 :
                LL[4] ? 3'b100 :
                LL[5] ? 3'b101 :
                        3'b110 ;

エラーがあることですrleverし、llever1ビット幅であり、私は彼らが広い3ビットである必要があります。愚かな私。私はコードを次のように変更しました：

wire [2:0] rlever ...
wire [2:0] llever ...

十分なビットがありました。しかし、プロジェクトを再構築したとき、この変更により30を超えるマクロセルと数百の製品条件が発生しました。誰かが私が間違ったことを説明できますか？

（良いニュースは、正しくシミュレーションできるようになったことです... :-P）

編集-

VerilogとCPLDを理解し始めると思う頃に、私が明らかに理解していないことを示す何かが起こったので、私は欲求不満だと思います。

assign outp[0] = inp[0] | inp[2] | inp[4] | inp[6];
assign outp[1] = inp[1] | inp[2] | inp[5] | inp[6];
assign outp[2] = inp[3] | inp[4] | inp[5] | inp[6];

これらの3行を実装するロジックは2回発生します。つまり、Verilogの6行のそれぞれが約6つのマクロセルと32の積項をそれぞれ消費します。

編集2-最適化スイッチに関する@ThePhotonの提案に従って、ISEによって生成された概要ページからの情報を以下に示します。

Synthesizing Unit <mux1>.
    Related source file is "mux1.v".
    Found 3-bit 1-of-9 priority encoder for signal <code>.
Unit <mux1> synthesized.
(snip!)
# Priority Encoders                                    : 2
 3-bit 1-of-9 priority encoder                         : 2

そのため、コードは何か特別なものとして認識されました。ただし、この設計は依然として膨大なリソースを消費しています。

編集3-

@thePhotonが推奨するマルチプレクサのみを含む新しい回路図を作成しました。合成により、リソースの使用量がわずかになりました。@Michael Karasが推奨するモジュールも合成しました。これも重要ではない使用法を生み出しました。したがって、ある程度の正気が広まっています。

明らかに、私のレバー値の使用は驚きを引き起こしています。もっと来る。

最終編集

デザインはもはや正気ではありません。しかし、何が起こったのかわかりません。新しいアルゴリズムを実装するために、多くの変更を加えました。1つの要因は、111個の15ビット要素の「ROM」でした。これは、マクロセルの控えめな数が、消費多くを製品の条件-xc2c64aで利用できるもののほぼすべて。私はこれを探しましたが、気づきませんでした。私のエラーは最適化によって隠されたと思います。私が話している「レバー」は、ROMから値を選択するために使用されます。（バストされた）1ビットプライオリティエンコーダーを実装したときに、ISEがROMの一部を最適化して削除したと仮定します。それはかなりトリックですが、それが私が考えることができる唯一の説明です。この最適化により、リソースの使用量が大幅に削減され、特定のベースラインを期待するようになりました。（このスレッドのように）優先度エンコーダーを修正したとき、以前に最適化されていた優先度エンコーダーとROMのオーバーヘッドを確認し、これを前者に独占的に割り当てました。

結局、私はマクロセルが得意でしたが、製品条件を使い果たしていました。ROMの半分は豪華なものでした。前半の2のコンプに過ぎなかったからです。負の値を削除し、他の場所で単純な計算に置き換えました。これにより、マクロセルを製品条件と交換することができました。

今のところ、これはxc2c64aに適合します。マクロセルと製品用語のそれぞれ81％と84％を使用しました。もちろん、今私はそれをテストして、私が望んでいることを確実にする必要があります...

支援してくれたThePhotonとMichael Karasに感謝します。彼らがこれを解決するのを助けるために彼らが貸した道徳的なサポートに加えて、ザフォトンがThePhotonが投稿したドキュメントから学び、マイケルによる提案の優先エンコーダーを実装しました。

表示するコードは基本的にプライオリティエンコーダーです。つまり、多くの信号の入力があり、その出力はそれらの信号のどれが設定されているかを示し、複数の信号が設定されている場合は、左端の設定信号を優先します。

ただし、この回路の標準動作の定義が、確認した2つの場所で矛盾しています。

Wikipediaによると、標準優先順位エンコーダーは入力を1から番号付けします。つまり、最下位入力ビットが設定されている場合、0ではなく1を出力します。Wikipedia優先順位エンコーダーは、入力ビットが設定されていない場合、0を出力します。

ただし、ザイリンクスのXSTユーザーガイド（p。80）では、コーディングしたものに近い優先エンコーダーを定義しています。入力には0から番号が付けられるため、入力のlsbが設定されると、0の出力が得られます。ただし、すべての入力ビットがクリアされている場合、ザイリンクスの定義には出力の仕様がありません（コードは3'd7を出力します）。

もちろん、ザイリンクスユーザーガイドは、ザイリンクス合成ソフトウェアが期待するものを決定します。重要な点は、(*priority_extract ="force"*)XSTがこの構造を認識して最適な合成結果を生成するには特別なディレクティブが必要であることです。

以下は、8対3の優先度エンコーダ用のザイリンクスの推奨フォームです。

(* priority_extract="force" *)
module v_priority_encoder_1 (sel, code);
input [7:0] sel;
output [2:0] code;
reg [2:0] code;
always @(sel)
begin
    if (sel[0]) code = 3’b000;
    else if (sel[1]) code = 3’b001;
    else if (sel[2]) code = 3’b010;
    else if (sel[3]) code = 3’b011;
    else if (sel[4]) code = 3’b100;
    else if (sel[5]) code = 3’b101;
    else if (sel[6]) code = 3’b110;
    else if (sel[7]) code = 3’b111;
    else code = 3’bxxx;
end
endmodule

ザイリンクスが推奨するコーディングスタイルを使用できるように周囲のロジックを再配置できる場合、それはおそらくより良い結果を得る最良の方法です。

これは、ザイリンクスエンコーダモジュールを

v_priority_encoder_1 pe_inst (.sel({~|{RL[6:0]}, RL[6:0]}), .code(rlever));

RL[6:0]すべてのRLビットがローのときに3'b111出力をトリガーする8番目の入力ビットを取得するために、すべてのビットをまとめることはしませんでした。

lleverロジックについては、ザイリンクステンプレートに従って変更されたエンコーダーモジュールを作成することで、リソース使用量を減らすことができますが、必要なのは7入力ビットのみです（6ビットにLL加えて、他の6ビットがすべてローのときにハイになる追加ビット）。

このテンプレートの使用は、XST合成エンジンを使用しているISEのバージョンを想定しています。ISEのメジャーリビジョンごとに合成ツールが変更されるようです。リンクしたドキュメントが実際にISEのバージョンに対応していることを確認してください。そうでない場合は、ドキュメントで推奨されているスタイルをチェックして、ツールが期待するものを確認してください。

ThePhotonの答えは素晴らしいものです。検討のために、ここにいくつかの追加情報を追加したいと思います。これは、HDLとsysthesisツールを使用した最先端の豪華なFPGAおよびCPLDデバイスがあるにもかかわらず、何年も前に設計されたものを詳しく調べると有益な場合があるという事実に由来します。最後に私の推奨するところまでこれを歩いている間、私と一緒にいてください。

優先エンコード機能を実行するディスクリートロジックパーツがあります。これらの部品によって実装されるロジックは、トランジスタの数を最小限に減らすことが不可欠であった長い間存在していました。74HC148やMC14532Bなどの一般的なパーツ番号のロジックパーツをWebで検索して、これらのパーツの同等のロジックダイアグラムを含むデータシートを見つけることができます。以下の図は、74HC148パーツのTIデータシートから取った1つの例です。

このロジックは、次の真理値表を実装します（同じデータシートから取得）。

上記のパーツファミリは、アクティブでない入力信号を使用することに注意してください。ON Semiconductor MC14532Bパーツの別のデータシートには、Verilogの例と同様のアクティブな高入力信号を使用したエンコーダー機能の真理値表が示されています。

同じデータシートに、MC14532Bの論理式が次のように示されています。

現在の例と比較するために、同様の方程式を直接Verilogコードにコーディングすることを検討してください。より好ましい結果が得られる可能性が高いです。