2023年2月3日金曜日

ICC の配線を早めに諦めさせる (set_route_opt_strategy)

IC Compiler で配置配線を行うと IC Compiler は設計が収束するまでブロック分割などの配線ストラテジを変えながら配線を何度もトライするが,設計初期の見積もりなどでは試行錯誤の回数を減らして CPU 占有時間を減らしたい.配線 (route_opt) の戦略を変えるには,set_route_opt_strategy コマンドがあり,うち2つのオプションにて配線の試行回数を制御できる.

set_route_opt_strategy --route_drc_threshold [NUM1] --search_repair_loops [NUM2]

--search_repair_loops オプションは,配線時に Violation が出たときに,配線戦略(ブロック分割など) を変えて再度配線を行う試行回数の数を制御する.NUM2 は0から500の整数で,その初期値は classic router では15,zroute では10.

--route_drc_threshold オプションは,詳細配線時にどれだけ Violation が出たら配線そのものを諦めるかという閾値.初期値は3000.-1を指定すると,IC Compiler は(DRC Thresholdを?)チェックせず無制限に詳細配線の再実行を行う.

ちなみに(?),Synopsys IC Compiler は命令するとそれが理不尽でも延々と頑張る(そしてえらく時間がかかってようやく諦める)印象で,Cadence SoC Encounter はいくら命令しても一向に言うことを聞かない印象である.Innovusは知りません.

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 演算をしないのがミソなのかな...

2023年1月29日日曜日

PrimeTime の report_timing オプション

オプションが多すぎてよくわかっていないのでまとめた.

pt_shell> report_timing [options1] [option2] ...

-from from_list
特定のパス,ピン,セルおよびインスタンスから始まるパスを解析する時に from_list にそれらを指定する.もしくはクロックを指定するとそのクロックから始まるパスを解析する.

-rise_from rise_from_list
-from オプションと同様だが,立ち上がり波形から始まる場合に解析する.クロックを指定する場合,クロック立ち上がり条件から解析する.

-fall_from fall_from_list
-rise オプションと同様.

-to to_list
特定のパス,ピン,セルおよびインスタンスに向かうパスを解析する時に to_list にそれらを指定する.もしくはクロックを指定するとそのクロックから始まるパスを解析する.
PrimeTime の性質上,-to オプションの方が -from オプションよりも効率的なので,end-point 指向のタイミング解析(-to)の方が,start-point 指向のタイミング解析より性能がよい.

-rise_to rise_to_list
-to オプションと同様だが,立ち上がり波形で終わる場合に解析する.クロックを指定する場合,endpoint がクロック立ち上がり波形にキャプチャされる場合を解析する.

-fall_to fall_to_list
-rise_to オプションと同様.

-through through_list
特定のパス,ピン,セルおよびインスタンスを通過する波形を解析する.本オプションは複数回指定する事が可能で,指定されたすべての through_list を通過する波形を解析する.例えば,A1 を通過し,B1 もしくは B2 を通過し,C1 を通過し,D1 に到達するパスを解析する場合は以下のように指定する.

pt_shell> report_timing -from A1 -through {B1 B2} -through C1 -to D1

-rise_through rise_through_list
-trought オプションと同様だが,立ち上がり波形である場合を解析する.

-fall_through fall_through_list
-rise_through オプションと同様.

-exclude exclude_list
特定のパス,ピン,セルおよびインスタンスを通過する波形を除外する.データパスが対象でクロックは非対称.-exclude オプションを利用すると非常に解析時間がかかるので,-from -through オプションなどを併用し探査空間を減らすと良い.-exclude オプションは -trace_latch_borrow オプションで考慮するタイムボロウィングをチェックしない.

-rise_exclude rise_exclude_list
-exclude オプションと同じだが,立ち上がり波形の場合を除外.

-fall_exclude fall_exclude_list
-rise_exclude オプションと同様.(man は rising と書いているが falling の間違いだろう)

-delay_type delay_type
遅延解析の対象を指定する.取り得る delay_type は以下の通り.
max (default) : 最大遅延(セットアップ制約)
min : 最小遅延(ホールド制約)
max_min : 最大遅延,最小遅延両方.先に最小遅延を報告し,次に最大遅延を報告
max_rise : 最大遅延のうち立ち上がり波形で endpoint に到達するもの
max_fall : 最大遅延のうち立ち下がり波形で endpoint に到達するもの
min_rise : 最小遅延のうち立ち上がり波形で endpoint に到達するもの
min_fall : 最小遅延のうち立ち下がり波形で endpoint に到達するもの

