スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

JSUNG2011:ユーザー事例(その5)

9/7(水)に開催された「SYNOPSYS USERS MEETING 2011」に行ってきました。

最後はCMエンジニアリングの「検証IPを用いたマルチCPU内蔵SoCの検証環境構築事例」です。

Agendaとして以下の流れで説明していました。
・マルチCPU内蔵SoCの概要と検証の課題
・検証戦略 ・検証環境紹介
・テストベンチ共通化、VIP活用で工夫した点の紹介(VIP活用テクニック)
・結果/効果
・まとめと今後の課題

まず、概要として今回のデザインですが、汎用CPU3個、AXI:2個、AHB:数十個、APBスレーブ:4個といったSoC。 今回の事例では珍しい事例と思ったのが、SoCすべてのデザインが揃ったなかでの検証ということだった。 本来はサブモジュールなどの検証が完了し、その上のブロック検証→TOP検証とボトムアップ的に上がっていくが、 このケースでは、TOP自体はもう存在し、そこからサブモジュールといった下位レベルからTOPレベルまでの検証 だった。

そういった事例において、検証戦略や検証環境の効率化などを聞くことができた。 まず第一に検証の階層分けということで、「TOPレベル」「サブシステム」「単体モジュール」「サブモジュー ル」と4つの 検証分類に分けて、それぞれで求められる検証品質を定義した。

その中でVIP(Verification IP)や、検証メソドロジ(VMM)を用いることで検証環境を共通化することが出来た。 ただ、懇親会での話を聞くと「TOPレベル」と「サブモジュール」だと求める検証レベルが違うので、サブモ ジュールでは手を加えたりもしたらしい。 VIPはAMBA系に関してはSynpsys社のものを使用し、オリジナルバスやGPIOなどは自作したとのこと。 VIPを使う効果として、VIPへの検証が発生しないことや使いやすさを挙げていた。

課題点として、「共通化による影響で、街頭検証に不要な検証部品がコンパイルされる」や 「VMMを利用したからといって、直ぐに再利用性が上がるわけではない」と言っており、 個々が意識して検証環境を作る or 使う必要があると感じた。

懇親会にて、検証項目について質問してみた。
間引くことはせずに、すべての項目を実施したとのこと。

関連記事

コメントの投稿

非公開コメント

プロフィール

Kocha

Author:Kocha
なんでもチャレンジ!(^o^)/
E-mail
github:Kocha
イベントカレンダー

カレンダー
08 | 2017/09 | 10
- - - - - 1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
カテゴリ
OVP (4)
最新記事
最新コメント
アーカイブ
リンク
Twitter
アクセス人数
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。