はじめに

AMD ザイリンクス社のVirtex®が登場したのは1997年、それから23年の時を経て、最新のVirtex®デバイスが搭載することのできるトランジスタ数は、23年前のおよそ1000倍にもなる。従来と同じ開発プロセスを維持していたのでは立ち行かなくなることは明白である。FPGAは開発規模においてはASIC/ICを凌駕するほどに成長しているものの、開発プロセスに注目すると、まだまだASIC/ICのそれに比べて改善の余地が大きい。

FPGAはPALやPLD、CPLDなどから発展してきた経緯があり、もともと製品やシステムの一部の機能を実現する「部品」としての位置付けであった。PALレベルであればシミュレーションする必要もなく、組合せ論理が正しく接続されていることを目視確認するだけで済んでいた。しかし現在のFPGAは製品やシステムの多くの機能を実現し、他社に対する差別化の要とも言える位置付けになっている。それにも関わらず昔ながらの開発プロセスの進め方やアプローチが散見され、そのようなプロジェクトでは現在のFPGAの規模、複雑度、能力に応じた開発プロセスの見直しが喫緊の課題である。

シミュレーションの活用

FPGAプロジェクトにおけるシミュレーションの位置付けについて考えてみると、RTLを対象にしたシミュレーション、論理合成後のネットリストを対象にしたシミュレーション、そして配置配線後の実タイミング情報を含むネットリストを対象にしたシミュレーションがある。最近では論理合成や配置配線を１つのコンパイル工程とし、コンパイルの前後で論理が変わっていないことを確認する等価性検証を実施するプロジェクトも増えてきた。逆に言えば、シミュレーションで確認することの多くがRTLに集中し、機能検証を確実に行い、RTL設計をゴールデンに製品の品質を担保する必要がある。


しかし設計規模が大きくなり、機能が複雑に絡み合う設計に対して、シミュレーションにおけるテストベンチやテストシナリオを作成することは必ずしも容易ではなく、この課題を克服するためにIEEE 1800.2 UVM標準を採用し、それと連動するテストプランを立てることが重要になる。そもそもシミュレーションは、与えられたスティミュラスに従って対象デザインを活性化し、その振舞いを波形データなどで表現することで、シミュレーション結果を設計者に提示するものである。波形データを目視確認する設計者は何かしらの期待値を持っており、それは仕様書からあるべき状態を想定し、あるべき振舞いを期待している。これを確認する作業が検証となる。図1.はシミュレーションによる大雑把な機能検証フローである。

図1. シミュレーションによる検証フロー

この検証フローには２つの分岐がある。分岐に使われる質問は、１つめが「正しく動作しているか？」であり、２つめは「テストは充分になされたか？」という質問である。正しく動作していることを確認する手段として、アサーションや、UVMにおいて期待値比較を可能にするスコアボードがある。「正しく動作しているか？」という質問に対して回答を得るための仕組みをテストベンチやデザインに仕掛けることで検証の自動化が可能になる。ここで正しく動作していなければデバッグへと進み、デザインを修正してシミュレーションを繰り返す。正しく動作している場合には、「テストは充分になされたか？」という質問に進む。

この質問に対して自動的に回答を得る仕組みはカバレッジである。カバレッジはコードカバレッジ、機能カバレッジ、トランザクションカバレッジなど、多彩なカバレッジ情報を集約し、テストが充分かどうかを判断できるようにする。充分でない場合にはテストを修正したり、あるいはランダムテストを活用する場合には制約を修正したりランダムシードを変更する。このように検証作業の多くを自動化することで、検証の品質と生産性を高めるためのインフラストラクチャとする。

しかしFPGAプロジェクトによっては、UVMの採用や、採用しても充分に活用できていないプロジェクトも多い。新規設計のユニットについては単体シミュレーションを実施するだけで、さらに上位階層に対してUVMを適用し、それと連動するテストプランを策定していないプロジェクトも多い。理想的には業界で最も採用されているIEEE標準であるUVMを導入するために、ある程度のソフトウェアのスキルを持つメンバーを投入し、何をランダム化するべきかなどの検証ノウハウを積み重ねていくことが大切である。

FPGA実機を用いたデバッグ

新規作成のユニットのみをシミュレーションして、早期からFPGAを焼き、実機に火入れするプロジェクトでは、その結果FPGAが正しく動作していない場合、実機デバッグをすることになる。FPGAの実機デバッグにおいては、開発環境に統合されているロジックアナライザ機能を使用することが多い。

