次世代のプログラマブルロジック開発者

その昔、論理合成の時代より前のこと、エンジニアは純粋なロジックによるシステムの設計依頼を受けたかもしれない時代がありました。その当時、レーダはありましたがマイクロコントローラはなく、デジタル信号処理はありましたが、すぐに入手可能なデジタル信号プロセッサはありませんでした。にもかかわらず、デジタル処理のレーダはありました。

当時、新卒のエンジニアは、アナログとデジタルのハードウェアの設計方法、そしてソフトウェアの開発方法に詳しいことが期待されました。私は、エンジニアが幅広く多方面の知識を持つ時代が過ぎ去ることに不安を感じ、ロジック設計の将来が心配です。もし大工の工具箱にハンマーしかなければ、すべての問題が釘に見える、と言う格言があります。今、すべての問題がソフトウェアの問題のように見える時を迎えているのでしょうか？

「FPGAアプリケーション」というキーワードでネットを検索すると、電気工学の最前線にあるアプリケーション、人工知能や音声認識から通信や画像処理に至るまで、幅広いアプリケーションがずらりと並びます。これらのアプリケーションの問題は、シンプルでなく初心者向けではないことです。これらのアプリケーションの実装をマスターする学習曲線は急勾配で、学習にはそれほど簡単でないトピックも含まれます。

この分野を志すなら、プログラマブルロジックデバイス自体や、それらの統合開発環境（IDE、どのメーカーにもある独自環境）、新しいプログラミングパラダイム（ハードウェア記述言語（HDL）およびその同時並行性と時間の概念の適応性など）を学習し、アプリケーション自体を理解する必要もあります。これらは、専門家を除けば、実際には乗り越えがたい高い壁です。これでは、プログラマブルロジックのスキルを自力で習得しようとする次世代のロジック設計者には、先が思いやられます。最初のステップから難しすぎるのです。この分野で活躍しようとする意欲が妨げられては、将来、プログラマブルロジックに熱意を傾ける人が激減するでしょう。プログラマブルロジック設計の現況に不満をぶつける多くのコメントがインターネット上にも現われており、その解決に取り組もうとするいくつかのオープンソースコミュニティもあります。多くの人々は、この状況を救うのはメタプログラミング（あるプログラムが別のプログラムをデータとして扱うプログラミング手法）だと感じています。

プログラマブルロジックの企業は、身動きの取れない立場にあります。これらの企業は投資家から一段と高性能で高価なチップの開発を求められる一方、そのようなチップを駆使できる人はあまり多くありません。企業は解決策として、ソフトウェア開発者をハードウェアの設計者に転向させており、その際に新たなツールを役立てています。

高位合成（HLS）コンパイラは、設計の抽象化をさらに高いレベルに引き上げますが、これによりロジック設計のルーツからも遠ざかることになります。高度なハードウェア設計を純粋なソフトウェア記述から作り出せるのはそれなりに注目に値しますが、この手法では、ロジック設計が持つ理屈抜きの魅力を実感できないでしょう。コンピュータを「さらに最適化できる」かどうかはさておき、私は昔のほうがシンプルな回路をより簡単に設計できたと言いたいのです。問題は、今ではシンプルな回路を設計するのが以前よりも難しいということです。

私は、自分で手作りしたロジック設計が実際に動作する回路を見て、本当に喜んだのを覚えています。工夫を凝らして、必要なデバイスの数を最小限に絞り込んだものです。1990年代始めにプログラマブルロジックを学んだとき、回路設計の知識を総動員して128個のロジックエレメントを含む単一デバイスにロジックを実装できたときは、さらに嬉しかったものです。自分で考え抜いて個々のロジックエレメントをすべて選んだのです。聞き覚えのないアルゴリズム開発者の知識には頼りませんでした。

ロジック設計の進化とともに、ソフトウェア設計も進化しました。ソフトウェア設計はオブジェクト指向プログラミング（OOP）が主流になりつつあり、一般に見られる設計パターンライブラリはドキュメントとして良く整備され、コードライブラリですぐに利用できます。私の設計パターンの資料は、Erich Gamma他の著書「Design Patterns, Elements of Reusable Object-Oriented Software（オブジェクト指向における再利用のためのデザインパターン）」です。ハードウェアの設計がオブジェクト指向として始まったのは興味深いのですが、その発展はHDLの登場で行き詰りました。HDLは設計の再利用に適合しますが、設計ライブラリには最も基本的な機能が含まれています。インターネットで「7400シリーズ集積回路のリスト」を検索すると、初期のハードウェア設計パターンが見つかります。Meilir Page-Jonesが彼の著書「Fundamentals of Object-Oriented Design in UML（UMLにおけるオブジェクト指向設計の基礎）」の中で、凝集度が高く結合度が低いオブジェクト設計の好例として集積回路を取り上げているのは興味深いことです。しかし、より複雑なプログラマブルロジックデバイスを追い求める中で、シンプルで直接的なロジック設計のルーツからは遠ざかりました。今の設計方法論は、コンピュータのアルゴリズムに頼って我々のロジックを実装するものです。私はこのアプローチがプログラマブルロジックの初心者にとって障壁になると考えています。

「テレビの後部に接続して映し出した最初のPongゲームには、何行のコードがあったか？」と聞かれれば、答えはゼロです。これは純粋なハードウェアで（図1参照）、ソフトウェアは含まれていませんでした！おそらく、新卒エンジニアの多くはソフトウェアを使わずにPongを設計できないはずです。 「そんな必要あるの？」と問われれば、「少なくとも、それが可能なことを知っておくべきでしょう。思うほど難しくないですよ」と言うのが私の答えです。

