PYNQ Visual Operator Deployment
Ziel ist es, Software-Arrays, Hardwareschnittstellen und Validierungsergebnisse miteinander in Einklang zu bringen. Zuerst wird festgestellt, ob der Benutzer die Bereitstellung eines neuen Operators, die Fehlersuche in einem bestehenden System oder die Leistungsoptimierung durchführen möchte. Dabei werden bestehende Autorisierungen und Projektstatus berücksichtigt. Jede Aufgabe sollte nicht unnötigerweise zu einem vollständigen Retraining oder einer Neustrukturierung ausgeweitet werden.
Minimale Eingabe
Benötigt werden Algorithmus/Vorverarbeitung, mindestens ein Satz Gold-Eingabe-/Ausgabedaten, Bit/HWH oder HLS-Top-Level, eine echte Platine und eine PYNQ-Umgebung. Fehlt ein Element, führen Sie zuerst eine Offline-Überprüfung mit den verfügbaren Daten durch und geben Sie an, welche Schlussfolgerung noch von den fehlenden Daten abhängt.
Lesen Sie die Portierungsanleitung und füllen Sie den Tensorvertrag aus. Das Beispiel zeigt einen generischen Graustufentensor, nicht eine direkt auf eine beliebige Platine ladbare Hardwarekonfiguration. Neue Modelle müssen Shape, Dtype, Layout, Farbe, Skalierung/Padding, Quantisierungsstufen, Runden, Sättigen, Ausgabedekodierung und übertragene Bytes festlegen. Bitgenaue Formate wie INT4 erfordern separate Packing-Regeln; der vorhandene Vertragsprüfer akzeptiert nur entpackte Zahlenarrays.
Validierungspfad auswählen
- Erstmalige Inbetriebnahme: Vertragsprüfung → feste Eingabe-Ganzzahlreferenz → Einzelrahmen-PL-Rohausgabe → kontinuierliche Rahmen → Anwendungsgenauigkeit → segmentierte Zeitnahme.
- Ergebnisinkonsistenz: Speichern Sie schrittweise Vorverarbeitung, Quantisierungsknoten und PL-Rohtensoren, um die erste Abweichung zu lokalisieren; ändern Sie keine Nachbearbeitungsschwellenwerte, um frühere Fehler zu überdecken.
- Durchsatz- oder Latenzprobleme: Feste Eingabebedingungen, Rahmennummer und Zeitstempel im selben Taktbereich aufzeichnen; verwenden Sie das Zeitmessskript, um Warteschlangen-, PL/DMA- und Nachbearbeitungszeiten zu unterscheiden.
- Platinenwechsel: DMA, Adressbreite, Cache-Kohärenz, Takt, Reset und Interrupts neu identifizieren; Goldreferenzen und Vergleichsmethoden beibehalten.
Wiederholbare vollständige Prompts finden Sie im Workflow. Lesen Sie nur den für die aktuelle Aufgabe relevanten Abschnitt.
Hardware und Puffer
Unterscheiden Sie zuerst zwischen standardmäßigem AXI DMA und benutzerdefiniertem HLS IODMA. Für den einfachen Standardmodus kann die Anpassungsvorlage verwendet werden. Benutzerdefinierte Schnittstellen müssen gemäß Register- und festen Längen-/TLAST-Verträgen implementiert werden. Verwenden Sie keine Python-API-Namen als Hardwareprotokolle.
Bei kontinuierlichen Puffern muss die Eigentümerschaft klar sein: Nach dem Schreiben durch die CPU mit dem Gerät synchronisieren; nachdem die Hardware abgeschlossen ist und nicht mehr darauf zugegriffen wird, mit der CPU synchronisieren. Im Fehlerfall werden die laufenden Puffer beibehalten, nicht bedingungslos im finally-Block freigegeben. Details siehe DMA-Lebenszyklus.
HWH ist eine Schnittstellenbeschreibung, belegt nicht, dass das Bit auf der Festplatte bereits geladen wurde. Beim Binden an geladene Hardware, laden Sie die Identität, Adresse und Referenzausgabe ab. Wenn LCD und Inferenz das PL gemeinsam nutzen, können Sie nicht zwei vollständige Overlays nacheinander laden, um die kombinierte Hardware zu erhalten.
Validierung und Optimierung
Ganzzahlige Hardware-Rohausgaben sollten im Prinzip elementweise exakt übereinstimmen. Für Gleitkomma-Algorithmen verwenden Sie eine vorab festgelegte absolute Toleranz und protokollieren Sie dtype und nicht endliche Werte. Verwenden Sie das Vergleichsskript und ersetzen Sie keine Schnittstellenreparaturen durch erhöhte Toleranzen. Die Genauigkeit quantisierter Modelle und die Implementierungskonsistenz werden separat bewertet.
Überprüfen Sie gleichzeitig LUT, Slice, FF, BRAM, DSP, Timing und Backpressure. Vergleichen Sie FIFOs mit festem Gewicht, Eingabe, Frequenz und Parallelität; Ergebnisse nach Modelländerungen separat auflisten. Durchsatz wird als Anzahl der effektiv abgeschlossenen Rahmen geteilt durch das reale Messfenster berechnet, Latenz als Zeit zwischen den beiden Enden desselben Rahmens, nicht als Summe der Mediane der Phasen.
Liefern Sie Verträge, Rohausgaben, Quellcode-/Bit-/HWH-Identität, Prüfergebnisse und Messbereiche. Häufige Fehler und Bedingungen für Methodenfehler siehe Fehlerbehebungsliste. Projektergebnisse und Portierungsgrenzen siehe Validierungshinweise.