FreePDK3を見てみる

FreePDK3 の存在を教えてもらったので見てみた．GitHubにあります．

特徴

• NanoSheet FET
• 埋め込み電源層(BPR)

断面の模式図．図はSynopsysから．

デザインルールで気がついたこと

• Middle on Line (MOL)では，M0A，V0A，GCON，M0B，V0B があり，M0A で Active につなぐ．M0A は V0A で M0B につなぐ．GATE は GCON で M0B につなぐ．GCON と V0A は同じ VIA 層なのでスペースが必要．M0B は V0B で M1 につなぐ．
• Active (Diffusion というか NanoWire というか)は連続でないといけないみたい．プレーナーみたいなパストラは作れない？
• いわゆる Single Diffusion Break みたい．Break していないけれど．

提供されているもの

• 回路シミュレーション (HSPICE)
• DRC/LVS (IC Validator)
• RC抽出 (Star-RC)
• レイアウト設計 (CustomCompiler)
• いくつかのセルレイアウト
• デザインルールマニュアル

CustomCompilerのテクノロジライブラリは以下にある．

$PDK_ROOT/syncust/NSCU_TechLib_FreePDK3

セルライブラリは以下にある．

$PDK_ROOT/examples/FreePDK3_examples

Inverter，NAND2，NOR2，AND2，OR2，XOR(Single-Row，Multi-Row)，Latch，D-FFセルが用意されている．

D-FF のレイアウト(イオンインプラントを除く)．2-Row セルなのね．SR-Latch を呼び出して D-FF を作っているので，あまり効率が良くないような．これ並べておいたら DRC 違反出るんじゃない．そもそもGate (縦の赤いレイヤー)が密かつ規則的に配置されていないのだけれど，そんなデザインルールでいいのだろうか．

修士の学生が作ったらしいが，正直テクノロジファイルを作成するだけで精一杯だったと書いていた．そりゃそうかもしれん．BPR も Star-RC でどうモデル化したらいいかわからないと言っているし，パラメータの妥当性もよくわからないし，研究に使うには危ないかも知れない．修論はこちら．

CustomCompiler，Milkyway DB ではなくて OpenAccess を使っているのね．.cds.init，.cds.env を移植したら Virtuoso で表示できてびっくり．

Resistance is Futile! Building Better Wireload Models を読む

 
論理合成で配線負荷を見積もる Wire-load Model を理解するために論文をサクッと読んでみた．
Steve Golson, "Resistance is Futile! Building Better Wireload Models", SNUG, 1999

Wire-load Model の基本

Wire-load Model は実際のレイアウト情報を使う事無く，配線の特徴(配線遅延)を予測する物である．配線とそれに接続されるファンアウトから，Wire-load モデルによって負荷容量，負荷抵抗，配線の面積を予測する．ライブラリによって設計される回路の統計的情報から，Wire-load モデルは作られる．回路の配線とその負荷容量をヒストグラムにできる．得られたヒストグラムのうち，度数の90%以下を10分割して Index を作成する事で非常に保守的な Wire-load モデルを作成できる．同じ方法で抵抗および面積のWire-loadモデルを作成できる．

一般にベンダーは面積条件に応じて複数の Wire-load モデルを提供している( Area-Based Wireload Selection )．

Wire-loadモデルの「神話(根拠の薄い社会通念)」

神話1：配置配線される回路の面積レポートを元に，Wire-loadモデルを選ぶこと

これは絶対的な教義であるが，実はフロアプランがなくてもおおよそ妥当な配線負荷を Wire-load モデルは提供できる．回路が大きかろうが小さかろうが論理的に隣接するセルは近傍に置かれる事が期待されるためである．
もちろん大きいブロックは長距離配線があるのでその部分は見積もりが悲観的にはなりやすい．

神話2：ある面積条件に対して一つのWire-loadモデルで十分である

十分ではない．同じ面積であっても，回路の条件によって異なる配線負荷となりうる．一方で「単一の Wire-load モデル」で十分との報告もある．

