Aller au contenu

Contraintes XDC et temporelles

Les contraintes appartiennent à la spécification. Elles indiquent les broches physiques et décrivent à l'analyse temporelle les délais exigés par le monde extérieur.

Partir du XDC officiel

Utilisez le XDC maître Basys 3 :

  1. Copier le fichier dans le projet.
  2. Décommenter seulement l'horloge et les périphériques utilisés.
  3. Renommer chaque port get_ports comme dans l'entité supérieure.
  4. Laisser le reste commenté.
  5. Noter la révision de la carte.

Horloge :

set_property PACKAGE_PIN W5 [get_ports clk_i]
set_property IOSTANDARD LVCMOS33 [get_ports clk_i]
create_clock -add -name sys_clk -period 10.000 -waveform {0 5.000} [get_ports clk_i]

Une période de 10 ns exprime 100 MHz.

Broches

set_property PACKAGE_PIN V17 [get_ports switch_i]
set_property IOSTANDARD LVCMOS33 [get_ports switch_i]

set_property PACKAGE_PIN U16 [get_ports led_o]
set_property IOSTANDARD LVCMOS33 [get_ports led_o]

Force de sortie, slew, pull-up et pull-down ne doivent être ajoutés que si l'interface le demande.

Ordre logique des contraintes

  1. Définir les horloges primaires.
  2. Définir les horloges générées.
  3. Définir les délais d'entrée/sortie des interfaces synchrones.
  4. Déclarer les relations entre horloges.
  5. Ajouter des exceptions ciblées uniquement après compréhension du chemin.

Délais d'entrée et de sortie

Pour un composant externe synchrone :

set_input_delay  -clock ext_clk -max 3.0 [get_ports data_i[*]]
set_input_delay  -clock ext_clk -min 0.5 [get_ports data_i[*]]
set_output_delay -clock ext_clk -max 2.5 [get_ports data_o[*]]
set_output_delay -clock ext_clk -min -0.2 [get_ports data_o[*]]

Ces valeurs ne sont que des exemples. Elles se calculent depuis la fiche technique externe, le circuit imprimé et la relation d'horloge.

Un bouton est asynchrone : un délai d'entrée relatif à l'horloge système ne constitue pas un modèle honnête. Il faut le synchroniser.

Les faux chemins ne corrigent pas le matériel

set_false_path retire un chemin de l'analyse. Il ne le rend pas plus sûr.

Danger

N'ajoutez jamais une fausse route simplement pour faire disparaître un nombre rouge. Vous supprimez une vérification, pas un défaut électrique.

Une exception n'est valable que si l'architecture rend réellement la relation temporelle inutile.

Chemins multicycles

Ils ne sont valables que si le protocole garantit plusieurs cycles au récepteur. Une contrainte de setup multicycle implique également d'analyser le hold correspondant.

Interroger les objets

get_ports *
get_clocks *
get_cells -hierarchical *sync*
report_clocks
report_clock_interaction

Une requête vide signifie que la contrainte ne touche peut-être aucun objet. Lisez les messages de contraintes.

Concepts temporels

horloge de lancement → clock-to-Q → logique/routage → setup du registre destination
  • Setup : donnée arrivée assez tôt avant le front de capture.
  • Hold : donnée stable assez longtemps après ce front.
  • Slack : temps requis moins temps d'arrivée.
  • WNS : pire slack négatif.
  • TNS : somme des slacks négatifs de setup.

L'objectif normal est l'absence de violation setup et hold sur tous les groupes correctement contraints.

Rapports essentiels

report_timing_summary
report_timing -max_paths 10 -sort_by group
report_utilization
report_drc
report_clock_interaction
report_cdc

Examinez aussi les chemins non contraints. Un message « timing met » avec une horloge oubliée est trompeur.

Relecture XDC

  • Révision de carte et source du XDC notées.
  • Broche et I/O standard corrects pour chaque port utilisé.
  • Horloge 100 MHz contrainte à 10 ns.
  • Horloges générées déclarées si elles existent réellement.
  • Délais I/O des interfaces synchrones présents.
  • Chaque exception possède une justification architecturale.
  • Aucune requête importante ne sélectionne zéro objet.
  • Aucun chemin pertinent n'est non contraint.