分科会セッションB4 「ソフトウェア屋はコデザイン技術に何を期待するか？〜パネルセッション延長戦〜」 [参加人数] DAシンポジウム約5名 SWEST 約40名・隊形はコの字型(約20名)と、その周囲に約20名。・混み過ぎず空き過ぎずな座席の埋まり具合・雰囲気は数名の限られた方で討論。時々その他の方が意見。 =============================================================================== 議論のポイント =============================================================================== 1. コデザインの対象となる「システム」とは何か？ 2. コデザインが必要なのはハードウェアとファームウェアであって、ソフトウェアは　関係ないのでは？　ソフトウェアが関係ないというのは本当か？ 3. 上げたいのは実行効率か？設計効率か？信頼性か？ =============================================================================== 1.コデザインの対象となる「システム」とは何か？ =============================================================================== (例：携帯電話のシステムダイアグラムを書いてもらう) 　->SWとHWで対象とするシステムは大きく異なる (HW) CPU・メモリ・バス・CDMAの変復調などの配置といったデバイスレベル (SW) ベースにHWがあり、OS・TCP-IPスタック・ブラウザ、電話帳管理といった機器　　　　レベル・コデザインすべきシステムはどんなシステムか？　->今、自分がコントロールできる範囲がシステム　->外部と内部のインターフェースの定義がないとシステムの範囲を定めることができ　　ない。　->(HW)箱、LSIやFWなどを含むメカ　　->大きなシステムになるといくつかの部分に分かれる。分解した一部の設計をする　　　人と全体を設計する人では当然意識するシステムも異なり、一意にシステムを定　　　義することが出来ない。どのような目的で設計するのか？・アサンプション(外部条件)を定義しなければ問題の定義すらできない =============================================================================== 2.コデザインが必要なのはハードウェアとファームウェアであって、ソフトウェアは　　関係ないのでは？ =============================================================================== ・ソフトウェアが関係ないというのは本当か? 　->正しいと思う。　->性能を上げるためにはHWとFWで考えているとダメ。全部考えてこそシステムレベル　　デザイン。　　スループットなどを考えると、全部を考慮しないと議論できない。　　->どこまでが制御領域か? 　->コデザインがない場合、HWがないとSWの開発ができない。並行開発のためにもコデ　　ザインは必要。（チェアマン）・デバイスとデバイスドライバ(HW-FW)間のコデザインは成立するが、SW屋が厄介に思　っているのは全体のシステムのコデザインではないか？アプリケーションも含めた時　にHWのコデザインは必要なのか？　->木を見て森を見てないのか？それで、最終的な仕様に問題を与えないのか？・HW屋から見るとSW屋は非常にずるい。どのSWの領域が(FW、組込みソフト、アプリケー　ション、コンテンツなど)HW-SWコデザインに向いた領域なのか？　->FWは向いている。アプリケーションまで含めるとどうなのか？　->本当はHWとSWを比較したらいけないのかもしれない。本題はどのようにシステム設　　計をうまく作るかではないか? 　 ->コスト(機能上、時間制約など)の問題(安いコストでまっとうなモノを作るには？) 　 ->SWはメモリーがコスト(->その他に設計コストもある) 　 ->ADSLの場合は、制約条件ではなくて目標(別にモデムを小さくする必要はない)。　　　制約条件と目標を分けて考える必要がある。少々落ちても大丈夫なスペックと、　　　落としてはいけないスペックの評価関数上におけるトレードオフ。　　 ->最低限の仕様は製品として価値を残すために存在する。仕様はconstrainedに　　　　与えられる。・(HW)コスト(プライス)、デリバリー、ファンクションの充足率を考慮してシステムと　して何を作るべきか定義される。 --スペックは一意に定められているわけではない。　(質問)プライオリティはついているのか？　　->Q(Quality),D(Delivery),C(Cost)。コストは上がっても常に良い物を作るように　　　指示されている。ただ、上司の本音は一ラインでやって欲しい。　　->最近の日本のベンチャーはDQCではないか？　->会社ごとで設計論(どこに重点を置くか)は変わってくるだろう。＜＜話の内容がそれたので2.に戻す＞＞・HWとFWはコデザインしなければならない。・アプリを含めて考慮するべきなのか？　->考慮すべきだと思う。　->定義によると思う。定義にあわせるのが重要。　　->アプリによって制限されるHWのアサンプションがあるのでは？アサンプションが　　　明確になることもあるが。 ->個人で考えているレベル(チップレベル、機器レベル、インフラレベル)が違う。　　レベルのフェーズをあわせる必要がある。・SWでは機器レベルのコデザインを期待しているが、HW屋からはデバイスレベルのコデ　ザインしか出てこない。両者の期待は外れているのではないか？　->デバイスドライバとアプリケーションは切り離せない。　->UNIXのようなデバイスドライバの抽象化を行うと、デバイスドライバの作りが決ま　　り上と下の切り離しが出来る。　　->ソフトは同じであっても選択するOSなどの違いによりパフォーマンスは異なる。・そもそもOSが生まれたのはHWの抽象化。組込みソフト・システムでは、コスト(重み) 　がちがう(フルスペックのOSが必要ではない)。　HWとFWのコデザインでの性能を測る単位はデバイスで、SWとデバイス間のコデザイン　が本当はあり、そこで性能を測るべきではないか？　->ここでのFWは(MPEG解凍チップなどの)デバイス中のソフトウェア(デバイスドライ　　バではない)。SWから見るとFWが入っているのかも判らない。＜＜議論が食い違っている＞＞・どこをシステムとして捉えているのか？・大きなシステムを考えるとOSの役割を議論できるが、SOCにOSは出てくるのか？OSの入　る範囲は(今の議論の)もっと上流。　->HW屋は自分たちが将来に描いている青写真をシステムとして捕らえているのではな　　いか？　　--200〜300kゲート程度の回路+RTOSが1チップに載っている実例もある。・FWの定義は難しい。FWの定義をした時点で既にHW、SWの定義が決まる。・何をHW、SWで作るか？HWが決まれば、SWとの切り分けが決まる。何をHWにするかの議　論で両者の関係はある。　(HW)ある実現したい処理があるとき、一部のホットスポットをHW化する方法もある。　　　時間的な条件などによって切り分けは変わる。本来は上の方(機器レベルぐらい) 　　　から見るべきではないか？　(別HW)ボトルネックの解決としてHW化する。＜＜再帰の場合のSWからHW化の議論＞＞・最大値が分かっていない部分のHWは書けない。・HWで制限(例えば再帰の回数)すれば、両者ともやりやすくなるのでは？　　->実装できる部分とできない部分はあるが、頑張ればHWでも実装できるのではない　　　か？・SWでできることはHWでできるが、HWはリファインの自由は利きにくい。SWでは変更に　よるコストが大したことなくてもHWではコストが甚大になる可能性もある。（まとめ）・いつコデザインがはじまるか？　->ボトルネック(Performance, Cost, Deliveryなどの面で)が見えた時にコデザイン　　の変更が行われる。 =============================================================================== 3.上げたいのは実行効率か？設計効率か？信頼性か？ =============================================================================== (チェアマンの動機）・SWの目的はHWの非依存(HWの抽象化)、しかしコデザインはSWに最適なHWを設計する目　的。SWはHWが手間をかけて生み出した性能を無駄遣いして設計効率を上げてトレード　オフをしている。検証も設計の一部。　->携帯電話のステップは100万ステップのオーダー。1社の銀行のオンラインシステム　　も100万ステップのオーダー。しかも携帯電話のステップは上昇中。　->コンフィギャブルなプロセッサは作りたくない。各構成を検証しなければならない　　(できない)。検証コストが高いのにその検証コストを更に高くするのか？ITRONで　　は、コンフィギャブルなプロセッサを使用することは少ない。　->SWはメタのレベルで抽象度を上げると共通にしかもきれいに書けるかも知れない。　　SW側はインスタンスレベルから階層を上げてメタレベルで書く(検証する)べきでは　　ないか？　 ->抽象度を上げたところで実は商品として成立していないのではいけない。その上　　　でいかにお客が満足する商品を開発するか？そこに向かって知恵を絞るのがコデ　　　ザインの本質ではないか？　->実行効率、設計効率などは商品、コストにあわせてプライオリティ(Q,D,C)は違う。　　一般論ではないと思う。　　->CADとLSIでもコデザインの意味は違う。ツールや過去の資産などによっても違う。・HW屋サイドから出てくるコデザインは実行効率を上げるためのコデザイン？　->実行効率を落とさずに設計効率を上げるのがコデザイン　->短期間で実行効率を上げるための(設計効率を下げずに実行効率を上げる)コデザイン　->並行開発もコデザイン・Cは最初なのか？最終出力なのか？　->Cは実装技術(Cが前提で他の実装技術は捨てている)である。Cで記述することにより　　幅が狭まる(本来のニーズにもっと適した記述方法は他にもあるのでは？)。 ->STARCでのVirtial Core Design Systemプロジェクトでは、Cを用いて仕様(ソートな　　ど)をライブラリ化しようとしている。インプリメントは設計者に依存する。実現し　　たい部分のみを書けるようにしたい。　->HWエンジニアはCでプログラムを書けないがCは習っている。Cで書く時にはインプリ　　を考えてしまう(メモリ、プロセス管理など)。 SW屋はアルゴリズムを書いている。 ->C以外に適している言語がなかったからCになったのではないか？自然言語より誤解　　がない。ただし、Cが一番良いとも思っていない。・SW屋の中での仕様記述と実装の違いが明確でないのでは？手続き型の言語で書くのと、　表形式で書くなど諸々の表記法がある中で、手続き型言語を使う理由はどこにあるの　か？　->手続き型言語はシーケンシャルな記述。パーシャルオーダーでしかない。手続き型　　言語は抽象度を削減してしまうから、スペックの記述にはちょっと・・・。　->言語の記述し得るスキームにマッピングしてしまう。 --Cを使用すると、書きすぎになってしまう(実装も書いてしまう)。状態遷移図です　　べてのシステムが書けるわけではない。 Cに替わるスペックを記述する仕様記述言語が現状ではまだない。・UMLのように図式で表すと、最終的には図式で側面を書いて(2種類ぐらい)それをイン　プリする形になると思われる。しかし、インプリに落とす所などは議論が残っている。 ->UMLはモデリング言語。モデルから言語には落ちない。SW屋では仕様記述はあきらめ　　ている現状がある。モデリングで妥協。　　HW屋は遅れてきて勝手に騒いでいる。・HWの設計手法(言語化)は今までのSWの手法を追いかけている、という捉え方もできる。・HW屋は自分のスペックをスキームが全く異なる手続き言語と宣言型言語という2種類　の形で書いている。 (チェアマン) ・話をまとめるつもりはないが、過去に比べるとHW屋とSW屋の話がかみ合っていた。 [感想] 以前のSWESTや関連記事に比べると両者とも会話がかみ合っており、HW屋とSW屋で激しい議論を交わしてきた成果が少しずつ出てきているのかなと感じた。ただ、やはり一部の方のトークを周囲が見ているという雰囲気だったので、もっと他の参加者が参加できるような内容になれば、分科会の一体感が増すのではないか？ (分科会B4 以上)