Previous ToC Next

154. ASIC 開発で死なない方法 (2021/11/25)

ふと思い立ったので、私が過去30年間に GRAPE-3, 4, 6, DR, 8 と5個の ASIC を開発し、MDGRRAPPE-1, 2 と富岳の開発(と MN-Core のも)を横目でみ て学んだ ASIC で失敗しない方法を書いておく。

  1. ベンダと打ち合わせしたスケジュールから6ヶ月、または少なくとも50%、で きれば100%延びても大丈夫な計画であること(6ヶ月と50%の大きいほう)。

  2. チップ全体のファンクションパターンを作り、そっちだけで機能検証でき るようにすること。さらに、演算器のファンクションパターンは乱数とか でなくて演算器の全ての機能を検証できるように手で作ること。

  3. このファンクションパターンで「設計自体」が検証できていること。設計 自体とはここでは ASIC ベンダに渡すもののことであり、検証とは アプリケーションで答があって、性能も通信等を考慮した上で要求を 満たしていると確認する、ということである。

    RTL インター フェースなら RTL シミュレーションでファンクションパターンが通って いる必要がある。同じブロックが多数あるチップの時に全部が入っている RTL でシミュレーションは不可能なこともあるが、複数のブロックがはいっ たチップ全体のテスト、ブロックをスタブに置き換えてその上のロジック 全部のテスト、は必須である。

  4. Power Integrity 設計では、十分な余裕をとること。特に、急激な消費電 力の変化に対する対策をとること。

以下ちょっとだけ解説。

まず1について、 ASIC 開発は「必ず遅れる」。遅れる最大の要因はまず「私」で、論理設計と検証に自分の想定より時間がかかることである。次は、 ASIC ベンダの側で、IP が動かないとか IP が動かないとか IP が動かないと かがありがちな理由だが他にも色々な理由で遅れる。 ES ができてきてからびっ くりするようなことが発生してマスク作り直しになることもある。

従って、実際にシステムが稼働するまでのどの時点でも遅延は発生する可能性 があり、実際に何箇所かで発生するのが普通である。なので、スケジュールに は大きな余裕が必要である。

大きな余裕をとると最新の半導体プロセスを使えないのでは?と思うかもしれ ないが、それはその通りである。なので、プロセスが最先端でなくても性能に 優位性が十分あるようなものでなければならない。逆にいうと、 プロセスが最先端であることで競争力をもつためには開発で 失敗しない、ないしは、プロセスで圧倒的優位にある必要があり、 かつての Intel の tick-tock モデルはそれであった。新しいプロセスでは 古い設計を、新しい設計は古いプロセスで、とすることで失敗しても ひとつ前の世代、というバックアップがあった。あと、タイムリーに製品投入 きないのでは、という疑問は当然あり、これもその通りである。それでも商売 になるように考えてね、ということになる。

2015 年以降は、最先端の半導体がバルクCMOS 構造から FinFET 等の立体構造 に移行し、CMOS スケーリングによる半導体自身の性能向上が非常にゆるやか になったため、最先端のプロセスでないことのデメリットは小さくなった。

次に 2 のファンクションパターンについて。これは第一には責任分界点とし て重要である。LSI のテスト方法として、大雑把にいってATPG パターン(ツー ルによる自動生成パターン)とスキャンパスによる自動テストと、実際クロッ クや信号をいれて動作させるファンクションテストがある。

自動テストは、LSI の回路が「設計通り」であることは確認してくれるが、 「仕様通り」であることは確認してくれないしそもそも動くかどうかも確認し てくれない。従って、論理設計自体に間違いが残っていた場合、これは自動テ ストでは決して発見されない。微妙なケースとして論理合成ツールにバグがあ るとか使いかたが間違っているとかの場合はさらに難しい問題になり、RTL シ ミュレーションでは通るがもしもゲートレベルシミュレーションをちゃんとやっ たら通らない、もちろん実チップも間違っているが自動テストは通る、という ことが起こる。ATPG はゲートレベル記述から生成するからである。

論理合成までしてからベンダに渡していてファンクションパターンがないと、 この時に責任はこちらにあることになる。一方、十分なカバレージのある ファンクションパターンがあれば、そのファンクションパターンにあうように することはすべて ASIC ベンダ側の責任になりこちらの責任ではない。なので、 できたチップが全く動かない、ということはない。もちろんスケジュールから 遅れることはある。

さらに、演算器に想定外のバグがはいることは常にあり、ファンクションパ ターンだけではチェックは困難で設計自体の検査には形式検証等も必要だが、 実チップの動作を保証してくれるのはファンクションパターンだけである。

3 は2の系みたいなもので、ファンクションパターンでチップの「あらゆる部 分」の「あらゆる機能」が、少なくとも想定した使用方法の流れにそった全て が、テストされていないといけない、ということである。これは 実機で全部通せるかどうかはちょっと別で、テープアウトの前のシミュレーショ ンで、という話。

4 は、電源ノイズ、というよりは「変動」をどうするかである。これは私自 身は GRAPE-6 で大変だったもので、ボード上の全チップの全パイプラインが 同時にアイドルからフル計算状態に移るので、瞬時に消費電力が3倍くらいに なることに電源ユニットが十分速く応答できなくて供給電圧が大きく下がる、 というものである。これに対する基本的な対策は、多少でも応答の速い電源に することと、電源からチップ上まででの電圧降下を可能な限り小さくすること である。これはいうほど簡単ではなくて、それは最近のチップだと電圧が 1V 以下で電流が何百アンペアとかになってるからである。とはいえ、とにか く電圧降下を小さくしないと計算開始した瞬間に電圧がさがって誤動作する、 といったことになる。 もうちょっと回路設計的な対応も考えるべきだがここでは触れない。

プロジェクトが破綻しないためには 1、作ったチップが動くためには2が重要 である。

Previous ToC Next