FSMのエンコーディング・スタイルは、タイミング、面積、消費電力などに非常に大きな影響を与える。一般的なエンコーディング・スタイルには、ワンホット・エンコーディング、グレイ・エンコーディング、最小エンコーディングなどがある。ワンホット・エンコーディングとは、FSMのあらゆる状態において、状態レジスタが1ビットだけ“ 1 ”となるような設計である。このエンコーディング・スタイルでは、最終的な設計のレジスタ数が多くなることがある。ワンホット・エンコーディングでは、組み合わせ回路の複雑さが、他のエンコーディング・スタイルと同等もしくはやや上回るものの、各状態レジスタへの入力を制御する組み合わせ回路が小さくなるため、タイミング的に有利な設計ができるという利点がある。ワンホット・エンコーディングを選択する設計者は、この利点を重視していることが多い。
グレイ・エンコーディングは特殊なエンコーディング・スタイルである。FSM内のあらゆる遷移において、遷移元と遷移先の状態レジスタが1ビットだけ異なる。遷移の際に値が変わるレジスタが1個だけなので、低消費電力が求められる設計には最適のエンコーディングスタイルである。状態をエンコーディングするためのレジスタの数は少ないが、次の状態への組み合わせ回路の複雑さや、生成される出力を事前に把握できない。大規模で遷移の多いFSMでは、グレイ・エンコーディングによる最適な構成を見つけるのは難しい。
最小エンコーディングとは、状態レジスタの数が最小となるスタイルだが、論理回路が複雑になる恐れがある。しかし慎重にエンコーディングを割り当てれば、論理回路を小さくできる。このエンコーディング・スタイルでは、最適化のレベルによって動作タイミングや面積、消費電力などが大きく変動することがある。そして最適な構成を採用しない限り、満足な結果は得られないかもしれない。レジスタの数が重要視されるような設計での使用には適しているが、消費電力が問題になるような場合には使用してはいけない。
消費電力や面積、タイミング制約などを改善するために、最小エンコーディングによる設計に対してレジスタを追加するなどのカスタマイズを検討することがあるかもしれない。この場合、必ずしもワンホットまたはグレイ・エンコーディングを踏襲する必要はない。また、要求仕様の観点から妥当性が認められない限りこの方法も使用するべきではない。
Moore方式とMealey方式は、出力信号の観点から規定されたFSMのエンコーディング・スタイルである。Moore方式FSMの出力論理が状態レジスタのみの関数であるのに対し、Mealey方式FSMの出力論理は入力および状態レジスタの関数である。設計に用いるにはMoore方式の方が安全だろう。必要に迫られてMealey方式を採用する場合、設計者は出力論理および、そのFSMを使用する高位のモジュールを徹底的に検証しなければならない。また、非同期に動作するFSM出力によって発生するあらゆる障害について検証する必要がある。
FSMを考える際のもう1つの観点として、次の状態への遷移論理が挙げられる。単純なFSMにおいては、各状態はFSMのエンコーディングを表すマクロであり、次の状態のレジスタ値アサインは、これらマクロを直接用いて行なわれる。次の状態のレジスタ値アサインを、状態マクロを直接用いて行なう際には、次の状態の計算に含まれるロジックは、アサインおよび状態レジスタのエンコーディングより前に記述されている条件文から得られる。コードを簡潔にするために、次の状態の変数に対するアサインは簡単な記述にする必要がある。
しかし、複雑な論理演算による次の状態の演算が必要なために単純なアサインでは表現できないことがある。このような場合には、次の状態の計算を複数の関数やタスクで構成することによって、単純化やモジュール化が可能である。関数を使用してFSMの出力を計算することもできる。しかしこれらの方法はFSMが複雑になるため、FSMの分割や単純化による回避が不可能でない限り用いるべきではない。
FSMでは、算術演算子または論理演算子を使用して次の状態を計算することがある。最も一般的な算術演算の方法としては、現在の状態に対し定数値によるインクリメントを行い、次の状態を計算するものがある。この計算手法では、FSMの複雑さが隠されることがある。例えばcase文中のアイテム数が実際のFSMの状態数より少なくなる場合がある。それぞれの計算によってアイテムには存在しないような新しい状態が生じることがあるためだ。このような次の状態の演算がcase文のdefault文の中に記述される場合にはさらに複雑になる。
FSMは、1つ以上の初期状態を持つことができる。一般的なルールとして、FSMは初期状態を持っているべきであり、設計の際には初期化するためのリセット信号を組み込むべきである。初期状態を持たないFSMは機能的な問題が発生しやすく、また、分析、検証、および保守が困難な設計になってしまうことが多い。
FSMの構成が検証や実装に与える影響は非常に大きい。自動的に検証できるような設計を行なうことが重要であり、プロジェクトにおいては設計スタイルを体系的な管理によって統一する必要がある。検証ツールは、FSMの機能的な問題を自動的に検出できなければならない。さらに、このツールはコーディング・スタイルや構文だけでなく、デッドロックなどの、潜在的な問題もチェックすべきである。検証ツールによってバグや問題のある部分が検出されたら、統合デバッグ環境で根本的な原因を分析していく。このデバッグ環境では、明解なメッセージ出力、RTLコードへのバック・アノテーション機能、部分的な詳細表示も可能な概略図表示、FSMの状態遷移図ビューア機能、波形ビューア機能などが必要であり、これらは、FSMに関わるバグの分析およびデバッグがスムーズに進められるよう統合されていなければならない。実装上の問題は、解析が容易なチャート図や品質検査結果によって、簡潔に表示されるべきであるし、さらにこれらの表示は、FSMの調査結果だけでなく関連するRTLコードにもリンクされていることが求められる。設計者はこのリンクを通してRTLにアクセスし、修正を加える。
FSMは、設計上のバグや問題が発生する可能性が非常に高い。設計者は、メトリックの分析がFSMの最終的な実装および検証の容易さを左右するということを念頭に置いて慎重に行なわなくてはならない。設計者は、プロジェクトに応じて、その要件に合うように1つまたは複数のFSMスタイルを選択できる。プロジェクトの要件を満たすためには、各FSMをより簡単に検証できるようにするため、状態や遷移の数などに対して上限値を設定し、検証を簡単にすることも検討すべきである。
以上の要件によって、FSMを設計する上での方法論が定義される。人為的なエラーを防ぎ、設計および市場投入までの時間を短縮するためにも、これらの方法論はツールに自動的に適用される必要がある。FSMの各タイプの特徴、およびそれぞれが適した用途に関する理解を深めることで、より良いFSMを開発できる。再設計によるコスト増加を避けるためにも、設計ガイドラインに従ったFSMの設計や、その検証に関する検討は非常に重要である。
Copyright © ITmedia, Inc. All Rights Reserved.