このページは、プロの FPGA 設計者になるためのページシリーズの 5 ページ目、最終ページです。これまでとは違い、技術的な話はしません。代わりに焦点を当てるのは、私たち人間としての姿と、どんな特性が FPGA 設計者の人生をより楽でより良くするかです。
これは実際に重要なこと
FPGA 設計者の性格や姿勢について話すのは、とくに技術的なテーマを扱うウェブサイトでは奇妙に思えるかもしれません。しかし、これから FPGA 設計者になる人のためのガイドなら、すべてを掌握して仕事をするのと、完全な混沌の中で仕事をするのを分ける人間的資質や行動についても論じるのが適切だと思います。
事実上どの職業にも適した性格というものがあります。人付き合いが苦手なら自動車販売員は難しいですし、子どもが好きでなければ良い教師にはなれません。同じように、FPGA エンジニアとして助けになる性格特性もあれば、そうでないものもあります。
説教するつもりも、誰かをやる気なくさせるつもりもありません。「努力しなければならない」と言うのでもありません。むしろ逆です。意図は、物事を正しく行い、より少ない労力で目標に到達することです。
このページでは、この職業と穏やかに付き合っていくために、あれこれの専門知識に加えて、成功する FPGA 設計者になるには何が必要かを描いてみます。このページはエンジニアの性格についてのものです。自制心と自己コントロールがあり、正確なタイプであるほうがよい、というのは驚きではないでしょう。細部への少しの執着も害にはなりません。
ただし、これを人生で苦しむとか、死ぬまで働くとかいう考えと混同しないでください。逆です。あるやり方で仕事を進める能力があれば、より速く、より楽に片づきます。楽しく、やりがいがあります。最初から正しく仕上げることが理想であり、それは達成可能です。
一方で、以下の理想的な FPGA 設計者像に、自分はまったく当てはまらないと感じるなら、うーん、何と言えばいいでしょうか。この考え全体をもう一度よく考えてみてはどうでしょう?
「動く」だけでは十分ではない
ソフトウェアの世界、とくにウェブサイトやアプリでは、とりあえず何か書いて、試して、おかしいところを直してまた試す、というのが一般的なやり方です。AI を使えばコードを書く段階すら飛ばし、機械がコーディングとテストの両方を行い、最終的に結果を Git リポジトリにコミットします。
根底にある考えはこうです。コードがテストに通れば、仕事は完了です。まだバグがあれば、QA が見つけるか、ユーザーからの苦情がまもなく届きます。その場合は、標準的な手順として修正依頼が出されます。そしてバグを直す。多くのソフトウェアチームは、まさにこう動くように構成されています。
このやり方がソフトウェア開発に適しているかどうかは別の議論です。私がはっきり言いたいのは、プロの FPGA 設計にとってこれは深く間違っているということです。FPGA プロジェクトでは「動く」だけではまったく十分ではありません。ホビイストならともかく、実際に量産されるプロジェクトでは絶対に不十分です。とくに長時間のデバッグの末にようやく何かが動いて嬉しくなり、そこで終わりにしたくなるのは、この罠に落ちやすいところです。
純粋主義的な説教に聞こえるかもしれませんが、これは単純な真実です。信頼できる FPGA 設計を得る唯一の方法は、自分が設計したものが必ず動くことを、一度きちんと自分自身に証明することです。設計がすべてのテストに通ったときではなく、失敗するはずがないと自分を納得させられたときにだけ、タスクは完了です。
これを数学の定理と比べてみましょう。数回数値で試して毎回正しかったから正しい、とは言いません。数学的な証明が得られたときに、その式は正しいと考えるのです。
実際には、これは Verilog ファイルの各行を数学の導出における式のように扱うという意味であり、タイミング制約 (timing constraints) やその他の関連するソースファイルも同じです。少し極端に聞こえるかもしれませんが、これだけ注意深くやることは長い目で見て報われます。
FPGA と他の電子部品との接続も同じです。動いたからといって電気的なインターフェースが問題ないと仮定してはいけません。データシートの要件が満たされていることを自分に証明します。FPGA のデータシートのものも、他の部品のものもです。電圧レベルは正しいか? 両側のすべてのタイミング要件が満たされることを FPGA 設計が保証しているか?
では、私の設計は常にバグがないのか? もちろん違います。私は人間で、間違いを犯します。数学の証明を完璧に仕上げられないことがあるのと同じです。コーナーケースの確認を忘れることもありますし、プラスとマイナスを入れ替えて全体を台無しにすることもあります。
しかし、この厳密なアプローチの良いところは、最終的に残るわずかなバグがたいてい明白で、比較的簡単に直せることです。そして一度直せば、設計はそのまま動きます。バグも謎も魔術もありません。堅牢に動く電子回路です。
それは、目標に素早く到達するための遅い道です。
人は本当にこんなに厳密に仕事をするのか?
短い答え:間違いなくノーです。とくにフリーランサーだった頃にそれを痛感しました。新しい顧客ごとに、私の最初の仕事は FPGA プロジェクトを安定させることでした。これは救急室で医師が患者を安定させるのに少し似ていました。そしてプロジェクトを担当していたエンジニアたちも、長いストレスと欲求不満の後で、ある種の安定化を必要としているように見えることがよくありました。
とりあえず書いてからデバッグする姿勢は、残念ながら FPGA 業界でも一般的です。無理もありません。Verilog の講座では、シミュレータがソフトウェアの世界のデバッガと同じような精神で提示されることがよくあります。根底にある提案は、試行錯誤で望む結果に到達するというものです。コンピュータ上で動くまでシミュレーションし、次に論理合成して、ハードウェアでも動くまで直すのです。
さらに悪いことに、この種の仕事のやり方を奨励する管理職もいます。彼らは結果を見るのにせっかちで、問題なさそうなものを見ると、次のタスクに移ることを期待します。スケジュールは厳しく、「バグは後で直す」のです。
このアプローチの結果として、本当に信頼できる FPGA 設計を得るのは難しく、ときに不可能です。これはシミュレーションでの大規模な回帰テストや、ハードウェアでの大規模なテストで補われます。企業によっては、FPGA を搭載した基板が生産ラインを離れる前に、製造されたすべての基板で温度試験を行います。出荷前のハードウェアテストは、独自のハードウェアとソフトウェアを持つ独立した部門になり、その目的はただ 1 つです。FPGA が本当に果たすべきことを果たしているか確認することです。
その裏には、非常にストレスを抱えた FPGA エンジニアがいます。謎のように現れては消えるバグを必死に追いかけ、スケジュールに遅れています。
いつもそんなにひどいわけではありません。FPGA が比較的低い周波数で動き、要件が単純で、散発的な失敗がそれほど大問題でなければ、試行錯誤の姿勢でもかなりうまくいくことがあります。
それに現実には、FPGA を扱うほとんどの人はその中間あたりにいます。Verilog を数学の式と見なす極端なところまではいかなくても、忍耐力、自制心、正確さへの敬意を高めに持っています。そうやって彼らはこの分野で仕事を成し遂げているのです。
自分が何をしているかを知る
FPGA では試行錯誤は進むべき道ではない、と納得していただけたなら、より厳密で正確な道が必要なことは明らかです。しかし、それだけでは十分ではありません。厳密な姿勢も、自分が何をしているかを正確に理解していなければ役に立ちません。
たとえば、Verilog コードで非同期リセット (asynchronous reset) を見かけるのは非常によくあります(前のページでも触れました)。これはロジックをリセットする正当な方法ですが、正しく使った場合に限ります。ほとんどの場合、このリセットは誤って使われており、したがってロジックが期待どおりに動くことを保証しません。でも現実には、すべてうまく動きます。たいていは。このテーマについては別のページがあります。
非同期リセットが誤って使われる理由は、おそらく人が他の情報源から Verilog コードをコピー&ペーストして自分のものにしているからでしょう。そのコーディングパターンはあまりに馴染み深く明白なので、それが実際に何を意味するのか立ち止まって考えません。そしてこの場合、何を意味せず、何を保証しないのかもです。
自分が何をしているかを知ることは、自分の設計が必ず動くと自分に証明できるための前提条件です。これは、各 Verilog 式が何を意味するのか、そして論理合成ツール (synthesizer) がそれをどう解釈するかもしれないかを正確に理解することを意味します。同じ原則は、タイミング制約 (timing constraints) や、FPGA 設計に関連して開発ツールが消費するその他の情報にも当てはまります。
しかしすでに認めたとおり、ほとんどの FPGA 設計者は設計が動くことを証明できるほど厳密ではありません。それでも、自分が入力するものの正確な意味を知ることは、正しい方向への一歩です。
抽象的に考える
コンピュータサイエンスの学術コースを取ったことがあれば、ソフトウェアを記述するために抽象的な生き物がどう発明されるかを見たことがあるかもしれません。たとえば、常に特定の方法で整理されるデータ構造、クラスとオブジェクト、データの流れ、ループの各反復後に保たれる不変条件などです。コンピュータサイエンスでは、人間が内部の細部を見過ごし、代わりにより単純な表現と関われるように、架空の生き物が絶えず発明されます。これにより脳の負荷が減り、複雑なソフトウェア設計を理解できるようになります。これが抽象化 (abstraction) と呼ばれるものです。
抽象化の反対側には、具体的な考え方があります。あるいは「物語る」思考と呼びましょうか。この姿勢では、コンピュータプログラムは物語のように扱われます。まずこれをして、次にこれをして、これが真ならこれをし、そうでなければあれをする。コードに指を這わせて出来事の順序を追えば、すべて理解できるというわけです。
物語る思考は、単純なスクリプト (script)、ウェブサイト、モバイルアプリ、その他の単純なソフトウェアの開発にはよく効きます。ユーザーがこのボタンを押したら、この画面やウェブページへ行き、そこから先はそのまま、という具合です。ソフトウェアは 1 本の単純な実行スレッドで進み、1 本の思考の流れで理解できます。
この 2 つの考え方の違いを例で示したいと思います。n の階乗 n! を計算する、C で書かれた次の関数を見てください。
unsigned int factorial(unsigned int n) {
if (n == 0)
return 1;
return n * factorial(n - 1);
}
これは再帰の古典的な例です。上のコードをどう理解しますか?
物語るやり方は「試してみる」ことです。こんな感じです。「関数が n=3 で呼ばれたとしよう。これは自分自身を n=2 で呼び、次に n=1、そして n=0 で呼ぶ。さて展開すると、n=0 の呼び出しでは 1 を返し、次に 1*1、次に 2*1 を返し、最後に 3*2、つまり 6 で、これが正解だ。よし、動く」。この思考過程はデバッガでステップ実行しながら行われることもあるでしょう。
もう 1 つのやり方は、数学的帰納法による証明に似ています。関数が実際に n の階乗を返すと仮定し、n-1 で成り立つなら n でも成り立つことを確認します。最後に n=0 で正しい値を返すこと、そして再帰が常に n=0 に行き着くことを確認します。実行の順序は無関係で、関数はただその目的を果たす抽象的な生き物として扱われます。
そしてこう尋ねるかもしれません。なぜ複雑にするのか? 物語る説明で十分だったではないか。これにはこう答えます。はい、でもそれは例が単純だったからうまくいっただけです。
そしてここでようやく本題です。ソフトウェアを理解するのに物語るやり方しかできないなら、それは FPGA 設計者としての障壁になります。第一の明白な理由は、FPGA ではすべてが同時に起きるからです。FPGA の中で「まずこれ、次にあれ」で説明できるものはごくわずかです。
第二の、より重要な理由は、FPGA 設計はしばしば複雑だということです。何が起きているかを頭で把握するには、しばしば抽象化が必要です。たとえば、Verilog モジュールを、その機能が細部に立ち入らず数文で説明できるように定義するのは良い習慣です。そのポートへのインターフェースも単純に説明できるべきです。複雑なロジックブロックをいくつかの単純なアイデアに還元できれば、人為的ミスの可能性は小さくなります。この原則はソフトウェアにも当てはまりますが、いつもそれほど決定的とはかぎりません。
抽象的に考える第三の理由は、自分自身に正しさを証明する能力に関係します。物語るやり方では、自分が考えられるシナリオしかカバーできません。本当の証明はすべてをカバーします。
複雑なタスクに取り組むときは、Verilog を 1 行書く前に新しい理論的な生き物を発明する必要があるかもしれません。たとえば、データパケットを入力も出力もするモジュールが必要なら、N をそのメモリバッファに現在格納されているパケット数と定義すると役立つかもしれません。これにより、バッファが決して満杯にならないことを証明できます。大したことではないように聞こえるかもしれませんが、数学的思考へ踏み出すこの一歩は大いに助けになります。モジュール内のすべてのロジックが、この N を正しい範囲内に保つことに何らか関係している、ということもよくあります。
コツは、ロジックを正しくするのに本当に役立つ正しい抽象的な生き物を見つけることです。これは、数日間 Verilog を 1 行も書かず、その後突然短い Verilog モジュールをとても速く書き上げることを意味するかもしれません。こうして着想されたコードは、しばしば短く、エレガントで、理解しやすく、最初の試みで動き、その後もずっと動きます。
ただし、上司に毎日何をしているのか聞かれると、これはうまくいかないかもしれません。数日間は見せるものがないのです。そしてようやく何かを思いついたとき、「こんな些細なモジュールだけ?」と言われるかもしれません。
ですから繰り返しますが、FPGA 設計に対して純粋に数学的であることが誰にでも必要な道とはかぎりません。それでも、もし物語る癖があるなら、それを捨てることをおすすめします。
ツールを信用しない
より正確に言えば、開発ツールは恐ろしい間違いを犯すのを止めてくれません。警告すらしてくれないこともあります。
世界のどのソフトウェアコンパイラも、ソースコードが要求するのとは違うことをする実行コードを生成したりはしません。もししたら、バグを報告しましょう。一方、論理合成ツールは、Verilog コードが要求する動作を満たさないロジックを生成することが十分ありえます。運が良ければ、それについて警告が出ます。さらに運が良ければ、論理合成ツールが吐き出す何百もの無害なメッセージや警告の中からその警告に気づくでしょう。
FPGA 開発スイートの他の部分も厄介な悪戯をしかけることがあります。最も明白なのは、ほとんどのツールが、タイミング制約 (timing constraints) が満たされていなくても、FPGA にロードできるビットストリーム (bitstream) を生成してしまうことです。つまり、FPGA は論理合成ツールが意図したとおりに動くかもしれませんし、動かないかもしれません。あるいは少し動いてから動かなくなるかもしれません。警告、あるいはクリティカル警告 (critical warning) が出ます。しかし、ソフトウェアコンパイラがコンパイルを終えて、動かないかもしれない実行ファイルを出すでしょうか?
ツールが止めてくれないまま FPGA 設計を台無しにする方法は無限にあります。これはある種の文化のようなものです。誰かが意図的に FPGA を扱いにくくしたいかのようです。
私はいくつかの異なる FPGA ベンダーと、かなりの数の FPGA 開発ツールで仕事をしてきました。それらすべてが物事を難しくする同じ傾向を持ち、安全網は望むべくもないというのは、なかなか興味深いことです。特定の、安価で邪悪な FPGA ベンダーが 1 社あるわけではありません。すべてのベンダーがそうです。
そのうえ、FPGA 開発ツールにバグがあることも珍しくありません。運が良ければ、プロジェクトをビルドしようとしてクラッシュしてくれるので、少なくとも設計を誤動作させるバグにはなりません。しかし、ビットストリーム (bitstream) の欠陥につながるバグは、頻繁ではないにしても起きます。新しい設計スイートがリリースされたときはもっと厄介です。FPGA の世界では、最新のものが必ずしも最良とはかぎらない、というのは控えめな表現です。
とはいえ、自分の設計が動かないからといってツールを疑ってはいけません。とくにこの分野に慣れていないうちは。そしてツールが失敗したと思うなら、動かぬ証拠を見つけましょう。FPGA 内で、こうなるはずが別のものになっていたロジックセルを見つけるのです。こうなったのは本当にツールのせいだと自分を納得させましょう。ツールがおかしいと感じるだけでは不十分です。そう見えるものには、ほとんど常にもっと単純な説明があります。
とくに、Verilog コードの無関係な部分を変えたらバグが消えたとしても、それはツールにバグがあるという意味ではありません。そうした挙動は、むしろ定義の甘いタイミング制約 (timing constraints) やその他の似た誤りの典型です。
この開発ツールの問題に対処する鍵は、繰り返しになりますが、自分が何をしているかを知ることです。このテーマに限って言えば、ツールが出す警告やメッセージを読み、それらが何を意味するのか、少なくとも大まかに何に関係するのかを理解することです。どの警告が無害で、いつも現れ、無視でき、無視すべきかを学ぶのは経験の問題です。なぜツールがバージョンを重ねても多くの無駄な警告を出し続けるのかについては……文化の話をしましたっけ?
ですから、ときどきすべての警告にざっと目を通し、目立つものがないか見るのは良い習慣です。すべてが完璧に動いているときにも、いやとくにそういうときにやりましょう。「動く」だけでは十分でないからだけでなく、どの警告が無害かを学ぶ方法としてもです。
そして実際、いくつかの警告は、あなたが正しくやったことの証拠でもあります。たとえば、あるレジスタが定数値を持つか別のレジスタと等価なので設計から削除された、という警告です。それは少し立ち止まり、文脈上それが理にかなっているかを考える機会です。こうした警告は、自分のコードについて興味深い事実に気づく助けになることがよくあります。
要件から設計へ
ソフトウェアを書くときは通常、要件と書くべきものの間にかなりまっすぐな線があります。とくに単純なソフトウェア(たとえばウェブサイトやモバイルアプリ)ではそうです。
FPGA 設計では、それほど簡単ではないかもしれません。FPGA への要件は、しばしば「部品はこれで、こう振る舞ってほしい」という形で語られます。
たとえば、カメラセンサ、FPGA、そして別のユニットへ向かう配線がある基板が構成だとします。タスクは、カメラセンサから画像を取り込み、ピクセルに基本的な信号処理を施し、雇用主が定める映像データ伝送用の特定フォーマットに従って、出力を別のユニットへ送ることです。
あなたは FIFO、ステートマシン (state machine)、パイプライン (pipeline)、RTL 設計についてすべて知っています。では、求められているものを作るにはどうするのか? 「ステートマシンを書け」と誰かが言ってくれるわけではありません。動くものを作ることが期待されています。
運が良ければ、要件は過去の多くのプロジェクトに似ています。ブロック図をコピーし、ロジックを真似し、いくつかの部品をコピーするかもしれません。しかししばしば、プロジェクトの要件に、そうした模倣を不合理にする何かがあります。
そのとき、あなたは FPGA アーキテクトにもなります。タスクをどう機能単位に分割し、それぞれが何をし、どう相互作用するかを決めるのです。プロジェクトのごく初期にこれをうまくやるほど、プロジェクトを書いて保守するのが楽になります。あまりにも多くの場合、より良いものがないために、既存プロジェクトのブロック図が新プロジェクトに押し付けられます。この近道には代償があります。
では、どうすれば良いアーキテクトになれるのでしょうか。多くは経験から来ますし、他のプロジェクトで選ばれた解決策を観察することからも来ます。先に抽象化について述べました。自分自身のものであれ他人のものであれ、設計を抽象的な言葉で理解することは、次のプロジェクトをより良く作る助けになります。Verilog モジュールを、短い名前で呼べるタスクを実行する機能ブロックとして見れば、自分のプロジェクトに使えるパレットが手に入ります。いくつかの配線が 2 つのモジュールをどう接続しているかを見て、その配線を通じたモジュール同士の相互作用に名前を付けられれば、新しいプロジェクトの各部分がどう相互作用すべきかを決める上でより良い立場に立てます。既存設計の中の理論的な生き物を認識するのが得意なほど、新しい設計を作るのも上手になります。
FPGA アーキテクトの部分が難しく聞こえるなら、小さな秘密を打ち明けましょう。本当に難しいのです。私は何度かこれをやりましたが、時間も後悔も大量に必要です。この初期段階での小さな間違いは、それぞれ重大な結果を招きます。
ただし、おそらくプロジェクトをゼロから設計する必要はないでしょうし、まして FPGA に慣れていない人ならなおさらです。このタスクは通常、チームで最も熟練した FPGA エンジニアに与えられます。ですから、システムアーキテクトの帽子をかぶるまでは少し時間があるでしょう。たとえチームで唯一の FPGA エンジニアとして雇われたとしても、既存コードを保守したり、既存プロジェクトを基に新プロジェクトを開発したりする可能性が高いです。
しかし、このタスクへの準備を始めるのに早すぎることはありません。
まとめ
多くの意味で、このページの主なテーマは、さまざまな形の自己規律でした。それは、しばしば人間的とされる行動を克服する能力です。不正確に、まずよく考えずに物事を行い(とくに Verilog コードとタイミング制約 (timing constraints) を書くこと)、後から間違いを直す(シミュレーションとハードウェアでのデバッグ)こと。何かが動いて喜び、次のタスクへ進みたくなること(「動く」だけでは十分ではありません)。物事を単純で自然な(物語る)方法で自分に説明し、その背後にある抽象的なアイデアを探そうとしないこと。ツールが出す警告のような、小さく退屈な細部を飛ばすこと。
私たちの人間性は、残念ながら FPGA 設計者としての私たちの敵です。しかし、私が努力することについて何も言っていないことに注意してください。仕事が片づくなら、より少ない仕事を目指すことは怠惰ではありません。目標は実際には、より少なく働きながら、より良い結果を得ることです。正しくやればそれは可能です。
これはロボットになることでもありません。仕事人生において自己コントロールと正確さを持つことですが、機械のように働くことでは決してありません。私たちには人間の脳が必要です。ロボットは何時間も働けますが、私たちの脳は疲れます。自己コントロールとは、長く退屈な一日の後に机を離れて休むことでもあります。たとえそのバグがまだ残っていても。
そしてこのシリーズ全体をまとめると、もう明らかなはずですが、FPGA 設計は最も単純な職業ではなく、その理由をかなり挙げてきました。常にエレクトロニクスについて新しいことを学ぶのが嫌なら、これはあなた向きではないかもしれません。物事を徹底的かつ正確に行う自己規律があると思えないなら、それも考え直す理由です。
そして、ここまでで私があなたを怖がらせることに成功しなかったなら、クラブへようこそと言い、最高の幸運と技術を祈ります。そして何より、私と同じくらいこの選択を楽しんでくれることを願っています。