2024年11月24日日曜日

IEEEの著作物を自分の論文に引用する

 IEEEの著作物,例えばIEEEに著作権譲渡した自分の国際会議論文を他の出版社の論文誌に引用する場合,IEEEに申請しないといけない.またその旨を著作物に明示しなければいけない.


・引用許可の申請
その場合,IEEE Xploreから申請が出来る.当該論文のページを開き,(c) マークの"Request permission for reuse"を選択する.


目的を入力する.論文誌への再利用であれば,"reuse in a journal/magazine"を選べば良い.出版予定の論文のタイトル,出版社,予定出版日などを入力する.自分の著作物を学位論文に引用するのであれば,"reuse in thesis/dissertation"を選ぶ.この場合申請は不要でお値段はタダらしい.

しばらくするとIEEE RightsLinkからメールが来るので,"Choose Payment"から支払えば良い.

1週間程度で最終的に支払のメールがやってくる.私の場合,4ページものの自分の文献の図表を引用するだけで4万2千円だって.
コ レ ハ ヒ ド イ ….


・引用ルール
本文を部分的に引用する場合:元の公開記事の全引用に続いて IEEE 著作権表示を記載する: © 20XX IEEE
図表の引用: IEEE 著作権表示 (© 20XX IEEE)を各図表に記載する
全文記事の引用:文献リストの当該文献に次のように記入 “© 20XX IEEE. Reprinted, with permission, from [full citation of original published article].”

・参考
Avoid Infringement Upon IEEE Copyright


2024年9月15日日曜日

大学・高専機能強化支援事業と教員の任期

 大学・高専機能強化支援事業は8年から10年の時限付きの事業.文系学生の定員を理系に転換する事から,事業の期間に文系教員のポストを理系教員に転換する事が想定される.一方で大学によっては支援事業が終わったら理系教員をサヨナラしてしまう大学もあるかもしれない.

JREC-INで"機能強化支援事業"で検索すると,現地点は12大学・高専にて公募があった.教員の任期を調べてみると以下の様な感じ.

任期あり,テニュアトラック以外(=再任なし):7
任期あり,テニュアトラック:3
任期なし:4

テニュアトラックをどうカウントするが難しいが,任期なし使い捨てポストが半分を占めるのはちょっとお辛いな.事業が終わったら拡大した学部・学科をどうするのだろう.(教員候補者なんて畑から生えてくるってか)

宇部高専制御情報工学科の公募,1年4ヶ月だけ働いてくださいはひどすぎる気が….一方で石川高専の※は力強すぎて涙が出てくる.

・物質工学科の公募【特命助教】(宇部工業高等専門学校)
> [契約期間]
> 任期あり - テニュアトラック以外
> 令和6年11月1日~令和9年3月31日。ただし、業績等を勘案して、令和11年10月31日までの延長があり得る。
> 事業年度ごと(当該年の4月1日から翌年の3月31日まで)の更新となります。

・和歌山大学システム工学部 情報科学、情報工学、人間情報学、およびその関連分野 講師または助教(テニュア・トラック制)3名の公募【大学・高専機能強化支援事業】(和歌山大学)
> [契約期間]
> 講師相当
> 任期あり - テニュアトラック
> 5年
> 助教相当
> 任期あり - テニュアトラック
> 5年
(4年経過後にテニュア審査に通ればテニュアが付与されるらしい)

・制御情報工学科の公募【特命准教授・特命助教】(宇部工業高等専門学校)
> [職種共通]
> 任期あり - テニュアトラック以外
> 令和6年12月1日~令和8年3月31日。ただし、業績等を勘案して、令和11年3月31日までの延長があり得ます。
> 業年度(当該年の4月1日から翌年の3月31日まで)ごとの更新となります。

・横浜国立大学教育推進機構 特任教員(准教授、講師又は助教)の公募 (横浜国立大学)
> [契約期間]
> 職種共通
> 任期あり - テニュアトラック以外
> 2025年 4月 1日から2026年3月31日まで
> 勤務成績により、年度ごとに更新の可能性有り。ただし、最長で2030年3月31日を限度とする(当初の雇用契約では最長でも2030年3月31日を限度とするが、予算の状況及び勤務成績を含めた勤務状況等に応じて2033年3月31日を上限として再採用の可能性あり)。
> ※雇用契約の更新の有無については、期間終了 30日前までに通知する。

