ラベル SiliconSmart の投稿を表示しています。 すべての投稿を表示
ラベル SiliconSmart の投稿を表示しています。 すべての投稿を表示

2023年1月31日火曜日

OCV,AOCV,POCV,LVF

あまりよくわかっていないので(今更)まとめた.いずれもチップ内ばらつきを取り扱うための手法.

Static Timing Analysis (STA)

STAではパス中の論理セルの遅延を積算していく事で回路遅延を求めていく.以下の図の右側の Flip-Flopの セットアップ制約 T_setup は

T_setup > T_clk - ( T_launch - T_capture )

である.ここで T_clk はクロック周期,T_lauch はlauch path 遅延(データパス遅延),T_capture は capture path 遅延(クロックパス遅延)である.なお共通項は取り除かれる(Common Path Pessimism Removal).



On-Chip Variation (OCV)

OCV では derate factor を用いて回路遅延の平均からのずれを表現する.例えば回路中の論理ゲートが 3σ 遅延で ±5% ばらつくとする.OCV では,オンチップばらつきによって T_launch が 5% 悪化し,T_capture が 5% 改善すると考える.するとセットアップ制約は

T_setup > T_clk - ( T_launch * 1.05 - T_capture * 0.95)

と悪化する.各セルが Nσ でどの程度ばらつくか予測がつけばよいため,極端な話 Monte-Carlo シミュレーションは不要かもしれない.ただし段数効果が入っていないこの解析結果はかなり悲観的である.

Advanced OCV (AOCV)

AOCV (a.k.a SBOCV: Stage Based OCV) ではパスの段数と距離をパラメータとして持つ.パスの段数はランダムばらつきの影響力に寄与し,段数が多いほどばらつきは減る.距離はシステマティックばらつきの影響力に寄与し,距離が長いほどシステマティックばらつきが多い.この二つのパラメータを得るために,キャラクタライザは同じ論理ゲートのチェーンを作成し,Montecalro Simulation もしくは感度シミュレーションを用いてばらつきモデルを作成する.ばらつきモデルは,段数あたりの derate factor のテーブルで,early (改善方向)と late (悪化方向) の2つを持つ.

具体的には異なる論理段数のチェーンに対して

[early derate factor] = ([nom. delay] - 3σ)/ [nom. delay]
[late derate factor]  = ([nom. delay] + 3σ)/ [nom. delay]

で各 derate factor を計算し,それをテーブルとして

object_type: lib_cell
delay_type: cell
rf_type: rise
object_spec: */INV
derate_type: early
depth: 1 2 3 4 5
distance: 0
table: 0.87 0.91 0.92 0.93 0.94

object_type: lib_cell
delay_type: cell
rf_type: rise
object_spec: */INV
rf_type: rise
derate_type: late
depth: 1 2 3 4 5
distance: 0
table: 1.17 1.12 1.09 1.08 1.07

の様に保持する.(fallも同様)

パス遅延の計算は,通常の STA 同様各論理ゲート遅延の和を取れば良い.段数効果を考慮するため OCV に対してより現実的であるが,同一の論理ゲートのチェーンで評価しているため,論理回路の遅延評価には不向きである.そのためクロックの様な同じ論理素子のチェーンの評価で使われる.距離の情報も必要なので,ネットリストから各素子の X-Y 座標のデータを取り込む必要がある.

Liberty Variation Format (LVF)

POCV: Parametric OCV (a.k.a SOCV: Statistical OCV) は derate factor そのものを持つのでは無く,POCV Coefficient と呼ぶばらつきの相対値 (σ/μ) を利用する.プロセスパラメータを Sweep して POCV Coefficient を計算する.そのため以下のような POCV モデルが生成される.

ocvm_type: pocvm
object_type: lib_cell
delay_type: cell
derate_type: early
rf_type: rise
object_spec: */INV_coefficient: 0.04
coefficient: 0.04

ocvm_type: pocvm
object_type: lib_cell
delay_type: cell
derate_type: late
rf_type: rise
object_spec: */INV_coefficient: 0.04
coefficient: 0.04

POCV の結果は,個々のセルごとのばらつき情報として出力するか, LVF (Liberty Variation Format) として出力する.slew-load 依存伝搬遅延,遷移遅延,slew-slew 依存ばらつきをモデル化している.LVF では μ に加えて σ のテーブルを持つ.

