システム検証における
このようなお悩みを解決します!
- 最適な検証手法がわからない
- 検証工数を少しでも削減したい
- 検証知識・ノウハウに課題がある
わからない
ユースケース、検証網羅性、検証リスク高の
三つの視点で最適な検証手法のご提案が可能です。
- ユースケース
ダイレクト検証による検証パターンの作成、期待値比較、アサーションベース検証 - 検証網羅性
制約付きランダム検証による偶発的な不具合の検出及び、網羅性確認目的のカバレッジの作成及び適用 - 検証リスク高
検証リスク高のモジュールに対するFormal検証の適用
削減したい
検証工数削減に繋がる検証手法のご提案及び
スケジュールの立案でサポートします。
- 各検証フェーズでのレビューによる認識合わせにより後戻りのないOutputを提供します
- 検証メソドロジ(UVM)を活用した再利用可能な検証環境を構築します
- 検証工数が膨大となりうるカバレッジ精査においてFormal検証の到達不可能解析をご提案します
- 環境構築・入力パターンの生成不要なFormal検証に早期着手します
課題がある
検証工数削減に繋がる検証手法のご提案及びスケジュールの立案でサポートします。
- 各検証フェーズでのレビューによる認識合わせにより後戻りのないOutputを提供します
- 検証メソドロジ(UVM)を活用した再利用可能な検証環境を構築します
- 検証工数が膨大となりうるカバレッジ精査においてFormal検証の到達不可能解析をご提案します
- 環境構築・入力パターンの生成不要なFormal検証に早期着手します
システム検証とは
システム検証はLSI開発の工程の一つで今後LSIの大規模化に伴って作業規模が増大すると予想されている工程になります。一般的な手法として知られているダイレクト検証は回路の仕様書から検証項目を作成して、テストシナリオを作成し、出力の挙動が仕様書に沿った動作になっているかを確認する検証手法になります。回路規模が小さいモジュールにおいては従来のダイレクト検証で品質の保証及び納期の確保が実現されてきましたが、近年のLSIの大規模化により入力パターンの組み合わせが膨大となり、検証者が全ての条件を想定してテストシナリオを作成することが現実的ではなくなってきております。
最近では形式検証を導入する開発が増えてきており、形式検証はFormal検証とも呼ばれ、仕様書から回路の振る舞いをpropertyで定義して、回路の全状態からそのpropertyに反する挙動が発生しないかを証明する手法です。動的検証と異なる点としては入力の生成やテストベンチの作成が不要の為、検証の早期着手ができる点や、入力の網羅性がDefaltで100%の状態で証明を行うので網羅性の視点で優れています。
ADTの特徴
最先端の検証手法
弊社では近年の検証における課題を理解した上で最先端の手法を戦略に入れた検証が提案できます。
一貫したサービスのご提供
検証戦略の立案から結果の報告まで一貫したサービスを提供します。
豊富な検証手法
各EDAツールの豊富な使用経験や、Formal検証技術、SystemVerilogを活用した豊富な検証手法のノウハウがあります。
システム検証の種類
アサーションベース検証
仕様に定められた振る舞い、Busのプロトコル、発生してはいけない挙動等をpropertyで定義して検証対象に適用することで、RTLの振る舞いが定義した内容に違反しないかを常時チェックする手法です。Bindを活用することで作成したアサーションの水平展開をすることができるので、汎用的に活用できるアサーションは検証資産になります。一般的な規格(AXI/AHB/APB等)はアサーションIPの適用、回路特有の振る舞いは専用のアサーションを作って適用することが必要になります。
制約付きランダム検証
入力データ情報と制約内容(constraint)をClassに定義してランダマイズを行うことによって、仕様上起こりうる入力パターンをランダムに生成して検証を行う手法になります。class以外にはシステムタスクを活用したランダムデータ生成や、randcase等の発生確率を定義したcase文の活用等、検証環境やシミュレータに合わせた様々なランダム検証手法があります。
DPI-Cを活用した機能Cとの協調検証
検証を行う際の期待値として機能Cを活用する場合、DPI-Cを活用することでSystemVerilogのテストベンチから機能C内の関数を呼び出すことができます。シミュレーション中に機能Cの関数を動かしながら期待値を作成することができるので、柔軟な期待値の作成が実現できます。
Functionカバレッジによる検証網羅性の確認
制約付きランダム検証において入力パターンの偏りがないかの確認や、回路の特定の挙動が発生したかどうか、発生した不具合の入力条件が成立したかどうかをカバレッジレポートで確認する手法です。 Functionカバレッジの確認はCoverGroupの定義や、SVAのCover propertyの定義が必要になります。カバレッジを実装した状態でシミュレーションを行い、カバレッジレポートを確認して未カバーが発生していた場合はテストパターン不足と判断できます。検証完了の判断基準になりますので、テストパターンの追加もしくは理由付きで対象外としてレビューする必要があります。
検証メソドロジを活用した環境構築(UVM)
検証分野で推奨されている技術、ルール、慣習、規律等を具体化したSystemVerilogのクラス・ライブラリです。オブジェクト指向の設計、予め決められた実行制御、TLMを使用したトランザクションレベルの通信が特徴になります。再利用可能なコンポーネントで環境構築を行う為、部品の再利用がしやすく、標準化された検証技術の為、検証者全員が同じルールで検証を行うことができます。環境構築を行う為にはクラスの継承や関数のオーバーライド等のソフトの知識も必要になります。検証業界ではUVMに対応した高機能なVIPも活用できるため、主に大規模なプロジェクト等では検証工数削減や回路の品質向上、チーム間の検証ルールの統一等が期待できる検証技術になります。
Formal検証
数学的な理論から回路の構造を解析し、検証者が定義したpropertyに違反する条件がないかを証明する手法になります。JasperGold、VC Formal等のFormalツールを活用してtclファイルによる実行環境を構築することでFormal検証を行うことができます。一般的な手法はFormal Property検証と呼ばれるもので、DUTとアサーションをFormalツールに読み込ませることでアサーションに違反する入力パターンが存在しないかをチェックする検証手法になります。シミュレーションに対して網羅性がメリットになり、コーナーケースや入力の組み合わせが膨大なRTLに対して効果的な検証手法になります。そのほかにもFormalのエンジンを活用した手法で、Connectivity Checking(接続検証)、カバレッジの到達不可能解析、回路の修正前後の等価性検証等のモードがあります。
エミュレータ
検証方法のひとつとして、エミュレータを導入することで、シミュレータでは実施できないような回路規模の大きいものや実行時間が長いものを実施することが可能になります。エミュレータでは、シミュレータとは異なり、コンパイル後の合成データを元にテストパターンを実施することになります。 その際の合成対象には、実行時間を高速化するためにRTLだけではなく、テストベンチも対象もなります。そのため、シミュレータとエミュレータではサポートする記述、文法(システムタスク等)が異なり、同じテストベンチでは使用できないため、それぞれで環境を作らないとなりません。検証開始の初期段階でどちらかで実施するかもしくはどちらも実施するかの検討が必要になります。
システム検証のフロー
UVMを用いた検証のイメージ図
開発言語・環境
システムLSI設計では、プロセッサ(CPU)からの命令で各種機能モジュールが動作します。CPUや各種機能モジュールは、お客様のIP、ベンダーIP、3rd-Party IPを使用して開発する機能にあう形にカスタマイズ設計を行います。
上記に近い構成の開発事例として、画像処理系や画像転送装置向けLSI、Gb イーサネット通信系、携帯電話端末/基地局向けLSI、車載系LSI(ダッシュボード、画像認識)、医療系LSI(内視鏡、超音波診断)、ストレージ(SSD、UFSコントローラ)など様々な開発実績があります。
検証言語
Verilog、SystemVerilog、VHDL、C言語
開発ツール
論理シミュレーション | VCS、Xcelium |
論理合成 | Design Compiler、Fusion Compiler、RTL Compiler |