-nworst paths_per_endpoint
各 endpoint に到達する最悪遅延パスの数.デフォルトは1,最大2000000.1以上を指定するとツールは以下の処理を行う.
-max_path が指定されていない場合は -max_path paths_per_endpoint を明示的に設定し,一つの endpoint に向かう複数パスの解析結果を報告する.
-slack_lesser_than もしくは -slack_greater_than が指定されていない場合は-slack_lesser_than 0 を明示的に指定し,タイミング違反するパスのみを報告する.

-max_paths max_path_count
報告するパス数を指定する.デフォルトは1.最大2000000.1以上を指定すると
ツールは以下の処理を行う.
-slack_lesser_than もしくは -slack_greater_than が指定されていない場合は-slack_lesser_than 0 を明示的に指定し,タイミング違反するパスのみを報告する.

-nworst
本報告対象となる各 endpoint に向かうパス数を変える.なお -max_path は報告する総パス数を変更する.-max_paths のオプションは -nworst のオプションより同じか大きくなくてはいけない.デフォルトでは両者は同じになる.

-group group_name
group_name に属するパスのみ報告する.group_name create_clock コマンドか,group_path コマンドで生成された物である.-group オプションを利用しない場合は全パスを解析する.

-unique_pins
指定されたピンリストに該当する最悪遅延パスのみ報告し,同じピンリストを通過する(より違反の小さい)他のパスを報告しない.いわゆる "non-unate" である XOR 論理は立ち上がり・立ち下がり波形の候補が大量にあるため,本オプションを"non-unate" 論理に適用するとタイミング違反の報告数を劇的に減らす事ができる.

-slack_greater_than minimum_slack
minimum_slack より大きい Slack を持つパスのみ報告する.-slack_lesser_than と併用すると,指定する範囲の Skack を持つパスのみ抽出する事もできる.

-slack_lesser_than maximum_slack
mnaximum_slack より小さい Slack を持つパスのみ報告する.デフォルトは0.-nworst もしくは -max_paths で1より大きい値を指定する場合,Negative Slack であるすべてのパスを解析する.

-ignore_register_feedback feedback_slack_cutoff
同じレジスタの入出力をつなぐ非反転ループを解析対象から外す.この場合,入力から出力,出力から入力の値が共に同一(非反転)である必要がある.最大遅延,最小遅延共に適用される.Slack の値が feedback_slack_cutoff より小さいパスのみが本オプションによって解析から除外される.

-report_ignored_register_feedback
-ignore_register_feedbackで除外されたパスリストを報告する.

-include_hierarchical_pins
タイミングリポートに階層をまたいだ点,パス内のスタセルのピンの情報を載せる.ドキュメント化支援の機能で,各点は遅延ゼロとして報告される.

-trace_latch_borrow
トランスペアレントラッチから始まるパスの遅延を報告する.特にタイムボロウィングしている場合,本オプションを利用する事でタイムボロウィングしているパスと対象のラッチ,非タイムボロウィングパスと順序セルのループなどを評価する事ができる.

-trace_latch_forward
トランスペアレントラッチの入力 D ピンで終わるパス遅延を報告する.ラッチ遅延解析機能を有効にし(timing_enable_through_paths true)かつ対象のラッチの入力が required time によって制約されている場合,本制約に必要となった入力 D ピンに関与するパス中のFanout が報告される.(理解に自信なし)

-pba_mode none | path | exhaustive | ml_exhaustive
パスベース解析モードを指定する.
none (default): パスベース解析をせず,通常のグラフベース解析を行う.最速.
path : グラフベース解析によってまとめられたパスに対してパスベース解析を行う.より高精度な解析が可能.pba_path_mode_sort_by_gba_slack 変数を変更する事でまとめるパス数(?)を変更可能.
exhaustive : より徹底したパスベース解析を行い,真のワーストケースパスを見つける.最も高精度だが計算負荷が高い.
ml_exhaustive : 機械学習ベースの exhaustive パスベース解析.精度と速度のトレードオフを見つける.
パスベース解析を利用するとパス間の分離を考慮する事が可能となり,クロストークや CRPR (Clock Reconvergence Pessimism Removal) のあり得ないパスを解析から除外できる.そのためこれらの解析の悲観性を改善する事が可能.

