Remplacement chinois ZYNQ pratique : que change la migration de Xilinx ZYNQ vers PBC7Z020G/021G
Le design d’origine utilise Xilinx Zynq-7000 (XC7Z020) pour le schéma hétérogène ARM logiciel + logique réaliste FPGA, et maintenant il doit passer au national. Remplacer la puce signifie-t-il réécrire tout le projet, ou seulement des changements locaux ? Cet article divise la migration de HWD7Z020 (compatible XC7Z020) sur PBC7Z020G/021G en trois couches — logiciel PS, logique PL, boot et BSP — et détaille le volume réel de changement, les parties réutilisables et les points de risque.
1. Pourquoi migrer : de XC7Z020 vers HWD7Z020 national
La valeur de ZYNQ est qu’une puce contient à la fois un dual-core ARM Cortex-A9 (PS, faisant tourner le logiciel système, le réseau et le système de fichiers) et une logique programmable (PL, faisant l’acquisition parallèle, l’accélération de protocole et les IO temps réel). Quand un design XC7Z020 doit passer au national, le but n’est pas une architecture totalement différente mais un drop-in national compatible en jeu d’instructions, périphériques et flux Vivado. PBC7Z020G porte HWD7Z020-1PBGA400 et PBC7Z021G porte HWD7Z020-1CLG484 ; tous deux sont grade industriel national, dual-core A9@800 MHz plus hétérogénéité FPGA, nativement compatibles Vivado sans patch supplémentaire, et notés -55~125 °C en température ultra-large.
Avant de migrer, divisez le projet en trois couches et estimez chacune :
- Logiciel PS : programmes bare-metal, tâches FreeRTOS, applis Linux et drivers tournant sur l’A9.
- Logique PL : RTL, IP cores, contraintes et mapping de broches écrits dans Vivado, tournant dans la matrice FPGA.
- Boot et BSP : image de boot, config de boot QSPI/eMMC/SD, device tree et package de support carte.
2. Migration logicielle PS : réutilisation BSP la plus élevée
1. Bare-metal et FreeRTOS : le projet change à peine
Les projets bare-metal et FreeRTOS appellent les interfaces périphériques A9 (UART, GPIO, timers, contrôleur d’interruptions) via le BSP. La disposition des registres PS de HWD7Z020 est compatible avec XC7Z020, donc les drivers SDK/BSP sont réutilisables et le code couche application n’a pas besoin de réécriture. Les changements se concentrent sur la régénération du BSP sous la librairie de périphériques nationale, la recompilation, et la vérification des numéros d’interruption et de la config d’horloge. L’effort se compte en jours, pas en mois.
2. Linux : ajustements locaux au device tree, U-Boot et noyau
Pour les designs Linux, le côté PS change plus que bare-metal, mais ce n’est pas un nouveau départ :
- Device tree (DTS) : remapper les nœuds de périphériques PS et les nœuds de connexion PL de l’arbre XC7Z020 vers les connecteurs de carte nationaux ; remplir la capacité/largeur DDR3, les partitions eMMC/QSPI, les nœuds Ethernet/USB pour la nouvelle carte.
- U-Boot et noyau : utiliser une config compatible XC7Z020 pour élaguer ; ajuster bootargs, baudrate console et montage rootfs ; recompiler et régression-tester les drivers custom sur le périphérique national.
- Couche application : les services utilisateurs, les programmes réseau et les algorithmes métier sont indépendants de la puce et passent directement.
Estimez d’abord la bande passante DDR3 depuis la config carte : PBC7Z020G/021G utilisent toutes deux DDR3 1 Go, bus 32 bits, 1066 Mbps ; bande passante octet = 4B × 1066 MT/s ≈ 4,26 Go/s, assez pour le contrôle embarqué ordinaire et le transfert d’image léger, donc pas de changement de plateforme nécessaire pour la bande passante.
3. Migration logique PL : re-planifier les contraintes après vérification des ressources
Comparaison des ressources PL (classe XC7Z020 vs HWD7Z020 / PBC7Z021G)
| Ressource | Classe XC7Z020 | PBC7Z021G (HWD7Z020-1CLG484) | Verdict migration |
|---|---|---|---|
| Cellules logiques | ~85K | 85K | Même classe, le design passe |
| LUT | ~53,2K | 53 200 | Même classe |
| Flip-Flops | ~106K | 106 400 | Même classe |
| Multiplieurs DSP | 220 | 220 | Même classe |
| Block RAM | 4,9 Mb | 4,9 Mb | Même classe |
| IO PL disponibles | — | 198 (plus 48 paires LVDS, 100 IO configurables en tension) | Re-planifier sur les nouveaux connecteurs |
Le code RTL comportemental d’origine, la logique purement combinatoire/séquentielle et la plupart des IP cores (BRAM, FIFO, PLL/MMCM, interconnexion AXI) se synthétisent directement sous le flux compatible et n’ont pas besoin de réécriture.
Contraintes, IP et re-mapping des broches
Après que le boîtier passe de PBGA400 (020G, petit 35×42 mm) à 1CLG484 (021G, 60×60 mm), les broches physiques et les IO exposées diffèrent, donc le fichier de contraintes XDC doit être ré-attribué par les nouveaux connecteurs de carte ; l’arbre d’alimentation, le routage DDR3 et les cristaux d’horloge (021G porte un cristal PS 33,33 MHz plus un cristal PL 50 MHz) sont aussi vérifiés contre la nouvelle carte. Si une IP utilise un bloc dur propriétaire du fournisseur (certains transceivers, modules de sécurité), confirmez si le périphérique national fournit une IP équivalente ; sinon remplacez-le par du RTL générique.
4. Chaîne de boot et checklist de mise en service
Modes de boot et image de boot
PBC7Z021G réserve un JTAG 6 broches et supporte les modes de boot JTAG / QSPI / carte SD sélectionnés par un DIP switch ; PBC7Z020G utilise 2 connecteurs 120 broches Panasonic et une alimentation 5V. Mettez en service la migration en parcourant cette checklist :
- Logiciel PS : régénérer le BSP, recompiler et régression-tester bare-metal/FreeRTOS ; mettre à jour le device tree, les bootargs U-Boot et la config noyau pour Linux.
- Logique PL : synthétiser le projet d’origine, réécrire les contraintes XDC pour le nouveau boîtier, vérifier la compatibilité IP et la fermeture de temporisation.
- Config de boot : confirmer le mode de boot (debug JTAG → production QSPI/SD), construire boot.bin (FSBL, bitstream, device tree) et rootfs.
- Large température et fiabilité : les cartes nationales sont -55~125 °C (020G/021G) ; faire tourner le cycling thermique et les tests longue mise sous tension pour la condition cible et confirmer la marge d’alimentation.
Sélection : choisissez 020G / 021G / expansion pure-FPGA selon la taille et les IO
- Remplacement ultra-petit (PBC7Z020G, 799 ¥) : 35×42×5,5 mm, 2×120 broches, pour les nœuds embarqués miniaturisés et de remplacement à logique moyenne et contrainte d’espace.
- Production complètement exposée (PBC7Z021G, 999 ¥) : 60×60 mm, 4×80 broches, 198 IO PL et 48 paires LVDS, ressources PS/PL complètement exposées, pour la production d’ingénierie et les designs nécessitant plus d’IO externes.
- Expansion pure-FPGA grandes ressources (PBC7K325G, 1 999 ¥) : quand le côté PL a besoin de transceivers haute vitesse ou de grande logique (16 voies GTX@12,5 Gb/s, 2 Go DDR3, 326K cellules logiques), un SoM Kintex-7 national prend le relais, complétant le schéma ZYNQ.
Le remplacement chinois de ZYNQ n’est pas une reconstruction : le logiciel PS et la couche application réutilisent le plus ; ce que vous touchez réellement est la re-planification des contraintes PL pour le nouveau boîtier et la mise à jour du device tree et de l’image de boot. Divisez en couches PS, PL et boot pour estimer chacune ; dans le flux compatible, un projet n’a besoin que d’ajustements locaux, avec le risque concentré sur la compatibilité IP et la régression large température, donc la migration arrive dans les délais.
