Déploiement d'opérateurs de vision PYNQ
L'objectif est de faire correspondre les tableaux logiciels, les interfaces matérielles et les résultats de vérification. Commencez par déterminer si l'utilisateur souhaite déployer un nouvel opérateur, localiser un défaut existant ou optimiser les performances, en vous appuyant sur les autorisations et l'état du projet déjà en place ; n'étendez pas chaque tâche en un réentraînement ou une refonte complète.
Entrée minimale
Sont nécessaires : l'algorithme / le prétraitement, au moins un jeu d'entrées-sorties gold, le fichier .bit / .hwh ou le top-level HLS, la carte réelle et l'environnement PYNQ. Si un élément manque, effectuez d'abord des vérifications hors ligne avec les documents disponibles, en indiquant quelles conclusions dépendent toujours des données manquantes.
Lisez les instructions de portage et remplissez le contrat tensoriel. L'exemple correspond à un tenseur de niveau de gris générique, et non à une configuration matérielle pouvant être chargée directement sur n'importe quelle carte. Pour un nouveau modèle, il faut redéfinir shape, dtype, layout, couleur, mise à l'échelle/rembourrage, échelles de quantification, arrondi, saturation, décodage de sortie et nombre d'octets transmis. Les formats au niveau du bit, comme INT4 compressé, nécessitent des règles de compression distinctes ; le vérificateur de contrat actuel n'accepte que les tableaux numériques non compressés.
Choix du chemin de vérification
- Première connexion : vérification du contrat → référence entière fixe en entrée → sortie brute PL d'une seule trame → trames continues → précision applicative → chronométrage par segment.
- Résultats incohérents : enregistrez étape par étape le prétraitement, les nœuds de quantification et le tenseur brut PL, localisez le premier point de divergence ; ne modifiez pas d'abord le seuil de post-traitement pour masquer l'erreur en amont.
- Débit ou latence anormale : conditions d'entrée fixes, enregistrez les numéros de trame et les timestamps dans le même domaine d'horloge ; utilisez le script de chronométrage pour distinguer mise en file d'attente, PL/DMA et post-traitement.
- Changement de carte : ré-identifiez DMA, largeur d'adresse, cohérence de cache, horloge, reset et interruptions ; conservez la référence gold et la méthode de comparaison.
Les prompts complets et reproductibles se trouvent dans le workflow ; lisez uniquement celui qui correspond à la tâche en cours.
Matériel et tampons
Commencez par distinguer le DMA AXI standard du IODMA HLS personnalisé. Pour le mode simple standard, référez-vous au modèle d'adaptation ; pour les interfaces personnalisées, implémentez selon les registres et le contrat de longueur fixe / TLAST. Ne confondez pas les noms d'API Python avec des protocoles matériels.
Les tampons continus nécessitent une propriété claire : synchronisation CPU→périphérique après écriture, puis périphérique→CPU après que le matériel a terminé et n'y accède plus. En cas d'exception, conservez les tampons en transit ; ne libérez pas inconditionnellement dans finally. Voir cycle de vie DMA pour les détails.
Le fichier HWH est une description d'interface, il ne prouve pas que le bit sur disque a été chargé. Lors de la liaison avec un matériel déjà chargé, vérifiez l'identité du chargement, l'adresse et la sortie de référence. Si le LCD et l'inférence partagent le PL, on ne peut pas obtenir un matériel combiné en chargeant deux Overlays complets successivement.
Vérification et optimisation
En principe, la sortie brute entière du matériel doit être exacte élément par élément ; pour les opérations en virgule flottante, utilisez une tolérance absolue prédéfinie, en enregistrant le dtype et les valeurs non finies. Utilisez le script de comparaison, ne remplacez pas une réparation d'interface par une tolérance élargie. Évaluez séparément la précision du modèle quantifié et la cohérence de l'implémentation.
Vérifiez également LUT, Slice, FF, BRAM, DSP, timing et back-pressure du flux. Comparez les FIFO avec des poids, entrées, fréquence et parallélisme fixes ; les résultats après changement de modèle doivent être listés séparément. Le débit se calcule en divisant le nombre de trames complètement traitées par la fenêtre de mesure réelle ; la latence se calcule par le temps entre les deux extrémités d'une même trame, sans additionner les médianes des différentes étapes.
Livrez le contrat, la sortie brute, l'identité du code source / du bit / du HWH, les résultats de vérification et la plage de mesure. Les erreurs courantes et les conditions d'échec des méthodes sont dans la liste de dépannage. L'effet du projet et les limites de portabilité sont décrits dans les instructions de validation.