SDRAMの調整も終息に向かって、最終調整に向かう頃、とても苦労したのが
FPGAのリソースが殆どなくなってきた事です
75%くらい消費していました。
後25%も残っているように思いますがFPGAのコンパイルは消費リソースが増えるとより苦しくなってきます。例えば90%とかになると、ほぼそれ以上は何も入らないです。
この回路をいじっていた当時、私は新入社員で、基板が出来上がっていたので
この回路のままなんとかしなければいけないと思っていました。
素人にとって、出来上がった電子回路基板と言うのは、絶対的で、置き換えるとかの発想は全くありませんでした。
そんなわけでこのFPGAのまま完成させていきました。
実は私の上司にとっても、AlteraのFPGAを採用するのは初めてで、実際に使った事がなかった様なので、以下の事を報告しましたが、何も聞いてくれませんでした。
・リソースがいっぱいいっぱいになってギリギリ
・ロジックエレメントが増えるとコンパイルの時間がかかる
・配置配線が毎回違ってタイミングが変わってしまう
何度も報告しましたが、これらは後に上司が自分でFPGAをコンフィグレーションするまで理解してもらえませんでした。
今になって思う事ですが、この上司の開発は、「回路図ファースト」だったのですが、FPGA開発の基本（と言うか理想）は、「FPGAファースト」なのだと思います
これはどういう事かと言うと、まずFPGAを含めたシステム全体のブロック図を作成し
そこに基板が出来ていると仮定して、FPGAのロジックを書き連ねる
シミュレーションを行い、FPGAの内容がある程度完成したところで、最適なFPGAを探す。リソースが不足していれば大き目なFPGAにして、リソースがだぶついていれば、よりリーズナブルなFPGAに変更する。
そうする事によって、FPGAの致命的なミスマッチを防ぐ事が必要なのだと思います。
私の上司は、FPGAが一般的な物になる前から回路図を引き続けていて、仕様検討の段階で的確にICを選定するのがとても得意でした。それ故にFPGAの選定も仕様検討の段階で行い、回路図も間違えはありませんでした。
おかげで、私の提案はどうにも聞き入れてもらえませんでした。
一つの要因として、私は可愛げが無かった事もあるのかと思います。
FPGAの開発と言うより、仕事をするものの心得として、周囲の人間と円滑にコミュニケーションを取れる事は大事だなと痛感しています。
私の上司は最後まで私の意見を取り入れる事はなく、何をするにも私には確認を取らず
いきなり回路を書いて、基板を作ってから指示をする事を繰り返しました。
幸い、FPGAもどんどん進化したおかげで、容量不足に悩む事は少なくなりましたが
やりづらさは依然として続きました。
上司を説得する能力の低かった私は、結果として開発効率を上げる事ができず
ひいては、社内の生産性を理想値より下げてしまいました。
今は反省しています。
