1

alwaysブロック内のイベント制御ステートメントの動作について疑問に思う：

always @(posedge clk) begin: TEST
    ...
    @(wait_for_signal_from_subsystem);
    ... 
    @(wait_for_another_signal_from_subsystem);
    ...
end

イベント信号が着信するまでプロセスは「スタック」しますか、それともclkエッジが着信するたびに再開しますか？

また、これは合成可能ですか（Quartus IIは「はい」と言っていますが、まだシミュレートされていません...）？これは良い習慣ですか、それともこの問題に対する別のより良いアプローチがありますか？

4

2 に答える 2

1

はい、あなたが言うようにそれは「行き詰まっています」。ブロックの1つの「ループ」のみを一度にアクティブにすることができます。ループが完了していない場合、ブロックは再入しません。

ブロック内の待機操作のため、そこで実行しようとしていることは合成できない可能性があります。

あなたのデザインの正確な詳細はわかりませんが、小さな有限状態マシンでこれにアプローチします。サブシステムからの信号はクロックより速くないと思いますので、次のようになります。

always @* begin
  if(state_f == `WAIT_FOR_FIRST) 
       state_nxt = got_first_signal ? `WAIT_FOR_SECOND : `WAIT_FOR_FIRST;
  else if(state_f == `WAIT_FOR_SECOND)
       state_nxt = got_second_signal ? `DONE_STATE : `WAIT_FOR_SECOND;
  else if(state_f == `DONE_STATE) 
       state_nxt = `WAIT_FOR_FIRST;
  else
       state_nxt = 2'bxx;
end

always @(posedge clk) begin
    state_f <= state_nxt;
end
于 2013-03-26T03:26:11.420 に答える
1

合成されていないテストベンチコードではなくハードウェアを設計していると仮定すると、これは良い習慣ではなく、とにかくあなたが望むことをしないでしょう。

言語の観点から、これはコンパイルおよびシミュレーションされます。それはalwaysブロック内のイベントの待機をブロックし、時計の各ポーズで再開しません。これに関するスペックリファレンスは見つかりませんでしたが、シミュレーションで観察したものです。エラーなしで合成できるとしたら、これが何に合成されるのか興味があります。

他のサブシステムからの信号がすでに同じクロックドメイン（に同期clk）にある場合は、各クロックエッジでその状態を確認し、これを使用して何かを行うことができます。

always @(posedge clk) begin: TEST
  if (the_other_signal == 1'b1) begin
    ...
  end
end

考慮すべき他のいくつかの事柄：

  • たぶん、あなたは信号がいつアサート/デアサートするかだけを気にします。その場合、エッジ検出を行う必要があります。
  • 信号がと非同期であるclk場合は、クロックドメインが交差しているため、入力信号を確認する前に同期する必要があります。
于 2013-03-26T03:26:59.720 に答える