fpga-development

FPGA 開発

HDL は、明示的な時間的インターフェースと電気的インターフェースを備えた、並行動作するハードウェアの記述として扱います。正しい設計には、機能上の意図、言語仕様、クロック／リセット動作、実装制約、検証エビデンスの一貫性が必要です。コンパイル、シミュレーション、合成、タイミング解析、物理的な観測から得られる事実は、それぞれ異なります。

運用上の契約

1. 求められている判断と設計範囲を特定します。新規 RTL、レビュー、シミュレーションの失敗、リソースの問題、CDC／タイミング解析、実装、ハードウェアのリリースのいずれかを確認し、その判断に必要な最小限かつ完全なエビデンスを使用します。
2. ターゲット固有の主張をする前に、デバイス／パッケージ、ボードのリビジョン、クロック、リセット、I/O 電圧、ピン制約を記録します。純粋な RTL の推論は、ボードの詳細を捏造せず、明示された抽象インターフェースに基づいて進められます。
3. 実装前に、トランザクションの意味、レイテンシ、スループット、バックプレッシャー、データの消失／重複に関するポリシー、初期化、演算の動作を明確にします。波形図はインターフェース契約の代わりにはなりません。
4. 合成可能な設計と検証専用の構成要素を分離します。HDL のサブセットとベンダープリミティブのモデルは、実際に使用するシミュレーターおよび合成ツールのバージョンに合わせます。
5. スラックを解釈する前に、制約の適用範囲と例外の意図を確認します。クロックの欠落や制約のないエンドポイントがある場合、サマリーが緑色でもエビデンスとして不完全です。
6. 接続されているハードウェアのプログラミング、リセット、消去など、状態を変更する操作の前に、実行対象、影響範囲、ロールバック手順を確認します。読み取り専用の調査は、確認なしで進められます。ビットストリームとプログラミング経路は、対象と完全に一致する必要があります。
7. 単一のソース／制約／ツール／デバイス構成に結び付いた成果物を保持します。昨日のテストと、今日の未検証ビットストリームを組み合わせて、リリース済みだと主張してはいけません。

タスクの振り分け

該当する深さの参考資料のみを読み、テンプレートを使って判断をレビュー可能な形で残します。

タスク	参考資料	テンプレート
デバイスと外部インターフェースの要件を確定する	ターゲットとインターフェースの契約	ターゲット契約
RTL の意味、推論、算術をレビューする	RTL と算術	RTL 契約
自己検証型の検証戦略を構築する	シミュレーションと検証	シミュレーション計画
クロック、リセット、ドメイン間の交差をレビューする	クロック、リセット、CDC	CDC レビュー
タイミングを診断する、または制約をレビューする	タイミングと制約	タイミングレビュー
パイプライン化、メモリ、DSP、実装上のトレードオフを判断する	実装とリソースのトレードオフ	RTL 契約とタイミングレビュー
実装をリリースする、または物理的な立ち上げを計画する	リリースとハードウェア検証	実装リリース

標準的な設計・検証のサイクル

観測可能な動作を仕様化する

トップレベルポート、幅、符号の有無、単位、クロックドメイン、リセットの意味を明記します。各トランザクションについて、受け付けが成立するタイミングと、出力が有効になるタイミングを定義します。ストール時の動作、継続可能な最大レート、許容するバースト、バッファリングの方針を指定します。FIFO を提案する前に、送信側と受信側のレートを確認します。有限のストレージでは、サービスレートの差が無制限に続く問題は解決できません。

数値演算では、オペランドの範囲と演算内容から中間値の幅を導出します。乗算、累算、再スケーリング、変換の各段階で、小数点位置を追跡します。丸め、飽和、オーバーフロー、無効な入力に対する方針を明記します。代表的な正の値だけに頼らず、負の値の極値や境界値をテストします。

推論されたハードウェアを実装して検査する

契約を、合成可能な組み合わせ回路および順序回路に変換します。代入の完全性、リセットの網羅性、レジスターのイネーブル、複数のドライバー、意図しないラッチ、幅や符号の変換を確認します。推論レポートを調べ、想定したメモリー、DSP、キャリー、レジスター構造が推論されていることを確認します。シミュレーションで正しく動作するビヘイビア実装でも、不適切なハードウェアやサポート対象外の初期化が推論されることがあります。

1つの方法論スキルを、ベンダーごとの手順書にまで広げないでください。コマンド、サポート対象の言語、ライブラリー、デバイスプリミティブについては、インストールされているツールの正確なバージョンのドキュメントを使用し、そのバージョン情報を結果とともに保持します。デバイスに依存しない例は、学習用および回帰テスト用の成果物であり、ピン設定済みのプロジェクトではありません。

時間的動作を検証する

参照モデルまたはスコアボード、明示的なタイムアウト、診断情報付きの失敗判定を備えたセルフチェック型テストベンチを作成します。設計に関係するリセット、ストール、同時転送、境界条件、パラメーターのバリエーションを網羅します。刺激と検査でサンプリング競合が起きないようにします。ランダム刺激を使用する場合は、再現可能なシードを記録します。

検証が実際に失敗できることを確認します。契約に違反する局所的な変更を意図的に加え、テストがそれを拒否することを確認します。その変更は成果物から削除します。有効なチェッカーのないシミュレーションが成功しても、得られる証拠はほとんどありません。カバレッジ数が示すのは実行された範囲であり、正しさや網羅的な証明ではありません。

