最近思うこと
徒然ないままに書いていきます。
とある先輩の話
大学の研究室の先輩から、日本支社からUS本社に転籍したよ。と言うメールを頂きました。普通の日本人の感覚では、「あぁ、本社に行っただけか」と言うもののような気がしますが、実際は資本関係があれど、ほぼ別会社なので、大きな転職&決断だと思います。
この先輩のスゴイところは、大人しい方なのですが、自分で行動を起こせること。
元々、大学で今流行のTSVを使った3次元集積化システムのプロセス開発をやっていた方です。とある日本支社に入ってからは、異なった仕事をやっていたそうなのですが、あるとき、このままではいけないと一念発起して、自分でプロジェクトをイチから立ち上げます。これは、日本の大企業にお勤めの方からすると、非常に困難なことであることは理解していただけるのではないでしょうか？
おそらく、その時は20代後半だったはずです。その若輩者が自分で企画書を作り、会社にプレゼンし、納得させる。後で聞いた話では、やはり日本支社はその時には思ったように動かなかったようです。そのとき、彼は何をしたか。
日本支社ではできない、と判断した先輩は、US本社の研究所に行って、そこで興味ある研究者たちを巻き込んでプロジェクトにしてしまいます。確か、1年ほどUSにはいたと思います。その成果を持って、日本支社を説得させたようです。
その後、ASETドリームチッププロジェクトで私は先輩と再会することになるのです。その先輩が、つい最近、さらに研究を進めるために、US本社に転職しました。
とある自分の話
私は今年度から自社に戻って、仕事をしております。今で約3ヶ月。この3ヶ月間、結構色んな仕事をしたと思っています。自分でも納得して、仕事をしていました。しかし、何かが物足りない。
それが何かと言うのを考えると、周りに優れた人、お手本にしたい人、と言うのは確実に存在しています。その人達を見ているだけで、ご飯が何杯か食べれますw しかし、それ以上に食欲が萎えるようなシチュエーション(ここではあえて書きません)が多いような気がします。そして、これ以上、自分は会社から得られる(知識的にね)ことはないのではないか、と言う気持ちにもなっています。であれば、30代をただ消化するだけではなく、実りのあるモノにしたいので、より優秀な人に囲まれた職場を目指すべきでは。。。そんな気になっています。
CPF Low Power Simulation with Analog and Mixed-Signal Design (CPF-AMS)
By Qingyu Lin on May 23, 2011
この記事は、CPF Low Power Simulation with Analog and Mixed-Signal Design (CPF-AMS)の超訳です。
我々は、5,6年前からCommon Power Format(CPF)を使った低消費電力シミュレーションについて議論してきた。成熟した設計メソドロジのおかげで、デジタル回路設計者には一般的なものとなった。しかし、今やSoC設計者はミックスドシグナルの設計者になろうとしている。ミックスドシグナルの設計では、低消費電力設計技術とそれを表現するフォーマットはどのようなものとなるのだろうか？
SoCでの検証では、アナログブロックの設計にVerilog-AMSを使っていようが、今までアナログのソルバをシミュレーションに使ってきた。つまり、Verilog/VHDLのレベルをSPICE/Spetreのレベルに変えていた。アナログソルバが使用されるのであれば、CPFの低消費電力表現を活かすことができる。CPF自体は高位設計のためのフォーマットであるが、アナログソルバにおいては、アナログ回路とデジタル回路を混載Simするのと同じ要領で使用することができる。
Fig.1に我々の想定しているシナリオを示す。この図では、記述レベルをVerilogからVerilog-AMSもしくはSPICEに切り替えたものである(図中のana_B)。3つの懸念事項を示す。
1. CPFのパワ情報がVerilog-AMSもしくはSPICEで使えるかどうか？
デジタル回路でもアナログ回路でも電力に対しての考え方はほぼ同じだ。回路を記述するのに、VerilogモジュールであろうとSPICEサブサーキットであろうと、同じようにCPFの消費電力情報を使えるようにすべきであろう。
2. アナログモジュールは、CPFのパワーの状態に応じて、正確にシミュレーションすることができるか？
デジタル回路では、パワースイッチをoffしたときに、その領域の信号線は不定値Xの状態になる。このことは、CPFの記述内容により、内部の信号の状態が影響を受ける、と言うことを意味している。アナログ回路においても同様に、パワースイッチをoffにしたときには、信号線の状態を変える必要性がある。
3. 低消費電力のデジタル回路とアナログ回路がお互いに通信しあうかどうか？
通常のミックスドシグナルシミュレーションでは、アナログ->デジタル、デジタル->アナログの境界に接続素子が配置される。CPFが使用された場合、接続素子はアナログとデジタルの素子値を交換するだけでなく、CPFの情報も正確に信号線に乗せて交換しないといけない。
さらに、電気信号の代わりに電圧と電流を拡張実数値モデル(wreal)を使用する場合、同様の問題をwrealモジュールにも考える必要があるであろう。
Qingyu Lin
エキスパートPython勉強会#14に行ってきた
久々の勉強会。そして、ネタはTDD.普段テストとかほとんどしていないダメグラマーなので、非常に興味があった。
TDDやってる？
そもそもの発端は、テストプログラムの質をどうやって維持している？ と言うところから始まった。そして、TDDで使用するテストの意味というのはなんなのか？
ボク自身の開発スタイルは、こうだ(去年2年間やっていたプロジェクト)。
- プロトタイプを高級言語(ここでは、Ruby or Pythonの意)で開発する。ここでの目的は、そもそも実現しようとしている技術が我々のリソースで可能かどうかの検証。
- C++で本番プログラムを書き始める。上で大枠のクラス構成なんかは決まっているので、とにかく空のクラスを作りまくり、枠を作る(テストは作っていない)。
- その一つ一つを徐々に実装する。テストは用意しないが、ビルド(コンパイル)だけはできることが最低条件。
- コードが固まれば、それをドキュメントに落とす。いずれコードが自分の手から離れることを想定して。
いわゆるトップダウン的な開発スタイルだと思っている。
なぜテストを書かないか？ それは、@voluntas 先生が指摘した通りだと思っているのだけど、実装がない段階で境界値テストなんてできない、と思っているから。後は、やはり実装の速度を優先する必要があるから、と言うのもある。
話はそこからどんどん先に進んで、「では、漏れのないテストをどうやって実現するか？ テストジェネレータを使うか？」というような知らない世界に進んで行く。
結局TDDって？
今回の勉強会で一貫していたのは、テストの重要性は誰もが認めているところ。バグが出たら、そこに対してテストを書いて、テストが通ることを確認している、と言うスタイルは、皆さん一致知っていたように思う。
なので、TDDをやっている、やっていないに関わらず、テストは皆さん書いているし、それを実行するためにテストスイートも使っている。
結局、テストファーストなのか、コードファーストなのかは、重要な問題ではないんだなぁ、と言うことを実感した。どちらを採用するかは、開発チームの方針によるのだろう。TDDが品質を向上させる魔法のアイテムというのではなく、一つのキッカケに過ぎない、ということがわかっただけでも価値があった、と言える。
では、結局TDDで書いているテストと言うのは何なのだろう？ ボクには、仕様をコードに埋め込む、と言うように感じられた。なので、QAテストである必要はない。要は、後にそのコードをメンテする必要がでたときに、いちいち仕様書を見ないといけないのか(そもそも、仕様書がない場合の方が多い気がする)、コードを見ただけで、だいたいの動作が予想できるか。この差は大きいのではないか？
ということで
技術的には全然ついていけなかったが、テストに対しての姿勢を超1流プログラマの方から伺えたのは貴重な機会だった、と思う。
必ずしもTDDにこだわる必要はない。しかし、テストを残していくのは、後にコードをメンテナンスする人への最低限の思いやりであり、エチケットではないか、と感じた。
『ツレうつ』を読みました。
文庫本が出ていたので。
- 作者: 細川貂々
- 出版社/メーカー: 幻冬舎
- 発売日: 2009/04
- メディア: 文庫
- 購入: 18人 クリック: 130回
- この商品を含むブログ (87件) を見る
- 作者: 細川貂々
- 出版社/メーカー: 幻冬舎
- 発売日: 2009/04
- メディア: 文庫
- 購入: 12人 クリック: 56回
- この商品を含むブログ (47件) を見る
うつとは無縁ですか？
ボクには知り合いに3人ほど欝になった人がいる。うち二人は研究室の同級生と先輩。その同級生とは、実は今は同じ会社。先週も飲んだりしてた。
しかし、ボクが結婚式を挙げるとき(2004年12月)、彼はまさに欝になろうとしていた。結婚式にも招待したのだが、そのときはIEDMで発表しないといけないから、と言う理由で断られたのだが、その後、欝を発症してしまったらしい。
あの研究室は、本当に辛かった。ボクも大学3年からその研究室に入ったが、見事に人格を破壊された。今では、そうやって本気で怒ってくれる人がいた事に感謝しているが、あの当時は、そのように考えることはできなかった。刺したい、と思ったことすらある。おそらく同級生も同じ思いではないだろうか。そして、ボクは、同級生が一番ヘルプを欲しがっているときに、何もすることができなかった。
中学の同級生
もう一人、ボクはあまり親しくなかったのだけど、中学の同級生(同じ部活)にI君と言う人がいた。当時からあまり気が合わなかったので、一虬に遊びに行ったりした記憶はなかった。その後、大学で6年間仙台の方に行って、中学の同級生とは連絡をほとんど取ることもなかったため、彼のことが頭に浮かぶことはなかった。
大学院修士を終了して、ボクは関西に戻ってきた。明確な意図はなかったけど、何となく両親の近くにいたかったのだろう。だからと言って、親と同居はしたくなかったので、三田にある寮に住んでいたわけだが、それでも月に何度かは神戸の実家に帰っていた。その時、たまたまI君の友人のT君と会うことがあった。
「今、Iがうつ病やねん。お前も忙しいんやろうけど、たまには会いに行ってやってくれへんか？」とボクは言われた。確か、2003年ぐらいだっただろう。当時、ボクは今の奥さんと付き合っており、「そんなんに付き合ってられるほど暇ちゃうし、何かめんどいわ〜」と言う感じで、彼の要望を断っていた。その後も何度か電話で催促されたような気もする。
もういつだったか覚えていない。彼からの電話。「I、2ヶ月前に首吊って死んでん。」その時ですら、ボクは「ふ〜ん」と言う感覚だったような気がする(もちろん、言葉にはしていない)。
当時、ボクはうつ病は心が弱い人間が甘えからなるものだと思っていた。なので、何の同情も払うことはなかった気がする。しかし、今になって、うつ病の事を知るほどに後悔している。ボクの力で、彼を自殺から救うことなどできるはずはあるまい。だが、うつ病を発症して友達付き合いもめっきり少なくなっていった彼を、なぜボクは突き放すような真似をしてしまったのだろうか？ なぜ、軽い気持ちで会いに行かなかったのか？ ボクが顔を出すことで、少しでも彼の想いを変えることだってできたのではないだろうか？
もう7年近く経つと思うが、そんな後悔が後をたたない。
誰だって追い込んでしまう可能性もある
この本にあったことは、今まで何度かメンヘルの話を聞いてきたので、だいたいわかった。しかし、天気の調子(特に台風)で気分の浮き沈みが激しいと言うことは知らなかった。そして、誰だってなる可能性はある。また、知らないうちに追い込んでしまうこともある。
ボクは、去年までとあるところに出向していた。そこで、別の二人の人とチームを組んで開発をしていたわけだが、そのうちの一人から「あの時、実は病院に行ってて、薬を飲んでいた」と言う話を聞かされた。もちろん、そんなに追いこんでいたつもりはない。しかし、ボクには人を見捨ててしまう、もしくは邪険に扱ってしまう悪い癖がある。そういうところが、彼を一歩手前まで追い込んでしまったのかもしれない。
当たり前の事だが、I君のような事を2度と繰り返したくはない。そのためには、自分もうつ病に対しての正しい知識をつけないといけない、と考えさせられた本でした。
マンガですが、おすすめです。
Analog/Mixed-Signal Behavioral Modeling – When to Use What
By Richard Goering on February 20, 2011
(この記事は、Analog/Mixed-Signal Behavioral Modeling – When to Use Whatの超訳です)
ミックスドシグナルの検証は難しい。その一因はモデルにある。設計者はどのようにモデルを選択したらよいだろうか？ そして、そのモデルの正確さをどのように保証すればよいのか？ 2/17にあった"Tech on Tour"の1セッションでいくつかの解が提示された。
Cadenceは先週EDA360 Tech on Tourの一環として、Mixed-Signalにおけるシリコンリアライゼーションのセミナーを実施した。このイベントは、北米の数カ所、ヨーロッパ、アジアでも行われる予定である。以下のトピックに加えて、AMSのビヘイビアモデリングも加わっている。
- アナログ/ミックスドシグナルのシミュレーションと検証方法
- ミックスドシグナルSoCにおけるメトリックドリブンシミュレーション
- ミックスドシグナルでの消費電力の解析
- ミックスドシグナルの実装方法
- ミックスドシグナルのIR/EM解析
- OpenAccessを使用した相互互換性
私は、ドイツCadenceのエンジニアであるWalter Hartongが話したAMS Beheviorla Modelingに参加した。このイベントは、2/17にサンノゼのCadence本社で行われた。
The Mixed-Signal Verification Dilemma -- ミックスドシグナルの検証でのジレンマ
「ミックスドシグナルの設計者が最も欲しい物は、パッケージ込みのフルチップを高速でかつ正確にシミュレートできるシミュレータである」とWalterは言った。しかし、SPICEはシミュレーションに数週間かかってしまう。また、デジタルシミュレーションは高速であるが、アナログの効果を含めることができない。小さなブロックでSPICEシミュレーションをすることはできる。しかし、これだけでは、チップ内のブロック同士が正常に機能することを確認したとは言えない。
ミックスドシグナルにもビヘイビアモデリングがいくつか適用できる。Walterは、Cadence Virtuoso AMS Designerでサポートしている以下の3つの形式を説明した。
- Conservative models: Verilog-A, Verilog-AMSで記述した保守的なモデルである。このアプローチは、アナログのカーネルで実行され、電圧・電流のドメインでキルヒホッフの方程式を解く。例えば、このモデルは数100のトランジスタからなるバンドギャップ回路をわずか数行で表現できる記述性を持ちながら、アナログの全体シミュレーションに組み込むことができる。
- Signal-flow models: 信号の流れに方向性を持ってしまうが、容易に解くことができる。このモデルは、フィードバックも記述することはできるが、入出力間の負荷による効果は含めることができない。このモデルは、アナログモデルの抽象化に役に立つ。
- Event-driven models: このモデルは、イベントがあったときのみ評価されるものであるため、シミュレーション時間はイベント数に比例する。このモデルは、デジタル回路、ミックスドシグナル回路、高位のモデルに役に立つものである。
それでは、どのタイミングでどのモデルを使用すれば良いのか？ Verilog-AとVerilog-AMSで記述されるConservativeなスタイルは、精度が要求される場面で機能するモデルである。このアプローチは、SPICEシミュレーションに比べて、50~100倍以上高速に実行できる可能性を持っているが、全てはモデルの良し悪しに依存してる。Walterは、「もし、記述能力が低ければ、SPICEと同等の速度、もしくはそれ以下の速度になってしまうだろう」と警告した。
Verilog-AMSで利用出来るwrealデータ型を使用すると、イベントドリブンのデジタルシミュレーションに実数の概念を取り入れることができる。要するに、デジタルシミュレーションの高速性とデジタルエンジニアで広がっているメトリックドリブンな検証スタイルを取り入れることができる。このスタイルは、シミュレーション効率の向上が求められるが、精度を落としたくないときに有効である。例えば、wrealは、フルチップのミックスドシグナルシミュレーションに有効である。
次のグラフ(Cadenceの元記事参照)は、アナログ/ミックスドシグナルのモデリングスタイルに対して、精度とスピードのトレードオフを示したものである。このグラフに示されるとおり、Conservativeモデリングスタイルは、幅広いレンジを持つ。すなわち、モデルの良し悪しに依存する、と言うことである。
モデリングにかかる時間(労力)も重要な観点である。このグラフ(Cadenceの元記事参照)に示すとおり、Conservativeモデルの開発は最も労力がかかる。Walterは、「ビヘイビアモデルの開発には、数日、数週間、数ヶ月要する可能性がある」と言う。Wrealモデルの開発は、Conservativeモデルよりは、詳細の記述が不要なため、早く開発ができる。「作ることができるモデルではなく、必要なモデルを開発すべき」と言うのが、重要な経験則だ。
How Do We Know the Models are Good? -- 良いモデルであることをどうやって確認できるのか？
もし、シリコン上での精度を十分に表現できないのであれば、そのビヘイビアモデルは役に立たない、と言わざるをえない。「設計者もモデルも常に変化するので、継続的なモデルの検証が必要である」と、Walterは指摘した。モデル上での小さな変化が、設計では受け入れられないこともある。
Walterはアナログ・ミックスドシグナルをターゲットとしたCadence Virtuoso model validationツールamsDMVのデモを行った。このツールは、自動化された回帰テストを提供する。しかし、このツールがあっても、アナログ設計者が詳細なモデルの検証を行うことは必要である。Walterは、「このツールはあなたの仕事を奪うものではない。ツールはモデルの詳細や回路のことは知らない。ただ、シミュレーション結果が事前に設定したスペックと一致しているかどうかが判定できるだけである」と言った。
Richard Goering
DVCon Paper: Assertion-Based Verification For Mixed-Signal Designs
By Richard Goering on March 10, 2011
(この記事は、DVCon Paper: Assertion-Based Verification For Mixed-Signal Designsの超訳です)
デジタル設計者と検証エンジニアもアサーションベースの検証手法の有効性については、何度も主張している。なぜ、アナログ/ミックスドシグナルには広がらないのだろう？ CadenceはDVCon2011において、アサーションベースの検証手法をアナログ/ミックスドシグナルに適用した例を発表した。
Cadence社のDon O'Riordan, Prabal Bhattacharya, Walter Hartongが、"Mixed Signal Assertion-Based Verification"と言うタイトルで発表した。プレゼンテーションしたのは、Cadence Virtuoso PlatformのシニアアーキテクトであるDon O'Riordanである(この論文を含め、他の論文もDVConのサイトから閲覧することができる)。
プレゼンテーションの中で、Donはアサーションベースの検証手法のメリットについて述べ、PSL(Property Specification Language)とSVA(SystemVerilog Assertion)をどうやってミックスドシグナルの世界に展開するか、を示した。ΣΔADCを用い、アサーションをシミュレーションに適用した例をしめした。ここで、Donは波形を単に見つめるよりをアサーションを用いたほうがデバッグが容易であることを示した。
Why Assertions Improve Verification -- なぜ、アサーションは検証を改善するのか？
Donが説明したように、アサーションは望ましい動作と望ましくない動作を記述するものである。あるイベントの後か、もしくはある時刻での信号が常に(もしくは、決して)trueであったり、もしくはtrue(逆にuntrue)になったり、と言う条件を記述する。シミュレーションでは、アサーションにトリガがかかったときに、エラーを直ちに捕捉できる。すなわち、このエラーが出力に出てくるのを待つ必要もないし、波形を見る必要もないのである。さらに、アサーションは、ドキュメンテーション、観測性、制御性、カバレッジも向上させる。
各社は、それぞれのアプローチでミックスドシグナルのアサーションを開発しているが、標準のアプローチが最もよい、とDonは言っている。彼は、二つの標準化グループを紹介した。両方共Accelera Verilog-AMSの寄与によるものであり、アナログ/ミックスドシグナルでのアサーションを標準化しようとしている。
- ASVA(Analog System Verilog Assertions)委員会は、SystemVerilogのサブセットであるSystemVerilog AssertionsへのAMSの拡張を進めている。
- SV-AMS(SytemVerilog AMS)委員会は、SystemVerilogそのものに対して、AMS拡張をしようとしている。このグループはASVAの結果を反映している。
どちらの委員会でも、SystemVerilogに"real"なデータ型を持ち込む必要性がある。「realデータをサポートしたときには、どんなスゴイことが起こるのか想像つかない」とDonは、言っている。今日、Cadence IncisiveのSVA(SystemVerilog Assertions)には、realデータタイプがBooleanの拡張として実装されている。これにより、AMSでのアサーションも可能となっている。
一方で、PSLは言語に依存しないものであり、アナログ/ミックスドシグナルに異なった付加価値をもたらす可能性がある、とDonは指摘する。彼は、ミックスドシグナルアサーションで、PSLが有効に機能するために、"アナログオブジェクトをPSLのBoolean層に持ち込むこと", "ミックスドシグナルシミュレータにおいて、アナログのイベントを可能にすること", "Verilog-AMSのwrealデータタイプを活用すること(これは、Cadenceが標準化委員会に出した改善事項に基づくものである)"が必要だと述べている。
Making Sure an Integrator Integrates -- 積分器の実装を検証する
ミックスドシグナルアサーションの単純な例がΣΔADCの例として示されている。このADCは積分器を含んでいる。この積分器が正しく実装されていることをどうやって検証すればよいだろうか？ 現在の出力と入力が共に正であれば、次の出力も正の値になるだろう(逆に全てが負であっても同じ)。そこでDonは、「積分器は、常に正負の符号を保持しべているべきだ、と言うアサーションを書くことができる。それにより、ノイズを含んだデジタルのネットを接続しても、混乱するようなことにはならない。
論文で指摘されているように、このPSLのアサーションは、入力が正の値である時に、次のサイクルでの積分器の出力は正である、と、どのサイクルでもテストされる。
pos_integ1: assert always { i1_inputs_pos } |=> i1_pos;
もし、アサーションが満たされなかった場合、シミュレータは確実に指摘することができる。Donは、「アサーションベースでシミュレーションを検証していれば、波形にバイオレーションが見つかった場合に、大きなフラグを見つけることができる。このフラグが、回路デバッグの際に、波形をじっと見つめる従来のやり方よりも、非常に有用なものである。
さらに、デジタルのエンジニアがやっているように、ミックスドシグナルエンジニアもアサーションでどれだけアナログ値をカバーできているかがわかる。これにより、ミックスドシグナルの世界にもメトリックドリブン検証の考え方を持ち込むことができる。さらに、検証プランにフィードバックできる単体のカバレッジレポートを得ることができる。
Mixed-Signal Assertions in Cadence Tools -- Cadenceツールでのミックスドシグナルアサーションの取り組み
Donは、DVConのプレゼンテーション中で、Cadenceツールのことには触れなかった。そこで、私はCadenceツールがどの程度アナログ/ミックスドシグナルのアサーションをサポートしているのか聞いてみた。以下はほんの一部だが、Virtuoso-AMS製品での対応状況である。
- Assertions on wreal data types using PSL
- Assertions on real data types using SVA
- Coupling of real and wreal data types to analog simulator kernel objects
- Verilog-AMS expressions in the Boolean layer of PSL
- Ability for analog signal transitions to clock assertion expressions in PSL
- Support for coverage measurements on PSL assertions
全てのSoCはミックスドシグナルである。そのため、ますますアサーションが重要になってくるだろう。そのため、Donは「アナログ/ミックスドシグナルのアサーション実現のために、PSA、SVAに標準化していこう」と述べた。
Richard Goering
アナログのトップダウン設計が進まない理由、もしくは、信号を0,1化するメリット
近頃社内でこのような話をよく聞く。ボクの中では、5年前に結論が出ている問題ではあるのだけど、今一度考察してみようかな。
主に二つある。
- 機能設計に集中できるほどには、デバイスの影響を抽象化できていない。
- プログラム化して、抽象度を設けていくよりも、作ってしまった方が早い。
デバイスの一次効果
前者はトランジスタだけに限ることではないけど、要は常に物理的な配置イメージを頭に置いていないと回路設計はできないのが現状である。
有名なアナログ設計の八角形というものがある。
- 雑音
- 線形性
- 利得
- 電源電圧
- 電圧スイング
- スピード
- 入出力インピーダンス
- 消費電力
これらはお互い相互に影響しあっている。アナログ設計者は常に(かどうかはわからんけど)、この八角形全体の影響を考慮しながら設計している。
では、デジタル設計にはなぜ上記のようなトレードオフがないか？ いや、ある。実際にセル設計している部隊。特に面積最小を狙っているようなところは、複数のトレードオフを考慮していかないと、最適な回路など到底生み出すことができないだろう。しかし、そこを超えてしまえば、遅延と電力と言う二つの特性だけにセルを抽象化できてしまう。
アナログセルの場合、オペアンプを作ったからと言っても、遅延と電力と言うように抽象化することはできない。それは結局連続量を扱わないといけない、と言うところに帰着するのだろうが、前後に挿入する回路によって、入出力特性が変わる可能性があったり、近くにおいた回路によるレイアウト的な影響で均一に作れなくなる、と言う可能性もある。
人間の頭でできることは、コンピュータにもできるだろう。しかし、コンピュータはあくまでスペックベースでしか答えを弾きだすことができない。上記のトレードオフを全て入れれたとしても、コンピュータが弾きだす最適だと思われる解と設計者が考える最適だと思われる解には、まだまだ差があるのが現状であろう。
汎用化の難しさ
そして、後者の方。
設計者のノウハウを全てプログラムに制約として入れてしまえば、最適値にたどり着く可能性はある。確かに、遺伝アルゴリズムタイプの最適化ではなく、数式ベースの最適化はそういう方向だろう。しかし、数式ベースの最適化ツールが成功することはなかった。これは、汎用性のなさ、と言う言葉に集約できると思う。
大学時代、S◯NYにインターンに行くチャンスがあった。プリント基板を設計・製造している事業所だ。今でもあると思う。ボクが学生の頃は、PS2の基板を製造していたと思う。S◯NYのような会社であれば、全てオートメーション化されているものだろうと思っていたら、実際に基板を作っているのは、南米の労働者たちであった。すなわち、機械ではない。
その時に聞いたことは、確かに自動化はできるが、バリエーションが多いので、汎用的なものを作るよりも人手で対処した方が早くて安く済む、と言うものだった。数式ベースの最適化ツールも同じ課題を抱えているように思える。全ての制約をプログラムにインプット出来れば、確かに最適解を得られないことはないだろう。しかし、費用対効果が成り立たない。展開製品が多いPLLのようなものであればPayするはずだ。確かにそうかもしれない。しかし、プロセスやスペックが異なれば、制約条件をイチから考える必要があり、結局のところベテランデザイナしかできない。それであれば、展開できるだけの技術力を持ったエンジニアを育成して、ベテランデザイナとタッグを組んで設計していく、今のスタイルの方が費用対効果的にはメリットがあるのだろう。
最後に
もう少し上手く書けるつもりだったけど、いまいち上手くまとまらなかった。自分の中でもまだモヤモヤしている部分がある。
このようにアナログの最適化・自動化と言うのは、やはり現実的ではない、と言うのが私の意見。美しさをコンピュータに判定させるのはどうしたらよいか、と言うのに似ている気もする。
それよりも、これからのアナログ回路は全てデジタルとの混載になるであろう。よく言われていることであるが、微細化のメリットを享受して、高速・低消費電力・小面積化を実現するためには、デジタル化出来る部分を増やしていった方がいい。とすると、今後アナログEDAに求められるのは、今まで以上のアナデジ混載回路の検証方法を確立することではないだろうか？
ということで、私はアサーションベースのアナログ回路検証に、今興味を持っているところだ。
