SWEST2 分科会5B
「LSI屋のいうコデザインは本当のコデザインではない
		〜 これがホントのコデザイン 〜 」

--部屋の様子--
人数 : 約30名程度

3人がけの机8つを四角くして互いに顔を付き合わせることで議論しやすい雰囲
気であった。中堅以上の人が集まっているという印象を受けた。中央の席とは
外れた場所にイスを用意し、この討論を見守るという姿勢の人も。

--議論項目--
  ・「組込みシステム」というものに対する双方の見解の違いを埋める議論
  ・「仕様は実行できるもの/実行できれば仕様ではない」
  ・コデザインとはどこを取って言っているのか
  ・UMLは何をしてくれるか
  ・HW/SW分割のポイント

--自己紹介--
それぞれ参加者がHW/SWのどちらかの立場を明確にすると言う意味も兼ねて、
自己紹介を行った。

  参加者の立場
    ハードウェア   : 13名
    ソフトウェア   :  7名
    どちらもできる :  2名
    どちらでもない :  2名

----------------------------------------------------------------------------
ポジショントーク(ハードウェア/LSI関連技術者)

過去の事例の紹介という位置付け

システムをC言語で記述したものから、ハードウェアの合成を行う
  ・顧客の仕様がC言語で来ることもある
  ・1000-2000行程度のもの
  ・自動でできればコデザインのイメージも変わる
  ・ハードウェアを数秒で合成可能
  ・シミュレーション時間の短縮(VHDLでのシュミレーション5時間に対して32秒)

何でもソフトでデバッグできるわけではないと言う例
  「ボードを挿入する事によってクラスタ環境ができるもの」
    ・状態が1000程度
       -> 人間が設計するのは無理
    ・デバッグ用マスターコントローラを設計
       -> バス速度に間に合わない
   -> 機能合成なしでは設計できない

W-CDMA用のシステムを全てC言語ベースで作成している
 -> Cでモデルを作ることによりシュミレーションの高速化が図れる

デバッグに対する要求
  ソフト屋さんとハード屋さんで求めるモデルが違う
    ソフト屋 : 動作レベルでモデル化
    ハード屋 : 信号レベルでモデル化
  デバッグに対する要求の多さは費やす時間の多さの裏付け

仕様検討の際、Cがそのままつかえるのでしっかり検討できる

C言語によるハードウェアの設計の効果：
	論理合成／論理検証にかかる期間が従来の1/3

----------------------------------------------------------------------------
ポジショントーク(ソフトウェア/システム開発関連技術者)

  ・「SW/HWのコデザイン」からこの分野に入ってきた
  ・Rapid Prototypingも重要だが、その前も重視したい
  ・「Cを書くことがシステムを作ること」
    C言語はあくまでも(最終)製品であり、仕様ではない
      -> 全てを一貫して流したい

  +--- ここからいきなり討論となる
  | 議論「アルゴリズムを記述するC言語と実装を行うC言語は別物」
  |   ハードウェアに依存するCソースもある(キャッシュのミス/ヒットなど)
  |    -> 一口にC言語と言ってしまってよいものか?
  |     -> キャッシュとかを意識したら何も残らない
  +---

OSをUMLなどで表記し、アプリケーションもUMLで表記する
  -> その後、最終段階でパーティショニングを行う
  #上流は全て一つ。最終製品はHW/SWのどちらかに落ちる

要求仕様から実装レベルのC言語まで一気に落としたい
  -> UMLがいいとは思うが...

----------------------------------------------------------------------------
議論「この話は組込みシステムには当てはまらないのでは？(HW)」

巨大なソフトウェアならそれでもいいが、組込みシステムならこの話は当ては
まらないと考えている (SW)
  -> すでに携帯電話のようなものも大きくなってきている
       リファレンスのC言語と実装のC言語は同じである
       仕様から実装まで落ちる間に制約が付いていく

----------------------------------------------------------------------------
議論「機能ブロックのアルゴリズムは (HW)」
 #どこがSWでどこがHWなのかわからない
 #これは仕様ではないと言い切れるポイントがわからない
  -> アルゴリズムとしてのCをそのまま利用しないことに意味はあるのか

 本当は何をしたいのかというところを議論したいのだ！(SW)
 UMLは仕様を記述するだけの言語であるが、これ以降も考えたい

           |
  仕様  -->|-->  エキスパートシステム  -->  成果物
           |        ↑制約
     できる/できない

#議論がどんどん泥沼化してきたので、
#それぞれの考えるコデザインのフローを示して整理することに

--それぞれの思うコデザインのフローを示す--

+--SW技術者1の考えるフロー----------------------------+
| システム仕様                                        |
|     |                                               |
|    UML  <= デザインパターン                         |
|     |                                               |
|     +----------+ <= パーティショニング              |
|     |          |     #ここはSpecCが求めているもの   |
|     |          |                                    |
|  Hardware   Software                                |
|  (VHDL)     (C,C++)                                 |
+-----------------------------------------------------+

+--SW技術者2の考えるフロー-----------------------------+
| 要求仕様 : 自然言語                                  |
|    |   <- 検討のサポート 分割変更前の{速度,規模,...} |
| 実装仕様                                             |
|    |                                                 |
|   実機                                               |
+------------------------------------------------------+

 #共通してSW側は仕様が重要だと言える