-start_end_type from_to_type
報告内容を以下の選択肢に指定する事ができる.
reg_to_reg : レジスタ間
reg_to_out : レジスタからマクロ出力
in_to_reg : マクロ入力からレジスタ
in_to_out : マクロ入力からマクロ出力
マクロの双方向入出力は in,out 共に対象となる.

-normalized_slack
実際の Slack ではなく,許容される最大遅延(クロック周期)で正規化した Slack を用いて報告する.本オプションは timing_enable_normalized_slack 変数を true にした場合に有効.

-start_end_pair
各 Startpoint から Endpoint のペアに対して,最悪となるパスを表示する.-slack_lesser_thanを併用している場合は,-slack_lesser_thanで指定した値より悪いパスを表示する.本オプションを利用すると Default の振る舞い(回路中の最悪パスのみを表示)とは異なり,すべての各 Startpoint から Endpoint のペアに対して遅延解析結果を示すため計算量及びレポートは膨大となる(なお DesignCompiler や IC Compiler 内部の STA エンジンとは異なる振る舞いを示す).解析対象を制限し実行時間とログを減らすために -slack_lesser_than や,-from -to を併用する事が望ましい.また本オプションを利用する場合は -nworst, -max_paths, -unique_pins, -slack_greater_than, -ignore_register_feedback オプションは併用できない.

-cover_design
違反している各ピンに対して最悪パス遅延を表示する.「違反」とは,Slack が負か,-slack_lesser_than より悪い事を示す.本オプションは以下のオプションとは併用できない.
-nworst
-max_paths
-unique_pins,
-ignore_register_feedback
-report_ignored_register_feedback
-start_end_pair
-pba_mode exhaustive
path_collection

-cover_through through_list
throu_list に定義したピン,ポート,セルインスタンス,ネットを通過する最悪違反パスを一つ報告する.Slack が負か,-slack_lesser_than より悪い事を示す.
以下のオプションとは併用できない.
-nworst
-max_paths
-through / -rise_through / -fall_through
-exclude / -rise_exclude / -fall_exclude
-unique_pins
-ignore_register_feedback
-report_ignored_register_feedback
-start_end_pair
-pba_mode exhaustive
path_collection

-dont_merge_duplicates
PrimeTime が -multi_scenario オプションで起動している時に,複数シナリオ間でパスをマージしたり複製する事を防ぐ.本オプションを利用しない (Default) では,複数シナリオで同じパスが報告対象となった場合,最もクリティカルな物を PrimeTime は報告する.本オプションを利用するとパスのマージや複製を行わず,同じパスであっても報告をする.

-pre_commands pre_command_string
セミコロンで区切った PrimeTime のコマンドを command_string に指定する事で,
-multi_senario オプションにおいて report_timing を実行する前にworker (slave) にcommand_list を渡すことができる.

-post_commands post_command_string
-pre_commands と似ているが,post_command_string report_timing 実行後に実行される.

-path_type format
タイミングリポートに示すパスの種類を選択する.format は以下の通り.
summary : パスの startpoint,endpoint, slack を表示
end : パスの endpoint, パス遅延,requred time, slack を表示
short : Defaultの様にすべてを表示するが,startpoint から endpoint へ向かう中間ノードは表示しない.
full (default): すべての情報を表示する.すなわちすべての中間ノードにおける遅延の加算値と積算値,また clock の launch と capture time, データの required time, slackを表示する.
full_clock : full に加え,クロック源 から launch, capture までのクロックパスの情報も表示する.
full_clock_expand : full_clock に加え, primary clock から generated clock までのパスも表示する.generated clock が無い場合は full_clock と同じ.

-input_pins
タイミングパスのすべての入力ピン,出力ピンを表示.その結果,ゲート遅延と配線遅延が分かれて報告される.使わない場合(Default)は出力ピンのみ表示.

-nets
タイミングパス中の配線を表示.使わない場合(Default)は表示しない.

