SWEST/DAS　共同招待講演2・セッションA-2 「研究・標準化動向分析に基づくシステムレベル設計手法の提案　−JEITA　SLD研究会の活動から−」参加者：約100名＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝黒坂氏（NECエレクトロニクス）：システムレベル設計はデジタルのLSI,SOCを対象としている SOCの中にはCPU，DSPなどが含まれ複雑なので設計手法を色々考えていかないといけないためそれらを調査しまとめたものです。研究会のメンバーである半導体メーカー、システムメーカー、EDAベンダと各種企業が集まり、5年弱で述べ100人くらいが参加し調査・検討したものです。研究会の目的はシステムレベル設計のニーズの調査、現在の技術動向を調査し、そこから提案、技術発信ができないかということで行っています。純粋な研究者ではなく、現場の人間が集まっているため、現場の声を集めることをフォーカスして行っています。活動はアンケートによるニーズ調査、システムレベル言語の調査、実際の今の技術がどうなっているのかを調べ、それをシステムレベル設計フローとしてまとめました。さらに、団体なども調査し今回まとめました。我々が定義したシステムレベル設計は要求仕様の定義、機能決定、設計空間RTWS4つの設計工程に定義されています。特徴的なところとしてプロファイリング技術も採用しています。このような設計フローを定義したときに色々な課題があります。それがどうのように解決されているかを調べています。具体的には3つの標準化団体と、その他欧米、日本の団体の活動を分析しました。調査の中で、現状の技術で標準化の提案やEDA技術が出てきたものもあります。まだまだ問題のあるところもあり、アーキテクチャを決定するツールや手法では実際の適用という観点から、またシステムモデルというものもまだギャップがあります。さらにはそういった技術を実際に適用していくという観点から色々評価、実験していかなければならないというところあげ、見積もり、モデリング、設計手法という3つの活動を定義しそれぞれのグループで調査、検討を行いました。＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝野々垣氏(東芝)：背景ですが、現在、新規に何かを作るというよりも以前に作ったものと似たようなものを作るという流用設計が主流です。当初システムレベル設計は比較的白紙から作りましょうというところも考えていましたが、その辺のところとギャップがあるので、プラットフォームを定義してその上でやりましょうというのが現状普及しつつあるというふうに認識しています。C言語ベースの設計も現場で注目されつつありますが、まだまだ少ないかなと認識しており、徐々にというところです。ツールが出てきて、それをポンと渡されてもなかなか使えないということで、ツールの実力の評価やどういった観点で評価すればいいのか、どういうふうに考えたらいいのか、どういうふうに運用すればいいのかといったことも考えたいという背景があります。そこでシステムレベルの設計フロー、どういった技術や思想や思索を用意しておくかといったことを現状のツールベースで評価しました。SLD研究会の設計フローをベースにして議論を進めました。現状の問題として、ハードウェアのシミュレーションは大事なのですが、シミュレーション時間が長くてなかなか終わらない、また、大きなハードウェアを作ると規模が大きすぎて全部検証しきれない、検証するのに工数が多すぎるし、ある工数で間に合わせようとすると品質がどうしても落ちてしまう、さらに、ハードウェアを作りましたと言っても、それを既存のハードウェアに適用するのに手間がかかる、また、設計空間探索という面からは単純なトップダウンの設計だとなかなか解空間が広すぎて絞り込めないというところが問題となっています。そこで、設計の解空間が絞り込めないという問題は、現状では仕方がないため、これについては妥協し、残りの3つの問題について、HW/SWの協調シミュレーションの処理時間が長いということについてはレイヤを意識したシミュレーションモデルの使用を推進しましょうという提案をします。ハードウェアの実装設計に手間がかかるという問題には動作合成ツールが使えるようになったのではという仮定の元に問題点指摘とそろそろ使えるのではという提案になっています。最後の問題については今までシミュレーションベースでやっていたものをアサーションベースもしくは形式検証を使う技術を積極的に利用してシミュレーションベースを補完していきましょうという提案になっています。まず、HW/SWの協調シミュレーションについて、目的はシミュレーション時間の短縮です。ハードとソフトのインターフェースを早い段階で検証し、ここでのミスをなくして効率よく開発をしたいということが非常に強く望まれています。また一方でハードとソフトのそれぞれの設計規模も増大しているので、全部シミュレーションするには時間がかかります。HW/SWの協調シミュレーションツールというのは出現しつつありますが、そのツールを使って何が検証できるのかといったあたりがあまりはっきりしないといったところが問題意識としてあります。そこでこれらの問題に対する解を与え効率的なシミュレーション運用方法を考えます。動作記述などは研究機関に任せ、ここではどうやってツールを使うかということにフォーカスを当てます。最終的にマルチレイヤでのハードとソフトの協調シミュレーションを行うことを提案します。ここでは保証される精度と保証されない精度を定義したものをシミュレーションレイヤと呼びます。実際は開発の状況によってレイヤの定義は異なりますので一概にこれが１つの答えとは言えません。ここでは４つのレイヤを用います。いくつかのレイヤに分けると、上位のモデルについては速いシミュレータで動作できます。細かいモデルは遅くなります。こういったものを考慮してレイヤモデルを作りましょうという提案になります。これを背景に９社９ツールのシミュレーションツールをカタログスペックレベルで調査しました。調査結果の表を見ると分かりますが、ツールはどれが一番いいということは一概にはいえないのですが、マルチレイヤで行うならこれがいいというようなものはあります。まとめると、HW/SWのシミュレータの課題として、検証できる精度が異なります。なので検証用途ごとにシミュレーションモデルを変えましょう。シミュレーションモデルにはトレードオフがあるので十分に考えて効率的に実行しましょう。シミュレーションレイヤを定義する際に、保証されない精度を明確に定義することが大切です。次に動作合成です。動作合成はハードウェアの実装を自動化したいという願いがあります。C言語ベースの開発によってシステムレベルの記述と検証の効率化が期待されています。しかし動作合成ツールを現場使うほど実用化は進んでいません。そこで EDAベンダのツールについてどういった改善項目があるかを検討しました。動作レベルの定義をここではレジスタ記述の有無とします。動作合成ツールはここでは少なくともレジスタ割り当てが自動的に決定できるツールとします。これについてカタログスペックでの評価をしました。ここでは並列性の記述とスケジューリングの記述が重要となります。研究的にチャレンジングな部分としては並列記述の合成、パイプライン記述の合成、自動的にスケジュールする機能、ブロック単位での並列化の機能が注目されています。前半部分については揃ってきていますが、後半の並列性やパイプラインの記述の部分はまだまだ研究の余地があり、ガイドラインのようなものが必要になります。最後に、ハードウェア検証の適用化に関してです。大きなハードウェアを作るとLSIの設計工数の70％以上が検証になります。現在はシミュレーションベース検証ですが、現実的な解としてアサーションベース検証で補完していく必要があります。これはデザインのある属性を仮定してそれをチェックするものです。これをどのようにやるかということについては動的検証手法と静的検証手法があります。使い方としては自分達が作ったブロックの中を検証するものと、自分のものと他のものをつなぐ部分が正しいか検証するものがあります。これらを分けて行う必要があります。PSLが多くのツールでサポートされています。アサーションベースの検証は検証危機を緩和する有力な方法です。網羅性も高いので検証品質の向上が望めますが、スケーラビリティに問題があります。アサーション検証のガイドラインが必要と思われます。＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝大塚氏(富士通)：モデリングに関する調査です。モデリングに着目したのはフローを用いた時、各フェーズでどのようなモデルを作ったらいいのか、それをどのように下（のレイヤ）につなげていくのかという問題があるからです。機能決定のフェーズにおいては実装方法を考慮しないでシステムの機能を定義したり検証したいという要望があります。アーキテクチャ決定のフェーズでは機能を複数のブロックに分割し、分析して最適な処理量を決定したいというものです。そこで計算モデル(MoC)に着目しました。ここで着目したいのはシステムの動作仕様を形式的に定義し詳細化するためのフレームワークとして取り上げます。MoCを用いることと対象システムに適合させることでモデル化の容易性や設計品質、設計生産性が向上するのではないかと期待されます。系統図に記した10種類のMoCについて調査しました。MoCの特徴を、アンタイムなモデルなのかタイムなモデルなのか、同期・非同期、プロセス間通信の仕組み、割込みの有無、プロセスの活性化ルール、階層構造の指定の仕方、プロセスの状態、決定性があるか、デッドロックの検出、静的なスケジューリング、リソースシェアリングについて考えられるかについて比較しました。各MoCがどのフェースでどういったことに適用可能かについて検討しました。各項目について考察しました。提案と主張として、各MoCの特徴を正しく理解することで品質、生産性が向上します。それぞれ違ったものの相互補完が重要になってきます。課題は要求仕様定義から機能決定につなげる技術、MoCとアーキテクチャ生成をうまくつなげる技術が望まれます。ベンダや研究者への期待として、MoCに関する調査、研究を活発化していただきたいと思います。また、MoCの利点を活かしたツール開発と実用化、MoCの選定ガイドラインや記述ガイドラインの策定が必要だと考えます。＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝荒木氏(インターデザイン・テクノロジー)：消費電力見積もりに関する調査と提案をいたします。背景として、消費電力見積もり技術へのニーズがあります。これは携帯情報機器などの発展によりSoCの低消費電力への厳しい要求があるからです。現状としては、ハードウェアの回路設計で低消費電力化しようというものが主流です。しかしシステムレベルで低消費電力を実現をしたほうがよいと言われています。システムレベルでどういった低消費電力のアプローチができるのかということを調査しました。1つのアプローチとしてはHW/SWの最適な分割というものです。2つ目はCPU のインストラクションのレベルで低消費電力化しようというものです。3つ目は動作合成の中でHWの消費電力をできるだけ下げる動作合成をしましょうというものです。 4番目はメモリのアクセスに伴う電力消費を低減させましょうというものです。その他にバスにともなう電力消費の低減するアプローチ、動的にブロックごとに消費電力を変化させるものもあります。見積もり手法の分類について、プロセッサ、カスタムHW、バス、メモリそれぞれの消費電力を見積もるというものがあります。ツール調査と見積もり技術の適用性検討を行います。見積もりには機能決定とアーキテクチャ決定という2つのフェーズがあります。機能決定の見積もり適用性検討は、前提として設計情報システムの機能記述であること、必ずしもシステム全体の機能記述が存在するわけではないとします。考えられるシナリオとして、プロファイリングでファンクションな仕様を決めて、全体的なプロファイリングして、その結果、機能定義をフィードバックします。ツールを使うメリットはありますが、問題点もあります。ソフトのコンパイラの最適化をするがハードウェアに実装した場合にうまくいくのかという疑問があります。ですから、どこかでハードウェアの最適化を行わなければならないと考えます。また見積もりの精度は、絶対値として消費電力が見積もれるわけでなく相対値で見るわけですが、どの程度精度が保証されているのかという課題があります。アーキテクチャ決定における適用検討として、カスタムHWの低消費電力を行うツール、アーキテクチャマッピングの最適化を行うツール、HW/SWの最適化を行うツールがあります。これらを組み合わせて使うと効果があると考えます。検討する点として、流用設計が基本になるので、言語設計を最適化すること、プラットフォーム自体を変更するということが考えられます。まとめとして、論文調査を行いました。後半では機能決定とアーキテクチャ決定の検討を行いました。カスタムHWに関する部分が問題となっています。また見積もりモデルを誰が作るのかということも課題です。＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝黒坂氏(NECエレクトロニクス)：発表全体のまとめを行います。今回は要求仕様定義、機能決定アーキテクチャ決定、実装設計へのインターフェースや計算モデルの分析、消費電力見積もり技術の検討を行いました。研究者の方々には課題を押さえていただいて研究していただきたいと思います。要求仕様の定義の工程については我々も手薄で課題として残っています。発表を終わります。＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝以下質疑応答 Q: 富山氏(名古屋大学) 要望ですが、アンケートをしてできると答えても実際は制限がある場合があるので、ツールの調査をされる際に実際の例を多く与えてそれが合成できるかを調査していただきたいと思います。小林氏実際の設計現場で使えるかという調査はされていませんか？ A: そこまではできなかったのが現状です。システムレベル設計をフルチップでやっているところはまだ少なく、若干EDA部門に近い部分が評価をやっているところが多いので、まだまだという現状です。色々新しい技術を提案していただける段階にようやくはいってきたのだと考えています。 Q: 村岡氏(STARC) 最近、開発側ではなかなか受け入れられないという状況があります。今回の調査は誰に対してなのか、開発者に対してなのか、ユーザなのか、EDA部門なのかというあたりを教えていただきたいと思います。 A: JEITAの活動としては標準化なら標準化団体、EDAならEDA団体に広く訴えていくのが活動の主旨になっています。実際に設計を担当している人たちに対して広く紹介していくという意味もあります。今日の発表の中では課題として皆様に訴えたかったというのも発表の主旨としてあります。 Q: HWモデル・SWモデルのレベル分けの話がありました。会社でもシミュレータを使っているのですが、開発の初期段階では抽象的なレベルでの設計をしますが、HWもSW も資産がありそれに追加していくというのが現在の開発手法です。少し抽象的なものを追加していくような、混在できるものがあったのでしょうか。また、LSIだけでなくモータなどのメカも含めた調査はされていませんか。 A: 我々の調査でモータの動作と電気側とのやりとりは今回は対象としていません。 SoCの設計について調査したというのが2点目への回答です。1点目については、RTL とCとの混在など既存のモデルとの混在は必ず要求されることです。混在環境というものは出現しつつありますが、やはり上流設計で書いて落としていくのが一番いいのではないかと考えます。モデルを何度も書くのではなく、そこを自動にし、落としたときの品質を保証するのは大切であり、検証について何をどこまでやりたいかをきちんと押さえておく必要があります。