とはいえ、一日に一度しかし実行できない昔の計算機と、コンパイル等に数時 間かかるとはいえシミュレーションや実行は何度でもできる FPGA ではデバッ グのしかたは根本的に違う。

例えば、通信路のハードウェアエラーをチェックする回路を作ったとしよう。 これが正しく動作しているかどうかを調べるためには、人為的にハードウェア エラーを起こして、それが検出されるかどうかを調べる必要がある。

このチェックをするのに、以下のようなことをしているのをみたことがある。

1. 常にエラーを出すようにハードウェアを書き換える。

2. コンパイル、起動、実行してエラー検出ができることをチェックする。

3. エラーをださない回路に戻す。

間違っていた理由は簡単で、上のやり方では可能なエラーパターンのうち1つ だけしかみていなかったが、実際の回路では15箇所くらいから出るエラーを 2ビットに縮約したエラー状態をチェックするようになっていた、ということ である。この15箇所が全てエラーを出した場合のみのチェックをしていた。

このようなやり方になったのは、ハードウェアを変更してエラーを出す、とい うやり方では、本来チェックするべき多様なエラーパターンをチェックするの にはあまりに長い時間がかかる、と意識的になり無意識になり思ったからであ ろう、と想像される。

どのような回路にするべきであったか、というと、外部からのレジスタへの書 き込み等で、ハードウェアを変更しなくても任意のエラーパターンを出すこと ができるような回路にして、それらが正しく検出できるかどうかをテストする、 というのが最低限するべきことである。問題の回路はパリティ生成回路なので、 単純にパリティビット毎に even か odd かを指定するフラグをつける、とい うか、回路的にはレジスタと xor 1つをつけるだけである。

このように、チェックをつける回路をいれても規模・速度的に問題にならない なら、いれておくのが正しいやり方である。あるパターンのエラーを発生させる ためだけのために FPGA の回路を変更する、という方法では、エラーパターン を網羅することが不可能なだけでなく、後でテストしたくなったらまたコンパ イルからやり直しになるからである。

なお、このように後からまたテストするためには、テスト自体が自動化されて いることが必須である。つまり、基本的にスクリプトをパラメータなしで 走らせて、スクリプト自体が出力結果があっているか間違っているか判定でき ないといけない。