2019年7月27日土曜日

IC Compilerにおけるderive_pg_connectionの順番

IC Compiler で電源を定義し回路(スタセル,マクロ)の電源ポートと接続するために
 derive_pg_connection コマンドを利用する.多電源回路では複数回コマンドを呼び出す必要があるが,スタセルの電源に接続したい電源名を最初に宣言する必要がある.

例えばVDDCとVDDMがあり,スタセルのVDDにVDDC配線を接続する場合は,
derive_pg_connection -power_net {VDDC} -power_pin {VDD} -ground_net {VSS} -ground_pin {VSS}
derive_pg_connection -power_net {VDDM}
とする.
もし
derive_pg_connection -power_net {VDDC}
derive_pg_connection -power_net {VDDM} -power_pin {VDD} -ground_net {VSS} -ground_pin {VSS}
と逆にすると,preroute_standard_cells コマンドでスタセルの電源レールを引いた時にVDDMとVSSのレールができてしまう.

preroute_standard_cells-net オプションをつけずに実行すると,デフォルトで電源とグラウンドのネットを使うとあるので,どうも一番最初に宣言した -power_net を回路の電源と認識するようだ.preroute_standard_cells コマンドで電源ネットを明示的に指定するためには以下のようにすれば良さそうだが未検証
preroute_standard_cells -net {VDDC VSS}

2019年7月23日火曜日

IC Compilerでホールド違反を回避できない時に気をつける事

(1) ホールド違反を回避しながら再配線する
set_fix_hold [all_clocks]
route_opt -incremental -only_hold_time

(2) focal_optを実行する
focal_opt -hold_endpoints all -register_to_register

focal_optはトポロジベースのポストルート最適化コマンドで,セットアップ違反,ホールド違反,DRC 違反などを回避可能だそうだ.ポストルート最適化なので route_opt のあとに実行する.

(3) コア面積の余裕を確認する
コア面積に十分余裕がないとホールド違反回避バッファを入れられないので,いくら
route_opt -incremental -only_hold_time
を実行してもホールド違反を回避できない.

create_floorplan で Utilization が 0.8 だから大丈夫?そんなことはなくて,TAP セル,Endcap セル,Tie セルなどがどんどん入るので余裕はない.さらにTiming Driven P&R では駆動力が足りない場合はより大きなセルに入れ替えたりパスを分割(path-spliting)して駆動力を確保するのでますます余裕はなくなる.

ある回路では,初期の Utilization が54.8%だったのに,配置配線後の実際のUtilizationは87.1%になっていた.

Utilizationは以下のコマンドで評価できる.
report_placement_utilization

2019年7月5日金曜日

HSPICEにおける非収束(Non-Convergent)の原因と対策

マニュアルを訳しただけです.

HSPICEでなんで収束しないの?そもそも収束って何?と言う人はSPICEの動作原理について勉強するといいかも.

[原因]
#0 回路構造の確認
回路にフローティングが存在すると,その点の電圧を決定できないために非収束となる.すべてのノードがなんらかしらの素子を経由しながら電源もしくはグラウンドに接続されている事を確認する.

#1 初期値の設定
安定状態が複数ある回路の場合,初期値を自動的に決められない.特にリングオシレータやフリップフロップは初期値を一意に決められない.その場合,.ic コマンド(initial condition)を使い初期値を与える必要がある.

#2 不適切なモデルパラメータの導入
物理モデルパラメータに沿わないパラメータを導入した結果,ソースドレイン電流や容量特製に不連続が発生する事がある.これはinitial timestep too smallエラーを引き起こす.

#3 PN結合の高抵抗
BJTやMOSFETのPN結合は高いオフ抵抗を持つ.このオフ抵抗が非収束の原因となる.HSPICEでは,.option gmindc .option gminを設定する事で,これらの素子に自動的に抵抗を挿入し収束可能性を向上する.

[対策]
#1 すべてのオプションを消して,HSPICEの標準の収束アルゴリズムを動かしてみる.

#2 .nodesetや.icを用いて初期値を適切に与える.

#3 デジタル回路であるなら,シンボリック動作点解析アルゴリズムを利用する.
.option symb=1

#4 ITL1とITL2を200から500の範囲で増やす.
.option ITL1=300 ITL2=300

#5 収束アルゴリズムを変える.HSPICEは標準でDCON=1,2とアルゴリズムを変え,
最終的にconverge=1を選ぶ.これでも収束しない場合設定で変えてやる.また
gmindcの値を小さくする(ただし1e-9より小さくしてはいけない)
.option converge=2 gmindc=1e-11
.option converge=3 gmindc=1e-11

#6 2 DC バイアスポイントによる方法もあるが,よくわからなかった.非収束の原因となるデバイスをオフにしてバイアスポイントを求め,次にこの素子をオンにしてバイアスポイントを求めるのだろうか.

