例えば、デリミタが標準のEOIの場合はこんな感じだ。
（コントローラ、トーカ、リスナが別デバイスの場合）
ベクタはこんな感じ。
コントローラ
トーカ
リスナ
デリミタがCRの場合
デリミタがデータ数の場合
（このベクタでは256に設定している。）
上記は、コントローラ、トーカ、リスナはそれぞれ別のデバイスとしていた。
これに対し、以下はコントローラがリスナまたはトーカでもある場合。
トーカ
リスナ
次は、パラレルポールの動作である。
パラレルポールを使う場合、コントローラは予めPPEコマンドで各装置にステータスを出す信号線を設定する必要がある。
このベクタでは、station_2, 3, 4にそれぞれbit 1,2,4の信号線を割り当て、SRQ（service request）はstation_2が発生するというシナリオでシミュレーションを行う。以下の縦線で挟まっている部分がコントローラがパラレルポールを行っている部分で、DIOのbit 2のみが0になっている。つまり、station_2のみが信号線を0にドライブしている。コントローラ側のプログラムはDIOの0になっているbitを探して、そこを割り当てている装置に対してシリアルポールを行う。以下ではstation_2に対してシリアルポールしているので期待通りの動作である。
こんな感じで検証を行ったが、一つ一つ波形で見ていくのは大変なので、可能なものはなるべくOVAちっくにシミュレーションベクタ内でチェックするようにした。例えば、チェックの結果が良の場合は以下のようにGOODのメッセージを表示し、エラーの場合はERRORメッセージを表示する。
ベクタはこんな感じで書いている。
また、今回は仕様が若干複雑なので、念のためCoveredでコードカバレッジを計測しながら検証作業を進めた。Covered（http://covered.sourceforge.net/）はTrevor Williams氏が開発し、GPLで公開しているコードカバレッジツールだ。
私は通常、プロジェクトのディレクトリ階層を以下のような構造にしている。
sim/がシミュレーション関係のディレクトリで、上層のsim/は単体検証用、implement_X下のは各インプリメンテーションの全体検証用である。テストベンチはtbench下に、ベクタはvect下にそれぞれ配置され、シミュレーションの実行はsim_execで行う。このディレクトリにはシミュレーション実行のためのスクリプト（do_sim）があり、do_sim {オプション} ベクタ名のような感じで実行する。
このスクリプトでcoveredを実行してコードカバレッジも計測できるようにしてある。
例えば、以下のように実行する。
do_sim -cov ... を実行するとsim_execディレクトリ下にcov/というディレクトリが作られ、そこにカバレッジデータが格納される。
カバレッジデータはベクタ単位のデータのため、最後にこれらをマージしてレポート化する必要がある。これは手操作で行う。 covered merge -o all.cdd cov/* がマージのためのコマンドであり、この場合、all.cddにマージした結果が出力される。
次に、all.cddからレポートを作成する。
そうして得られたレポートが以下である。
・ラインカバレッジ。
3箇所カバーされていない箇所があるが、これはcase文のdefault記述の部分で通常ここがヒットすることは無い。したがって、ラインカバレッジとしては100%と考えても問題ないだろう。
・トグルカバレッジ。
見れていないのは殆どがデータレジスタ等の任意のビットなので、値が振れていないということなんだろうが、振る舞いに関わる箇所ではなくて、ペイロードの中身の部分なので現状でもとくに問題ないかなと思う。
・組み合わせ回路のカバレッジ。
これも、現状でもとくに問題ないレベルだと思う。
ここに至までに、仕様追加やバグ修正等もあったので、問題なく合成できるかを確認した。
リソースの使用率は70%になった。前回は69%だったので若干増加している。
タイミングはMetしている。
0 件のコメント:
コメントを投稿