Note d'adaptation locale (non AMD original ; 2026-10-18, ajouté par la session DSH)

Chaîne d'outils différente : Ce système utilise un vivado-mcp tiers (installation active <vivado-mcp>, 32 outils), pas le vivado-mcp-server officiel ; le <EIF repo>\vivado-mcp dans le dépôt est une copie inchangée du dépôt, pas une instance en cours d'exécution (le client doit définir explicitement PYTHONPATH=<vivado-mcp>\site, sinon le _mcp_pilot_paths.pth du venv peut frapper une copie de chemin chinois de .mcp-pilot → start_session échoue en silence).

Mappage des outils : vivadoExecute/vivado_execute → run_tcl/safe_tcl ; vivado_start → start_session ; vivado_stop → stop_session ; vivado_list_sessions → list_sessions ; vivado_status → get_run_progress ; vivado_log_messages → get_critical_warnings (uniquement runme.log) ou read/grep ; read_file → read ; create_file → write ; replace_string_in_file → edit ; file_search → glob ; grep_search → grep ; run_in_terminal → pwsh ; runSubagent → subagent.

Si la session ne dispose pas d'outils MCP, utiliser le pont CLI : python <vivado-mcp>\mcp_ctl.py session "<Tcl multiligne>" (équivalent à run_tcl), call <tool> --args-file <json>, list. Un processus MCP par appel, les sessions multi-étapes doivent être écrites en un seul session. (Depuis le 2026-10-24, le profil desktop a été configuré avec mcp__vivado__*, nécessite le redémarrage de l'hôte pour s'appliquer ; si non pris en compte, le pont CLI reste le seul chemin.)

Version réelle : Vivado 2023.1 (base officielle 2026.1) ; Python utilise <interpréteur Python : voir python dans config.yml (install.ps1 écrit la valeur réelle)>.

Recherche de documentation : Pas de vivado_doc_search localement, utiliser web_fetch (docs.amd.com / docs officielles) ou <project_root>\docs.

Contrainte stricte : Le chemin d'installation MCP doit être purement ASCII (les chemins chinois sont corrompus par le décodage GBK de Tcl Vivado) ; les sessions Vivado, synthèse, implémentation et simulation sont globalement sérialisées.

Compétence de contrôle de révision Vivado

Cette compétence automatise la configuration du contrôle de révision pour les projets Vivado via un pipeline en 5 étapes, plus une étape 2.5 optionnelle pour préserver les sorties générées existantes. Elle fonctionne avec les projets standard RTL uniquement, les conceptions IPI (y compris les conteneurs de conception), DFX (reconfiguration partielle) et les projets de configuration segmentée Versal.

Le pipeline détecte le type de projet, analyse les emplacements des sources, exporte les composants, capture les paramètres et génère un script de construction — produisant un répertoire autonome capable de recréer le projet à partir de zéro.

Quand utiliser cette compétence

Configurer le contrôle de révision pour tout projet Vivado
Rendre un projet portable pour les membres de l'équipe ou le CI/CD
Exporter et organiser toutes les sources du projet
Créer des scripts de construction automatisés pour des constructions reproductibles
Gérer le contrôle de révision DFX, BDC ou de configuration segmentée

Quand NE PAS utiliser cette compétence

Le projet n'est pas encore créé (aucun fichier .xpr n'existe)
Besoin uniquement de modifier un script de construction existant (éditer directement)
Besoin d'analyse temporelle ou de débogage de conception (utiliser d'autres compétences comme la mise en base de référence)

Prérequis

Avant d'exécuter, le projet Vivado doit être ouvert avec :

Une propriété PART valide définie
Les fichiers sources ajoutés au projet
Le module TOP configuré
Pour DFX : propriété PR_FLOW activée
Pour la configuration segmentée : propriété SEGMENTED_CONFIGURATION définie (ou périphérique Versal Gen2)

Pipeline en 5 étapes (+ étape 2.5 optionnelle)

Toutes les procédures Tcl se trouvent dans helper-procedures/helper_scripts.tcl. Source ce fichier d'abord dans Vivado, puis exécute chaque étape séquentiellement.