遅延の計算では,各論理ゲートを通過するごとに以下の遅延 (Incr) を足し合わせていく.

Incr = Mean ± K * (Sensit_cell)^2/ (Sensit_slack)

ここで,Mean はパス中の一つの論理ゲートの遅延の平均,K はtiming_pocvm_report_sigma という変数(KσのK?),Sensit_cell は論理ゲートの 1σ ばらつき,Sensit_slack はパス Slack の 1σ ばらつき,と思われる.
(PrimeTime の説明だが,これ合ってるのか?)

こちらの Youtube動画 だともうちょっとシンプルに
Total_delay = (μ_1+ ...+μ_n) + sqrt(σ^2_1+...+σ^2_n) * N
であった.(NはNσ?)

この LVF は遅延の平均(μ)と標準偏差(σ)を利用しているので,分布が正規分布である事を想定しており,Regular-LVF と呼ばれる.さらに微細なプロセスではパス分布がガウス分布に従わないので,平均(μ)と標準偏差(σ)に加え,平均のシフト量,スキュー,尖度を考慮した,Moment-Based LVF を利用する必要があるそうだ.

なんかここまで来ると SSTA と変わらなくない?と思ってしまう.SSTA と違いパス単位の検証しかせず Max, Min 演算をしないのがミソなのかな...

2022年6月22日水曜日

Primelib は SiliconSmart と同じ

 タイトルそのまま.同じスクリプトがそのまま動きます.むしろ起動時に
> Reading  /cad/synopsys/primelib/T-2022.03-1/etc/sis.err...done
なんてログが出てくるので,「さては SiliconSmart だな,テメー」,という気分になります.

2022年5月28日土曜日

Setup search inside SiliconSmart

Flip-Flop の遅延特性のうち,Setup time の定義は2つある.
(1) C2Q 遅延の最小値から C2Q 遅延が 3~5% 悪化した点の D2C 遅延を Setup とする.
(2) D2Q 遅延が最小となる D2C 遅延を Setup とする.

広く認識されているのは (1) で,(2) はマイナーなイメージ.多くの人が参照している CMOS VLSI Design では (1) と (2) の両方を上げて,(2)でよいのではと述べている.

実際のキャラクタライザではどうしているのか調べたところ,SiliconSmart では D2C 遅延を変更し Q 出力が失敗する直前を探す探査をしているとマニュアルに書かれていた((1),(2)とも違う動き).
なお SiliconSmart が吐き出した SPICE ネットリストを見ると,SiliconSmart 自身は HSPICE による Setup の bisection 探査を呼び出していて,HSPICE の内部アルゴリズムが Setup を調べてレポートしているようだ.

2021年12月18日土曜日

電力とエネルギーと電力解析CADの中身

集積回路CADでは,回路において電気がする仕事量として,エネルギー(電力量,electrical energy)ではなくなぜか電力(power)が使われる. PowerCompiler などのレポートも電力(W)で表示される.
電力とエネルギーは混同されがちだが違うので,本来の仕事量はエネルギーとなるべきである.ではツールはどう取り扱っているのか各種マニュアルを調べてみた.ちなみに,マニュアル中でも電力とエネルギーは割とグチャグチャです(もしくは凄くセンシティブに使い分けているのか)

・キャラクタライズツール側(SilicoonSmart, LibraryCompiler)
キャラクタライズツールは,電力を3要素に分解し,そのうち内部電力(Internal power)とリーク電力の項を.libとして保持する.
(1)リーク電力:静止時の電力
(2)内部電力:セル内部で消費される電力.貫通電流など.
(3)スイッチング電力:外部容量の充放電による電力
電力は本来時間の関数だが,時間の関数として持つ事は難しい.電力はある波形が入ったときに流れた電荷量の積分値に電圧をかけたもの(エネルギー)から,出力容量の充放電エネルギー量,リークによるエネルギー量を引くことで内部電力(正確にはエネルギー)を計算する.

.libの Power Table は,第一軸入力スリュー,第二軸出力容量,そして肝心の第三軸はトグルあたりのエネルギーなっている(Eint/transition, in units of fJouls).
リーク電力は入力論理値それぞれ一意の値となる.

