2024年9月12日木曜日

大学・高専機能強化支援事業

簡単に言うと,国の施策として大学の理工系の学生を増やす金銭的な支援をするよ,と言う話みたい,読売新聞の記事がまとまっていてわかりやすいと思う.


支援の内容は2種あって,支援1は学部再編等による特定専門人材への転換(公私立大学が対象),支援2は高度情報専門人材の確保に剥けた機能強化(国公私立大学・高専が対象)とのこと.支援1は学部再編とに必要な経費の補助に20年(x8年?),支援2は学部・研究科の定員増に伴う体制強化にと高専の学科コース新設拡充に必要な経費の補助に10億円(x10年?)支援されるそうだ(ハイレベル枠は20億円程度支援).

国立大学について絞ってみると,全国86校あるなか,2023年度選定で37校,2024年度選定で18校選ばれているらしい.半分以上ということか.

読売新聞の記事によると,東京23区の大学は学部増設の規制がかかっているらしくこの施策には応募できないとある,けれど東大とか東工大とか選定リストにあがっているのね.文系の定員を理系にスライドするのだろうか.

文科省の説明はこちら

・成長分野をけん引する大学・高専の機能強化に向けた基金による継続的支援について

・「大学・高専機能強化支援事業」の公募選定結果について(報道発表資料)

理系としてはありがたい話な気もするけれど,この施策で採用された教員は「どうせ彼・彼女は機能強化支援枠だし」と言われるのかも,と思うと悲しい….(悲しいけれど似たような話を聞いたことがあるので)
まあコレも一種の飴と鞭アファーマティブアクションってことか.

2024年7月31日水曜日

draw.io の PMOS シンボルを作る

draw.io を使おうと試行錯誤しているのだが,PMOS のシンボルが気に入らない.なのでテンプレートを元に編集して作ってみた. 
 

ついでに NMOS も.
 

ついでに,4端子版の PMOS と NMOS も作ってみた.
 
 

できあがりはこんな感じ.コピペして使います.


テンプレートそのものを編集できれば良いのだけれど.

参考:

2024年7月23日火曜日

IC5のライブラリ(CDB)をIC6に変換する

cdb2oa を使う事で,IC5 のライブラリ (CDB) を IC6 のライブラリ (OpenAccess) に変換できる.これは IC6 に入っているので,IC5 は必要ない.

・準備
IC6 の設計ディレクトリを IC5 とは別の設計ディレクトリを用意する.
IC5 の変換対象のライブラリと同名のライブラリを IC6 にも用意する.空っぽで OK.
IC5 の変換対象のライブラリのロックを解除しておくこと.cdb.lock を削除すればよい.
LIB1 が LIB2 のセルを利用している場合,LIB2,LIB1の順番に変換すること.
LIB1 が LIB3 のテクノロジファイルを Attach している場合,LIB3,LIB1の順番に変換すること.

・使い方
IC6 の設計ディレクトリに移動する.
% cd [IC6 dir]
cdb2oa を実行.
% cdb2oa -cdslibpath [path of IC51] -lib [lib name of IC51]

・参考

2024年7月18日木曜日

IC Compiler/ IC Compiler II でマクロの配線長を報告する

IC Compiler/IC Compiler II ではマクロ中の配線長を報告する事が出来る.報告の方法もいくつか段階がある.

(1) マクロ内の総配線長を知りたい場合 (統計値)
IC Compiler    : report_qor
IC Compiler II : report_qor

(2) マクロ内の各配線層ごとの配線長を知りたい場合(統計値)
IC Compiler      : report_design -physical
IC Compiler II  : report_design -routing

(3) 特定の配線の配線長を知りたい場合
IC Compiler    : report_net_physical [net_name]
IC Compiler II : report_nets -physical [net_name]

なんだか微妙にコマンドやオプションが変わっているけれど,報告内容そのものは同じのよう.

2024年7月4日木曜日

Let's Note CF-FV1の電力制御

Let's Note は「PC設定ユーティリティ」でファンの速度を変更できるのだが,CPU をぶん回す意図で「高速」設定にしていたのだけれど,これは間違いだったという小話.
PC:CF-FV1,Core i7-1165G7 4-core 8-thread,LPDDR4X-4266 16GB,CT100P1 (爆熱SSD)
負荷:ngspice 8 並列

観察していると以下のような感じだった.計測は OCCT を目視です.
・標準:最初10秒ほど28W,4GHz,1分ほどは25W,3.9GHz ぐらいで動作し,それから20W,3GHz ぐらいで継続して動作.温度は70度~80度,ファン爆速
・高速:17W,2.8GHz ぐらいで動作.温度は60度,ファン爆速
・低速:17W,2.6GHz ぐらいで動作.温度は65度,ファン低速

ファン高速モードは,CPU高速動作モードではなくて,CPUいたわりモードなのであった.標準にしておけということだな.

OCCT には以下の情報が記載されていた.
CPU TDP: 28.0W
CPU Power Limit 1 (Long Duration) : (21.00W)(28.00sec)
CPU Power Limit 2 (Short Duration) : (60.00W)(2.44msec)

TDP,TDPって一体何なんだ.

2024年6月14日金曜日

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 で表示できてびっくり.

2024年6月11日火曜日

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 が良いのかなと思っていたけれど,そうとは限らないというのが意外であった.あとトレッキーだな.

2024年6月3日月曜日

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

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

オチ:
 

やった手順.ボスに絵日記と言われるやつ.
Gnuplot を SourceForge からダウンロードして解凍
https://sourceforge.net/projects/gnuplot/files/gnuplot/

 
このまま Make すると
 
で死ぬ../configure --with-qt=qt5してみたけれど単体では効果無し(そりゃそうだ)

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

したら Make は通るけれど Make Installでだめ
 
調べたら,QT5のバージョン依存なので以下を入れろというアドバイスがあった.
qttools5-dev-tools libdtkwidget-dev libdtkwm-dev pkg-config

実際には qttools5-dev-tools だけ入れたら動いた.
 
libdtkwidget-dev libdtkwm-dev は apt に無かった.pkg-config は入れなくても通った.


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

だめだったアドバイス.
https://sourceforge.net/p/gnuplot/bugs/2591/
 
https://groups.google.com/g/comp.graphics.apps.gnuplot/c/1etT8-2x8cg
 

2024年5月23日木曜日

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

忘れるのでメモ.

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

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

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

Intel 第13世代,14世代CPU (Raptor Lake系)の動作の不具合(24/05/22追記)
最近(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つのシナリオを挙げている.マイクロコードのアップデートで(これ以上の劣化は)回避できるとのこと.

・ソフトエラー関係
日本語の記事はこちらが詳しい
ECC によって保護されていないため宇宙線による誤動作が多発し,その部分を無効化して性能を猛烈に悪化させつつ使うか,そもそもまともに長時間動かせなくて諦めた,というお話である.

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

・パッケージ関係
富士通の HDD コントローラ突然死
富士通の 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]あります.

2024年5月14日火曜日

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

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

dc_shell> compile_ultra -no_autoungroup
dc_shell> report_area -hierarchy

 

同じように,電力も階層ごとに見ることが出来ます.
dc_shell> report_power -hierarchy


compile_ultra はデフォルトで階層を展開するので,
dc_shell> compile -ungroup_all
dc_shellcompile_ultra
compile コマンドと compiler_ultra コマンドを併用する必要は無いようだ.DesignCompiler R-2020.09-SP4 でのお話です.