合成中にラッチを回避する方法


9

VHDLを使用して組み合わせロジックのブロックを設計したいのですが、合成結果に意図しないラッチが含まれることがあります。

シンセサイザがラッチを推論しないようにするには、どのコーディングガイドラインに従う必要がありますか?

例:コードの小さなセグメントで、if-elseステートメントを使用する必要がありますか?


私が尋ねようとするものが得られたら、私に知らせてください

あなたの例からあなたが何を意味するのか分かりませんでした。言い換えが元の意図と一致していることを確認してください。
W5VO 2011

@fatai、私はすでにコメントしました、meta.stackexchange.comで利用可能なあなたのアカウントを削除する特定の方法があります。フラグが立てられた最後の質問にリンクしました。現場のモデレーターには、この力はありません。これには、開発チームに連絡する必要があります。
Kortuk、2012年

回答:


13

ラッチを回避するには、すべての出力がコードの可能なすべての分岐に割り当てられていることを確認する必要があります。

例えば、

if a = '1' then
   b(0) <= '1';
else
   b(1 downto 0) <= "00";
end if;

最初の条件ではb(1)の値が指定されていないため、ラッチが生成され、コンパイラーはb(1)の以前の値をそこに保持することを決定しました。これを作成してラッチを生成しない方法の1つは、次のとおりです。

if a = '1' then
   b <= prev_b;
   b(0) <= '1';
else
   b(1 downto 0) <= "00";
end if;

...

if rising_edge (clk)
    prev_b <= b;
end if;

ここでは、bが古い値を保持する必要があることを明示的に述べ、b(0)を新しい値で上書きします。

もう1つの方法は、@ TomiJの回答のように、デフォルト値を指定することです。

あなたがラッチを取得しているコードを投稿する場合、私たちはあなたが特定の理由を見つけるのを助けることができます。


b <= bそれでも信号の状態を保持する必要があるため、のアプローチではラッチを回避できないと思います。
Tomi Junnila、2011

君の言う通りかもね; クロックロジックに慣れすぎています。編集します。
fbo 2011

6

組み合わせロジックにプロセスを使用している場合(そしてこの理由のために私はそれをお勧めしません)、プロセスを通るすべてのパスが、プロセスが駆動するすべての信号に何かを割り当てることを確認してください。プロセスが実行された「前回」の出力に依存する可能性のある出力はありません。

そうしないと、次にプロセスがスケジュールされたときに、前回新しい値を取得しなかった信号の値を保持する必要があるため、ラッチを推測します。

純粋な組み合わせロジックを継続的な割り当てとして保持し、クロックロジックのプロセスを使用したいのですが、ラッチが取得されません。


5

ラッチを回避するための4つのルール:

  • 書き込む信号から読み取らないでください。
  • 正しい感度リストを持っている(読み取るすべての信号が感度リストにある必要があります)
  • 書き込み先のすべての信号がすべてのパスに割り当てられていることを確認してください。(例:if-else-statementの各ブランチで)
  • 変数を使用するプロセスでは、すべての変数が(別の変数またはシグナルで)読み取る前に、デフォルト値で初期化されていることを確認してください。

さらに、複数の組み合わせプロセスがある場合は、ループを作成しないようにしてください。

@TomiJの回答のスタイルなど、いくつかのコーディングスタイルがこれらのルールを守るのに役立ちます。@Martin Thompsonが指摘しているように、組み合わせロジックをすべて一緒に回避することをお勧めします。代わりに、すべてをクロックプロセスに入れます。


+1素晴らしいルールのセット。ルール2(感度リストについて)は、合成とシミュレーションの間で一貫した結果を保証するために実際に重要ですが、ラッチの推論について実際には違いはないことに同意しますか?
リック

@rick AFAIK、不完全な機密リストで合成ツールが何をするかについての保証はありませ。IEEE規格のVHDL合成(1076.6-1999)には、「プロセス感度リストには、プロセスステートメント内で読み取られたすべての信号が含まれます。感度リストが不完全なプロセスはサポートされません。とはいえ、特定の合成ツール(おそらくすべて?)不完全な感度リストを受け入れますが、感度リストをすべて一緒に無視するだけです。厳密なIEEE標準の代わりにその動作に依存する場合は、ステートメントが正しいと思います。
フィリップ

おかげで、それは正しいように聞こえます、それは私のモデルがその標準に準拠しなくなるでしょう。これまでに見たすべての合成ツールは感度リストを無視しているので、好奇心をそそられました。しかし、ラッチを推測できるという噂を聞いたことがあります。
リック、

3

@fboと@Martin Thompsonによって指摘されているように、プロセスによって駆動されるすべての信号にプロセスのすべてのブランチで何らかの値が割り当てられていることを確認する必要があり、その値は出力の以前の状態に依存していてはなりませんプロセスの。

これを確実にする最も簡単な方法は、たとえば、プロセスの最初に各出力にいくつかのデフォルト値を割り当てることです(たとえば、fboの例をco-opting)。

COMBO: process(a)
begin
    b <= (others => '0'); -- Assign default value to b
    if a = '1' then
        b(0) <= '1';
    else
        b(1 downto 0) <= "00";
    end if;
end process COMBO;

1
これは私がよく使う方法です。ただし、場合によっては、ラッチ警告がビットの割り当てを忘れたことを示すことがありますが、この方法ではバグを見つけにくくなる場合があります。たとえば、ワイド信号のすべてのビットを個別に割り当てていて、誤って数え直した場合などです。
fbo 2011

2
組み合わせプロセスでのみ。クロックプロセスでは、フリップフロップを推論します。
Martin Thompson
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.