-nosplit
レポート分割しない.

-transition_time
遷移遅延(slew)を報告する.

-capacitance
パスの総キャパシタンス容量を報告する.report_capacitance_use_ccs_receiver_model 変数の設によって,CCS receiver容量(default) か,ランプ容量を選択できる.

-significant_digits digits
報告値の小数点を 0 から 13 の間で指定する.初期値は report_default_significant_digits 変数で制御でき,その Default は2.

-crosstalk_delta
"Delta" の列として,各セルの入力ピンにクロストークデルタ遅延を表示する.解析は自動的に -input_pins となる.Delta 遅延はクロストークシグナルインテグリティ解析を実行した場合か,set_annotated_delay -delta_only もしくは set_annotated_transition -delta_only を指定した場合に計算される.本オプションは解析結果を報告に加えるだけで,解析そのものは前出のコマンドであらかじめ実行しておく.Delta 遷移遅延は -transition_time をつけると表示する.

-derate
"Derate"の列として,ディレーティング係数(derating factors)をセルと配線に対して表示する.Defaultでは表示しない.解析は自動的に -input_pins となる.-path_type full_clock_expanded オプションを併用すると,ディレーティングがパス全体に及ぼす影響を示す事ができる.

-variation
"Mean" と "Sensit" の列として,parametric on-chip variation (POCV)の情報を表示する.POCV 解析のためには timing_pocvm_enable_analysis 変数を true にしておく必要がある.

-exceptions dominant | overridden | all
ユーザー定義のタイミング例外を報告する.
dominant では支配的なタイミング例外を報告する.例えば false path,最大及び最小遅延,マルチサイクルパスなど.
overriden では, dominant で上書きされたタイミング例外を報告する.
制約の無い (unconstrained) パスやその理由は,timing_report_unconstrained_paths 変数が true の場合にすべての解析で表示される.
get_timing_paths オプションのパスグループに観測対象のパスをあらかじめ指定する事で対象の観測対象に絞って報告できる.

-voltage
"Voltage" 列として,各素子の動作電圧を表示する.

-supply_net_group
"Supply-Net-Group " 列として,パス中の各素子の電源グループ名や電源配線名を示す.電源グループ名が未定義の場合は "unconnected" と表示される.電源配線名が定義されているが電源グループが未定義の場合,電源配線名の先頭に "n" が付与される.

-physical
"Location" 列として,各素子の X-Y 座標を報告する.事前に read_parasitics コマンドの実行と read_parasitics_load_locations 変数を true にする必要がある.座標情報が無い場合は"unplaced"と表示する.

-sort_by group | slack
報告するパスをグループ(default)もしくは slack でソートする.

-tag_paths_filtered_by_pba tag_name
-pba_mode を利用している場合,本オプションを利用する事で path-based 解析ですべてのパスをタギングし,次の path-based 解析で同じタグ名を利用する.path-based 解析後の get_timing_paths もしくは  report_timing に -exclude オプションと共にタグ名を指定すると,指定したパスを解析から外す事ができる.

-imsa_session session_name
eco_update_path_timing を有効にし IMSA モードの時のみ有効.Default では IMSA モード はメモリ内のすべてのパスを解析するが,本オプションを使うと特定のセッションのみ解析する.

path_collection
報告するパスを指定する.例えば変数 mypaths に [get_timing_paths ...]で指定する.

-dvfs_scenarios dvfs_scenarios_list
解析する DVFS シナリオの一覧を指定する.本オプションは SMVA 解析でのみ有効.DVFSシナリオは get_dvfs_scenarios コマンドで生成する.

-domain_crossing domain_crossing_mode | all | only_crossing | exclude_crossing
domain crossing report モードを指定する.Default は all.特定のモードに
指定されているパスのみを示す.all を指定すると,ドメインを横断するパス,ドメイン内の
パスすべてを考慮する.only_crossing ではドメインを横断するパスのみを報告し,exclude_crossing ではドメイン内のパスの未報告する.SMVA 解析でのみ有効.

-yield
設計歩留まりに貢献するパスの一覧を生成する.歩留まりに貢献しないパスを除外し,続く get_timing_yield コマンドにおいてパラメトリック歩留まり分析に活用される.本オプションは -pba_mode exhaustive オプションでのみ有効.本オプションは get_timing_paths  および get_timing_yield 実行時の実行時間とメモリ利用量を劇的に軽減できるため,歩留まり解析では常に使うと良い.

