ÁŹW `ć1ŹÍ uƒfƒoƒbƒO‚Ě ˘ŠE‚ւ悤‚±‚» \ \ g ÝŚv h‚Ş gŚźŹŘ h‚ĚƒIƒ

dwm_028-031 99.8.29 10:23 PM ページ28
ーー
ー“設計”が“検証”のオマケになる!?
編集部
本特集の導入として，デバッグ
（機能検
グのテクニックがディジタルLSI の設計
証とテストベンチ開発）の動向について
手法に導入されるということである．こ
解説する．検証用の記述量が回路その
こでは，ディジタルLSI設計におけるデ
検証効率を上げる従来の手法
ものの記述量を上回るようになり，機
バッグ
（機能検証とテストベンチ開発）
機能検証の効率化は，これまでおもに
能検証
（RTL検証）
を効率化したいとい
の動向を紹介し，本特集
「デバッグ鉄人
2 通りの方法で進められてきた．一つ目
う要望が高まっている．その一方で，
への道」の導入とする．
はEDAツールやプラットホーム
（パソコ
現状の機能検証の手法は体系化されて
いるとは言いがたい．どのような手法
“検証”
の比重が“設計”を上回る
ことにもなりかねない．
ンやワークステーション）に投資して，
シミュレーションの速度を上げる方法で
を導入すれば効果が上がるのかが，わ
開発するLSIの回路規模が数十万ゲー
ある．たとえば論理エミュレータやサイ
かりにくい．一つの方策は，検証の専
トに達したあたりから，機能検証を深刻
クル・ベース方式のシミュレータ，ある
門家である
「検証エンジニア」を配置す
な問題として受け止める設計現場が増え
いは高性能なパソコンやワークステーシ
ることである．検証技術の高度化に対
ている
（p.31のコラム「“検証”は設計現場
ョンを導入すれば，1 回のシミュレーシ
応するには，スペシャリストを育てて
の永遠の課題」を参照）．これはたんにシ
ョン
（またはエミュレーション）
にかかる
ミュレータの実行時間が延びている，と
時間が短縮する．
いく必要がある．
（編集部）
いうだけではない．回路構成が複雑にな
二つ目は，検証用データの作り方を工
「デバッグ」とは，プログラム・コー
ったため，検証項目を考えたり，適切な
夫する方法である．かつては，機能検証
ドのなかに混入したエラー
（バグ）を洗い
テストベンチを作成する工数もまた増え
（RTL 検証）においても，ゲート・レベ
出す作業を指す言葉である．これは，も
ているのである．
ともとソフトウェア開発の世界でよく使
ルの検証と同じように入力信号パターン
たとえば，開発するLSIのタイプや開
と期待値
（テスト・パターン）を用意し，
発スタイルにもよるが，検証用記述
（テ
シミュレータを走らせることが多かった．
いまではハードウェア設計の世界でも
ストベンチの記述）の量が回路そのもの
その後，テスト・パターンを自動生成
あたり前のようにデバッグという言葉が
の記述量を上回ることも珍しくなくなっ
するプログラムを作成したり，設計対象
使われている．ディジタルLSIの設計に
ている．「30 万ゲートのASIC を設計し
の外部にビヘイビア・モデルを接続する
われてきた言葉だ．
プログラミング言語にそっくりのコード
ているが， テストベンチの記述は約
方法が知られるようになった．いわゆる
（ハードウェア記述言語）が使われるよう
50,000行．回路の記述量はそれよりも少
テストベンチである．これによって，検
になり，実機テストよりもシミュレーシ
ない」
（リコー 画像システム事業本部 プ
証用データの作成にかかる手間が軽減さ
ョンの比重が高くなるにしたがって，デ
リンタ事業部 第三設計室 設計2グルー
れたり，検証用データを別のプロジェク
バッグという言葉がしっくりくるように
プの井上喜嗣氏）．「50万∼100万ゲート
トなどで再利用しやすくなった．
なってきた．
のASICを開発すると，全体の40％が検
さらに，最近では検証結果の良否を判
しかし，思い起こしてほしい．ハード
証用の記述になる．100万ゲートを超え
定するチェック機能をテストベンチに埋
ウェアの世界で言語による設計が浸透し
ると50％は検証用の記述だ」
（富士通 基
め込む方法も利用されるようになってい
始めたのは，たかだか，ここ5 ∼6 年の
幹通信事業本部 基盤技術統括部 回路技
る．これによって，シミュレータのロ
ことである．コードのエラーを検出する
術部 プロジェクト課長の山崎正実氏）．
グ・ファイルを解析したり，目視チェッ
という意味では，ハードウェア設計者は
もはや，検証は設計の一部とは言えな
経験が豊富であるとは言えない．
確かなことは，今後，ソフトウェア開
発の世界で培われた，さまざまなデバッ
28
くなってきている．それどころか，今の
ペースで検証の工数が増え続けると，
“設計”のほうが
“検証”のオマケ，という
クを行う必要がなくなる．
機能検証の体系がない
二つ目の手法は有効な方法だが，問題
23
dwm_028-031 99.8.29 10:23 PM ページ29
もある．テストベンチの作り方は，設計
者個人のスキルと，設計グループが採用
する機能検証手法の両方に依存する．
まず設計者個人のスキルの問題であ
る．よく言われることだが，テストベン
チの開発はハードウェア・モデルの作成
作業よりも，ソフトウェア・プログラミ
ングに近い．つまり，よいテストベンチ
を作るためには，設計者は従来と異なる
スキル，すなわちプログラミングのスキ
ルを身につける必要がある．
次に，設計グループが採用する機能検
_ 設計者が1人でバグと対決
`検証エンジニアとタッグを組んでバグを追いつめる
〔図1〕設計者と検証エンジニアが共同でデバッグ
証手法の問題である．テストベンチの作
現在，多くの設計現場では，回路設計者自身が機能検証を行っている．_のように，1人でバグと対決してい
り方は，検証対象となる回路に依存する．
る．今後，大規模LSIの設計現場を中心に，`のように，設計者と検証エンジニアがタッグを組んでバグを追
さらに，仕様書の作成方法や検証の手順，
いつめていく方向へ向かう．なお，この中間形態として，各エンジニアが設計プロジェクトごとに設計と検証
の役割を交代している設計現場もある．
デザイン・レビューのやり方などによっ
ても変わる．個々の設計者がどれだけ優
れたテストベンチを作成しても，設計グ
ループ全体の調和がとれていなければ，
になることが多い．
米国などでは設計グループと検証グル
機能設計のフローを図2に示す．設計
者と検証エンジニアが並行して作業を進
そのテストベンチは有効に機能しない．
ープを明確に分けて，LSIを開発するこ
めるため，トータルの期間が短くなる．
結局のところ，テストベンチの作り方
とは珍しくない．各グループには，設計
ただし，これは，検証エンジニアとして，
を含めて，機能検証手法にこれといった
専任の技術者
（設計者）
と検証専任の技術
新たな人員を投入した場合の話である．
決まった体系が見あたらないところに問
者
（検証エンジニア）が所属している．な
∫高度な検証技術をタイムリに導入できる
題がある．「機能検証のあるべき姿を描
お，設計者と検証エンジニアの役割分担
よいテストベンチを作成するには，プ
くのはむずかしい」
（ 日立製作所 半導体
には，いろいろなケースがある．たとえ
ログラミングのスキルが必要である．つ
グループ システムLSI事業部 開発本部
ば，A設計者はまったく検証にタッチせ
まり，よい検証
（デバッグ）
を行うにはソ
設計技術応用部 技師の正田剛史氏）．
ず，検証エンジニアがすべての検証に責
フトウェア技術の知識が不可欠である
「自分たちにとってどの方法がよいのか，
任をもつ場合や，Bモジュール・レベル
（特集 第4 章を参照）．さらに，最近で
敷居が高い手法の場合，それを乗り越え
のテストを設計者が担当し，統合テスト
はさまざまな新しいタイプの機能検証ツ
てもやるべきか，という判断がむずかし
を検証エンジニアが担当する場合などが
ールが登場している
（特集 第6章を参照）
．
い」（NEC システムLSI 事業本部 第一
ある．
たとえば，検証言語
（特集 第7章を参照）
システムLSI事業部 DSP部 プロジェク
トマネージャの吉田誠氏）．
検証の専門家が必須に
機能検証の問題に対処する有効な方策
専門家を置く三つのメリット
設計現場に検証エンジニアを配置する
やカバレッジ解析ツールなどである．検
証技術が高度になり，設計者が仕事の片
手間に新しいスキルを身につける，とい
利点は，以下の三つが考えられる．
うことがむずかしくなりつつある．「従
∏設計品質が上がる
来，機能検証には特殊技能は必要ないと
の一つは「検証エンジニア
（verification
思いこみによるエラーやケアレス・ミ
いう認識だったが，最近は設計者が主導
engineer）
」の導入である
（図1）．ここで
スなど，設計者では見つけられないバグ
していけばよい，という感じではなくな
いう検証エンジニアとは，設計プロジェ
を第3 者の視点で洗い出す．「検証エン
った」
（NECの吉田誠氏）．
クトにおいて，テスト仕様書の作成
（検
ジニアを配置したことで，エラーの混入
証項目のリストアップ），テストベンチ
率が 社内の他の部門の半分以下になっ
の作成，シミュレーションなどを担当す
た」
（OA機器メーカの設計マネージャ）．
検証エンジニアは日本にもいる
日本の設計現場でも，検証エンジニア
る専任の技術者を指す
（特集 第2章を参
「設計者は自分の関心のあるところを深
を配置しているところはある．「HDL設
照）．また，デザイン・レビューを含む
く検証する．逆に言うと，木を見て森を
計を始めたころから，検証と設計を分け
検証フローの確立
（特集 第5章を参照），
見ないようなところがある」
（大手半導体
る体制でスタートした」
（リコーの井上喜
検証環境の構築や保守
（特集 第3章，第
メーカのEDAサポート・エンジニア）
．
嗣氏）．「1996年9月から検証専任のエン
8章を参照）なども検証エンジニアの仕事
π設計期間を短縮できる
ジニアを置いている」
（キヤノン 商品開
23
29