パネルセッション１
「システムLSI設計とソフトウェア設計の協調」
Table of Contents
全体の流れ
司会、オーガナイザによるイントロダクション
各パネラーによるポジショントーク
１．三好氏（C言語によるシステム設計の実例）
２．柴下氏（システムのデザインフローについて）
３．石山氏（協調設計、求められるもの・・・ソフト/装置開発者の視点）
４．福田氏（基本ソフトウェアから見た立場）
会場も含めた討論
全体の感想
流れとしては、司会の門田浩氏、オーガナイザの高田広章氏によるパネルセッションの趣旨、論点、
全体の流れの説明の後、各パネラーによるスライドを用いたポジショントークとそれぞれのについての質疑、
そして会場全体を交えた議論というものであった。参加者の人数はDAシンポジウム、SEWST3の参加者が合わせて２００人程度(ほぼ満席)、
途中の挙手によるアンケートによるとDA参加者７割、SWEST3参加者が3割という構成であった。
司会（門田氏）
（スライド：ながーく論じられてきた協調設計）
ハードウェア/ソフトウェア協調設計について議論をする際に、ソフトウェア技術者とハードウェア技術者との認識には決定的なずれが
あるように感じる。
両者が協調していくにはどうすればよいか、あるいはそもそもに協調など必要ないのか？その点について議論を進めていきたい。
オーガナイザ（高田氏）：
視点、論点はどこにあるのかを明確にしておきたい。
・システム設計方法論？
・ソフトウェア開発効率化？
・単なる主導権争い？
各パネラーの紹介
司会によってセッションの各パネラが紹介される。
パネラ(以下敬称略）
- 三好 清司（富士通）
- 柴下 哲（メンターグラフィックスジャパン）
- 石山 康介（NEC静岡）
- 福田 晃（九州大）
各パネリストによるポジショントーク
三好（C言語によるシステムLSI設計の実例）
（ADSL Transcever LSI）
組込みシステム設計の実例の紹介を通じて、議論の足しになれば、、、
スライド１：ADSLの開発方法について
ADSLのTransceverに２つのLSIがあり、その設計の流れについての紹介がこのトークの趣旨。
ADSL：Layer1の伝送を行うもの。設計しているシステムの全体像の紹介
送信系 ー 通信路 ー 受信系
外界ノイズモデル
外界ノイズモデルに於いて漏話が発生することを考慮に入れてシュミレーションをする。
スライド２：デジタル部のアーキテクチャの紹介
スライド３：設計手法
１．評価条件のCmodel化
２．方式＆アーキCモデル設計
アルゴリズム開発
ハード、ファーム機能分割
ハードブロック分割
３．タイミングモデル設計
Hard処理遅延を考慮した入出力モデル化
４．RTL設計
５．ファーム設計
スライド４：設計手法（前スライド）の詳細
ファーム開発を強調
スライド５：ハードソフト設計
スライド６：ハード処理のコデザイン化の流れ
ファーム・ハードの処理の結合度合い
疎：設計しやすいが、効率化が落ちる（ハード性能）
密：設計困難だが効率化できる
スライド７：まとめ
通信のレイヤ１のアプリケーションの実現の方法としては、協調設計の考えからすると次の3つの段階があると考えられる。
１、完全ハード
２、主信号系ハード・制御系ファーム
３、全てをファーム
現在は２の段階にある。
私の考えるコデザインとは？：自由度と処理性能、消費電力のトレードオフ
質疑
Q.方式モデルからアーキテクチャモデルへの切り替え、その分割は？
A.うーーん、なんとなく。
Q.そこが本質なのではないか、、
Q.ファームウェアという言葉、デバイスを制御するプログラム全てを言うのか？
A.ハードそのものを書き下したもの
Q.ソフトはソフトではないか？ところでファームウェアを記述する言語は何？
A.アセンブラ
Q.開発サイクルはサイクルは存在しないのか？
A.（スライド3を参照して）（２）が出来上がると（３）を基準の位置とする。（３）から（２）へは戻らない。
Q.何回くらい？
A.４，５回
システムデザインフローについて
スライド１
特定のシステムにはとらわれずに、、、
・使用の記述、検証
・トレードオフ解析、IP、ミドルウェア、RTOSの選択
新規設計部分のファンクション記述
・ソフトウェア ・ハードウェア
コデザイン コベリケーションの差について
スライド２
ソフトとハードのトレードオフをソフトウェアで、、、
・性能解析用とインプリのモデル（ハード、ソフト両方）
性能解析用：どの程度の時間がかかるなどの情報しかない
・仕様記述
・実処理は記述しない（パフォーマンスモデル）
・ファンクション記述とアーキテクチャ記述の分離
・処理の負荷情報を対応するアーキテクチャモデルでの時間に変換
・仕様の動作検証
・仕様は正しく完全か
・デザインの全てのパーツは結合して動作するか
・記憶要因の冗長性はあるか
etc
スライド３
仕様検証の目的と作業
・仕様段階のエラーの発見
・ソフト、ハードのトレードオフ
（・インプリメンテーション）
スライド４：アーキテクチャのトレードオフ解析
スライド５：インプリメンテーション
・コミュニケーションシンセシスとI/Fシンセシス
・IP部分はインプリモデルのインサーション
・新規設計部分はビベイビア合成でRTLのHDLか手でRTL
・信号処理に特化したソフトが最近の主流
スライド５
協調検証でコ・デザインの結果を早期に確認
（実際のツールの例が示される）
質疑
Q.タイミングの検証はできるのか？
A.上位のレベルでのタイミングについてはできる。割込みなどは協調検証で。
Q.RTOSは特定のものを仮定しているのか？
A.している。
協調設計：求められるもの・・・ソフト・装置開発者の視点
スライド１：商品開発の全体の流れの説明
顧客要求から、企画、設計、製造を通じて商品になるまでが示される。
スライド２：設計
設計目標から設計結果までの流れ。
その中でのフィードバック、スパイラルアプローチの部分が重要なのではないか？
組込みシステム：ある特定のものにソフトが乗ればいいというものではない。
スライド３：協調検討の例
主要構成要素、基本構成の検討
・CPU、主要周辺、ベースソフトを想定した設計
・主要構成要素が選択された後の全体設計
スライド４：LSI屋の協調設計への反発
ソフト屋にとってCによる記述は最終出力、設計結果であって仕様ではない
実装の主要部分は終了しており、残された選択の余地は些細な部分のみ
仕様に基づく協調設計が求められる
手続き型言語では仕様はかけない
スライド５：当面のアプローチ
仕様記述の統一された手法は（当面）できないだろう、、、ならば、ソフト屋ハード屋相互を結び付けていくべき
通訳の育成の重要性
・相互理解
・システムアーキテクトの育成
・協調検討の機会
・相互交流
大学教授としての意見もあり？
スライド１：システムソフトウェア研究の現状
・研究者の絶対数の不足
・組込みシステム研究者の不足
⇒意識革命が必要
スライド２：HW屋、SW屋の意識のずれ
HW屋SW屋の重要視する点の違いについて（「誤解を恐れずにいえば」と前置きして）
ハード：目に見えるものを重要視
・ハードウェアコスト、性能、電力
ソフト：目に見えにくいもの重要視
・開発コスト
ソフト屋のこのような傾向：ソフトウェア工学はソフトをハードウェア非依存にする技術の歴史
スライド３：協調設計の全体の流れ
組込みの最近の流れ
用途が特化⇒近年においては用途の特化のされ方が広くなる（ex.携帯電話の組込みjava）
スライド４：従来の協調設計
・対象：応用プログラム、多くの場合単体
・プログラムとハード絵輪
スライド５：システムソフトウェアの課題
・開発効率と実行速度のトレードオフ
・保護、セキュリティ、信頼性
・デバイスとのインターフェース
・省電力への貢献
スライド６：協調設計におけるOSの位置
・協調設計に取り込む
最適設計の自由度の拡大
新しいシステムの可能性
・リターゲッタブルOS
スライド７：今後のシステムLSIの協調設計
・OSを取り込んだシステム設計、方法論の確率
・分担の見直し
従来の分担：ハードウェア、システムソフトウェア、応用プログラム
垂直方向の分業化における協調設計
司会：協調設計のニーズはあるが、立場が違う。どのような場所にどのようなニーズがあるか？
ソフト屋からまず、、、
福田:苦労するのはデバイス周りの制御、ちょっと違ってても動くハードがほしい
石山:協調設計の話ではないが、デバイスの最高性能についてはアピールしていても、実行時の平均的な性能についてのアピールがない。
これはお互いのやり方の理解ができていないのではないか。デバイスの仕様についても納得のいかないものが多い。
三好:性能を見積もることについて。通信をやっているので、今扱っているADSLでは時間にシビアで因果律に従ったシーケンスの決まったアプリケーションとなるが、プロトコルが違うとまったく異なる。あるシーケンスが決まったらそれに対する処理の全体は頭の中に浮かんでくる。そうすれば大体の処理の時間から性能の見積もりはできる。原始的だが、足りないところは付け加えていくことでスパイラルアプローチは避ける。動かしたときにきちんと性能が出ることに注目する。
石山:今言われたようなアプローチでは、複数のチップが存在するような環境では、ソフトウェア屋はうまく設計できなくなる。検証モデルの問題。
ソフト屋と視点が違う
三好:システムもLSIの中も、システムの分析という視点で言えば実は似ている。
大きなシステムもLSIも同じような視点で見ることが可能だ。
柴下:今の話を聞いていて、協調設計はハード屋は固定であるように感じる。パラメータは２つ。１つはシステムの大きさ、？
Cは最終形であるといわれたが、Cでかかれたアルゴリズムは出発点のような気も。
会場：C言語で書く人は処理系を書くと考えてしまっている。作りたいものをどう表現するかは自由じゃないのか？
表現されたものをどう実現するかという視点が希薄なんじゃないか？
福田:それは論理的な思考がかけてる人が多いんですよ（笑）Cだと書いたら動く。論理的な思考じゃないとかけない言語が
ないといけないのかもしれない。
高田：物を書くには最適なものがある。Cでスペックを書くなんて最悪なんじゃないの？
石山:手続き型で書くから良くない？
会場：いろんな言語を調査したが、今のところみんながまともに書ける言語がCしかない、っていのが現状ではないか。
柴下:それは違う。仕様は仕様書。規模だ。アルゴリズム中心ならCでもいい。もっと大規模ならそうはいってられない。
Cが言葉の仕様書として向いているかはわからない。
司会：使用記述と協調設計のつながりは？その本質は？
石山:ほしいものをきちっと書く。そこから先をうまくやるための方法論がまだわかってない。どういう風に書けばうまくいくかも
わかってない。どちらかがうまくいくと実はうまくいくんじゃないか？
会場：システムレベルデザインの標準化を考えた人たちがいる。きっかけはVHDLvsVerilog。どうやったらシステムレベル設計は
うまくいくのか。一つの言語で全てを書くのは無理。たとえばCでは制約は書けない。だったら複数の言語で書くのがいい。
複数の言語を落とし込むセマンティクスがほしい。
三好:人間の頭の中を一つの言語で書けるわけがない。それをブリッジするものが必要。人間が考えていることを
そのままプログラムにしていく例がある。このようなことが協調設計においてこれからのトピックになるのでは？
司会：ハードのバグはソフトでカバーするの？これはツールで防げないか？
柴下:発見はできるけど、防げない
司会：どうしたら
柴下:基準を見つけるまでシュミレーションを繰り返す
司会：基準はどうやって
柴下:設計者の頭の中
司会：元に戻っちゃいましたねぇ。上位モデルを設計するのはどういう人？
福田：昔はアーキテクトは一人か二人だった。システムアーキテクトがやればいい。
会場：企業にはそれらしき人がいる。でも、フレキシブルなものを作りたい場合、全体を見渡せる有能な人がいる。
ハード、ソフトにこだわってはだめ。
会場：協調設計は過渡的な状況でないか？今の状況は誰も決められないから話し合いましょうという段階じゃないか？
ハードソフトの切り分けが難しく、それをまとめる人もいないから協調設計。Spec-Cなどはそのすきまが商売に
なるんじゃないかというところだろう。コンフィギュアラブルになればその切り分けはより難しくなる。協調設計は妥協の産物だ。
会場：仕様を決めるという作業と設計するという作業の次元が違う。でもごっちゃになっている。本来分離されて意識されるべきもの。
協調設計は具体化する際に行われることで、仕様を決めることは別。
会場：ソフト屋から見て、無駄な機能が多すぎる。商品として考えたときにサービスが過剰になっている。
アプリケーションから見ると、LSIは見えない。何が必要なのかがハード屋さんにはわかっていないんじゃないか？
司会：では続きは後半戦で。
全体としては、パネラーによるポジショントークがおのおのが現場で感じている協調設計の課題についての
意見であったのに対し、議論ではSW/HW共通の仕様記述のあり方についての議論が中心となった。SW/HW双方の技術者とも、
お互いに対する不平不満というよりは、共通の議題についてお互いが抱えている問題点を言い合えるという意味では、非常に
中身の濃い議論だったように思う（実際、オーガナイザーの高田氏も「こんなに議論がかみ合うとは思わなかった」と発言
している）。前回(SWEST2)での議論の報告からはもっと喧嘩腰の議論になることを想像(期待？)していたが、ふたを開けてみれば
お互いの問題意識、論点のかみ合った、ある意味和気あいあいとした議論となったようにも感じた。
ちなみに、夜のセッションで行われた「延長戦」では、HW/SW双方の使用される用語に対する認識の違いを
埋めるところから始まり、この議論よりもより具体的な組込みシステムの開発事例を基に、こちらも内容の濃い議論が
展開されたので、あわせて参照されたい。