2023年4月27日木曜日

とある助教の公募戦線記録(2)

これまでに出した公募の結果が一段落したのでまとめてみる.検討したけれど出していないものもあげます.

スペック
・男
・集積回路の物理設計よりのCAD屋.回路設計もするよ
・応募時の業績:論文誌6本,レター3本,国際会議20本,その他
・科研費は若手x2,共同研究x2,分担がいくつか
・任期5年再任有りの3年目

こだわったところ
・集積回路設計特にCADに関わりたい
・PIは,私が知っている教員か,外部資金などを取っている教員を希望した
・お金は取ってこれるので地方国立大とかがいいのでは
・理想は関西圏だけれど西日本ならいいかな
・2年間ぐらいかけてのんびり就活する予定だった

2020/? 公立大
・先方のPIから「うちに来ない?」と連絡がきた
・以前も公募があったが学会で「アナログ回路の人が欲しいんだよね」と言われたので応募を止めた所だった
・任期付き助教?
・2018年の公募で事前にお断りされて,転職直後に応募してよと言われても….

2021/8 私立大
・教授,准教授,もしくはテニュア准教授,「若干名」
・分野は集積回路全般なので問題なさそう
・前回就活時,学会で「数年後公募あるから応募したら?」と情報をもらっていたので応募
・応募後2週間ほどでお祈りメール
・落ちた理由は業績が足りないとの事 (事後に指摘された)

2021/10 私立大
・講師(任期付),2年+1年x3のようだ.5年が上限
・分野は集積回路全般なので問題なさそう
・英語講義を6コマ担当するとのこと….研究できるのか?
・応募2週間後に面接,ボコボコにされる
・面接2週間後に内々定

2021/10 国立大
・准教授
・分野は集積回路全般,だけど本命は超伝導とか光コンピューティングみたい
・書類出そうと思っていたが,講師が先に決まってしまったので見送った

感想
・意外に教育歴は見られる?面接で「今大学で教えている科目の演習科目やってほしいな」と言われた
・でも「演習科目やってほしいな」は別の先生から「いらん」と言われるなど
・現在の担当科目名だけでなく内容も書いた方が面接の時の議論のネタになるからよいみたい
・JRecinの過去ログは消えるのでPDFは保存しておくべき
・(本公募ではなく)知り合いが受けた公募では,JRecinでは「再任あり」とあったが面接では「再任無し」になったケースがあったと聞いた,で蹴ったらしい
・上げるつもりはないので転職を考えておきなさいと言われています,厳しい(>_<),が業績ないもんな
・准教授ではなく講師(任期付)なのは察してください.着任してから理解したけれどほぼ助教だこれ…

過去の公募戦線ログ

2023年4月26日水曜日

ECS LIVAX2-120 に Linux Mint を入れてVNCサーバーにする

 ただの日記です.タイトル通り,ECS LIVAX2-120 に Linux Mint (XFCE) を入れてVNCサーバーにします.スペックは以下の通り.
・Celeron N3050(1.6GHz、ビデオ機能内蔵)
・DDR3L 4GB
・SSD 128GB
・HDMI 1.4a(30Hz 4K出力対応)、ミニD-Sub15ピン
・Gigabit Ethernet
・IEEE 802.11ac/a/b/g/n無線LAN、Bluetooth 4.0(ただし使えていない)
・USB 3.0×3

元々は Cent OS 7 でこれは後述するネットワークの問題はなかったのだが,Gnome があまりに重たすぎるので軽量めの Linux Mint に移行した.

Windows PC に VNC Viewer を入れて,ポートフォワードで Server に接続する.ネットワーク構成は以下のような感じ.

Windows PC (VNC Viewer)
↓ [ssh]
Linux Mint (VNC Server)
↓ [ssh -X]
計算機サーバー群

直接計算機サーバーに VNC を立ち上げないのは,サーバーにVNCのポートを開けるのが怖い事とサーバーごとに個別に VNC Server を立ち上げなくてすむ利点がある.

Linux Mint 21.1 をダウンロードし,Rufus でブート USB を作成.インストールは普通に実施する.VNC サーバーにするために SSH (oepnssl) と VNC (tigerVNC) をインストールするのだが, 大学のネットワークが複雑すぎてインターネットに到達できない.仕方なく Buffalo の USB WiFi ドングル (WI-U2-433DMS/N) をさして携帯テザリングしようと思ったのだが,ドライバがなくて WiFi が使えない.なので以下のサイトを参考に,Windows マシンで Github のドライバのデータをダウンロードして,Linux Mint 上でコンパイルした.
https://hirotaka-hachiya.hatenablog.com/entry/2020/12/14/184422

