Hardware Rich Development

日付

著者

Hardware Rich Development

透明性、T型エンジニア、そしてFPGA:Jami Friedmanインタビュー

日付

初回公開日

August 28, 2025

シリーズ全体を読む

/ 6

この記事は、Quilterの物理法則に基づくレイアウト自動化を使い、NXP i.MX 8M Mini搭載コンピューターを再現した過程を詳しく紹介するシリーズの一部です。 

威勢よく名乗りを上げるリーダーもいれば、自分が知らないことの「回路図」をさらけ出し、そこから信頼を築いていくリーダーもいます。Leaf LabsのExecutive VPであるJami Friedmanは、後者に属します。

Leaf Labsが作っているのは、消費者向けアプリでも、話題性を狙ったAIデモでもありません。彼らが取り組むのは、よりハードウェアに近い領域、つまりファームウェア、FPGA、低レベルコンピューティングです。それ以外のすべてを可能にする、目立たない土台です。そしてJamiは技術畑の出身ではありませんが、現在は、私がこれまで出会った中でも最も技術リテラシーの高い小規模チームのひとつで、オペレーション、プログラムマネジメント、事業開発を統括しています。

彼女の歩みは、自分が何を知らないのかを見極め、それからスポンジのように吸収することから始まりました。

「私のやり方は、その場に身を置いてすべてを吸収することでした。きっと多くの失敗をしたと思います。でも、抜け出す唯一の方法は、やり抜くことなのです。」

コードの外側から始まったキャリア

Jamiは、組み込みLinuxのデバッグやDDRの配線で経験を積んだわけではありません。彼女の出発点は人とプログラムでした。最初はBose、次にAmazon、そしてPerkinElmer。彼女の強みはシリコンではなくプロセスでした。当初は、分野が違ってもプログラムはプログラムだと考えていました。ハードウェアは、そうではないことを彼女に教えました。

「設計を確定させた時点で、本物のお金を使うことになります。リードタイムもあります。もう後戻りはできないのです。」

それがハードウェアの厳しい現実です。ソフトウェアと違い、明日パッチを配信することはできません。インピーダンス目標を外したり、戻り経路が分割プレーンをまたいだりすれば、何週間もの待ち時間と数千ドルの損失につながります。

シグナルインテグリティのミスで試作が頓挫するのを見たことがある人なら、その痛みを知っています。配線がギャップをまたぎ、ビアが不格好なループを生み、アイパターンが崩れる。机上では回路図は機能していました。しかしラボでは破綻します。こうしたミスは、プロジェクトを遅らせるだけではありません。ロードマップ全体を脅かすのです。

この現実に対するJamiの敬意は、教科書から得たものではありません。エンジニアと同じ部屋に座り、略語の裏にある論理に耳を傾け、勢いが止まらないようにすることから生まれたものです。

計測器や吊り下げられた機器が置かれた実験台の古い写真。

FPGAの実践:タイミング、エッジ、そしてトレーサビリティという規律

ハードウェアにおける理論と実践のギャップを露呈させる分野があるとすれば、それはFPGA設計です。美しいRTLを書くことも、延々とシミュレーションすることもできますが、タイミング、クロック、リセットといった物理的な現実を見落とせば、誰が主導権を握っているのかを基板が思い知らせてくれます。

だからこそ、優れたFPGAエンジニアは謙虚さと厳密さを同じだけ備えています。EE JournalのKevin Morrisがよく言うように、FPGAは「ソフトウェアの習慣が死にに行く場所」です。プログラマブルに見えても、その本質はハードウェアです。そしてその違いが重要なのです。

物理の仕様としての制約

制約ファイルは単なる帳簿付けではありません。物理と論理がどう折り合いをつけるかを定める仕様です。Clive Maxfield(Design Warrior’s Guide to FPGAsの著者、通称「Max」)のような思慮深いエンジニアなら、制約は静的なファイルではなく生きたドキュメントなのだと教えてくれるでしょう。良い制約は明示的です。クロックには名前が付けられ、派生クロックは文書化され、フォールスパスやマルチサイクルパスは証明された場合にのみ存在します。後工程で見つかるバグの多くは、論理エラーとは無関係で、原因はもっぱらずさんな制約の扱いにあります。

クロックドメインクロッシング:エッジを尊重する

