===========================================================================
分科会1 セッションF2:                                         SWEST5 議事録
「モデルと実装の壁 ─アーキテクチャ選択─ (仮題)」
                                                                 2003/07/24
===========================================================================
【 会場／参加者 】
日時: 7/24 15:10-16:50
会場: E 会場（100座席程度）
参加者人数: 26人前後

---------------------------------------------------------------------------
【 ポジショントーク１？】
ポジショントーカ：藤懸さん（システム・ジェイディー）

設計と実装の間にギャップがある．
まず，オブジェクト指向設計があって，
設計が終ったらオブジェクトが 200 もあったっていう話がある．

アーキテクチャの話しがあったが、ソフトウェアの方に話が振れてしまってい
たので，ここでは，ソフトウェアとハードウェアのインターフェースをとるよ
うな話をしたい．

まず，参加者全員に質問します．
自分はソフトウェア屋（ソフトウェア開発中心）だと思われている方は挙手を
お願いします．学生さんは研究内容がどれだけソフトウェアをやっているかと
いうことで．

（１５人くらい手を挙げる）

逆に，ハードウェア屋さんはいますか？

（５人くらい手を挙げる）

やっぱりハードウェア屋さん少ないですね．
今回，全体にハードウェア屋さんが少ない気がしている．

今回アーキテクチャ選択ということで，最初にシステム全体の設計があって，
それからこの辺りはハードウェアで実装して，この辺りはソフトウェアで，ソ
フトウェアのアーキテクチャはこうで，ハードウェアのアーキテクチャはこう
しましょうという話があると思う．そういう話をしたい．

高田先生がお話したいことがあるそうです．

【 ポジショントーク２？】
ポジショントーカ：高田先生（名古屋大学）

ずっと OS などソフトウェアをやってきたが，最近，コデザインに興味をもっ
てここ 3 年くらいやっている．最近思っていることをいいます．
プレゼン資料を用意していないので，ホワイトボードへ図を書きます．（図１）

最近，我々の研究室では，SpecC とか協調設計，システムレベル設計をやって
います．

これ以上の上流の話は昨日やったので，今日は C 言語レベル，SpecC や
SystemC でもいいし，ないしは，ハードウェア屋さんが言う動作レベルで既述
するというところから，話をスタートする．

これを実装するひとつのやり方が，ソフトウェアで作ることである．
（図の）最左翼として Pentium ．汎用プロセッサの上にコンパイルして落せ
ば終り．最右翼は，動作合成，ハードウェア設計．専用ハード．

ただ，ここでいう専用ハードというのは，結局でてくるものは，プロセッサみ
たいなものができる．

C 言語レベルから落ちてくる変数はレジスタになるし，演算器があって，その
間を複雑なものであればバスでつないだり，単純だと直截配線してマルチプレ
クサを入れる．

おおよそレジスタファイルがあって，演算回路があって，場合によっては，そ
の間がバス接続されているハードウェアだと，データパスがあって，これとは
別にコントロールパス（FSMで書く）が全体を制御する．

結局プロセッサとどう違うのかというと，プロセッサからデコーダを引いたも
のというイメ−ジで，FSM がひとかたまりで作られているだけで，プロセッサ
との本質的な違いはない．命令がない，デコーダがないだけであまり差がない
気がする．

常に興味があるのは，アーキテクチャ選択ということで，どういうものをどっ
ちで作るのか，どっちで作ればいいのかに興味がある．

通常，ソフトウェアとハードウェアは二律背反するようなアプローチという風
に見られている．結構そうではないと思う．（図の汎用プロセッサと専用ハ−
ドの間をさしながら）この間に連続するソリュ−ションが今提案されつつある．

ひとつは，専用プロセッサ，例えば，DSP．汎用プロセッサと違って専用の命
令がある．

この隙間には，いわゆる configurable processor がある．要するに，一番性
能がほしいところだけ専用命令を追加すれば，そのアプリに特化したプロセッ
サができる．それは，専用命令の入れ方によって，（図を指しながら）広い範
囲で場所が変わる．

結局，技術が割と連続して分布しているように思う．そうなると，あるもの
はどっちで，あるものはどっちで作った方がいいということに興味があるわけ
だが，もっと話はややこしくて，どんなものをどの辺りで作ればいいのかとい
うことをどう見極めるのか？

