================================ パネルセッション「システムLSI設計と組込みソフトウェア設計の協調」 -------- ディスカッションに一部抜けがあります． -------- A会場でおこなわれた．参加人数はほぼ満席状態． -------- 議長：門田氏 −長く論じられてきた協調設計−視点・論点はどこに？・システム設計方法論・ソフトウェア開発効率化・単なる主導権争い・エンジニアの意識改革三好氏（システムLSI設計） ○C言語によるシステムLSI設計の実例（ADSL Transceiver LSI） −シミュレーション・デジタル部，アナログ部それぞれのブロック図・通信路モデル（C言語）・ノイズモデル −DMTDP-LSI Hardware アーキテクチャ・一般的なDSP ・TDP，FFT/IFFT，FDP ・150MHz（バス75MHz） −開発フェーズ 1. 評価条件のCモデル化（1人）ノイズモデル，通信路モデル 2. 方式，アーキCモデル設計（4人）アルゴリズム開発 Hard/Firm機能分割 3. タイミングモデル設計（5人） Cycle Accurateレベル｜｜ 4. RTL設計 5. Firm設計・3，4は平行して同一人物が開発・ハード設計はVHDL −ハードの協調設計化 … Hard/Firm結合度合い・方式Cモデル ↓ ・全体の処理量を把握 ↓ ・パラメータの自由度が必要？→ Firm化 or 専用Hard化（小型化，低消費電力） −まとめ・完全ハード → 主信号系ハード，制御系ファーム → すべてをファームという時代の流れにあわせていかにハードウェアからファームウェアへ効率よく　　　置き換えるかが協調設計「自由度」と「処理性能，消費電力」のトレードオフ Q. 方式モデルからアーキモデルへの書換えの具体的なやり方は？ A. なんとなくだいたい Q. ここが本質かなと思う Q. ファームというのはデバイスドライバ？ A. ハードそのものをファーム化したイメージ．ソフトはソフト Q. 言語は？ A. アセンブラ Q. 開発フローで戻ったり回ったりしないか？ A. ほとんどしない．そのステップ内でなんとかしている芝下氏（ツールベンダ） ○システムデザインフローについて [仕様の記述・検証] ↑ ↓ │コ・デザイン ┌─——— [トレードオフ解析] ─———┐ │ │ │ │ │ [新規設計部分のファンクション記述] │ │ ↑ ↓ ↓ ↓ ↓ ↓ │ [C，アセンブリ] [ビヘイビア合成，RTL，ネットリスト] │コ・ベリフィケーション ↓ ↓ ↓ ↓ │ [ソフトウェア] [ハードウェア（アナログ，デジタル）] ↓ −仕様の記述・検証とトレードオフ解析・性能解析用とインプリのモデル（ハード・ソフト）それぞれでどのくらいの時間がかかるか？のみのモデル・仕様記述最上位設計では実処理は記述しない（パフォーマンスモデル）ファンクション記述／アーキテクチャ分離・仕様の動作検証ソフトウェア屋からは抽象度が高すぎる？ −仕様検証・仕様段階でのエラー発見・ソフト・ハードのトレードオフ・IPの選択と組合せ −インプリメンテーション・コミュニケーションシンセシスとI/Fシンセシスにより全体の接続を自動生成・IPはインプリのモデルのインサーション・ハード：RTLレベル．Verilog，VHDL−IPベースなら処理時間が見積もれる・ソフト：C ・新規部分はビヘイビア合成でRTLのHDL生成or手でRTLに落とす信号処理に特化したツールで商用化が先行 ↓ どの程度正しいか協調検証…コデザインの結果を速く確認結果をパフォーマンスのモデルにフィードバック Q. タイミングの検証はできるか？ A. 上位レベルで抽象的なタイミングを検証する．割込み等のレベルは協調検証で．石山氏（システム・ソフト設計） ○協調設計：求められるもの[ソフト／装置開発者の視点] ・長年，組込みソフトを書いてきた→ソフトとハードの連携が取れていない −商品開発の流れのおさらい・経営要求が上にでてくる現実制約 −設計…いろいろな人が集まって議論しあうことが重要 −協調検討の例主要構成要素，基本構成の検討 ↓ その後の全体的な構成の検討 −LSI屋のコデザインへの反発〜Cライク言語を入力とした設計〜・ソフト屋にとってCは最終出力 Cは設計結果であって仕様ではない実装は終了しており，あとはささいな部分のみ −当面のアプローチ〜仕様記述は（当分）できない・通訳の育成・相互理解・システムアーキテクトの育成・協調検討の機会（ハード／ソフト）・相互交流（研究者／実務者） Q. 発表者はどのような立場か？ A. ソフト屋に軸足を置く装置設計者だが，LSI屋と言っても良い福田氏（大学） ○基本ソフトウェアからみた立場 −システムソフトウェア研究の現状・研究者の絶対数不足 OS，コンパイラ大学教育，評価計算機工学コア分野から逸脱 ↓ 意識改革が必要・組込みシステム研究者の不足 −HW／SW屋さんの意識のずれ・HW屋さん目に見えるもの（ハードウェアのコスト，性能，電力）・SW屋さん目に見えにくいもの（開発コスト等）ハードウェア非依存にする技術の歴史 HW屋さんは，与えられたアプリケーションプログラムをいかに最適設計するかを　　考える！携帯電話等，走らせたいプログラムが一意ではないことも −従来のコデザイン・対象：応用プログラム（多くは単体）・応用プログラムとハードウェア・OS不在 −システムSWの課題・開発効率と実行速度のトレードオフ・保護，セキュリティ −コデザインにおけるOSの位置・コデザインにOSを取り込む最適設計の自由度拡大新しいシステムの可能性・リターゲッタブルOS −OSを取り込んだシステム設計／方法論の確立・分担の見直しハードウェア，システムSW，アプリケーションプログラム垂直方向の分業化における協調設計ディスカッション　協調設計のニーズはあるか？それはどのようなニーズか？コデザインがうまくいかない，というのはSW側だけの意見なのか？　苦労はデバイス周りの制御．ちょっとくらい違っても動くHWが欲しい．　例えばイシの説明に来るHW屋に，バス幅は大丈夫か？キャッシュをはずしたらどの程度の性能がでるのか？を聞いても返事がない．お互いの立場が良くわかっていない．性能や電力の仕様は書けるのか？　性能見積もりはだいたい頭の中でやり，プロセッサを組んでみて足りない部分は専用HWとする．なるべく設計フローでぐるぐる回さない　用途が決まった部分以外ではSWが対応しきれずにタイミング等が合わなくならないか？　LSIの中も似ていて同じような動きをしている．　ADSLは仕様がきちんとしているのか？不確定要素はあるか？　通信線に関してはすべて決まっている．　HW屋はCがスタート，SW屋はCがゴールという印象．　Cで書くのは始まりか？終わりか？　作りたいモノをどうやって表現するか？という手段としてC言語がある．　論理的思考をしなくても書けば動く言語が必要．　使用記述言語がいろいろあるのになぜCなのか？Cでスペックを書くのは最悪だとSW屋は思っている．　Cが良いといっているわけではない．UMLはHW屋しか知らなくて，共通に知っているのは Cしかないというのが実態ではないか．　仕様は仕様書なのでは？アルゴリズム中心ならCでも良いし，仕様・規模による．システムをどのレベルで見ているかによって言っている意味が違うのでは？　上流設計と協調設計はどうリンクしている？　欲しいものをきちんと書く，それをどうやって書けばいいのか．　システムレベルデザインを標準化しようというグループがあった．VerilogとVHDLの争いを終わらせてシステムレベル設計をうまくやろうとし，ひとつの言語ですべてをカバーするのは無理だから，それぞれに合う言語を使ってシステムを設計しようとした．それぞれの橋渡しのセマンティックスを考えた．SystemC，SpecCの登場により世論がCベースに流れてしまった．　DA側の人はLSIの実現性に関してはCがスタート．実際はMatlabを使ったりもする．それぞれに合った言語を使ってブリッジする方法を考えるのが良い．　DA側の意見はよく整理されているが，そのプラットフォームから出てきたHWがバグだらけで，それはソフトで何とかして欲しい，というのがSWの不満．これはツールで何とかなるものか？バグは防げないという認識がある．〜システム・アーキテクトらしき人はいる．協調設計は過渡的な状況だ．仕様を決めるということと設計するということは違う．決めた仕様をどうやって実現するかが設計だ．意識上は分離されるべきだ．以前，あるチップでひどい目にあった．2種類選べればいいところを，余計な機能がごちゃごちゃついている．気を利かせたつもりかもしれないが，余計なサービスを提供されても困る．システムは最後はソフトとして外から見えてハードは隠れるのだから，どういうサービスをするモジュールなのかということを考えて設計して欲しい．パネラーだけでなく，会場の参加者からもさまざまな意見が出始めたあたりから，活発な -------- 前半は，パネラー同士によるディスカッションがおこなわれたが，半ばからは会場の参加者も参加する形で進められた．このあたりから議論は盛り上がりを見せ，予想通り（？） SWEST参加者とDAS参加者が意見を戦わせる構図となり，白熱した．結論らしい結論は出ないまま，このテーマは分科会へと持ち越された．