日記帳だ! with Tux on Libserver

二度目の大改造!! 日記帳…か?を継承し、より柔軟でパワフルなBlogに変身しました。

RSSに対応しています。リンク・コメント・トラックバックは自由にしていただいてほぼ問題ありません。
RSS購読方法、僕のリンク・コメント・トラックバックについての考えを読むことをおすすめします。

シミュレーションをするのが仕事

最近、論理回路の修正をいろいろやっている。

ここまで修正内容はHDLをちょこっといじるだけなのだが、

それで正しく動作するか確認するシミュレーションを作らないといけない。

修正内容はちょっとだけど、シミュレーションを書くのは意外とめんどくさい。


例えば、既存の回路には入力Aと入力Bがあるタイミング関係で入力されると、異常な動作をしていたとする。

こういう問題はある信号の生成条件にANDで信号を1つ加えるだけとか、そういうちょっとした修正で直せるが、

これが確かに直ったか確認するためのシミュレーションではいろいろ考えないといけない。

まず事前条件があるならば、その条件を満たすように操作が必要かも知れない。

ある内部状態のときしか起きないのならば、その状態まで持っていく記述が必要になる。

その上で、入力Aと入力Bのタイミングを適切に設定しないといけない。

そして、出力を見るわけだが、どういう出力を見れれば直ったことを確認出来るか考えないといけない。

異常な動作をしていても、正常な動作をしていても出力が変わらないのでは役に立たない。

差が付くように事前条件を付ける必要があるかも知れない。

異常だと期待値がこれ、正常だと期待値がこれ、など考えて区別が付くようにしないといけないと。


「ここの行を修正して、このシミュレーション通ればOKだから」と渡されたことがあって、

ソースコード直して、シミュレーションを回すと確かにOKだったのだが、

修正前でもシミュレーションがOKになってしまうということがあった。

なんか事前条件が間違えていて、修正前でも正常に動くパターンになっていたようで。

修正部分がわかっていて、確認方法もわかってるから、中身知らなくてもとりあえず大丈夫だろ、

と今の仕事をし始めて間もない頃に渡されたのだが、思いの外難儀した。


少なくともそういうミスをしてはいかんなということで、修正後に通るのはもちろん、修正前に失敗することは確認している。

これで修正が利いていることは確認出来るシミュレーションになっていることは確実だ。

ただ、そのシミュレーションが網羅的に機能を確認出来るかどうかが別問題で、もれなく抜けなくやらないといけない。

異常検出機能を追加して、異常を検出できることは確認したけど、

よく考えたら異常から復帰できることは確認してない(仕様上は異常検出→中断→自動リセット→再開可能)ということに気づいて、

シミュレーションに追加したというエピソードがある。

再開は問題なくできたけど、別の問題を発見してしまい、追加で変更をするはめになってしまったが。

異常発生タイミングによって再開できたりできなかったりということがあっては困るということで、

異常発生方法を2つに場合分けしたら発見してしまったと。元のシミュレーションの異常発生タイミングがおかしかったのだ。


ソースを書いては、シミュレーションを書いてというのは論理回路設計に特有のことのような気がする。

実機で動いているときに多数の信号波形を見ることはなかなか難しいし、ましてや内部信号の波形なんて見ようが無い。

FPGAならともかくカスタムICだと作り直しが難しいとか、そういうところもシミュレーションに力を入れる理由にはあるんだろうが、

それを抜きにしても論理回路の挙動は実機で容易にわかるものではない。

ソフトウェアならばデバッガを使ってやれば、内部の値も見ることができる。

それで内部状態も見ながらデバッグできるならそれでいいわけだし。

網羅的にあれこれテストしようとするとソフトウェアでもテスト書いてあれこれというのはあるんだろうけどさ。

今までそういうことをやった経験はないんだが。


Author : hidemaro
Date : 2016/06/24(Fri) 23:55
電気・数学・物理 | Comment | trackback (0)

Tools