神話3：配線抵抗はゼロにすべき

誤っている．これは配線遅延をゼロにする事に相当する．ワイヤ容量だけでも配線遅延と電力見積もりには貢献しているが．

神話4：配線面積をゼロにすべき

実際には配線は面積を要求する．面積の情報を提供できると，DesignCompiler は配線面積を考慮しながらゲートレベルの最適化を実現する．

神話5：ベンダーの提供するWire-loadモデルを常に信用すべき

そうとは限らない．仮にベンダーの Wire-load モデルがあっても，以下の条件では精度が落ちうる．

• 設計対象がベンダーの Wire-load モデルより大きい
• ネットリストの条件が異なる(配線が多い，混雑している，IOが多い)
• アスペクト比が異なる
• 設計フローが異なる．

ベンダーによっては Wire-load モデルに求める精度が異なる事も考慮すべき．

神話6：カスタムしたWire-loadモデルが常によい

これは Design-Specific Wire Model と呼ばれており，最初に配置配線を試し，そこから得られた配線の統計情報からその回路専用の Wire-load モデル を構築するものである．神話1と同様に広まっているが，同時に疑わしいらしい．

例えば以下の条件によって精度が落ちうる．

• ベンダーが用意した大量の回路から得た統計的モデルに対し，本モデルは限られたサンプルから生成される．
• 設計初期の Netlist から Wire-load モデルは作成されるが，それは設計後期の条件とは異なる．
• モデル生成ツールが設計者が想定していないモデルを利用する可能性がある．
• 各インスタンスが独自の Wire-load モデルを取得するようにフローを一意にする必要があるかもしれない(マクロごとにWire-load モデルを使い分けないといけないということ？)

神話7：Wire-loadモデルは配線後の統計と一致していないといけない

これは神話6の背景にあるものだが間違っており，一致する必要は無い．Wire-load モデルの目的は形状(配線長)の予測ではなく，配線時のタイミングを予測する事が目的である．

論文は Wire-load モデルと実際の設計の相関の解析などを紹介しているけれど，そこは省略． Design-Specific Wire Model が良いのかなと思っていたけれど，そうとは限らないというのが意外であった．あとトレッキーだな．

Linux Mint 21.2 に Gnuplot をソースから入れる

Tgif でグラフをお絵かきする古い人間なので， Linux Mint 21.2 に Gnuplot をソースから入れます．CentOS の時より変に苦労した．

オチ：

$ sudo apt install qttools5-dev-tools qtbase5-dev $ tar zxvf gnuplot-6.0.1.tar.gz $ cd gnuplot-5.4.1 $ ./configure -with-tgif -with-qt=qt5 $ make $ sudo make install  

やった手順．ボスに絵日記と言われるやつ．

Gnuplot を SourceForge からダウンロードして解凍

https://sourceforge.net/projects/gnuplot/files/gnuplot/

$ tar zxvf gnuplot-6.0.1.tar.gz $ cd gnuplot-6.0.1 $ ./configure -with-tgif .... No package 'Qt5Core' found No package 'Qt5Gui' found No package 'Qt5Network' found Package 'Qt5Core', required by 'Qt5Svg', not found ... $  

このまま Make すると

$ make ... qtterminal/qt_term.cpp:51:10: fatal error: QtCore: そのようなファイルやディレクトリはありません 51 | #include <QtCore>  

で死ぬ．./configure --with-qt=qt5してみたけれど単体では効果無し(そりゃそうだ)

qtbase5-dev を入れるといいらしい．

https://qiita.com/tom_tom_tom/items/e16618aa5040998252a3

$ sudo apt install qtbase5-dev  

したら Make は通るけれど Make Installでだめ

$ make clean ... $ ./configure -with-tgif -with-qt=qt5 ... $ make ... $ make install ... /bin/bash: 行 1: /usr/lib/x86_64-linux-gnu/qt5/bin/lrelease: そのようなファイルやディレクトリはありません make[3]: *** [Makefile:1575: qtgnuplot_fr.qm] エラー 127  

