FPGAでPCIeを実装する基礎

FPGAでPCIeを扱うには、プロトコル知識だけでなく、トランシーバー要件・ボード配線・OSの列挙(Enumeration)まで一気通貫で設計し、LTSSMなどで段階的に検証することが近道です。
本記事では、PCIeの基本用語から実装方式(IP/DMA)、基板設計・コンフィグ時間の要件、ソフトウェア実装、性能設計、デバッグと典型トラブルまでを、実務で詰まりやすいポイント中心に整理します。
実務では、論理が正しくてもリンクが上がらない、PCに認識されない、速度が出ないといった問題が起きがちです。どの層で詰まっているかの見分け方も併せて解説します。
目次
- FPGA×PCIeでできることと代表的な用途
- PCIeの基本用語と構成要素(レーン・Gen・Link Training)
- FPGAでPCIeを使うための選択肢(ハードIP・ソフトIP・DMA)
- 必要なFPGA要件(GT/SerDes・リファレンスクロック・対応Gen)
- ボード設計の要点(配線長・インピーダンス・リセット)
- コンフィグ完了時間の要件(Configuration Time)
- Enumerationまでの流れと確認ポイント
- ソフトウェア側の実装(ドライバ・BAR・割り込み)
- 性能設計の勘所(スループット・レイテンシ・TLPサイズ)
- デバッグ手順(LTSSM・リンクアップ・アイダイアグラム)
- よくあるトラブル(リンクしない・認識しない・速度が出ない)
- まとめ
FPGA×PCIeでできることと代表的な用途
FPGAにPCIeを載せると、PC/SoCと高速・低遅延にデータをやり取りでき、計測・加速・ストレージなど幅広い用途に展開できます。
PCIeはPCやサーバーの標準的な拡張インターフェースです。FPGAをPCIe Endpointとして実装すれば、CPUメモリーやストレージに近い位置でデータを扱えます。Ethernetなどよりレイテンシを詰めやすく、OSからデバイスとして見えるため統合しやすいのも特長です。
代表例は、DAQ(高速計測)や画像・動画のストリーミング取り込み、推論・暗号・圧縮などのアクセラレーター、ネットワーク機能のオフロード、NVMe準拠のストレージコントローラーやカスタムストレージ制御、低遅延トレーディングやHFT向けのパケット処理などです。要点は「必要な場所に必要な帯域でデータを運ぶ」ことで、PCIeはそのための汎用バスになります。
一方でPCIeは、論理設計だけでは完成しません。トランシーバーやクロック、基板配線、リセット、FPGAのコンフィグ時間、OS列挙、ドライバーまでがつながって初めて動きます。用途に応じてどこに工数がかかるかを最初に見積もることが成功の鍵です。
PCIeの基本用語と構成要素(レーン・Gen・Link Training)
理論帯域はおおむねGenとレーン数で決まり、リンクが上がらないときはアプリ層を疑う前にLTSSMがどこで止まっているかを見ます。
レーンと帯域
レーンは差動ペアの送受信を1組とする単位で、x1/x4/x8/x16と表します。帯域は「Gen(世代)×レーン数」でおおむね決まりますが、世代ごとにエンコーディング方式が異なるため、単純な倍数にはなりません。
| 世代 | エンコーディング | 有効帯域率 | x1の片方向理論帯域 | x8の片方向理論帯域 |
|---|---|---|---|---|
| Gen1 | 8b/10b | 80% | 約0.25GB/s | 約2GB/s |
| Gen2 | 8b/10b | 80% | 約0.5GB/s | 約4GB/s |
| Gen3 | 128b/130b | 約98.5% | 約0.985GB/s | 約7.88GB/s |
実効帯域はTLPヘッダーやDLLPのオーバーヘッド、フロー制御、DMAのバースト設計、ホスト側の制約などにより、理論値を下回るのが一般的です。必要帯域からレーン数とGenを逆算し、余裕を持たせて設計します。
Genごとの差
Genは物理層の転送速度で、上がるほど要求される信号品質が厳しくなります。Gen3以降は受信側イコライゼーションやチャネル特性への依存が増え、基板設計や部品選定の難易度が上がります。
Gen4/Gen5では、ボード上へのリタイマーの挿入が必要になるケースや、イコライゼーションフェーズの追加、信号ロス要件の厳格化など、Gen3とは質的に異なる設計課題が加わります。Gen4/Gen5対応FPGAもAltera Agilex 7/5やAMD Versal Premiumなどですでに実製品があり、高帯域が求められる用途では選択肢に入ります(本記事はGen3までが中心)。「取りあえずGenを上げる」のではなく、目標性能と開発リスクのバランスを取るのが実務的です。
Link TrainingとLTSSM
Link Trainingは、電源投入後にリンクが確立するまでの自動交渉の仕組みで、内部状態機械LTSSMが段階的に遷移して速度やレーン数、等化などを決めます。リンクが上がらない時は、アプリ層を疑う前にLTSSMがどこで止まっているかを見ます。ここを観測できるかどうかが、デバッグの速度を大きく左右します。
FPGAでPCIeを使うための選択肢(ハードIP・ソフトIP・DMA)

