OpenLane flowを引き続き見てみる
OpenLane flowを少し見ようか
OpenLane flowを使いサンプルのspmを最後まで実行できた．「エラーなくフローが実行できGDSを見れた」ので、もう少し確認をしてみよう．
実際にはOpenROADの部分で気になるところが多い、テストケースでなにを見れるか確認するところから始めようと思う．
目的は、いわゆるベンダー作成のワークアラウンド、企業側で実装するヘルパースクリプトやフロー変更などの検討だろうか．
1. デザイン
デザイン・テストケースかと思ったのだが・・・ほんとにフローテスト用のデータだった．
シリアル・パラレル・マルチプライヤ（spm）ですよね。ということは、積和（シグマ計算）の一例を実装しているるようだ．
SPMと書いてあるから、こんな感じのデータパスでシングル周期かマルチ周期での実装と思ってました
よって、デザイン見てなかったが・・・
HDLを見ると、下記のタイプを使った掛け算器のようです（cat見なので間違ってるかも）．
タイミグコンストレイント
それでタイミング・コンストレイントってクロックだけよね？ということでSDC見ると
set_units -time ns
create_clock [get_ports clk] -name core_clock -period 50
「あーーーーー」って感じ
2 タイミングチェック
Slackが9.11nsって、クロック10Mhzでパスが1nsかかっていない：
======================= Typical Corner ===================================
Startpoint: _272_ (rising edge-triggered flip-flop clocked by core_clock)
Endpoint: _272_ (rising edge-triggered flip-flop clocked by core_clock)
Path Group: core_clock
Path Type: max
Fanout Cap Slew Delay Time Description
-----------------------------------------------------------------------------
0.00 0.00 0.00 clock core_clock (rise edge)
0.00 0.00 clock network delay (ideal)
0.00 0.00 0.00 ^ _272_/CLK (sky130_fd_sc_hd__dfrtp_2)
2 0.01 0.05 0.38 0.38 v _272_/Q (sky130_fd_sc_hd__dfrtp_2)
dsa[2].last_carry (net)
0.05 0.00 0.38 v _235_/B1 (sky130_fd_sc_hd__a21o_2)
2 0.01 0.04 0.20 0.57 v _235_/X (sky130_fd_sc_hd__a21o_2)
_005_ (net)
0.04 0.00 0.57 v _199_/A2 (sky130_fd_sc_hd__a21bo_2)
1 0.00 0.03 0.20 0.77 v _199_/X (sky130_fd_sc_hd__a21bo_2)
dsa[2].last_carry_next (net)
0.03 0.00 0.77 v _272_/D (sky130_fd_sc_hd__dfrtp_2)
0.77 data arrival time
0.00 10.00 10.00 clock core_clock (rise edge)
0.00 10.00 clock network delay (ideal)
0.00 10.00 clock reconvergence pessimism
10.00 ^ _272_/CLK (sky130_fd_sc_hd__dfrtp_2)
-0.12 9.88 library setup time
9.88 data required time
-----------------------------------------------------------------------------
9.88 data required time
-0.77 data arrival time
-----------------------------------------------------------------------------
9.11 slack (MET)
このサンプルはデザインを見るというより、処理が流れるというタイプのサンプル．
サインオフディレクトリのタイミング（Setup）を見ると、RC抽出コンディションでネット遅延の部分見てみると：
10 0.03 0.04 0.11 10.22 ^ clkbuf_3_3__f_clk/X (sky130_fd_sc_hd__clkbuf_16)
clknet_3_3__leaf_clk (net)
実際のデバイス向きのテストパターンを使って処理してみたほうがよさそうということは分かる．
余談
クロック1GHz（1ns周期）でもいける（METする）感じ、実際にSDCを変えて流してみた．
Startpoint: _268_ (rising edge-triggered flip-flop clocked by core_clock)
Endpoint: _269_ (rising edge-triggered flip-flop clocked by core_clock)
Path Group: core_clock
Path Type: max
Corner: Fastest
Fanout Cap Slew Delay Time Description
-----------------------------------------------------------------------------
0.00 0.00 clock core_clock (rise edge)
0.00 0.00 clock source latency
1 0.01 0.00 0.00 0.00 ^ clk (in)
clk (net)
0.00 0.00 0.00 ^ clkbuf_0_clk/A (sky130_fd_sc_hd__clkbuf_16)
8 0.09 0.08 0.11 0.11 ^ clkbuf_0_clk/X (sky130_fd_sc_hd__clkbuf_16)
clknet_0_clk (net)
0.08 0.01 0.12 ^ clkbuf_3_7__f_clk/A (sky130_fd_sc_hd__clkbuf_16)
10 0.03 0.04 0.10 0.22 ^ clkbuf_3_7__f_clk/X (sky130_fd_sc_hd__clkbuf_16)
clknet_3_7__leaf_clk (net)
0.04 0.00 0.22 ^ _268_/CLK (sky130_fd_sc_hd__dfrtp_1)
2 0.01 0.04 0.23 0.46 v _268_/Q (sky130_fd_sc_hd__dfrtp_1)
dsa[0].last_carry (net)
0.04 0.00 0.46 v _186_/C (sky130_fd_sc_hd__and3_1)
1 0.00 0.03 0.11 0.57 v _186_/X (sky130_fd_sc_hd__and3_1)
_094_ (net)
0.03 0.00 0.57 v _187_/A (sky130_fd_sc_hd__clkbuf_1)
2 0.01 0.03 0.07 0.64 v _187_/X (sky130_fd_sc_hd__clkbuf_1)
dsa[0].last_carry_next (net)
0.03 0.00 0.64 v _189_/A (sky130_fd_sc_hd__nor2_1)
1 0.00 0.06 0.07 0.71 ^ _189_/Y (sky130_fd_sc_hd__nor2_1)
dsa[0].y_out_next (net)
0.06 0.00 0.71 ^ _269_/D (sky130_fd_sc_hd__dfrtp_1)
0.71 data arrival time
1.00 1.00 clock core_clock (rise edge)
0.00 1.00 clock source latency
1 0.01 0.00 0.00 1.00 ^ clk (in)
clk (net)
0.00 0.00 1.00 ^ clkbuf_0_clk/A (sky130_fd_sc_hd__clkbuf_16)
8 0.09 0.08 0.11 1.11 ^ clkbuf_0_clk/X (sky130_fd_sc_hd__clkbuf_16)
clknet_0_clk (net)
0.08 0.01 1.12 ^ clkbuf_3_7__f_clk/A (sky130_fd_sc_hd__clkbuf_16)
10 0.03 0.04 0.10 1.22 ^ clkbuf_3_7__f_clk/X (sky130_fd_sc_hd__clkbuf_16)
clknet_3_7__leaf_clk (net)
0.04 0.00 1.22 ^ _269_/CLK (sky130_fd_sc_hd__dfrtp_1)
0.00 1.22 clock reconvergence pessimism
-0.04 1.19 library setup time
1.19 data required time
-----------------------------------------------------------------------------
1.19 data required time
-0.71 data arrival time
-----------------------------------------------------------------------------
0.48 slack (MET)
クロックの共通パス部分は同じとして考えると、0.2nsくらあるのでそれを引いてSlack 0.3nsくらいか、OCV、配線遅延とクロストーク等を加味するとネガティブの可能性も残るかもいったところか？！
ところで、最近のミニマルファブでも配線間絶縁膜はエアギャップが使えるのか？ そうなると、CCエフェクトは劇的に低下するのだが・・・
3 フローで気になる部分（Global Place）
大まかに見たところ、タイミング・ドリブンP&Rのような感じではないように受け取れる．そこで、コマンドオプションを調べておく．
Global Placeで結線主体で配置を決められてもともいたのだけど、timing placeできないのかなとoptionを調べてみた．
オプションはある．どう使える？
書いてあるけど、初期から使えるかどうかはわからない．タイミングアップデートを途中でしないはずだから初期タイミング情報で配置決める感じか．
もう少しタイミング・ドリブンP&Rっぽくするには、初回Global Placeはsythesis後のタイミング情報と結線性で配置決めてもらえるとよいが、スキャン系信号についてはプライオリティつけられると良いなと思う．ダメならいったん切って、後処理で再結線するか・・・
Global Placement、Global Route（概略距離計算＝配線RC見積もり）、Global Place追加処理（最適化の処理をタイミングベースで）でGlobal Placeを完了させたい．
この時点で概略距離からタイミングみて、そこから追加バッファ挿入等の処理ができるとよいのだが．
CTSはこの後処理するようなので、クロックスキュー等でサイクルが変動するけれど、このステージではSDCインサーションディレイ（見積もり推定値：希望値ではない）で行っておいて、後段に進むかどうかをExplorationで見極める感じになるのだろう．
4 気になる部分（STAとSIと配線見積もり）
～100nm世代のプロセス・テクノロジで必要となるのは、SI（Crosstalk Delay）が必要だろうと思う． OpenSTAのコードも見てみたのだが、Crosstalk Delayの要素は見当たらない、そうするとSI（CrosstalkDelay計算等価的方法）としてカップリング容量をタイミングウィドウベースでパスを抽出、次に容量ファクターを計算、遅延等価の容量を付加する操作して暫定的に対応するしかないと思う．（OpenDBを操作するTclで何とかなるかな、ちょっと処理に時間かかるとおもう）
カップリング容量の見積もりには、Global Routeで距離計算情報を使うのが良いがGlobal Placeの状態で処理できるかどうか．
Global Routeは、配線指定必須のようでもしかすると距離を求めるのは別途行うしかないのかもしれない．
OpenDBには情報は入れられると思うので、スクリプト処理でも良いので距離計算とCCを設定して、タイミング計算させてみることはありか別途調べるか試行してみるか．
とうことで、Global Routeのオプションを調べてみる：
Wirelengthのレポートはとれる、Global Routeの概略配線も大雑把かげんも調整できそう、であれば既存のオプションとの組み合わせで、スクリプトレベルで何とか設定できるのかもしれない．
まとめ
OpenLaneもOpenROADいずれも、100nmプロセステクノロジで考えると少し物足りないと感じる．オープンソースであるので、利用者側でコードを作成してPR出す（EDAで言うとエンハンスメント・リクエスト）か社内にとどめて開発するか考えると思うが、やりようはいろいろとあるだろう．
EDAツールの価格が高いので、OpenSourceを利用するのは良いけど足りない部分は自前というところのコストとの天秤かな．
Googleで検索すると、OpenLaneを流している人はそこそこいるのだが、実際に使ったTEG/サンプルデバイス作るほど猛者はいるのだろうか？
デバイス作るとなると費用が相当かかるので、130nm程度のテクノロジを小ロットでも数千万はいるのかな・・・