調べたら，QT5のバージョン依存なので以下を入れろというアドバイスがあった．

qttools5-dev-tools libdtkwidget-dev libdtkwm-dev pkg-config

https://github.com/linuxdeepin/deepin-system-monitor/issues/22

実際には qttools5-dev-tools だけ入れたら動いた．

$ sudo apt install qttools5-dev-tools  

libdtkwidget-dev libdtkwm-dev は apt に無かった．pkg-config は入れなくても通った．

GUI が QT になったのかね．ソースから入れると /usr/local/bin に入るのね．

だめだったアドバイス．

https://sourceforge.net/p/gnuplot/bugs/2591/

$ ./configure --with-qt=qt5 $ make  

https://groups.google.com/g/comp.graphics.apps.gnuplot/c/1etT8-2x8cg

$ sudo apt install libqt5svg5-dev  

集積回路における信頼性問題の具体例

忘れるのでメモ．

・ハードエラー関係

Intel のチップセットのSATAコントローラの動作が徐々に基準を満たさなくなると言う話．確かポート1，2だけは大丈夫で，ポート1，2だけ使う製品(ノートPCとか)は出荷を継続して，デスクトップPCのマザーはリコールして大量廃棄したという話．

Intel、新チップセット「Intel 6シリーズ」で不具合、一部店舗で対応製品の販売停止も

Intel Sandy Bridge chipset flaw prompts recall

ルーターなど組み込みで使われている Atom C2000 が長期起動するとクロックが出なくなって止まるという話．

Atom C2000ファミリに18カ月前後の動作で起動できなくなるエラッタ

Semi-Critical Intel Atom C2000 SoC Flaw Discovered, Hardware Fix Required

Apollo Lakeが長期稼働で信号劣化し品質基準を満たさず。ステッピング変更へ

ソースが無いが，2件ともコアトランジスタに IO 電源をつないでしまったための HCI での劣化が原因と言われていた気がする．

Intel 第13世代，14世代CPU (Raptor Lake系)の動作の不具合(24/05/22追記)

Intel 第13と第14世代のハイエンドCPU中心に不安定になる不具合多発。高クロックによりCPUが劣化？

最近(2024年)の Intel CPU 向けの自作 PC 向けマザーボードは電力制限がかなり緩くて CPUの消費電力がかなり高設定( PL1 や PL2 が 253W だったり，無制限になったり)なのだが，そのせいで CPU 自体に不可逆的な劣化が発生してしまうとのこと．Intel は Intel Baseline Profile というのを提供し，これを満たす BIOS を入れると PL1 が 125W，PL2 が 188W などに制限されるらしい．もちろん性能も落ちる．

電圧が原因であれば NBTI，電力や発熱が原因であれば HCI であろうか．

24/10/26追記

Intel によると，想定以上の高温高電圧環境での使用により，クロックツリーのトランジスタが劣化し，その結果クロックのデューティー比が不適切となりシステムの動作が不安定になったとのこと．BIOSの制御が不適切とか，プロセッサの電源管理アルゴリズムが不適切とか，4つのシナリオを挙げている．マイクロコードのアップデートで(これ以上の劣化は)回避できるとのこと．

・ソフトエラー関係

HOW TO KILL A SUPERCOMPUTER: DIRTY POWER, COSMIC RAYS, AND BAD SOLDER

日本語の記事はこちらが詳しい

スーパーコンピューターの系譜　Chen博士がCRAYの後に手がけたSS-1

ECC によって保護されていないため宇宙線による誤動作が多発し，その部分を無効化して性能を猛烈に悪化させつつ使うか，そもそもまともに長時間動かせなくて諦めた，というお話である．

Intel reveals Itanium 2 glitch (23/11/07追記)

「高温下において特定のデータを特定の順番で処理を実施した」時に，システムが不正にシャットダウンし保存データに異常が発生するとのこと．対策として周波数を800MHzまで落とすか，マザーボードを作り替えるか，CPUを入れ替えるらしい．結局何が原因なのかはわからなかったが，状況から考えるとIR-Dropかdi/dtノイズだろうか．