・九州大学システム情報科学研究院 准教授(特定業務プロジェクト教員)の公募【主に工学研究院応用化学部門分子生命工学講座にて従事】
(九州大学)
[契約期間]
> 任期あり - テニュアトラック以外
> 任期5年(審査により、最長2032年度末まで雇用期間を延長することがある。職階上の昇進なし。)

・筑波大学図書館情報メディア系准教授または助教の公募(行動経済学)(筑波大学)
> 准教授相当
> 任期なし - テニュアトラック以外
> 試用期間なし
> 助教相当
> 任期あり - テニュアトラック
> 5年間
> 【有期労働契約を更新する場合の基準】
> テニュア獲得(任期なし)時を除き、有期労働契約の更新はありません。

・石川工業高等専門学校機械工学科教員公募(石川工業高等専門学校)
> [契約期間]
> 任期なし - テニュアトラック以外
> 原則任期は付さない。ただし,博士の学位を取得見込みの場合(助教に限る)のみ,採用日から3年間の任期付き採用とし,任期中に学位を取得した場合は,任期を付さない教員となる。
> ※「大学・高専機能強化支援事業(高度情報専門人材の確保に向けた機能強化に係る支援)」の事業期間にかかわらず,原則任期は付さず,当該事業終了後も継続雇用します。

・石川工業高等専門学校建築学科(2分野)教員公募 (石川工業高等専門学校)
> [契約期間]
> 任期なし - テニュアトラック以外
> ※「大学・高専機能強化支援事業(高度情報専門人材の確保に向けた機能強化に係る支援)」の事業期間にかかわらず,原則任期は付さず,当該事業終了後も継続雇用します。

・高度情報(人文情報学)特定プロジェクト教員(准教授または講師) 1名 (九州大学)
>【雇用期間】
> 任期5年(審査により、最長2032年度末まで雇用期間を延長することがある。職階上の昇進なし。)
> ※ただし、本学における通算契約期間は10年を上限とする。

・特任教授の公募(ネットワークデザイン学科・自然言語処理・2026年4月任用)(明治大学)
> 任期あり - テニュアトラック以外
> 任期5年(2026年4月1日~2031年3月31日)。

・専任教授の公募(ネットワークデザイン学科・エッジAIシステム・2026年4月任用) (明治大学)
> [契約期間]
> 任期なし - テニュアトラック以外

・特定プロジェクト准教授の公募(高度情報専門人材)(九州大学)
> [契約期間]
> 任期あり - テニュアトラック以外
> 任期5年(審査により、最長2032年度末まで雇用期間を延長することがある。職階上の昇進なし。)

2024年9月13日金曜日

大学・高専機能強化支援事業の選定結果から公募のかかる大学を予測する(?)

大学・高専機能強化支援事業のおかげで特定成長分野に助成金が交付されるのだが,採択された大学のリストを見ると将来の公募の動向を把握できるかもしれないと思った.

あくまで私の分野の話だが,2023年に採択された大学が今年(2024年)公募をかけていて,それらは2025年以降の着任を想定しているように見える.この傾向が続くのであれば,現在(2024年)に採択された大学は2025年に公募をかける事が予測できる,かもしれない.例えば2024年に京都大学が支援2ハイレベル枠に選定されている事から,2025年に複数人の公募がかかる可能性が予測できる.❤京大大好き❤な人は,2024年の公募戦線に出撃するのはやめて,2025年の公募戦線に参戦するのがよいかもしれない.

ただし特定成長分野とは「デジタル・グリーンを中心とした成長分野」であり「理学関係・工学関係・農学関係分野」とのことなので,どの分野に力を入れるかは大学による.

支援2は大学・高専名しかわからないが,支援1であれば改組後の学部・学科名も記載されているので,もう少し精度高く公募がかかる分野を予測できるかもしれない.

大学・高専機能強化支援事業は原則2025年度までとのことなので,2026年の公募以降は正常に戻ってしまう可能性がある.公募戦線を考えている人は,乗るしかない、このビッグウェーブに!!(2023年に認可された大学が2024年9月地点で未だに公募出していなかったりもするので,スパッとなくなる事はないかもしれないが)

追記:
学位授与機構のHPに,各大学がどのような内容で改組をするか示して資料が公開されている.
https://www.niad.ac.jp/josei/report/r6selection/

