アカウント名:
パスワード:
HDL みたいにシミュレーションで期待値チェックっていう開発手法をソフトウェアがとりずらいのはよくわかるが、COBOL時代のソフトでも入出力さえ一致すればいいとかではないのかな。（相手がある）通信とか人間の入力待ちとかもCOBOLで書いてある？
ソフトウェアテストでカバレッジ100%は目指すなとか何処かに書いてあったことは、門外漢の俺でも知っている
HDLだって、組み合わせ論理しかないなら楽だろうが、ステートが複雑ならテストも大変じゃねーのかねえ。CPUとか
まあそう言うことを言いたいのかもイマイチワカランけれど
期待値チェックはやりますが、(ユニット)テスト自動化でしかない。ソフトと同じ。なにがやりにくいのか？ ユニットテスト自動化とかしないの？(HDL開発でもユニットテスト手動化という手法はありますw)
HDLは内部状態の波形とか見たりダンプして比較したりするツールは充実してますけどね。それはふつうデバッグ用途で検証用には使わんでしょ。データ量が無駄に大きすぎるし、微妙な修正でも期待値が一気に変わってめんどくさすぎる。
けっきょくHDLで書くハードウェアロジックは、ソフトより比較的複雑じゃないんです。がんばって1週間以上かけて書いたHDLのモジュールと、ちゃちゃって書いたソフトの関数の複雑度が同じくらいだから、HDLはユニットテストが比較的広範囲に適用できているように見えるんです。入力端子に人間がくっついたりしないというのが大きいと思う。
横だが、HDLで開発する際には、タイミングとは別に論理だけのチェックはやるよ。テストベンチとか書く
それはソフトと同じでしょう？ソフトでもなにもやりにくくないし、じっさいやられている。
いや波形とか見たりダンプして比較したりするだけじゃないよね、と言うコメントを返しただけだが
DRPみたいなリコンフィグアラブルプロセッサのテストってどうやるんだろう。
ソフトは1000件コピーされてもすべて同一だけど、LSIは1000個作ったら製造不良なんかで個別に不良がでるから、それを選別するために結構詳細な期待値チェック書くはずだよ。テストは開発手法と同時に品質保証ツールでもある。
＞複雑度・・・思わず納得しそうになったが、どうなんだろう。
半導体製品の設計時に行う論理検証用と製造時に行う出荷試験用のテストパターンは別物だよ論理検証は設計時にしか行わないしバグの発生が許されないから動作のダブリなんか気にせず徹底的に行う製造試験は故障検出率が高くて短いパターンにすることが優先で全部の動作モードで動かすことなんか考えていない回路の正さは論理検証で保証してあるから製造したトランジスタと配線がきちんと作られていることだけ確認できればいい
今話題になっているのは論理検証の方だけど、そんな長大なテストパターンは1秒何円でコスト計算される製造試験では使えない
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stay hungry, Stay foolish. -- Steven Paul Jobs
HDLみたいに (スコア:0)
HDL みたいにシミュレーションで期待値チェックっていう開発手法をソフトウェアがとりずらいのはよくわかるが、COBOL時代のソフトでも入出力さえ一致すればいいとかではないのかな。
（相手がある）通信とか人間の入力待ちとかもCOBOLで書いてある？
Re:HDLみたいに (スコア:1)
ソフトウェアテストでカバレッジ100%は目指すなとか何処かに書いてあったことは、門外漢の俺でも知っている
HDLだって、組み合わせ論理しかないなら楽だろうが、ステートが複雑ならテストも大変じゃねーのかねえ。CPUとか
まあそう言うことを言いたいのかもイマイチワカランけれど
Re: (スコア:0)
期待値チェックはやりますが、(ユニット)テスト自動化でしかない。
ソフトと同じ。なにがやりにくいのか？ ユニットテスト自動化とかしないの？
(HDL開発でもユニットテスト手動化という手法はありますw)
HDLは内部状態の波形とか見たりダンプして比較したりするツールは充実してますけどね。
それはふつうデバッグ用途で検証用には使わんでしょ。
データ量が無駄に大きすぎるし、微妙な修正でも期待値が一気に変わってめんどくさすぎる。
けっきょくHDLで書くハードウェアロジックは、ソフトより比較的複雑じゃないんです。
がんばって1週間以上かけて書いたHDLのモジュールと、ちゃちゃって書いたソフトの関数の
複雑度が同じくらいだから、HDLはユニットテストが比較的広範囲に適用できているように
見えるんです。
入力端子に人間がくっついたりしないというのが大きいと思う。
Re: (スコア:0)
横だが、HDLで開発する際には、タイミングとは別に論理だけのチェックはやるよ。テストベンチとか書く
Re: (スコア:0)
それはソフトと同じでしょう？
ソフトでもなにもやりにくくないし、じっさいやられている。
Re: (スコア:0)
いや波形とか見たりダンプして比較したりするだけじゃないよね、と言うコメントを返しただけだが
Re: (スコア:0)
DRPみたいなリコンフィグアラブルプロセッサのテストってどうやるんだろう。
Re: (スコア:0)
ソフトは1000件コピーされてもすべて同一だけど、LSIは1000個作ったら
製造不良なんかで個別に不良がでるから、それを選別するために
結構詳細な期待値チェック書くはずだよ。
テストは開発手法と同時に品質保証ツールでもある。
＞複雑度・・・
思わず納得しそうになったが、どうなんだろう。
Re: (スコア:0)
半導体製品の設計時に行う論理検証用と製造時に行う出荷試験用のテストパターンは別物だよ
論理検証は設計時にしか行わないしバグの発生が許されないから動作のダブリなんか気にせず徹底的に行う
製造試験は故障検出率が高くて短いパターンにすることが優先で全部の動作モードで動かすことなんか考えていない
回路の正さは論理検証で保証してあるから製造したトランジスタと配線がきちんと作られていることだけ確認できればいい
今話題になっているのは論理検証の方だけど、そんな長大なテストパターンは1秒何円でコスト計算される製造試験では使えない