次のコードがラッチを推測しないのはなぜですか？次のロジックでラッチが推論されないのはなぜですか？
dとrstが両方とも "0"の場合、ツールは "e"に割り当てられるものをどのように知っていますか？
module tmp(input d,
input clk,
input rst,
output reg o,
output reg e);
[email protected](posedge clk)
if(rst) begin
o <=0;
e <= 1;
end
else if(d) begin
o<=1;
e<=0;
end
else
o <=1;
endmodule
あなたは常にブロックモデル順序論理（内のフリップフロップを持つすなわちロジック）。 dとrstが両方とも1'b0の場合、に割り当てられたコード行は実行されません。その結果、eはその前の値を保持する（すなわち記憶する）。しかし、それはOKです。eはD型フリップフロップとして合成されるためです。フリップフロップには状態があり、格納されています。ラッチは必要ありません。
だから、常に@（posedge **）がFFを推論するツールになったのですか？また、フロップの前の優先順位ロジックのために、 "e"は状態を変更していません。したがって、全体的に「ラッチ」を避けていますか？ ただし、常に@（**）;もし私が同じ論理を書いていたら;以前の状態（デフォルト）を格納するためのFF/Memory要素がないため、ラッチを推測することになります。 ありがとうございました。 – user2624915
はい、常に@（posedge **）はツールがFFを推論するようにします。 （クロックエッジで出力が変化する他のロジックコンポーネントは何ですか？） –
if/elseが優先順位ロジックです。 rst = 0、d = 1の場合、eに0が代入されます。rst = 0かつd = 0の場合、eは最後の値を保持します。これはラッチではなくフリップフロップを表します。 – toolic
'e'は最後の値を保持します。レベルセンシティブではなく、エッジセンシティブなデザインなので、ラッチではなくFFが推論されます。 –