2023年1月26日木曜日

PrimeTime で Positive Slack Path を表示する(report_timing -slack_lesser_than)

PrimeTime で STA の結果を表示するには report_timing を使うが,標準では Negative Slack しか表示せず,すべてタイミングを満たしている場合は解析結果が表示されないようだ.表示する閾値は -slack_lesser_than オプションで制御できるので,Positive Slack を表示するには -slack_lesser_than オプションに正の値を指定する(デフォルトは0,単位は.libのもの).

report_timing -delay_type min -slack_lesser_than 10

2022年11月26日土曜日

サーバーの物理的に引っ越したらネットワークがつながらなかった

サーバーを物理的に別の場所に引っ越したらネットワークにつながらなくて7ヶ月ほど長らく苦しんでいた.オチとしては,

/etc/sysconfig/network-scripts/ifcfg-xxxx

が前の場所に向けて設計されていたので,NetworkManager (GUI) の設定と矛盾していて動作ができなかったみたい.接続プロファイル作り直したらあっさり動いてトホホ.どこカスタムしたかなんて覚えてないしな.OS 入れ直せばよかったのかも.(でも OS 入れ直すと CAD 動かすためのシェアードファイル探すの大変だしな)

2022年10月12日水曜日

DesignCompilerの電力解析結果

 ボスが面白いデータをくれた.DesignCompiler の電力解析結果である.乗算器を遅延制約を変えて合成している.

Period Intl     Switch Leak         Total
1 ns 636.4446 uW 523.31 uW 2.20E+04 nW 1.18E+03 uW
10 ns 63.6445 uW 52.331 uW 2.20E+04 nW 137.9381 uW
100 ns 6.3645 uW 5.2331 uW 2.20E+04 nW 33.5603 uW

すべて電力(ワット)で書かれているが,単なる和では Total は求まらない.

変換するにはエネルギーに変える.回路が同じだから処理あたりのエネルギーは同じ.
Intl+Sw (Power)        Intl+Sw (Energy)
1159.7546    nW 1159.76 fJ
115.9755     nW 1159.76 fJ
11.5976     nW 1159.76 fJ

リークもエネルギーに変える.単位時間に応じてリークは増える.
Leak (Energy)
2.20E+04 aJ
2.20E+05 aJ
2.20E+06 aJ

和を取ってエネルギーを求め,それをクロック時間で割って時間あたりのエネルギーである電力を計算する.結局,DesignCompilerの電力解析結果は,サイクルあたりの電力の総和を計算している事になる.
Total (Energy) Total (Power)
1.18E+03 fJ 1.18E+03 uW
1.38E+03 fJ 1.38E+02 uW
3.36E+03 fJ 3.36E+01 uW

[内部電力] = [内部エネルギー] / [時間]
[外部電力] = [外部エネルギー] / [時間]
[処理あたりのエネルギー] = [内部電力 + 外部電力 + リーク電力] * [時間] 
ということですね.



2022年9月13日火曜日

ランダウアーの原理と集積回路のエネルギー

ランダウアーの原理で盛り上がっていたので調べてみた.

ランダウアーの原理:情報を1bit消去するために必要なエネルギー:k T ln2
k: ボルツマン定数,T:絶対温度

室温だと E_landauer = 1.38e-23 JK-1 * 300K * ln2 = 2.87e-21 J

intel Broadwell-U が13億トランジスタで,ざっくり半分がコア,半分アンコアとしてコア部を構成するのは6.5億トランジスタ,これをざっくり NAND2 換算すると1.4億ロジックゲート,すべての NAND2 で1サイクルあたり 1 E_landauer を消費するとして,サイクルあたり4.02 e-13 J,3 GHz で動いて 1.2e-3 J/s = 1.2 mW といったところ.TDPが15W なので,ランダウアーの原理で消費するエネルギーは全体に比べて1万分の1程度である.

今の集積回路のエネルギーはトランジスタのゲート容量や拡散配線などの寄生抵抗容量で構成されていて,仮に「寄生」成分がない理想的な状況であっても (CMOS) トランジスタのゲート容量は本質的に必要なので,ランダウアーの原理がコンピュータの消費エネルギーを支配する事は当分はなさそう.