チームの成熟度を測りたければ、クロックドメインクロッシング(CDC)の扱い方を見てください。メタスタビリティは、ブロック図がどれほどきれいに見えるかなど気にしません。XilinxのKen Chapmanは、メタスタビリティを「サイレントキラー」と呼んだことで知られています。対策はわかっています。1ビット信号には2段フリップフロップの同期化回路、バスにはFIFO、カウンタがドメインをまたぐときには適切なグレイコード化です。それでも多くの障害は、ツールが「うまくやってくれる」とエンジニアが思い込んだことに起因しています。ツールは物理を防いではくれません。優れたFPGA設計者は、同期が証明されるまですべてのドメインを有罪とみなします。

リセット:後回しではなく規律として

リセットは、FPGA設計で最も過小評価されている部分かもしれません。デバイスと状況に応じて同期か非同期かを選びますが、選ぶなら意図的に選ぶべきです。リセットツリーは、クロックツリーと同じ厳密さで設計すべきです。ファンアウトに注意してください。解除シーケンスを検証してください。ラボノートに記された「断続的な」立ち上げの悪夢の多くは、決してランダムではありません。ずさんなリセット戦略の直接の結果なのです。

可観測性:デバッグのための設計

ZipCPUブログの著者であるDan Gisselquistのような専門家は、常に可観測性の必要性を強調しています。統合ロジックアナライザ(ILA)はオーバーヘッドではなく、命綱です。優れたFPGAエンジニアは、最初からフック、信号、デバッグバスを設計に織り込んでおきます。どんなシミュレーション環境もすべてを捉えられるわけではないことを受け入れているのです。可観測性こそ、ブラックボックスを透明なシステムに変える方法です。

フロアプランと物理的な意識

きれいなフロアプランは、未来の自分への思いやりです。すべてのスライスを固定する必要はありませんが、関連するロジックをそのピンの近くに置く、タイミングクリティカルなモジュールをまとめる、インタフェースに制約をかけるといった考え抜かれた配置が、終わりのないタイミングクロージャ作業と、すんなり動く設計との分かれ目になることがよくあります。長年Xilinxに在籍したエンジニアで、FPGA史の伝説的人物の一人であるPeter Alfkeは、若い設計者に「タイミングとは幾何学である」とよく言い聞かせていました。それを無視すれば、デバイスが思い知らせてくれます。

トレーサビリティと再現性

一度は動いたのに二度と再現できないビットストリームほど、苛立たしいものはありません。ツールのバージョンを固定してください。ビルドシードを記録してください。制約ファイルの正確なバージョンを保存してください。ラボの基板が立ち上げに成功したら、そのビルドを再現可能にしてください。優れたチームは、FPGAの成果物をソースコードと同じように、不変で、追跡可能で、レビュー可能なものとして扱います。

ジェネラリストの強み

そしてここが、Leaf Labsの理念とFPGAの実践が交わるところです。最高のFPGA設計者は、決してFPGA設計者であるだけではありません。自分たちの制約が、PCBの層構成の下流、組み込みソフトウェアの上流にあることを理解しています。トランシーバのレーンが失敗すれば、IPコアだけでなく、リファレンスプレーンや戻り経路も確認します。ジッタが現れれば、発振器、PLL、電源レールについて問いかけます。

質の高いFPGAの技について語られるときに名前が挙がる人々、Clive Maxfield、Peter Alfke、Ken Chapman、Dan Gisselquistには共通点があります。彼らはFPGAを単なるチップではなく、システムとして捉えているのです。それこそが、Leaf Labsがすべてのエンジニアに根付かせようとしている精神です。幅広さが、深さをより確かなものにします。

中核システムとしての人

Leaf Labsには略語があふれていますが、Jamiがエネルギーを注ぐのは別のところ、つまり人です。

「チームが幸せでなければ、他のことは何もうまくいきません。」

21人の会社では、これは決まり文句ではありません。緩衝材がないのです。エンジニアが一人苦しんでいれば、プロジェクト全体がそれを感じます。そしてLeaf Labsのエンジニアは幅広い役割を担うため、認知的な負荷は現実のものです。ここでのジェネラリズムは流行語ではありません。生き残るための手段です。

そのためには、くだらない質問をしても安全で、電気エンジニアが恥ずかしがらずに暗号技術をのぞき込むことができ、好奇心が出荷されたコードと同じくらい評価される文化が必要です。

それは、Leaf Labsが数百人規模への拡大に抵抗する理由でもあります。彼らの仕事は、透明性と人とのつながりに依存しています。成長のための成長は、その両方を壊してしまうでしょう。

多分野にまたがるエンジニアを育てる