・電力解析側(PowerCompiler)
こちらは一部憶測で,回路の消費電力を以下のように計算すると思われる(トグル確率による平均電力評価の場合).
(1) リーク電力:入力がHighの確率,Lowの確率,それぞれの時のリーク電力からリーク電力の期待値を計算し,全てのセルの総和を取る.
(2) 内部電力:全ての入力から出力へのエネルギー量に,入出力の遷移確率とパスの重みをかけたものの総和を取る※
(3) スイッチング電力:全てのパスの出力容量と対応するトグル確率をかけた物の総和をとり,Vdd^2/2をかける.

動的電力の単位は.lib中の容量単位,電圧単位,時間単位から以下のように計算する.静的電力は単位が.libに書いてある.

power_unit = (capacitive_load_unit * voltage_unit^2)/time_unit

要約すると以下の通り.
・キャラクタライズ側は,きちんとエネルギーを測ってそれをエネルギーとして Power table に登録している.リーク電力はそのまま.
・解析側は,Power tableに書かれたエネルギーとトグル確率から動的エネルギーを計算し,電力に変換.リーク電力は全セルの和をとる.

あたりまえ?かもしれないが,動的電力は回路が動いたときに消費した正味の電力なので,意味合いはエネルギーと等価.電力を周期で割った物ではない.

最初から最後までエネルギーとして取り扱えばこんな問題は起きなかったのに,なんでなんや...

※P_int = Σ_{i=A,B} E_{i→Z} x PathWeight x TggleRateという式がでてくる(A,Bは入力,Zは出力).P_intはエネルギーの総和を評価している.

.lib (Liberty)については Synopsys がその仕様をオープンにしているので参考にした.といっても800ページ近くあるので一部だけしか読めてないですが.

2020年6月19日金曜日

SiliconSmart のタイムステップ

SiliconSmart が呼び出すシミュレータのタイムステップは以下のパラメータで制御できる.

time_res_high
クリティカルな解析におけるシミュレーションタイムステップの最大値.高精度な過渡解析で必要となる最小の時間解像度となる.
デフォルト値:1e-12
レンジ:1e-15~1e-3

time_res_low
シミュレーションタイムステップの最大値.荒い時間分解の最大値となる.
デフォルト値:100e-12
レンジ:1e-15~1e-3

ちなみに,time_res_high のデフォルト値は 2016 はマニュアルの記載では 1e-10 なのだが,誤植です.Magma 発行の 2007 のマニュアルには 1e-12 が記載されていた.長年の疑問が解けた..

2020年6月16日火曜日

Libertyモデル(.lib)における,index_1とindex_2のxy軸対応

index_1がy軸,index_2が横軸.

fall_constraint(mpw){
index_1("0.1, 0.2, 0.3");
index_2("0.1, 0.2");
values( "1.10 1.11", \
"1.12 1.13" \
"1.14 1.15");
}

index_x,index_yとすればよかったのにね.開発当時多次元Matrixを想定していなかったのだろう.Liberty のフォーマットは結構レガシーなので,そういう問題が多々あったりする(エネルギーではなくPowerで計算していたり)

参考:Library Compiler User Guide, 2017

2020年6月15日月曜日

SiliconSmart で入力容量を評価するパラメータ:cin_bias_capacitance, set subtract_leakage

SiliconSmart で入力容量を評価する際,あまりに容量が小さいとシミュレーションが不正確になるので,SiliconSmart はドライバの出力に容量をつけてシミュレーションを行う.シミュレーション後入力容量の評価ができた後で,この容量は削除される.
pintype グループの cin_bias_capacitance パラメータで制御することができ,初期値は 10ff である.

set cin_bias_capacitance 10ff

SiliconSmart は入力容量を求めるために,入力ピンの電流を cin_low_threshold  から  cin_high_threshold の間で積分する.IO セルのようにリーク電流が大きいセルをキャラクタライズする場合,pintype パラメータの subtract_leakage 1に設定するとcin_low_threshold および cin_high_threshold のパラメータを無視するようになる.

set subtract_leakage 1

2020年6月9日火曜日

SiliconSmartでキャラクタライズする項目を限定する

SiliconSmartでキャラクタライズする項目を限定するには,characterizeコマンドに-matchオプションをつける.

characterize -match {setup*|hold*|delay*} cells

