事業内容

エキスパートエンジニアによるサポート

各ステップにおける最適な提案と実施

  • 要求仕様定義、機能仕様定義・・・
  • パーティショニング・・・
  • 検証プラン・・・
  • RTL設計・・・
  • 検証環境構築及び検証・・・
  • プロトタイプ検証・・・
  • バックエンドプロセス(パートナーとの共同作業)・・・
  • EDAツール評価・・・
  • 各種IP評価・・・

ベリフォアは、LSI・FPGAの開発効率向上でお困りのお客様に解決策を提供する、ソリューションカンパニーです。

検証環境構築及び検証

次の3つの力でお客様にお応えします。

  • 最適な検証アーキテクチャを提案する力
  • 最高の検証環境を短期間で実装する力
  • 検証の新技術を独自開発する力
ベリフォアの3つのサービスについて
■検証サービス

設計者とは別に、検証のエキスパートエンジニアが第三者検証を行います。
ダイレクト検証はもちろん、制約付きランダム検証アサーションベース検証フォーマル検証など最先端の技術を駆使し、再利用可能な検証環境とともに最短の期間で最高の品質を ご提供いたします。またRTL設計前に性能検証を行うことも可能です。 例えば、「バスアーキテクチャの変更にともない、パフォーマンスを前もって確認しておきたい」といったご要望にも しっかりとお応えいたします。

■検証IP開発(VIP=Verification IP)

RTL機能検証の効率を如何に上げるか?SoC開発のボトルネックである機能検証、 その効率化の答えは検証環境再利用化につきます。しかし、その実現は片手間には行えません。 ベリフォアは、再利用可能な検証環境構築にともない、必須の検証アイテムをVIP(機能ブロック)化いたします。 検証効率の切り札であるVIP、その開発にも我々の検証技術がきっちりとお応えいたします。

■検証ツール

RTL機能検証にともなうコード作成量は、機能記述のRTLライン数と平均してほぼ同等のものになります。 また膨大なシミュレーションパターンとそのデバッグ、工数は増えることはあっても減ることはあまりありません。 そんな増大する一方の機能検証作業の効率を如何に上げるか、我々は日々検討、改善しています。
さらに、ちょっとしたかゆいところに手が届く、デバッグがやり易くなる、 そんな支援ツール(VeriClearなど)を独自に開発しています。 大手EDAツールの補助として、あるいはエンジニアのストレスを少しでも解消するものとして、販売はしなくともあると嬉しい、 そんなツールを我々はご用意しております。
その他、フォーマル検証ツールはじめ機能検証にかかわるツール ならどんなことでもご相談ください。

検証技術解説

検証サービスの流れ

検証サービスの手順と成果物
■検証サービスの手順

検証コンサルティング・サービスの流れとして、大きくは検証仕様検討検証環境実装リグレッションの3段階があります。検証対象によってそれぞれの工程でかかる時間は変わってきますが、一般的にカスタムのメモリーコントローラなどが検証対象の場合には、それぞれの工程で1ヶ月ずつ、合計3ヶ月程度の作業期間が必要になります。しかし、ベリフォアが提供する検証IPを利用することで、その期間をダイナミックに短縮することが可能です。

■成果物
検証仕様検討 → 検証仕様書:
検証コンサルティング・サービスの基本となるドキュメントです。検証目的、検証対象、検証手法、 検証アーキテクチャ及び各検証項目の定義とチェック方法を記述し、提供いたします。具体的には、お客様との打ち合わせを通して 確認した検証対象の仕様及び制約に基づき、どのような機能をどう検証するかについて記述します。 例えば、ランダム検証の場合には制約と機能カバレッジについて、 ダイレクト検証の場合にはテストシナリオについて記述します。 また想定されるコーナーケースがあれば、その要因を発生させるためのシナリオとカバレッジ についても記述します。弊社が作成した検証仕様書をお客様にレビューしていただき、 検証内容に合意していただいた後、この検証仕様書に基づいてテストベンチの開発を行います。
検証環境実装 → テストベンチ・外部仕様書:
検証を再現させるためのテストベンチ及びテストシナリオファイル一式を提供いたします。 テストベンチはオブジェクトを、テストシナリオファイルに関してはソースコードを提供いたします。
リグレッション → 検証結果報告書:
検証仕様書に基づいて実施した検証結果を報告するドキュメントです。 ダイレクト検証とランダム検証を用いた検証の場合、ランダム検証の機能カバレッジの達成率と、 ダイレクト検証結果をまとめたものです。通常、機能カバレッジ達成率が100%に達し、 全てのダイレクト検証がパスしたときに、検証が終了したとみなします。ランダム検証に関しては、達成率だけではなく、 カバレッジポイントごとの発生頻度を確認することも可能です。また、リグレッションに用いたテストケースの サマリについても記述します。通常、リグレッションはほぼ毎日実行され、機能カバレッジ達成率が更新されますので、 検証の到達度をトラッキングすることが可能です。
リグレッション → RTL不具合報告書:
RTLに不具合があった場合の、内容とその修正内容のサマリを記述したドキュメントです。通常、 リグレッションの課程で不具合が発見された場合、まずその不具合の根本原因がRTLにあるのかテストベンチにあるのかを追求します。 根本原因がRTLにあると想定された場合には、不具合の報告、再現条件などを速やかにお客様に御連絡差し上げます。 なお、各不具合はバグトラッキングシステムにより管理されます。

検証技術解説

事例紹介