アカウント名:
パスワード:
たとえば、現在テストに3カ月かかっていて、倍の6か月かけてしまうと新製品供給の遅れが販売政策上許容できないとかそういうレベルの「半分」なんですか?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ソースを見ろ -- ある4桁UID
既にやっているのでは? (スコア:1)
Re:既にやっているのでは? (スコア:2, 参考になる)
これまでのCPU
バグはブラックリストで回避。
製造後に検証してバグが見つかれば、ブラックリストに追加し、修正用のマイクロコードを追加する。
ブラックリストが増えれば増えるほど、回避用のコードに分岐する可能性が増えて遅くなる。
提案されているCPU
バグはホワイトリストで回避。
製造後に検証して安全な状態が見つかれば、ホワイトリストに追加する。
ホワイトリストが増えれば増えるほど、回避用のコードに分岐する可能性が減って速くなる。
AMDのBarcelonaは前者の回避方法なので、マイクロコードで修正したけど、とっても遅くなりました。
前者の回避方法で速度を落とさないためには、バグをつぶして設計しなおす必要があります。
後者の場合、検証の作業量が問題でしょうね。
論文では、in-orderの簡単なCPUなら、2000個のホワイトリストで数%の面積増、
5%のパフォーマンスロスとなっています。
これが最近の複雑なCPUだと、どれだけのホワイトリストが必要なのか。
組み込み向けCPUなら状態数が比較的少ないですし、出荷時のホワイトリストで
パフォーマンス上問題がなければ、出荷後に修正が必要ない(そして速度が落ちない)
このの方式が向いているのかもしれません。
Re:既にやっているのでは? (スコア:2, 参考になる)
Re:既にやっているのでは? (スコア:1)
現状では、設計時に定義した仕様どおりに動いているかどうかをなんとか検証できているぐらいです。
それもすべての組み合わせができているわけではなく、こういうテストベンチなら網羅できるだろうという、
各社のノウハウによって検証数を減らして対応しています。
そんな状況でもホワイトリストが有効なのは、ソフトウェアと同じく、
ハードウェアでも回路状態の局所性があるからです。
ほとんどの場合、少数の状態しか取らないので、その状態をホワイトリストに入れましょう。
リストから外れた状態を取ったら、パイプラインを空にしてもう一度実行しましょう。
ホワイトリストから外れる可能性は低いので、パイプラインを空にしても全体に対する
速度のロスは小さい。
こんな感じでしょうか。
CPUのキャッシュメモリをイメージすれば、近いかもしれません。
理想的には1次キャッシュにすべてのコードが収まれば良いですが、無理ですよね。
1次キャッシュは多くても128kBぐらいしかないですが、ほとんどのコードはそこに収まるので、
速度のロスは小さいです。
Re: (スコア:0)
これには膨大な手間がかかるので、なんとか避けたいというのが論文の目的なわけですが。
テストケースは当然設計時に全部求まっています。
半分のケースだけ検証して出荷、残りの半分は後から検証するということです。
Re:既にやっているのでは? (スコア:1)
たとえば、現在テストに3カ月かかっていて、倍の6か月かけてしまうと新製品供給の遅れが販売政策上許容できないとかそういうレベルの「半分」なんですか?
Re: (スコア:0)
> 半分のケースが検証できるのなら、検証時間を倍にすれば全ケースチェックできる(?)。
倍なのか10倍なのかそれ以上なのかわかりませんが(元の回路規模にも依存します)、非常に検証時間をかければ全ケースチェックできるでしょう。
全チェックは現実的には無理です。Barcelonaもそうですが、現実のプロセッサも全ケースについてチェックなんてしていません。
ってあなた、組み合わせ回路の検証の大変さを知らないの?
> たとえば、現在テストに3カ月かかっていて、倍の6か月かけてしまうと新製品供給の遅れが販売政策上許容できないとかそういうレベルの「半分」なんですか?
倍の6ヶ月なのか10倍の2年半なのかわかりませんが、致命的な遅れになることも多いでしょう。