第80回

Engineering Life in Silicon Valley

フリー・エンジニアという仕事(第二部)


今回のゲストのプロフィール

ボブ・アイゼンスタッド(Bob Eisenstadt):LSI設計エンジニアとして20年近くの経験を有する.VLSI Technology Inc. (現在はPhilipsの一部)でASIC設計の経験を積んだ後,Supermac, Radius, Silicon Graphics, 3DFX,Silicon Imageなどのグラフィックス関係の企業でLSI設計の外部スペシャリストとして活躍する.そのほかにスタートアップの設立の経験や,パテント取得の経験を有する.オフには運動,造園,家族と過ごす.マサチューセッツ州ボストン出身.



前回まで
 大学卒業後,シリコン・バレーに来たが,早い時期にレイオフされてしまった.この経験を活かしつつ老舗のASICベンダに就職し,ASICエンジニアとして仕事を続ける.その後,Silicon Graphicsでフリー・エンジニアとして働くきっかけができ,さまざまなシリコン・バレーの企業でフリー・エンジニアとして働く.

ASICからCOTへの変化


 ボブさんはグラフィクス関係のデバイスを開発された経験が多いのですが,これには何か理由が?
 フリー・エンジニアとしての仕事を,Silicon Graphicsからスタートしたからでしょうね.この分野の仕事をRadiusやSupermacで続け,その後は3DFXに行き,2001年にはSilicon Imageという会社でプロジェクトに参加しました.そして9.11で一気に景気が冷え込みましたが,景気の良いときは本当に仕事が多く,自分で選べる状態でした.

 また,当時は主流が2Dから3Dにシフトするときだったので,グラフィクス関係にずっと携わっていられたのだと思います.インターネット・バブルの時期でしたが,同じくCOT(Customer Owned Tooling)が流行った時期でもあったので,それも私のできる仕事を増やしてくれていたと考えています.


 それまでのASIC開発は,顧客であるシステム屋さんやセット・メーカが論理設計まで行い,その後はASICベンダが1チップ化するなりデバイス化を行ってきましたが,COTになると,開発は論理設計以上にマスク開発まで顧客が担当することになりましたね.TSMCやCharter, IBMなどの純粋な半導体ファウンダリと直接やりとりする形になりました.これで今まで以上に半導体開発全体に携わったことのあるエンジニアが重宝されたのですね?
 完全にデバイス化をする仕事を自前で行い,すべてのコストをコントロールし,自社の知的財産をIP化してコントロールすることでシステム・メーカやセット・メーカは差別化を達成できると考えていたわけです.

 しかし,マスク代や開発費が高騰しているので,コスト・メリットがどれぐらい出るのかは難しい判断だと思います.


 マスク代はよく聞く問題ですが,いくらくらいでしょうか?
 0.18μmプロセスで30万ドル(約3200万円),0.13μmで75万ドル(約8000万円),90nmで150万〜170万ドル相当になります.ですから,1品種で1万個しか作らないデバイスはコスト的に無意味になってきています.

 現状は,歩留まりが安定している0.18μmが主流のように感じますし,マスク代もしだいに安定してきています.0.15μmも0.18μmと似た歩留まりとコスト体系なので,この二つのプロセスは長く使われると思います.これ以上のパフォーマンス…大量のゲートを収めたいとか,パフォーマンスを要求しているデバイスなどは90nmを使うことになります.今後,e-beamの利用でさらにコストが下がってくると思います.

 システム化においては,マルチチップ・モジュール(MCM)などがよく議論されています.しかし,結局使えるデバイスを採取するところで歩留まりが決まってくるので,いかに利用可能なデバイスを採取するかが大きな問題になり,コスト的に見合わないケースが多くあります.ですから,設計がしっかりしていれば1チップ化したほうが歩留まりを向上させることが可能なようで,今後もシステムを1チップ化していく方向は衰えないと思います.