基本的には対象となる問題を観測するためのトリガを設定し、指定したプローブ信号の内容をサンプリングし、指定したサイクル深度のデータをスタティックメモリにアロケーションする。ロジックアナライザ機能はVerilogなどのHDLコードとして出力しデザインに取り込むため、トリガやプローブ信号、サンプリング深度を変更して観測するには、再コンパイルが必要となる。

このような実機デバッグでは、さまざまな課題に直面する可能性がある。

• FPGAが正しく動作していない状況下で、どの信号をどれくらいの深度で観測すべきかを特定し、ロジックアナライザのコンフィギュレーションを決定しなくてはならない
• ロジックアナライザの再設定に伴って再コンパイルの時間を要する
• ロジックアナライザによるサンプリングデータのメモリ領域を確保することによりデザインに影響を及ぼし、設計の修正が必要になる
• 正しく動作しない現象に再現性がなく、デバッグが前に進まない

このような課題に対する有効な解がないまま実機デバッグを始めると、いつバグが特定できるのか、いつバグが終息できるのかといった予測性が失われることが多い。プロジェクトによっては問題となっている振舞いをシミュレーションで再現しようと試みることもある。

しかし、この手法には大きな矛盾がある。そもそもシミュレーションはテストプランに基づいてテストベンチやテストスティミュラスを作成し、それによって所望の結果が得られるかを確認するための手段である。所望の動作をしない状況を作り出すためのスティミュラスはテストプランには存在しない。もし問題を再現するためにテストスティミュラスを作成するならば、その労力はFPGAを焼く前に費やされるべきである。

このような状況に陥らないようにするには、プロジェクトの早い段階からプロジェクトを俯瞰した検証戦略を立てることが重要になる。

検証戦略を立てる

検証戦略とは、機能検証をスムーズに遂行してプロジェクトを終了させるまでを見越した視野と複合的な思考によって、労力や資源をどのように活用するかを策定したシナリオであり、その方向性に沿った計画、準備、運用を含む総合的な方策のことである。資源には人的資源やスキルセットの他、ツール資源、検証IP資源、計算機資源などが含まれる。それらをどのように、どのフェーズで、どのような検証対象に対して活用するかの指針も検証戦略に含まれる。また部分的に業務を外部委託するという選択肢も取り得るが、その際には受入れ時の検収条件も併せて検討しなくてはならない。

検証戦略について考える上で、機能検証の対局にある「機能バグ」を想定することは、非常に有効なアプローチである。特に過去に出たバグの発生傾向や、どのように修正したかを分析することは、何よりも重要な情報源となる。
図2.はIBM Researchが、過去のバグの発生傾向を調べるために、設計の動作をその特徴に応じて分類したものである。

図2. IBM Researchによるデザインの分類

デザインはその動作の特徴によってコントロール系とデータパス系に分類される。しかしデータパスはさらにステートマシン要素を含むデータ転送系と、主に演算処理を行うデータ変換系とに再分類することができる。こうして分類した結果、コントロール系とデータ転送系ではRTL1000行に対して約10個という割合でバグが混入していたのに対し、データ変換系で混入したバグの割合は、同じRTL1000行に対して約2個だったことが報告されている。

コントロール系やデータ転送系に含まれるステートマシンを検証するには、シミュレーションを使って複雑な状態繊維を網羅的に活性化させようとテストスティミュラスを駆使するよりも、ブロック単位でフォーマルエンジンを用いて網羅的な検証を行う方が、効率的であろう。最近では完全に自動化されたフォーマル・アプリケーションを活用することで、特別なスキルを必要とせず、誰でも使うことができる。

一方で4Kや8Kなどの画像データを処理するアルゴリズムでは、１つのフレームをシミュレーションするのに1日、2日と費やしてしまうため、むしろFPGA実機で確認した方が効果的かも知れない。FPGA実機前のシミュレーションは必須であるという指摘と矛盾するように思えるかも知れないが、バグの発生確率が低いと分かっていれば、そのような戦略もある。

図2.の例はあくまでもIBM Researchのものだが、自分が置かれている組織やプロジェクトチームが過去に経験してきたバグの出方に関して一定の分析をし、さらにFPGA実機におけるデバッグ労力などを総合的に分析することで、戦略の選択肢は広がり、その中で最適なバランスを達成することができる。やみくもにFPGAを焼いて実機に火入れするのではなく、プロジェクト終了に至るまでを俯瞰した戦略を立てることで、プロジェクト成功の確率が高まる。

検証戦略と開発プロセス