非常に単純な答えとして，並列性が必要なものは専用がいいという直観．
なにをもって並列というかは問題．汎用でも命令を並列に扱えるようになって
いるから．並列という言葉も簡単ではない．

もうひとつ，flexibility という軸もある．
これはハ−ドウェアでやると一度組んでしまうと直せない．
ソフトウェアでやると有利で，後で直しやすいという話がある．

それも落し穴がある．

専用ハードでも，今や FPGA 上で作ると，flexibility という観点では汎用プロ
セッサと全く変わらないと言える．

FPGA 上で作ってしまうと flexibility は同じ．
ただし，専用ハードを ASIC で作ると，flexibility はない．
（図で）縦軸を flexibility ととると，こんな三角形を作ることができる．
横軸は専用性？ 横軸は少し怪しいがこんな三角形をかけば，この三角形の中
に今のテクノロジが落ちてくると思う．

	  --------------------------------------------------
C言語レベル(SpecC,動作レベル)

    flexibility <---------------------------------------
 |             汎用プロセッサ(Pentium)                         安い
 |         
 |             専用プロセッサ、DSP
 |               ↑
 |               ｜ configurable
 ↓              ↓   
 並列性       専用ハード/FPGA  -------------  専用/ASIC        高い

			       [ 図 ]
	  --------------------------------------------------

(藤懸さん)

この話しを聞いて，LSI 屋にとっては，ハードウェアのする仕事がないという
イメ−ジにとってしまえるが，LSI屋の方で，ご意見はありませんか？

===========================================================================
【 議論 】

発言者の表記
 (藤)：藤懸さん（システム・ジェイディー）
 (高)：高田先生（名古屋大学）
 (冨)：冨山先生（名古屋大学）
 (中)：中村先生（東京大学）
 (二)：二上さん（東陽テクニカ）
 (ソ)：ソニーの方．分かりませんでした m(_ _)m
 (A?)：分かりませんでした m(_ _)m
 (B?)：分かりませんでした m(_ _)m
 (C?)：分かりませんでした m(_ _)m
 (I?)：分かりませんでした m(_ _)m
 (N?)：早稲田の方．分かりませんでした m(_ _)m

---------------------------------------------------------------------------
(A?)
私はハードウェア屋．私のところではほとんどマイコンでやっている．
確かに昔，やっぱりすぐに書き直したいということがあって，それにマイコン
で対応，それ以外のところを回路でしていた．

結局，HW／SWの組み合わせ処理が間に合うのかという問題．
間に合わないとHW．それが安い解決方法
FPGA が出てくると，どこでもいいように感じる．

実状は，HW の規模を小さくするには処理速度を犠牲にした方が，
プロセッサ側にコストを振るというのがよいのではないが，そういう設計にし
ていると思う．

ASICの設計だとCでもできるが、
実際には，アナログ回路がきたりして，
アナログは回路でやって，それ以外はプロセッサで．
アナログの場合はすくないと思いますが．

コストドリブンでやっている．


(高)
プロセッサでやるとコストが安い，専用でやるとコストが高いということ？


(B?)
FPGA は早くできるが，HW の規模は汎用プロセッサよりも大きいと思う．


(高)
常識的だとは思いますが，本当にみなさん，agree ですか？


(ソ)
規模は３００万ゲート．まずプロセッサに載せて，どこをHWにするかは机上に
で見積もっている．実際，実機にもっていかないと分からない．
前倒しで見積もりたい．コデザインのツールがほしい．

机上での計算がミスすると，チップが何千万するので，専用ハードを置こすの
は恐い．ただ単に汎用プロセッサにふっていいものではない．
FPGAでやればいいが， FPGAでは規模が小さい，ゲート数が足りない．

そこで，前倒しで，パフォ−マンスの見積もり，検証できるような環境がほし
い．現場からはあがっている．

バストランザクションのシミュレーションが間に会わない．アービトレーショ
ンが見積もれない．


(藤)
今の話しは，全然，ドメインが違うと思う．投じる開発予算に制約がゆるいも
のと厳しいものを同レベルで論じると，本当に議論が発散するのでやめたい。

例えば，新規にいくらでもハードウェア(LSI)を起こすことができる所はあり
ますか？あまりいないと思う．LSI 作るのは最後のどうしようもない状態と仮
定した方がいいと思う．ASIC から FPGA への移行があると思う。バリバリの
LSI をおこさないという前堤で議論を勧めたい．


(高)
性能が机上で見積もれないというのはどこについてですか？


