分科会B4
「ソフトウェア屋はコデザイン技術に何を期待するか？ 〜 パネルセッション延長戦 〜」
チェアマン 高田広章氏（豊橋技術科学大学）
会場規模：80人程度
全体人数：47人
内訳：DASから5人程度 SWESTから多数
(議論に先立ち、チェアマン(高田氏)から「議論のポイント」を提示)
実は、SW技術者とHW技術者で全く違う
ここですれ違いになっている
なら、コデザインするべき対象は？
そもそも、FWとSWを分けてしまえば、SW,HWコデザインなど必要ないのか？SWが関係無いのは本当？
(この2つのポイントをもとに議論が展開される)
たしかに、コデザインの中でヒューマンインタフェースまでは気にしていない場合はある。
しかし、性能を上げようという議論の中ではFWだけで考えているとだめである。全部考えないといけない。区分けしてはいけないと思い立った。
割り込みのターンアラウンドタイムならいいが、スループットで考えるなら、共通資源使う対象全てを考える。
（ポイント１に関しての意見）
自分のコントロールできる範囲をシステムと言いがちだが、全体がシステムなのでは？
コデザインが無いと
ＨＷができてからＳＷ
と言う流れだから問題なのであって、同時進行と言う意味でのコデザインは必要。
技術者の制御範囲に戻って
外部条件(アサンプション)と内部条件(アサーション)が仕様であり、それ以降が実装である。
全部がシステムと言うのも分かるが、下位のレベルの部分を扱うエンジニアとしては対象を絞らないと厳しい
システムと言ったときに、その外側を考えますか？インタフェースを定義しているのは図。
その中で安く作るのがエンジニアリングの本質。
ユーザーインタフェースはシステムの外部なのか内部なのか？この視点で考えが変わってしまう。
たとえば、携帯だったらどうだろう。筐体まで入る。ユーザーインタフェースはボタンの押し方や筐体の頑強性も入る。
しかし、「ここをやれ」と言われると話は変わる。
いくつかの部分に分解され、そのうち一部を「やれ」と言われる人と、全体を見る人の意識が繋がっていない。
この話ばかりすると議論が進まないのか。でも、だからと言って「システム」の範囲広げても議論できない。
昼の議論では機器レベルの人とデバイスレベルの人と２とおりの捕らえ方があった。
DASの対象はシステムＬＳＩ...だからデバイスレベルになる。
デバイスと言う領域をシステムと捉えるとデバイスとドライバ(ファームウェア)だけがコデザインになって、いままでのコデザインが成立してしまう。
もっと大きいシステムになったときに厄介なような気がする。
木を見て森を見ないようなことで全体に影響がないのか？
最終的な仕様に影響が出ないと言い切れるなら問題無いが、携帯と基地局のインタフェースは考えなくてはいけない。
もちろん、考えに入れる。コデザインの対象に入らないと言う意味の話である。
でも、ほんとうにそれでいいのか。
ファームウェアもアプリケーションソフトもコンテンツもソフトウェアである。
（ＳＷ、ＨＷの）コデザインの中のＳＷの範囲。つまり、どこをSWと捉えるかをはっきりしないとＨＷ屋とぶつかる。
（例）ヘッドホンステレオ
磁気テープと再生機構(アルゴリズム？)のコデザインということを考えるとどうだろう。PHILIPSの考えたことをいまさら変えようなんてことは誰も考えない。
アプリケーションまで含めるべきか？
そもそも、本当にやりたいことは何なのだろうかを考えれば、「どうやって物をうまく作ろうか」と言うことを考えたいはず。
ならば、ＨＷとＳＷの区別をすることがいけないのではないのか。システム設計をどうやってうまくやるのかと言うことを議論したいのではないか。
そのとおり。コストが安くてちゃんとしたものができればいい。
(論点が「コスト」「性能」に広がる)
端末の最適設計とは、時間的にも満足してコストも小さくすること。ソフトはメモリ(コスト)に関わるのでは？
ある条件の範囲でどのようなものを作りたいというのがあって作っているはず。コスト、時間などというものは目標になっても制約になることは実際無いのでは。
組み込みの世界では納期に間に合わないからスペック削ったりして間に合わせている。
製品の評価関数の中で、落としても良い部分とそうでない部分をどう捉えるかで決まるのは。メモリもその1つの要素だと思う。
いくつかの評価関数の中でのトレードオフなのである。
でも、最低限守るべきスペックがある。今よりは良くしなくてはいけない。だから仕様は制約である。
ソフトで性能を上げようとしても、余り大きいのはまずい。結局トレードオフになるのではないのか？
ＨＷは安くなったが、ＳＷ設計コストはむしろ無視できない。
ものは量産。ベースをつくるコストは高くても、結果的に安ければ良い。
しかし、量産もピンからキリまである。微妙なバランスである。
ソフト開発にお金かけなきゃソフトは出来ない。でも、かけられる金額は変わらない…
コスト関数の要素として、コスト(C)、デリバリー(D)、ファンクション(F)の3要素
自分の会社では現在、、この順に重要とされている。
スペックは決まっているのではなく、コスト関数である。
自分のの会社はQ(ファンクションや信頼性や性能も含む)、D,Cの順
本当は順位などつけないでやってほしいけれど、実際はつけないとやっていけない。
これに関しては、会社のカラーが出るものだと思う。
（論点が広がってきてしまったので戻す）
われわれのやりたい「設計」って何なのだろう？
アプリまでコデザインしなくてはいけないのか？
場合によってはアプリソフトによって制約されるアサンプションもある、
たとえば、ボタンの同時押し数、画面表示など。だからアプリまで考慮するべき。
アプリケーションが直接使うリソースのＨＷと、そうでないリソースのＨＷで話が違うのでは。
後者ならコデザインの中からアプリケーションを忘れて良い？
デザインはどこまでのことを言うのか？
どこまで制御範囲に入るかで、アプリをコデザインに含むか？
例えば、携帯電話のゲームアプリは？
ＳＷ側は全体を考えているのに、ＨＷ側から出てくるコデザインがデバイスレベルだから落胆しているのでは。
デバイスドライバレベルも考えるのだから、アプリも考えなくてはいけない。
（HW,FW,SWの切り分け、棲み分け）
たとえば、UNIXのように、デバイスが抽象化できていればアプリとデバイスドライバは切り離せる。
ＯＳが生まれた理由はそもそもＨＷのイメージをSWから切り離すこと。
組み込みの場合はコストとは違う重みもあるのでフルスペックのＯＳが必要とは限らない。
特定の組み込み用途へのソリューションは今までにもあったが、ＯＳとアプリのコデザインというのもあるのでは？
性能が悪いのがアプリの書き方が悪いかもしれないし、相性かもしれない。それを改善するとき
ファームとハードをコデザインした場合は性能を測る単位はデバイス（FW+HW)。
つまりデバイスとSWのコデザインがあるのでは。
FWという言葉は危険。
デバイスドライバのようなものを指すときと、ＭＰＥＧチップの中身みたいなミドルウウェアのようなものを指す場合がある。
でも、デバイスドライバはCPUメーカーでなく、デバイスメーカが提供すべきでは。
ここの話の食い違いのもとは
・システムオンチップ(SoC)のシステムだどこまでのこと？
・上の話だけしているとOS屋の出番が無い。OS屋のやることは今言われているSoCのもっと上のレベルではないのか。これではＨＷのいうコデザインにＳＷが出てくるはずが無い。
SoCは実際、辞書的な定義どおりになっていない。
今のシングルチップマイコンも特に目新しくないしSoCと言えるのではないのか？
そもそもSoCを言い出した人の考えたシステムって何なのだろう？当時は「将来的にここまで実現できる」と思われていても、いまでは夢のような話になっているのでは。
とりあえず、大規模なものじゃなければ、ＲＴＯＳまで乗っけているのもある。
FWの定義は難しいが、本来ＯＳがうまく吸収すればＨＷとＳＷを分離できる（OSの目標）
でも、Ｉ／Ｏ以外の処理を行う部分もハードで作っている。（MＰＥＧなど）
このことも、HWの範疇が決まれば関係無い。
今の件について。
何かやりたい処理をどのくらいの性能でやら無ければならないという要求がある。
その1つの方法としてHW化はある。
もっとシステム全体をフラットに見なおしてそのようなことを考えれば、ＳＷとＨＷは対等になれるのでは。
アクセラレーション可能な部分をＨＷ屋はちゃんと探しているのか？
たとえば、携帯のブラウザなんかは手をつけないのか。
つけたくない。無理である。
無理と言っても、もっと考えられないのか？たとえば、その中のポップアップメニューのような部分がボトルネックになってたりしたら、そこだけ手をつけようとはしないのか。
ボトルネックだった部分を何とかすると言うのは難しい。
その処理がリカーシブだったりすると、どこまでサポートするべきか分からない。
上の件。ＨＷ屋はその気になれば何とか作っちゃうような気がする。
でも、無限大までなんてモノは作らない。
けっきょく、ＨＷとＦＷのやるべきことの振り分け方で違うのでは
ＨＷは1回作ると変えられない。
例外を考えるときりが無いので、たいていの場合を考えるだけでＯＫ(例外を気にしない)なモノはHWでやる。
いつコデザインの変更をはじめるか
いろんな（前出のＦ、Ｄ、Ｃなどの）ボトルネックが出たらやる。
（次のポイントが提示される）
前出のＱＤＣの順？...
もともとSWの歴史はＨＷ非依存にする流れだった。
コデザインはハードに最適化させたソフト…非依存の流れを依存させようと言う流れにしてしまう
これに関しては、ケースバイケースだと思う。でも、組み込みは設計効率に偏っている。
たとえば、携帯のプログラムステップが銀行のオンラインシステムを追い越そうとしている。
今のような議論がちょっと違和感感じる。上げたいのは信頼性。ちゃんと動くこと。（検証）
今フィギュアラブルプロセッサとコンフィギュアラブルＯＳがいろいろな所で出ているが、コンフィギュアラブルＯＳについて及び腰になる人が多い。それは、検証が難しいから。
では、プロセッサのときはどうする？
ＯＳがやればいい。ＳＶ(スーパーバイザ)なのだから。
抽象度をあげたところで扱うのがソフトウェアの仕事である。
抽象度を上げた所でまずクリアにするべき。
動作の裏を取って、お客に受け入れられるかがコデザインの本質。
実際、その検証はＥＤＡ、コンパイラなんかやっている。
今まで見てきたコデザイン関係の研究全部が全く言ってることが違う。だから、上げる目標が違っても当然。
汎用に適用できるコデザインは無い。いわばＳＷ・ＨＷの相互がインタラクティブに協調しようと言うことだと思う。
これをわれわれが考えていかなければいけないのでは。
（SWとHWの協調設計につての議論が続く）
今までＨＷ側から出た研究はほとんど実行効率になっているような気がする。
実行効率を上げるための設計効率なのか。つまり、設計効率落とさないように実行効率上げる。
デバイスはＶＨＤＬで作っても良いけど、（チップが完成してしまう前に）早めにビヘイビアなどをSpecCなどで見せてくれればSW側の開発効率上がる。
ラピッドプロトタイプみたいなものである。
いままでSWとHWの並行開発は忘れがちであったSW開発が早くはじめられても、HWが後になったら並行では無い。
実装の記述のおかげでその後の選択肢を狭めているような気がする。
仕様にはただ「ソート」って書けば良いのに、その中身をCで書くとそれっきりになる。
仕様を書く努力なのであって、そこに実装をかいてもしょうがない。
（仕様記述言語に関する意見）
VCDL（Virtual Core Description
System）
Cを使って仕様をライブラリ化しようと言う試みがあった。そこに「バブルソート」が書いてあっても、実装では適するものを考える。
「Cで書く」ということ自体にものすごいイメージギャップがある。
HWの人の９割方はＣ書けないと答える。でも、そのうち9割の人は学校でCを習ったと言う。
そもそもSWの人にとってＣで書いた仕様を実装するとき、またＣを書くというのがピンと来ない。
Ｃは自然言語より誤解は無いからまあ良いような気がする。
いや、仕様と実装の区別がクリアでない
その仕様を手続き志向なＣで書くのはどうかと思う。ほかに良い表現法があるはずなのになぜＣなのか？
シーケンシャルなものと、場合分けみたいなもの、それぞれに適するものがあるが、これが今は、「コンピュータで読める」ことが大事になったのだと思う。
手続き型はシーケンシャルである。[Ａ]→[Ｂ]→[Ｃ]
でも、仕様は[Ａ]→[Ｂ] [Ｂ]→[Ｃ]と言うようなパーシャルオーダーしかないはず。
Ｃで書くともともと意図しない余計な所までシーケンシャルになってしまう。
Ｃはスペックでなくてインプリメンテーションを書いてしまうからよくない。その一方、Ｃ以外に現実使えるものは思いつかないということもある。
それを提案できないＳＷ側の責任もある。
結局はＵＭＬみたいなものになるかもしれないが、図式は解釈のセマンティックスの定義が難しい。ＵＭＬはちゃんとしてあることになっている。
実際のところ、仕様の検証は、同じものの実装を二種類の表現で書くくらいしか方法が無いのでは。
ＵＭＬはモデリングなので、実装には落ちない。（情報が欠けている）
乱暴な言い方すれば、ＳＷの仕様をよく書こうといろいろ提案されたが、その場その場で使い分けなければいけないものであった。
しかし後から追いついて来たＨＷ屋が仕様記述を1つのものにしようとした…
これに関して言い訳させてもらうと、ＲＴＬが一番トップレベルの仕様記述であると思う。
今のベリフィケーションは二種類の記述したものの矛盾してないかの比較なんかでやっている。
最近のＨＷ設計者は複数の表手段を使うようなことをやっている。
1つの仕様を複数の人が同じ解釈をしてくれるかも問題。
だから、なんとなしにＣに辿り着いてしまう。
（ここで時間切れ）
机を中心に向かって丸くなるように配置。参加者の半数はその輪にいる。実際に発言を行ったのはその輪にいる人が中心であった。そのため、発言の比率としてはSW側とHW側でほぼ1対1であったようである。
ポイント2の「システム」の範囲についての議論では、特にSW側とHW側の意見交換を繰り返すうち、結論までは行かなかったが現状の把握ができたのではなかろうか。
最終的に、仕様の記述の仕方に問題があるという議論の流れになったのだが、1つの結論を導き出すことはできなかった。
過去の記録にあるように、「コデザイン」の方向性がなかなか見えてこない。しかし、チェアマンの高田氏のいうように「議論にまとまりが見えてきた」ようである。意見の食い違いは多少あるものの、発言者それぞれの立場を相互に理解して議論が進んでいたようであったため、意見交換としての意義はあったのではないかと思う。