2019年7月1日月曜日

HSPICEの性能を上げる10のtips

SynopsysのBlogを直訳したものです.
10 tips to improve performance using HSPICE

#1 HSPICEの収束性を上げるためにrun levelを適切に設定する.
.option runlvl = 1|2|3|4|5|6

#2 High Performance Parallel(HPP)オプションを使い,マルチスレッドで高速化する.
% hspice [file].sp -mt [numCPU] -hpp

あまりたくさんのCPUを指定しても速くならない.2~4CPU程度

#3 分散コンピューティング(Distributed Computing)オプションを使い,マルチマシンで高速化する
% hspice [file].sp -dp [numCPU]

分散コンピューティングのための事前に設定が必要.

#4 ポストレイアウトシミュレーションの場合, RC 縮約を使う.
.option sim_la

#5 ワイルドカードを使ってすべてのノードの電圧・電流を見るのではなく,見たいノードを指定する.
.probe tran v(xi.*)  i(xi.*)
× .probe tran v(*)  i(*)

#6 ポートの電流の向きを指定する.
.probe tran isub(xinv.vdd) isub(xinv.v*)
×  .probe tran isub(*)

#7 .alterを使っている場合,回路構造の解析を省略する.
.option altcc altchk

#8 回路要素のチェックや回路構造のチェックを飛ばしシミュレーション時間を短くする
.option notop noelck

#9 回路を変更していない場合,過去のシミュレーション結果を再利用する事でシミュレーション時間を短縮する
% hspice -i [file].tr0 -meas [meas file]

[meas file]は,HSPICEの構文のうち.measureなどの測定命令,.paramなどの設定命令のみを抜き出したもの

#10 .measureがすべて終了したらシミュレーションを終了する.
.option autostop

2019年4月18日木曜日

Windows10ホスト上のVMware Workstation 15 PlayerのゲストCentOS7.2とフォルダを共有する

すんなりいかなかったのでメモ.解決策は以下のリンクの通りになった.
Solved: Shared folders not available on Linux guests after upgrading to VMWare Workstation 15


ホスト側:
[管理]→[仮想マシン設定]→[オプションタブ]→[共有フォルダ]から,ホスト側の共有フォルダの場所を指定する.
これは今まで通り

ゲスト側:
yumでopen-vm-toolsをインストール
% yum install open-vm-tools
マウントポイント/mnt/hgfsを作る
% cd /mnt
% mkdir hgfs
手動でマウントしてみる.
% vmhgfs-fuse .host:/ /mnt/hgfs -o allow_other
/mnt/hgfs/[ホストOSで設定した共有フォルダ名]/
にアクセスしてみて,読み書きできればOK

手動でマウントできたら,/ets/fstabに以下の構文を書いてあげると次回以降自動でマウントする.
% echo ".host:/ /mnt/hgfs fuse.vmhgfs-fuse allow_other 0 0" >> /etc/fstab

あとは必要に応じてスタティックリンクを作ればOK
% cd 
% ln -s /mnt/hgfs/[ホストOSで設定した共有フォルダ名]/ SharedFolder

ゲストOSをサスペンド・レジュームするとマウントができなくなると書かれていたが,こちらではそんなことはなさそう.ただしサスペンド前のディレクトリスタックは無効になっているみたい.

起動に時間がかかるようになった.mountしようとして時間かかっているのだろうか.

2019年4月13日土曜日

Gmailで別のGmail(G-suite)のメールを読み書きする

(本当はもっとスマートなやり方がある気がするが)
新しい職場のメール環境がG-Suite(以下Gmail2)で,二段階認証だったりなんなりでメールがめんどくさい.そもそもメーラーを使い分けたくないので,使い慣れたGmail(Gmail1)でGmail2のメールを読み書きしたい.

(1) アプリケーションを使ってGmailで送受信するためのアプリパスワードを作る.

Gmail2のほうは二段階認証なのだがアプリ側にそのような対応はできないので,アプリ専用のパスワードを作る.Gmail2のほうのGoogleアカウントへログインし,[セキュリティ]→[アプリパスワード]を作成する.

(2) 送信側:Gmail2のSMTPサーバーを使ってGmail1を送信する.

Gmail1の歯車マークから[設定]→[アカウントとインポート]→[名前]→[他のメールアドレスを追加]を選ぶ.
最初の画面でメールに記載される名前とGmail2のアドレスを入力する.
Gmail2のアドレスを入力するとそこからサーバーの情報を読み取ってくれるので,適切なSMTPサーバー/ポートになっていることを確認して,アプリパスワードを入力する.
必要に応じてデフォルトを変えたり返信モードを設定すればOK.

