return 0 vs return (0) in C

C 言語のプログラムで return で戻り値を返すときにかっこをつける人とつけない人がいる．ググルとつけない人が多いようだが，他の制御文 for()，while() などは括弧をつけている．なぜ return はつけないんだろう，って調べてみた．

まず，オリジナルの C 言語の return 文は括弧をつけよとのことであった．また仕様書を読む限り，制御文と括弧の間にはスペースを，関数と括弧の間にはスペースを入れないよう書き分けているようだ．

return (0); ○

return(0); △?

return 0; △?

return0; ×

for(;;); △?

for (;;); ○

myfunc (); △?

myfunc(); ○

ただし，ANSI C や今のコンパイラは括弧をつけなくても認識してくれる，との話である．

Source: Stack Overflow

https://stackoverflow.com/questions/161879/parenthesis-surrounding-return-values-in-c/46867785#46867785

Virtuoso -nograph が実行できない

オチ：x11の基本フォント(xfonts)をすべて入れる．

Virtuoso -nograph を実行すると，cdsVnc が云々と言って実行が止まる．

% virtuoso -nograph -replay rotate.il *WARNING* Unable to open -nograph X Window Display "local:80" *WARNING* (using "exec /usr/cadence/IC617/tools.lnx86/dfII/../bin/cdsVncserver :80 -co /usr/share/X11/rgb&"). *WARNING* cdsXvnc output may be found in file $HOME/.vnc-cds/local:80.log %

.vnc-cds/local:80.log を開いてみると，フォント(fixed)が見つからないと怒られている("could not open default font")．'fixed'でググルと fixed フォントが必要なようだ．

16/11/23 11:25:20 Xvnc version 3.3.7 - built May 31 2004 15:31:52 16/11/23 11:25:20 Copyright (C) 2002-2003 RealVNC Ltd. 16/11/23 11:25:20 Copyright (C) 1994-2000 AT&T Laboratories Cambridge. 16/11/23 11:25:20 All Rights Reserved. 16/11/23 11:25:20 See http://www.realvnc.com for information on VNC 16/11/23 11:25:20 Desktop name 'local:80 (username)' (local:80) 16/11/23 11:25:20 Protocol version supported 3.3 16/11/23 11:25:20 Listening for VNC connections on TCP port 5980 Font directory '/usr/share/X11/fonts/' not found - ignoring Font directory '/usr/share/X11/fonts/misc/' not found - ignoring Fatal server error: could not open default font 'fixed'

フォントが入っていないのが原因なので，基本フォントをすべてサーバー側マシンにインストールしてやる．

https://access.redhat.com/solutions/320563

sudo yum search xorg-x11-fonts*

でフォントをすべて表示させて，すべて install すればよい．

どうも VNC 等を使うと表示されるエラーみたいだけれど，cdsVnc って Cadence ツール内部の VNC なのだろうか．研究室内で VNC を使ってサーバーにつないでいるので，こちら側の問題かと思ってしまった．

シリコンバレー: ケイデンスとアバンティの間の争い

面白い記事を見つけたのでGoogle翻訳にぶち込んだ物をあげてみる．なお正確性についてはわかりません．似たような話は特に中華圏で多数上がっているけれど，Google検索で古い物を探していくと，最も古い物としてなにかのWeb記事のPDF印刷版がヒットした．2002年のタイムスタンプみたい。

http://km2000.us/franklinduan/articles/Cadence%20Avanti.pdf

もっときれいに翻訳できた記事もあったけれど，あえて原典？を翻訳したものを貼ってみる．

--ここから

硅谷故事 Cadence & Avanti 的故事

 1994 年 3 月中旬のある日、ケイデンス デザイン システムズ社のオフィスビルの社長室は緊張した異様な雰囲気に包まれ、オフィスにいた 2 人とも無表情でした。デスクの後ろには、ケイデンスの社長兼 CEO であるジョセフ・B・コステロがいます。デスクの前には、台湾出身の中国人であるジェラルド・'ジェリー'・C・スーがいます。）、シューはこの時、ケイデンスのチップ設計部門のゼネラルマネージャーでした。

  徐建国氏は手にした辞表をカストロ氏に手渡している。

  カストロ氏は数回の対話を経て、徐建国氏の辞任は避けられないと悟った。

  「あなたの計画は何ですか？」とカストロは尋ねた。

  「まず休暇を取ります。」徐建国は答えた。

  「どこへ行くの？」とカストロ氏は巧みに尋ねた。

これは、Xu の休暇先と、Cadence を辞めた後の Xu の将来の計画の両方について尋ねる、突っ込んだ質問です。 「ビーチに行く予定です」。

 徐建国は、将来の居場所については答えを避けて答えた。数日後、記者会見は終了し、徐建国氏が正式にアークシスの社長兼最高経営責任者（CEO）に就任した。彼はカストロから電話を受け、その声はよく知っていた、「ここがあなたのビーチだ。日焼けによる皮膚の厚さを失わないよう気をつけていただければと思います。 」その後、カストロ氏は電話を切った。  こうして、シリコンバレーの企業秘密窃盗事件史上最大の法廷闘争が始まった。

(Avanti : Arcsys は後に別の企業 ISS と合併し、社名を Avanti に変更しました。``阿凡提'' はそれの音訳です。国内の中国語訳が先駆者としてよく使用されます) 

背景: 先史時代

 1970 年代後半、集積回路商品化に向けて設計が進み始めました。そこで、電子設計自動化（EDA: Electronic Design Automation）のコンピュータ支援設計（CAD: Computer Aid Design）と呼ばれる、これらの回路の設計をサービスする専用のソフトウェアが登場し始めました。1970 年代後半から 1980 年代前半にかけて、EDA のリーダーは Calma、ComputerVision、Applicon でした。しかし、1980 年代半ばからすぐに、Mentor Graphics、Daisy、および Valid の他の 3 社が市場の最大シェアを占めるようになりました。  1980年代以降、コンピュータが商用段階に入ると、企業はチップ設計の無限の可能性に徐々に気づき、無数の新興企業が誕生し、それらと連携するCADソフトウェア業界も黄金時代を迎え始めました。

 私たちの物語の主人公の一人であるカストロが EDA のキャリアをスタートしたのはこの時でした。  今ではシリコンバレーの象徴的な人物となったカストロ氏は、他のシリコンバレーのレジェンドとは異なり、シリコンバレー出身ではなく、偶然の出来事がきっかけでシリコンバレーにやって来て足跡を残したに過ぎない。

  カストロの当初の目標は、物理学者になって科学者のキャリアに集中することでした。1970年代、彼は東海岸のイェール大学に留学していましたが、ガールフレンドは西海岸のサンフランシスコの学校に通っていました。カストロはエール大学での学業を終えた後、バークレー大学で物理学の学位を取得するために西海岸に移りました。彼は博士号の取得を目指している間、ナショナル セミコンダクターで夏の仕事をしていましたが、夏の仕事の内容を説明していたとき、ガールフレンドに「君は自分よりも夏の仕事の方が好きみたいね」と言われました。カストロ氏は慎重に検討した結果、博士号取得を断念し、エレクトロニクス業界に参入した。

  カストロは 2 ～ 3 年のキャリアを経て、1983 年に SDA に入りました。

1986年、カストロはSDAの会長に就任した。

