パスワードを忘れた? アカウント作成
500675 journal

astroの日記: 凹む 2

日記 by astro

仕事の話。

来週にT/Oなのだが、未だに下地を修正中。
しかも、ヤバかったマクロじゃなくて、ランダムLOGIC部分でだ。
hold修正に、40個位バッファを入れたところ、逆にsetupが死んでいる。
セル占有率が部分的に100%近くになってて、バッファが挿入できない。

そもそも、floorplanからしてミスだった。
巨大なRAMを置いてしまったために、RAMとPORTに引きずられれMPUが股裂き状態。
しかも、新プロセス、新ライブラリ。
まだ誰もT/Oしてないという状況で、通常のライブラリより短いTATでT/Oしろという。
本気かと思ったが、どうやら上は本気らしい。
当然、CFは遅れて、合成もDFT遅れてくるわけだが、後ろは変わらない。
レイアウトに入ったときに「このスケジュールだと、動かないものをT/Oする
ことになると思いますが、それでもやりますか?」と聞いたのだが、それでは
困るという。困るなら、困らないですむ方法を考えてくれと投げたが放置。
挙句の果てに、インフルエンザだかで数日休む始末。
先方には、ぎりぎりまで黙っておいてスケジュールを伸ばさせてくれというつもり
だったらしいが、逆にお客から前倒し依頼がきて頓挫。
「好転する要素はない」と言ったにもかかわらず黙っていた自分の責任は自分で
とってほしい。自分に策がないのに、勝手にそういうことするなといいたい。

誰か、半導体レイアウト屋を雇ってくれませんか。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • 論理設計のほうが工数かかかりますからね。一見やるだけに見えるレイアウトにしわ寄せがくるのは当然のような気もします。実際は因果関係の定量化が難しい工場の方もすごいプレッシャーだと思いますが。
    全体のリスクをどう見積もっているのか、責任構造がどうなっているのか知りたいところです。
    「こんなスケジュールではできn!」というのはもう飽きたので、違うこと言ってみたいです。

    オイラがいたファブレスの方だと、メタル層数を増やすか、サイズを犠牲にしていいよね とすぐに言い返します。さらにエンジニアを働かせるために追加コスト。客はチップサイズ、値段は前に合意しただろうが、と反論しますが、前提となるスケジュールが..と議論は進みます。IDMのASICセールスではそれは言い難いでしょう。

    直前のプロジェクトでは、PTVの範囲を狭めて、信頼度を落とす という手法を取ろうと思ったのですが、意味を理解していない・できない人が多くてめんどうでした。
    OCVを見ないとか、xtalkによる遅延変動を半分までしか認めないとか、言うと効果的な相手もいます。それはそれで正しい手法な感じもします。評価中に致命的に問題が見つかったなら少しだけ焼直せばいい。ついでに論理のバグも直しちゃえ。と言って論理設計者のプレッシャーも減らしてあげるとか。
  • by astro (17245) on 2007年03月04日 15時40分 (#1120481) 日記
    そうですね。
    論理設計で、CFを上げる直前に仕様変更や追加が入っただのというのは論外としても、
    最初からタイトなスケジュールを立てておいて、遅れた分後ろにしわ寄せを
    しているわけです。そして工場では信じられない工期でサンプルを仕上げて、
    なんてやってると、どこかでリカバリー不可能な事故が起きてから喚くわけです。
    そもそも、タイトというか無理なスケジュールを承知で進むなら、リスクを
    どう見積もっているのか、誰がどこでジャッジするのかを明らかにしておくべき
    というのは同意です。

    マージンを削ってみたり、OCVの係数を変えてみるとかいろいろやってみるん
    ですが、そのたびに抵抗勢力がいろいろ言ってくるわけで。
    DesignCenter的な考え方だと、与えられたconstraintは絶対守らなくては
    ならない、と考えてるというのも分かるのですが、IDMにいるんだからいったい
    そのマージンは何を見てるのか、係数の意味はどうなのとか、考えないってのは
    ダメでしょ、ってことで。
    そもそも、fmax=200MHzとか言ってるライブラリで500MHz以上をぶん回しなさい
    という時点で、マージンもライブラリスペックもクソもないわけですが。

    後は、リワーク前提というのも、半導体業界特有の奇異な風習だと、最近になって
    お偉方たちが喚き始めましたが、これもどっかのアホ会社が業績不振で2期連続
    赤字を達成しちゃってあわてて費用削減策というのが見え見えであきれます。
    もちろんリワークしたくてしてるわけじゃないですが、リワークの多い製品は
    マネージメントにも問題があるわけで、根治じゃなくて単なる泥縄なわけです。
    リワークゼロゼロいうなら、経営のリワークもゼロでお願いいただきたいなと
    思うわけです。
typodupeerror

ナニゲにアレゲなのは、ナニゲなアレゲ -- アレゲ研究家

読み込み中...