仕様書を詰めることは難しい


 ずっと設計に携わっていましたが,とくに最近のトレンドなどはありますか?
 2.0μmがつい10年前まで使われていたプロセスで,それよりもさらにプロセス技術が発達しました.同じく設計技術も進化してきました.しかし,フロント設計,つまり論理設計やシステム設計と,バックエンド設計(レイアウト・レベルでの設計)がうまく分離できなくなっています.ゲート遅延以上に配線遅延をうまく見積もったり,モデリングすることが大切になっています.ここは,設計ツールが飛躍的に進化したので,自動化が進んでいると思います.

 フロント系設計と論理設計では言語設計,つまりVerilog-HDLやVHDL,そして新しいSystemCを使った設計などが当たり前になってきています.また,バックエンド系のツールも最近はとても優秀で,指定したスペック内でなんとか配置配線をしようとがんばってくれます.ツールがたいへん進化しているので,実際のRTLから始まる設計については問題を感じません.私がもっとも問題だと感じているのは,デバイスがあまりにも大きくなっているので,一人のエンジニアが仕様のすべてを理解するのが不可能になっている点です.


 アーキテクトとか熟練のエンジニアがいても,仕様書が不完全ということでしょうか?
 そうですね.シリコンバレーだと10名から20名のエンジニアに対して,1〜3名のアーキテクトがいるという例が一般的です.アーキテクト達は,全体的なブロック図を描いたり大まかなボトルネックになるポイントを指摘したり,かなり設計上の要点を押さえてくれます.おぼろげな輪郭から徐々に詳細な点を作り上げていきます.ですから,実際にRTLの設計段階に入ってシミュレーションしてみて,初めてFIFOの深さが足りないとかデータ・パスの遅延が長すぎるとかブロック間のタイミングが難しいといった問題がわかるのです.

 きちんとモデリングや仕様書を書いてもですか?
 一人の人間が理解できる範囲を超えているのでモデリングも難しいし,仕様もことばで表せないことがたくさんあります.また,アーキテクトとか熟練エンジニアはとても賢いのですが,すべてを紙に書くといった細かさに欠ける人が多いので,チーム全体に情報が伝わらない例が多くあります.

 設計時間の多くは,自分にアサインされたブロックを中心としてチップ全体を理解しようとする,チーム全体の「勉強時間」に費やされる例がほとんどでしょう.


 よくある話ですが,納期が間に合わないのでとりあえずどんどんお客さんからもらった仕様書やアーキテクトから渡された仕様書で試行錯誤しながらRTLをガリガリ書いていく…そしてブロック間のシミュレーションを行ったときにやっと問題が見えてくるというやつですね.
 まったくおっしゃるとおりで,どこも似たような手順で手探り状態でRTLを書き始めます.大幅な変更は当たり前とかね(苦笑).しかし,おもしろいことに,パフォーマンス・モデルやトランザクション・モデルといったハイレベル・モデリングを徹底している会社は,最終的に良い結果を出しています.

 それはどういうことですか?
 とくにグラフィクス関連の設計では,細かいチューニングによってパフォーマンスを最高にすることが可能です.しっかり手順を踏んでモデリングをしてきた会社が,チューニングの段階で何をしなければいけないのかをしっかりと把握しているので,開発の成果も確実に近くなります.また,システム全体の問題点の絞り込みもできています.だからモデリングなどに対して,チーム全体でじっくり取り組めればベストですね.

 余談ですが,最近インドなどに設計の仕事が流れてしまうことを心配している人達がいますが,私はそうは思いません.しっかりと紙の仕様書で記述できるデバイスやブロックなどは可能だと思えるのですが,普通に行われているデバイス開発はどうしても徐々に作り込むプロセスが大切なので紙に書き残せる仕様書は少なく,システム関連の人達とデバイス開発の人達がいっしょに仕事ができる環境が必要です.こういう設計は距離や時差があると難しくなると思います.だから,海外の開発部隊…つまりインドなどに流せる仕事は,簡単なデバイスやブロックなどが妥当だと思います.

検証環境のアーキテクト



 理想的には本当にしっかりとモデリングすることがベストですが,実際にはなかなかできていないということですね….これら以外に問題と感じている所は?
 仕様書レベルでのモデリングに関連する話ですが,検証のアーキテクトという考えかたが必要です.検証は後回しになっていますし,複雑なデバイスなので検証もとても複雑になります.同じ基礎アーキテクチャであれば過去の検証資産の流用などがおおいに可能になります.Intelなどが良い例です.基本アーキテクチャを進化させてゆく設計プロセスですから,検証チームも過去の資産の流用や,先回りして検証に必要なテスト・ベンチやテスト・ファイル,評価ボードなどを開発することが可能になります.

 新しいアーキテクチャで設計するとゼロに近い状態から検証に必要な環境を作り出さなければならないので,それだけ費用と時間がかかります.場合によっては,これは設計サイクルに1〜2年追加されることになってしまいます.ですから,ベンチャ企業でチップを一発で成功させるには,相当な努力やくふうが必要となります.逆に既存のベンダは検証の環境を流用するなどのコスト・メリットが得られます.ですから,仕様書レベルで設計の全体像を把握すると同時に,検証の環境をいかに設計していくかを把握する「検証のアーキテクト」が大切になります.


 ここでもハイレベル・モデリングが必要ですか?
 しっかりしたモデリングがある場合,チップのボトルネックや問題点の把握ができているので,そこから検証やテストの段階で何をしなければいけないか,ある程度予測できます.グラフィックスの場合,FPGAなどのプロトタイピングによって実データを流さないとわからないことがたくさんあるので,ソフトウェア・シミュレーションだけに頼れない部分があるとか….こういうのを洗い出して行くことがモデリングを行うことで,ある程度把握できるのです.全部とはいいません(苦笑).少なくても私が見てきた企業で徹底的に差が出ていたのはこういうことができていた会社です. (次回に続く)