Leaf Labsは、完成されたユニコーンを採用するのではなく、エンジニアをより幅広い役割へと育てます。選考の基準は、どの言語を知っているかではありません。システムをたどれるかどうかです。データがどう流れるかを順を追って説明できるか。あるレイアウト上の選択が、ファームウェアの制約にどう波及するかが見えるか。

「すべてにおいて専門家であることは期待していません」とJamiは言います。「でも、少なくともその言葉を話せる程度には、新しい領域に踏み込んでいくことを期待しています。」

これがT型エンジニアの論理です。ある分野での深い縦軸と、スタック全体にわたる幅広い横軸の組み合わせです。この形が、信頼性と適応力をもたらします。

Leaf Labsでは、システム思考を重視した採用により、適切な考え方を持つ若手エンジニアが、専門の狭いベテランを上回ることもあります。彼らは、経験豊富なプロが面接でつまずき、新卒者が活躍する場面を見てきました。その理由は単純で、一方はツールに注目し、もう一方はシステムに注目していたからです。

だからこそ、彼らの面接はメンタルモデルを重視します。そして候補者をランチに連れて行くのもそのためです。問い詰めるためではなく、その候補者を頼りにすることになる人たちと会ってもらうためです。

どこまでもシステム

Jamiは、エンジニアが基板について考えるように組織について考えます。細い配線はどこか。ボトルネックはどこか。負荷が偏っているのはどこか。

彼女の視点は、システムとしてのプロセスです。ハードウェアのプログラムは、依存関係とタイミング制約の集まりです。こちらで部品の発注、あちらでレビュー、その先にはテスト治具。どんなずれも、分割プレーン上の不適切なビアのように、設計全体に波及します。

「ビジネスプロセスインテリジェンスとそれほど違いはありません」と彼女は言います。「ただ、サプライチェーンを最適化する代わりに、デジタルロジックを最適化しているのです。」

この見方により、彼女のリーダーシップは流れを重視するものになっています。人とタスクの回路が、負荷の下で壊れないようにすることです。

ハードウェアとしての透明性

Leaf Labsは、自社名で製品を出荷しているわけではありません。彼らが出荷しているのは、他社のための信頼です。そうしたプログラムにおいて最大の差別化要因は、技術的な卓越性ではありません。コミュニケーションです。

最高のプロジェクトとは、コミュニケーションが絶えず、むしろ過剰なほど行われるプロジェクトです。散らかった作業台の写真。部分的な進捗についてのメモ。最終版を待つ代わりに、手早く撮ったスクリーンショット。

「私たちが何に取り組んでいるのか、クライアントに一度も疑問を抱かせたくないのです」と彼女は言います。

些細なことに聞こえるかもしれませんが、エラーが製造まで隠れているハードウェアでは、これがすべてです。過剰なコミュニケーションは時間を稼ぎます。選択肢を生み出します。これは、物理的なシステムに応用されたアジャイルの考え方です。より小さな単位、より速い可視化、より短いフィードバックループ。

ハードウェアがソフトウェアほど柔軟になることは決してありませんが、アジャイルの実践を取り入れれば、もろさは軽減されます。スプリントレビュー、日々のアップデート、早期の試作。透明性がそれを可能にします。透明性がなければ、アジャイルはスローガンに成り下がります。透明性があれば、ハードウェアチームは量産モードではなく開発モードで仕事を進め、エラーをまだ安く済むうちに発見できます。

足場としての構造

Leaf Labsには、200人規模の会社になるという野心はありません。野心がないからではなく、彼らの構造が意図的なものだからです。成長のための成長は、透明性を薄め、コミュニケーションを分断します。

「構造は私たちに自由を与えてくれます」とJamiは言います。「思慮深くあるための心の余裕を与えてくれるのです。」

ここでいう構造とは、官僚主義ではありません。創造性を支える足場です。ジェネラリストが混乱に陥ることなく、幅広くリスクのある仕事をするためのガードレールです。エンジニアがプロセスを一から作り直したり、互いの領域に踏み込んだりするのを防ぎます。

大企業では、構造は硬直化します。Leaf Labsでは、構造は生きています。引き継ぎは明示的で、コミュニケーションはリアルタイム、フィードバックループは短い。これは偶然ではありません。設計されたものなのです。

好奇心に根ざしたリーダーシップ

私が最も感銘を受けたのは、Jamiが何を知っているかではなく、知らないことにどう向き合っているかでした。好奇心を持って。ユーモアを持って。オープンな姿勢で。

「もし過去に戻れるなら、もっと質問をするでしょう。あんなに力ずくで押し通そうとはしなかったと思います。」