(ソ)
例えば、バスのア−ビトレ−ションとかで、再送不可能な状態でシステムが破
綻なく動くかどうか。


(高)
それはやっぱりシミュレ−ションでは、遅いということですか？
一応，シミュレ−ションをかければ不可能ではない？


(ソ)
そういう環境が欲しい。


(藤)
一番困るのがバストランザクションということですが、最近トランザクション
レベルのシミュレ−ションをしましょうというものがある。


(ソ)
その環境を作っているのですが、HW屋さんは verilog で書くが、そのモデル
を誰が作るかが問題。システムレベル設計でHW屋さんが書きはじめてくれてい
れば、そこらあたりのモデルがファ−ム屋さんのファ−ムにくっつけて、ア−
ビトレ−ションが見積もれる環境が構築できるんですけど、HW屋さんのレベル
は verilog なので。


(藤)
おっしゃるとおりだと思います。
最近、CoWare というところはその辺りのモデリングも含めてやりますよと言っ
ています。どこまでできるかは私は知りませんが。


(ソ)
あと、既存資産が verilog である。
それとのが非常に難しい。
システムレベルに移れない。


(中)
組込みシステムではないが，SW/HW という意味で metric がある。
性能、消費電力、コスト、flexibility、time-to-market(TTM)。
専用HW は低い消費電力で高いパフォ−マンスがでる。しかし、コストもかか
る。flexibilityも低い。time-to-market(TTM)には不利である。

CADも進歩して、集積度も上がったので、パフォ−マンスと消費電力に関しては、
必ずしも専用HWであることにその優位性はある？
そもそもコストが高いのかという話があり、コストは考えなくてもいいので
はないかと話がある。HW でやるにしても、合成すればいいので、
コストと TTM に関しては、事態は緩和されつつあると議論があった。
必ずしもコスト、TTMは考えなくてもよい？

性能の見積もりが大変という話があったが、verilog でやるのと C でやるの
では話が違っている。
verilog では HW の動作を書く、例えば、このバスの競合があった場合はとか
書くが、C で書く場合はそんなことを書かなくても動作してしまう。

論文の中でこんなア−キテクチャは性能がないとか書くが、
シミュレーションをどこまでやるかは良心の問題。

同時にこれとこれがができないようというようなモデリングは C でも大変。
それはいくらか自分で手当てしないとダメだが、C で書くと、具体的なリソー
ス制約のモデリングがいいかげんでもシミュレーションできてしまう。


(藤)
C は構造を書くわけではなく、手続きを書くので、構造をもったものは非常に
難しいと私も思います。そういうことをやっていたので，よく分かる．


(ソ)
今の話はモデルの詳細度というものであると思う。
今注目されているのが、bus transaction level というものがあって、
バスのトランザクションだけは検証できるようなモデルを抽象度で書けば、
ソフトウェア屋さんがシステム全体がつじつまがあっているかどうかをシミュ
レ−ションできるような方向にもっていくという話がトレンドになっていると
思う。


(高)
単純に C というわけではない？


(中)
では，どこで性能がうまく見積もれていないのかという話が話せればお願いし
ます。


(ソ)
例えば、最も負荷がかかる場合で、ハ−ドウェアと CPU がバスをとりあう場
合に、CPU がどれくらいのスループットがでるかをある程度シミュレ−ション
の過程で見積もりたい。そういう性能を早い段階で見積もっておかないと、
最適な要求仕様を満たすようなチップをだせない。


