SWEST2 セッション4B 会場：No.4（60席）参加者：13名 ----------------------------------------------------------------------------- 中西恒夫：コードサイズ縮小のためのプロセッサと目的コード生成システム ----------------------------------------------------------------------------- プロセッサHDLとその上で動作するオブジェクトコードのコジェネレータを開発中。組込み機器分野でのコスト意識、システムオンチップでの利用などから、速度面と同様にコード圧縮は重要。 Fraserの頭部共通化に対して、尾部共有の手法を提案。辞書式の展開注入型圧縮と、論理合成して回路化してしまう方法を併用する。 Strength Reductionについての説明はあとで行われた。予備実験についてかなりの圧縮がZ80を用いて検出された。今後は他のCPUにおても調査してみたい。 JAVAのバーチャルマシンにおいては短い頻出命令列がたくさん見つかるため、圧縮等のアルゴリズムを変更する必要有。 -QandA / Comment----- 1) コードのコストをハードへ移行しているのだが、タイミング等の問題も考慮したほうが良いのでは？ゲート数の増加も検証する必要あり。 2) ファンクションコールのオーバーヘッドを削減するために、プロセッサが大きくなるのは外部と内部でコストが大幅に違うことを考えると効果が悪いのでは？ 3) パイプラインにするのはかなり大変ではないか？ 4) 例外処理や割り込みについては、サブのPCをいれるなどの方法を考えている。以上 5) コード圧縮に適した命令セットがあるか検証しては？他のCPUも交えて統計的に考察したい ----------------------------------------------------------------------------- Victor M.Goulart：Concerns about High Functionality IP Cores in a System with Functional Redundancy ----------------------------------------------------------------------------- システムにおいてソフトウェアは非常に重要であるが、それだけでは高性能は狙えず、高速なハードウェアに頼る必要がある。このHWとSWを協調設計する際に、HW/SWの機能分割が大きな問題となる。また、LSI上に搭載可能なトランジスタ数は飛躍的に増加しており、IPコアベースの設計は不可欠になってきている。ゲート容量とスイッチ回数で消費電力は決定される。従って、素子レベルの消費を抑えたり、電圧可変にしたり、電源供給のカットオフを可変にしたりして、これらを動的にスケジューリングしたり機能制限をする事によって電力を抑える。動作周波数をさげると同じ処理を少ない電力でできる。システムの使っていない部分に電力を送らないようにする。バスの未使用部分をカットしたりIPコア単位でカットしたりする。レジスタを使って動的なカットオフも行う。同じ機能をより電力消費の少ないコアで行う。(これは動作が遅い場合が多い) 同じ機能に異なる複数のコアを用意する。目的に応じて機能を切り替える。チップの面積次第でシステムに実装するコアを選択する。低機能なコアから高機能なコアまで用意する。ただし、プロトコルやインターフェースの違いというIPコアと同じ問題を抱える。タスクをスケジューリングチェックポイントでコードセクションに分割する。 -QandA / Comment----- 1) コアを動的に変更する立場からコンパイラに要望などはあるか？コンパイル処理が複雑になってもコアの切り替えなどを意識したコンパイラが必要。 2) 商業的に見てチップに同じ機能のコアを複数持たせる意味はあるのか？チップでもっとも大きくなるのはメモリだからコアによるロスは考慮する必要は少ない。 3) こうしたアプローチが有効になるにはOSが対応することが必要だが、特に意識しているOSがあるか？タスクスケジューリングが複雑になるし、システムの振る舞いを設計者が把握すれば OSの助けは重要ではない。 ---------------------------------------------------------------------------- 小林憲次：テストベクターを使った検証ツール ---------------------------------------------------------------------------- 既存ツールとの比較アプリケーションのコードの最後にテストベクタとベリファイに関する記述をするのでソースは乱さない。コンパイル時にライブラリとリンクして実行ファイルを作成する。プログラマーがループ同期構造などは保証する必要あり。言語レベルで高速シミュレーション可能。テストベクタは再利用可能。既存のソフト資産を流用可能。 -QandA / Comment----- 1) RTOSを使う場合は例えばWindows上ならクロックベースのスレッドを立ち上げるのか？そうなる。 2) Windows上の別スレッドから割込みを発生させてのでバックは可能か？割り込みとしてはテストベクタの中に記述して呼び出すことになる。 3) タスク間のフローの流れはどうなるのか？なんらかの割り込みが入ってコンテキストスイッチが生じる。 4) ハードを設計するときにデータが届く時間を守ってテストベクタを作るが、ソフトウェアの検証ではタイミングが変わっても許されるのか？おかしなタイミングで割り込みなどが入って暴走する場合などもある。そうしたことが起きないように設計してあるべき。 5) テストカバレッジで100%をどう保証するか？割り込みを呼び出してるのはメインループから切り替わるとき。？？？ 6) 高位言語でのシミュレータだと、実行環境による差異を考慮すべきでは？理想論では多重割り込みなどは使わないほうがよい。 7) 現実に割り込みに優先度があるのにそれを考慮しないでシミュレートしても意味があるのか？テスト時はあきらめてもいいのではないか。 8) ループは常にアトミックなものと捕らえてるとしか思えない？プログラマーが同質性を保証しろという考え。 9) シミュレータの有効性はどの程度あるのか？ 90%以上ある。タイミングなどがシビアな分は実機でシミュレートすべき。 -- 以上