・パッケージ関係

富士通の HDD コントローラ突然死

富士通ハード・ディスク・ドライブ不良問題

富士通がHDD不具合問題でCirrus社などと和解，154億円の特別利益を計上

富士通の HDD に積んだ Cirrus Logic 製のコントローラ LSI がパッケージに起因する経年劣化で死亡するという話．日経では「富士通が製造を委託した」とあるが，がっつり Cirrus Logic のロゴが入っているし LSI チップを買ったようだ．パッケージ材料である住友ベークライトの「EME-U」に含まれる無機リンを構成する赤リンおよびその皮膜が高温高湿下でリン酸になり，それがピンの材料である Ag を溶かし配線を短絡した．

パッケージ起因のソフトエラー

[1] T. C. May and M. H. Woods, “Alpha-Particle-Induced Soft Errors in Dynamic Memories,” IEEE Trans. Electron Devices, vol. 26, no. 1, pp. 2–9, 1979, doi: 10.1109/T-ED.1979.19370.

パッケージに含まれる残留放射性元素がアルファ崩壊したときに放射されるアルファ線が集積回路に突入して生じるソフトエラー．不具合として「システムノイズ」「最低動作電圧」「センスアンプ」「特定パターン依存」など候補があったが，この論文によって放射性粒子起因の誤動作というのが新しい候補になった(?)．「ソフトエラー」という一過性の故障や「クリティカルチャージ」という集積回路が"0"，"1"を反転するのに必要な電荷量の差などが定義された論文みたい．

・コンデンサ関係 (23/02/11追記)

第四級アンモニウム塩を利用したコンデンサが液漏れを起こし電解液が基盤や基板上の部品を腐食させる事故が一時期多発していた．Wikipediaの記事にもなっている．

NEC Tokin のプロートライザが使用中に劣化するらしく，デカップリング容量として採用したノートパソコンの死亡例が一時期よく観察された．腕に自信のある人はプロートライザを剥がしてタンタルコンデンサに入れ替えるらしいが．．．

タンタルコンデンサは小さい逆電圧でも電流が流れる上，短絡モードで故障するので，使い方にはかなり気をつけないといけない．交流や電源電圧・電流がグラグラ動く箇所のデカップリングコンデンサとして使うと壊れる可能性があります．テクトロはタンタルコンデンサが好きなのか，燃えて壊れた報告がいくつか[1][2]あります．

DesignCompilerでモジュールごとの面積内訳を見る

 DesignCompiler でモジュールごとの面積内訳を見たい場合，階層構造の展開をやめた上で，report_area に -hierarchy オプションを付ける．compile_ultra はデフォルトで階層を展開して論理と回路を最適化してしまうので，-no_autoungroup オプションを付ける．

dc_shell> compile_ultra -no_autoungroup

dc_shell> report_area -hierarchy

design_vision> report_area -hierarchy **************************************** Report : area Design : cpu_top_wo_mem Version: R-2020.09-SP4 Date : Tue May 14 10:42:04 2024 **************************************** Information: Updating design information... (UID-85) Warning: Design 'cpu_top_wo_mem' contains 1 high-fanout nets. A fanout number of 1000 will be used for delay calculations involving these nets. (TIM-134) Library(s) Used: mrow_0p7 (File: /home/xxx/mrow_0p7.db) Number of ports: 579 Number of nets: 17670 Number of cells: 17221 Number of combinational cells: 15986 Number of sequential cells: 1226 Number of macros/black boxes: 0 Number of buf/inv: 3293 Number of references: 22 Combinational area: 8079.139917 Buf/Inv area: 2618.919946 Noncombinational area: 539.439997 Macro/Black Box area: 0.000000 Net Interconnect area: undefined (Wire load has zero net area) Total cell area: 8618.579914 Total area: undefined Hierarchical area distribution ------------------------------ Global cell area Local cell area ------------------ ---------------------------- Hierarchical cell Absolute Percent Combi- Noncombi- Black- Total Total national national boxes Design -------------------------------- --------- ------- --------- --------- ------ ---------------- cpu_top_wo_mem 8618.5799 100.0 1204.0700 47.0800 0.0000 cpu_top_wo_mem alu_0 1550.5800 18.0 1550.5800 0.0000 0.0000 alu decoder_0 91.5500 1.1 91.5500 0.0000 0.0000 decoder gpi_0 3.5200 0.0 1.7600 1.7600 0.0000 gpi gpo_0 8.3600 0.1 6.6000 1.7600 0.0000 gpo hardware_counter_0 142.5900 1.7 128.5100 14.0800 0.0000 hardware_counter regfile_0 4915.3600 57.0 4478.8800 436.4800 0.0000 regfile uart_0 307.0500 3.6 290.7700 16.2800 0.0000 uart uart_rx_0 348.4200 4.0 326.4200 22.0000 0.0000 uart_rx -------------------------------- --------- ------- --------- --------- ------ ---------------- Total 8079.1399 539.4400 0.0000 1  