-match オプションでマッチしたシミュレーションのみが実行される.runtime ディレクトリを見るとどのようなシミュレーションが実施されるかわかる.代表的なのは以下.
Cin:入力容量評価
delay:遅延評価
energy:動的エネルギー評価
hold:ホールド時間評価
initialization:初期状態の各ノードの電圧評価
leakage_power:リーク電力評価
ncmpw:最小パルス幅評価
setup:セットアップ時間評価

2019年10月2日水曜日

SiliconSmartでシミュレーションが走らない時のメモ

SiliconSmart を使ってキャラクタライズさせるときに,タスクは生成されるもののシミュレーションが走らず10時間経って自動で落ちてしまう,CPU が動いている気配もない,とはまったのでメモ.

SiliconSmart の DP Managerを使っていると,runtime/cdpl の中にログが生成される.

runtime/cdpl/worker.W1.[マシン名].[数字].log

ここに個々の Worker の動作ログが格納されるので,動作不良のヒントになる.

今回は,/etc/sysconfig/network-scripts で実際割り当てているIPアドレスと,/etc/hosts で書いた自分自身の IP アドレスに不整合があり,存在しない IP アドレスにジョブを投げようとしておかしな事になっていた.標準出力に出してくれればよかったのだけれど,難しいか.


2019年3月10日日曜日

SiliconSmart の実況状況をGUI表示する(DP Manager)

SiliconSmartで分散コンピューティングしているときの各Workerの状況をGUIで確認するにはDP Managerを使う事ができる.

~sis_install_dir/cpdl_runtime/bin/dpmanager


緑は処理完了,赤は未了を示す.

2018年12月20日木曜日

SiliconSmartでHSPICEのライセンスを使わない(HSPICE_embedded)

SiliconSmart 2016では,シミュレータとしてHSPICE_embeddedを選択する事ができ,これを使うとSiliconSmartのライセンスだけでHSPICEを用いてキャラクタライズをする事ができる.
(ただしHSPICEは2015.06より新しくないといけない)

configure.tclのシミュレータ選択に以下のように書けばよい.

set simulator hspice_embedded
set simulator_cmd { full-path-to-hspice < input_deck > -o < listing_file >}


これでHSPICEのライセンスをモリモリ消費せずにキャラクタライズを回せる.

2018年12月17日月曜日

SiliconSmart Aceで出力スリューの大きいセルをキャラクタライズする

SiliconSmart Aceで特に出力がRail-to-Railにスイングしにくいセルをキャラクタライズするには以下の設定を追加する.

・configure.tclに対する追加
set total_slew_multiplier [val]
内部パラメータであるtotal_slewの定数倍を指定する.total_slewは遅延やエネルギーを計算するウィンドウを示すパラメータで以下の式で計算される.
total_slew = largest_slew / (logic_high_threshold - logic_low_threshold) * total_slew_multiplier
largest_slewは入力スリューの最大値.

・該当セルの.instに対する追加
set_config_opt -type -timing -to [PIN] -pin [PIN] partial_swing 1
フルスイングしない信号ピンに対し,Rail-to-Rail以外の電圧を評価できるようにする設定.partial_swing を 1 にすると,SiliconSmartの波形解析エンジンではなく,.measureで評価した電圧の絶対値を評価するようになる.ただ,デバッグ用?でNLDMに使えるのかはよくわからない.

2018年10月16日火曜日

SiliconSmart がキャラクタライズに失敗するときの対策

SiliconSmart を用いてキャラクタライズをしているとき,あまりにも遅いセルを使っていると

Info:    Failed tasks:
Info:      INV_01X_1:
Info:          delay__A__lh__YB__hl__ACQ_1

とキャラクタライズに失敗する.セルが最大入力スリュー時間制約(=シミュレーション時間制約)や最大出力スリュー制約を満たさない時,このようにキャラクタライズに失敗する.この場合,時間制約を延ばすと出力が反転しシミュレーションに成功する可能性がある.これらスリューの制約は以下の設定で変えられる.

largest_slew float:最大入力スリュー時間
max_tout float:最大出力スリュー制約

長くするとそれだけシミュレーション時間が長くなる.

2018年2月28日水曜日

intel Core-i7 vs AMD Ryzen for HSPICE

intel Core-i7 と AMD Ryzenの速度比較を行った.比較方法は多くの人が身近によく使う Synopsys HSPICEの実行速度で,正確にはSiliconSmart ACEで69種の論理セルを持つセルライブラリのキャラクタライズ速度で比較した.

