コーディング・スタイル・チェックとは，Verilog HDLやVHDLで記述されたRTL（register transfer level）設計記述の文法エラーと，文法エラーにならない問題点をチェックすることを言う。コーディング・スタイル・チェックを実行するEDAツールを「コーディング・スタイル・チェッカ」と呼ぶ。
設計記述の可読性を上げる
コーディング・スタイル・チェッカを用いることで，設計の早い段階で回路の不具合が発見できるため，設計期間の短縮が可能となる。また，命名規則や記述形式をチェックして統一化することで，設計記述（設計データ）の可読性が向上する。
これでRTL設計データのレビューが容易になり，かつそのデータの再利用性が高くなる。なお最近のコーディング・スタイル・チェッカは，単純な記述のスタイルをチェックするだけではなく，後段の設計工程である，論理合成や自動レイアウトで問題を引き起こしそうな個所を指摘する。
設計記述の可読性を上げる
コーディング・スタイル・チェッカでチェックする内容は，主に以下のように分類できる。
（1）可読性向上のために守るべき，記述作法のチェック
（2）バグが発生しやすい不確定な記述のチェック
（3）生成される回路の面積や動作速度の面で，問題が発生しそうな記述のチェック
（4）LSI製造上で，問題になりそうな記述のチェック
以下で，それぞれのチェックの内容に関して説明をする。最初に（1）の「可読性向上のために守るべき，記述作法のチェック」である。
このチェックでは対象となっているRTL設計データが，推奨される記述スタイルになっているかどうかをみる。例えば図1の左側のVerilog HDLでの記述例では，「begin」や「end」の記述がなく，「else」がどの「begin」に対応しているか理解しにくい。
【図1 可読性の向上の例】出典はエッチ・ディー・ラボ。 （画像のクリックで拡大）
図1の右側のような記述スタイルが推奨される。コーディング・スタイル・チェッカはこのような可読性の問題点や命名規則などをチェックする。命名規則に関して，ツールのユーザーが独自の規則を定義することが可能になっている。
バグが発生しやすい記述を探る
次に（2）の「バグが発生しやすい不確定な記述のチェック」について説明する。ここでは，予期せぬ不定値が発生しそうだったり，予期せぬ不具合が発生しそうなRTL記述をチェックする。
例えば図2（a）の例では，「Bin」は4ビット幅なので，0～15の値を取る。一方，配列は[8：0]なので，9以上の値を取る時，不定値を出力する。
【図2 不確定な記述の例】出典はエッチ・ディー・ラボ。 （画像のクリックで拡大）
図2（b）の例では，case文で“2'b00”か“2'b01”以外の場合は，「Dout」に不定値を代入している。このDoutをif文で判別する場合，不定値ならelse項が実行されて，不定値が固定値に置き換わってしまう。このような記述は，設計不具合を発生させる危険の極めて高い記述と言える。
面積や速度で問題のありそうな記述
次に，（3）の「生成される回路の面積や動作速度の面で，問題が発生しそうな記述のチェック」について説明する。ここでは，if文のネストの段数やcase文の項目数などを見て，対象のRTLデータから作られるチップが，性能面の問題を引き起こすことにつながる記述をチェックする。
また，ビット幅の不一致などをチェックし，バグの可能性と冗長記述の可能性をみる。ビット幅の問題では，図3のように，if文の条件項で算術演算すると，32ビットの演算器が生成されることが知られている。
【図3 冗長な回路が発生の恐れがある記述の例】出典はエッチ・ディー・ラボ。 （画像のクリックで拡大）
製造上で問題になりそうなRTL
次に，（4）の「LSI製造上で，問題になりそうな記述のチェック」について説明する。具体的には，リセット・ラインや，クロック・ラインに論理素子が存在するかをチェックしたり，異なるクロック・ドメイン間での信号の伝播をチェックする。コーディング・スタイル・チェッカは，論理合成してゲート・レベル回路を出力するツールではないが，回路構造的な内容も一部チェックしている。
スタイルをまとめて解説
以上説明したような，RTL記述のコーディング・スタイルをまとめた資料がある。半導体理工学研究センター（SATRC）が発行している『RTL設計スタイルガイド』1）などである。コーディング・スタイル・チェッカが，同書に記載のRTL記述に関する項目をチェックするルールを備えていると，使いやすいだろう。
コーディング・スタイル・チェッカは，通常，独自のチェック項目を数百以上備えている。この中には，相反する項目や，類似する項目も多数ある。すべてのコーディング・ルールをチェックすると，必要以上のエラーが出力されてしまう。このため，コーディング・ルールをあらかじめ選んでから，コーディング・スタイル・チェッカを使った方が良い。
擬似エラーに注意
コーディング・スタイル・チェッカが出す擬似エラーには注意が要る。擬似エラーとは，実際には問題にはならないが，チェッカがエラーと判定してしまう項目を言う。
例えば，図2（a）の配列オーバーの問題は，Binが0-8の数値以外を取らないように記述されていれば，実際には問題とはならない。コーディング・スタイル・チェッカは，論理式を解析しないので，その場合でもエラーとみなしてしまうことが多い。これが擬似エラーの例である。
また，図4のビット幅についても，8ビットと8ビットを加算するため，キャリー・オーバーを考慮して本来は9ビットに代入すべきである。しかし仕様的に8ビットでよい場合も多い。こちらもコーディング・スタイル・チェッカは，擬似エラーを出力する可能性が高い。コーディング・スタイル・チェッカの出力結果は吟味する必要がある。
【図4 擬似エラーの発生の恐れがある記述の例】出典はエッチ・ディー・ラボ。 （画像のクリックで拡大）
参考文献
1）半導体理工学研究センター，『RTL設計スタイルガイド』，2005年.
2）長谷川裕恭.，「HDLの記述スタイル」，『Design Wave Magazine』，2001年2月-2002年11月.
3）長谷川裕恭，「RTLとゲート・レベル検証の不一致問題対策」，『Design Wave Magazine』，1997年11月