形式解析は、プロパティ、前提条件、クロック／リセットの抽象化、証明範囲を明示したうえで、シミュレーションを補完できます。有界の合格は無界の証明ではありません。また、自明に成立するプロパティは検証の成功ではありません。ソルバー、ツール、バージョン、反例の証拠を結果とともに保持します。

クロック、リセット、クロッシングをモデル化する

プライマリークロックと生成クロック、およびそれらの実際の関係を洗い出します。各クロッシングについて、単一ビットのレベル、パルス／イベント、コヒーレントなワード、ポインター、ストリームのどれに当たるかを区別します。その意味に応じて、同期化方式または転送アーキテクチャを選択します。各ビットを個別に同期化しても、ワードのコヒーレンシーは保証されません。短いパルスは消失することがあります。変化が速すぎると、パルストグルでイベントを取りこぼすことがあります。

片側だけのリセットやクロックの停止も含め、各ドメインでのリセットのアサーションと解除の動作を明確にします。デバイス固有の同期器属性や実装制約には、適切なベンダーのガイダンスが必要です。機能シミュレーションでは、アナログのメタステーブル状態に対する信頼性はモデル化されません。

実際のインターフェースに対してタイミングを満たす

クロック制約とI/O制約、生成クロック、コーナー、モード、無視されるコマンド、制約のないエンドポイントを検証します。次に、セットアップおよびホールドパス、クロックの関係、アンクターンティー、論理段数、配線の寄与、例外を調べます。フォルスパスやマルチサイクルパスには、アーキテクチャ上の根拠と検証済みの適用範囲を必ず紐づけます。通常のトラフィックが発生しないというだけでは不十分です。

パイプライン、幅、メモリー、リタイミング、クロックを変更する場合は、タイミングだけでなくレイテンシーとプロトコルの動作も再検討します。制約モデルの修正と回路の改善は別の作業です。どちらの作業によって結果が変わったのか、その理由とともに記録します。

リリースの証拠を保持する

ソースと制約のハッシュ、トップレベルとパラメーター、正確なツール／ビルドのバージョン、デバイス／パッケージ、レポート、警告、テスト、出力成果物のハッシュをまとめて保持します。実行した工程を明示します。たとえば、エラボレーション、機能シミュレーション、合成、配置配線、静的タイミング解析、CDC解析、形式解析、プログラミング、物理検証です。

ハードウェア作業では、イメージの識別情報、ボード、プログラミング用の転送手段、文書化されたクロック／ピン／I/O条件、初期状態、復旧手順を確認します。指定された機能と、関連するリセット／電源再投入時の動作を観察します。プログラマーが正常終了しただけでは、設計の動作が実証されたことにはなりません。

実行可能な検証例

元のready/valid バッファーと自己チェック型テストベンチは、同期リセットによるフラッシュを伴う、1エントリー・単一クロックの転送契約を示しています。Python 3、Icarus Verilog、Yosysを使って、オフラインのフィクスチャーチェッカーを実行します。

python3 scripts/fpga_fixture.py --json --output /path/to/new-fixture-results

スキルのディレクトリから実行するか、スクリプトをフルパスで呼び出してください。出力ディレクトリは空であるか、新規である必要があります。幅やシードを変更する前に、--helpを確認してください。バージョン、ソースハッシュ、各ステージの結果が記録されるため、結果のJSONと保持されたログを確認してください。ツールが見つからない場合、結果は不完全となり、検証が成功したことにはなりません。このフィクスチャーには、ピン制約、配置配線、タイミングサインオフ、CDC、物理ハードウェアでの証明は含まれません。想定上のボードプロジェクトとしてプログラムしないでください。

チェッカーのテストは/scripts/test_fixture.pyにあります。python3 -m pytest scripts/test_fixture.py --no-cov -qを実行してください。統合テストでは指定されたツールが必要で、利用できない場合は明示的にスキップされます。意図的なローカル変更によってテストベンチが失敗することを確認してください。変更したRTLを成果物として残さないでください。

使用しない場合

• ESP32のファームウェア、ピンの制約、フレームワークAPI、書き込み、OTAは、リポジトリのesp32-developmentスキルの対象です。
• プラットフォームに依存しないコンポーネント選定、回路図、負荷・ドライバー、ベンチ測定に関する検討は、リポジトリのelectronicsスキルの対象です。HDLの型や制約名から電気的な互換性を推測しないでください。
• 特定ベンダーのツールに関する管理、インストール、運用手順には、そのツールの最新ドキュメントまたは専用スキルが必要です。ベンダー間で制約構文やプリミティブが同等だと想定しないでください。
• 高速なボード上のチャネル、RF、EMC、電源インテグリティ設計、規制対象のサインオフには、該当分野の専門的な根拠資料が必要です。このスキルでは依存関係や不足している根拠資料を特定できますが、それらのレビューに代わるものではありません。

完了基準

依頼された成果物と判断が提示され、チェックが正しいリビジョン／構成に結び付けられ、既知の制限が明示され、結論が実施した検証ステージの範囲を超えていない状態で完了です。診断では、収束しない試行を3回行った後、証拠を保持し、推測に基づく制約やRTLパッチを適用するのではなく、未解決の最小の疑問をエスカレーションしてください。