今月のテーマ: オープンソースEDAの調査

日本の半導体産業がまだ元気だったころ、外資系EDA企業で働いていました．
OpenLANE

AWSでOpenSource EDAのフローソリューションを見て15年以上前のEDAベンダーが提供していたフローと同じだなと思い・・・90nmより微細なプロセスの場合はCMPなど微細化に伴う処理が必要だったり、タイミング検証のモデルでプロセス・バリエーションの対応が必要となる世代であるのでちょっと足りていない感じのフローだなと思う．

TSMCリファレンスフロー7.0（2006年）

TSMCリファレンスフロー 2006

この頃のLowPower Synthesisは、主にMTCMOSを使った電流スイッチで電流制御ではあるものの、民生品でも消費電力に対する要望が出てきたころ．

昔から、MAGICやSPICE3、ICARUSシミュレーターやVHDLコンパイラなどは使っていたし、自作STAなども作ったりしていたので無料で使えることは良いと思っている．

OpenRoad Flow

今月の調査テーマとしては、OpenLaneの中で利用されているOpenRoadについて少し調べてみようと思います．

1. OpenRoad App

OpenLaneのフローを見てもらうと、TSMCのリファレンスフローの3.0や4.0くらいであることは分かると思う．

タイミング・クロージャの部分にクロストークなどを考慮した最適化は含まれていないことは明白．

例えば、グローバル・ルーティング時に考慮するべきカップリング設定とタイミング・ドリブン・ルーティングを実行するフローパーツが無いことやノイズ分析とその解が含まれていないことから甘く見て4.0くらいだろう．

OpenLane Flow

OpenLANE

TSMCのリファレンスフロー 2006年

TSMC Reference Flow

2. OpenLaneの試行

テストで作成したレイアウトを見るもの良いのですが、まずは基本的セルレイアウトを見てみる．
CKBUF4（クロックバッファx4ドライバ）ですが、130nmテクノロジですからプレナー．

sky130 ckbuf4

$ cd OpenLane
$ make
$ make test

klayout spm 部分

なるほど、レガシーですね

ちょっと突っ込む

  • シングルコーナーはいただけない
    　HDL合成後のタイミングチェック、配線容量無しの状態でのタイミングチェックだろう、この状態でタイミングバイオレーションしているようであればフィジカル合成は成功しないということだけど、シングルコーナーなのでスピードワーストでのみのチェックかなと思われる．（ここでこんな雑でよいのか？！）

  • DFT
    　ここで言うDFTは、スキャン・インサートだけかしら？配置前にスキャンつなぐと配置がスキャンツリーに引っ張られてしまうので、配置後にスキャンつなぎした結果を出すようにしたほうが良いのだけど・・・

  • Exploration
    　フローをよく見ると、Explorationが入っていて（これはツールではなくて設計者が見ることを示している）しっかり設計を見直せということを理解する必要はあるだろう．
    　商用EDAほどのコストはかからないが、その分設計者は気配りしましょうということだな．

  • IO配置
    　モジュールでもパッケージでも初期のIO配置がランダムなのはいただけない、フレームはあらかじめ決まることのほうが多いので、必然的にタイミング・コーンもきまるほうが多い．

  • Placemnet
    　配置オプティマイズが、リサイズ＆バッファしかないので最適化としては弱い．RTLからの流れで過剰にバッファが入っていることもあるので、いったんバッファ抜いてあらためてインサートをやり直しするというのもありだろう．　グローバル配置後に一度タイミング・チェックを実行し、概略距離でバッファを挿入とリサイズしてセットアップガードバンドを少し持たせてるような緩めにフィジカル最適化を行っておいたほうがホールド調整で苦労が減る.

  • クロスカップリングの影響は
    　クロストークの影響をほぼ見ていないようなフローであるので、STAの部分にSIを組み込むとよいのだがOSSのプロジェクトとしてはアクティビティは無いよう．
    　OpenSTAのコードを見ました．RCX側でカップリング容量の抽出はできるようですが、遅延計算にクロストークディレイは含まれていなくSI Awareではない．
    　OpenRCXのコードも確認しました、カップリング容量の抽出はできる、各コーナーでの抽出も可能．マルチシナリオ使えるようにはなりそう．

  • InPlace Synthesis
    　この頃のフィジカル最適化には、インプレースで再合成が可能になっているフローが多かったと思う．オーバーコンストレイントで論理合成で入ってきたHDLの場合配置できないこともあるので再合成で調整できるほうがタイミング・クロージャーもフィジカル・クロージャも良い結果（収束が早い）が得られる．

OpenDBにLEF/DEF/SDC/RCXなどを取り込んでフィジカル合成を各ツールコマンドで処理しています．　コードは昔ながらのC++が多い、組み込み言語はTclとPythonなのはEDAの歴史的な流れに沿った感じです．

3. テストデザインで試行

OR1200

OR1200などで実行してみるとタイミング・クロージャ含めてどれくらいの動作周波数になるか分かるのでベンチマークとしては面白いのではないかと思う．

テクノロジは100nm以下が手ごろでよいかなとは思うけど、フリーの90nmのPDKあるのかな？！

それより先にデザイン・フロー変更と不足している部分をどうするか考えたほうがよいのかな．

まとめ

引き続き試行を続けてみようと思う．