2011-05-15 1 views
4

私はverilogモジュールにalwaysブロックを書く方法について簡単な質問があります。
私はVerilogモジュールで、以下の入力がある場合:Verilog常に(*)記号を使用してブロックする

input  [31:0] PCplus4 ;  // Value of PC + 4 
input  [31:0] A;   // Value A, i.e. RSbus (Use Forwarded Value) 
input  [31:0] B;   // Value B, i.e. RTbus (Use Forwarded Value) 
input  [31:0] IMM;   // Extended Immediate Value 
input  [25:0] TARGET;   // Target Address for Jumps 
input   [3:0] BR;   // Branch Selector Input 

を私は

always @ (*) 

代わりの

always @ (PCplus4 or A or B or IMM or TARGET or BR) 

常に(*)@これを行うを使用している場合は任意の違いがありますVerilogのすべてのバージョンで有効な構文ですか?

+1

SystemVerilogは、ツールチェーンがデザイナーの意図に対して何らかの追加チェックを行うことを可能にする 'always_comb'(と' always_ff'/'always_latch')を導入したことに言及する価値があります。 – Chiggs

答えて

10

always @(*)構文が2001年にIEEE Verilog Stdに追加されました。最新のVerilogツール(シミュレータ、合成など)はすべてこの構文をサポートしています。ここ

はLRM(1800から2009)からの引用である:

イベント制御の不完全event_expressionリストは、レジスタ転送レベル(RTL)シミュレーション におけるバグの共通のソースです。暗黙の event_expressionは、@ *、 event_expressionにprocedural_timing_ control_statementの(声明 基であってもよい) 文で読まれているすべてのネットや 変数を追加することにより、これらの の問題を解消する便利 速記です。

したがって、2行のコードは同等です(alwaysブロックの本体のコードによって異なります)。しかし、@*構文は維持しやすくなります。

3

always @(*)は、2001年版の標準に追加されました。これは、最新のすべての品質ツールでサポートされています。私は任意の再利用を意図したコードでコンストラクトを使用することについて懸念していませんが、特に社内のユーティリティが含まれている場合はalways @(*)をサポートしない古いツールに遭遇する可能性があります。

0

これは、alwaysブロックが依存するすべてのワイヤをリストするためのショートカットです。これらのワイヤは「感度リスト」です。これを使用するメリットの1つは、ワイヤが物理的に接続されているため、合成されたコードが感度リスト(posedgeとnegedge以外)に入れたものを気にすることはないということです。シミュレータは、ブロックを実行させるイベントを選択するためにリストに依存することがあります。ブロックを変更してリストを更新することを忘れた場合、シミュレーションは実際の合成された動作とは異なる可能性があります。

0

どちらも同等ですが、[email protected](*)を使用すると、シミュレーション合成の不一致が回避されます。 は、あなたが以下のように感度のリストで15個の信号を持っていると仮定しましょう:

[email protected](a1 or a2 or ... or a15) 

今、設計者が誤ってこのリスト内のA14を持つ逃していることを前提としています。合成ツールはこの事実を無視し、このブロック内のRHS上のすべての信号が機密性リストにあると仮定してコードを合成します。シミュレーションツールは感度リストに依存するため、動作が異なります。

0

第1質問は....私はそれが第2のシナリオでは、あなたが出力にトリガリングを引き起こす可能性があると感じる唯一の入力であるかどうかによって異なりますと言います。理想的には、「入力の変更に対して」を示すように*を使用する方が良いでしょう。また、冗長なコードを避けるのにも役立ちます。

2番目の質問では、それはverilog -2001で導入されて以来、広範囲に使用されています。