Design Vision
Objectif et configuration
Inspection graphique de conception DC et interaction de synthèse. Utilisez Design Compiler pour une synthèse reproductible sans tête ; Design Vision est utile pour l'inspection de la hiérarchie, du timing et des schémas.
Résoudre design_vision à partir de l'environnement configuré de l'utilisateur ou du profil d'outil.
Découvrir la version réelle, les options supportées, les licences et la documentation localement.
Utiliser la découverte d'environnement ; ne pas supposer un
répertoire d'installation, un compte, un point de terminaison de licence ou un shell de démarrage particulier.
Conserver les inventaires d'installation, les journaux et les index de documentation dans un état local privé.
Conventions d'invocation et de commandes
Utiliser l'exécutable configuré directement depuis l'environnement préparé. Préserver son nom de wrapper ; changer le nom d'invocation d'un répartiteur peut sélectionner un produit différent. Confirmer les conventions interactives et par lots dans la documentation de cette version. Cette référence fournit des candidats de commandes, pas la preuve de leur existence dans chaque version.
design_vision -f design.tcl
Pour les scripts d'étape supportés, flow.py capture les commandes, statut, journaux, artefacts et points de contrôle sans nécessiter un wrapper shell. Les outils peuvent fournir des interfaces natives avec des sémantiques différentes pour des indicateurs similaires.
Entrées et sorties
DC .ddc ou RTL/netlist supporté avec bibliothèques correspondantes, SDC et configuration de conception ; un affichage fonctionnel pour une utilisation GUI. Utiliser des copies des points de contrôle pour des modifications exploratoires.
Points de contrôle de conception compatibles DC, rapports et journaux de session ; artefacts GUI exportés explicitement lorsque supportés. Ne pas écraser les points de contrôle de synthèse acceptés lors de l'inspection.
Opérations d'étape
Récupérer la syntaxe des commandes installées, les types d'arguments, les valeurs par défaut, les restrictions, les exemples, les exigences de fonctionnalité et les prérequis d'état de conception avant de construire des nouvelles commandes. Identifier si chaque opération interroge l'état, met à jour l'état dérivé, modifie une conception ou exporte des artefacts.
| Étape | Commandes ou procédure native | Prérequis et vérifications |
|---|---|---|
| Charger/inspecter | read_ddc current_design report_hierarchy report_timing | Utiliser le contexte de bibliothèque/contrainte de synthèse correspondant au design sauvegardé. |
| Synthèse | analyze elaborate compile | Déléguer la synthèse reproductible et les portes formelles à synopsys-design-compiler. |
| Sauvegarder | write_file write_sdc | Traiter toute modification de conception comme un nouveau candidat nécessitant vérification. |
Tcl, inspection et documentation
Les commandes DC de conception/collection s'appliquent là où elles sont documentées : current_design, get_designs *, report_hierarchy, report_timing, report_area et check_design. Les API spécifiques à la GUI doivent être recherchées séparément.
Pour les interfaces Tcl, construire les chemins/arguments comme des listes Tcl, gérer les collections en utilisant les API de collection supportées, intercepter les erreurs et inspecter explicitement les valeurs de retour des commandes. Un fichier Tcl syntaxiquement valide n'établit pas la disponibilité des commandes. Pour les pilotes natifs, utiliser leur format d'entrée documenté à la place.
python3 scripts/docs.py search '' --tool design-vision --limit 20
# Sélectionner la version installée lorsque plusieurs correspondances existent.
# Récupérer une entrée retournée avec : python3 scripts/docs.py show DOCUMENT_ID
Les exemples s'exécutent depuis le répertoire du bundle. Lire la découverte de commandes pour la création d'index privé, la récupération bornée, la disponibilité à l'exécution et les vérifications de cycle de vie. Une entrée manuelle peut décrire une variable ou un diagnostic plutôt qu'une commande appelable. Une documentation manquante reste un obstacle à la sélection de commandes non supportées.
Paramètres contrôlés et dépendances
Les paramètres de synthèse suivent la politique DC. Les paramètres d'affichage/disposition GUI sont observationnels ; toute modification de conception mappée invalide les preuves d'équivalence et physiques en aval.
Même contexte DC version/base de données/bibliothèque ; les bibliothèques/affichage GUI peuvent échouer indépendamment de dc_shell. Utiliser le nom exact du wrapper car il sélectionne la personnalité du produit.
Enregistrer les valeurs originales/proposées, l'hypothèse supportée par le rapport, la référence manuelle, l'étape valide et la métrique attendue. Utiliser l'optimisation pour des comparaisons bornées avec des fonctionnalités immuables et des contraintes dures.
Récupération d'échec et vérification
Diagnostiquer les erreurs d'affichage/GUI séparément des erreurs de synthèse. Préserver les noms de wrapper et le contexte de conception/bibliothèque. Toute modification de conception nécessite de nouvelles preuves de synthèse/formelle avant une promotion ultérieure.
Capturer la commande/le statut, les journaux internes, les rapports et l'identité de l'état/du point de contrôle. Classifier la cause, consulter la documentation installée pertinente et appliquer la correction justifiée la moins perturbatrice. Restaurer une copie inscriptible du dernier point de contrôle entrant valide et réexécuter les étapes affectées. Comparer les métriques vérifiées avant de conserver une modification ; conserver les tentatives rejetées. Utiliser le dépannage pour la décision de récupération.
Les modifications fonctionnelles nécessitent une autorisation explicite. Ne pas assouplir les exigences de timing, supprimer les contraintes requises ou contourner la vérification pour signaler un succès. Arrêter lorsqu'aucune correction justifiée ne reste ou qu'un budget configuré est épuisé, et signaler quelle entrée ou réparation d'environnement est nécessaire.
Modèles et acceptation
Inspecter les sorties réelles et les rapports spécifiques au produit par rapport à la portée demandée. Pour la synthèse/implémentation, exiger des artefacts mappés/liés et des contraintes préservées ; reprouver la fonctionnalité après les transformations. Pour la vérification, exiger une couverture complète et des vérifications requises propres. Pour la simulation/débogage, exiger que la tâche/le test prévu se termine avec des diagnostics examinés.
Conserver séparément la validation de la documentation, les vérifications de syntaxe Tcl, l'exécution de l'outil, l'acceptation d'étape et les preuves de validation de bout en bout. Un flux généré n'est pas une implémentation vérifiée. Voir le contrat d'exécution et la portée de validation pour les limites de preuves requises.