source <skill-path>/helper-procedures/helper_scripts.tcl

Étape 1 : Détecter le flux du projet

Exécute detect_project_flow pour identifier le type de projet. Cela retourne un dictionnaire flow_info nécessaire pour l'étape 3.

set flow_info [detect_project_flow]
set flow_type [dict get $flow_info flow_type]

Retourne l'un des éléments suivants : "Standard", "DFX (Partial Reconfiguration)", "Segmented Configuration", "DFX + Segmented Configuration" — avec le suffixe optionnel "+ IPI BDC" si des conteneurs de conception sont détectés.

Pour les détails sur la logique de détection et les cas particuliers, lire detect-project-flow/REFERENCE.md.

Étape 2 : Analyser les emplacements des sources

Exécute analyze_source_locations pour classer les sources comme Push Button (toutes locales), Remote (toutes externes) ou Mixed.

set scenario_info [analyze_source_locations]
set scenario [dict get $scenario_info scenario]

Si scenario est "Remote", sauter complètement l'étape 3 — les sources se trouvent dans des dépôts externes et ne doivent pas être dupliquées.

Pour les détails, lire analyze-source-locations/REFERENCE.md.

Étape 2.5 : Préserver les sorties générées ? (optionnelle, interactive)

Demander s'il faut conserver les sorties .gen existantes pour certains IPs/BDs au lieu de les laisser être entièrement régénérées à partir de Tcl lors de la reconstruction. Cette étape n'existe pas dans les versions antérieures de cette compétence et est entièrement optionnelle. Comment l'exécuter dépend de qui pilote le pipeline :