2022年9月8日木曜日

ASAP7 のセルライブラリの一覧

 良く忘れるので載せておく.7.5 Track セルです.
# AND-OR
A2O1A1Ixp33_ASAP7_75t_R.gds
A2O1A1O1Ixp25_ASAP7_75t_R.gds
AO21x1_ASAP7_75t_R.gds
AO21x2_ASAP7_75t_R.gds
AO22x1_ASAP7_75t_R.gds
AO22x2_ASAP7_75t_R.gds
AO31x2_ASAP7_75t_R.gds
AO32x1_ASAP7_75t_R.gds
AO32x2_ASAP7_75t_R.gds
AO33x2_ASAP7_75t_R.gds
AO211x2_ASAP7_75t_R.gds
AO221x1_ASAP7_75t_R.gds
AO221x2_ASAP7_75t_R.gds
AO222x2_ASAP7_75t_R.gds
AO322x2_ASAP7_75t_R.gds
AO331x1_ASAP7_75t_R.gds
AO331x2_ASAP7_75t_R.gds
AO332x1_ASAP7_75t_R.gds
AO332x2_ASAP7_75t_R.gds
AO333x1_ASAP7_75t_R.gds
AO333x2_ASAP7_75t_R.gds
# AND-OR-INVERTER
AOI21x1_ASAP7_75t_R.gds
AOI21xp5_ASAP7_75t_R.gds
AOI21xp33_ASAP7_75t_R.gds
AOI22x1_ASAP7_75t_R.gds
AOI22xp5_ASAP7_75t_R.gds
AOI22xp33_ASAP7_75t_R.gds
AOI31xp33_ASAP7_75t_R.gds
AOI31xp67_ASAP7_75t_R.gds
AOI32xp33_ASAP7_75t_R.gds
AOI33xp33_ASAP7_75t_R.gds
AOI211x1_ASAP7_75t_R.gds
AOI211xp5_ASAP7_75t_R.gds
AOI221x1_ASAP7_75t_R.gds
AOI221xp5_ASAP7_75t_R.gds
AOI222xp33_ASAP7_75t_R.gds
AOI311xp33_ASAP7_75t_R.gds
AOI321xp33_ASAP7_75t_R.gds
AOI322xp5_ASAP7_75t_R.gds
AOI331xp33_ASAP7_75t_R.gds
AOI332xp33_ASAP7_75t_R.gds
AOI333xp33_ASAP7_75t_R.gds
# AND2-4 
AND2x2_ASAP7_75t_R.gds
AND2x4_ASAP7_75t_R.gds
AND2x6_ASAP7_75t_R.gds
AND3x1_ASAP7_75t_R.gds
AND3x2_ASAP7_75t_R.gds
AND3x4_ASAP7_75t_R.gds
AND4x1_ASAP7_75t_R.gds
AND4x2_ASAP7_75t_R.gds
AND5x1_ASAP7_75t_R.gds
AND5x2_ASAP7_75t_R.gds
# DFF w/ asyncronous set/reset
ASYNC_DFFHx1_ASAP7_75t_R.gds
# Buffer (f is fast: FO3, other: FO4,5,6)
BUFx2_ASAP7_75t_R.gds
BUFx3_ASAP7_75t_R.gds
BUFx4f_ASAP7_75t_R.gds
BUFx4_ASAP7_75t_R.gds
BUFx5_ASAP7_75t_R.gds
BUFx6f_ASAP7_75t_R.gds
BUFx8_ASAP7_75t_R.gds
BUFx10_ASAP7_75t_R.gds
BUFx12f_ASAP7_75t_R.gds
BUFx12_ASAP7_75t_R.gds
BUFx16f_ASAP7_75t_R.gds
BUFx24_ASAP7_75t_R.gds
# Posedge clk DFF w/ neg. data polarity (QN<=!D)
DFFHQNx1_ASAP7_75t_R.gds
DFFHQNx2_ASAP7_75t_R.gds
DFFHQNx3_ASAP7_75t_R.gds
# Posedge clk DFF w/ pos. data polarity (Q<=D)
DFFHQx4_ASAP7_75t_R.gds
# Negedge clk DFF w/ neg. data polarity (QN<=!D)
DFFLQNx1_ASAP7_75t_R.gds
DFFLQNx2_ASAP7_75t_R.gds
DFFLQNx3_ASAP7_75t_R.gds
# Negedge clk DFF w/ pos. data polarity (Q<=D)
DFFLQx4_ASAP7_75t_R.gds
# D-latch (High-transparent)
DHLx1_ASAP7_75t_R.gds
DHLx2_ASAP7_75t_R.gds
DHLx3_ASAP7_75t_R.gds
# D-latch (Low-transparent)
DLLx1_ASAP7_75t_R.gds
DLLx2_ASAP7_75t_R.gds
DLLx3_ASAP7_75t_R.gds
# Full adder
FAx1_ASAP7_75t_R.gds
# ?? (Not Half adder)
HAxp5_ASAP7_75t_R.gds
# Hold buffer (#stack)
HB1xp67_ASAP7_75t_R.gds
HB2xp67_ASAP7_75t_R.gds
HB3xp67_ASAP7_75t_R.gds
HB4xp67_ASAP7_75t_R.gds
# Integrated clock gating (ICG) cell
ICGx1_ASAP7_75t_R.gds
ICGx2_ASAP7_75t_R.gds
ICGx3_ASAP7_75t_R.gds
# Inverter
INVx1_ASAP7_75t_R.gds
INVx2_ASAP7_75t_R.gds
INVx3_ASAP7_75t_R.gds
INVx4_ASAP7_75t_R.gds
INVx5_ASAP7_75t_R.gds
INVx6_ASAP7_75t_R.gds
INVx8_ASAP7_75t_R.gds
INVx11_ASAP7_75t_R.gds
INVx13_ASAP7_75t_R.gds
INVxp33_ASAP7_75t_R.gds
INVxp67_ASAP7_75t_R.gds
# Majority (inverse, non-inverse)
MAJIxp5_ASAP7_75t_R.gds
MAJx2_ASAP7_75t_R.gds
MAJx3_ASAP7_75t_R.gds
# NAND
NAND2x1p5_ASAP7_75t_R.gds
NAND2x1_ASAP7_75t_R.gds
NAND2x2_ASAP7_75t_R.gds
NAND2xp5_ASAP7_75t_R.gds
NAND2xp33_ASAP7_75t_R.gds
NAND2xp67_ASAP7_75t_R.gds
NAND3x1_ASAP7_75t_R.gds
NAND3x2_ASAP7_75t_R.gds
NAND3xp33_ASAP7_75t_R.gds
NAND4xp25_ASAP7_75t_R.gds
NAND4xp75_ASAP7_75t_R.gds
NAND5xp2_ASAP7_75t_R.gds
# NOR
NOR2x1p5_ASAP7_75t_R.gds
NOR2x1_ASAP7_75t_R.gds
NOR2x2_ASAP7_75t_R.gds
NOR2xp33_ASAP7_75t_R.gds
NOR2xp67_ASAP7_75t_R.gds
NOR3x1_ASAP7_75t_R.gds
NOR3x2_ASAP7_75t_R.gds
NOR3xp33_ASAP7_75t_R.gds
NOR4xp25_ASAP7_75t_R.gds
NOR4xp75_ASAP7_75t_R.gds
NOR5xp2_ASAP7_75t_R.gds
# OR-AND
O2A1O1Ixp5_ASAP7_75t_R.gds
O2A1O1Ixp33_ASAP7_75t_R.gds
OA21x2_ASAP7_75t_R.gds
OA22x2_ASAP7_75t_R.gds
OA31x2_ASAP7_75t_R.gds
OA33x2_ASAP7_75t_R.gds
OA211x2_ASAP7_75t_R.gds
OA221x2_ASAP7_75t_R.gds
OA222x2_ASAP7_75t_R.gds
OA331x1_ASAP7_75t_R.gds
OA331x2_ASAP7_75t_R.gds
OA332x1_ASAP7_75t_R.gds
OA332x2_ASAP7_75t_R.gds
OA333x1_ASAP7_75t_R.gds
OA333x2_ASAP7_75t_R.gds
# OR-AND-INVERTER
OAI21x1_ASAP7_75t_R.gds
OAI21xp5_ASAP7_75t_R.gds
OAI21xp33_ASAP7_75t_R.gds
OAI22x1_ASAP7_75t_R.gds
OAI22xp5_ASAP7_75t_R.gds
OAI22xp33_ASAP7_75t_R.gds
OAI31xp33_ASAP7_75t_R.gds
OAI31xp67_ASAP7_75t_R.gds
OAI32xp33_ASAP7_75t_R.gds
OAI33xp33_ASAP7_75t_R.gds
OAI211xp5_ASAP7_75t_R.gds
OAI221xp5_ASAP7_75t_R.gds
OAI222xp33_ASAP7_75t_R.gds
OAI311xp33_ASAP7_75t_R.gds
OAI321xp33_ASAP7_75t_R.gds
OAI322xp33_ASAP7_75t_R.gds
OAI331xp33_ASAP7_75t_R.gds
OAI332xp33_ASAP7_75t_R.gds
OAI333xp33_ASAP7_75t_R.gds
# OR
OR2x2_ASAP7_75t_R.gds
OR2x4_ASAP7_75t_R.gds
OR2x6_ASAP7_75t_R.gds
OR3x1_ASAP7_75t_R.gds
OR3x2_ASAP7_75t_R.gds
OR3x4_ASAP7_75t_R.gds
OR4x1_ASAP7_75t_R.gds
OR4x2_ASAP7_75t_R.gds
OR5x1_ASAP7_75t_R.gds
OR5x2_ASAP7_75t_R.gds
# Scan-DFF w/ posedge clk
SDFHx1_ASAP7_75t_R.gds
SDFHx2_ASAP7_75t_R.gds
SDFHx3_ASAP7_75t_R.gds
SDFHx4_ASAP7_75t_R.gds
# Scan-DFF w/ negedge clk
SDFLx1_ASAP7_75t_R.gds
SDFLx2_ASAP7_75t_R.gds
SDFLx3_ASAP7_75t_R.gds
SDFLx4_ASAP7_75t_R.gds
# Tie cell
TIEHIx1_ASAP7_75t_R.gds
TIELOx1_ASAP7_75t_R.gds
# XOR, XNOR
XNOR2x1_ASAP7_75t_R.gds
XNOR2x2_ASAP7_75t_R.gds
XNOR2xp5_ASAP7_75t_R.gds
XOR2x1_ASAP7_75t_R.gds
XOR2x2_ASAP7_75t_R.gds
XOR2xp5_ASAP7_75t_R.gds