技術的な権威がしばしば芝居のように演じられる分野において、彼女のリーダーシップスタイルは人間的です。自分が学んでいる途中であることを隠しません。チームを、感情的な負荷がタイミング制約と同じくらい重要なシステムとして扱っています。

文化は、しばしば技術の成否を左右します。優秀なエンジニアがいても、自分の知らないことを認めても安全だと感じられなければ、その創造性を十分に引き出すことはできません。トップの好奇心は、システム全体に波及していきます。

基板、顕微鏡、オシロスコープ、測定ケーブルを備えた電子機器の実験作業台。

未来のハードウェアを築くための哲学

略語やプロセスチャートを取り除けば、残るのはシンプルな問いです。ハードウェアを出荷するとき、私たちはどんな世界を築いているのか。

ハードウェアは残り続けます。スペースも電力も注意も必要とします。ユーザーにリズムを教えます。信頼性と修理に対する期待を形づくります。大切に使われるよう促すか、無駄を招くかのどちらかです。チームが設計を確定させるたびに、人々がその物とどのように暮らすべきかについて、小さな賭けをしているのです。

だからこそ、プロセスには謙虚さが必要です。透明性は単なるマネジメント手法ではありません。倫理的な姿勢です。自分たちの仕事を見せ、批判を歓迎し、発売日だけでなく未来を見据えて設計するという宣言なのです。

未来のハードウェアのための哲学は、たとえばこんなものかもしれません。明快さのために作る。巧妙さよりも可観測性を優先する。隠れた結合を減らす選択をする。電力、タイミング、セキュリティを最優先事項として扱う。修理の余地を残す。いずれ誰かが引き継ぐものとして決定を記録する。実際に誰かが引き継ぐのですから。新しいエンジニアがすぐに議論に加われるツールとアーキテクチャを目指す。プレッシャーの下にある人間が筋道立てて理解できる設計を好む。

何よりも、文化を物理に合わせることです。早期の可視化を促す。落ち着いた問題解決に報いる。人々が勇敢になれるだけの構造を与える。それができれば、私たちは基板を出荷する以上のことを成し遂げられます。製品よりも長く残る働き方を伝えることができるのです。

Hardware Rich Developmentのための教訓

Jamiとの対話は、納期に追われる中で忘れがちな一連の真実を明らかにしてくれました。

  • 透明性は任意ではありません。ハードウェアにおける沈黙は、あまりにも高くつきます。たとえ荒削りでも、早めに共有しましょう。
  • ジェネラリズムは構造的なものです。最も価値のあるエンジニアは、領域をつなぎ、システムで考えます。深さは今も重要ですが、幅広さがレジリエンスを生みます。
  • 構造は自由です。優れたシステムは、エンジニアに混乱の重荷ではなく、考えるための余裕を与えます。
  • 好奇心はリーダーシップです。知らないことを認めるほうが、確信を演じるよりも多くの信頼を築きます。
  • FPGAのフローを尊重しましょう。制約、CDC、リセット、トレーサビリティは、どんなRTLブロックよりもスケジュールを左右します。

多くの点で、Leaf LabsはHardware Rich Developmentを体現しています。略語を積み重ねているからではなく、ハードウェアを回路であると同時に文化としても扱っているからです。彼らのアプローチは、論理のシステムを設計するのと同じくらい慎重に、人のシステムを設計することです。

それはおそらく、あらゆる技術リーダーにとってのより広い教訓でもあるでしょう。エンジニアリングとは、常にシステム思考です。唯一の問いは、どのシステムに目を向けるかということです。

‍

Quilterを実際に試す

Project Speedrunは、自律的なレイアウトの実際の姿と、Quilterが実現する時間短縮を示しました。次は、ご自身のハードウェアでお確かめください。

利用を始める

設計の検証

仕上げが完了したら、最後に確認するのはハードウェアが動作するかどうかです。電源投入時には電気的な不具合の多くが現れます。エンジニアにとって、緊張と期待が入り交じる瞬間です。

第4回に進む

設計の仕上げ

自律的なレイアウトにより、DRCを実施済みの完成した設計が得られます。仕上げは、製造に向けて最終調整するための短い精密な作業です。

第3回に進む

設計のコンパイル

設計の準備ができたら、次はQuilterに引き渡します。従来のワークフローでは、この段階でエンジニアとレイアウト担当者が設計意図を確認します。Quilterはこの打ち合わせを回路理解のプロセスに置き換えます。プロジェクトをアップロードし、制約条件がどう解釈されたかを確認して、ジョブを実行します。

第2回に進む