同じように，電力も階層ごとに見ることが出来ます．

dc_shell> report_power -hierarchy

design_vision> report_power -hierarchy **************************************** Report : power -hier -analysis_effort low Design : cpu_top_wo_mem Version: R-2020.09-SP4 Date : Tue May 14 10:43:05 2024 **************************************** Library(s) Used: mrow_0p7 (File: /home/xxx/mrow_0p7.db) Operating Conditions: mrow_0p7 Library: mrow_0p7 Wire Load Model Mode: top Design Wire Load Model Library ------------------------------------------------ cpu_top_wo_mem wl1 mrow_0p7 Global Operating Voltage = 0.7 Power-specific unit information : Voltage Units = 1V Capacitance Units = 1.000000pf Time Units = 1ps Dynamic Power Units = 1 W (derived from V,C,T units) Leakage Power Units = 1pW -------------------------------------------------------------------------------- Switch Int Leak Total Hierarchy Power Power Power Power % -------------------------------------------------------------------------------- cpu_top_wo_mem 90.595 N/A 3.24e+06 N/A N/A hardware_counter_0 (hardware_counter) 12.242 N/A 3.04e+04 N/A N/A gpo_0 (gpo) 0.789 N/A 5.75e+03 N/A N/A gpi_0 (gpi) 0.000 5.31e-04 1.56e+03 5.31e-04 N/A uart_rx_0 (uart_rx) 0.293 N/A 8.16e+04 N/A N/A uart_0 (uart) 12.376 N/A 6.87e+04 N/A N/A alu_0 (alu) 0.000 0.000 6.24e+05 6.24e-07 N/A regfile_0 (regfile) 2.594 N/A 1.85e+06 N/A N/A decoder_0 (decoder) 41.427 N/A 2.64e+04 N/A N/A 1

compile_ultra はデフォルトで階層を展開するので，

dc_shell> compile -ungroup_all

dc_shell> compile_ultra

と compile コマンドと compiler_ultra コマンドを併用する必要は無いようだ．DesignCompiler R-2020.09-SP4 でのお話です．

論文誌の投稿スケジュール感覚(2023)

 Publish or Perish，悲しいことに論文誌を書かなければこの業界では生き残っていけない．日本の集積回路業界で標準的な(?)，電子情報通信学会 (IEICE) と情報処理学会 (IPSJ) の論文誌の特集号のスケージュルをまとめてみる．ボス曰く，IEICEについては，一般号でもあまり時間の感覚は変わらないとのこと．(英文論文誌によっては査読は2回戦までしかないらしい)

12月には判定が出てないとD論に間に合わないのですけど(>_<)，という心理をよく突いた？スケジュール感になっています．

・IEICE CAD特集号

3月中旬：投稿締め切り (3月上旬に設定された投稿締め切りは，2017年度以降毎年にわたり1週間延長されているようだ)

3月下旬：査読者割り当て

4月中旬：査読報告

