半導体設計経験者がGoogleが支援するSkywaterのIC PDKを俯瞰する

背景

最近、オープンハードウェアが熱いです。RISC-Vもそうですが、どんどんオープン化が進んでいます。これはソフトウェア開発の流れであり、ソフトウェアIT企業がどんどんハード開発に進出しています。

なぜソフトウェア企業がハードウェア開発に介入しているのかというと、理想のソフトウェアのためだと言えます。アラン・ケイが言った様に「理想のソフトウェアを書くためには理想のハードウェアが必要」ということは概ね事実でしょう。実際にソフトウェア要求でハードウェアに機能を実装する機会は昔からあるわけで、それが大規模化されているにすぎません。この背景としては、FPGAの様な再構成可能なICチップの普及やOpenCLの様な高位合成系の普及も背景にあることは疑いようはありません。

そして、この独自ハード開発に本気で取り組んでいるのが、Google、Apple、Microsoftでしょう。Amazonは演算の方より、ネットワークの方に力を入れている印象ですが…。最近はAIブームが一段落し、ビジネス・汎用領域に入ってきており、低コスト化の必要性が増してきています。それゆえ、これら企業は、ハードウェアに積極的に取り組んでいる、というところです。やっぱりソフトだと効率が悪い所はたくさんありますから。…まあ、今は何となく落ちぶれているように見えるIBMは昔からソフトもハードもやっていたわけで。AIだって、IBM発な所もあったしで、やっぱり同じところに落ち着くんだろうなと。そんな感じを昔からのやっている人は思う訳です。

そして、ついに集積回路(IC)のファブ(製造)まで、オープン化しようという試みが始まり、Googleが出資する所まで来ています。半導体設計経験者として、非常にその動きが興味深いので、その進捗状況を見つつ、現状を俯瞰したいと思います。

目的

Googleが出資している、IC設計環境（通称PDK、Process Development Kit）の完成度を俯瞰し、状況などを考察することをこの記事の目標とします。

プロセスとしては、Skywater Technology社のプロセスが対象となります。Skywaterというのは聞いたことが無かったのですが、色々と調べてみると、アメリカ資本で作られた数少ないファブとのことで、半導体リスクを抑制するということも関係しているようです。

PDKのリンクは次の通りです：https://github.com/google/skywater-pdk

色々と資料は上がっているので、環境の提供状況を見ていきましょう。

そもそもPDKとは何か？

興味を持って読んで頂いている人の中には「PDK」について全く知らない方もいるでしょうから、その説明をしたいと思います。誤解を恐れずに言えば、ソフトウェア分野で言うSDと似たような物、といえば大体あっています。

SDKは、「OSなどの特定プラットフォームをターゲットとして、ソフトウェアを開発するための環境ファイル群」を提供します。コンパイラは自分で用意するとしても、対応するコンパイラは言語や規格などにより決まってきていて、その枠内で自由に用意することになります。

一方、PDKは、「ある製造プロセスをターゲットとして、ICを設計するための環境ファイル群」を提供します。「ある製造プロセス」とは、通常「特定の会社の、特定の製造方法」ということになります。例えば、Intelの10nmプロセス、みたいな言い方で有ったり、TSMCの0.18um RFプロセスみたいな言い方をします。外注を受け付けているにせよ、内製向けにせよ、「製造プロセス」とは「プラットフォーム」でもあり、そういった観点では、SDKと同じ構造になっています。なお、ソフトウェアでいう「コンパイラ」に相当するものは、IC設計においては「シミュレーションモデル」「物理検証環境」の二つ必要になります。まともに設計されたPDKであれば、共に提供されているのが普通です。

PDKの特殊性は、物理的な製造ルールであり、そこに機密がある、ということです。「寸法それ自体がノウハウ」ということです。ですから、PDKの提供とNDA(機密保持契約)はセットでした。そういった状況があるので、専門家以外は状況を把握できない、そんな状況になっていました。そこに一石を投じようとしたのが、今回のGoogleのPDK支援です。