(中)
それはそういう状況を想定してシミュレ−ションしないからいけないのですか？
それとも、こういう状況があるからといって予めシミュレ−ションすれば、そ
れは...(話し割られる）


(ソ)
それを早い段階でやりたいのですが、現在はうまくいっていない。


(中)
テストパタ−ンが実際の動作を摸倣できるだけの入力を今は設計者が与えるこ
とができていいない？

(ソ)
はい


(藤)
あとモデルの書き方が難しい。どこまでモデルの詳細を書けばいいか、もちろ
ん徹底的にかけばシミュレ−ションできるが、かといって落しすぎると先ほど
の問題がでてくる。どこまで情報を落していいのかが分からない。

ソフトウェア屋からするとモデルが動く必要はないという話しがあるが，
ハ−ドウェア屋はモデルが絶対に動いてほしい。


(高)
モデルという言葉が SW と HW でだいぶ違う。
SW は動いてしまうと実装。
HW はモデルが動いてから実装までが遠い。
SW は動いてしまうとよくて、あとはチュ−ニング。


(藤)
HW も FPGA だと動いたら実装ではないですか？


(高)
そういう気はします．


(藤)
要するに、物理現象とかがいらない世界ですよね．


(I?)
高田先生の話しはだいぶハ−ドウェアの制約が少なくなってきたという話しで
すが、それは現場で感じています。

汎用プロセッサは本当に安いのかどうかという疑問を感じる．
ある程度になると、FPGA の方が安くなってしまう。

作っているものと性能でだいぶ違うと思う．

ある程度の性能を出そうとするとプロセッサはべらぼうに高い。
安いプロセッサを使って、外にFPGAなどを置くのが妥当では？


(藤)
皆さん御意見ありませんか？
専用プロセッサと汎用HWのコストパフォ−マンスについて．


(中)
それは，設計のコストをどう考えるかだと思う．
確かに汎用プロセッサは何でもできるが，無駄なことをやっているから高い．
ボードのアセンブルは熱の話しとかある．（さきほどの話しは）定性的に言っただけ．


(ソ)
タ−ゲットの種類によって違う。
例えば，携帯電話は消費電力がうり。
どういうカテゴリに対してかが問題．


(藤)
今の話しもそうですが，一概に，汎用プロセッサだから安いとは言えない。
今の話しで御意見は？


(中)
製品の継承性という話しもあると思う。
汎用プロセッサの世界では、どういうものによるが，奇抜なものを使わなけれ
ば，継承性を維持できると思う．
一旦，ハードに落ちると毎回自分で作らないといけないという時もある．
継承性も flex. や ttm にも定性的にはあると思う。

あるシナリオとすれば、ドメインにもよるが、
例えば、携帯だと専用HW でないとダメというところもあるが，
汎用プロセッサですませることができるならいいと思う。


(藤)
継承性と言われましたが、もともとあるものをがらっとかえるにしても，
HW化するとSWは楽にすると設計自体はらくにならない。
HW 化されたことによって，ソフトウェアにしたことで莫大なコストがかかる
と思う．HWからはプロセッサ変えたら終りと思うが，SW側からは，
レジスタ構成がかわるだけで検証がやりなおし。

そういうところでかかるコストというのはHW屋が思うよりもバカにならない．
堅いソフトウェア，軟らかいハードウェア．

ソフトウェアは意外に融通がきかない。ちょっとしたことでも大変になる．ハー
ドウェア屋の方がこれを分かっていなくて、変えようということを言いだす。


(高)
ソフトウェアさん、直すことを嫌う．一度動いたら手を加えたくない
割りとハードウェアは石に焼くまで気軽に直す。

SW/HW での不一致があって、どっちが直すかとなったときに
ハードウェアを直すことの方が多いという話しがあった。
SW の方が検証空間が広い。
最近「HW は複雑になりすぎて検証できません」と言われるので、
「SW は20年前からそんなことできていません」と言うのですが．
検証は重要だが、そういうところがある．

SW 一ヶ所を直した場合の波及範囲がよくみえない。
HW の方は物理的な locality のおかげで見えやすいのかなと思う．

今の SW の作り方が悪いといえばそうなるのかもしれませんが．どこに波及す
るかが分からない．堅いメーカ立場では、プログラムの置くアドレスが変われ
ば再検証という話しもある。キャッシュの影響があるのでリアルタイム性の検
証などはやりなおし．

「SW にすると検証コストが低くなる」というのは本当？


(二)
ソフトウェアが堅いという話しに対して，
例えば，低いレベルで，ビット幅を定義するとします．
ビット幅は HW では柔軟、SW のC言語は int が王様．

int が 16 ビットであるというプロセッサでソフトウェアを書いたとして、
int が 32 ビットのプロセッサに変えた場合，100万行のプログラムがあった
として，int の幅の変化をheader file だけで修正可能でしょうか？不可能！


(高)
絶対動かないです．


(二)
ですよね．
大方の組込み屋さんは，こういった移植は，もう不可能である．
一旦int16で作ったら、int16だとする．まして，その先は考えてはいけない．
これは，ソフトウェア屋のハードウェア限界．

昔はこういうプロセッサになったときは，
ちょっと書き換えてテストすれば動くといっていた．

実際は，ありとあらゆる障害をソフトは作りこんでいるので，ハードになって
しまっている．


(藤)
確かに、HW は物理現象とのインタ−フェ−スが難しいので、そこで問題がで
てくるだけで，ロジカルな部分は大丈夫。
HWはビット幅の変更(大きい方法への)ロジカルには大丈夫．
どうせ作りなおすならHWという話しもある．
HW の方がよっぽど SW．


(高)
6つ目の軸、検証性がある。TTM に入る？


(I?)
検証という話しは，用途によって違うと思いますが，SW はそんなに固い？か
なという感じがします。元もと，ビット幅の話しも元から意識して書いていれ
ば移植できるのでは？ そういう書方をすればいいと思いますが．
最近，プロセッサが変わってもあまりビックリはしない．


(二)
それはビット幅がかわってもですか？


(I?)
残念ながら，ビット幅がかわることは，ほとんど経験したことがない．
ビット幅ではあまりビックリしたことはない．
16 ビットのものは 16 ビットとしているので，
うまくにげれていると思う．


(高)
さっきの話し，100万行だといったから無理だといった
JSP 5000行ぐらいで，でも1、2カ所ぶち当たった．


(ソ)
そこのあたりの cpu 依存な部分とそうでない部分を切り分けて，ビット幅が
固定されるような部分は，うまくレイヤで切り分けるように対応をするように
という話しを社内でしている．


(二)
プロセッサ独立なレイヤがあって，
デバイス専有のレイヤがあって，一番上あたりは，App Spec レイヤ．
そのあたりは，もはや単なるプログラムではない．私から言わせると，C で既
述したモデルに近いと思う．

高田先生のところの OS のコントロールもモデルセントリックになっているの
ではと思いますが？ただ単に，線などで図に書くのがモデルだとは思ってはい
ません．いかにテーマにフォーカスするかがモデル的なもの．


(高)
プログラムはいろんな側面のものが1次元に書いてあるから，読みにくいの
だとおもう．そういう意味で，アスペクト指向に期待しています．
アスペクトごとに書けたら，確かにモデルに近づくと思う．
アスペクトで見て、くっつけて、システムとモデルが一致するのはいい．

int (32仮定) <-> int という型との I/F での修正が大変だが，すべて int
であれば問題ない。word (32bit) が int であるという暗黙の了解で書いてい
るところが問題だったと思う．

話題提供的に...
configurable processor という話しは信じられない．configurable os はあ
まりない．作りたくないからだ．configuration した組み合わせをすべて検証
したくない．どうやって検証するのか？なるべく１種類にしたい．
それは，検証コストが高い

では，configurable processor はどうやって検証する？
それは，HW は検証しやすいから可能なはなし．
下流が大変から上流はあまり気をおかない．


(藤)
configurable proc は おおきなSWよりも圧倒的に検証しやすいと思う．
pentium みたいなものが configurable になっているわけではなく，
小さなプロセッサが configurable になっている．


(中)
I/F がはっきりしているかどうかだと思う．
HW の場合は配線されていて分かるが，SW の場合はどうやって呼び出されてい
るかが分からない．そういう呼出しがあるから難しいのであって，HW が検証
しやすいとは思わない。
SW は int と書けば動くが，HW は ビット幅指定は必須．
そういうところに細かく考えているからいいんだ．
制約の厳しい世界で設計するから HW は検証しやすい．


(藤)
さっきの私の検証しやすいというのは語弊があったと思う．
SW屋が死んでいるよりもHW 屋は死んでいないと思う．
HW屋は無駄に仕事をするところがある．見切りをつけるのが下手．
HW だらだらと検証してるからいつまで立っても終らない(趣味の世界)
SW は納期がせまっている．HW が送れればSWにつけがまわる．
趣味の世界にいるのは HW．


(冨)
HW 屋は，忙しい忙しいと口ではいってもニコニコ笑っていると思う．


(高)
検証は値段の高い ASIC を作るから徹底的にやるというのは分かる．
FPGA になると flex. が同じくらいになるから，
FPGA になると検証を楽らくになる？
楽にすましてしまうかもしれない．


(B?)
HW バグがあっても直せない，HWのバグだと分かっていてもSW が対応．
それが仕様になる．HW が変更しやすくなり、HW を直すと、システムとして動
かない．SW は色んな作り方ができる．


(I?)
HW は検証しやすい？
では，HW 論理レベルのシミュレーションができるようになったが，
SW はなぜ検証できない？不思議．そこには特性がある．


(高)
それは，入力データ空間の違いでは？
以前，HW屋「最近全数チェックできなくて...」という話しを聞いて，HWとSW
は違うなと思った．SWは全数チェックはありえない．
HWは今やありえないが，それでも，けっこうなことをHWはやっている．
入力空間が，HW で 32 bit 入力，SW で 32 バイト入力ですというくらいの違
いはあると思う．はるかに入力パターンが多いから，苦しい．


(I?)
基本的にはそうかもしれない．
HW はいろんなところで独立に動いている．
SW はすべてがぶつ切りで動いている．
システム全体で考えると、関数単体で動いたらいいというものではない．
相互作用があるから難しさがあるのかもしれない．


(高)
1つのプロセッサを複数のものがとりあうから大変。
さっきのバスをとりあうと所は難しいという話しが正にそうですね。


(二)
HW 屋が１ヵ月働いてこめるバグは？
SW 屋が１ヵ月働いてこめるバグは？
その両者の比をおもちの方は？
さっきまでの話しはメカニズムだが，結果としてどうだろうと思う？


(I?)
そういう数はとっていないが，HW がこめる方が多いように思う．


(冨)
バグは HW の方が少ないという気はする．なぜなら，１ヵ月の間にSW / HW の
プログラムの行数が違うからバグの数が違う．


(二)
SW 屋の方がばりばり書いてる？
HW 屋さんは慎重？


(藤)
さきほどの，動作を書いているか，構造を書いているかの違いではと思う．


(中)
HW は表現能力のないものだからバグを込めにくい．
HW 書くときには，順序関係を考えて書く．
C だと陽にかかないとだめ，書き方の自由度がある．
探索空間が拡がって、検証が大変になるのだと思う．


(二)
ステートマシンを書くHW屋さんとステートモデル？を書くSW屋さんとの話し．
HW はステートマシンに対するメカニズム，sync をきっちり作るから，
Verification 可能なテスタが作れる．
SW は HW 屋さんのようにはやらない。割り込みが入った場合にどうするので
すか？プログラムを書きます．
例えば、割り込みが入ったときの約束事は？ないです！
とにかくバリバリ書きます！

困るのは，HW屋さんは状態を量子化して書こうとすると納期に間に合わない．
100 万行書くときは 100 人でいっせいにやる．


(高)
前の書いた図は現状ではない．
同じ機能を作る上では、HWは生産性が悪いのは仕方ない．
これから渾沌とするということを表現したかった。


(C?)
専用 HW は汎用プロセッサと同じことをやってもしょうがない．
汎用プロセッサの 5 〜 10倍だせればウリになる。40倍を狙う。
そんなイメージ．

プロセッサで書く方は長くなると思う．
SW は100万行，HW は1万行で機能ができる。
HW は1つ1つが独立しているから検証しやすい。
SW は自分自身をコントロールしているからそこでバグが出やすい。

C で並列性を最大がかけるが、HW の規模が大きくなる．
C で並列性を最小にすると，規模は小さくなるが，カウンタが現れてパタパタ動く．


(高)
並列度最小にすると汎用が速い。
並列度を出すことで専用がいきてくる。並列度を出さないとメリットがない．
特に FPGA は遅いので，数個の並列度ではダメ．もっとださないと思う．

話題提供: configurable processor の話し
  こんなアプリでこんなに早くなる（テンシリカ）

専用が得意な分野
 - 並列化: jpeg デコーダ
    専用命令を出せば、パイプラインで早い
 - ネットワーク処理: TCP/IP, bit manipulation
    マスクを取ったりするだけで10命令。HW は結線で1クロックもかからない．
    パケットを組み立てたり、分解するのは得意

逆に，ある程度の複雑な長いコードは汎用側が得意．
前に書いた３つの指標は渾沌としている．
細かいcriteriaを挙げてデザイン指針を出さないと渾沌とした世界を闘えない．


(藤)
こんなものが HW が得意というのは？


(中)
高田先生の前半には同意。
汎用プロセッサはパイプラインをやっている．すべての命令が同じくらいの難
しいことをしなけらばならない．逆に，複雑な処理は，パイプラインが流れな
いので，専用に落す必要がある．

bit maniplation は汎用プロセッサには複雑な処理．複雑な演算命令は専用の
勝ち．あとは，どのくらいの頻度であらわれるのか？その重さは？という問題．
まず estimate するというのが常套手段。


(I?)
今のの話しは納得した。
処理の粒度（難しさ）によって違って，それを SW にするか HW にするか．


(高)
この絵は、単純化した絵である。
つまり、１つの機能を左か右かという極端なものである。
大きいシステムをまず機能分割して、軸が右か左かを議論する必要がある。
それをするとさらに複雑になる．
こういう細かい特質が分かってくれば、システム設計の助けになると思う。

さっきの，並列性やbit concatination の話しで，SpecC や Handel-C などに
加えられている部分は，その辺りのもので，納得できる．
HW では簡単に実装できるが，C にはないものと言える．


(冨)
この図で，右と左の違いは設計の自由度。HW設計者の。
ある意味で右側が包含しているといえる。
同じ設計を同じ時間を書けていいのであれば，右の方がいいものができる．
汎用プロセッサの方は設計数年。専用は数か月。
設計期間が大きな要因になるのでは？


(高)
右が包含しているのは当然。
その時点での合成技術をこれくらいのものが合成できる
右が進めば、左がすすむ．
ある一定の開発期間でできる範囲で議論しないと不公平ではないと思う。
汎用プロセッサはもともと flex. があるのだから，
FPGA で作るのは意味がない。
それは除外する．だから左がとじた議論をしている．


(I?)
堅さという意味では、右が軟らかくて，左が堅いといえる．
ちょっとした追加ができない。汎用プロセッサでは．


(高)
左はなんでもかんでもソフトウェアでする世界です．
あえて，ソフトウェアという言葉をさけていた．
ソフトのハード化，逆に，ハードのソフト化といわれるように，
ソフトウェア／ハードウェアという言葉は既に意味を失っている．
だから，SW／HW という言葉をできるだけ避けていた．
右は HW で作って、左は SW でつくる．どこかでわけている．
config. processor は間にあって折衷．

「configurable processor はソフトだから flex. があります」という話しは
大嘘だと思っている．ばりばりに組んだ専用命令にバグがあったら，どうしよ
うもない．つまり，仕様変更があってもソフトだから簡単に変更できるという
話しはウソ．

巨大な命令の中に間違いがあると絶対に直せない．


(I?)
一度作った後が flex. なのか？
一度つくるのが flex. なのか？
という違いがありそうだ。

configurable processor も，こういう命令を追加したいと思っておこしたら，
もう変わらないというものと，そのつど，dyanamic に変えるというものでは
違う．

その意味で，FPGA が flex. かというと，一度つくると，設計に戻らないと変
わらないといけないという意味では堅い．

(高)
flex. という観点では，汎用プロセッサと専用HW も一緒．
どっちも設計までは戻らないといかないが、製造までは戻らなくよい。
原理的ないじりやすさは全く差はないと思う．
もっと違うファクタはある．検証性という観点からは違うものがあるが．


(N?)
研究は並列処理。今日の話しはどれくらいの粒度の並列かが大事だと思うが。


(高)
並列は大きい粒度の並列と小さい粒度の並列があると思う。
大きいシステムを機能レベルに切り分けて、どこにマッピングにするかと考え
たときに抽出するのは大きい並列で、あとは1個のCの関数ができたときに、そ
こからでてくるインストラクションレベルの並列とがある。
その二つの並列をまぜて議論してしまうと話しはごちゃごちゃになる。

ここに書いているのは後者の並列。前者の並列は、組込み屋さんは、マルチタ
スクとマルチスレッドで設計しているので、ほどほどのものはでてくるはず。

自然にでてくるパラレルは性質が全然に違うものパラレルに出てきて動く。
タスクA、B、Cは全然中味の違うものだとして、タスクAは汎用プロセッサ、タ
スクCも汎用プロセッサに振り分けて、タスクBだけは専用ハードにする、さら
にタスクBの中の critical な部分は専用ハードにして、他の部分は汎用プロ
セッサ上にもっていくと思う。


(N?)
その切り分けの自動化を考えた場合に、この部分は重い処理だから専用にする
という判定に使えるものかなと思う。


(高)
なかなかコデザインの研究はたくさんあると思いますが、
自動的に振り分ける話しはあまり成功していないように思う。

別に自動に切りわけなくても、手動でふりわけても充分だと思う。
性能見積もりが早くできれば、いろいろトライすればいいので、手動でも困ら
ないかなと私は思う。

===========================================================================