京大だと工学部電気電子工学科,情報工学科の定員20名増,研究室4増,教員無有期4名,有期8名増とある.一方で支援1の北陸先端科学技術大学院大学は教員の増員については述べていないから増員しないのかしら.

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 でのお話です.

2024年3月28日木曜日

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

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

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

3月中旬:投稿締め切り (3月上旬に設定された投稿締め切りは,2017年度以降毎年にわたり1週間延長されているようだ)
3月下旬:査読者割り当て
4月中旬:査読報告
5月中旬:判定報告
7月中旬:第二次投稿締め切り
8月中旬:査読報告
8月下旬:判定報告
12月  :早期公開
3月上旬:Preprint PDF発行

6月上旬:投稿締め切り
7月中旬:査読報告
8月上旬:判定報告
9月上旬:第二次投稿締め切り
10月上旬:査読報告
10月下旬:最終判定
11月下旬:最終原稿投稿
12月上旬:発行

7月中旬:投稿締め切り
7月下旬:査読者割り当て
8月中旬:査読報告
9月中旬:判定報告
10月中旬:第二次投稿締め切り
12月中旬:査読報告
12月下旬:判定報告
4月  :早期公開 (?)
7月上旬:Preprint PDF発行(?)

10月上旬:投稿締め切り
10月中旬:査読者割り当て
11月中旬:査読報告
12月上旬:判定報告
1月上旬:第二次投稿締め切り
2月上旬:査読報告
2月下旬:最終判定
3月下旬:最終原稿
6月上旬:発行

2024年2月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



2024年2月5日月曜日

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

環境は Linux Mint 21.2です.クラスファイルは ieice2.2 です.(2015年)
普通にコンパイルすると
.
で止まる.
\usepackage{graphicx,xcolor}% for pdflatex
\usepackage[dvipdfmx]{graphicx,xcolor}
に変える.

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

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


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

ほんとうかいな.カレントディレクトリに置いたファイルは"./"をつけよう.
\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 とすべて小文字でした.

2024年2月2日金曜日

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

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

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

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

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

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

確認
全部 emb が yes になっているからOK.

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

2024年2月1日木曜日

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

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

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

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


.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 を使っている.

2024年1月29日月曜日

アヴェンチュラの互換品?

 自転車に乗るときにクーレンズのアヴェンチュラを使っているのだが,買ってから 8 年経つ事もあり,インナーレンズフレームが崩壊して,公式のインナーレンズフレームを買い換えたらレンズが入らなくてフレームぶつ切りにして接着剤でくっつけ,つるも左側は折れてしまい接着剤でくっつけている.クーレンズはめがね事業から撤退してしまったようだ.アヴェンチュラ自体はフレーム+インナーレンズフレーム+アウターガラスレンズ4種(偏光2枚)+ハードケースのコミコミで5000円くらいと激安と当時有名だった.私はインナーレンズ買ったから1万5000円ぐらいしたけれど.

Amazonを見ていると,割とそっくりな商品として FERRY のアイウエアを見つけたので買ってみた.フレーム2つ(ただしツルは1セット)+インナーレンズフレーム+アウターガラスレンズ4種(偏光1枚)+ハードケースで2680円と激安である.


アヴェンチュラは黒だけれど,


FERRY は赤にした.形はすごく似ている.FERRY のロゴがダサい.


比較をしてみる.ツルは形は似ているけれど,根元も取り付け方法も違う.FERRY はなぜか90度回転して外すらしい.


サングラスそのものも形は似ているけれど,詳細は少々異なる感じ.


でも形状の互換性はある程度あってお互いに取り付け自体は可能.なんか隙間空いている?


インナーフレームも形は似ているけれど子細は違うような…….


互換性あるかなってぐいぐい押しつけていたら根元からポキッと折れたorz.まあ年数経っているしな…….結局,インナーレンズだけ接着剤でひっつけて使うのがいいのかね.

2024年1月26日金曜日

半導体クラウド学院

半導体クラウド学院 (半導體雲端學院 Semiconductor Cloud Academy)」という,TSMC が一般向けに作成した Web 教育システムがある事を教えていただいた.メールアドレスを登録すると,集積回路についてその原理から学ぶことができるみたい.コースの動画がかわいくて,中学・高校生が見ても楽しそうである.

なんとびっくり日本語対応である(でも句読点が台湾).

私のブラウザでの振る舞いがおかしくてテストを受けられないのだけれど,テストを受けると認証みたいなものももらえるらしい.