1988 年、SDA は別の EDA 会社 ECAD と合併し、社名をケイデンスに変更し、カストロが新会社の社長兼 CEO に就任しました。

  1988年から1992年はカストロにとって最も傑出した年だった。彼のリーダーシップの下、ケイデンスは継続的な拡大、合併、買収を経て、1988 年には業界 7 位でしたが、1992 年には業界リーダーになりました。彼の市場主導の企業経営モデルは、彼の成功の最大の特徴となっています。

  EDA CAD市場を大きく分けると、3つに分けることができます。フロントエンド技術（シミュレーションを含むフロントエンドとVerilogなどのデバイスの組み合わせ）、バックエンド テクノロジ (配置配線チップのレイアウトと配線を含むバックエンド）、検証技術（DRC/LVSなど）。

  EDA 市場が煙に巻かれた 1992 年と 1993 年には、2 つの巨人だけが残っていました: シノプシスは基本的にフロントエンド技術を独占し、市場のほぼ 60% を占めていました; ケイデンスは基本的にバックエンド技術と検証を独占していました。市場のほぼ80％を占めています。他の EDA 企業は生き残っていますが、市場シェアと利益は苦戦しています。しかし、EDA のこれまでの歴史と同様に、一見平静に見える瞬間が突然の変化の前兆であることがよくあります。

Dark Clouds：アバンティの出現

 もちろん、ケイデンスに脅威はありません。まず、電子設計はますます複雑になっており、常に新しいソフトウェアが必要であり、新しいテクノロジー企業が絶えず出現しています。この状況に対するケイデンスの解決策は、独自のテクノロジーを開発し、新しいテクノロジーを獲得する機会を待つことです。一般的に、新興の中小企業にはケイデンスのような強力な営業力がありません。ケイデンスがこれを高値で買収し、強力な販売力と組み合わせることで、そのメリットはさらに大きくなりました。

  カストロ氏が予期していなかったもう 1 つの脅威は、社員数十数人の小規模企業 Arcsys であり、この会社の目標はまさに Cadence の中核であるチップ レイアウトと配線です。

  1991年初頭、ケイデンスの元従業員だった中国人4人、スティーブン。 Stephen Tzyh-Li Wuu、Yuh-Zen Liao、Yuln-Chung "Eric" Cho、および Michael Mon-Yen Tsai は辞任し、Cadence を去り、新しい EDA ソフトウェア会社 Arcsys を設立しました。

  次の 2 年間で、Arcsys は独自のレイアウトおよび配線製品 ArcCell の発売を開始しました。ArcCell はまだ非常に大まかな試用段階にありましたが、Cadence はすでにその脅威を感じていました。アークシスは他の小規模な新興企業と同様に、強い生命力を持っていますが、その販売能力は非常に限られています。カストロは、この幼き敵をゆりかごに閉じ込めることに決めた。

  1992年末、カストロは最も有能な補佐官徐建国にアークシスとの戦争を指揮させることにした。徐建国は『ケイデンス』のラフなスタイルで有名で、ショッピング モールを戦場に例えて表現するのが好きで、中国の孫子の兵法をガイドとして使用しています。かつての皇帝が失敗した将軍の首を刎ねたように、彼は頻繁に人を解雇した」と元部下の一人は語った、「しかし彼は常に、自分が解雇した人物の代わりにもっと良い人材を探していた。

ショッピングモール: 兵士たちは欺瞞に飽きない

 徐建国で働く人々は、自分たちが恐怖の中で生きていると感じることが多い。徐建国は自軍の戦い方を強く主張し、ケイデンス内でも論争を巻き起こした。彼はかつて部下に、敵対者を取り締まるという目的を達成するために、アークシスのエンジニア全員の在留状況を調査し、不法滞在の疑いがある者を通報する準備をするよう命じたことがある。

  Xu Jianguo は 1992 年末に技術担当者とマーケティング担当者を含む B チームを設立しました。徐建国は、技術面でアークシスを上回ることと、市場でアークシスを抑制するという 2 つの側面から戦争を開始し、チーム B の内部会議で徐建国はこの戦いを AK47 と名付けました。この名前はもちろん、覚えやすいように旧ソ連製の AK47 アサルトライフルと同じにすることを意図したものですが、徐建国はこれに“Kill Arcsys in 47 weeks”，（47 週間で Arcsys を殺せ）という新たな意味を与えました。 

  徐建国はチームメンバー全員を集め、ポケットから4ダースの弾丸が入った弾丸箱を取り出したと言われている。彼は、毎週射撃場に行って弾を撃ち、もし47発の弾丸を発射してアークシスが倒されなければ、最後の一発を自分のために取っておくつもりだと語った。

  マーケティングの面では、Xu 氏は営業スタッフを個人的に率いて、反抗的なユーザー (ケイデンスを捨てて Arcsys を使用したユーザーを指します) を訪問し、製品の違いのあらゆる詳細を尋ね、ユーザー変更のあらゆる理由を尋ね、各ユーザーにさまざまな製品を返品することを約束させました。徐建国氏は自分が手にしている権力を十分に認識しており、ケイデンス社は強力な販売ネットワークと経済的背景を持っているが、アークシス社はそのような位置争いに対抗することはできない。

  技術面では、チップ設計はサブミクロンおよびスーパーサブミクロン技術の時代に入り始めており、古いチャネル配線技術は新しいエリア配線技術に置き換えられます。彼は技術スタッフがイノベーションを行えるよう厳しい時間を残し、研究開発部門には Arcsys よりも先に新しいテクノロジーのイノベーションを完了するよう求めました。

  誕生したばかりのアークシスにとって残念なことに、ケイデンスからの強い圧力を受けて、会社の経営状況は悪化してしまいました。1993 年を通じて、ArcCell の売上は 170 万ドルにとどまり、利益が得られなかっただけでなく、年間 220 万ドルの損失を被りました。Arcsys にとって、Xu Jianguo のポジション戦争と価格戦争は、Arcsys を実質的に崩壊の危機に瀕させました。

  裏切り：同志からライバルへ 

 しかし、アークシスが生き残る機会を模索する一方で、ケイデンス内に分裂の兆しが見え始めた。徐建国の容赦ない圧力はついに抵抗を引き起こした。研究開発部門の技術者たちは、徐氏の機嫌の悪さや達成不可能な目標スケジュールを頻繁に提示することに不満を表明し、上司に不平を言い始め、ついにこの反乱は激化し、制御不能になった。

  1993年末、徐建国氏と、技術部門出身でケイデンス設計部門の技術者から深く尊敬されていたチップ設計部門のゼネラルマネージャーであるジェームス・ソロモン氏との対立が表面化した。両者はエンジニアのレポートラインをめぐって論争を起こした。両者の対立はますます深刻化し、ついにカストロと衝突するに至った。カストロ氏は事件終了後ソロモン氏を支持し、社外から別のゼネラルマネジャーを採用した。これは徐建国に大きな打撃を与え、徐建国はこれらの矛盾はカストロのせいだと考え、退陣を決意した。

  これは生き残りに苦戦しているアークシスにとって朗報だ。中国人で構成されている企業は、技術重視や言語の難しさから営業やマーケティングが苦手などの弱点を抱えていることが多いです。営業およびマーケティングの経歴を持つ徐建国氏は、アークシスが最も必要とする候補者です。それで、プロローグで見た、徐建国がカストロに辞任するクリップがありました。

  Xu Jianguo 氏は 1994 年 3 月に Arcsys に入社しました。Arcsys の取締役会は、Xu Jianguo 氏に 1 株当たり額面 30 セントで合計 550,000 株の購入権を付与することを約束しました。これは 3 年後には約 2,000 万米ドル以上の価値になります。

  徐建国の敵への亡命はカストロにとって大きな打撃となった、なぜならアークシスにとって徐建国の重要性を真に理解していたのは彼だけだったからである。Xu のいない Arcsys は、数ある平凡な新興企業の 1 つで目立たないが、Xu Jianguo の強力な市場開拓能力、広範なユーザーネットワーク、強力な個人信用、およびそれに付随する資金力により、Arcsys は大きな可能性を秘めた企業となるでしょう。自分の力に挑戦するために。

冷戦: 熱戦前夜

 徐建国氏がケイデンスを離れアークシスに入社するという動きにより、正式にケイデンスの直接的な敵対関係が始まった。それまではアークシスは主要なライバルの一つとして挙げられるだけだったが、それ以降はアークシスがナンバーワンのライバルとなった。

  ケイデンス内部の報道によると、カストロ氏はこの件を非常に個人的なものとして受け止めたという。経営学のコースでは、業務と個人的な感情を区別することを教えられますが、会社の業務の処理に個人的な感情が混入しすぎると、多くの場合、悪い結果が始まります。カストロ氏の徐建国に対する容赦のなさは、後に両社間の交流に徐々に影響を及ぼし、最終的には両社間の個人的な憎しみとなった。ケイデンス自体は非常にオープンな環境で、エンジニアの平均勤続年数は3～4年程度で、人の出入りは比較的自由です。エンジニアがある会社から別の会社へ、場合によっては競合他社へ転職することは道徳的に間違っているとは考えられていません。しかし、徐建国のように集団を率いて戦いの途中で敵に降伏する人は実際には多くありません。カストロは公の場で徐氏を嘘つきで裏切り者と呼んだ。

  確かに、カストロ氏が心配していたのは当然だった。徐建国氏の辞任でグループBは当然崩壊し、ケイデンス社員の士気は大きな打撃を受けた。さらに恐ろしいのは、シューがアークシスに加わったことで、アークシスは自国と敵を知り、前進も後退も可能な有利な状況にあるということだ。カストロ氏は雪崩効果についても懸念している。より多くの人が徐建国から学び、アークシスに投資するだろう。アークシスが徐建国氏の任命を発表するとすぐに、取締役会はケイデンスの弁護士から、アークシスを不正競争の罪で裁判に起こすと脅迫する書簡を受け取った。一連のやり取りの後、両社の弁護士は最終的に次の暫定合意に達した。

 1. ケイデンスでの仕事の引継ぎを促進するため、徐建国の任命日は4月から7月に延期された。

 2. 1994 年中、アークシスはケイデンスの従業員を採用しないものとします。

 これにより、雪崩の発生が防止されます。これら 2 つの保証により、カストロはケイデンス内で災害対策の実行を開始しました。安福会社内の恐怖の雰囲気を復活させて、傷ついた士気を回復させ、従業員の集団的な帰属意識を強化し、顧客の信頼を再確立することができます。

  強力な財務的背景を持たなかったために訴訟を起こす勇気がなかったアークシスは最初の一息をついたが、確かに敗北を認めなかった。1995 年の直後、Arcsys はすぐに Cadence の引き抜きを開始し、最初の 1 か月以内に 9 人のエンジニアが Cadence を離れ Arcsys に加わりました。

  双方の態度により、当然のことながら冷戦は激化し続けた。

トラップ: スパイ vs. スパイ 

 1991 年に 4 人が会社を設立してから 1993 年の製品発売まで、Arcsys のソフトウェアの急速な進歩はケイデンスによって常に怪しいと考えられてきました。しかし、疑惑は疑惑であり、証拠が見つからないうちは、カストロは鷹の目のようにアークシスの一挙手一投足を監視することしかできない。  1994 年 9 月、ケイデンスのシニア ソフトウェア デザイナーであるミツル "ミッチ" イグサは、すでにソフトウェア アーキテクチャを専門とする同社の最も重要なエンジニアの 1 人であり、カストロに辞表を提出しました。

  この流れでアークシスは採用凍結期間に入り、カストロは高額の報酬を約束しながらミッチに居場所を尋ねた。ミッチはカストロが約束した社内でのいかなる地位の誘惑も断り、新しい会社を設立するか、独立したコンサルタントになるかもしれないと主張した。

  ミッチがアークシスで働かないという仕様書への署名を拒否したとき、すでに張り詰めていたカストロの神経はさらに疑念を強めた。現時点でのミッチの仕事は主に、新年に Arcsys を倒すための Cadence の新しい秘密兵器である QPlace と呼ばれる新しいレイアウト技術に関するものです。技術的なソフトウェア アーキテクチャの設計者として、ミッチはこのテクノロジーのあらゆる詳細に精通しています。このような非常に特殊な技術は、シリコンバレー全体でレイアウトと配線を行う 3 ～ 4 社のみが使用でき、アークシスは最大の買い手となります。カストロはこれもアークシスの陰謀であると感じ、これが反撃の機会であると感じた。

  ミッチがケイデンスを去った後、カストロはミッチが元々使用していたワークステーション（パーソナルコンピューターよりも強力なコンピューター）の包括的かつ詳細な調査を行うよう誰かに依頼しました。

 最終的に発見されました: ケイデンスを離れる前日、ミッキーは自宅のコンピュータに 6 MB の電子メールを送信していました。この電子メールの最大ファイルは 5.3 MB で、これはケイデンスのコア テクノロジである QPlace のソース コード ファイルでした。

  このような強力な証拠があったため、ケイデンスは地元のサンタクララ検察官に通報し、ミッチ・イグザの自宅とプライベートメールを捜索する権利を獲得した。彼らは、QPlace のすべてのソース コード、数枚のコピー、ミッチとアークシスのマネージャーとの約束の記録、アークシスからミッチへの金銭の支払いなど、探していたものを見つけました。

  この調査結果は、アークシスがケイデンスからの企業秘密の組織的かつ組織的な窃盗に関与したというカストロ氏の疑惑を裏付けた。この証拠は、アークシスがケイデンスの技術秘密を取得する意図があることを示すだけで、それがミッチの背後にある黒幕であることを証明することはできません。盗品を購入することと窃盗を組織することの間には、刑事上の大きな違いがあります。

  カストロは、次回はすべての盗品が報われることを望みながら、もう一度耐えなければならなかった。同時に、この時点からカストロは私立探偵に24時間体制でミッチを追跡するよう命じた。その後、ミッチはアークシスのマネージャーと数回会い、金銭の支払いを受け入れ、それが後に彼の犯罪の証拠となった。

  この経験から、9 人が 1995 年初めにケイデンスを去ったとき、カストロ氏はすぐに専門家にワークステーションの詳細な検査を依頼しました。彼らは同様の事件を何度も発見しました。最も重大な証拠は、所属する「byebye.tar」と呼ばれるファイルです。 Chih-Liang "Eric" Cheng 宛 このファイルには、QPlace ソース コードの最新バージョンが含まれています。QPlace は非常に新しいテクノロジーであるため、Arcsys は更新された新しいソース プログラムを入手することも期待しています。

事故：第三者による大発見 

 

 1年が経ち、あっという間に1995年半ば。Xu Jianguo 氏は Arcsys の責任者になって丸 1 年になりますが、これが彼の輝かしい瞬間であり、彼は自分の存在価値を確認しました。

1994 年 6 月から 1995 年 6 月までの間、Arcsys は前年の 170 万ドルの 7 倍にあたる 1,300 万ドルの売上を達成し、利益を上げました。さらに重要なのは、Arcsys が 1995 年 6 月に 1 株あたり 26 株の価格で公開会社になったことです。50元、アークシス社全体の価値は2億4000万。この功績は誰が評価しても称賛に満ちているだろう。カストロ氏にとって徐建国氏は、しばらくはさらにアンタッチャブルに見えた。

  ところが、カストロ氏の前に思いがけない朗報が飛び込んできた。1995年8月、カストロと徐建国の間の憎しみはすでに誰もが知っていた。サイプレスのエンジニアはカストロに電話したところ、アークシスの ArcCell からのエラー メッセージがケイデンスのソフトウェアとまったく同じであると感じ、ArcCell がケイデンスのソース プログラムの少なくとも一部を盗用したことが確認されました。

  このサイプレスのエンジニアが ArcCell をテストしていたとき、他のカラフルなソフトウェアが多すぎると、ArcCell が表示すべき色の表示に失敗し、エラー メッセージが報告される場合があることに気付きました。これは、X-windows を使用するワークステーション ソフトウェアでよく発生する問題で、異なるソフトウェアの色の割り当てが競合します。これは特別な注意に値するものではありませんが、この ArcCell エラーは次のように書かれています: "Error a: color not found in this file"。 このエラーは元々次のように書かれる予定でした: "Error: a color not found in this file"。

  ``山不转水转''，シリコンバレーは小さすぎる場所です。このサイプレスのエンジニアは当時ケイデンスの社員であり、このプログラムの作成者でしたが、この小さな文法上の誤りは実際には修正する必要がなかったため、修正することは考えられませんでした。

  二人の異なる人間が同じ場所でまったく同じ愚かな間違いを犯すことはほとんど不可能です。これは、Arcsys がケイデンスの最新テクノロジーを盗むことを意図しているだけでなく、オリジナルの ArcCell 製品自体がケイデンスの直接の侵害であることを示す最初の明確な証拠です。これでカストロ氏は検察に対し、アークシス社がケイデンスの企業秘密の窃盗に関与しただけでなく、同社のオリジナル製品自体が盗品であったと主張できるようになる。

  アークシスはこうした経緯を知らず、11月に競争力強化を目的とした検証技術会社ISSとの合併を発表し、合併後の社名はアバンティとなった。 検察はカストロの要請に同意し、アバンティ合併から1週間後の1995年12月初めにアバンティ全社に対する捜索令状を執行した。このような大規模な襲撃はシリコンバレーの歴史の中でも非常に珍しい。

法廷: 二つの巨人の間の戦場

 しかし、法律の森を持つ国である米国であっても、法廷への立ち入りはまた別の戦場であり、時間とお金を賭けた戦場です。この戦場にあるものはすべて奇妙であり、テクノロジーほど明確ではありません。Avanti 現在、その財政力でこの新たな戦争と戦う余裕がある。Avanti の強い抵抗により、刑事訴訟は非常に遅々として進まず、ケイデンスは同時に民事訴訟を開始し、Avanti がケイデンスの製品を盗んで販売したとして告訴した。

  アバンティも負けじとケイデンスを独占と不当競争で訴えた。なぜなら、ケイデンスは、裁判所が裁判と評決を終える前に Avanti ユーザーを脅迫し、Avanti ソフトウェアを放棄してケイデンスの支持に戻るよう強制したからです。 同時に、カストロはアバンティへの攻撃を開始するために株式市場の株式も売買しました。アバンティの株価は長い間混乱状態にありました。その結果、アバンティが新しい企業を買収するために新たな銀行融資が必要になったとき、アバンティ株の変動は、不信感と投機の兆候とみなされています。この行動は完全にカストロ氏の徐建国に対する個人的な憎しみによって動機付けられたもので、行き過ぎて最終的にはシリコンバレー全員の反発を招いた。

  法廷闘争は長く厳しいものであり、戦争は誰もが想像していたよりも長かった。この過程で計３人の判事が交代し、反訴や反訴があり、法廷文書の漏洩があり、ＳＥＣによる介入調査などがあった。

  2001 年、Avanti の全員に対する刑事訴訟がついに結審しました。正式な判決は7月25日に言い渡される。 検察がいくつかの告訴を取り下げ、大半の告訴を減額した後、アバンティの全員が争うことなく犯罪を認めた。6人のうち4人には1年から2年の懲役が課せられ、アバンティはケイデンスに1億9500万ドルの損害賠償を支払うよう命じられ、シリコンバレーの知的財産訴訟における企業間の賠償額としては最高額の記録を樹立した。

 6 人の被告に対する実際の量刑と罰金は次のとおりである: 社長兼 CEO の Xu Jianguo は懲役を免除され、罰金 270 万米ドル、エンジニアリング担当副社長の Stephen は懲役を免除された。 ウー氏は州刑務所に2年、罰金270万ドル、テクノロジー担当副社長の廖宇正氏は郡拘留1年、罰金270万ドル、マーケティング担当副社長の卓愛科氏は郡拘留1年、罰金10万ドル。 8,000米ドル、商業事業部長の黄金氏は懲役を免除され1万8,000米ドルの罰金、従業員の張愛科氏は364日間の郡拘留と270万米ドルの罰金を科された。

現在の状況: 5 年後の現在

 1996 年に訴訟が始まり、2001 年に判決が下されて終了してから 5 年が経過しました。

コンピューター業界にとって、5 年は新たな変化の時代です。

  過去 5 年間に、次のような発展と変化がありました。 

1. シノプシスは、遠ざかっていたものの、引き続きフロントエンド テクノロジーでリーダーシップを発揮し、現在市場の 85% を占めています。

2. Avanti は 1996 年に合法性を確保するために「クリーン ルーム」手法を使用して Arccell ソース プログラムを書き換え、新製品は Milkyway と Apollo と呼ばれました。

3. Avanti のレイアウトと配線は、タイミング駆動技術の利点により市場シェアを拡大​​し続け、2001 年までに Avanti と Cadence はそれぞれ市場の約 40% を占めるようになりました。

4. Mentor Graphics が EDA 市場に再参入します。階層型検証により検証市場といくつかの新規市場で最大のシェアを獲得します。

5. カストロは 1997 年にケイデンスを去りました。本人の言葉によれば、アバンティとの戦いで体調を崩し、C&PというEDA会社を買収した後、ようやく社長兼CEOの職責を新CEOに引き継ぎ、EDA市場から撤退することができたという。

  2001 年 7 月の判決後、アバンティは絶望の淵に立たされました。同社の取締役会のメンバーのほとんどが刑務所に収監されており、まず毎月の罰金を支払う必要がある；ケイデンスの民事訴訟はまだ進行中である；ユーザーはアバンティの将来に疑問を表明しており、その結果、売上は大幅に減少している。

  2001 年 12 月 3 日、シノプシスは予期せず Avanti を 8 億米ドルで買収すると発表しました。これはすぐにシリコンバレーの企業やエンジニアの間で議論を巻き起こしました。

  シノプシスは、その倫理的姿勢に関する一部のエンジニアからの非難に応じた。シノプシスが取得した8億ドルのうち、1億ドルは、将来的にシノプシスの経営陣に登場しないことを保証するために、元のAvanti取締役会の数人の取締役に与えられた。 シノプシスは金を使って元のアバンティの人々との関係を清算する。1億米ドルのうち、徐建国氏は個人的に約4,000万米ドルを受け取ることになる。  これは EDA 市場が一時的に落ち着いていると考えられます。

レビュー: 2 つの敗者の結果 

 2001 年までに、EDA 市場には 4 つの巨人がいると見なすことができます。売上高では、

1位の Cadence、約 15 億米ドルです。

2位はシノプシス、約9億ドル。

3位の Mentor Graphics、約7億ドル。

4位のアバンティ、約4億ドル。

  シノプシスによる Avanti の買収により、シノプシスの技術力は大幅に強化される。現在のプロセス技術が 0.18um の範囲に入ると、新しいソフトウェアを求める声がさらに高まり、今後数年で新たな戦争が始まるでしょう。

  ここ数年の紛争はケイデンスとアバンティの双方にとって不利益であると言える。ケイデンスは徐々にバックエンド市場と検証市場での独占を失いました。アバンティは訴訟の恐怖にさらされ、最終的には潰されました。一方、傍観していたシノプシスはフロントエンドの独占を強化しました。メンターは機会を捉えてください，カムバックするために。

  カストロ氏や徐建国氏にとっても悪かった。カストロは 1997 年に感情的に関与しすぎたため、不満を感じて EDA 分野を去りました。そのことがシリコンバレーの EDA コミュニティ全体との敵意を引き起こしました (Avanti 盗難事件に対する EDA コミュニティの冷淡な対応のため)。  徐建国氏は現在、ほとんどの時間を台湾で過ごしており、シリコンバレーに戻る気はないが、今やシリコンバレー業界は彼を犯罪者とみなし、個人としての信用を失っている。

  追記 

 私の仕事は EDA の CAD 分野なので、業界には比較的詳しいです。Avanti の徐建国氏のリーダーシップの物語は、かつてシリコンバレーの中国人が誇りに思っていたものであった。事件の結果が逆になるとは誰が予想したでしょうか。徐建国の行動のせいで、シリコンバレーでは中国人エンジニアに対して一定の不信感が生まれました。

  この件に関する私の個人的な意見: 私は Cadence の CellEnsamble と Avanti の ArcCell および Apollo を使用しました。Avanti には技術的にわずかな利点があります。最終判決では、裁判官は主に ArcCell のデータベース部分の盗作に焦点を当てました。明らかにこれは車のようなもので、Avanti のデジタル エンジニアの方が優れたエンジンを搭載していますが、ボディのデザインは Cadence のボディから直接コピーされています。

  商用ソフトウェアの財産権の保護と標準規格のオープン化は、業界で常に議論の絶えないテーマであり、多くのユーザーが利用の観点からの情報開示や標準策定を求める一方で、企業の強い閾値効果が課題となっている。が作成した標準により、他の企業が市場に参入することが困難になります。）が、これらの標準の進歩は遅かったです。情報の非公開は企業の利益を保護しますが、明らかに技術の交流を妨げます。

  2001 年 12 月 19 日、別の訴訟が起こされ、この話は終わりました。非常に古い EDA 会社である SiliconValley Research は、Xu Jianguo に法的通知文書を送るため、シリコンバレーのエンジニアに彼の所在を尋ねました。過去数日間、SVRは不正競争の疑いでアバンティを民事裁判所に告訴した。1990 年代初頭、SVR はレイアウトと配線の第 2 の市場でしたが、Avanti の台頭により SVR は失われました。彼らは今、正義を望んでいます。

  業界のエリートが路上のネズミのような状態に陥ってしまったことについては、一考の価値がある。

--ここまで

AnalogArtist の dbCreateRect の使い方

以下の記事で紹介した Virtuoso の吐き出した SKILL コマンドでレイヤーが dbCreateRect コマンドの集合になるのだけれど，dbCreateRectコマンドの引数がよくわからなかったので調べた．
AnalogArtist(Virtuoso)のCellViewをSKILLコマンドに変換する(dbWriteSkill)

dbCreateRect(
cellViewID, 
list(Layer purpose)
list(x1:y1 x2:y2)
)

2つ目の list 型引数は Layer 名と purpose なのだけれど，これは TechFile の Layer# でなくても Layer 名そのものでも良いみたい，後者はダブルクオートをつける．
list("BOUNDARY" "drawing")
list(100 -1)

フィッシングメール (noreply@qmailserver.com)

 フィッシング詐欺メールがやってきた．珍しく Gmail のスパムフォルダをすり抜けたのだが，日本語もちゃんとしているし，アドレス偽装をするとGmailに警告されてしまうからか，発信者の名前を本学の科研費関連のメアドにしていた．本学の教員狙い撃ちの本文になっていてなかなか立派だった．おっきい組織は狙われるんだね．科研費問い合わせのメアドも正しいし，ドメインも正しいし(うちは.ac.jpではないのだ)，赤く塗った職員さんも実在の人物みたい (よくある名前ではなくてかなり珍しい名前)．

某大学では「標的型攻撃メール訓練」と言うのをやっていたのだがたしか QTnet のドメインである事が丸わかりのお粗末な物だったのだけれど，これはぱっと見わからんかもしれん．リンク先もクアルトリクス (qualtrics.com) なので Web アンケートと言われたら信じそう．

(だからこそ「購読の解除はこちら」って表示されてしまったのだろうけれど)

23/11/07追記

ご丁寧にリマインドメールまで送ってきた．これもしかして本物，ってコト！？（そんなことありません）

英語の会計用語

英語の会計用語がごっちゃになってきた．

明細書：quotation

請求書：bill

領収書：reciept

明細付き請求書(納品書と請求明細書を兼ねる)：invoice 

請求書払い：payment on invoice

立て替え払い：payment in advance

IC Compiler でダイナミック電力とスタティック電力を見積もる (report_power)

report_power コマンドを用いる事で，STA ベースのダイナミック電力及びスタティック電力の見積もりが可能．正確な電力の見積もりにはユーザーの指定するスイッチング確率がアノテートされている必要がある．ここでは IC Compiler の report_power のオプションについてまとめる．

icc_shell> 

[-net]

[-cell]

[-only cell_or_net_list]

[-hierarchy]

[-levels level_value]

[-verbose]

[-flat]

[-exclude_boundary_nets]

[-include_input_nets]

[-analysis_effort low | medium | high]

[-nworst number]

[-sort_mode mode]

[-histogram [-exclude_leq le_val

| -exclude_geq ge_val]]

[-nosplit]

[-scenarios scenario_list]

[-groups group_list]

-net

配線による電力見積もり値を報告する．デフォルトで有効．

-cell

セルによる電力見積もり値を報告する．階層モジュールにおいて physical-only cell が含まれている場合，physical-only cell と non-physical-only cell の電力量は分けて報告される．本オプション利用時にいくつかのnon-physical-only cell は電力を報告しないことがあり，その場合N/Aと表記される．デフォルトで有効．

-only cell_or_net_list

-net もしくは -cell オプションを利用時に報告対象とするcellおよびnetを指定する．cell_or_net_list に挙げられた cell もしくは net のみが電力の報告対象となる．-net と -cell を同時に指定する場合少なくとも一つの -net と -cell が指定されなくてはならない．

-cell に physical-only-cell が指定されない限り電力報告対象とはならない．

-hierarchy

階層的なフォーマットとして，ブロック単位の電力を報告する．-levels オプションを利用する事で報告対象の階層数を指定する．-sort および -nworst オプションは無視される．

-levels level_value

報告対象の階層数を指定する．level_value は正の整数．-hierarchy オプションを使用しない場合本オプションは無視される．

-verbose

-net もしくは -cell オプションが指定された場合，cell または net のより詳細な情報を表示する．本オプション利用時は power group summary にグループ内のセル数が表示される．

-flat

階層を除去し全階層のオブジェクトに対して電力を報告する．デフォルトでは現在の階層のオブジェクトに対して電力を報告する．

-exclude_boundary_nets

現在は無効．

-include_input_nets

Primary input のスイッチング電力も報告する．デフォルトでは無効．本オプションを利用する事で net の電力が報告されるようになり，総消費電力にも影響する．cell の内部電力及びリーク電力には影響しない．

-analysis_effort low | medium | high

電力解析の精度と速度のトレードオフを取る，デフォルトはlow．本オプションはスイッチング確率の計算に影響するため，解析対象のスイッチング確率がアノテートされている場合に影響する．

-nworst number

報告をフィルタし消費電力の多い上位 number 個のみを表示する．-net もしくは -cell オプションが指定されたときのみ有効．

-sort_mode mode

-nworst オプションを利用したときのソーティング方法を指定する．-net もしくは -cell オプションが指定されたときのみ有効．

-histogram -exclude_leq le_val | -exclude_geq ge_val

電力解析結果をヒストグラムとして表示．-exclude_leq と -exclude_geq は電力のうち指定値 le_val より大きいか指定値 ge_val 小さいものを除去する．-net もしくは -cell オプションが指定されたときのみ有効．

-nosplit

ラインスプリッティングをしない．

-scenarios scenario_list

Multicorner-multimodeでのシナリオを指定する．各シナリオは個別に報告される．無効なシナリオは無視する．本オプションを指定しない場合は現在のシナリオを解析対象とする．

-groups group_list

特定のグループの電力を報告する．デフォルトではすべてのインスタンスはどれかのグループにのみ属するため，グループの電力の総和が総電力と一致する．有効なグループは以下の通り:io_pad, memory, black_box, clock_network, register, sequential, combinational.

compile コマンドと compile_ultra コマンドの違い

DesignCompiler には compile コマンドと compile_ultra コマンドがあるけれど，その違いは何か調べた．compile_ultra の方が上位互換と考えて良いみたい．

compile: DC Expert を起動する．DC Expert は HDL を最適化されたテクノロジ依存のゲートレベル記述に変換する．

compile コマンドの基本機能は以下の通り．

・GUI と CLI をサポート

・階層的コンパイルをサポート

・フルコンパイル，インクリメンタルコンパイルをサポート

・FF およびラッチを利用した順序回路の最適化

・タイミング解析

compile_ultra: DC Ultraを起動する．より高速で厳しいタイミング条件における回路の合成，また回路の QoR (Quality of Results) の向上が可能．

compile コマンドの機能にさらに以下の機能が追加されている．(専用のライセンスが必要)

・DesignWare library をサポートし，DW library の中からベストな回路構成を自動的に選択，最適化．

・Alib と呼ぶ仮想ライブラリを生成する事で，より大規模な解空間の中から面積と遅延のトレードオフを探査する事を可能にする．

・階層構造を自動的に分解することで，DesignCompiler が回路中の論理の共有を可能にしタイミングをより向上させる．

・階層構造を持つ回路の特に下層の階層境界のポートを変更を許可する．

・データパス抽出を行い算術演算をデータパスブロックに変換し，データパスジェネレータを利用する事でよりより実装を実現する．

・-retime オプションを利用すると，レジスタリタイミングを実施する．

・topological mode を利用すると，DesignCompiler は以下の処理を行う．

　・より高精度なポストレイアウトタイミング，面積，電力の見積もりを wire-load model を用いず行う．

　・マルチコア CPU を利用した論理合成の高速化

　・多電源設計をサポート

　・multicorner-multimode 最適化を実施し論理合成を高速化

・-spgをオプションを利用する事で DesignCompiler Graphical を利用に可能にする．それによって

　・physical guidance technology によって IC Compiler に対してセルの初期配置情報を提供する事でよりよい QoR を実現する．

　・論理合成時の配線混雑度を軽減する．

　・信号配線層の最適化を実現．

　・floorplan exploration によって設計者がフロアプランの修正を可能に．

DC Expert と DC Ultra の違いを挙げると，Expert は以下を実施する．

・マルチプレクサの最適化

・順序セルのマッピング

・ブール代数最適化とマッピング

・Auto-Uniquilization

・Implement Synthetic Parts

・タイミングドリブン，電力ドリブンの組み合わせ回路最適化

・遅延とリーク電流の最適化

・デザインルール考慮

・area recovery

Ultraはさらに以下を実施する．

・面積のアングルーピング

・データパスの最適化

・レジスタリタイミング

Logicool ERGO M575Sを再ペアリングさせる

M575Sをひっくり返してペアリングボタン長押し，高速点滅モードにする．その状態でWindows の「Bluetoorhまたはその他のデバイスを追加する」からペアリングすればよい．
常時点灯はペアリング中，ゆっくり点滅はペアリング相手がいないという意味らしい．

ソースはYahoo知恵袋だよ．https://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q12257600962

電力解析でのスイッチング確率の設定する (set_switching_activity)

論理合成 (DesignCompiler) や静的遅延解析 (PrimeTime) における電力計算をスイッチング確率ベースで行う場合，スイッチング確率を外部から指定するために set_switching_activity コマンドを使う．DesignCompiler における set_switching_activity コマンドのオプションや使い方をまとめる．

dc_shell> set_switching_activity

[-static_probability static_probability]

[-toggle_rate toggle_rate]

[-state_condition state_condition]

[-path_sources path_sources]

[-rise_ratio rise_ratio]

[-period period_value | -base_clock clock]

[-type object_type_list]

[-hierarchy]

[object_list]

[-verbose]

-static_probability static_probability

電圧の High(1) の確率を指定する．引数は0から1.0までの小数である．0.25を指定すると，その時間における電圧 High の確率が25%として計算する．

-toggle_rate toggle_rate

正の小数として，0->1および1->0にトグルするトグル確率を指定する．単位時間におけるトグル確率として指定する．単位時間は -period オプションを用いて指定する．時間の単位はライブラリの物を利用する．クロックがある場合は，-base_clock オプションを用いる事で指定したクロック周期に対するトグル確率として指定する．(後述の利用例を見るとよい)

-state_condition state_condition

状態遷移条件によって振る舞いが異なるピンやセルなどの状態依存トグル確率を指定する．ただしセルやピンの電力の状態遷移依存性がキャラクタライザによって適切にキャラクタライズされている必要がある．このオプションはセルのリーク電流の状態依存性などをアノテートする事を可能にする．指定する state_condition が電力テーブルの内部表現と一致している必要がある．

-path_sources path_sources

パス依存のトグル確率を計算する時にパスの source を指定する．セルの電力のパス依存性がキャラクタライズされている必要がある．指定する path_source が電力テーブルの内部表現と一致している必要がある．

-rise_ratio rise_ratio

ピンのトグル数のうち立ち上がり波形の確率を，0から1の小数で指定する．0の場合はすべての入力が立ち下がり，1の場合はすべての入力が立ち上がりとして指定する．本オプションを利用する場合はトグル確率をユーザーが指定しなくてはいけない．初期値は0.5．

-period period_value

-toggle_rate オプションで指定したトグルが発生する時間期間を指定する．時間の単位はライブラリのものである．本オプションが指定された場合，実際のトグル確率は -toggle_rate オプションで指定した数字を本オプションで割った数字となる．本オプションを明示的に指定しない場合数字として1.0が利用される．

-base_clock clock

トグル確率を計算するために利用するクロックを指定する．本オプションによってクロックが指定された場合，際のトグル確率は -toggle_rate オプションで指定した数字を本オプションで指定したクロック周期で割った数字となる．クロック周期を変更しながら複数回 report_power コマンドを実行する事も可能で，その場合トグル確率は毎回クロック周期ごとに計算しなおされる．クロックとしてワイルドカード"*"を指定する事も可能で，その場合PowerCompiler はそのデザインに関係するクロックを自動的に検出してトグル確率を計算する．

-type object_type_list

スイッチング確率を設計者が明示的に指定したい場合に，対象となるオブジェクトを指定する．オブジェクトとしては以下を選択できる．

registers (sequential cell outputs),

tristates (tristate cell outputs),

black_boxes (black box cell outputs),

inputs (input design ports or hierarchical instance pins),

outputs (output design ports or hierarchical instance pins),

inouts (inout design ports / hierarchical instance pins),

ports (design port or hierarchical instance pins),

nets (nets),

regs_on_clocks clock_list (outputs of flip-flips clocked by the clocks in

clock_list),

clock_gating_cells (clock gating cell outputs),

memory (memory cell outputs).

本オプションを特定のインスタンスに指定する事でスイッチング確率を明示的に指定する事が可能である．registers もしくは　regs_on_clock を指定した場合，順序セルの反転出力(QN)，非反転出力(Q)が共にアノテートされる．その場合非反転出力は指定のトグル確率が，反転出力は1から指定のトグル確率を引いた値がアノテートされる．regs_on_clock を対象とする場合は，クロック名のリストである clock_list 引数を指定する必要がある．registers はフリップフロップおよびラッチが対象となるが，regs_on_clock はフリップフロップのみ対象であり，クロックゲーティングも対象である．

object_list 引数は対象を明示的に指定するが，-type は対象を暗黙に指定する．オプションは相互に排他的である．

-hierarchy

-type オプションと共に利用し，指定したオブジェクトの下位の階層すべてにアノテートする．本オプションを利用しない場合は，指定したオブジェクトのトップ階層のみアノテートする．

object_list

-static_probability オプションおよび -toggle_rate オプションの対象となる，ネット，ピン，ポート，セルなどのオブジェクトのリストを指定する．

-verbose

スイッチング確率をアノテートした結果を詳細に報告する．

コマンド例

次の例では，set_switching_activity は入力ポートのトグル確率を 33 / 1320 = 0.025，静的分布確率を 0.015 に設定する．

dc_shell> set_switching_activity -toggle_rate 33 -period 1320 

-static_probability 0.015 [get_inputs]

次の例では，入力ポートのトグル確率を0.25，静的分布確率を0.015に設定する．ここではクロック CLK が関連するクロックとして定義されているので，電力を計算する時のトグル確率はクロック周期 10 を用いて実際には 0.25 / 10 = 0.025 として計算される．

dc_shell> create_clock CLK -period 10

dc_shell> set_switching_activity -toggle_rate 0.25 -base_clock CLK -static_probability 0.015 -type inputs

次の例では状態遷移依存の静的分布確率を or1 セルにアノテートする．

dc_shell> set_switching_activity -static_probability 0.10 -state_condition "A & B" [get_cell or1]

dc_shell> set_switching_activity -static_probability 0.35 -state_condition "A & ! B" [get_cell or1]

dc_shell> set_switching_activity -static_probability 0.25 -state_condition "! A & B" [get_cell or1]

dc_shell> set_switching_activity -static_probability 0.30 -state_condition "! A & ! B" [get_cell or1]

次の例では，パス依存トグル確率を xor1 セルの Y 出力にアノテートする． 

dc_shell> set_switching_activity -toggle_rate 0.022 [get_pin xor1/Y]

dc_shell> set_switching_activity -toggle_rate 0.020 -path "A" [get_pin xor1/Y]

dc_shell> set_switching_activity -toggle_rate 0.002 -path "B" [get_pin xor1/Y]

次の例では現在のデザインにおけるすべての順序セルのアノテートされたスイッチング条件を除去する．

dc_shell> set_switching_activity -type registers -hierarchy

次の例ではクロック clk1 と clk2 を使うすべてのレジスタのスイッチング確率をアノテートする．

dc_shell> set_switching_activity -toggle_rate 0.1 -static_probability 0.5 -type {regs_on_clock {clk1 clk2}} -hierarchy

次の例では related_clock 属性としてワイルドカード"*" を指定したオブジェクトに対し，すべての入力にトグル確率0.2を，静的分布確率0.5を，アノテートする．電力解析結果は report_power コマンドで表示される．関連するクロックは自動的に推論され，トグル確率0.2がそれぞれのクロックの周期に会わせて相対的にスケールされる．

dc_shell> set_switching_activity -toggle_rate 0.2 -static_probability 0.5 -base_clock "*" -type inputs

dc_shell> report_power

研究費と機材とその移管の話

大学教員として活動するためには，様々な研究費を獲得する努力と，必要に応じて大学のポストを転々とせざるを得ない事がある(その証拠に，運営費交付金は右肩下がりだし，任期付きポストも増やすインセンティブがあると聞く)．結果的に研究資金と研究機材を抱えて大学間を右往左往する羽目になるのだが，大学や研究契約内容によっては研究資金や研究機材の移管ができず置いて行かざるを得ないケースがある．

正確なことはわかっていないのだが，「研究契約の主体」と「資金や機材の寄付の可否」がポイントなのだろうか．

あくまで私の事例だが，

最初の引っ越し：国立大→私立大

経費：科研費は移管．共同研究費は移管できなかったと思う

機材：科研費，学内経費，共同研究費すべてを「寄付」と言う形で移管

次の引っ越し：私立大→私立大

経費：科研費は移管．共同研究費は移管できず，残るボス先生に移管

機材：科研費のみ移管．学内経費，共同研究費は移管できず(事務的には機材は「私がいた部屋の備品」で教員に所属していないので移管という考えが無い)

面白かったのは，国立大→私立大で移管した機材も，科研費と学内経費の分は移管できるが，共同研究費は移管できなかった事．受け入れはできるが持ち出しはできないの？？！？

将来の引っ越し：私立大→？？？

経費：公的資金は移管できる．共同研究費は移管できない．

機材：公的資金は移管できる．共同研究費は移管できない．

とのことらしい．

任期付きポストでも研究費取って来いよでもいいのだが，任期切れたら持ち出しできませんは勘弁してほしいものよ．

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

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

スペック

・男

・集積回路の物理設計よりのCAD屋．回路設計もするよ

・応募時の業績：論文誌6本，レター3本，国際会議20本，その他

・科研費は若手x2，共同研究x2，分担がいくつか

・任期5年再任有りの3年目

こだわったところ

・集積回路設計特にCADに関わりたい

・PIは，私が知っている教員か，外部資金などを取っている教員を希望した

・お金は取ってこれるので地方国立大とかがいいのでは

・理想は関西圏だけれど西日本ならいいかな

・2年間ぐらいかけてのんびり就活する予定だった

2020/? 公立大

・先方のPIから「うちに来ない？」と連絡がきた

・以前も公募があったが学会で「アナログ回路の人が欲しいんだよね」と言われたので応募を止めた所だった

・任期付き助教?

・2018年の公募で事前にお断りされて，転職直後に応募してよと言われても…．

2021/8 私立大

・教授，准教授，もしくはテニュア准教授，「若干名」

・分野は集積回路全般なので問題なさそう

・前回就活時，学会で「数年後公募あるから応募したら？」と情報をもらっていたので応募

・応募後2週間ほどでお祈りメール

・落ちた理由は業績が足りないとの事 (事後に指摘された)

2021/10 私立大

・講師(任期付)，2年+1年x3のようだ．5年が上限

・分野は集積回路全般なので問題なさそう

・英語講義を6コマ担当するとのこと…．研究できるのか?

・応募2週間後に面接，ボコボコにされる

・面接2週間後に内々定

2021/10 国立大

・准教授

・分野は集積回路全般，だけど本命は超伝導とか光コンピューティングみたい

・書類出そうと思っていたが，講師が先に決まってしまったので見送った

感想

・意外に教育歴は見られる？面接で「今大学で教えている科目の演習科目やってほしいな」と言われた

・でも「演習科目やってほしいな」は別の先生から「いらん」と言われるなど

・現在の担当科目名だけでなく内容も書いた方が面接の時の議論のネタになるからよいみたい

・JRecinの過去ログは消えるのでPDFは保存しておくべき

・(本公募ではなく)知り合いが受けた公募では，JRecinでは「再任あり」とあったが面接では「再任無し」になったケースがあったと聞いた，で蹴ったらしい

・上げるつもりはないので転職を考えておきなさいと言われています，厳しい(>_<)，が業績ないもんな

・准教授ではなく講師(任期付)なのは察してください．着任してから理解したけれどほぼ助教だこれ…

過去の公募戦線ログ

とある博士学生の助教公募戦線記録

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

ECS LIVAX2-120 に Linux Mint を入れてVNCサーバーにする

 ただの日記です．タイトル通り，ECS LIVAX2-120 に Linux Mint (XFCE) を入れてVNCサーバーにします．スペックは以下の通り．

・Celeron N3050(1.6GHz、ビデオ機能内蔵)

・DDR3L 4GB

・SSD 128GB

・HDMI 1.4a(30Hz 4K出力対応)、ミニD-Sub15ピン

・Gigabit Ethernet

・IEEE 802.11ac/a/b/g/n無線LAN、Bluetooth 4.0(ただし使えていない)

・USB 3.0×3

元々は Cent OS 7 でこれは後述するネットワークの問題はなかったのだが，Gnome があまりに重たすぎるので軽量めの Linux Mint に移行した．

Windows PC に VNC Viewer を入れて，ポートフォワードで Server に接続する．ネットワーク構成は以下のような感じ．

Windows PC (VNC Viewer)

↓ [ssh]

Linux Mint (VNC Server)

↓ [ssh -X]

計算機サーバー群

直接計算機サーバーに VNC を立ち上げないのは，サーバーにVNCのポートを開けるのが怖い事とサーバーごとに個別に VNC Server を立ち上げなくてすむ利点がある．

Linux Mint 21.1 をダウンロードし，Rufus でブート USB を作成．インストールは普通に実施する．VNC サーバーにするために SSH (oepnssl) と VNC (tigerVNC) をインストールするのだが， 大学のネットワークが複雑すぎてインターネットに到達できない．仕方なく Buffalo の USB WiFi ドングル (WI-U2-433DMS/N) をさして携帯テザリングしようと思ったのだが，ドライバがなくて WiFi が使えない．なので以下のサイトを参考に，Windows マシンで Github のドライバのデータをダウンロードして，Linux Mint 上でコンパイルした．

https://hirotaka-hachiya.hatenablog.com/entry/2020/12/14/184422

WiFi テザリングができるようになったら，SSH と VNC を「ソフトウエアの管理」からインストールする．アプリが入ればインターネットは不要なので， WiFi は消えてしまって構わない．

VNC Server を起動するも X が正常に立ち上がらない．~/.vnc/xstartup を以下のように編集して VNC を再起動する．

def 

export XKL_XMODMUP_DISABLE=1

unset SESSION_MANAGER

unset DBUS_SESSION_BUS_ADDRESS

/etc/X11/Xsession

/usr/bin/startxfce4 &

/usr/bin/xfce4-session &

/usr/bin/xfce4-pannel &

/usr/bin/xfce4-terminal &

VNC Server の起動はサービスに登録するのがスマートだろうが，過去の癖から手動で起動するようにしている．以下のエイリアスを作成している．Virtuoso を起動するため "-depth 24" で色解像度 24bit を指定する．

alias vncserver4k="vncserver -geometry 3800x2000 -depth 24"

すべての準備がすめば Windows PC で以下のバッチファイルを作成して，ポートフォワードと VNC Cliant を起動する．

start /b cmd /c "C:\PROGRA~1\PuTTY\putty.exe -load liva -l [userID] -pw [userPW]"

timeout 30

start /b cmd /c "C:\PROGRA~1\UVNCBV~1\UltraVNC\vncviewer.exe -connect 127.0.0.1::5901 -nocursorshape -notoolbar -noauto -password [userPW] -8greycolors"

timeout は SSH セッションが成立するのに時間がかかるが予測がつかないので少し長め，接続を確認したら手動でスペースを打って次に進めている．パスワード平文で保存しているのでセキュリティ的には危ないかもしれない．

Celeron N3050 は今となってはゴミかもしれないが，シンクライアント的に使うにはまあ十分かなぁ．4KのVNCもなんとか使えてる．ただしCADのログファイルがガンガン Terminal に出力されると途端にカクカクし始めるけれど．．．

THE RIGHT WORD fraction, fragment, part, piece, portion, section, segment

 よくわからなくなったので調べた．New Oxford American Dictionaly からです．

Fragment: 破損が発生したことを示唆し (fragments of pottery)，多くの場合ガラスや陶器などの脆い物質を指す．

Segment: 全体が自然または既存の分割線に沿って分離されていることを示唆する (a segment of an orange). Section は，ある全体を形成するための，明確に分離された一方で他の部分と隣接する一部を示唆する (section of bookcase) ．

Fraction: 通常、実質的ではないが明確に線引きされた部分を示唆する (a fraction of her income) ．Portion は誰かに割り当てられた部分を示す (her portion of program) ．

Piece: 全体から分離したどのような一部にも利用でき，最も良く使われる．

特に意図がなければ Piece を使えば良さそうだ．

近隣国の○○○○的組織

・Taiwan Semiconductor Research Institute (TSRI)

https://www.tsri.org.tw/

台湾の先生が使っているようだ．先生は「CICに質問しなさい」と学生に指導しているので，質問やサポートを受け付けてくれるのかな，うらやましい．

中身はよくわかっていませんが，台湾はクラウドでチップ試作できるのでしょうか．個々のラボで環境整備しなくて良いのでいいな．

https://www.tsri.org.tw/tw/commonPage.jsp?kindId=D0010

どんなEDAがあってどうやって使うとか親切な説明があって涙がでます．参考にさせてもらおう．TSRI ってNational Chip Implementation Center (CIC) が元なのかな，

http://www.cic.org.tw

を選ぶとTSRIにリダイレクトされますね．

・IC Design Education Center (IDEC)

https://www.idec.or.kr
「韓国の半導体産業の競争力(한국 반도체산업의 경쟁력)」だそうです．EDAの一覧がカタログになってます．ちゃんとまとまっててめっちゃいい．
http://doc.idec.or.kr/eunjuseok/EDA_Tool_%EC%86%8C%EA%B0%9C%EC%9E%90%EB%A3%8C1.pdf

日本の先生も頑張って環境構築のドキュメント作成してくださっているけれど，こういう網羅的な資料があると「使ってみよう」って思う気がするんだけどな．(でも未だにINCISIVとか書いてあるし無理か．．．)

中国に同じような組織があるのかはわからなかった．留学生が言うには ASIC 向けの EDA を大学で使うのは難しく FPGA 実装が主流だそうだ．

LTSpiceでMOSFETの動作点を解析する

 LTSpice でも .op で MOSFET の動作点を表示できる．制御記述 .op のみを記述し( .tran は書かない)，"Run" を押すとシミュレーションが走る．まず各ノードの電圧電流が表示がポップアップされるが閉じておく．次に "View" -> "SPICE Error log"を選択すると，MOSFET の動作点解析結果を見ることができる．

ICC の配線を早めに諦めさせる (set_route_opt_strategy)

IC Compiler で配置配線を行うと IC Compiler は設計が収束するまでブロック分割などの配線ストラテジを変えながら配線を何度もトライするが，設計初期の見積もりなどでは試行錯誤の回数を減らして CPU 占有時間を減らしたい．配線 (route_opt) の戦略を変えるには，set_route_opt_strategy コマンドがあり，うち2つのオプションにて配線の試行回数を制御できる．

set_route_opt_strategy --route_drc_threshold [NUM1] --search_repair_loops [NUM2]

--search_repair_loops オプションは，配線時に Violation が出たときに，配線戦略(ブロック分割など) を変えて再度配線を行う試行回数の数を制御する．NUM2 は0から500の整数で，その初期値は classic router では15，zroute では10．

--route_drc_threshold オプションは，詳細配線時にどれだけ Violation が出たら配線そのものを諦めるかという閾値．初期値は3000．-1を指定すると，IC Compiler は(DRC Thresholdを?)チェックせず無制限に詳細配線の再実行を行う．

ちなみに(?)，Synopsys IC Compiler は命令するとそれが理不尽でも延々と頑張る(そしてえらく時間がかかってようやく諦める)印象で，Cadence SoC Encounter はいくら命令しても一向に言うことを聞かない印象である．Innovusは知りません．

OCV，AOCV，POCV，LVF

あまりよくわかっていないので(今更)まとめた．いずれもチップ内ばらつきを取り扱うための手法．

Static Timing Analysis (STA)

STAではパス中の論理セルの遅延を積算していく事で回路遅延を求めていく．以下の図の右側の Flip-Flopの セットアップ制約 T_setup は

T_setup > T_clk - ( T_launch - T_capture )

である．ここで T_clk はクロック周期，T_lauch はlauch path 遅延(データパス遅延)，T_capture は capture path 遅延(クロックパス遅延)である．なお共通項は取り除かれる(Common Path Pessimism Removal).

On-Chip Variation (OCV)

OCV では derate factor を用いて回路遅延の平均からのずれを表現する．例えば回路中の論理ゲートが 3σ 遅延で ±5% ばらつくとする．OCV では，オンチップばらつきによって T_launch が 5% 悪化し，T_capture が 5% 改善すると考える．するとセットアップ制約は

T_setup > T_clk - ( T_launch * 1.05 - T_capture * 0.95)

と悪化する．各セルが Nσ でどの程度ばらつくか予測がつけばよいため，極端な話 Monte-Carlo シミュレーションは不要かもしれない．ただし段数効果が入っていないこの解析結果はかなり悲観的である．

Advanced OCV (AOCV)

AOCV (a.k.a SBOCV: Stage Based OCV) ではパスの段数と距離をパラメータとして持つ．パスの段数はランダムばらつきの影響力に寄与し，段数が多いほどばらつきは減る．距離はシステマティックばらつきの影響力に寄与し，距離が長いほどシステマティックばらつきが多い．この二つのパラメータを得るために，キャラクタライザは同じ論理ゲートのチェーンを作成し，Montecalro Simulation もしくは感度シミュレーションを用いてばらつきモデルを作成する．ばらつきモデルは，段数あたりの derate factor のテーブルで，early (改善方向)と late (悪化方向) の2つを持つ．

具体的には異なる論理段数のチェーンに対して

[early derate factor] = ([nom. delay] - 3σ)/ [nom. delay]

[late derate factor]  = ([nom. delay] + 3σ)/ [nom. delay]

で各 derate factor を計算し，それをテーブルとして

object_type: lib_cell

delay_type: cell

rf_type: rise

object_spec: */INV

derate_type: early

depth: 1 2 3 4 5

distance: 0

table: 0.87 0.91 0.92 0.93 0.94

object_type: lib_cell

delay_type: cell

rf_type: rise

object_spec: */INV

rf_type: rise

derate_type: late

depth: 1 2 3 4 5

distance: 0

table: 1.17 1.12 1.09 1.08 1.07

の様に保持する．(fallも同様)

パス遅延の計算は，通常の STA 同様各論理ゲート遅延の和を取れば良い．段数効果を考慮するため OCV に対してより現実的であるが，同一の論理ゲートのチェーンで評価しているため，論理回路の遅延評価には不向きである．そのためクロックの様な同じ論理素子のチェーンの評価で使われる．距離の情報も必要なので，ネットリストから各素子の X-Y 座標のデータを取り込む必要がある．

Liberty Variation Format (LVF)

POCV: Parametric OCV (a.k.a SOCV: Statistical OCV) は derate factor そのものを持つのでは無く，POCV Coefficient と呼ぶばらつきの相対値 (σ/μ) を利用する．プロセスパラメータを Sweep して POCV Coefficient を計算する．そのため以下のような POCV モデルが生成される．

ocvm_type: pocvm

object_type: lib_cell

delay_type: cell

derate_type: early

rf_type: rise

object_spec: */INV_coefficient: 0.04

coefficient: 0.04

ocvm_type: pocvm

object_type: lib_cell

delay_type: cell

derate_type: late

rf_type: rise

object_spec: */INV_coefficient: 0.04

coefficient: 0.04

POCV の結果は，個々のセルごとのばらつき情報として出力するか， LVF (Liberty Variation Format) として出力する．slew-load 依存伝搬遅延，遷移遅延，slew-slew 依存ばらつきをモデル化している．LVF では μ に加えて σ のテーブルを持つ．

遅延の計算では，各論理ゲートを通過するごとに以下の遅延 (Incr) を足し合わせていく．

Incr = Mean ± K * (Sensit_cell)^2/ (Sensit_slack)

ここで，Mean はパス中の一つの論理ゲートの遅延の平均，K はtiming_pocvm_report_sigma という変数(KσのK?)，Sensit_cell は論理ゲートの 1σ ばらつき，Sensit_slack はパス Slack の 1σ ばらつき，と思われる．

(PrimeTime の説明だが，これ合ってるのか？)

こちらの Youtube動画 だともうちょっとシンプルに

Total_delay = (μ_1+ ...+μ_n) + sqrt(σ^2_1+...+σ^2_n) * N

であった．(NはNσ?)

この LVF は遅延の平均(μ)と標準偏差(σ)を利用しているので，分布が正規分布である事を想定しており，Regular-LVF と呼ばれる．さらに微細なプロセスではパス分布がガウス分布に従わないので，平均(μ)と標準偏差(σ)に加え，平均のシフト量，スキュー，尖度を考慮した，Moment-Based LVF を利用する必要があるそうだ．

なんかここまで来ると SSTA と変わらなくない？と思ってしまう．SSTA と違いパス単位の検証しかせず Max, Min 演算をしないのがミソなのかな．．．

PrimeTime の report_timing オプション

オプションが多すぎてよくわかっていないのでまとめた．

pt_shell> report_timing [options1] [option2] ...

-from from_list

特定のパス，ピン，セルおよびインスタンスから始まるパスを解析する時に from_list にそれらを指定する．もしくはクロックを指定するとそのクロックから始まるパスを解析する．

-rise_from rise_from_list

-from オプションと同様だが，立ち上がり波形から始まる場合に解析する．クロックを指定する場合，クロック立ち上がり条件から解析する．

-fall_from fall_from_list

-rise オプションと同様．

-to to_list

特定のパス，ピン，セルおよびインスタンスに向かうパスを解析する時に to_list にそれらを指定する．もしくはクロックを指定するとそのクロックから始まるパスを解析する．

PrimeTime の性質上，-to オプションの方が -from オプションよりも効率的なので，end-point 指向のタイミング解析(-to)の方が，start-point 指向のタイミング解析より性能がよい．

-rise_to rise_to_list

-to オプションと同様だが，立ち上がり波形で終わる場合に解析する．クロックを指定する場合，endpoint がクロック立ち上がり波形にキャプチャされる場合を解析する．

-fall_to fall_to_list

-rise_to オプションと同様．

-through through_list

特定のパス，ピン，セルおよびインスタンスを通過する波形を解析する．本オプションは複数回指定する事が可能で，指定されたすべての through_list を通過する波形を解析する．例えば，A1 を通過し，B1 もしくは B2 を通過し，C1 を通過し，D1 に到達するパスを解析する場合は以下のように指定する．

pt_shell> report_timing -from A1 -through {B1 B2} -through C1 -to D1

-rise_through rise_through_list

-trought オプションと同様だが，立ち上がり波形である場合を解析する．

-fall_through fall_through_list

-rise_through オプションと同様．

-exclude exclude_list

特定のパス，ピン，セルおよびインスタンスを通過する波形を除外する．データパスが対象でクロックは非対称．-exclude オプションを利用すると非常に解析時間がかかるので，-from -through オプションなどを併用し探査空間を減らすと良い．-exclude オプションは -trace_latch_borrow オプションで考慮するタイムボロウィングをチェックしない．

-rise_exclude rise_exclude_list

-exclude オプションと同じだが，立ち上がり波形の場合を除外．

-fall_exclude fall_exclude_list

-rise_exclude オプションと同様．(man は rising と書いているが falling の間違いだろう)

-delay_type delay_type

遅延解析の対象を指定する．取り得る delay_type は以下の通り．

max (default) : 最大遅延(セットアップ制約)

min : 最小遅延(ホールド制約)

max_min : 最大遅延，最小遅延両方．先に最小遅延を報告し，次に最大遅延を報告

max_rise : 最大遅延のうち立ち上がり波形で endpoint に到達するもの

max_fall : 最大遅延のうち立ち下がり波形で endpoint に到達するもの

min_rise : 最小遅延のうち立ち上がり波形で endpoint に到達するもの

min_fall : 最小遅延のうち立ち下がり波形で endpoint に到達するもの

-nworst paths_per_endpoint

各 endpoint に到達する最悪遅延パスの数．デフォルトは1，最大2000000．1以上を指定するとツールは以下の処理を行う．

-max_path が指定されていない場合は -max_path paths_per_endpoint を明示的に設定し，一つの endpoint に向かう複数パスの解析結果を報告する．

-slack_lesser_than もしくは -slack_greater_than が指定されていない場合は-slack_lesser_than 0 を明示的に指定し，タイミング違反するパスのみを報告する．

-max_paths max_path_count

報告するパス数を指定する．デフォルトは1．最大2000000．1以上を指定すると

ツールは以下の処理を行う．

-slack_lesser_than もしくは -slack_greater_than が指定されていない場合は-slack_lesser_than 0 を明示的に指定し，タイミング違反するパスのみを報告する．

-nworst

本報告対象となる各 endpoint に向かうパス数を変える．なお -max_path は報告する総パス数を変更する．-max_paths のオプションは -nworst のオプションより同じか大きくなくてはいけない．デフォルトでは両者は同じになる．

-group group_name

group_name に属するパスのみ報告する．group_name は create_clock コマンドか，group_path コマンドで生成された物である．-group オプションを利用しない場合は全パスを解析する．

-unique_pins

指定されたピンリストに該当する最悪遅延パスのみ報告し，同じピンリストを通過する(より違反の小さい)他のパスを報告しない．いわゆる "non-unate" である XOR 論理は立ち上がり・立ち下がり波形の候補が大量にあるため，本オプションを"non-unate" 論理に適用するとタイミング違反の報告数を劇的に減らす事ができる．

-slack_greater_than minimum_slack

minimum_slack より大きい Slack を持つパスのみ報告する．-slack_lesser_than と併用すると，指定する範囲の Skack を持つパスのみ抽出する事もできる．

-slack_lesser_than maximum_slack

mnaximum_slack より小さい Slack を持つパスのみ報告する．デフォルトは0．-nworst もしくは -max_paths で1より大きい値を指定する場合，Negative Slack であるすべてのパスを解析する．

-ignore_register_feedback feedback_slack_cutoff

同じレジスタの入出力をつなぐ非反転ループを解析対象から外す．この場合，入力から出力，出力から入力の値が共に同一(非反転)である必要がある．最大遅延，最小遅延共に適用される．Slack の値が feedback_slack_cutoff より小さいパスのみが本オプションによって解析から除外される．

-report_ignored_register_feedback

-ignore_register_feedbackで除外されたパスリストを報告する．

-include_hierarchical_pins

タイミングリポートに階層をまたいだ点，パス内のスタセルのピンの情報を載せる．ドキュメント化支援の機能で，各点は遅延ゼロとして報告される．

-trace_latch_borrow

トランスペアレントラッチから始まるパスの遅延を報告する．特にタイムボロウィングしている場合，本オプションを利用する事でタイムボロウィングしているパスと対象のラッチ，非タイムボロウィングパスと順序セルのループなどを評価する事ができる．

-trace_latch_forward

トランスペアレントラッチの入力 D ピンで終わるパス遅延を報告する．ラッチ遅延解析機能を有効にし(timing_enable_through_paths true)かつ対象のラッチの入力が required time によって制約されている場合，本制約に必要となった入力 D ピンに関与するパス中のFanout が報告される．(理解に自信なし)

-pba_mode none | path | exhaustive | ml_exhaustive

パスベース解析モードを指定する．

none (default): パスベース解析をせず，通常のグラフベース解析を行う．最速．

path : グラフベース解析によってまとめられたパスに対してパスベース解析を行う．より高精度な解析が可能．pba_path_mode_sort_by_gba_slack 変数を変更する事でまとめるパス数(?)を変更可能．

exhaustive : より徹底したパスベース解析を行い，真のワーストケースパスを見つける．最も高精度だが計算負荷が高い．

ml_exhaustive : 機械学習ベースの exhaustive パスベース解析．精度と速度のトレードオフを見つける．

パスベース解析を利用するとパス間の分離を考慮する事が可能となり，クロストークや CRPR (Clock Reconvergence Pessimism Removal) のあり得ないパスを解析から除外できる．そのためこれらの解析の悲観性を改善する事が可能．

-start_end_type from_to_type

報告内容を以下の選択肢に指定する事ができる．

reg_to_reg : レジスタ間

reg_to_out : レジスタからマクロ出力

in_to_reg : マクロ入力からレジスタ

in_to_out : マクロ入力からマクロ出力

マクロの双方向入出力は in，out 共に対象となる．

-normalized_slack

実際の Slack ではなく，許容される最大遅延(クロック周期)で正規化した Slack を用いて報告する．本オプションは timing_enable_normalized_slack 変数を true にした場合に有効．

-start_end_pair

各 Startpoint から Endpoint のペアに対して，最悪となるパスを表示する．-slack_lesser_thanを併用している場合は，-slack_lesser_thanで指定した値より悪いパスを表示する．本オプションを利用すると Default の振る舞い(回路中の最悪パスのみを表示)とは異なり，すべての各 Startpoint から Endpoint のペアに対して遅延解析結果を示すため計算量及びレポートは膨大となる(なお DesignCompiler や IC Compiler 内部の STA エンジンとは異なる振る舞いを示す)．解析対象を制限し実行時間とログを減らすために -slack_lesser_than や，-from -to を併用する事が望ましい．また本オプションを利用する場合は -nworst, -max_paths, -unique_pins, -slack_greater_than, -ignore_register_feedback オプションは併用できない．

-cover_design

違反している各ピンに対して最悪パス遅延を表示する．「違反」とは，Slack が負か，-slack_lesser_than より悪い事を示す．本オプションは以下のオプションとは併用できない．

-nworst

-max_paths

-unique_pins,

-ignore_register_feedback

-report_ignored_register_feedback

-start_end_pair

-pba_mode exhaustive

path_collection

-cover_through through_list

throu_list に定義したピン，ポート，セルインスタンス，ネットを通過する最悪違反パスを一つ報告する．Slack が負か，-slack_lesser_than より悪い事を示す．

以下のオプションとは併用できない．

-nworst

-max_paths

-through / -rise_through / -fall_through

-exclude / -rise_exclude / -fall_exclude

-unique_pins

-ignore_register_feedback

-report_ignored_register_feedback

-start_end_pair

-pba_mode exhaustive

path_collection

-dont_merge_duplicates

PrimeTime が -multi_scenario オプションで起動している時に，複数シナリオ間でパスをマージしたり複製する事を防ぐ．本オプションを利用しない (Default) では，複数シナリオで同じパスが報告対象となった場合，最もクリティカルな物を PrimeTime は報告する．本オプションを利用するとパスのマージや複製を行わず，同じパスであっても報告をする．

-pre_commands pre_command_string

セミコロンで区切った PrimeTime のコマンドを command_string に指定する事で，

-multi_senario オプションにおいて report_timing を実行する前にworker (slave) にcommand_list を渡すことができる．

-post_commands post_command_string

-pre_commands と似ているが，post_command_string は report_timing 実行後に実行される．

-path_type format

タイミングリポートに示すパスの種類を選択する．format は以下の通り．

summary : パスの startpoint，endpoint, slack を表示

end : パスの endpoint, パス遅延，requred time, slack を表示

short : Defaultの様にすべてを表示するが，startpoint から endpoint へ向かう中間ノードは表示しない．

full (default): すべての情報を表示する．すなわちすべての中間ノードにおける遅延の加算値と積算値，また clock の launch と capture time， データの required time, slackを表示する．

full_clock : full に加え，クロック源 から launch, capture までのクロックパスの情報も表示する．

full_clock_expand : full_clock に加え， primary clock から generated clock までのパスも表示する．generated clock が無い場合は full_clock と同じ．

-input_pins

タイミングパスのすべての入力ピン，出力ピンを表示．その結果，ゲート遅延と配線遅延が分かれて報告される．使わない場合(Default)は出力ピンのみ表示．

-nets

タイミングパス中の配線を表示．使わない場合(Default)は表示しない．

-nosplit

レポート分割しない．

-transition_time

遷移遅延(slew)を報告する．

-capacitance

パスの総キャパシタンス容量を報告する．report_capacitance_use_ccs_receiver_model 変数の設によって，CCS receiver容量(default) か，ランプ容量を選択できる．

-significant_digits digits

報告値の小数点を 0 から 13 の間で指定する．初期値は report_default_significant_digits 変数で制御でき，その Default は2．

-crosstalk_delta

"Delta" の列として，各セルの入力ピンにクロストークデルタ遅延を表示する．解析は自動的に -input_pins となる．Delta 遅延はクロストークシグナルインテグリティ解析を実行した場合か，set_annotated_delay -delta_only もしくは set_annotated_transition -delta_only を指定した場合に計算される．本オプションは解析結果を報告に加えるだけで，解析そのものは前出のコマンドであらかじめ実行しておく．Delta 遷移遅延は -transition_time をつけると表示する．

-derate

"Derate"の列として，ディレーティング係数(derating factors)をセルと配線に対して表示する．Defaultでは表示しない．解析は自動的に -input_pins となる．-path_type full_clock_expanded オプションを併用すると，ディレーティングがパス全体に及ぼす影響を示す事ができる．

-variation

"Mean" と "Sensit" の列として，parametric on-chip variation (POCV)の情報を表示する．POCV 解析のためには timing_pocvm_enable_analysis 変数を true にしておく必要がある．

-exceptions dominant | overridden | all

ユーザー定義のタイミング例外を報告する．

dominant では支配的なタイミング例外を報告する．例えば false path，最大及び最小遅延，マルチサイクルパスなど．

overriden では， dominant で上書きされたタイミング例外を報告する．

制約の無い (unconstrained) パスやその理由は，timing_report_unconstrained_paths 変数が true の場合にすべての解析で表示される．

get_timing_paths オプションのパスグループに観測対象のパスをあらかじめ指定する事で対象の観測対象に絞って報告できる．

-voltage

"Voltage" 列として，各素子の動作電圧を表示する．

-supply_net_group

"Supply-Net-Group " 列として，パス中の各素子の電源グループ名や電源配線名を示す．電源グループ名が未定義の場合は "unconnected" と表示される．電源配線名が定義されているが電源グループが未定義の場合，電源配線名の先頭に "n" が付与される．

-physical

"Location" 列として，各素子の X-Y 座標を報告する．事前に read_parasitics コマンドの実行と read_parasitics_load_locations 変数を true にする必要がある．座標情報が無い場合は"unplaced"と表示する．

-sort_by group | slack

報告するパスをグループ(default)もしくは slack でソートする．

-tag_paths_filtered_by_pba tag_name

-pba_mode を利用している場合，本オプションを利用する事で path-based 解析ですべてのパスをタギングし，次の path-based 解析で同じタグ名を利用する．path-based 解析後の get_timing_paths もしくは  report_timing に -exclude オプションと共にタグ名を指定すると，指定したパスを解析から外す事ができる．

-imsa_session session_name

eco_update_path_timing を有効にし IMSA モードの時のみ有効．Default では IMSA モード はメモリ内のすべてのパスを解析するが，本オプションを使うと特定のセッションのみ解析する．

path_collection

報告するパスを指定する．例えば変数 mypaths に [get_timing_paths ...]で指定する．

-dvfs_scenarios dvfs_scenarios_list

解析する DVFS シナリオの一覧を指定する．本オプションは SMVA 解析でのみ有効．DVFSシナリオは get_dvfs_scenarios コマンドで生成する．

-domain_crossing domain_crossing_mode | all | only_crossing | exclude_crossing

domain crossing report モードを指定する．Default は all．特定のモードに

指定されているパスのみを示す．all を指定すると，ドメインを横断するパス，ドメイン内の

パスすべてを考慮する．only_crossing ではドメインを横断するパスのみを報告し，exclude_crossing ではドメイン内のパスの未報告する．SMVA 解析でのみ有効．

-yield

設計歩留まりに貢献するパスの一覧を生成する．歩留まりに貢献しないパスを除外し，続く get_timing_yield コマンドにおいてパラメトリック歩留まり分析に活用される．本オプションは -pba_mode exhaustive オプションでのみ有効．本オプションは get_timing_paths  および get_timing_yield 実行時の実行時間とメモリ利用量を劇的に軽減できるため，歩留まり解析では常に使うと良い．

PrimeTime で Positive Slack Path を表示する(report_timing -slack_lesser_than)

PrimeTime で STA の結果を表示するには report_timing を使うが，標準では Negative Slack しか表示せず，すべてタイミングを満たしている場合は解析結果が表示されないようだ．表示する閾値は -slack_lesser_than オプションで制御できるので，Positive Slack を表示するには -slack_lesser_than オプションに正の値を指定する(デフォルトは0，単位は.libのもの)．

report_timing -delay_type min -slack_lesser_than 10