WiFi テザリングができるようになったら,SSH と VNC を「ソフトウエアの管理」からインストールする.アプリが入ればインターネットは不要なので, WiFi は消えてしまって構わない.

VNC Server を起動するも X が正常に立ち上がらない.~/.vnc/xstartup を以下のように編集して VNC を再起動する.

def 
export XKL_XMODMUP_DISABLE=1
unset SESSION_MANAGER
unset DBUS_SESSION_BUS_ADDRESS
/etc/X11/Xsession
/usr/bin/startxfce4 &
/usr/bin/xfce4-session &
/usr/bin/xfce4-pannel &
/usr/bin/xfce4-terminal &

VNC Server の起動はサービスに登録するのがスマートだろうが,過去の癖から手動で起動するようにしている.以下のエイリアスを作成している.Virtuoso を起動するため "-depth 24" で色解像度 24bit を指定する.
alias vncserver4k="vncserver -geometry 3800x2000 -depth 24"

すべての準備がすめば Windows PC で以下のバッチファイルを作成して,ポートフォワードと VNC Cliant を起動する.
start /b cmd /c "C:\PROGRA~1\PuTTY\putty.exe -load liva -l [userID] -pw [userPW]"
timeout 30
start /b cmd /c "C:\PROGRA~1\UVNCBV~1\UltraVNC\vncviewer.exe -connect 127.0.0.1::5901 -nocursorshape -notoolbar -noauto -password [userPW] -8greycolors"
timeout は SSH セッションが成立するのに時間がかかるが予測がつかないので少し長め,接続を確認したら手動でスペースを打って次に進めている.パスワード平文で保存しているのでセキュリティ的には危ないかもしれない.

Celeron N3050 は今となってはゴミかもしれないが,シンクライアント的に使うにはまあ十分かなぁ.4KのVNCもなんとか使えてる.ただしCADのログファイルがガンガン Terminal に出力されると途端にカクカクし始めるけれど...

2023年3月24日金曜日

THE RIGHT WORD fraction, fragment, part, piece, portion, section, segment

 よくわからなくなったので調べた.New Oxford American Dictionaly からです.

Fragment: 破損が発生したことを示唆し (fragments of pottery),多くの場合ガラスや陶器などの脆い物質を指す.
Segment: 全体が自然または既存の分割線に沿って分離されていることを示唆する (a segment of an orange). Section は,ある全体を形成するための,明確に分離された一方で他の部分と隣接する一部を示唆する (section of bookcase) .
Fraction: 通常、実質的ではないが明確に線引きされた部分を示唆する (a fraction of her income) .Portion は誰かに割り当てられた部分を示す (her portion of program) .
Piece: 全体から分離したどのような一部にも利用でき,最も良く使われる.

特に意図がなければ Piece を使えば良さそうだ.

2023年3月17日金曜日

近隣国の○○○○的組織

・Taiwan Semiconductor Research Institute (TSRI)
台湾の先生が使っているようだ.先生は「CICに質問しなさい」と学生に指導しているので,質問やサポートを受け付けてくれるのかな,うらやましい.

中身はよくわかっていませんが,台湾はクラウドでチップ試作できるのでしょうか.個々のラボで環境整備しなくて良いのでいいな.

どんなEDAがあってどうやって使うとか親切な説明があって涙がでます.参考にさせてもらおう.TSRI ってNational Chip Implementation Center (CIC) が元なのかな,
を選ぶとTSRIにリダイレクトされますね.

・IC Design Education Center (IDEC)
https://www.idec.or.kr
「韓国の半導体産業の競争力(한국 반도체산업의 경쟁력)」だそうです.EDAの一覧がカタログになってます.ちゃんとまとまっててめっちゃいい.
http://doc.idec.or.kr/eunjuseok/EDA_Tool_%EC%86%8C%EA%B0%9C%EC%9E%90%EB%A3%8C1.pdf

日本の先生も頑張って環境構築のドキュメント作成してくださっているけれど,こういう網羅的な資料があると「使ってみよう」って思う気がするんだけどな.(でも未だにINCISIVとか書いてあるし無理か...)

中国に同じような組織があるのかはわからなかった.留学生が言うには ASIC 向けの EDA を大学で使うのは難しく FPGA 実装が主流だそうだ.

2023年2月5日日曜日

LTSpiceでMOSFETの動作点を解析する

 LTSpice でも .op で MOSFET の動作点を表示できる.制御記述 .op のみを記述し( .tran は書かない),"Run" を押すとシミュレーションが走る.まず各ノードの電圧電流が表示がポップアップされるが閉じておく.次に "View" -> "SPICE Error log"を選択すると,MOSFET の動作点解析結果を見ることができる.

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 動かすためのシェアードファイル探すの大変だしな)