5月中旬：判定報告

7月中旬：第二次投稿締め切り

8月中旬：査読報告

8月下旬：判定報告

12月　 ：早期公開

3月上旬：Preprint PDF発行

・T-SLDM

6月上旬：投稿締め切り

7月中旬：査読報告

8月上旬：判定報告

9月上旬：第二次投稿締め切り

10月上旬：査読報告

10月下旬：最終判定

11月下旬：最終原稿投稿

12月上旬：発行

・IEICE 集積回路小特集

7月中旬：投稿締め切り

7月下旬：査読者割り当て

8月中旬：査読報告

9月中旬：判定報告

10月中旬：第二次投稿締め切り

12月中旬：査読報告

12月下旬：判定報告

4月　　：早期公開 (?)

7月上旬：Preprint PDF発行(?)

・T-SLDM

10月上旬：投稿締め切り

10月中旬：査読者割り当て

11月中旬：査読報告

12月上旬：判定報告

1月上旬：第二次投稿締め切り

2月上旬：査読報告

2月下旬：最終判定

3月下旬：最終原稿

6月上旬：発行

Listings の使用をやめて Algorithmicx を使う

Listingsのキャプションがいまいちすぎる．情報系では Algorithmicx を使うらしいので導入してみる．

tlmgrでインストールしよう

% sudo tlmgr install algorithmicx

とするもてめえの TexLive は 2019 で，最新の 2023 より古いから入らんよと言われてしまう．(ログは忘れた)

apt update して再度インストールを試みるも 2019 が再度インストールされてしまう．．．(LinuxMint 21.2です)

% sudo apt remove texlive-full

% sudo apt remove texlive-base

% apt update

(再起動)

% sudo apt install texlive-full

(2019をインストールしてしまう)

仕方ないので install-tl を使ってインストールすることに．texjpの指示通りです．

https://texwiki.texjp.org/?Linux#texliveinstall

ただリポジトリを指定するとうまくいかなかったので指定しなかった．

% wget http://mirror.ctan.org/systems/texlive/tlnet/install-tl-unx.tar.gz

% tar xvf install-tl-unx.tar.gz

% cd install-tl-2*

%  sudo ./install-tl -no-gui 

...

Actions:

 <I> start installation to hard disk

 <H> help

 <Q> quit

Enter command: I

(延々ダウンロード)

% sudo /usr/local/texlive/2023/bin/x86_64-linux/tlmgr path add

念のためアップデートしてみた．なぜかいくつかアップデートが走った．

% sudo tlmgr update --self --all

tlmgr: package repository https://ftp.yz.yamagata-u.ac.jp/pub/CTAN/systems/texlive/tlnet (verified)

tlmgr: saving backups to /usr/local/texlive/2023/tlpkg/backups

tlmgr: no self-updates for tlmgr available

[ 1/12, ??:??/??:??] update: acmart [4890k] (68950 -> 69242) ... done

...

[12/12, 00:15/00:15] update: versonotes [133k] (55777 -> 69249) ... done

running mktexlsr ...

done running mktexlsr.

running updmap-sys ...

done running updmap-sys.

tlmgr: package log updated: /usr/local/texlive/2023/texmf-var/web2c/tlmgr.log

tlmgr: command log updated: /usr/local/texlive/2023/texmf-var/web2c/tlmgr-commands.log

念のため既存の tex をコンパイルしてちゃんと動くか確認．

% cd ~/(適当なTexディレクトリ)

% make

本番の tex 環境に戻り，コンパイルしてみる．

参考にしたサイトだと tlmgr で以下のようにパッケージをインストールせよとあったけれど，うちの環境では不要のようだった．．

% sudo tlmgr install algorithmicx

% sudo tlmgr install algorithms

Listings では HTML の plane タグの様に特殊文字のエスケープなどは必要なかったのだけれど， alrogithmic の環境だと

通常の Latex の環境同様エスケープや改行などは必要みたい．あと文中に日本語があるとコンパイル時に

! Not two-byte family.