Humain tapant directement dans une session Vivado active (console Tcl de l'interface graphique, ou session batch pilotée manuellement avec un vrai tty) — à partir du 2026-09-21, vous n'avez besoin de rien faire de spécial : si vous appelez l'étape 3 (export_all_sources) sans avoir déjà répondu vous-même, elle détecte un vrai tty sur stdin et, si le projet a quelque chose d'éligible, vous invite automatiquement avant de continuer. Vous pouvez toujours appeler prompt_preserve_outputs explicitement avant si vous préférez contrôler exactement quand l'invite apparaît :

set preserve_selection [prompt_preserve_outputs]

Répondre "n" (ou simplement appuyer sur Entrée) retourne {enabled 0 ips {} bds {} cache_dir {}} — les étapes 3 et 5 se comportent alors exactement comme avant cette fonctionnalité.
Répondre "y" liste chaque IP autonome éligible et chaque BD créée par l'utilisateur (via list_preservable_outputs) — y compris les XCI qui se trouvent en dehors d'une conception — et vous permet de choisir lesquels préserver (all ou une liste séparée par des virgules). Cette sélection est mixte/partielle entre différents éléments de plus haut niveau (certains IPs/BDs autonomes préservés, d'autres non) — c'est le cas d'utilisation principal pris en charge. Elle n'est pas partielle au sein d'un seul BD : un BD est préservé comme une unité entière, et vous ne pouvez pas choisir lesquels des IPs personnalisés à l'intérieur sont préservés ou régénérés (confirmé comme une délimitation de périmètre intentionnelle, pas un bug — marqué comme une amélioration possible du Q4).
Si un élément sélectionné n'a pas encore de sortie .gen (jamais généré/synthétisé), export_all_sources émet un avertissement et l'exporte normalement au lieu de le préserver — rien à préserver n'est pas une panne matérielle, mais cela ne crée pas non plus silencieusement une entrée de cache incomplète.
La préservation ne prend en charge qu'un cache distant : un répertoire en dehors de ce projet. Après avoir choisi les IPs/BDs, vous êtes invité à fournir le chemin absolu de ce répertoire de cache. Un chemin invalide (relatif, vide ou imbriqué dans le projet) désactive la préservation pour cette exportation.

Cette procédure bloque sur gets stdin, donc elle ne fonctionne qu'avec un vrai tty attaché — ce qui est exactement la condition que export_all_sources vérifie maintenant (_rc_stdin_is_tty) avant de l'invoquer automatiquement.

CI automatisé / pipelines de régression (harnais de type run_pipeline.tcl) — sauter complètement cette étape et passer {} (la valeur par défaut) aux étapes 3 et 5. Cela préserve le comportement pleinement automatisé en 5 étapes d'origine, inchangé.

Agentique (un agent IA pilotant Vivado via des appels Tcl en mode Bash/batch, dialoguant avec un humain) — ne pas appeler prompt_preserve_outputs : son gets stdin n'a pas de vrai tty sur lequel bloquer et lira simplement EOF, désactivant silencieusement la préservation sans aucune invite visible. Au lieu de cela :

Appeler list_preservable_outputs (requête pure, pas de stdin) pour voir ce qui est éligible.
Si elle retourne des IPs ou des BDs, demander directement à l'humain dans la conversation lesquels (le cas échéant) il souhaite préserver, ET un chemin absolu vers un répertoire de cache en dehors du projet pour stocker les sorties préservées.
Appeler build_preserve_selection $chosen_ips $chosen_bds $cache_dir avec les réponses de l'humain pour obtenir le dictionnaire preserve_selection.
Si list_preservable_outputs ne retourne rien, ne pas demander — il n'y a rien à préserver.

set items [list_preservable_outputs]
# ... demander à l'humain dans la conversation, puis :
set preserve_selection [build_preserve_selection $chosen_ips $chosen_bds $cache_dir]

Passer le preserve_selection retourné à l'étape 3 (export_all_sources). Pour les détails, lire helper-procedures/REFERENCE.md.

Étape 3 : Exporter toutes les sources (conditionnel)

Sauter cette étape si l'étape 2 a retourné "Remote". Sinon, exporter les sources RTL, les contraintes, les IP (en Tcl via write_ip_tcl), les conceptions (en Tcl via write_bd_tcl), les fichiers de simulation et les fichiers de données vers un répertoire organisé.

Passer flow_info de l'étape 1 pour activer les exportations spécifiques à DFX/configuration segmentée (pblocks, DCP, solutions NoC). Passer preserve_selection de l'étape 2.5 (ou l'omettre) pour contrôler la préservation des sorties par IP/BD. Si vous l'omettez et que stdin est un vrai tty, export_all_sources invite elle-même à le saisir (voir l'étape 2.5 ci-dessus) plutôt que de sauter silencieusement la préservation. Pour tout IP/BD nommé dans preserve_selection, sa propre arborescence .srcs/.gen (rien d'autre) est copiée dans le cache_dir externe que la sélection spécifie — jamais dans export_dir/RevisionControl/ lui-même.

if {$scenario ne "Remote"} {
    export_all_sources "RevisionControl" $flow_info $preserve_selection
}

Pour les détails sur les règles de filtrage, la gestion des IP BD et les exportations DFX, lire export-all-sources/REFERENCE.md.

Étape 4 : Capturer les paramètres du projet

Enregistrer toutes les propriétés du projet non par défaut dans un script Tcl qui peut les restaurer lors de la reconstruction.

file mkdir RevisionControl/Scripts
capture_project_settings "RevisionControl/Scripts/project_settings.tcl"

Capture : PART, BOARD_PART, TARGET_LANGUAGE, PR_FLOW, SEGMENTED_CONFIGURATION, TOP, VERILOG_DEFINE, directives de synthèse/implémentation, et propriétés spécifiques aux fichiers (VHDL LIBRARY, IS_GLOBAL_INCLUDE).

Pour les détails, lire capture-project-settings/REFERENCE.md.

Étape 5 : Générer le script de construction

Créer build.tcl pour la recréation du projet en une commande.

generate_build_script "RevisionControl/Scripts/build.tcl" "RevisionControl" $scenario_info

Le script généré utilise des chemins relatifs, importe les sources locales (import_files), référence les sources distantes à leur emplacement (add_files), recrée les IP et BD à partir des scripts Tcl, crée des exécutions OOC IP, génère les cibles BD, source project_settings.tcl, et finalise l'ordre de compilation. Pour tout IP/BD préservé à l'étape 2.5, il restaure plutôt les .srcs/.gen de cet élément à partir du répertoire de cache externe et les add_files/read_ip/read_bds directement — pas de rejeu de write_ip_tcl/write_bd_tcl, pas de re-synthèse — tandis que chaque IP/BD non préservé passe toujours par le chemin standard de régénération Tcl. Cette ramification est par IP/BD, jamais globale pour l'ensemble du projet. Si le répertoire de cache (ou les données d'un élément préservé spécifique à l'intérieur) est manquant au moment de la reconstruction, le script généré génère une erreur matérielle plutôt que de se rabattre silencieusement sur la régénération.

Pour les détails, l'ordre de RM DFX et la gestion des .gen manquants, lire generate-build-script/REFERENCE.md.

Flux de données du pipeline

Étape 1 : detect_project_flow
 → dictionnaire flow_info (passé à l'étape 3)

Étape 2 : analyze_source_locations
 → scénario ("Push Button" / "Remote" / "Mixed")
 → Si Remote : sauter l'étape 3

Étape 2.5 : prompt_preserve_outputs (optionnelle, interactive uniquement)
 → dictionnaire preserve_selection {enabled, ips, bds, cache_dir} (passé à l'étape 3)
 → omis/décliné ⇒ {} ⇒ les étapes 3 et 5 se comportent exactement comme avant
 → si omis ET stdin est un vrai tty ET quelque chose est éligible, l'étape 3
   l'appelle automatiquement en votre nom (ajouté le 2026-09-21) au lieu de
   prendre par défaut silencieusement l'absence de préservation — pas de tty
   (CI/agentique) ⇒ inchangé
 → cache_dir doit être un chemin absolu EN DEHORS du projet (cache distant
   uniquement) — un chemin invalide/manquant désactive la préservation pour
   cette exportation

Étape 3 : export_all_sources(répertoire, flow_info, preserve_selection)
 → Répertoire Sources/ avec RTL, IP, BD, Contraintes (le répertoire lui-même
   ne change jamais de forme en fonction de preserve_selection)
 → (uniquement si preserve_selection a sélectionné quelque chose) l'arborescence
   .srcs/.gen de chaque élément préservé est copiée dans cache_dir — jamais
   dans le répertoire lui-même

Étape 4 : capture_project_settings(fichier)
 → project_settings.tcl

Étape 5 : generate_build_script(fichier, répertoire, scenario_info)
 → build.tcl (reconstruction automatisée ; restaure .srcs/.gen de tout élément
   préservé à partir de cache_dir au moment de la reconstruction — génère une
   erreur matérielle si cache_dir ou les données d'un élément préservé à
   l'intérieur sont manquants)

Structure de sortie

RevisionControl/ est exporté à côté du projet Vivado actif et sa propre forme ne change jamais selon que la préservation de l'étape 2.5 a été utilisée — il ne contient jamais <proj>.gen/, <proj>.srcs/ ou <proj>.xpr du projet original (ceux-ci restent intacts là où ils sont), et XPR n'est jamais sous contrôle de révision dans aucun flux.

project_1.gen/            # projet Vivado original actif — voisin, intact
project_1.srcs/
project_1.xpr

RevisionControl/
├── Sources/
│   ├── RTL/              # sources Verilog/SV/VHDL
│   ├── Constraints/      # fichiers XDC (+ pblocks.xdc pour DFX)
│   ├── IP/               # scripts write_ip_tcl — IP autonomes non préservés
│   │                     # uniquement (pas de .xci copié) ; les IP préservés
│   │                     # sont complètement ignorés ici (voir ci-dessous)
│   ├── BD/               # scripts write_bd_tcl — BDs non préservés uniquement
│   │                     # (pas de .bd copié) ; les BDs préservés sont
│   │                     # complètement ignorés ici, sans repli Tcl (voir
│   │                     # ci-dessous)
│   ├── Simulation/       # Bancs de test
│   ├── Data/             # fichiers .mem, .coe, .mif, .hex, .elf, .csv
│   ├── Scripts/          # scripts Tcl de pré/post-hook
│   ├── Checkpoints/      # (DFX uniquement) DCP statiques verrouillés
│   └── NoC/              # (configuration segmentée uniquement) fichiers .ncr
└── Scripts/
    ├── project_settings.tcl
    └── build.tcl

Sorties préservées (étape 2.5 répondue "Oui", ≥1 IP/BD sélectionné)

Si l'étape 2.5 a préservé quelque chose, le seul artefact est un répertoire de cache distant externe — un chemin en dehors du projet que l'utilisateur a fourni (cache_dir dans preserve_selection), jamais copié dans RevisionControl/ et jamais suivi par git :

<cache_dir>/
└── project_1/
    ├── ip/
    │   └── <nom_ip>/
    │       ├── srcs/     # copie du répertoire .srcs de cet IP (le fichier
    │       │             # .xci est à l'intérieur intact)
    │       └── gen/      # fichiers .dcp, .xcix, stub .vhd/.v générés
    └── bd/
        └── <nom_bd>/
            ├── srcs/     # copie du répertoire .srcs de ce BD (le fichier
            │             # .bd est à l'intérieur intact)
            └── gen/      # wrapper, synth_ip DCP/rapports, etc.

Sorties préservées et CI/agentique (étape 2.5 jamais rencontrée)

Aucun artefact de préservation n'existe — le pipeline se comporte comme un pipeline en 5 étapes classique (antérieur au 2026-09-21) : tout l'export est basé sur Tcl, rien n'est mis en cache externe, RevisionControl/ contient tous les scripts Tcl IP/BD comme avant, et build.tcl régénère tout.

Note de mise en œuvre : capture des paramètres

Les propriétés suivantes sont capturées dans project_settings.tcl si elles diffèrent des valeurs par défaut :

Propriété	Commentaire
PART	Dispositif cible
BOARD_PART	Partie de carte (si définie)
TARGET_LANGUAGE	VHDL / Verilog / Mixed
VERILOG_DEFINE	Définitions de préprocesseur
TOP	Module de plus haut niveau
PR_FLOW	1 pour DFX
SEGMENTED_CONFIGURATION	Chaîne AXI / PCIe / etc.
SYNTHESIS.DIRECTIVE	Par défaut si non défini
IMPLEMENTATION.DIRECTIVE	Par défaut si non défini
VHDL_LIBRARY	Par fichier source
IS_GLOBAL_INCLUDE	Par fichier source

Encodage de fichiers non Tcl dans les scripts Tcl

Tous les binaires et fichiers de données (.dcp, .edf, .ngo, .ngc, .bin, .mcs, .prm, .ltx, .xpe, .xlsm) sont copiés littéralement dans le répertoire d'exportation et référencés par chemin de fichier dans les scripts — ils ne sont pas encodés en base64. Les fichiers .bit, .xsa et .dsa sont explicitement exclus de l'exportation (trop gros, résultent de la construction). Les rapports de timing et les fichiers journaux de Vivado (.rpt, .log, .jou) sont également exclus en tant qu'artefacts de construction.

Dépannage

Problème	Cause probable	Solution
L'étape 1 retourne "Inconnu"	PART non définie, ou arrière-plan Tcl	Définir `current_project [current_project]` si nécessaire ; vérifier que PARTS est défini
L'étape 2 retourne "Remote"	Tous les fichiers sources ont des chemins	C'est intentionnel ; ne pas exécuter l'étape 3
L'étape 3 échoue pour DFX	`PR_FLOW` pas activé, ou pblock manquant	Activer `PR_FLOW` ; s'assurer que le pblock existe
`write_ip_tcl` échoue silencieusement	Session Vivado trop ancienne, ou erreur silencieuse	Utiliser `set ip [get_ips -quiet $name] ; write_ip_tcl $script -ip_object $ip` et vérifier `$script`
`build.tcl` ne trouve pas les sources	Chemin relatif mal calculé	Vérifier que `RevisionControl/` est un frère du projet original
Étape 2.5 : `prompt_preserve_outputs` n'affiche rien	Aucun tty (CI/agentique)	Utiliser le flux agentique : `list_preservable_outputs` → demander à l'humain → `build_preserve_selection`

chemmy-11/vivado-revision-control

Qu'est-ce que vivado-revision-control ?

Demander à votre IA préférée

Documentation