2022年8月24日水曜日

Google Siteを公開する

新しい Google Site に移行してから,Site が検索結果に表示されなくて困っていた.原因は Google Site の情報が Google Drive 上で非共有になっていたためだった.Google Drive で Google Site の情報を格納しているファイルを選択し,右側のメニューから「アクセスを管理」→「公開済みサイト」→「公開」を選ぶと Google 未ログインでもアクセスできるようになった.

自分自身は常に Google アカウントでログインしているから検索結果に出てくるのだが,非ログインで表示されなくてようやく気がついた.

2022年7月30日土曜日

作成したWebページを検索エンジンに表示させる (Google Search Consoleを使う)

とある国際会議の Web ページを作成したのだが Google 検索でヒットしない.しばらく放っておけばクロールされるのかもしれないが,手動で登録するには Google Search Console を使うらしい.


やるべき事は以下の通り.

・Google Search Console に目的のページを入力して自分の Google アカウントがサイトの所有権を持っているか確認する.

・所有権がない場合,所有権を認識するための HTML を Google Search Console からダウンロードし,目的のサイトに FTP などでアップする.

・Google が上記 HTML を認識したらGoogle Search Console で目的のサイトの検索パフォーマンスなどが表示できるようになる.

・クローラが Web サイトの構造を認識できるサイトマップを用意する.SEO 対策であれば XML や HTML で記述すべきらしいが Text 形式でアップした HTML の URL をリストアップするのでもよいみたい.

・アップしたサイトマップを Google Search Console 経由で登録する.ステータスが「成功しました」になればOK.

今回のケースは,サイトマップを登録したら則検索結果に反映されるようになった.ただ,学会名と開催年の間にスペースを入れないと見付からないけれど….