PYNQ ビジョンオペレーターデプロイメント
目標は、ソフトウェア配列、ハードウェアインターフェース、検証結果を相互に対応付けることです。まず、ユーザーが新規オペレーターのデプロイ、既存障害の原因特定、パフォーマンス最適化のいずれを完了したいのかを特定し、既存の承認とプロジェクト状況をそのまま使用します。すべてのタスクを完全な再トレーニングやリファクタリングに拡張しないでください。
最小入力
アルゴリズム/前処理、少なくとも1組のゴールデン入出力、ビットストリーム/HWH または HLS トップレベル、実ボード、PYNQ 環境が必要です。不足項目がある場合は、既存資料から可能なオフライン検査を先に行い、どの結論が不足資料に依存しているかを指摘します。
移行手順を読み、テンソル契約を記入します。サンプルは汎用グレースケールテンソルであり、任意のボードに直接ロードできるハードウェア構成ではありません。新しいモデルでは、shape、dtype、layout、色空間、スケーリング/パディング、量子化スケール、丸め、飽和、出力デコード、転送バイト数を再決定する必要があります。INT4 などのパックされたビットレベルフォーマットには、別途パッキングルールを記述する必要があり、既存の契約チェッカーはパックされていない数値配列のみを受け入れます。
検証パスの選択
- 初回接続: 契約チェック → 固定入力整数リファレンス → 単一フレーム PL 生出力 → 連続フレーム → アプリケーション精度 → セグメント単位のタイミング計測。
- 結果不一致: 前処理、量子化ノード、および PL 生テンソルを段階的に保存し、最初に差異が発生した位置を特定します。後処理のしきい値を変更して前段のエラーをマスクしないでください。
- スループットまたはレイテンシ異常: 入力を固定し、同一クロックドメイン内のフレーム番号とタイムスタンプを記録します。タイミングスクリプトを使用して、キューイング、PL/DMA、後処理を区別します。
- ボード交換: DMA、アドレス幅、キャッシュコヒーレンシ、クロックリセット、割り込みを再特定します。ゴールデンリファレンスと比較方法は維持します。
再現可能な完全なプロンプトはワークフローにあります。現在のタスクに対応する1つの項目だけを読み取ってください。
ハードウェアとバッファ
まず、標準 AXI DMA とカスタム HLS IODMA を区別します。標準シンプルモードはアダプテーションテンプレートを参照できます。カスタムインターフェースは、レジスタと固定長/TLAST 契約に従って実装する必要があります。Python API 名をハードウェアプロトコルとして使用しないでください。
連続バッファでは所有権の明確化が必要です。CPU が書き込んだ後はデバイスに同期し、ハードウェアが完了してアクセスしなくなった後に CPU に同期します。異常時にはインフライトバッファを保持し、finally 内で無条件に解放しないでください。詳細はDMA ライフサイクルを参照してください。
HWH はインターフェース記述であり、ディスク上のビットストリームがすでにロードされていることを証明しません。ロード済みハードウェアにバインドする場合は、ロード ID、アドレス、リファレンス出力を照合します。LCD と推論が PL を共有する場合、2つの完全なオーバーレイを順次ロードして複合ハードウェアを取得することはできません。
検証と最適化
整数ハードウェアの生出力は、原則として要素ごとに厳密に一致する必要があります。浮動小数点アルゴリズムでは、事前に規定された絶対許容差を使用し、dtype と非有限値を記録します。比較スクリプトを使用し、許容差を拡大してインターフェースの修正を代替しないでください。量子化モデルの精度と実装の一貫性は、それぞれ評価します。
同時に LUT、Slice、FF、BRAM、DSP、タイミング、ストリームのバックプレッシャーをチェックします。FIFO は固定重み、入力、周波数、並列度と比較します。モデル変更後の結果は別途リストします。スループットは有効完了フレーム数を実際の測定ウィンドウで割り、レイテンシは同一フレームの両端の時間で計算し、各ステージの中央値を加算しません。
契約、生出力、ソースコード/ビットストリーム/HWH の識別、チェック結果、測定範囲を提供します。一般的なエラーとメソッドの無効条件についてはトラブルシューティングリストを参照してください。プロジェクトの効果と移行可能範囲については検証手順を参照してください。