(3) 受信側:Gmail2のメールをPOPでGmail1に受信する.

Gmail2の歯車マーク→[メール転送とPOP/IMAP]から,[すべてのメールでPOPを有効にする]にチェックする.
この時,「Gmail2のメールを受信トレイに残す」としておくと,メールは受信トレイにたまり続ける.
Gmail1の歯車マークから[設定]→[アカウントとインポート]→[他のアカウントでメールを確認する]を選ぶ.
Gmail2のアドレスを入力するとそこからサーバーの情報を読み取ってくれるので,POP(しか選べなかった)を選び,適切なPOPサーバー/ポートになっていることを確認してアプリパスワードを入力する.

あとは適当なアドレスと通信を確認して,以下のように通信ができていればOK.
[適当なアドレス]→[Gmail2]→POP→[Gmail1]
[Gmail1上でGmail2として返信]→IMAP→[Gmail2]→[適当なアドレス]


【・・dynabook R63のファンに注油する,CPUクーラーのグリスを塗る

4年使ったdynabookさん,ファンから軸音がガリガリするようになり,3.5インチのHDDでもつんでるんか?ってぐらい異音がする.あまりにもつらいので注油することにした.

ねじを外してPCの底を開ける.左上にCPUファンがあるので,CPUファンを止めている2か所のねじをはずす.CPUファンとヒートパイプは分かれるので,ファンだけ外すのであればヒートパイプは外す必要はない.ヒートパイプを外すには,CPU周辺の2か所のねじをはずす.


CPUファンは小さいねじと小さい爪で固定されているので,ファンの外装を止める小さいねじを外す(上の写真では外してしまっている).


ファンを引き抜くと軸受けがみえるので,オイルを少量添付する.


ファンのシャフトが入る真ん中の黄色い穴に少量だけ添付した.


自転車で使っているワコーのメンテルーブを少量吹き付けた.




CPUグリスもカピカピになっていたので塗りなおした.Arctic Sliver 5という自作PCで使っているやつです.

元の通り組み立てたら終わり.軸音も解消され元の通りになった.最初CPU温度が無負荷で80℃を超えビビったけれど,グリスを塗りなおしヒートパイプのねじを増し閉めしたら45℃ぐらいに改善された.
このPC(R63/PS)は買った時からファンが異様にうるさくてサポートに見てもらったものの「異常なし」で帰ってきたのだが,注油してもファン音は改善されなかった.後継機(RZ63/AS)のファン音はまだまともなんだけれどな.

2019年4月12日金曜日

【・・dynabook R63のキーボードを交換する

4年使った【・・dynabook R63のキーボードが摩耗し,ASDFのキーがぐらぐらし,ついにはAのキートップがはがれるようになったのでキーボードモジュールを交換した.昔はYahoo Auctionとかで買っていたけれど,今はAmazonでも売っている.いずれにせよどういうルートでパーツ売られているのかわからないけれど.(横流し品ではないよね?)

R63は2種類キーボードがあり,ただのキーボード(3000円弱)とアキュポイントとバックライト付きキーボード(5000円弱)がある.手持ちのR63は後者が初期装備なので後者を買った.アキュポイント付きキーボードはキーボードのマトリックス信号とアキュポイントの信号が同じフラットケーブルを通っているので,両社の互換性については不明.
(アキュポイントなしのマシンにアキュポイント付きキーボードをつけて動くかわからないし,アキュポイントがないマシンはキーボード下部のマウスクリックボタンもないので使い勝手は悪そうである)



買ったキーボードモジュール.


裏側.左側の細いケーブルがバックライト,真ん中の太いのがキーボードとアキュポイント.キーボードを外すためには,本体の下側のカバーを外し,バッテリーを外し,今ついているキーボードのフラットケーブルをすべて外す.

次に,最近のdynabookはキーボードを両面テープで接着しているので力づくではずす.本体フレームの後ろから押し出してあげるとよい.強力すぎて本体のフレームが壊れるかと思った.取り外したキーボードはバキバキになります.新しいキーボードは市販の両面テープで接着する.


フラットケーブル拡大の図(上下逆さ).写真左の太めの信号がアキュポイントで,この信号が適切にはまらないとアキュポイントが暴走して使い物にならない.何度かさしなおすことを想定し,調節してちゃんと動くことを確認してからカバーをねじ止めするのがおすすめです.私の場合,差し込んで,バッテリーと蓋をねじ止めて,起動したらアキュポイントが暴走していて,再度開封して差し込みなおして,ねじ止めて(以下ループ)を5回以上繰り返した 囧rz


