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

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

<shape aspect="fixed" h="110" name="PMOS" strokewidth="inherit" w="70"> <connections> <constraint name="NE" perimeter="0" x="1" y="0" /> <constraint name="SE" perimeter="0" x="1" y="1" /> <constraint name="W" perimeter="0" x="0" y="0.5" /> </connections> <background> <save /> <ellipse h="10" w="10" x="30" y="50" /> </background> <foreground> <stroke /> <path> <move x="41" y="35" /> <line x="41" y="75" /> </path> <stroke /> <path> <move x="70" y="0" /> <line x="70" y="35" /> <line x="45" y="35" /> <line x="45" y="75" /> <line x="70" y="75" /> <line x="70" y="110" /> </path> <stroke /> <path> <move x="0" y="55" /> <line x="30" y="55" /> </path> <stroke /> <restore /> <rect /> <stroke /> <fillstroke /> </foreground> </shape>  

ついでに NMOS も．

<shape aspect="fixed" h="110" name="NMOS" strokewidth="inherit" w="70"> <connections> <constraint name="NE" perimeter="0" x="1" y="0" /> <constraint name="SE" perimeter="0" x="1" y="1" /> <constraint name="W" perimeter="0" x="0" y="0.5" /> </connections> <background> <save /> </background> <foreground> <stroke /> <path> <move x="41" y="35" /> <line x="41" y="75" /> </path> <stroke /> <path> <move x="70" y="0" /> <line x="70" y="35" /> <line x="45" y="35" /> <line x="45" y="75" /> <line x="70" y="75" /> <line x="70" y="110" /> </path> <stroke /> <path> <move x="0" y="55" /> <line x="41" y="55" /> </path> <stroke /> <restore /> <rect /> <stroke /> <fillstroke /> </foreground> </shape>  

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

<shape aspect="fixed" h="110" name="PMOS4" strokewidth="inherit" w="70"> <connections> <constraint name="NE" perimeter="0" x="1" y="0" /> <constraint name="SE" perimeter="0" x="1" y="1" /> <constraint name="W" perimeter="0" x="0" y="0.5" /> </connections> <background> <save /> <ellipse h="10" w="10" x="30" y="50" /> </background> <foreground> <stroke /> <path> <move x="41" y="35" /> <line x="41" y="75" /> </path> <stroke /> <path> <move x="70" y="0" /> <line x="70" y="35" /> <line x="45" y="35" /> <line x="45" y="75" /> <line x="70" y="75" /> <line x="70" y="110" /> </path> <stroke /> <path> <move x="0" y="55" /> <line x="30" y="55" /> </path> <stroke /> <path> <move x="70" y="55" /> <line x="45" y="55" /> </path> <stroke /> <restore /> <rect /> <stroke /> <fillstroke /> </foreground> </shape>  

<shape aspect="fixed" h="110" name="NMOS4" strokewidth="inherit" w="70"> <connections> <constraint name="NE" perimeter="0" x="1" y="0" /> <constraint name="SE" perimeter="0" x="1" y="1" /> <constraint name="W" perimeter="0" x="0" y="0.5" /> </connections> <background> <save /> </background> <foreground> <stroke /> <path> <move x="41" y="35" /> <line x="41" y="75" /> </path> <stroke /> <path> <move x="70" y="0" /> <line x="70" y="35" /> <line x="45" y="35" /> <line x="45" y="75" /> <line x="70" y="75" /> <line x="70" y="110" /> </path> <stroke /> <path> <move x="0" y="55" /> <line x="41" y="55" /> </path> <stroke /> <path> <move x="70" y="55" /> <line x="45" y="55" /> </path> <stroke /> <restore /> <rect /> <stroke /> <fillstroke /> </foreground> </shape>  

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

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

参考：

draw.ioで既存図形の形を編集する

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]

・参考

https://community.cadence.com/cadence_technology_forums/f/custom-ic-design/22549/translating-ic5-libaries-to-ic6

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]

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

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って一体何なんだ．

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 であろうか．

・ソフトエラー関係

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月上旬：発行