機能設計・検証の工程では，まず，仕様書をベースにハードウェア記述言語を使ってRTL設計データ（コード）を人手作成する（図1）。最近は，動作合成を使って，RTLコードを自動的に作成するケースが増えている。次に，このコードについて，機能的な確からしさ，性能的な確からしさ，コーディング品質をチェック（検証）する。そして，RTLコードに論理合成を適用してネットリストを得る。このネットリストとRTLコードの間で等価性をフォーマル検証（等価性検証）で確かめる。
上述したRTLコードの機能的な確からしさや，性能的な確からしさは，多くの場合，論理シミュレーションを使って検証する。その際に，論理エミュレーションやプロトタイピングを併用して処理速度を向上させるケースが増えている。また論理シミュレーションの際に，アサーション記述を含めたテストベンチを利用すると効率のよい検証（アサーション・ベース検証）が実施できる。
論理シミュレーションに加えて，フォーマル検証（プロパティ・チェッキング）を実施する例が増加している。プロパティ・チェッキングでは，仕様書の内容をプロパティ記述言語で表現し，その内容がRTLコードに反映されているかチェックする。機能・性能以外の品質検査としては，非同期検証やコーディング・スタイル・チェックがある。
検証が十分に行われたかどうかは重要な課題である。その十分性を図る尺度として，各種の検証カバレッジが定義されている。カバレッジをチェックしながら，検証作業を進めることで，検証の効率化が図れる。
機能検証手法の規格化が進む
従来，機能検証は各社各様に立案され実施されてきた。最近，検証手法を規格化して，検証品質を向上させ，かつ検証作業の効率化を目指す動きが盛んになってきた。現在，よく知られている検証手法は二つある。一つは英ARM Ltd.と米Synopsys, Inc.が策定した「VMM（Verification Methodology Manual）」。もう一つは，米Cadence Design Systems, Inc.と米Mentor Graphics Corp.が策定した「 OVM（Open Verification Methodology）」である。どちらも，検証記述言語としてSystemVerilogを使う。
検証手法の規格化と共に，検証効率化のために，検証の手順や検証用データを再利用するための，検証ライブラリ（検証IP）が登場している。これらもかつては各社各様だったが，最近，規格化の動きが出てきた。例えば，米Accelleraは， VIP-TSC（Verification Intellectual Property Technical Subcommittee）を2008年５月に設置し，検証IPや検証ライブラリの標準化を進めている。これにより，検証IPや検証ライブラリのインタオペラビリティ（相互運用性）が高まると期待されている。
