竹下世界塔の計算機よもやま話

アクセスカウンタ

zoom RSS プロセッサの設計運用の形態、検証の楽しみ

<<   作成日時 : 2011/04/05 21:30   >>

ブログ気持玉 0 / トラックバック 1 / コメント 2

 エコ、省エネの話も出ますが回路の話はありません。設計運用上での話。

 大規模プロセッサにもなると各ブロックごとに5〜10名のチームが担当し、設計することになる。すべてのモジュールの結合の責任は、当時はシミュレーション担当が行っていた。理由は単純でビルドできないとシミュレーション出来ないからだ。
 設計チームは自分の担当ブロックに関しては責任を持ってやるが、隣接するモジュールとの結合に関しては責任が曖昧になる傾向があった。でも、端子が合わないとビルド出来ないんですけど。これは「全体が動く」ということに関しては責任を持ってないし、ペナルティもないからだろう。
 システムシミュレーション担当だった私が「ビルドできねーよ」「動かねーよ」といっても、自分のブロック内については本当に真剣にデバッグや修正などするが、ミスがあった時にどちら側のブロックで対処するか、端子の機能定義などについては責任の所在がない感じを受けた。これは設計方針が大いに関係してくる。私のいた部隊は伝統的にそれぞれのチームの独立性が高かった。その結果、単体モジュールとしてはリーダが責任を持ってリリースするのでおおむね高品質だが、物理設計では限られた半導体の面積をめぐって隣接するチームとの領地争いが起きたり、仕様変更が必要なときに他のチームとのコミュニケーションがあまりうまくいってなかったりする。ここに口出しできるのは、別の場所から広く浅く見ている検証屋さんで、それこそスタセルの修正依頼から「あなたのチームは進捗状況が進んでるから隣のチームのミスを吸収してちょ」などの調整役になった。
 本来はトップアーキテクトの指示一発だろうが、小さな問題は検証屋の提案、大きな問題は昼イチに毎回やってるリーダ会で調整した。民主的であったとも言える。トップアーキテクト=課長も我々を信任してくれて器がでかいと思うのだがどうか。もちろん本当にヤバい時は課長が出てきて手配してくれる。そういった安心感もあった。

 で、エコの話。
 設計が複雑になってくると消費電力の累積もバカにならない。このままではパッケージ化できないよ、と半導体製造部門から言われて、ある課長がチーム間を飛び回って省電力化の指示を出していた。
各チームは高速化命、電力は無限大だと思ってるような設計をしがちなので、ここの性能はソコソコでいいから削ってくれなど実に細かくてたくさんの依頼をその課長はしたようだ。回路に詳しく、説得力もあり、権限もあるからできることだ。しかし大変だったろう。そうやって小銭を集めて回るかのごとく消費電力を削減し、一応の目標はクリアしたらしい。ご苦労様です。

 話に聞いただけなのだが、よその設計部隊はトップアーキテクトがいて、中央に陣取る制御回路が指示を出し、周りの回路は中央の回路の言いなりに動くような構造だったそうだ。
 作る方は、まあ楽だ。指示どうりに作ればいいのだし、設計変更にもそのまま従えば良い。全体のアーキテクチャを知らずとも作れる。障害は制御回路の指示ミスか、周辺回路が仕様を満たしてないかのどちらかだ。この方法だと制御回路がかなり複雑になりそうだ。一番驚いたのは検証チームの話。なんとテストプログラムを流して○×表を作るだけ。設計チームはそれで判断して修正するという。う〜ん、トップアーキテクトに心酔しない限り私には向かないかもしれない。

 検証の楽しみは、現場を押さえて被疑者を呼んで取り調べを行い自白させることじゃないのか。おっと言い直す。障害の原因まで徹底して調べ、該当するモジュールがあれば担当者に質問し、動作に問題がなければさらに遡って調べる。その間、地道にトレースポイントを絞り、必要があればプログラムを書き、長時間かかるシミュレーションの完了を待つ。原因がわかった時は推理小説のラストを迎えたような気分になれるのだ。しかも探偵・刑事役で。設計は直接しなくても検証ほど面白い仕事はないと感じていた時期が私にはあった。

テーマ

関連テーマ 一覧


月別リンク

ブログ気持玉

クリックして気持ちを伝えよう!
ログインしてクリックすれば、自分のブログへのリンクが付きます。
→ログインへ

トラックバック(1件)

タイトル (本文) ブログ名/日時
検証って何?
...続きを見る
uarchs jimdo page!
2011/04/07 01:05

トラックバック用URL help


自分のブログにトラックバック記事作成(会員用) help

タイトル
本 文

コメント(2件)

内 容 ニックネーム/日時
設計も検証も一緒にやってたので、犯人を探したら自分ってな変な推理小説みたいなコトも多々あり(苦笑)。自分で自分のミスをみつけるほど堪えるもんはないっす…。
さくらい
2011/04/12 11:58
検証の方でもあるんですよ。金田一耕助シリーズに出てくる等々力警部みたいに「よし!わかった!」と検挙したら犯人は検証プログラムのせいだった、または検証モデルに抜けがあった、等。ボロクソ言われます。
設計者が隣の人のモジュールを検証しあうクロスチェックは有効ですね。
houmei
2011/04/12 16:02

コメントする help

ニックネーム
本 文




プロセッサの設計運用の形態、検証の楽しみ 竹下世界塔の計算機よもやま話/BIGLOBEウェブリブログ
文字サイズ:       閉じる