次回の予告
 フリー・エンジニアとしての生活などについて伺う.また今後のエンジニアリングについても話題が出た.



トニー・チン
htchin@attglobal.net
WinHawk
Consulting

 


copyright 1997-2004 H. Tony Chin

連載コラムの目次に戻る

Interfaceトップページに戻る

コラム目次
New

Engineering Life in Silicon Valley 第79回 フリー・エンジニアという仕事(第一部)
移り気な情報工学 第36回 時代間通信アーキテクチャ
フリーソフトウェア徹底活用講座 第14回 GCC2.95から追加変更のあったオプションの補足と検証(その3)

Back Number

フリーソフトウェア徹底活用講座
第13回 続々・GCC2.95から追加変更のあったオプションの補足と検証
第12回 続・GCC2.95から追加変更のあったオプションの補足と検証
第11回 GCC2.95から追加変更のあったオプションの補足と検証
第10回 続・C99規格についての説明と検証
第9回 C99規格についての説明と検証
第8回 C言語におけるGCCの拡張機能(3)
第7回 C言語におけるGCCの拡張機能(2)
第6回 GCCのインストールとC言語におけるGCCの拡張機能
第5回 続・C言語をコンパイルする際に指定するオプション
第4回 C言語をコンパイルする際に指定するオプション
第3回 GCCのC言語最適化以外のオプション
第2回 GCCの最適化オプション ――Cとアセンブラの比較
第1回 GCCの最適化オプション

移り気な情報工学
第36回 ITもの作りの原点
第35回 ビットの化石
第34回 ユビキタスなエネルギー
第33回 ロゼッタストーンとWWW
第32回 情報家電のリテラシー
第31回 草の根グリッドの心理学
第30回 自分自身を語るオブジェクト指向「物」
第29回 電子キットから始まるエレクトロニクス
第28回 映画に見る,できそうでできないIT
第27回 ITも歴史を学ぶ時代
第26回 1テラバイトで作る完全なる記憶
第25回 日本はそんなにIT環境の悪い国なのか
第24回 10年後にも生きている技術の法則
第23回 ITなギズモ
第22回 ブロードバンドネットワークに関する三つの質問

Engineering Life in Silicon Valley
第78回 インドに流れ出るシリコンバレーエンジニアの仕事
第77回 エンジニア達の健康管理・健康への努力(第二部)
第76回 エンジニア達の健康管理・なぜエンジニア達は太る?(第一部)
第75回 ユーザーインターフェースのスペシャリスト(第二部)
第74回 ユーザーインターフェースのスペシャリスト(第一部)
第73回 放浪の旅を経てエンジニアに……
第72回 凄腕女性エンジニアリングマネージャ(第二部)
第71回 凄腕女性エンジニアリングマネージャ(第一部)
第70回 ビジネススキルを修行しながらエンジニアを続ける
第69回 専門分野の第一線で活躍するエンジニア
第68回 シリコンバレーに夫婦で出向(第二部)
第67回 シリコンバレーに夫婦で出向(第一部)
第66回 目に見えないシリコンバレーの成功要因
第65回 起業・独立のステップ
第64回 インターネットバブルの前と後の比較
第63回 日本でシリコンバレースタートアップを体験する(第四部)
第62回 日本でシリコンバレースタートアップを体験する(第三部)
第61回 日本でシリコンバレースタートアップを体験する(第二部)
第60回 日本でシリコンバレースタートアップを体験する(第一部)

フジワラヒロタツの現場検証
第72回 現場検証,最後の挨拶
第71回 マイブーム
第70回 OSぼやき放談
第69回 技術者生存戦略
第68回 読書案内(2)
第67回 周期
第66回 歳を重ねるということ
第65回 雑誌いろいろ
第64回 となりの芝生は
第63回 夏休み
第62回 雑用三昧
第61回 ドリームウェア
第60回 再び人月の神話
第59回 300回目の昔語り
第58回 温泉紀行
第57回 人材ジャンク
第56回 知らない強さ
第55回 プレゼン現場にて


Copyright 1997-2004 CQ Publishing Co.,Ltd.