アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
物事のやり方は一つではない -- Perlな人
おっしゃるとおり (スコア:1)
論理設計で、CFを上げる直前に仕様変更や追加が入っただのというのは論外としても、
最初からタイトなスケジュールを立てておいて、遅れた分後ろにしわ寄せを
しているわけです。そして工場では信じられない工期でサンプルを仕上げて、
なんてやってると、どこかでリカバリー不可能な事故が起きてから喚くわけです。
そもそも、タイトというか無理なスケジュールを承知で進むなら、リスクを
どう見積もっているのか、誰がどこでジャッジするのかを明らかにしておくべき
というのは同意です。
マージンを削ってみたり、OCVの係数を変えてみるとかいろいろやってみるん
ですが、そのたびに抵抗勢力がいろいろ言ってくるわけで。
DesignCenter的な考え方だと、与えられたconstraintは絶対守らなくては
ならない、と考えてるというのも分かるのですが、IDMにいるんだからいったい
そのマージンは何を見てるのか、係数の意味はどうなのとか、考えないってのは
ダメでしょ、ってことで。
そもそも、fmax=200MHzとか言ってるライブラリで500MHz以上をぶん回しなさい
という時点で、マージンもライブラリスペックもクソもないわけですが。
後は、リワーク前提というのも、半導体業界特有の奇異な風習だと、最近になって
お偉方たちが喚き始めましたが、これもどっかのアホ会社が業績不振で2期連続
赤字を達成しちゃってあわてて費用削減策というのが見え見えであきれます。
もちろんリワークしたくてしてるわけじゃないですが、リワークの多い製品は
マネージメントにも問題があるわけで、根治じゃなくて単なる泥縄なわけです。
リワークゼロゼロいうなら、経営のリワークもゼロでお願いいただきたいなと
思うわけです。