検証カバレッジとは，検証の網羅性の尺度である。ハードウェア設計では，検証カバレッジは機能検証に対するカバレッジを指すことが多い。性能検証や電力検証においても，検証の網羅性の尺度が望まれているが，現時点では，有効な具体的提案は見られない。
検証の網羅性の尺度は，設計品質に対する保証を定量化したり，検証工程を管理したりする際に必要になる。ただし，どちらに対しても，完全な網羅性の尺度は原理的に存在しない。実用レベルの回路を完全に検証するためには，天文学的な時間を要し，「完全な尺度」を定義したとしても，通常許される範囲での検証では，端数以下の網羅性となるためである。
すべての検証カバレッジは，検証の必要条件を異なった視点から定義する。実用レベルの検証網羅性を確保するためには，いくつかの検証カバレッジを採用し，それぞれの数値を総合して十分かどうかを判断する必要がある。検証カバレッジの選択は，それまでに蓄積されてきた知見と，対象となる設計の特性とから定める。使う検証カバレッジの組み合わせの決定や，検証の十分性の判断は，検証あるいは設計全体のプロジェクト・マネージャに委ねられるのが一般的である。
2種類に分類
検証カバレッジは，その性質から次の二種類に分類できる。すなわち
（1）コード・カバレッジ：実装に対する検証網羅性の尺度
（2）機能カバレッジ：仕様に対する検証網羅性の尺度
である。なお，本稿では，あらかじめ定められた仕様に従ってハードウェア記述言語を用いてRTL（register transfer level）コードを記述する作業を「実装」と呼ぶことにする。この作業を「設計」と呼ぶこともあるが，設計はより広い意味を持つため，ここでは「実装」とした。以下では，（1）のコード・カバレッジと（2）の機能カバレッジの概要とトレードオフ，さらにフォーマル検証とカバレッジとの関係，カバレッジの標準化について，説明する。
HDLコードをどこまでカバーしたか
（1）のコード・カバレッジは，ハードウェア記述言語（HDL：hardware description language）で書かれたコードに対して，検証パターンがどこまでカバーしたかを表す指標である。コード・カバレッジの考え方は，1970年代からソフトウェア開発の分野で使われており，C0（命令網羅率），C1（分岐網羅率），C2（条件網羅率）といった呼び方が定着している。これに対応する形で，ハードウェア設計では下記のようなコード・カバレッジが用いられ，多くの論理シミュレータがサポートしている。
- （1.1）ライン・カバレッジ：ソース・コードの実効行（コメント以外の行）のうち，どれだけが実行されたかを表す指標。ステートメント・カバレッジとも呼ばれる。
- （1.2）ブロック・カバレッジ：行ごとではなく，コードの基本ブロックを一つの単位と考え，基本ブロックがどれだけ実行されたかを表す指標。
- （1.3）分岐カバレッジ：分岐条件に対し，真偽それぞれの場合を実行したかどうかを表す指標。
- （1.4）条件カバレッジ：複合的な分岐条件に対し，条件を構成する変数のすべての場合を実行したかどうかを表す指標。エクスプレション・カバレッジと呼ばれることもある。例えば，条件が「A&B」の場合，分岐カバレッジならば，「A&B」が真の場合と偽の場合を調べれば良いのに対し，条件カバレッジでは，AとBの可能な組み合わせ，すなわち，（A，B）=（0，0），（0，1），（1，0），（1，1）のすべてを実行する必要がある。
- （1.5）パス・カバレッジ：複数の条件分岐がある際に，それぞれの分岐の組み合わせを実行したかどうかを表す指標。例えば，二つの分岐が連続している場合，分岐条件が真真，真偽，偽真，偽偽の場合を実行したかどうかを見る。
- （1.6）トグル・カバレッジ：コードで使われている全信号，または注目している信号の各ビットが変化しているかどうかを表す指標。「0」→「1」，「1」→「0」を区別する場合としない場合がある。
- （1.7）FSMカバレッジ：RTL記述で現れる有限状態機械（FSM：finite state machine）に対し，すべての状態を通ったか，またはすべての状態遷移を通ったかを表す指標。複数の有限状態機械が連動している場合，それぞれを別々に扱う方法，一つの有限状態機械として扱う方法がある。
仕様をどこまでカバーしたか
（2）の機能カバレッジは，実装（例えばRTL（register transfer description）コード）が仕様をどれだけ満たしているかを表す指標をいう。ただし，「仕様」の定義はあいまいなため，仕様を基盤とする検証カバレッジの定義もさまざまなのが現状である。一般的に用いられるのは，「仕様レベルの機能カバレッジ」と，「実装レベルの機能カバレッジ」である。それぞれ，機能仕様に対するカバレッジ，実装仕様に対するカバレッジと読み替えても良い。
（2.1）仕様レベルの機能カバレッジとは，仕様書や規格書から導かれた検証項目群のうち，どれだけが実行されたかを表す指標である。検証対象の中味を見ないで検証する，「ブラック・ボックス検証」で採用される。この機能カバレッジが十分な指標であるためには，検証項目群が十分網羅的であること，および各項目が十分実行されたことが必要である。
検証項目群の網羅性に関しては，仕様書から系統的に項目を導くプロセスが確立され，実証されていることが求められる。一つの検証項目には多くのパラメータがある場合がほとんどであり，そのすべての組み合わせを実行することは現実的でない。このため，有効なパラメータの組み合わせを定義し，それを実行することによって，検証項目がカバーされたとするアプローチが一般的である。有効なパラメータの組み合わせを定義する手法としては，実験計画法などが知られている。
（2.2）実装レベルの機能カバレッジは，RTL記述に代表されるLSIの実装記述に対して，設計者自身，または実装方式を詳しく理解した人が，チェックすべきポイントや条件を指定して，そのポイントや条件がどれだけカバーされたかを表す指標である。多くの場合，実装記述で用いられる部品が持つ重要な性質に対応してチェック・ポイントや条件を，アサーションの形で記述する。
例えば，FIFO（first-in first-out）の場合，キューが空および一杯のときに読み出し・書き込み動作を試みた場合がチェックすべきポイントになる。実装上，問題となりやすい部品や部位は「ホット・スポット」などと呼ばれることがある。EDAベンダーの検証ツールには，ホット・スポットに対するチェック・ポイントや条件がアサーション群の形でまとめられており，これを利用することで効率的な機能検証が可能になる。
二つのカバレッジそれぞれに利害得失がある
次に，コード・カバレッジと機能カバレッジの特徴について考察する。
コード・カバレッジは，設計や実装に関する知識がほとんど要らないという点で，設計依存性が低く，客観的な検証指標という特徴がある。各種ツールのサポートも十分なレベルに達している。各種のコード・カバレッジを適切に組み合わせることで，比較的簡単に一定品質の検証を実施できる。ただし，コード・カバレッジが十分なレベルに達していないときに，新たな検証パターンを作成する作業では，設計や実装の知識が必要になり，かなり手間のかかる作業となることがある。
一方，機能カバレッジは，LSIが実現する機能そのものをチェックしており，十分な機能カバレッジがあれば，それが品質保証に直接つながるという利点がある。一方で，機能的に十分なチェック・ポイントや条件を設定するためには，設計・実装の知識が必要なだけでなく，ホット・スポットの考え方，アサーションの考え方，実験計画法など，さまざまな知識が必要となる。
アサーションに対するツールのサポートはほぼ十分なレベルに達しているが，アサーションを「どこに，何を，どれだけ」入れるかに関しては，有効な手法が十分には確立されているとは言えない。
実際の運用では，双方のカバレッジを併用することが必須である。例えば，単体検証の品質はコード・カバレッジで確保し，ホット・スポットとなるモジュールについては実装レベルの機能カバレッジを使う。大きなモジュールやシステム全体の検証では，仕様レベルの機能カバレッジを用いる方式が現実的である。
フォーマル検証への適用
カバレッジの概念は，「チェックすべきポイントをどれだけ実行したか」に基づいており，その意味では論理シミュレーション・ベースの検証を前提としている。一方で，LSIの検証でフォーマル検証が用いられるようになってきており，検証の網羅性を表すカバレッジの考え方をフォーマル検証と整合させる要求が増えつつある。
実装レベルの機能カバレッジに関しては，チェックすべき項目がアサーションで記述されるため，フォーマル検証にそのまま適用できる。単にアサーションが発火（成立）したかだけでなく，アサーションに書かれた条件の充足性を完全に検証することが可能である。仕様レベルの機能カバレッジもアサーションで記述できる場合が多いが，そのほとんどは回路全体に関連するアサーションとなるため，現在のフォーマル検証の処理能力では扱いきれない。
フォーマル検証で完全に検証できない場合でも，どれだけの範囲を検証できたかが分かれば有益である。これをカバレッジと考えて，コード・カバレッジや機能カバレッジと融合させる試みが行われているが，実用レベルに達するには時間がかかると考えられる。
標準化がスタート
以上のように，カバレッジにはさまざまな定義があり，それらを理解した上で，利用するカバレッジの組み合わせを決めることが求められる。その際，カバレッジ・データを種々の検証ツールの間で使い回す必要が出てくる。それに応えようと，標準化機関のAccelleraが，カバレッジ基準を標準化するプロジェクトを2006年12月に開始した（同プロジェクトのホームページ）。このプロジェクトでは，カバレッジ・データをEDAツール間で相互運用できるようにすることを狙う。具体的には，標準カバレッジ・モデルの定義，種々のEDAツールで使えるカバレッジ・データ標準の策定がなされる予定である。