換装後.ちゃんとキーボード打てるようになりました.新品のキーボードはしっとりしていてよい.ただ,Gのキーがちょっと傾いている気がするし,アキュポイントがちょっと暴走気味.やっぱりQCで外れたものを横流(ry
心配なら聖地チチブデンキで買おう!

2019年4月5日金曜日

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

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

スペック
・男
・集積回路の物理設計よりのCAD屋.回路設計もするよ
・応募時の業績:論文誌4本,レター1本,国際会議10本,その他
・任期5年再任有りが再任無しになっていたので仕方なく公募戦線へ再挑戦することに
(再任については私の勘違いでは?という話もあるとか)

こだわったところ
・集積回路設計に関わりたい
・PIは,私が知っている教員か,外部資金などを取っている教員を希望した.

2018/8 国立大
・任期付き助教(5年,再任無し)
・研究室の指定有り
・分野は少し違う.分野はこちらが合わせる事はできそう
・応募後,8週間ほどでお祈りメール

2018/8 公立大
・任期付き助教(5年,再任有りだったはず)
・研究室の指定有り
・先生の分野と自分の分野は同じ
・悩んだけれど,知らない先生だったのでやめてしまった
・応募者がいなかったらしく,再公募しているようだ

2018/? 公立大
・任期付き助教(5年,再任有りだったはず)
・研究分野の指定有り
・分野は少し違う.研究分野はこちらが合わせる事はできそう
・学会でPIの先生に話をしたら「アナログ回路の人が欲しいんだよね」と言われたので応募を止めた

2018/10 私立大
・任期付き助教(5年,審査後任期無し)
・研究室の指定あり
・分野は近いようで少し違う.研究分野は合わせる事はできそう
・応募後,即連絡が来て即面接,即内定.PIに採用権限があるためらしい

感想
・集積回路系といっても分野が広いので,デジタル回路向けCAD屋さんにフィットする公募は少なく感じた
・IoTとか,デバイスを作る側ではなく使う側の公募は多い?
・もっと多くの国内学会に参加しておくべきだった.知らない先生が意外と多い
・JRecinの過去ログは消えるのでPDFは保存しておくべき
・助教から助教なのは察してください

前回の公募戦線記録はこちら:とある博士学生の助教公募戦線記録

2019年4月4日木曜日

VMware上のCent OS7に固定IPを割り当てる

Windows10をホストOS,Cent OS7をゲストOSとして,ゲストOSに固定IPを割り当てたい.いろいろやり方があって混乱したけれど,結果的には以下の記事の情報が役に立った.

VMWARE PLAYER の NAT ネットワークを極める
http://hetarena.com/archives/2343

ポイントは,Vmware上のNATネットワークでは,
ゲストOSからみて
ホスト:192.168.xxx.1
ゲートウェイ:192.168.xxx.2
になる.固定IPにしたければ,(1)DHCPの範囲外で性的に割り当てるが,ホストOS上で動くDHCPサービスがゲストOSに固定IPを割り当てるようにすればよい.

ゲストのCent OSでは,まず自分のMACアドレスを探す.
% ip a
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
(略)
2: ens33: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:0c:29:35:e2:ea brd ff:ff:ff:ff:ff:ff
    inet 192.168.xxx.128/24 brd 192.168.xxx.255 scope global noprefixroute dynamic ens33
(略)


この地点ではDHCPで192.168.xxx.128が割り当たっている.xxxはVMwareインストール時に一意に決まるそう.
ens33のlink/etherに続く12文字がMACアドレス.これをホストOSのDHCPサービスの設定に書き込む.

NATではホストOSはVMnet8で通信するのでそこを書き換える.
開くファイル:C:\ProgramData\VMware\vmnetdhcp.conf
host VMnet8 {
     hardware ethernet 00:0c:29:35:e2:ea;
     fixed-address 192.168.xxx.50;
 }
のように書き換える.ここでは固定IPとして 192.168.xxx.50を割り当てる.なお,システムによっては直接編集ができないようなので,私はいったんデスクトップにファイルをコピーしたうえで編集し,C:\ProgramData\VMware\vmnetdhcp.confを上書き保存した.

設定を反映させる.

ホストOSのDHCPサービスを再起動.
[タスクマネージャ]→(必要に応じて詳細設定表示)→[サービス]→[VMnetDHCP]を右クリック→[再起動]

ゲストOSのネットワークを再起動
% systemctl restart network

IPアドレスを確認
% ip a
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
(略)2: ens33: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:0c:29:35:e2:ea brd ff:ff:ff:ff:ff:ff
    inet 192.168.xxx.50/24 brd 192.168.249.255 scope global noprefixroute dynamic ens33
(略)

これでIPアドレスを固定できた.

ここまで記事を書いて気が付いたが,昔全く同じ記事を書いていた.車輪の再発明をしてしもうたてへぺろ(少しだけ情報多いからそのまま載せます)