---------------- セッションS2-4-3：組込みシステムへのマルチコア導入の光と影 コーディネータ：冨山宏之(名古屋大学)、高野裕之(東芝セミコンダクター社) 会場：B会場 参加者数：約20人 ---------------- テーマ 近年、組込みシステムへのマルチコア導入が増えているが、 必ずしもメリットだけとは限らない。そこで、その際の トレードオフや問題点などを探っていく。 ----------------- ※以下、発言者はアルファベットで表記 A(司会)：MePのプロトタイプを作った マルチコアを用いた製品の開発に携わっている。 B:マルチコア関係をやっているわけではないが、どういう形で使われているかに興味がある C:マルチコアのソフトの取りまとめ D:ソフトに近いハードを担当 E:ネットワーク系を扱っている。 マルチコアもよく聞く。いろいろなうんちくを聞き、仕事に役立てたい。 F:システムレベル関係に携わる。 マルチコアが当たり前。単体のCPUではどうしろといえるが、マルチコアになると、 いい方針が示すことができない。 G:ベンチャーの会社で組込みOSを作っている。 Emblixでいろいろ作っている。 H：Nios2でのマルチプロセッサを作っているので、参考になることが聞ければと重い参加した。 I:今年からハードを担当。視野を広げていきたい J：画像処理の高速化にマルチコアを利用しようと考えている。 K：自分の研究には関係していないが、最近マルチコアをよく聴くので、面白いことが聞ければと思っている。 L：マルチコア用ITRON仕様OSの開発をしている。 M:ハードもソフトもあまり開発したことがない。 勉強のために参加 N：入社３年目。今まで組込みソフトウェアに関わってきた。最近ツール関係に転属。 そこでマルチコアに関わる。 O：共同研究でマルチコアを使用。LinuxとITRONを載せる。後は負荷分散。 P：マルチコアによる負荷分散をやっている。コストやニーズについて聞けたらいい Q：通信インフラを担当。PowerPCを使用している。熱問題が問題となっており、 マルチコアに移行しなければならない。最近はLinux。 R：まだマルチコアについてはあまり検討していないが、マルチコアを用いた際の 抽象化やデバッグについて興味がある。 S:CPUが複数あることに違和感はないが、１つのチップに入ってきたことでどのような変化があるかが 興味深い。 A：マルチコアにどんな問題があるかを提案してください。 B：マルチコアかにはメリットもデメリットもたくさんある。 いろいろなひとの意見をまとめてみた。 企画者はスケーラブルに品種を展開することができ、また機能分割により設計規模を削減することができると考えているが、 並列開発に移行する際の不安を感じている。 装置の設計者は、高クロックでの設計に魅力を感じているが、並列アクセス設計が不安 ソフト開発者は性能の保障やセキュア設計ができる。しかし、処理を並列に分割できるかや、 デバッグがいやだ エンドユーザは安定して使える、カスタマイズがやりやすくなる、個性を出せることがメリット。 マルチコアを意識しないため、デメリットはない。 シングルコアで性能を達成できるか、マルチに移行してしまうことになるか？ 今後もソフト開発が破綻せず継続していけるか？ いろんなものを混在したマルチコアはどうなっていくか？ 他の会社と共同で開発することになるのか？ マルチコアは共同開発がしやすいのか？ いろいろな人が開発していかなければ間に合わないので、開発環境も必要と思う。 A：熱問題でマルチコアにせざるおえない。Linuxにせざるおえない。 Q：ヒートシンクに風を当てるにはどうしたらいいのかを考えていったとき、 うまくいかないので、マルチコアで熱問題の解決を図る。 A：いくつもプロセッサを並べるのがいいか、ワンチップがいいか？ Q：理想はワンチップだが、いいものがないので複数プロセッサを用いている。 開発する際には、変更が必要なので拒絶反応が大きい。今日のソースを変えないでいいということが 新鮮な感じがした。 A：まとめると、理想はワンチップ化したいが、ボードに複数プロセッサが載っている ものを使っている。 構成、ソフトウェア開発という点においてはNECと共通部分がある。 ソースコードを変えないことというのが重要。 Q：ソースコードがあれば、LinuxでSMPにすれば、アプリは変更しなくていいと思っていた。 基地局では、処理性能を上げたいため、熱問題が生じている。 過渡的にはハイブリットOSがあるかもしれないが、最後にはSMPをサポートしているLinuxであろう。 B：ファンはつけたくないが、性能は上げたいというならば、SMPしかないのかなと思う。 しかし、携帯電話などでは、非対称に分けた状態が普通と思っていることもあるので、場合による。 G：SMPのマルチコアならば、Linuxを持ってこれば何もしなくても動く。 MPU1つでいくつかの機能をもたせることができればよい。 非対称では、それぞれの機能を行うプロセッサを搭載。 実時間性能を出すにはLinuxでは無理と思っている。 あるCPUはRTOS、あるCPUはLinuxという構成が考えられるが、あいているCPUを別のほうに移すという ことも考えたい。SMPのほうがそういうことがしやすいと思う。 A：デバイスドライバを書くことに慣れているかどうか？ Q：SMPにする理由は、マルチCPUに近く、とにかく熱を下げたいため。OSには特にこだわらない。 どういう風に機能分割するかをソフト設計でもめる。 ハード的にどうインタフェースをとるかが問題になり、ソフトでは機能分割が問題になる。 出来上がってしまえば効率がよいと思っている。 全体性能を上げてしまえばいいという考えがある。 基地局としてはリアルタイム性よりマルチにしたい。 A：マルチコアシステムは、出来上がってしまえば効率がよいというのは本当か？ B：そうかもしれないが、並列システムを使えるかという点で、解決しなければならない問題がある。 最初のレベルでの設計を支援する必要がある。 プログラマーをどうやって集めるか。なかなか並列対応の性能のよいプログラムをかける人はいない。 人材を育てることも必要。 S:チップを作る人に対するデバッグサポートの意識が必要と思う。 A：MePでもJTAG-ICEでサポートしているが、バスのトラフィックまで見るものはない。 普通のデバッガと同じように、ブレークポイントを置いたり、レジスタを見たりするといったもの。 問題だとは思っているが、いい解決策がない。声の大きい問題のほうに力を注いでしまう。 デバッグ関係では、見えてはいけない部分はデバッガからも見えないようにしている。 セキュリティが強くなっている。 ハード、ソフトへの機能分割やインタフェースなどに対するフレームワークを作ることができるか？ S：自動分割ができるというのは無理。まったく新しいものを作ることはないので人間の経験は結構あたる。 機能分割は人間が試すと割り切り、それ以外の部分を短縮させる。 A：見積もりの制度をよくするものがほしい。 これからやろうとしているところではどうすればよいか S：経験のある人を連れてくる B：この部分は自動化できない部分かもしれない F：それぞれのCPUで動かし、それぞれを統合する際に、どれが問題かを突き止めるのは難しい。 検証を終え、実際に動かすまでが難しい。 最初にCPU間のインタフェースを決めることと疎結合のシステムを作ることが必要。 A：疎結合で、CPU間は通信は発生しないが、メモリへのアクセスはOK。 製品展開になればいろいろ考えられるが、方法論がないので、結局やってみないとわからない。 S:ばらばらに開発してということについて、その場合にはシミュレータもデザインし、 まずシミュレータであわせていく。コストはかかるが、その方が速い。 F：お互いがダミー化してプログラムを開発している。そのダミーを誰が作るかが問題になることもある。 プロトタイプ開発でできたものを利用することで逃げている。 O：Linux on ITRONについて、機能を分けるか、一緒に使うのか、どちらがよいのか？ Q：インフラの装置としては、ハイブリットOSを使うことはあまり考えていない。 しかしLinuxにはリアルタイム性の問題があり、ITRONで解決するというのは今は有効と思う。 A：スケジューラをもう１つ乗せるなどの他の解決法があるか？ Q：触ったやつがあるならそれを使ったほうがよい。 RTLinuxは解決法の１つであろう。 今までの資産をどのように生かすのかを考えると、Linux on ITRONが最良。 A：ITRONのSMP対応はどうなっているか？ L：割込みなどのアーキテクチャがプロセッサごとに変わってくる。 T:各プロセッサが独立しているならいいが、メモリの独立性や排他性がうまくできていないものを マルチコアで動かす場合には、いいアプローチはないか？ B：仮想記憶を持っていないプロセッサを使っていた。 ハードウェアでメモリ保護をしていた。システムのトップレベルで切ってしまう。 S:ハードウェアでの保護がない場合は、ヘッダファイルを変更し、そこでチェックをする。 関数をマクロにし、ラッパーをかぶせる。 A：仮想アドレスを入れるとオーバヘッドが大きくてつらい U:ITRONにもIIMPがあるが、ハードのMMUやMPUを用いるので、マルチプロセッサにした場合には どうなるか保証は出来ない。 A(まとめ)：いろいろあるので皆さんがんばりましょう。 お互い情報を共有しましょう。