********************************************************************** セッションS2-a チュートリアル1 テーマ:テスト・検証(DAS学会発表) 発表者:  座長:吉田浩章  発表1:松本剛史  発表2:中村祐一  発表3:高西由希子  発表4:井上雅文 日時:2010/9/2 8:35〜10:30 参加人数:40名(終了時) ********************************************************************** -- 質疑応答の記述方法 Q. 質問内容 A. 質問に対する回答 ********************************************************************** 発表1:ループ最適化対する形式的等価性検証手法 -- 概要 実行時間の大部分を占めるループ実行を最適化することで、システム全 体の性能を向上させることができる。 2通りのループ最適化が現在行われている。 1つは自動最適化であり、もう1つが人手によるソースコードの変更であ る。 人手により最適化が行われる場合は、その前後で正しさを検証すること が重要である。 本研究では、2つのループの等価性検証により、最適化の正しさを検証す る手法を提案する。 提案手法では、等価性を検証すべき2つの配列変数について、その任意の 等価なインデックスの要素を表す記号式を作成し、記号式の等価性を判 定する。 本手法では、ループ展開は不要でありループの繰り返し回数が多い場合 に検証時間が長くなる問題の解決にも寄与できる。 また実験により、2つのループが等価であるものには、等価であるとの結 果を得た。 さらに、故意に誤りを含めた2つのループに関しては、等価と照明できな い結果を得た。 -- 質疑応答 Q. ループのときにインダクションを使うということは、仮定が異なると 検証できない場合はあるのか? A. あり得えます。例えば、中間配列を用いる場合がある。また、中間配 列のインデックス間の対応が取れない場合は、等価なのかは検証できな い。 Q. 中間並列を1つの変数で覚えている場合は検証できないですか? A. 難しいです。 Q. 実験結果で過去のものであれば、検証にどの程度の時間がかかってい るのか? A. 繰り返し回数によっては全く検証処理が終わらないものがあった。 Q. データが素直に流れるものを実験に利用しているように見える。SMT ソルバに与えた式は、分岐等を含んだ難しい式なのか? A. SMTソルバに与えているもの式は、配列やループ検証をしている割に は簡単になっている。条件分岐はそれなりの式が必要になります。 Q. 例題で与えたプログラムに、条件分岐は含まれているのか? A. 含まれています Q. 例題のプログラムサイズが大きくなった場合の解析時間はどうなりま すか? A. ループのボディが100行くらいまでなら大丈夫だと思います。 1000行になると難しいと思います。 ********************************************************************** 発表2:信号処理回路に対するSystemCとRTLレベのテストベンチ共用化 -- 概要 近年の設計手法では、C言語やSystemCなどの上流設計記述でモデル化、 シミュレーションを行ったのちに、RTL(Register Transfer Level)の設 計を行う。 このような設計手法では、各段階での等価性検証が必要である。 本研究では、C言語で記述されたアルゴリズムモデルに対する検証環境を、 より抽象度の低いSystemCモデル、RTLモデルにもそのまま利用して検証 することができるプラットフォームを提案する。 このプラットフォームでは、抽象度の高いときに不足しているタイミン グ情報を生成できるシンクロナイザにより、抽象度の低いモデルのタイ ミング情報をシミュレーション環境中に挿入することで、テストベンチ の共用化を実現する。 信号処理回路に対して検証を行った実験では、テストベンチ改変不要の SYstemC/RTLの検証実行を実証した。 -- 質疑応答 Q. SystemCだとトランザクションレベルなど、タイミング精度によりレ ベルが変わると思います。今回は2つのモデルを利用し、そのモデル間で 通信をしていると思いますが、その間のタイミングはどのように記述し ているのか? A. sc_fifoをそのまま利用している。基本的には機能合成ツールで合成 できるレベルのものを用いている。 Q. Cで書くとき、出力を見てから次の入力を与える場合等は、一般的に テストベンチの作成は難しいのでないか? A. テストベンチが連続してストリームのように入力されることを前提と しています。 Q. Cの書き方を工夫しているが、アーキテクチャ専門の設計者がやろう と思えばできるものですか? A. A4で3ページの仕様書です。あらかじめアーキテクチャ設計者さんに 作った仕様書は3ページであり、その内容は、ピンの資料と並列動作のと きに2つのモデルに分けるものです。 タイミングでバッファを入れること以外は仕様書の変更なしに可能です。 ********************************************************************** 発表3:ソフトウェア/ハードウェア協調シミュレータの一考察 -- 概要 近年のSoCの普及に伴い、ソフトウェア/ハードウェアの協調設計が必要 であることから、ソフトウェア/ハードウェア協調シミュレータの考察を 行った。 本シミュレータは、FPGAボードとPCがPCIバスを通じて接続されている。 PCではSimulinkプログラムを使用しシステムの記述を行い、Simulinkの ブロック図内のS-functionとFPGAボードへスムーズへ置き換える。 プログラムにより、システムアーキテクチャとハードウェアを容易に書 き換えることができるため、システムアーキテクチャの最適化とLSI設計 を同時に進行させることができる。 本手法を画像協調アルゴリズムに対して適用し、ハードウェアの実行途 中におけるシステムアウトプットのモニタ機能や、フィルタ構造の決定 などの利点を明らかにした。 また、スムーズにFPGAへ変換することができるため、シミュレーション 時間が高速化された。 -- 質疑応答 Q. FPGA内部の信号をみることはできますか? A. simlinkからFPGA内部の信号をみることはできません。処理結果から 判断するしかないです。小さなブロックからFPGA上へハードウェア化す るため、ボトルネック部分は比較的容易に特定しやすいと思います。 Q. s-functionをRTLに変換後、シミュレーションした場合に10日ほどか かったのか? A. その通りです。 Q. FPGAに対応させるにはどのくらいの時間がかかるのか? A. 0.6秒はs-functionをその言語のままシミュレーションした場合です。 Q. どの時間が何に対応するかわかりずらかったので教えてください。 A. SFFに置き換えて、FPGAで処理すると0.4秒です。これをSFFに置き換 えずに、ソフトウェアの状態でハードウェアを考えずにシミュレーショ ンすると0.6秒です。RTLをシミュレーションすると10日ほどかかるます。 Q. s-function単位でFPGAに変換した理由は?全体をFPGAに置き換えるこ とは考えなかったのか? A. 小さい単位で確実にLSI化するためです。全てをFPGAに置き換えてし まうと、バグがある場合に、どこかバグか分かりづらくなります。 - 共著の方が発言 1. FPGAのバグについて FPGAのバグを調べる機構は実装されています。 2.シミュレーション時間について simlink単独でのシミュレーションするのと同じスピードで、一部をハー ドウェアモデルにした場合のシミュレーションが可能になることが重要 です。 Q. 他の画像処理アルゴリズムを使うなど、タイミング制約などがある場 合は対応できるのか? A. 他のアルゴリズムに対し適用していないので分かりません Q. 今回の成果でハードウェア部分にどのくらいの時間がかかるかは把握 できますか? A.可能です。 Q. verilog部分を変更することは可能ですか? A. 可能です。 Q. FPGAのデバッグ機能はxilinxの機能ですか? A. 独自で実装したデバッグ機能です。デバッグ情報をmatlabから見るこ とができます。仕組みとしては、同期しながら内部情報をダンプしてい ます。 ********************************************************************** 発表4:エラー検出回復方式回路の回路構成と性能に関するシミュレーショ ン評価 -- 概要 通常の回路では、データパスでの遅延エラーは許容できない。 このため、正常な回路処理を保証するために、クロック周期を最大遅延 時間以上に設定する。 一方、エラー検出回復方式では、正常な回路処理はエラー検出回復機構 により保証され、遅延エラーは許容されるため、クロック周期を最大遅 延未満に設定することが可能となる。 そのため、回路性能はクロック周期削減により処理時間の削減が、遅延 エラーが発生した際の回復処理にかかる時間損失を上回る場合に向上す る。 本発表では、エラー検出回復方式について、その回路構成と動的制約の 検討した。 さらに、加算器への適用についてモデルシミュレーションを行い、回路 動作の正当性および、完全同期式に比べ、最大で11%の速度性能の向上 を確認した。 -- 質疑応答 Q. クロック周期を短くしていったときに、エラーの発生率はどの程度増 加していくのか? A. 限界までクロックを下げると約10%くらい、10回に1回くらいはエラー が発生します。 Q. エラーが起きたときの動作はどうなっていますか? A. 我々が使用しているモデルでは、次の周期にリストアし、さらに次の 周期に回復します。 Q. 32個の加算器をつなげていて、エラーが1つのビットで発生し、他の ビットの処理が全て停止しない場合、大変なことになりますよね? A. その通りです。現在は、1ビットでもエラーが発生すると、すべての 計算をやり直しています。 Q. 従来の研究成果と比べ、今回の結果の位置づけはどうなっていますか? A. 理論的にどのような回路に対しても、本手法が適用できることを証明 したいです。 Q. 今回は特定の回路に対して、11%といった結果を得ていますが、最終 的な一般的に適用して行く場合、今回の結果はどのような位置づけにな りますか。 A. わかりません - 共著の方が回答:エラーの検出方法を確立するなど、プラットフォー ムの構築と今後の研究のための下準備のために評価を行いました。 ********************************************************************** -- まとめ 4件の研究発表それぞれに対し、多くの質問があり、有意義な議論が行わ れた。 -- 以上。