ミシガン大、CPUの未知のエラッタを回避する技術を開発 25
ストーリー by soara
CPUでもセーフモード 部門より
CPUでもセーフモード 部門より
ミシガン大学のValeria Bertacco准教授のグループは、CPUに含まれる構造的欠陥（エラッタ）を回避する技術「semantic guardian」を開発した（Technology Reviewの記事、論文のPDF）。このsemantic guardianは、CPUに組み込まれた監視機能で、CPUがテストされている条件下でのみ動作するように制御するというもの。テストされてない状況でCPUが活動しそうになった場合、semantic guardianがテスト済みの状況で活動するようにCPUのモードを変更する。これにより、未知のエラッタにも対応できるようになるため、製品リリース前のテストに費やされている時間及びコストを削減できるという。
CPUのエラッタと言えばAMDのBarcelonaに存在したTLBエラッタが記憶に新しいが、こうした技術が組み込まれていればあのリリース前後のゴタゴタも避けられたのかもしれない。
まちがってたら ごめんね (スコア:1, 興味深い)
un-trusted状態になったら
形式的検証のされた
シングルスカラ実行に切り替える、
みたいな
遅くなる？
当たり前じゃん
キモは
un-trusted状態の検出ロジックを
自動で合成する
ことかな
Re:まちがってたら ごめんね (スコア:1, おもしろおかしい)
新たに検証されたtrusted-stateを
オンチップRAMかなんかに追加できる
みたいな
わたし？
ミント
12さい
既にやっているのでは？ (スコア: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年半なのかわかりませんが、致命的な遅れになることも多いでしょう。
エラッタの意味 (スコア:1, すばらしい洞察)
エラッタの意味を勘違いしていないか? エラッタは正誤表という意味だよ。
ハードのバグなどによって、データシートに修正があったときにメーカーが発行するのがエラッタ。
「xxxにエラッタが出た」と言うのはバグが出たと言っているのではなくて、文書が発行されたということ。
Re:エラッタの意味 (スコア:1, すばらしい洞察)
単数形のerratumは
1. an error in writing or printing.
2. a statement of an error and its correction inserted, usually on a separate page or slip of paper, in a book or other publication; corrigendum.
Re:エラッタの意味 (スコア:1)
タレコミ子が勘違いしているんだと思う。
1.に書いてある通り、erratumは誤字とか印刷ミスのことで、
広い意味でのエラーを表す意味で使われることはめったにない。
少なくとも、ハードウェアの欠陥を表す意味で使われているのを見たことは経験上無い。
まあ、ふつうに2.の意味でしょ。
念のため、リンク先の記事も論文も見てみたが、
errataを欠陥の意味で使っている箇所は無かった。
Re: (スコア:0)
修正をエラッタと呼ぶのなら、修正の対象もエラッタと呼ばれても何の問題もない。
"CPU errata"で検索すると用例がいろいろでてくるよ。
CPUベンダー以外の用例は認めないってことはないよね？
Re: (スコア:0)
いや呼ばない。普通エラッタは正誤表のこと。
> "CPU errata"
君がその用例をもって何を主張したいのか不明だが、それはCPUの正誤表って意味。
Re:エラッタの意味 (スコア:1)
1) まずbugが見つかって、それを製造者がエラッタとして発表する
2) 一般の学術誌での使われ方では、正誤表という意味ではない。訂正、かな。
客観的にはバグでも、お客さんから見たら単なる粗相だと。タレコミみたいに第三者がエラッタと呼ぶのは、やや違和感あります。
Re:エラッタの意味 (スコア:1)
"Errata are design defects or errors."
と定義されている。
つまりこういうことですね (スコア:0, おもしろおかしい)
「あ...ごめんなさい。それ、来月からなんですよ」
「じゃこの煮込み雑煮を」
「ですからごめんなさい お雑煮も来月からなんですよ 冬場だけのメニューでしてどうも」
Re:つまりこういうことですね (スコア:1)
Re: (スコア:0)
Re: (スコア:0)
特定の条件下で有効になるというだけで
Re: (スコア:0)
「餃子ライスか定食できますか？」
「ウチはライスやってないんだ」
「じゃあ 餃子と大盛り焼きそばください」
の方がたとえ話としては向いている気がする。
ニュースソースをちゃんと読んでからタレ込んで (スコア:0)
> こうした技術が組み込まれていればあのリリース前後のゴタゴタも避けられたのかもしれない。
ニュースソースには実用化には程遠いとあるので、Barcelonaに組込めるはずもありません。
Re: (スコア:0)
タレコミ者は「この技術があれば、例えば過去にあった○○○のような問題が解決する」と
読者に判ってもらうために例示を示してるんだよ。
そんな配慮に気づきもせず人の悪口を放言する前に、日本語を読む能力をつけろよ。