12/05/00
その昔、ソフトウェアの開発はほとんど人手で行っていた。フローチャートと変数表を用いハンドアセンブルしたバイトコードをエディット機能が貧弱なモニターから入力していたのだ。
「回路の最適化なんて人間の仕事ではないでしょう」と先日客先で言われた。確かにそういう考え方もある、「HDLは人間に解かり易く書き、回路の生成はコンパイラの仕事」と言う観点にたてばもっともな意見であるし不必要に複雑に書く必要はない、だが
さて、「美しいソースコード」さえ書けば「スペック出なくてもいい」なんて仕事は*まず*あり得ないのでHDLをいじくってコンパイラにガンガン介入する事になる。たとえ回路規模と動作速度が満足できても「パッケージの許容パワーにはいらへんやんけ!」というのは実はよくあることなのだ。
普段仕事ではSynopsys社のDesign Comilerを使用している、こいつはASICの世界では事実上「標準」ということで有名（そのせいか知らんがえらく高価である事も有名）で大概のASICベンダーはDesign Compilerのライブラリーを出している。
基本的にはコンパイラーにライブラリとHDLのソースを喰わせて、規模と動作速度を指示してやれば後は機械が頑張ってくれる事になっている、一応どのくらい頑張ってくれるのか指示することもできて「適当でいいよ」「本気でやってね」「死ぬまで頑張れ」の3種類選べるのだがスペックが満たせないからといって迂闊に「死ぬまで頑張れ」等と指示しようものなら
さて、いつまでもLOGを見てボーゼンとしているわけにもいかんので対策を打つのだが、ここでいきなりコンパイラに指示を与えるスクリプトのパラメーターを変更してマージンを削ってなんてのはやめよう。仮配線と実配線の差はプロセスが進むごとに開く一方だ、迂闊にマージンを削ることはレイアウターの皆さんに迷惑がかかる。 レイアウターの方々とは良好な関係を保っておこう、くれぐれも「仮配やったら、スペック満たしてるやんけワレー！」なんて発言は謹むべきだろう。
最初はコンパイラーから出力された回路を検証しよう、タイミング違反が起きているようならSTAを使ったり、規模の問題であるならばマクロごとの回路規模をチェックしたりしてボトルネック箇所を洗いだすのだ。弱点が解っていれば敵をおそれる必要はない、急所を狙ってクリティカルヒットを繰り出そう。