----------------------------------------------------------------------------
議論「HW/SW分割のポイント」

ワークフローの各Activityを明確化して、それについて語る

仕様が自然言語でなされている時点で固めるのが得策なのか?
それよりもC言語できっちり決めてから動く方が良いのではないか (HW)
 -> 一度C言語で固めたものを変更したくはない (SW)
 -> SWとHWでは複雑さのレベルが違いすぎて、SWの検証やrefineは避けられない。

HW/SW分割を行うとき、仕様書がほとんどBlackBoxなのになぜ分解できるのか(HW)
 -> カンと経験。本当にCriticalと思えば記述して検証もする。(SW)

今までHW/SW分割は全部見えた段階で行っていた。(SW)
最近はどんどん上位のレベルにあがってきている。
 -> UMLでの記述と言うのはその傾向の採集形態かも知れない
   -> 果たしてモデリングだけで分割できるのか (HW)
    -> モデリング自体どうあるべきなのか

HW側 仕様よりも実際に実装を変えていくほうが重要。 (時間がかかる)
SW側 Cになってしまったらもう変えない。仕様の方が重要。

より上位での分割の可能性
  -> 最終形態になれば分割は最後になるのではないか (SW)
     UMLの段階ですでに具体的なイメージを持っている
       -> 各段階で分割することだって可能なはず (HW)
           (要求仕様から実装仕様の間とか)
         -> 狭義のコデザイン手法の全体への適用を考えよう
            UMLの段階でコデザインできるツールが欲しい

----------------------------------------------------------------------------
議論「コデザインはどこ？」

#互いに言っている「コデザイン」という言葉が不透明に。
#LSI開発関係者(高専教官)が現状を整理する。

+----コデザイン--------------------------------+
|       ------ 仕様                            |
|      ↓       |                              |
|     IP  <--  C言語                           |
|  この流れも   |                              |
|  コデザイン   +-------+  <= ここもコデザイン |
|               |       |                      |
|           MPU(HW)  アセンブラ                |
+----------------------------------------------+
  仕様->IP, 仕様->Cと流れるコデザイン (上流)
  C->HW, C->アセンブラと流れるコデザイン (下流)
   -> 上流と下流2種類のコデザインがある
    -> 上流から見たら下流のコデザインは「チューニング」に相当

----------------------------------------------------------------------------
議論「UMLは本当に有用か？」

UMLはCとかの言語で再度記述し直さなければならないので、
人間の手で実世界(実行可能言語)とのマッピングが必要ではないか (HW)
 -> 確かにできない (自動化では性能でない)

この設計のときUMLは何をしてくれるのか (HW)
 -> 体系化されていないが、開発効率はCで叩くよりもはるかによい

HW屋さんとSW屋さんの「UML上での言葉」は通じるのか
 -> HWのUMLオブジェクトはSWのUMLオブジェクトと一致しない

ハードもソフトもわかってない状況でUMLで記述できるのか (HW)

方法論を議論すべき
  論理システム設計では、要求->設計->実装と落としていく。
  しかし本来であれば意味システム上でのモデルを作り、そのモデルから論理
  要求、論理設計、論理実装が見えなければならないはず。

本当にできるという足場を明確にしてから何かをしなければならないんじゃないのか？
 -> そういう意味で実際に動かすことができるC言語は強い

組込み屋さんとはいえハードウェアは理解しているわけではない
 -> プログラムのオプティマイズをかけるよりもC言語コンパイラのオプティ
    マイズレベルを上げろと要求する

UMLは道具でしかない
  MethodとMethodologyは別物

論理モデル->物理モデル->論理設計->物理設計
各ドメインにあったメソドロジーを使うべき
 -> SWは単一のドメインに落ちるが、ハードウェアはそうではない
 -> DesignというものをValidationとともに考えるべき
LSIを起こす場合と起こさない場合もある

----------------------------------------------------------------------------
議論「動くものは仕様ではない」

ソフト屋さんとしては、実行可能なものは仕様ではない
 -> ツールとしては実行可能でなければならない
    とすれば作るのは無理

----------------------------------------------------------------------------
まとめ

本質はツールとか関係なく、HW屋さんとSW屋さんが仲良く設計していければそれでいい
 -> HW,SW屋さん相互の連携が必要 (情報のやり取り)
 -> 同じ言葉で話したい

コデザインの対象に食い違いがある
同じ言葉で話すためのきっかけたりうる
 -> でも道のりは遠いか?

仕様の実行可能性
  「動けば仕様ではない(SW)」
  「動くような確かなものでなければ仕様ではない(HW)」

感想
一部の方の過激なトークを周りが冷静な目で見つめるといった状況。
前から「コデザイン」について語ると、議論というより喧嘩に近いという話を
聞いていたが、参加してそれを実感した。
全体を通じて感じたが、ハードウェアよりの方は現実を見つめ、しっかりとし
た何かを求める傾向があるが、ソフトウェア側の方は夢を語る傾向がある。ハ
ードウェア屋にとってはソフトウェア屋のそのスタイルが気に食わないような
気がしてならない。

以上