ちなみに、OpenなPDK自体が非常に新しい訳ではなく、従来からアカデミックベースでは試みられていました。ただ、コンパイラに相当するツール群をどうするのか？という問題があり、中々厳しい状況だった、というのが自分の認識です。最近、フリーのツールも割と揃ってきたので、そういったコミュニティを活性化させて、より加速したいという意図なのかな？と思っています。

ファイルの提供状況を確認する

それではPDKの中身を確認していきましょう。githubからのリンクを辿るとPDKのドキュメントが出てきます。ドキュメントは作成途中らしく殆ど完成していません。

とは言え、以下は既に提供済みの様です。

• sky130_fd_pr：Spice用デバイスモデル
• sky130_fd_sc_hd：High Density Digital Standard Cells
• sky130_fd_sc_hdll：High Density Low Leakage Standard Cells
• sky130_fd_sc_hs：High Speed Digital Standard Cells
• sky130_fd_sc_ms：Medium Speed Digital Standard Cells
• sky130_fd_sc_ls：Low Speed Digital Standard Cells
• sky130_fd_sc_lp：Low Power Digital Standard Cells
• sky130_fd_sc_hvl：High Voltage Digital Standard Cells
• sky130_osu_sc：物理検証関係？
• sky130_osu_sc_t09：アクセス権なし（未完成？）
• sky130_osu_sc_t12/t15：スタンダードセルのGDS, PEX後Spiceモデル。※tの後の数字はトラック幅？
• sky130_osu_sc_t18：リンク無（未完成？）

まだα版なので、多分完成度はそれなりであって、動かない可能性もありますが、それなりに頑張ってリリースしている印象です。

当たり前といえば当たり前ですが、殆どスタンダードセル（SDKでいう所の基本関数群）ですね。高密度系から高速系まで揃ってていい感じです。Spiceのデバイスモデルもありますから、回路シミュレーションも試せるでしょう。スタンダードセルの実際のレイアウト（物理寸法ベースの設計）はサイズ別に4つリリースしたいようですが、12トラックと15トラックのみ提供済みですね。このレイアウトは大抵手作業で作って最適化するので、作成中なのかもしれません。面積最適化のことを考えると9トラックが使いたくなりますが、現在作成中でしょうか。

上記を見ると、設計を試してみるという観点では、十分な材料が揃っています。Spiceでシミュレーションして、スタンダードセルを使ってレイアウトして、物理検証をする、という所までは出来そうです。実際の設計については、次回以降、記事にして行くつもりです。何せ普段使わないツール群が必要になるので、準備に相応の時間が必要ですので。

物理検証ツールの確認をする

ではまずは、非常に重要な物理検証から見ましょう。

物理検証は半導体製造において、非常に重要です。製造可能なルールを定め、そのルールに適合していることをツールにより確認することが設計者に求められています。また、回路図上には表れない、物理的なサイズにより付加される非理想的な現象を抽出することで、より確度の高いシミュレーションを実施することも必要で、それも物理検証ツールの枠内に入ってきます。

この時の物理検証は3つ必要なものがあります。それぞれについて確認して行きます。

Design Rule Check (DRC)

これは最優先で必要なものです。DRCに違反がある場合、製造することは出来ませんから、省略することは困難です。このチェックはアルゴリズムが既に固まっています。ですから、「速度を気にしなければ」オープンソースでもチェッカーを作ることは容易でしょう。

なお、この分野でDRCと言えば、メンター社のCalibreがデファクトスタンダードです。実際にルールもCalibreルールで書いていることが多いですし、PVSというCadenceのツールもCalibreルールが読めたはずです。Calibreは速いので、お金があるなら、Calibre一択なんですが（Cadence派やSynopsys派には怒られるかもですが）。

さて、それを見た上でサイトを見ると、DRCは最も有名なフリーIC開発ツールの一つであるMAGICに対応しているようです。これであれば、フリーでも使えるので個人でも使えるので安心です。

Layout vs Schematic (LVS)

これは次に必要となるものです。LVSはレイアウトと回路図の比較を行い、欲しい回路のレイアウトパタンになっているのかを確認するためのツールです。このアルゴリズムは既に固まっている物があるので、DRCと状況は変わりません。メンター社の物がデファクトなのも一緒です。

確認してみると、レイアウト抽出もMAGICの物が使える様な設計になっています。