と警告が出て止まってしまう．まあでも日本語でアルゴリズム書くこと無いからいいか．

Algorithmicx の参考に下サイト：

https://li-feel.hatenablog.com/entry/2017/12/19/160618

https://github.com/PMOB/study-tex/wiki/reference-algorithm

IEICEのクラスファイル を TeXLive 2023で動かすようにする

環境は Linux Mint 21.2です．クラスファイルは ieice2.2 です．(2015年)

普通にコンパイルすると

! Undefined control sequence. \set@color -> ;\pdfcolorstack; \@pdfcolorstack push{\current@color }\aftergroup... .

で止まる．

\usepackage{graphicx,xcolor}% for pdflatex

を

\usepackage[dvipdfmx]{graphicx,xcolor}

に変える．

これまで Bibtex では ieicetr.bst と reference.bib をワーキングディレクトリに置いて

\bibliographystyle{ieicetr}

\bibliography{reference}

という記述を使っていたのだが，TexLiveをアップデートしてから

This is BibTeX, Version 0.99d (TeX Live 2022/dev/Debian) The top-level auxiliary file: IEICE_CAD.aux I couldn't open style file ieeetran.bst ---line 26 of file IEICE_CAD.aux : \bibstyle{ieicebst : } I'm skipping whatever remains of this command I couldn't open database file reference.bib ---line 27 of file IEICE_CAD.aux : \bibdata{reference : } I'm skipping whatever remains of this command I found no database files---while reading file IEICE_CAD.aux I found no style file---while reading file IEICE_CAD.aux (There were 4 error messages)

というエラーが出るようになった(TexLive 2023 なのになんで 2022 なん？)．それどころか TexLive デフォルトでインストールされる IEEEtran もエラーになるように．bst ファイルのデフォルトの保存ディレクトリにある bst ファイルも，カレントディレクトリにある bst ファイル，bib ファイルも読めない．これらはカレントディレクトリに置けばいいって奥村先生も言っているのになぜ．

悩んでいたのだが，以下のサイトからパスをちゃんと書かないといけないらしいという情報を見つけた．

Bibtex Error: Can’t Open Style file IEEEtran.bst

ほんとうかいな．カレントディレクトリに置いたファイルは"./"をつけよう．

\bibliographystyle{./ieicetr}

\bibliography{./reference}

デフォルトでインストールされる BST ファイルについては， BSTINPUTS が

% echo $BSTINPUTS 

/usr/local/texlive/2023/texmf-dist/bibtex/bst/

を指していて IEEEtran は

% ls /usr/local/texlive/2023/texmf-dist/bibtex/bst/IEEEtran/IEEEtran.bst

にあるので，以下のように書き換えれば良いらしい．\bibliographystyle{IEEEtrran/IEEEtran}

\bibliographystyle{ieeetrran/IEEEtran}

上記の様にコードを変更したらどちらも動いた．良かったけれど動き方がなんか想定と違う気が．．．

念のため，.zshrc にBSTINPUTSも設定しておこう．

% export BSTINPUTS=/usr/local/texlive/2023/texmf-dist/bibtex/bst/

24/02/15 訂正

bibliographystyle のディレクトリ名 IEEETran はieeetran とすべて小文字でした．

PDFへのフォントの埋め込み TexLive 2023版

PDFへのフォントの埋め込みをしないと IEEE PDF eXpres が文句を言うので埋め込む．

初手でいきなり気持ち悪い事をするのだが，GhostScriptの設定を変更する．設定ファイルは以下にあるようだ．(いくつかのWebサイトでは [ver]/lib の下と書いているが，そうでは無いらしい)

/usr/share/ghostscript/9.55.0/Resource/Init/gs_pdfwr.ps

.standardfonts で指定している基本フォントをすべてコメントアウトしてしまう．

/.standardfonts [ % /Courier /Courier-Bold /Courier-Oblique /Courier-BoldOblique % /Helvetica /Helvetica-Bold /Helvetica-Oblique /Helvetica-BoldOblique % /Times-Roman /Times-Bold /Times-Italic /Times-BoldItalic % /Symbol /ZapfDingbats ] readonly def