検証戦略を立てる際に、その選択肢が広がらない最大の理由は、開発プロセスが充分に成熟していないことが多い。開発プロセスは、時代や市場が求める要件を満たすために常に成熟することが求められる重要な要素であり、組織としてのアセスメント評価、最適化を継続的に行わなくてはならない。
開発プロセスは重要な３つの要素から成り立っており、それは「手続き」、「ツール資源」、「人的資源」である。

図3. 開発プロセスの３大要素

例えばRTLを作成する工程について考えてみる。過去の様々なプロジェクトからの学習や得られたベストプラクティス、カンファレンスなどで共有される知見などから、可読性、再利用性、デバッグ容易性に優れたRTLを作成するには、命名規則を儲けることが有効であるということがわかる。特に重要なクロック信号やリセット信号はもちろん、同期・非同期の区別、正論理・負論理の区別、モジュールとファイルの関連付けに至るまで、さまざまな命名規則が有効であるとされる。どのような命名規則が適切であるかは本稿のスコープの外だが、そのような命名規則は文書化して共有するべきであり、また技術の進化やコンプライアンスへの遵守の必要性などを反映して更新されるべきものである。これが決められた「手続き」である。

手続きに従って記述されているかどうかを確認するには、ツールの適用が必要である。定義された手続きに則り、命名規則を遵守しているかどうかを自動的にチェックし、違反があればメッセージを出力し、問題の箇所を特定する。プロジェクトにおいてどれくらいチェックが完了しているかなど、全体を俯瞰した情報を提供してくれるツールもある。このようなツールのライセンスに容易にアクセスできることが、「ツール資源」となる。

そしてツールを使いこなし、メッセージの読み方や効果的な解析と修正方法などを定型化し、ツールユーザに徹底することでツール活用の効果が高まる。ルールやツール機能の更新時に組織内でトレーニングを実施することも重要である。また形骸化を防ぐためには、命名規則が定められた背景や、下流工程となる論理合成やシミュレーション、デバッグ、配置配線などにおいて、どのようなメリットをもたらすのかといった情報をトレーニングで触れることも必要である。このような理解が深まることで形骸化を防ぎ、モチベーションの維持につながる。このような人的な側面が重要であり、開発プロセスにおける「人的資源」として挙げられている。

RTL記述のリンティングのみならず、機能検証におけるさまざまな手法を文書化し、手続きとして定義する。また過去のバグ事例からブロックの特徴に応じて有効な検証ツールや手法を定義し、それが活用できるようにトレーニングを実施することは、組織としての開発プロセスを成熟させ、ひいては検証戦略を策定する際にさまざまな選択肢が得られることになる。

まとめ

FPGAは継続的に大規模化、複雑化を遂げており、従来よりも多くの機能やインタフェースを搭載することができるようになっている。そして最終製品やシステムを差別化する上でも重要な位置を占めている。開発環境には論理合成やシミュレーション、配置配線などのツールがあるが、シミュレーション１つをとってみてもカバレッジを測定したりアサーションを追加したり、IEEE 1800.2 UVMを活用して制約付きランダム検証を実施できるように進化を遂げている。それに対応できるよう、手続きを整備し、文書化し、そして人的資源として開発エンジニアのスキルを上げるようなトレーニング実施も重要である。さらにはシミュレーション以外の完全自動のフォーマル・アプリケーションやリンティングツールを導入するといったことも重要である。先にあげた３大要素を見据えながら、組織として開発プロセスを成熟させ、適切な検証戦略が立案できるように継続して最適化を図ることが大切である。

 

参考文献

[1] Harry D. Foster, “Evolving Capabilities – Introduction to Verification Academy” on Verification Academy website - https://verificationacademy.com/sessions/introduction-verification-academy

[2] Chriss Giles, “Improving Initial RTL Quality”, on Verification Academy website - https://verificationacademy.com/sessions/improving-initial-rtl-quality

[3] Mark Eslinger, “Verification Academy Questa AutoCheck Demo – Advanced Linting” on Verification
 Academy website - https://verificationacademy.com/sessions/questa-autocheck-demo

 

「Design and Verification Landscape」技術情報メールニュース

PALTEKでは本ブログ「Design and Verification Landscape」シリーズの技術情報をメールで年に3-4回発信しています。
ご登録いただいた方には、最新の情報をメールニュースとしてお届けします。
ご希望の方はこちらのフォームよりご登録ください。

※競合製品取り扱い企業様の申込については、お断りする場合がありますので予めご了承ください。

 

このブログのシリーズ一覧は下記になります。是非あわせてお読みください。