Parastic Extract (PEX)

これは動作検証に必要となるものです。PEXは規制容量抽出で、配線に付いてしまう配線容量の値を抽出します。これにより、実際に製造したものが、正しく回路動作することを確認する訳です。これもデファクトはメンター社の物です。

ただ、このPEXについては、恐らく固まったアルゴリズムは無いでしょう。基本となるものはあるはずですが、各社は自ら実測したりして、演算順序や抽出方法にチューニングを施しているはずです。PEXは何も考えずに実施すると素子数が爆発して、シミュレーションに非常に時間がかかる様になります。ですから、素子数を抑制出来る効果的なアルゴリズムが必要になってくるのですが、これは非常に難しいです。ですから、これはオープンPDKの最後までの課題となるでしょう（PDKというか、ツール用意の課題かもしれませんが）。

さて、PDKを眺めてみると、やっぱりPEXルールは整備されていない様に見えます。なので、まだまだ発展途上、という事でしょう。

物理設計環境を確認する

物理設計環境は極論するとレイアウトエディタがあれば出来るのですが、マスクの枚数が多いと自分で書くのは大変なので、実務上はEDAツールの支援（パラメタライズドセル）が必要です。加えて、デジタルの場合は手でレイアウトを書くのは現実的ではない（素子数が多すぎる）ので、論理合成ツールと自動配置配線ツールが必要になってきます。

こういった視点で物理設計環境を確認すると全く環境構築は出来ていない状況です。ただ、スタンダードセル群があったりするので、現在構築中な印象はあります。これも今後の発展に期待でしょう。

シミュレーション環境を確認する

回路シミュレーションとしては、粒度として、論理レベルと回路レベルの二つがあります。

論理レベルのシミュレーションはプロセス依存性は一切ないので、フリーのシミュレータで問題ないでしょう。SkywaterのPDKは基本的にVerilogで記述されているので、Verilogシミュレータがフリーで存在すれば、課題は解決します。実際、フリーのシミュレータを見たこともありますから、これで十分でしょう。

問題は回路レベルのシミュレーションです。これは一般には、トランジスタレベルのシミュレーションとも言われています。トランジスタの動作は「それなりに難しいモデリング」がされていて、微分方程式を回路方程式に基づき解く必要があります。とはいえ、1からモデリングするのは色々と大変なので、デバイスモデルという物があり、その未定パラメータを決定する必要があります。そして、それはトランジスタを作って、それに合わせてフィッティングし、パラメータ抽出をしないといけません。ということでこれが提供されているのか、というのが最重要でした。

結果としては、デバイスモデルは提供がされている様です。トランジスタはBSIM4でモデリングされている様で、cell/nfet～ディレクトリで中身が確認できます。ですから、現状のPDKでもトランジスタレベルのシミュレーションは可能です。

まとめ

Googleが支援するSkywater Technology社のオープンPDKの現状を見ていきました。思ったより、環境構築がされていて、ちょっとびっくりしましたが、想定の枠内でもありました。物理検証の初歩は可能なものの、寄生容量抽出までは至っていませんし、これだけだとまだちょっと厳しいかなという気がします。

とはいえ、フリーのPDKが出てきた意義というのは大きいです。

今後の課題としては、プロセスノードが最先端とはとてもじゃないが言えない0.13umプロセスってことですね。Skywaterとしては今後90nmのプロセスを立ち上げていきたい方針の様ですが、出来れば65nmプロセス程度があると、製造を委託する側としては幅が広がりますね。65nmなら、5Gで使われるmm-waveのICもデザイン出来ますし。プロセスノードは欲張ったらそれだけ設備投資が必要になるので、どこかで諦めることが必要になってきますが、Skywaterがどこまでプロセススケーリングを進めるのか、少々楽しみです。

あとは、オープンという名前に恥じない様な、製造費用だと嬉しいですね。出来れば、50万円ぐらいだと個人でも辛うじて、趣味として出せるのでうれしいですが、流石に難しそうです。中々、半導体は個人で進めるのは難しいですが、今後、こういったレガシープロセスの設計環境が広がっていくと、技術的には楽しそうです。