FPGAの世代や要件に応じて、ベンダのハードIP/ソフトIPやDMAサブシステムを選び、開発コストと性能のバランスを取ります。
ハードIPとソフトIPの違い
多くのFPGAではPCIeコアがIPとして提供され、物理層やデータリンク層の大部分をブラックボックス的に利用できます。
| 方式 | 利点 | 制約 |
|---|---|---|
| ハードIP | 性能と安定性が高く、ベンダーが想定する範囲の使い方なら最短で動く | クロック構成やリセット、配置配線など「推奨に従う」設計が必要 |
| ソフトIP | 柔軟性がある | タイミング収束やリソース、性能面で難易度が上がりがち |
PCIeは規格の守る範囲が広く、すべて自前で実装すると検証コストが大きいため、通常はベンダーIPを使い、差別化はDMAやアプリ層で行うのが現実的です。
DMA方式の選び方
DMAはスループットとCPU負荷を決める中心要素です。PCIeコアが動いても、DMAが小さな転送を刻む、割り込みが多すぎる、ホスト側のバッファー管理が悪い、といった状態では速度が出ません。最初に必要な転送パターン(連続ストリームか、ランダムか、双方向か)を定義し、それに合うDMA方式(SGDMA、リングバッファー、ホストメモリー直書きなど)を選びます。
必要なFPGA要件(GT/SerDes・リファレンスクロック・対応Gen)
PCIe対応可否は、内蔵高速トランシーバー(GT/SerDes)、基準クロックの受け方、サポートするPCIe世代・レーン数に強く依存します。
PCIeは高速シリアル通信なので、FPGA側にGT/SerDes(高速トランシーバー)が必要です。製品グレードによって到達できる速度やサポートするプロトコルが異なり、同じファミリーでも「PCIe x8 Gen3はこのグレードまで」といった制限があります。デバイス選定の最初に、必要なGen/レーン数と対応表を突き合わせるのが鉄則です。
リファレンスクロックはリンクの根幹です。一般に100MHzのPCIeリファレンスクロックをボードからFPGAへ供給し、ジッター要件や配線、クロッキングアーキテクチャに注意します。
| 構成 | クロック源 | 使われる場面 |
|---|---|---|
| Common Refclk | ホストとエンドポイントが同一クロック源を共有 | FPGA×PCIeで最も一般的 |
| SRNS | 独立クロック・SSCなし | マルチボード構成などで検討 |
| SRIS | 独立クロック・独立SSC | マルチボード構成などで検討 |
クロックが規格から外れると、リンクアップしてもエラーが増えてGenが下がる、といった「一見動いているが性能が出ない」状態になりやすいです。
また、PCIe IPはクロックドメインやリセットの要求が厳密です。ユーザーロジック側もAXI-Stream/AXI-MMなどのインターフェース仕様を正確に守り、CDC(クロックドメインクロッシング)を適切に設計します。物理層が不安定なときに上位ロジックを疑うのは遠回りなので、まず要件を満たす基盤があるかを確認します。
ボード設計の要点(配線長・インピーダンス・リセット)
PCIeはボード品質がリンク安定性を左右し、要点は差動配線・インピーダンス管理・リセット/電源シーケンスです。
配線の基本は差動インピーダンス管理とペア内スキューの抑制です。受信側の等化である程度吸収できますが、限界を超えるとリンクが上がらない、Genが上がらない、CRCエラーが増えるといった症状が出ます。レーン間スキューやビアの使い方、リターンパスの確保など、基板ルールを先に固めてから部品配置を行うのが安全です。
リセット(PERST#)と電源シーケンスは「認識しない」問題の定番原因です。リセットは単に遅らせればよいわけではなく、FPGA側が確実に受けてPCIeコアが初期化されるタイミングと、クロック安定、電源の立ち上がりを合わせる設計が必要です。
コネクター近傍の保護素子やAC結合コンデンサーの配置も重要です。素子選定や配置を誤ると、信号品質の劣化が再現性の低い不具合として出ます。ソフトで誤魔化しにくい領域なので、基板レビューの段階で「規格が要求する物理層」を満たしているかをチェックリスト化して潰します。
コンフィグ完了時間の要件(Configuration Time)
FPGAのコンフィグ完了がホストの列挙開始に間に合わないと、ホストからは存在しないデバイスとして扱われます。
FPGAは揮発性デバイスが多く、電源投入後にビットストリームをロードして初めてPCIe回路が動きます。重要なのは「ホストがPCIeの列挙を始める時刻」と「FPGAがPCIe Endpointとして応答可能になる時刻」の関係です。
これは「PCIeの難しさ」というより「システム起動順序の設計」の問題です。どのタイミングまでに何が成立しているべきか(電源、クロック、コンフィグ、リセット解除、リンクトレーニング開始)を、ボードとFPGAとホストの三者で整合させることが核心になります。
PCIeを扱うFPGAは何秒でコンフィグすべきか
厳密な秒数はホスト(BIOS/UEFI、マザーボード、設定)で変わりますが、目標は「ホストがEnumerationを開始する前に、FPGAがPERST#解除後にConfiguration Spaceへ応答できる状態になっていること」です。PCIeはリンクトレーニング以前に、まず物理的に存在して応答できることが求められます。
PC電源投入から比較的早い段階で列挙が走るため、コンフィグが数秒単位で遅いと不利になります。特に大規模FPGAでビットストリームが大きい場合、SPIフラッシュのクロックやモード設定、圧縮の有無でコンフィグ時間が大きく変わります。最初に概算し、必要ならx1でデバッグしてから最終的にx8へ、といった段階設計も有効です。
| 手段 | 特徴 |
|---|---|
| JTAG書き込み | 開発には便利だが、起動時の自動認識には直結しない |
| 外部ローダー(マイコンなど) | 制御しやすい反面、システムの起動順序を設計し直す必要が出る |
| SPIフラッシュなど不揮発メモリーからの自動起動 | 量産で自然に認識させる王道。設定速度(QSPI化、クロック上限、圧縮、マルチブート設計)を詰める |
コンフィグが遅い場合に起きる問題と対策
多い症状は、PC起動時にデバイスが未認識のままで、再起動するかOS側で再スキャンしないと現れないパターンです。ホストが列挙を一度通過し、その時点で応答しないデバイスを「存在しない」と判断するために起きます。
開発時の回避策としては、OS起動後にFPGAをコンフィグし、デバイスマネージャーなどの「ハードウェア変更のスキャン」で再列挙させる方法が実用的です。再起動より速く、試行錯誤の回転を上げられます。ただし最終製品としてはユーザー体験が悪いので、あくまで開発用と割り切ります。
FPGA/基板設計受託開発
FPGA/SoC開発を軸に、回路設計からファームウェア開発、試作・量産まで対応
Enumerationまでの流れと確認ポイント
コンフィグ完了後、LTSSM遷移〜リンクアップ〜Configuration Space読出しまでの流れを追い、どこで詰まっているかを切り分けます。
流れを分解すると、(1)電源とクロックが安定、(2)PERST#解除、(3)LTSSMがDetect/Polling/Configurationを経てL0へ、(4)ホストがConfiguration Spaceを読み、Vendor ID/Device IDやクラスコードを見てドライバーを決める、という順です。どこで止まっているかで担当領域が変わるため、段階ごとに観測手段を用意します。
最重要は「リンクが上がっているか」です。FPGAのPCIe IPが提供するステータス(リンクアップ、Negotiated Link Width/Speed、LTSSM状態)を取り出し、LEDやレジスターで見えるようにすると切り分けが速くなります。
リンクアップしているのに認識しない場合は、Configuration Spaceの内容(Vendor IDが0xFFFFになっていないか、BAR設定が妥当か、クラスコードが意図どおりか)と、ホスト側のログを確認します。期待するクラスコードを返すだけでも「列挙は通る」ので、開発中はまず最小構成でEnumerationを確実に通し、その後にDMAやアプリ機能を増やすのが安全です。
ソフトウェア側の実装(ドライバ・BAR・割り込み)
OSから扱う際は、BARの領域分け(制御用とDMA・デバッグ用)とドライバーの初期化手順が要点です。
BAR設計
BARはホストから見た「FPGAの窓口」です。制御レジスター用の小さなMMIO領域と、DMA制御やステータス、デバッグ用の領域を分けると運用しやすくなります。つまずきやすいのはBARサイズやアライメント、キャッシュ属性、エンディアンの扱いで、ここが曖昧だと「たまに動かない」系の不具合が出ます。
割り込み設計
割り込みはMSI/MSI-Xが一般的で、レイテンシとスループットの両面に影響します。出しすぎるとCPU負荷が上がり、ポーリングだけにするとレイテンシが悪化します。実務では、DMA完了をバッチ化して一定量たまったら割り込み、緊急イベントは即時割り込み、といった設計で折り合いをつけます。
ドライバー初期化とDMA連携
PCIeデバイスとして列挙されても、ドライバーがBARをマップし、DMA用バッファーを確保し、IOMMUやキャッシュ整合を処理して初めて安定した転送になります。開発初期は汎用ドライバー(ユーザー空間アクセスや簡易DMA)で動作確認し、仕様が固まってから本格ドライバーへ移ると手戻りを減らせます。
性能設計の勘所(スループット・レイテンシ・TLPサイズ)
理論帯域だけでなく、TLPヘッダーやDLLPのオーバーヘッド、最大ペイロード、DMAバースト、レイテンシ要件を踏まえてボトルネックを潰します。
性能は「リンク速度×レーン数」だけでは決まりません。PCIeにはTLPヘッダーやDLLP、フロー制御、クレジット制限があり、小さな転送を頻発するとオーバーヘッドが支配的になります。
最大ペイロード(Max Payload Size)や最大リード要求(Max Read Request Size)はホストとデバイスの交渉で決まり、ここが小さいと読み出し性能が伸びません。さらにDMAの発行粒度、ホストメモリーの連続性(IOMMUやページ分割)、割り込み頻度が絡むため、ボトルネックは「FPGA内」より「システム全体」に潜むことが多いです。
| 重視する指標 | 設計の方向 | 評価の単位 |
|---|---|---|
| スループット | 十分に大きい連続転送を作り、無駄な往復を減らす | GB/s |
| レイテンシ | 巨大なバッファリングは遅延を増やすため、一定の小ささで区切りつつTLPを無駄に増やさない折衷点を探す | 分位点(p99など) |
用途ごとに指標を分けて評価すると、体感と一致しやすく改善点も見つけやすくなります。
デバッグ手順(LTSSM・リンクアップ・アイダイアグラム)
リンクしない・不安定・エラー多発は、層を下から上へ(LTSSM観測→物理層品質の確認→プロトコル解析)切り分けるのが最短です。
- 物理層の成立を確認する: 最初にLTSSM状態、Negotiated Speed/Width、リンクアップフラグを観測します。ここで止まっているなら、配線、AC結合、極性/レーンマッピング、リファレンスクロック、PERST#の順で疑います。
- 物理層の品質を確認する: リンクアップしてもGenが上がらない、エラーが多い場合は、アイダイアグラムやBER、受信等化設定の妥当性を見ます。ベンダーのトランシーバー評価機能を使い、同じボードでも温度やロットで余裕が変わる前提でマージンを取ります。動くかどうかではなく「どれだけ余裕があるか」を見ないと、量産後に化けます。
- プロトコル層を解析する: Configuration Spaceアクセス、BAR設定、DMA転送のTLPが期待どおりかを確認し、必要ならプロトコルアナライザーで観測します。リンクと列挙が安定する前に上位を解析すると、ノイズが多く原因を誤認しやすくなります。
よくあるトラブル(リンクしない・認識しない・速度が出ない)
症状ごとに最初に疑う層が異なります。リンクしないなら物理層、認識しないならコンフィグ完了と列挙のタイミング、速度が出ないならGen/レーン数の交渉結果から確認します。
| 症状 | 主な原因 | 最初に確認すること | 代表対策 |
|---|---|---|---|
| リンクしない | 差動ペアの配線ミス、極性反転、レーン入れ替え、AC結合の位置や値、基準クロックの取り回し、PERST#の論理やタイミング | x1でのリンクアップやGen落ちで再現性を取る | 基板ルールを先に固め、物理層の要件をチェックリスト化する |
| 認識しない | コンフィグ完了時間と列挙タイミングの不一致、Vendor ID/Device IDの未設定、クラスコードの不備 | Configuration Spaceが読めるか | 不揮発起動とリセット制御で、起動時に自然に見える形にする |
| 速度が出ない | 最大ペイロードやリード要求サイズ、DMAの粒度、割り込み設計、ホスト側のIOMMUやメモリー帯域 | Gen1相当やx4で上がっていないか | 十分に大きい連続転送を作り、無駄な往復を減らす |
リンクしない
物理層の問題が最優先で、ボード起因が多くを占めます。どの条件で改善/悪化するかを記録すると切り分けが進みます。
認識しない
再スキャンで見える状態は開発段階の回避策にすぎません。設定不備でも同様の症状になります。
速度が出ない
交渉結果を確認したら、転送サイズを大きくしたときに伸びるか、CPU負荷が張り付いていないかを見ます。
まとめ
FPGAでPCIeを成立させるには、IP選定・FPGA要件・基板品質・コンフィグ時間・Enumeration・ドライバーまで一気通貫で設計し、LTSSMなどで段階的に検証することが近道です。
LTSSMやリンク状態を常に観測できる作りにしておくと、トラブル対応も性能改善も速くなります。
お問い合わせ
FPGAに関するお問い合わせはこちら
※ 本記事に記載されている製品名・社名は、各社の商標または登録商標です。