Core-i7 マシン:
intel Core-i7 4790 Base: 3.6GHz Boost: 4GHz 4-core 4-thread (Haswell)
DDR3-1600 dual-channel 8GB
Cent OS 6.8

Ryzenマシン:
AMD Ryzen Threadripper  Base: 3.4GHz Boost: 4GHz 16-core 16-thread (Summit Ridge)
DDR4-2400 quad-channel 32GB
Cent OS 7.4

CADはライセンス数に限りがあるのでハードウエアマルチスレッディングは共に無効(Core i7についてはONでも実験してみた).キャラクタライズは並列実行するが,終盤はコアが余り出すので並列性は落ちる.
HSPICE は vJ-2014.09-SP1-2 を利用した.なお HSPICE は SSE2 を使うらしい(SSE2が無いと動かない).周波数ブーストはあり.全然 apple-to-apple ではないけれどしゃーなしやな.

結果:
Ryzen: 25:42.99
Core-i7: (4-thread)1:48:04.94,(8-thread) 1:49:25.39
Ryzenの方が4.2倍高速という結果に.Baseのクロック周波数低いのに処理速度が速いということはIPCがよいのね.Summit RidgeはAVXなどが弱いがSSE2しか使わないなら十分戦える,これならEPYCも期待できそう.


2018年2月23日金曜日

SiliconSmartAce で利用するCPU数を設定する

SiliconSmartAceはキャラクタライズ時に使うCPUの数が増えるとそれだけ並列にSPICEシミュレーションを回すので処理が高速になる.
CPUの数は,

config/configure.tcl

のグローバル構成情報を記述する項目

define_parameters default{

中の,

set run_list_maxsize {NUMCPU}

の{NUMCPU}の数字を変える.16CPUなら16とする.

2014年2月20日木曜日

Silicon Smartにおける"no convergence"の一原因

Silicon Smart AceとHSPICEを使ってスタセルのキャラクタライズを行っていたところ,以下の様なエラーをHSPICEが出力しキャラクタライズがとまる事態が発生した.

Error: Simulation initialization__ACQ_1.sif for cell SN51DFFRBQXC1 failed.
Error: Error while running simulation: Error found in simulator log file (deck.lis): **error** no convergence in operating point


キャラクタライズ対象のセルのネットリストが正常に動作する場合,Silicon Smartに入力する論理情報およびキャラクタライズ条件に不備がある可能性がある.今回のセル(非同期リセット付きポジティブエッジDFF)の場合,セルのインスタンスファイル(.inst)のピンの定義および論理情報は適切であったが,オプションのユーザー定義のキャラクタライズ条件(User-specified characterization and modeling configuration options.)に不備があり,Reset時の条件が書かれていなかった.そのため変なSPICE Deckを生成したと思われる.
LPEした回路の不備かと思った.紛らわしいエラーだ.

2013年6月19日水曜日

SiliconSmart備忘録

SiliconSmart ACEを研究室の子に教えてもらったのでメモ.

最低限必要なのは
・全体の設定ファイル(configure.tcl)
・各セルごとの論理を定義したファイル(.inst).
・SPICEネットリスト.
configure.tclはインストールディレクトリにテンプレがある..instは無ければ手で作れとのこと.既存の.libがあればそれから生成することもできる.

各ファイルのディレクトリ構造は(ほぼ)固定である.SiliconSmartはカレントディレクトリのディレクトリ構造から,各設定ファイルを読み取る.ディレクトリ構造は以下となっている.
./config # configure.tclを入れる.
./control # .instファイルを入れる.
./netlists # ネットリストを入れる.これは別のディレクトリを指定できる.

キャラクタライズの条件はconfigure.tclにも,.instにも,そして既存の.libからも読み取ることができる.
優先度が存在し,高い順に
.inst > configure.tcl > .lib
である..libにIndexの切り方とか指定していても全然反映されず詰まった.

キャラクタライズで利用するSPICEファイルの拡張子は.cir.別の拡張子を使うときはimport時に-extオプションを使う.

Magmaのツールなので,平等にNLDMもCCSもESCMも出せる.

セルの面積情報を付加することができない.やり方はマニュアルに書いてあるが,.libに反映されない.バグ?