今回も引き続き「DVConステアリングTG」からお届けします。
DVCon Japanの詳細はこちらです。
DVCon Japan 2023 – 実行委員会メンバーはドキドキしている！
来る6月22日（木）、川崎市産業振興会館にてDVCon Japan 2023が開催されます。DVConはDesign & Verification Conferenceの略称で、Accellera Systems Initiativeがメインスポンサーとなり、日本国内では情報処理学会-SIGSLDM(SIG-System & LSI Design Methodology)、IEEE CEDA All Japan Joint Chapter、そして一般社団法人電子情報技術産業協会による協賛のもとで開催されます。
DVCon Japan 2023のロゴ
今年のDVConは午前中の基調講演やAccellera Overviewのセッションに続いて、8セッションのチュートリアル、１２セッションの論文発表が３トラック並行して行われ、さらに午後からは展示会も開催されます。また夕方からはネットワーキングを目的とした懇親会／展示会も用意されています。
DVCon Japanは2022年に第一回が開催されましたが、コロナ禍の影響でオンライン開催とオンデマンド視聴でした。オンライン開催はJEITA - 電子情報技術産業協会のスタジオから無事に配信することができました。つまり今年のDVCon Japan 2023は国内開催のDVConとしては初めての会場での対面開催となります。実際にお客様を前にしての総合司会や論文発表でのセッションチェアの役割はもちろん、各会場でのPC設営と音響設定、200人を超えると予想されるお客様を誘導し、ランチの準備や懇親会の準備、後片付けまでをこなさなくてはいけません。現在、実行委員会のメンバーはその準備に追われ、実は相当ドキドキしています。ご参考までに実行委員会メンバーの普段の顔写真は、こちらから見ることができます。
標準規格に関するチュートリアルの予備知識
もう１つ、別の意味でのドキドキ感があります。それは８セッションのチュートリアルの中でも、日頃からあまり接する機会がない、Accellera標準やIEEE標準について学ぶことができる３つのセッションが提供できるということです。ここでは、そのセッション受講前の予備知識についてご紹介します。
- Portable Test & Stimulus Standard
これは通常PSSと呼ばれており、Accelleraの標準です。SoCやASIC、FPGAなどのテストシナリオに関する標準です。どうやってテストするかより、何をテストするかに注目します。SoCに含まれるリソースを考慮し、例えばUSBでデータを受取り一度メモリに蓄積し、DMAチャンネルがデータをコピーして画像プロセッサに渡す、といった一連のテストシナリオについて考えます。ここで重要なのはUSB、DMA、画像プロセッサというリソースが扱えるデータタイプは何か、データフローはバッファ型かストリーム型か、DMAチャンネルは他のリソースと共有するのか占有するのかなどを制約として指定すると、その制約を守った「リーガルなテスト空間」にあるすべてのテストシナリオをグラフ展開し、スケジュールし、生成してくれます。テストを記述するというよりは制約ベースで合成するという表現が正しいでしょう。DMAチャネルを使わずにCPU上の実行命令がメモリに取込み、そこから画像プロセッサに送るという別にシナリオがリーガルであれば、それも生成してくれます。
PSSは2018年6月26日に「PSS Language Reference Manual 1.0」をリリースして以降、2019年2月25日には0a、2021年4月14日には2.0をリリースし、現在は2.1に向けた標準化作業が進んでいます。ただ今回の改訂ではあまりにも大きな仕様変更をしているため、ひょっとするとV3.0という版名になるかも知れません。その大きな仕様変更は、DVCon Japan 2023のチュートリアルで知ることができます。 - IP-XACT
2010年4月、SPIRITコンソーシアムはAccellera Systems Initiativeと統合しました。SPIRITはもともとIPの運用を促進するIP-XACTの策定を進めており、当時すでにIEEEのコーポレートメンバーとなっていたAccelleraとの統合は、その後のIEEE標準化の加速にもつながっています。
IP-XACTは、IPを再利用する際に、IPの構成方法やインタフェース、コンフィギュレーション、レジスタマップなどがIP提供者によってまちまちで、多くのドキュメントを読んで使用するプロセスにはヒューマンエラーが介在しやすく、IP再利用で期待される生産性向上にブレーキをかけてしまう課題に対応しようとするものです。IP統合に関する要素を標準化し、メタデータとしてXML表記することで、ツールやスクリプトによる自動化を促進し、ひいてはIPの再利用性やSoC統合を容易化することが趣意です。
IP-XACTはIEEE-1685として2009年に標準化され、その後2014年に改訂されています。Accelleraに設置されたIP-XACTのワーキンググループでは、IEEE標準に対する捕捉的なユーザーガイドを作成したり、ベンダー固有の拡張機能などを策定したりしてきました。またIP-XACTの標準をさらに改善し、IP統合だけでなく早期プロトタイピング、機能検証、パワー解析、AMS、デバッグなどへの対応を議論してきました。このような活動の結果、期待されているものがIEEE-1685 2023年版としてリリースされる予定です。DVCon JapanではIP-XACTの基本的な情報も復習しつつ、2023年版リリースでどのような変更がされるかについてもお伝えする予定です。 - UVM ― pyuvm
UVM – Universal Verification MethodologyはもともとAccelleraで標準化された検証メソドロジで、制約付きランダム検証、カバレッジドリブン検証を実現するためのAPI群およびクラスライブラリで、IEEE 1800 – SystemVerilogにより実装されていました。その後、UVMがIEEE標準となる際に、IEEE 1800.2 UVMではAPIの仕様のみを扱い、APIの実装部分は標準化の対象とはなりませんでした。この移管後、AccelleraのUVMワーキンググループからは、IEEE 1800.2のリファレンスライブラリという位置付けで、SystemVerilogによるクラスライブラリ実装を提供することになりました。
この変更により、UVMはSystemVerilog実装でなくても良いため、例えばSystemCワーキンググループではシステム開発から半導体検証への流れを滞りなくすることを目的として、SystemC実装のUVM互換ライブラリに着手しています。同じように、UVMをPythonで実装しようとするオープンソースのプロジェクトも登場しました。もともとcocotbというHDLシミュレータとのコ・シミュレーション実現の関数ライブラリがあり、これを活用してpyuvmとしてUVM実装ライブラリが提供されています。
すでにSystemVerilogでのリファンレンス・ライブラリが存在するのに、なぜPythonなのか、また実効性はあるのかなどについても解説される予定です。
川崎市産業振興会館 – 外観
DVConは米国では4日間で$695、ヨーロッパでは2日間で€300ですが、国内では1日ですが￥3,000-で開催します。DVCon Japan 2023への参加登録やプログラムについてはhttps://www.dvcon-jpn.org をご参考にしてください。半導体の上流設計と機能検証に関する最新情報やベストプラクティスを学び、ぜひ懇親会で乾杯しましょう。皆様の積極的なご参加をお待ちしております。
（EE Tech Focus合同会社 / 三橋明城男）
それではMBSEの概要を説明します。エムビーはモデルベースの略です。モデルベースとは仕様や仮定、コンテンツなどをモデルという抽象的な数式やパラメータ、図式などで表現することです。これによりだれでも共通的な認識を得ながら一意的な結果をみちびきだすことです。モデルベースにはMBDとMBSEというものがあります。どちらもモデルベースでの開発方法のアプローチですが、少し違います。これからそれを説明します。
さらに説明を加えますと、MBDとMBSEは言葉が似ておりますが違うものであることを説明します。ただし、これらは関係しあうものでもありますのでそれを模式図で表します。左側がモデルベースドデベロップメントMBDで右側がモデルベースドシステムズエンジニアリングMBSEです。MBDは物理的な設計ですからモデルは物理モデルになります。先ほど紹介したLPBフォーマットはこのモデルを繋ぎ変えるプラットフォームになります。一方MBSEはシステムの要求を分析し基本的な機能ビヘイビアをつくり、それから導入法のアーキテクチャをつくって、それが妥当か検証するというストーリー作りのエンジニアリングです。これから仕様であったり、開発指針であったり、体制であったりを定義していく過程です。MBDもMBSEも概略段階から詳細段階に検討を繰り返しながら完成させるものです。
それではMBSEの事例を紹介します。これはフロントロ-ディング型のMBSEの進め方の例でJEITAのMBSE研究会で行っている事例研究の紹介です。
MBSEの手法を使ってビヘイビアごとに大まかな実務的な機能を割り出します。時系列やリソースを意識してそれをつないでいくと工程表が出来上がります。
ここで工程をグルーピングして、MBDを実施する際のモデリングや設計検証作業をするグループの 工程の切り分けを行います。一般のMBSEには無い手法ですが、BAT Mapping という手法を考案し適用しています。さきほどパーティショニングした一つ一つを 「ビヘイビア TO アーキテクチャチーム、略してBAT」という仮想ワークグループをつくります。論理アーキテクチャに従って仮想組織と開発の流れを整理します。
最後に定義されたMBDの一つをさらにMBSE手法で作業内容と情報交換を詳細化した例を紹介します。先ほど定義したMBD Task 1の部分を詳細化したものです。まず、BAT内の作業をBATに課せられたミッションが達成できるように単一の作業のレベルまで詳細な工程までブレイクダウンします。BAT間でやり取りされる情報を明確化します。ここでLPBフォーマットが登場します。伝達される情報をLPBフォーマットで記述することにより、ミスや洩れのない情報が電子データで伝達可能となり、フローの自動化につながります。
