私は基本的なCPUコントロールユニット用のVHDLでFSMを書いています。あるプロセスでは、命令コードを解読するためにcase文を使用します。私の質問は、 "..." =>ステートメントが何かを変えるか、何かを変えるか、あるいは推測される "回路"が同じであるかの順序ですか？私はそれが間違いないと思うが、私は確信したい。VHDLケースステートメントのオプションの順番
私はむしろ、値の順序ではなく、方向付けが容易な順番でケースを持っています。
when "..." =>文の順序はおそらく問題/理由はVHDLでシミュレーションや合成に何かを変更することはできません彼らは、 は、を相互に排他的にする必要があります。
この注文には何の効果もありません。
case State is
when A => ...
when B => ...
end case;
私はいくつかの合成ツールが順番に基づいて、異なる状態エンコーディングを作り出すことができるが、これはあなたが心配する必要があります何かすべきではないと仮定
case State is
when B => ...
when A => ...
end case;
と同じです。
合成ツールはケースステートメントのすべてのブランチを収集し、1つの大きなマルチプレクサに入れるため、注文に違いはありません。マルチプレクサはあなたの異なる分岐条件（明らかにあなたの入力）で評価します。
when others =>文を忘れてはいけない;「case文」について）
この短く正確な答えに加えて：これは、優先度を作成する 'if-elsif -...-elseif-else'チェーンと大きな違いです。 – Paebbels
私は、一致するcase文を使用してプライオリティエンコーダを作成することは可能です。 IEEE Std 1076-2008 10.9ケースステートメントを参照。パラグラフ6から始まり、定義済みの演算子「？=」（パラグラフ10）に依存する。 9.2.3の「？=」右オペランド表を参照してください。 （誰かの合成ツールがそれを受け入れるかどうかは別の質問です）。 case文は、then elsif ...に変わる可能性があります。単純に選択肢に関する規則が追加されています（if文条件）。サルのレンチを '短く正確に'投げてしまって申し訳ありませんが、case文の前に '普通'という言葉を付け加えてください。 – user1155120
@ user1155120私はそこで何かを学んだことを認めなければなりません - 私は '事件 'について知りませんでした。ありがとうございました。しかし、私が知ることから、ブランチは依然として相互に排他的でなければなりません。 IEEE Std 1076-2008では、「注1：ケースステートメントの実行は、選択肢が網羅的であり、 が排他的であるため、唯一の選択肢を選択する」と述べています。 –