図1：Pongの回路図（画像：Adafruitのブログから入手、出所不明）

IEEEは2019年初頭に、エンジニアに愛用/敬遠されているプログラミング言語のリストを公開しました。それによると、エンジニアの愛用プログラムはPythonです。その通りでしょう。私は数年前にTexas Instrumentsの設計コンテストで審査員を務めましたが、私の知る限り、10の大学チームのうち9チームがプロジェクトにPythonを使用していました。IEEEのリストでは、VHSICハードウェア記述言語（VHDL）とVerilogは、愛用/敬遠のどちらにも含まれていませんでした。IEEEの編集者は、これらのHDLプログラミング言語が眼中になかったかもしれません。というより、調査対象の誰もがHDLを気にかけていなかったのでしょう。もしそうなら、これらの言語、またはロジック設計を念頭に置くエンジニアがいかに少ないかを意味します。ロジック設計分野の将来に暗雲が垣間見えます。

では解決策は？新しいエンジニアに、問題を見据えてその解決策をソフトウェアまたはハードウェアに求めるように考えてもらう方策とは？結局のところ、ほとんどの問題はどちらでも解決できます。私に1つのアイデアがあります。

皆様ご存じのArduinoプラットフォームは、ソフトウェアに興味を持つ若者を数多く生み出しました。こうした若者は、エンジニアやコンピュータ科学者を目指して学校に入学しています。Arduinoはどのようにこれを成し得たのか？まず、ソフトウェア開発の学習曲線を短縮しました。ソフトウェア開発をより手軽にしたのです。

基板を定義することで、リンカコマンドファイルの設定を不要にできました。また信号名が標準になり、IDEによってコンパイルの細部が隠れました。Pythonの美しさの1つは、厳密な書式設定が必要なことです。たとえば、インデントは統一しなければなりません。これにより、あまり意味のない任意の選択がなくなり、開発プロセス全体がよりシンプルになる効果が生まれ、開発者の生産性向上につながるのです。プログラマブルロジックにも、これに相当するものが必要です。プログラマブルロジック業界は規格化に向けて手を組むべきでしょう。

以下は、私がその規格に提唱している内容の一部です。Arduinoにはネストされた割り込みへの適合などの基盤となるアーキテクチャを変更する固有の堅牢な機能がないように、このプラットフォームで解決すべきロジックの問題は、今のプログラマブルロジックデバイスがすべてのタイミングの制約に対応できるくらい単純だと仮定しましょう。Arduinoに相当するプログラマブルロジックデバイス基板（PLDB）には、1,000ロジックエレメントの設計が機能するのに十分遅いクロックが必要です。つまり、プラットフォームには機能の検証さえあればよいということです。

誰もがPythonを愛用するので、PLDBがPythonでサポートされること、nMigenやMyHDLのようなフレームワークで構築されるか（図2参照）、またはRTLILを含むYosysによって構築されることを提案します。これにより、初心者はインタープリタ言語で各自のロジック設計をシミュレートし、真理値表を作成し、利用可能な他のPythonライブラリにアクセスできます。Pythonのライブラリについて言えば、Pythonを使用することで、コミュニティはPythonパッケージインデックス（PyPI）を使用して再利用可能なハードウェアブロックを配布し、堅牢な共有設計パターンの欠如にも対処できます。nMigenはPythonと同様にメタプログラミングをサポートするので、このフレームワークはシンプルな設計をサポートするものですが、プラットフォームは複雑な設計もサポートするように拡張性をともないます。

図2：Pythonベースのフレームワーク（画像提供：MyHDL.orgおよびm-labs.hk）

ホストPCからPLDBへのインターフェースにはUSBを使用し、同時にAPIとともにPLDB組み込みマイクロコントローラを用いてホストPCがPLDBの構成を学習できるようにします。これにより、プログラマブルロジック開発用のPython環境の自動セットアップが可能になります。このようなセットアップによって、合成、配置、ルーティング、プログラミングの細部が隠れ、PCでの機能的なシミュレーションや実際のハードウェアでの実行が容易になります。

解決すべきシンプルなロジックの問題はもうないとお考えの読者のために、Digi-Keyのマイクロコントローラ販売に関する統計をいくつかご紹介します。図3に、お客様が購入しているマイクロコントローラのクラス内訳を示し、図4に各クラスの販売数を示します。合計で、Digi-Keyのサイトでは80,000を超えるマイクロコントローラの部品番号が表示され、マイクロコントローラの在庫数は19,000を超えており、世界中のあらゆる場所にすぐに発送できます。この図からは、シンプルな8ビットプロセッサがより多くのエンジニアに使用され、Digi-Keyが他のどのプロセッサクラスよりも多く8ビットマイクロコントローラを出荷していることが分かります。この実績から、複雑な問題よりも単純な問題が多くあることが見えてきます。

図3：各タイプのマイクロコントローラを購入しているDigi-Key顧客数（画像提供：Digi-Key Electronics）

図4：Digi-Keyで販売されている各タイプのマイクロコントローラの数（画像提供：Digi-Key Electronics）

私たちが目指すべきなのは、たとえロジック設計の正式な教育を受けていない人でもプログラマブルロジックを好きになることです。しかし、そのためには開発パラダイムを変える必要があるでしょう。