しかし TSMC は大学連携だったり教育だったりに力を入れだしていて,なんだか昔の STARC を一社でやり始めている感じだなぁ.

興味のある人は上記リンクから右上の「学生センター」を選択して登録してね.

2024年1月21日日曜日

sudo で X11 を有効にする

Cadence のインストーラー (installScape) を sudo で起動しようとすると,X11 に繋がらないと怒られる.
sudo で X11 を有効にするためには,xauth を用いてユーザーの X サーバ接続権限情報を sudo に与えてしまう.ユーザー名が [user] だとすると以下のような感じ.
/root/.Xauthorityが無いと怒られる場合は空のファイルを作ってから再実行.


まあ,オチとしては,installScape は root で実行するものではないという事なのですけどね.インストール先のパーミッションを適当な管理者にしてユーザー権限でインストールすべし.

2024年1月18日木曜日

"Error: 'top' doesn't specify a unique design" in DesignCompiler

 学生が以下のような tcl で論理合成中に current_design コマンドでエラーが出ると相談しにきた.
このエラーはファイル中に同じモジュール名の回路が複数ある場合に生じるエラー.しかし読み込んでいる Verilog ファイルは1つしかない.今回の例では,read_file コマンドで Verilog ファイルを読み込み,analyze コマンドで同じ Verilog ファイルを再読込しているため,メモリ中に同じモジュールが2つある事になっていたらしい.この場合,
list_design -show_files
list -designs
などでどのようなモジュールが読み込まれているか表示させてデバッグできる.今回についてはファイル読み込みが重複していたので,read_file コマンドを削除し analyze コマンドだけ実行することで解決した.

参考:
Pran Kurup and Taber Abbasi, "LOGIC SYNTHESIS USING SYNOPSYS® 2nd Ed.", KLUWER ACADEMIC PUBLISHERS

2024年1月15日月曜日

Milkyway でセルが正常に更新されなくて困っていた

オチ:Virtuoso の StreamOut のログとMilkywayのログをちゃんと確認すること.

ASAP7 ではセルを 4x して配置配線するので,1x ライブラリをコピー→ XScale を使って 4x → StreamOut → Milkyway DB → IC Compiler で配置配線をしていたのだが,一部のセルのサイズが変わらなくて困っていた.オチはは OA ライブラリ中に同名の別セルが存在していたことが原因だった (具体的には,4x ライブラリのセルが 1x ライブラリの INVx2_ASAP7_75t_SL をインスタンスとして読んでしまっていた).

StreamOut はちゃんと警告していて,ダブった方を "INVx2_ASAP7_75t_SL_0" とリネーム("_0")している.リネームされたのが 1x セルならよかったのだが,4x セルがリネームされてしまったのであった.

...
WARNING (XSTRM-145): The structure name 'INVx2_ASAP7_75t_SL' has been changed to 'INVx2_ASAP7_75t_SL_0' by the translator. This could be because multiple cells with the same cell name exist in different libraries, the same cell name has been mapped to multiple cell names, or the cell name length is greater than the '32' that was specified using the '-respectGDSIINameLimit' or '-gdsCellNameLength' option.
...

Milkyway の setPRBdry のログを確認すると正しく電源が抽出されているように見えたのだが,

...
Cell [INVx2_ASAP7_75t_SL_0.FRAM] has 2 horizontal p/g rails on MET1.
         the 1 rail's net type is gnd
         the 2 rail's net type is power
Extracting P/G track for cell INVx2_ASAP7_75t_SL_0.FRAM
power/ground track (low, high): (-144, 144) (4176, 4464)
...

これはリネームされた 4x セルで,本来の名前のままの 1x セルは処理中には異なる位置の電源が抽出されており,ちゃんと「電源おかしいで」と警告されていたのであった.

...
Cell [INVx2_ASAP7_75t_SL.FRAM] has 2 horizontal p/g rails on MET1.
         the 1 rail's net type is gnd
         the 2 rail's net type is power
Extracting P/G track for cell INVx2_ASAP7_75t_SL.FRAM
power/ground track (low, high): (-36, 36) (1044, 1116)
WARNING: cell AOI321xp33_ASAP7_75t_SL.FRAM and NAND2x1p5_ASAP7_75t_SL.FRAM have different PG rail extension.
...

余談だけれど,スタセルの外形情報は Milkyway のログから抽出してもいいかもしれない.Virtuoso をゴリゴリスクリプトで動かすのは結構遅いので.