gm300の日記: 過剰品質 vs SONY timer 2
日記 by
gm300
http://techon.nikkeibp.co.jp/article/NEWS/20100703/183963/?P=2
言っていることの大筋は、きっと正しい。
でも、過剰部分をどう見積もるか、果たして正しく見積もっているのか?という点が抜けているんじゃない?
100年使えるDRAMって一言いっても難しい。全品が100年ちょうど持つなら、本当に過剰なんだろう。
しかし、機械系では、平均故障間隔とか、平均故障時間を使う。
平均100年なら、100個使っているシステムでは、大体一年で、使えなくなる。
http://techon.nikkeibp.co.jp/article/NEWS/20100703/183963/?SS=imgview&FD=1327670156
この左側の段々構造が何を意味しているか、はっきり説明されていないが、きっと設計の各段階でマージンをとるからそれを重ねると悲惨よ。右の図は、全体がよく見えていれば、冗長な部分の保障を薄くして、回避不可能な点のみしっかり保障という流れなんだろう。
まあ、設計の前段階をソニーの同じチームで行えばできるんだろうけどな。
知らないうちにマージンが積み重なるというのは、真である。しかし問題はそこじゃない。同じ理由で、知らないうちにマージンが無くなってしまう。 というのも真なのだ。悲しいけど、マージンは見えないが、故障は目立つ。
言っていることの大筋は、きっと正しい。
でも、過剰部分をどう見積もるか、果たして正しく見積もっているのか?という点が抜けているんじゃない?
100年使えるDRAMって一言いっても難しい。全品が100年ちょうど持つなら、本当に過剰なんだろう。
しかし、機械系では、平均故障間隔とか、平均故障時間を使う。
平均100年なら、100個使っているシステムでは、大体一年で、使えなくなる。
http://techon.nikkeibp.co.jp/article/NEWS/20100703/183963/?SS=imgview&FD=1327670156
この左側の段々構造が何を意味しているか、はっきり説明されていないが、きっと設計の各段階でマージンをとるからそれを重ねると悲惨よ。右の図は、全体がよく見えていれば、冗長な部分の保障を薄くして、回避不可能な点のみしっかり保障という流れなんだろう。
まあ、設計の前段階をソニーの同じチームで行えばできるんだろうけどな。
知らないうちにマージンが積み重なるというのは、真である。しかし問題はそこじゃない。同じ理由で、知らないうちにマージンが無くなってしまう。 というのも真なのだ。悲しいけど、マージンは見えないが、故障は目立つ。
言いたいのはロジック設計 (スコア:2)
プロセス的というか物理的なマージンを思い浮かべるけど、
実際語っているのはロジック設計部分でのマージンの話をしている感じです。
例えばロジックを再利用できるようにモジュール設計して、
1clkで1outputなスループットを得たとします。でも、再利用する場面では
2clkで1output得られれば良いけど、安全のために手を加えない。
(感覚的に)スループットはロジック規模と比例するので、結果的に
余計なシリコン面積となりコストに跳ね返る。これを無駄なマージンと
主張しているように見えますね。
それをSystemCを使って高位合成することで無駄がなくなりました、
GUIかぶせてシミュレーション結果をわかりやすく検証できるように
なりました、制御回路も高位合成が実用になってますよ、そんな
主張だと思います。
だから、確率的に発生する故障につながるようなマージンの話ではないと
思いました。
まぁ、ロジック設計上のマージンを数値に直してきちんと評価できているか、
それは確かに疑問ですが。
Re:言いたいのはロジック設計 (スコア:2)
SystemCの話に、ハードの話で文句いうのもたしかに(おいらが)変。
で、もう一度読み直しました。
新規設計には、SystemCベースの設計は、効くみたいです。その理由を勝手に読み取ると
1. simlaton 速度が速い。絵で確認できる。従って修正結果を確認するのが楽。
2. 記述の修正が簡単。従っていろいろな修正を加えることができる。
写真とか、話の始めのほうには、物理設計や設計再利用について触れているみたいですが、
たしかに本文中にはそれにふれていないですね。
... どこでどれくらい効果が出たかわかりやすい定量的な表にしてくれればいいのに。