マップするフォントを指定するファイルを作成する．

echo "rml H :0:ipam.ttf" > textfont.map echo "gbm H :0:ipag.ttf" >> textfont.map echo "rmlv V :0:ipam.ttf" >> textfont.map echo "gbmv V :0:ipag.ttf" >> textfont.map

-f オプションをつけてコンパイル

dvipdfmx -f textfonts.map main.dvi

確認

% pdffonts main.pdf name type encoding emb sub uni object ID ------------------------------------ ----------------- ---------------- --- --- --- --------- BFXFUH+NimbusRomNo9L-Regu Type 1C Custom yes yes yes 4 0 TLDEQQ+CMSY8 Type 1C Builtin yes yes yes 5 0 AKQSYA+NimbusRomNo9L-ReguItal Type 1C Custom yes yes yes 6 0 NIKTLI+NimbusRomNo9L-MediItal Type 1C Custom yes yes yes 7 0 YLFCCB+NimbusRomNo9L-Medi Type 1C Custom yes yes yes 8 0 BWTDFP+Helvetica Type 1C WinAnsi yes yes no 10 0 XBVXSN+CMMI10 Type 1C Builtin yes yes yes 18 0 XYEUNM+CMR10 Type 1C Builtin yes yes yes 19 0 TSPOJC+CMSY10 Type 1C Builtin yes yes yes 20 0 VKZLRK+CMSY9 Type 1C Builtin yes yes yes 21 0 NLQACA+CMMI9 Type 1C Builtin yes yes yes 22 0 ACXUUK+Helvetica Type 1C WinAnsi yes yes no 27 0 BHRAOW+Helvetica Type 1C WinAnsi yes yes no 32 0 YZDJWY+CMMI8 Type 1C Builtin yes yes yes 39 0 %

全部 emb が yes になっているからOK．

環境構築すると GS の設定を変更するのすぐに忘れちゃうんだよな．

HSPICE で過渡解析の結果として初期値のみが表示される

HSPICEで過渡解析を行ったときに，初期値(時間0点)のみ表示されて波形が表示されないことがある．

これは autostop を使っている状態で .Measure の条件を満たす波形入力が存在しないことが自明な場合(例えばトリガ条件の信号が存在しないなど)に過渡解析を実施せずに終了してしまう様だ．ややこしいのは最後のログが "*** job concluded" と表示される事だけれど，実際には初期条件の評価しかしていない．

例えばこんなSPICE CARDを入力すると．

... * Prop. delay .Measure Tran Prop_dut Trig v(W5_10) Val='VOLT/2' rise=1 targ v(W6_01) val='VOLT/2' fall=1 print=0 .Measure Tran Prop_ref Trig v(W5_10) Val='VOLT/2' rise=1 targ v(W6_10) val='VOLT/2' fall=1 print=0 V_D01 DATA01 0 pwl (40p 0 100p 0 '100p + SLEW' 'VOLT' ) .subckt INV4 IN OUT VDD VSS XINV1 IN OUT VDD VSS VDD VSS INV_X1 XINV2 IN W1 VDD VSS VDD VSS INV_X1 XINV3 IN W2 VDD VSS VDD VSS INV_X1 XINV4 IN W3 VDD VSS VDD VSS INV_X1 .ends ...

.Measureの条件である W6_01，W6_02 は存在しないのでこの .Measure は無視される．

結局生成された波形ファイル (.tr0) を見ても，時間ゼロでの初期値(ここでは0.7 V)が点で表示されるだけである． ちゃんとログを見ると，

**warning** (delay_wring.sp:32) Unable to find referenced node w5_10; Output variable ignored. Specify a valid node.

という感じに存在しないネットについてはワーニングがでているので，まあちゃんと確認しなさいということか． 

昔の HSPICE はこんな振る舞いだったかな，とはちょっと疑問ではある．ここでは P-2019.06-1 を使っている．