拡張SpecCによるソフトウエアアーキテクチャ記述 人数: 10〜20くらい。 ******************************** 「SpecCはアーキテクチャ記述に適しているか」 ---- CCS (Calculus of Communicating Systems [Milner80]) 能動態を主体にものを考える。Agent(作用体)が並列に動くように記述するためのシス テム。state machineはどちらかというとpassive。 SpecCのビヘイビアはCCSの作用体に対応。 組み込みシステムにおける、作用体の最小単位はハードウエアの1クロックサイクルに おける作用。 SpecCはスーパステートの概念を用いることにより、上流からRTLまでの一環開発をねら ってきた。 ソフトウエアアーキテクチャ記述のためにはSpecCは不足することがある。 SpecCからRTLへかけてのシームレス開発技法を求める。 ---- CCS: 状態遷移を式で記述する。 SpecCも同じような感じで図にかく。 --- アクションの意味。 一つの作用体が同じプロセッサ上で新しい作用体に変化する際に起きるアクションの実現。 - データパス経由のメッセージ同期通信とか 平行する二つの作用体の間でおきるアクションの実現。 バッファ経由ランデブー、コールバック、ポーリング --- GajskiのSpecCモデルは、アーキテクチャを表わすか? 要素、要素間通信路、要素間通信路の端子、通信意味の表示が必要 ADL(architecture description language)の出現 パワーポイントはhome pageにおいておく。downloadできるようにします。 --- ADLの例 ACME, Aesop, C2.... --- OOはアーキテクチャを表しにくい。(Luckhan, D,C. 2000) OOでは出口がわかりにくい。インターフェースが決まっているが、中で何を呼んでいるのか 今一つ判り難い。 --- SpecCの図はちょっと判り難い? --- ソフトウエアアーキテクチャを記述するための原始要素はなにか? --- 昔もいまも、組込みの設計手順はかわらない。 --- ADLの標準化をしようとしてる。 Q: SpecCをADLとして使うわけだが、言語拡張と、ライブラリの提供。どちらが必要か? A: 両方組み合わせながら、やるのがいい。 Q: 具体的には? A: ある組込みシステムをSpecCですべて書いて、従来手法と比較して発表を行った。 Q: CCSを用いられるというのだが、関連がよくわからなかった。 A: CCSをもちいる利点は、並列な記述、検証ができる。 Q: モデル検査手法がある。SMV, Spin等のよいツールがある。 Q: CCS, CSP CCSは能動態でシステムを記述。??? ***************************************************** 真のコ・デザインをめざして、の一検討。 問題提起 SWEST1,2,MST2000の議論でわかったこと、たかのさんがどのようにソフトやさんに教育 されたか。初心・現場にかえって再考する。コ・デザインのありかたの一提案。 --- 組込みシステム=SW+HWのはず。 パソコン等とは違って、SWとHWをいっしょに考える必要があるが、お互いの技術者の 理解が足りない。SW, HWも複雑性爆発になやんでいる。ブレイクスルーがほしい。 いっしょに最適化していける手法や枠組みはないのか? -- システムに関する問題認識の差 LSI: システムのキーとなる機能はLSI化されてると思ってる。 S/W屋: システム全体の複雑化でシステム開発が破綻しそう --- デザインとは? LSI: C/C++コードは出発点。 仕様の実行可能性を検証しないといけない 複雑化するLSI検証の枠組みを期待 SW: programはデザインの終着点 複雑性をおさえこむ手段 実行できたらそれは実装 LSIは単なる部品 検証はあきらめてる --- コデザインを目指した提案に対して SW屋のデザインにHWやがおしかけたらどうか? SW: デザインは実装非依存であるべき LSI: 上位での評価は精度がひくい。 批判が多い。 --- でもやっぱり、組込みシステム=SW+HWのはず。 現場のやり方にもどってみると・・・? - ソフトやといっしょにしごとしてる。プログラムもLSIも無い状態で。ゲーム機とか、  車載とか、携帯とか。いつもどんなかんじでやってるか? - 暗黙のうちにやってるのを、明確にする。手順を提供? --- 開発フローを再考すると SWデザイン->実装->検査 スパイラル 検査の段階にLSI,HW評価をいれる。最初は机上やシミュレータで。 プログラミングモデルの例。 ハードウエアをメモリに抽象化。 メインメモリにアクセスする方法が違う。 --- コデザインのイメージ --- 例: 2並列で1/2のクロックにするとか 1周 簡単なモデルで 2周 cache->dma 3周 swを一部hwへ 4周 mp化 --- まとめ プログラミングモデルの存在と翻訳プロセスに注目して、その延長上にコデザインがある。 --- 質問 コデザインの方向足り得るか? LSIの仕様/制約を翻訳するという考え方についてどう思うか? ---- OOの上流デザインをやってる。HW屋さんの折衝はお客さんがやってる。 ソフト屋さんは、OOでレイヤーを作って、HWの差を吸収するようにしてる。 HWの差を吸収するなんてことを考えずに、お互いの仕事を理解しつつ、積極的にお互い 干渉しつつすすめる。 レイヤー化というのは、本質的に抽象度が違うところに適用するのがふつう。 べつに、HWの差を吸収するわけではない。 HWが提供してくれる機能はなに?どんな平行性? ---- HW屋さん。 コデザイン。LSI屋さんが思っているデザインを、SWはデザインと思わないことが、そも そもの問題。LSIのデザインと、SWのデザインはべつべつにやる。でも、お互いによく話 し合って最適に。 ---- ************************************** kVerifier light kVerifier RT&C 検証ツールをつくっている。 XPがはやってる。プログラミングコードとテストコードをいっしょに書く。 テストの視点から、説明する。 CppUnit 問題点: 単体テストで、全体テストは難しい。 FFTライブラリ: テストベクタを与えて、結果。 テストベクタを独立させることによって、いろんなところにもっていける。 テストベクタはひとつのIPとして考えることもできる。 デモ。 全体テストが可能。 回路とRTOSタスク混在シミュレーションが可能。 Q: k-uOSの具体的な機能 A: 1k, 2kとかのメモリちっちゃなときに、タスク機能を提供する。スタック共有とか。