ファブレスがテープアウトまでに行う戦い集
はじめに
今回は少し違った視点で半導体設計を見ていきたいと思います。ファブレス企業が設計を開始して、最後のテープアウトまで発生する戦い集です。開発要素が多い場合はさらなる戦いが待ち構えているかもしれません。
自己紹介
日本の大学でPhDを取得し、日本の会社に就職するも会社の方針転換で一年も経たずに外部に出向し、先行きが見えないため別の日本企業に転職。なぜか転勤族になり西の方に移住。英語を勉強して外資系に転職しVISAをサポートしていただきUSに移住。その後GCを取得しBay Areaの大手テック企業に転職して今にいたります。専門は半導体のプロセス設計です。
半導体に関する記事等はこちらに集約しておりますので、ご参考までにリンクを貼っておきます。一部有料ですが作者のお茶代と思ってください。
デザインルールとの戦い
必ずデザインルールというものが各Fabに存在します。このデザインルールはこれに沿ってデザインすれば失敗(製造に関する)はないし、性能や歩留まりはFab側で保証するよ。というガイドラインです。
Fabless企業もこれに沿って作れば問題なのですが、そのままだと他社との違いは全くなくなります。なのでFab側と交渉や実績を積み重ね、このデザインルールをリスクなく破るかが、Fabless側の腕の見せ所になります。
リスク許容範囲を自分達で設定して、敢えてデザインルールを破り性能を引き出すは重要な仕事です。ただFab側の保証外になるので、その部分で重大な不具合が発生したとしても自分たちの責任になります。
DFMとの戦い
DFM(Design For Manufacturing)というルールがデザインルールとは別で設定される場合が多いです。これは主にFab側で発生するランダム欠陥等による歩留まり低下を抑制するためにあります。またはFab側で発生する製造ばらつきをデザイン側である程度吸収してもらうという役割もあります。
ただ、DFMに従うと特性が落ちる場合が多々あります。例えばTwin VIAなどは容量が増えるのでChip速度の点で不利になる場合があります。なのでFabと交渉して敢えてDFMを無視するというのも必要な戦いとなります。
検証ツールとの戦い
デザインルールを回す検証ツールとの戦いは常にストレスを感じます。まずルール記述が独特なので、何が問題なのかを読み解くのは長年の経験と勘が必要になります。またVersionや環境によって検証がSTOPしたり、謎のErrorを吐いて止まったりと常に何かしら小競り合いが発生します。
あと大きな会社だと良くあるのが、ライセンス不足とかです。検証には膨大なリソースを使うのでテープアウトが近くなるとライセンス不足が発生します。なのでゾンビーになっているJOBを止めたり使用できる優先度を明確化したりして対応します。
時間との戦い
これは常に付きまとう戦いです。回路検証に時間がかかりすぎたりや致命的なBugが見つかったりした場合はテープアウトを延期せざる得ません。ですが納期は決まっているので、Fab側と交渉してロットが流れるスピードを早くしてもらう交渉が必要になります。Hot Runというのがありますが追加料金を払うことでSuper Hot Runが使えます。結局お金次第です。時間をお金で買う典型例です。
Documentとの戦い
さぁようやくGDSもできた。テープアウトだとなってもまだ戦いは終わりません。Fabにもよりますがかなり複雑なDocumentを記入する必要があります。出力したGDS番号がどのマスクに対応するのかとか、そのGDS番号がイオン注入の用途として合っているかなどの確認作業とDocumentationがあります。これを間違うとマスクが意図したものではないとか、そもそもマスクが作られていないなどの問題が発生します。
Fab側ではこのDocumentとGDSを使い簡単なチェックをします。ここでDebugをして問題がないことを確認したらようやくテープアウト完了となります。
まとめ
今回は自分が経験したことのある、戦い集となります。このほかにもワークステーションの乱とか、クリスマス休暇の変などもありますがそれは後ほど・・・。
アメリカSilicon Valley在住のエンジニアです。日本企業から突然アメリカ企業に転職して気が付いた事や知って役に立った事を書いています。