Chapitre 14 — Temps, événements et modèle de simulation
Objectif — Finalité du chapitre Comprendre comment le simulateur VHDL planifie les transactions, détecte les événements, applique les délais et ordonne les processus, afin d’interpréter correctement les chronogrammes et les cycles delta. |
Objectifs pédagogiques
À la fin de ce chapitre, l’étudiant devra être capable de :
- distinguer transaction, activité et événement sur un signal ;
- utiliser l’attribut 'event ;
- expliquer les retards inertiel et de transport ;
- identifier les impulsions rejetées par un modèle inertiel ;
- décrire l’ordonnancement des cycles delta ;
- expliquer la mise à jour différée des signaux ;
- comparer l’affectation d’un signal et celle d’une variable ;
- utiliser les attributs 'last_value, 'last_event, 'stable, 'quiet et 'delayed ;
- distinguer simulation fonctionnelle et simulation temporelle ;
- analyser un chronogramme comportant plusieurs processus ;
- diagnostiquer les résultats inattendus dus aux cycles delta.
Prérequis
- affectations concurrentes et processus ;
- signaux, variables et constantes ;
- bancs de test et chronogrammes ;
- détection des fronts d’horloge ;
- notions de synthèse et de placement-routage.
Organisation du chapitre
Section | Contenu | Compétence principale |
|---|---|---|
| 14.1 | Événements et transactions | Comprendre l’activité des signaux |
| 14.2 | Retards inertiel et transport | Modéliser la propagation temporelle |
| 14.3 | Cycles delta | Interpréter l’ordonnancement du simulateur |
| 14.4 | Attributs des signaux | Interroger l’historique temporel |
| 14.5 | Simulations fonctionnelle et temporelle | Choisir le niveau de validation |
| TD | Analyses et chronogrammes | Résoudre des situations complexes |
Concept clé — Temps physique et temps de simulation Un cycle delta ne fait pas avancer le temps physique affiché. Il permet au simulateur de stabiliser les dépendances entre processus à un même instant. |
14.1 Notion d’événement
Le simulateur manipule des signaux dont les valeurs évoluent selon des transactions planifiées. Un événement se produit uniquement lorsque la valeur effective d’un signal change.
14.1.1 Changement de valeur d’un signal
| Affectation immédiate en temps, différée en delta | VHDL |
| a <= '1'; |
Cette instruction planifie une transaction. La valeur de a n’est pas modifiée au milieu de l’exécution du processus ; elle sera mise à jour lors d’une phase ultérieure du cycle de simulation.
14.1.2 Transaction
Une transaction est une demande de mise à jour d’un signal à une valeur et à un instant donnés. Une transaction peut ou non produire un événement.
Valeur actuelle | Transaction planifiée | Activité | Événement |
|---|---|---|---|
| 0 | 0 | Oui | Non |
| 0 | 1 | Oui | Oui |
| 1 | 1 | Oui | Non |
| 1 | 0 | Oui | Oui |
14.1.3 Activité d’un signal
Un signal est actif lorsqu’une transaction est appliquée à son pilote, même si la valeur finale reste identique. L’activité est donc plus générale que l’événement.
Définition — Différence essentielle Toute modification de valeur est précédée d’une activité, mais toute activité ne provoque pas nécessairement un événement. |
14.1.4 Attribut 'event
| Détection d’un événement | VHDL |
| if clk'event then -- clk vient de changer de valeur end if; |
L’attribut 'event retourne true pendant le cycle delta où un événement vient de se produire sur le signal.
14.1.5 Ancienne détection du front montant
| Forme historique | VHDL |
| if clk'event and clk = '1' then q <= d; end if; |
Cette forme est correcte dans de nombreux modèles, mais rising_edge(clk) exprime plus clairement l’intention et tient compte des règles du type std_logic.
14.1.6 Attribut 'active
| Détection d’une transaction appliquée | VHDL |
| if bus'active then report "Une transaction a ete appliquee au bus"; end if; |
'active peut être vrai même si bus conserve sa valeur. Cet attribut permet d’étudier l’activité des pilotes.
14.1.7 Exemple activité sans événement
| Deux affectations identiques | VHDL |
| signal s : std_logic := '0'; stimuli : process begin s <= '0'; wait for 10 ns; s <= '1'; wait; end process; |
La transaction s <= '0' produit une activité au début du test, mais aucun événement si s vaut déjà 0.
14.1.8 Transactions retardées
| Forme ondulatoire | VHDL |
| s <= '1' after 10 ns, '0' after 20 ns, '1' after 30 ns; |
Instant prévu | Transaction |
|---|---|
| 10 ns | s reçoit 1 |
| 20 ns | s reçoit 0 |
| 30 ns | s reçoit 1 |
14.1.9 Plusieurs pilotes
Un signal résolu comme std_logic peut recevoir des transactions de plusieurs pilotes. Une fonction de résolution détermine alors la valeur effective.
| Deux pilotes conceptuels | VHDL |
| pilote_1 : process begin bus <= '1'; wait; end process; pilote_2 : process begin bus <= '0'; wait; end process; |
Avec std_logic, le conflit entre 1 et 0 produit généralement X. Avec un type non résolu, plusieurs pilotes sont interdits.
14.1.10 Ordre conceptuel
Étape | Action du simulateur |
|---|---|
| 1 | Un processus exécute une affectation de signal. |
| 2 | Une transaction est ajoutée au pilote. |
| 3 | À l’instant prévu, le pilote est mis à jour. |
| 4 | La valeur résolue du signal est recalculée. |
| 5 | Si la valeur change, un événement est créé. |
| 6 | Les processus sensibles au signal sont réveillés. |
14.2 Retards en VHDL
Les affectations retardées modélisent la propagation d’un signal. VHDL distingue principalement le retard inertiel, utilisé par défaut, et le retard de transport.
14.2.1 Retard inertiel
Le retard inertiel représente un composant incapable de transmettre les impulsions trop courtes. Il convient à de nombreuses portes logiques.
| Retard inertiel explicite | VHDL |
| y <= inertial a after 10 ns; |
| Retard inertiel implicite | VHDL |
| y <= a after 10 ns; |
Sans mot-clé transport, l’affectation retardée est inertielle par défaut.
14.2.2 Rejet des impulsions courtes
Avec un retard inertiel de 10 ns, une impulsion plus courte que la limite de rejet peut disparaître du signal de sortie.
Impulsion d’entrée | Sortie inertielle typique |
|---|---|
| Largeur 3 ns | Rejetée |
| Largeur 8 ns | Rejetée avec limite de 10 ns |
| Largeur 12 ns | Transmise après le retard |
14.2.3 Clause reject
| Limite de rejet personnalisée | VHDL |
| y <= reject 4 ns inertial a after 10 ns; |
Le modèle impose un délai de propagation de 10 ns, mais rejette seulement les impulsions plus courtes que 4 ns.
14.2.4 Retard de transport
Le retard de transport transmet toutes les transactions, même les impulsions très courtes. Il représente un délai de propagation idéal, par exemple une ligne de transmission abstraite.
| Transport pur | VHDL |
| y <= transport a after 10 ns; |
14.2.5 Comparaison
Critère | Inertiel | Transport |
|---|---|---|
| Mot-clé | inertial ou implicite | transport |
| Impulsions courtes | Peuvent être rejetées | Toujours transmises |
| Modèle typique | Porte logique | Ligne ou connexion idéale |
| Usage RTL synthétisable | after généralement ignoré ou interdit | Simulation uniquement |
14.2.6 Exemple comparatif
| Deux sorties soumises au même stimulus | VHDL |
| sortie_inertielle <= entree after 10 ns; sortie_transport <= transport entree after 10 ns; |
Une impulsion de 5 ns sur entree peut être absente de sortie_inertielle, mais apparaît sur sortie_transport avec un décalage de 10 ns.
14.2.7 Génération d’une impulsion courte
| Stimulus | VHDL |
| entree <= '0'; wait for 10 ns; entree <= '1'; wait for 5 ns; entree <= '0'; wait for 30 ns; |
14.2.8 Chronologie attendue
Instant | entrée | sortie inertielle | sortie transport |
|---|---|---|---|
| 10 ns | Monte à 1 | Aucune sortie immédiate | Transaction prévue à 20 ns |
| 15 ns | Redescend à 0 | Impulsion susceptible d’être annulée | Transaction prévue à 25 ns |
| 20 ns | 0 | Reste 0 | Monte à 1 |
| 25 ns | 0 | Reste 0 | Redescend à 0 |
14.2.9 Affectation avec plusieurs formes d’onde
| Transactions multiples | VHDL |
| y <= transport '1' after 5 ns, '0' after 12 ns, '1' after 20 ns; |
Les délais des éléments successifs doivent être croissants dans la forme d’onde.
14.2.10 Effet d’une nouvelle affectation
Lorsqu’un processus exécute une nouvelle affectation sur le même pilote, le simulateur met à jour la file de transactions selon les règles inertielle ou transport. Les transactions futures peuvent être conservées, remplacées ou supprimées selon le modèle.
Précision — Ne pas confondre Le retard inertiel n’est pas simplement un décalage temporel. Il inclut un comportement de filtrage des impulsions. |
14.2.11 Synthèse des retards
Une expression after représente un temps de simulation. Dans une description RTL synthétisable, elle ne crée pas automatiquement un retard physique contrôlé.
- Les outils de synthèse ignorent souvent les délais after ou les refusent.
- Les délais physiques dépendent de la technologie et du placement-routage.
- Une temporisation matérielle doit être réalisée avec horloge et compteur.
- Les modèles inertiels et transport sont surtout utilisés en simulation.
14.2.12 Exemple de mauvaise temporisation RTL
| Non portable pour la synthèse | VHDL |
| sortie <= entree after 100 ns; |
| Temporisation matérielle correcte | VHDL |
| if rising_edge(clk) then if compteur = LIMITE then sortie <= entree; else compteur <= compteur + 1; end if; end if; |
14.3 Delta cycles
Les cycles delta permettent au simulateur de résoudre les dépendances entre signaux et processus sans faire avancer le temps physique.
14.3.1 Mise à jour différée des signaux
| Signal relu immédiatement | VHDL |
| process begin s <= '1'; assert s = '1' report "s n'est pas encore mis a jour" severity warning; wait; end process; |
Pendant l’exécution du processus, s conserve son ancienne valeur. La transaction sera appliquée après la suspension du processus.
14.3.2 Variable mise à jour immédiatement
| Variable locale | VHDL |
| process variable v : std_logic := '0'; begin v := '1'; assert v = '1' report "Cette assertion ne doit pas echouer" severity error; wait; end process; |
14.3.3 Signal contre variable
Propriété | Signal | Variable |
|---|---|---|
| Affectation | <= | := |
| Mise à jour | Planifiée | Immédiate |
| Communication entre processus | Oui | Non directement |
| Événement | Peut réveiller un processus | Aucun événement de signal |
| Valeur relue dans le même processus | Ancienne jusqu’à mise à jour | Nouvelle immédiatement |
14.3.4 Exemple de chaîne concurrente
| Trois affectations | VHDL |
| b <= a; c <= b; d <= c; |
Si a change, b, c et d ne sont pas nécessairement mis à jour dans un seul cycle delta. La propagation logique nécessite plusieurs cycles delta.
14.3.5 Chronologie en cycles delta
Temps | Delta | Action |
|---|---|---|
| 10 ns | δ0 | a change ; le processus de b est réveillé |
| 10 ns | δ1 | b est mis à jour ; le processus de c est réveillé |
| 10 ns | δ2 | c est mis à jour ; le processus de d est réveillé |
| 10 ns | δ3 | d est mis à jour ; le réseau devient stable |
14.3.6 Plusieurs processus
| Processus interdépendants | VHDL |
| P1 : process(a) begin b <= not a; end process; P2 : process(b) begin c <= b and enable; end process; |
Un changement de a exécute P1. La mise à jour future de b réveille ensuite P2 lors d’un delta suivant.
14.3.7 Ordonnancement simplifié
1. Les processus réveillés s’exécutent jusqu’à leur suspension.
2. Les affectations de variables prennent effet immédiatement.
3. Les affectations de signaux créent des transactions.
4. Le simulateur applique les transactions prévues pour le delta courant.
5. Les événements réveillent de nouveaux processus.
6. Le simulateur répète les deltas jusqu’à stabilisation.
7. Lorsqu’aucun travail ne reste, le temps avance vers la prochaine transaction.
14.3.8 Processus avec deux affectations de signal
| Dernière transaction du même processus | VHDL |
| process(a) begin y <= a; y <= not a; end process; |
Les deux affectations ciblent le même pilote et le même instant. La dernière affectation détermine généralement la transaction finale conservée pour ce delta.
14.3.9 Variables intermédiaires
| Calcul séquentiel immédiat | VHDL |
| process(a, b, c) variable temp : std_logic; begin temp := a and b; temp := temp or c; y <= temp; end process; |
La deuxième ligne utilise la nouvelle valeur de temp. Une seule affectation finale est planifiée pour y.
14.3.10 Deux signaux intermédiaires
| Résultat inattendu dans le même processus | VHDL |
| process(a, b, c) begin s1 <= a and b; s2 <= s1 or c; y <= s2; end process; |
s2 utilise l’ancienne valeur de s1 et y utilise l’ancienne valeur de s2. Plusieurs activations sont nécessaires si s1 et s2 figurent correctement dans la sensibilité.
14.3.11 Correction combinatoire
| Version avec variables | VHDL |
| process(all) variable v1 : std_logic; variable v2 : std_logic; begin v1 := a and b; v2 := v1 or c; y <= v2; end process; |
| Version concurrente | VHDL |
| s1 <= a and b; s2 <= s1 or c; y <= s2; |
14.3.12 Sensibilité et cycles delta
Dans un processus combinatoire, tous les signaux lus doivent être présents dans la sensibilité. Sinon, le simulateur peut ne pas réexécuter le processus après la mise à jour d’un signal intermédiaire.
Bonne pratique — process(all) VHDL-2008 réduit les erreurs de sensibilité en incluant automatiquement les signaux lus. |
14.3.13 Oscillation en delta
| Boucle combinatoire pathologique | VHDL |
| a <= not a; |
Ce modèle peut provoquer une succession infinie de cycles delta à un même instant, car chaque mise à jour entraîne une nouvelle valeur.
Attention — Limite d’itérations Les simulateurs imposent souvent une limite de cycles delta afin de détecter les boucles combinatoires non stabilisables. |
14.3.14 Wait for 0 ns
| Passage à un delta suivant | VHDL |
| s <= '1'; wait for 0 ns; assert s = '1' severity error; |
wait for 0 ns ne fait pas avancer le temps physique, mais permet au simulateur de passer par une nouvelle phase de mise à jour.
14.4 Attributs des signaux
Les attributs temporels fournissent des informations sur les événements, les valeurs précédentes, l’activité et la stabilité d’un signal.
14.4.1 Attribut 'event
| Événement au delta courant | VHDL |
| if signal_x'event then report "signal_x a change de valeur"; end if; |
'event est un booléen vrai lors d’un changement effectif de valeur.
14.4.2 Attribut 'last_value
| Valeur précédente | VHDL |
| if entree'event then report "Ancienne valeur = " & std_logic'image(entree'last_value); end if; |
'last_value retourne la valeur du signal avant son dernier événement.
14.4.3 Détection manuelle d’un front
| Transition 0 vers 1 | VHDL |
| if clk'event and clk'last_value = '0' and clk = '1' then -- Front montant end if; |
Cette écriture est pédagogique ; rising_edge(clk) reste recommandé.
14.4.4 Attribut 'last_event
| Temps depuis le dernier événement | VHDL |
| if entree'last_event > 20 ns then report "Entree stable depuis plus de 20 ns"; end if; |
'last_event retourne une valeur de type time correspondant au temps écoulé depuis le dernier changement de valeur.
14.4.5 Attribut 'stable
| Stabilité sur une durée | VHDL |
| if entree'stable(10 ns) then valide <= '1'; else valide <= '0'; end if; |
L’attribut crée un signal booléen implicite vrai si aucun événement n’a eu lieu pendant la durée indiquée.
14.4.6 Assertion de stabilité
| Contrôle autour d’une opération | VHDL |
| assert donnees'stable(5 ns) report "Les donnees ont change trop recemment" severity warning; |
14.4.7 Attribut 'quiet
| Absence d’activité | VHDL |
| if bus'quiet(10 ns) then report "Aucune transaction recente sur le bus"; end if; |
'quiet est sensible aux transactions, même lorsque celles-ci ne changent pas la valeur du signal.
14.4.8 Différence stable/quiet
Situation | 'stable(10 ns) | 'quiet(10 ns) |
|---|---|---|
| Aucune transaction | True | True |
| Transaction vers la même valeur | Peut rester True | False |
| Transaction changeant la valeur | False | False |
14.4.9 Attribut 'delayed
| Copie retardée implicite | VHDL |
| signal_retarde <= signal_x'delayed(10 ns); |
signal_x'delayed(10 ns) désigne un signal implicite reproduisant signal_x avec un retard de 10 ns.
14.4.10 Détection d’un changement trop rapide
| Contrôle de période minimale | VHDL |
| process(clk) begin if clk'event then assert clk'last_event >= 5 ns report "Periode ou demi-periode trop courte" severity error; end if; end process; |
Prudence — Valeur de 'last_event Dans un processus réveillé par l’événement courant, l’interprétation des attributs temporels doit être validée avec le simulateur et le contexte exact. Pour mesurer une période, il est souvent plus clair de mémoriser explicitement l’instant précédent avec now. |
14.4.11 Utilisation de now
| Mesure explicite entre deux fronts | VHDL |
| process(clk) variable instant_precedent : time := 0 ns; variable periode_mesuree : time; begin if rising_edge(clk) then periode_mesuree := now - instant_precedent; instant_precedent := now; end if; end process; |
14.4.12 Attribut 'transaction
En complément, 'transaction fournit un signal implicite qui change à chaque transaction du signal source. Il permet de surveiller l’activité des pilotes.
| Surveillance des transactions | VHDL |
| process(bus'transaction) begin report "Nouvelle transaction sur bus"; end process; |
14.4.13 Tableau récapitulatif
Attribut | Type/rôle | Question répondue |
|---|---|---|
| 'event | Booléen | La valeur vient-elle de changer ? |
| 'active | Booléen | Une transaction vient-elle d’être appliquée ? |
| 'last_value | Même type que le signal | Quelle était la valeur précédente ? |
| 'last_event | time | Depuis combien de temps la valeur n’a-t-elle pas changé ? |
| 'stable(T) | Signal booléen | Aucun événement pendant T ? |
| 'quiet(T) | Signal booléen | Aucune transaction pendant T ? |
| 'delayed(T) | Signal implicite | Quelle est la copie retardée de T ? |
| 'transaction | Signal de type bit | Une transaction a-t-elle eu lieu ? |
14.5 Simulation fonctionnelle et temporelle
Les différentes étapes de simulation répondent à des questions complémentaires sur la fonction logique et le comportement temporel du circuit.
14.5.1 Simulation avant synthèse
La simulation RTL ou comportementale utilise le code source VHDL. Elle vérifie principalement la fonction et l’ordonnancement logique.
- temps de simulation généralement court ;
- signaux internes proches du code source ;
- délais physiques non représentés, sauf modèles explicites ;
- cycles delta visibles dans certaines analyses ;
- étape principale pour les bancs de test fonctionnels.
14.5.2 Simulation fonctionnelle post-synthèse
Une simulation de la netlist synthétisée, sans délais détaillés, vérifie que la transformation en portes et registres conserve la fonction.
Question | Réponse recherchée |
|---|---|
| Les optimisations ont-elles conservé la fonction ? | Équivalence logique |
| Les initialisations sont-elles prises en charge ? | Comportement de la netlist |
| Les primitives sont-elles correctement inférées ? | Structure technologique |
14.5.3 Simulation temporelle post-implantation
Après placement et routage, les délais de cellules et d’interconnexions peuvent être annotés dans une netlist de simulation.
- délais dépendant de la technologie ;
- retards de routage ;
- temps clock-to-Q ;
- délais de setup et hold ;
- glitches liés aux chemins de propagation ;
- simulation plus lente et plus complexe.
14.5.4 Modèles technologiques
Les bibliothèques du fabricant décrivent les primitives, leurs fonctions et leurs caractéristiques temporelles.
Élément | Exemple de contenu |
|---|---|
| LUT | Fonction logique et délai |
| Bascule | Setup, hold, clock-to-Q |
| Buffer d’horloge | Propagation et distribution |
| Bloc mémoire | Temps d’accès et modes de fonctionnement |
| E/S | Délais d’entrée et de sortie |
14.5.5 Annotation des délais
Les outils de conception peuvent produire un fichier d’annotation temporelle, souvent au format SDF, associé à une netlist de simulation.
Contexte — Dépendance aux outils La procédure exacte de simulation temporelle dépend du fabricant FPGA, du simulateur, des bibliothèques et de la version des outils. |
14.5.6 Comparaison des niveaux
Niveau | Entrée | Délais | Objectif |
|---|---|---|---|
| RTL fonctionnel | Code VHDL | Idéaux ou explicites | Valider l’algorithme |
| Post-synthèse fonctionnel | Netlist | Faibles ou nuls | Valider la transformation |
| Post-route temporel | Netlist implantée | Technologiques | Observer la propagation |
| Analyse temporelle statique | Netlist + contraintes | Pires chemins | Prouver le respect des timings |
14.5.7 Simulation temporelle et analyse statique
La simulation temporelle ne remplace pas l’analyse temporelle statique. Elle ne couvre que les scénarios simulés, alors que l’analyse statique examine systématiquement les chemins contraints.
Simulation temporelle | Analyse temporelle statique |
|---|---|
| Dépend des vecteurs de test | Examine tous les chemins contraints |
| Produit des chronogrammes | Produit marges et rapports |
| Observe des séquences | Vérifie setup, hold et fréquences |
| Peut être très lente | Plus adaptée à la fermeture temporelle |
14.5.8 Retards physiques et RTL
Le code RTL doit décrire une architecture synchrone robuste, pas tenter de compenser arbitrairement des délais physiques avec after.
| À éviter dans le RTL synthétisable | VHDL |
| q <= d after 3 ns; |
Le délai physique réel de q dépendra de la bascule, du routage, de la charge et des conditions de fonctionnement.
14.5.9 Glitches en simulation temporelle
Deux chemins combinatoires de délais différents peuvent produire une impulsion transitoire. Une simulation fonctionnelle idéale peut ne pas la montrer.
| Fonction sensible aux chemins | VHDL |
| y <= (a and b) or (not a and c); |
Lorsque a change et que les deux termes n’ont pas le même délai, y peut brièvement changer avant de retrouver sa valeur stable.
14.5.10 Stratégie de validation
1. Valider les unités avec des testbenches RTL auto-vérifiants.
2. Vérifier l’inférence et les avertissements de synthèse.
3. Définir les contraintes d’horloge et d’E/S.
4. Lancer l’analyse temporelle statique.
5. Utiliser une simulation technologique lorsque le projet ou l’interface le justifie.
6. Valider enfin sur la cible FPGA.
Travaux dirigés
TD 1 — Analyse d’une simulation avec plusieurs processus
Énoncé
| Réseau de trois processus | VHDL |
| signal a : std_logic := '0'; signal b : std_logic := '0'; signal c : std_logic := '0'; signal d : std_logic := '0'; P1 : process(a) begin b <= not a; end process; P2 : process(b) begin c <= b; end process; P3 : process(c) begin d <= c; end process; |
À 10 ns, a passe de 0 à 1. Déterminer l’évolution de b, c et d par cycle delta.
Correction
Instant | Delta | b | c | d | Explication |
|---|---|---|---|---|---|
| Avant 10 ns | stable | 1 | 1 | 1 | Valeurs stabilisées après l’initialisation |
| 10 ns | δ0 | 1 | 1 | 1 | a change et réveille P1 |
| 10 ns | δ1 | 0 | 1 | 1 | b change et réveille P2 |
| 10 ns | δ2 | 0 | 0 | 1 | c change et réveille P3 |
| 10 ns | δ3 | 0 | 0 | 0 | d change ; réseau stable |
Résultat — Lecture Toutes les modifications se produisent à 10 ns dans le temps physique, mais dans des cycles delta successifs. |
TD 2 — Étude des cycles delta
Énoncé
| Affectations dans un processus | VHDL |
| process(a, b) begin x <= a and b; y <= x; end process; |
Supposer a=1, b=1, x=0 et y=0. Le processus est activé par le changement de a. Quelles valeurs sont utilisées ?
Correction
- x <= a and b planifie x=1.
- y <= x lit encore l’ancienne valeur x=0.
- Après le processus, x passe à 1.
- Comme x est lu mais absent de la sensibilité, le processus ne se réexécute pas.
- y reste donc à 0 : la liste de sensibilité est incomplète.
| Correction VHDL-2008 | VHDL |
| process(all) begin x <= a and b; y <= x; end process; |
Cette correction réexécute le processus après l’événement sur x, mais y nécessite encore un delta supplémentaire. Pour un calcul local direct, une variable est souvent plus claire.
TD 3 — Signaux et variables
Énoncé
| Comparaison | VHDL |
| process variable v : integer := 0; begin s <= s + 1; s <= s + 1; v := v + 1; v := v + 1; report "v=" & integer'image(v); wait; end process; |
Expliquer les valeurs obtenues après la première activation.
Correction
Objet | Calcul | Résultat |
|---|---|---|
| Signal s | Les deux expressions lisent l’ancienne valeur ; la dernière transaction domine | Ancienne valeur + 1 |
| Variable v | Chaque affectation voit la valeur immédiatement précédente | Ancienne valeur + 2 |
TD 4 — Retard inertiel et transport
Énoncé
| Modèles | VHDL |
| y_i <= x after 8 ns; y_t <= transport x after 8 ns; |
x produit une impulsion de largeur 3 ns. Décrire y_i et y_t.
Correction
- y_i utilise le retard inertiel par défaut : l’impulsion de 3 ns est rejetée si elle est inférieure à la limite de rejet.
- y_t reproduit l’impulsion avec un décalage de 8 ns.
- La largeur de l’impulsion transportée reste 3 ns dans ce modèle idéal.
TD 5 — Attributs
Énoncé
Un signal bus reçoit une transaction vers sa valeur actuelle à 20 ns, puis change de valeur à 30 ns. Comparer bus'active, bus'event, bus'quiet(15 ns) et bus'stable(15 ns).
Correction
Instant | 'active | 'event | 'quiet(15 ns) | 'stable(15 ns) |
|---|---|---|---|---|
| 20 ns | True | False | False | Peut rester True |
| 30 ns | True | True | False | False |
TD 6 — Interprétation d’un chronogramme complexe
Scénario
| Circuit | VHDL |
| p <= a xor b; q <= transport p after 5 ns; r <= p after 5 ns; process(clk) begin if rising_edge(clk) then s <= r; end if; end process; |
a et b changent presque simultanément et créent une impulsion de 2 ns sur p. L’horloge présente un front montant 8 ns après le début de l’impulsion.
Questions
1. L’impulsion apparaît-elle sur q ?
2. L’impulsion apparaît-elle sur r ?
3. Quelle valeur peut être capturée par s au front ?
4. Pourquoi la réponse dépend-elle du chronogramme exact ?
Correction
- q utilise transport : l’impulsion de 2 ns est reproduite après 5 ns.
- r utilise l’inertiel par défaut : l’impulsion courte peut être rejetée.
- s capture la valeur de r présente au front montant.
- Le comportement dépend des instants précis de début, de fin et de propagation.
TD 7 — Détection d’une boucle delta
| Boucle sans délai | VHDL |
| signal a : std_logic := '0'; a <= not a; |
Expliquer pourquoi le temps ne progresse pas et proposer une version de banc de test qui fait progresser le temps.
Correction
| Oscillateur de simulation avec délai | VHDL |
| a <= not a after 10 ns; |
Le délai programme chaque nouvelle transaction 10 ns plus tard. Le temps peut donc avancer.
TD 8 — Simulation fonctionnelle ou temporelle ?
Besoin | Approche adaptée |
|---|---|
| Vérifier la table de vérité d’une UAL | Simulation RTL fonctionnelle |
| Vérifier un retour 9 vers 0 | Simulation RTL fonctionnelle |
| Mesurer la marge de setup d’un chemin | Analyse temporelle statique |
| Observer un glitch de routage | Simulation post-route temporelle éventuelle |
| Valider la logique après synthèse | Simulation fonctionnelle de netlist ou équivalence |
Méthode d’analyse d’un résultat inattendu
1. Identifier l’instant physique concerné.
2. Repérer les événements qui réveillent chaque processus.
3. Lister les valeurs lues au début de chaque activation.
4. Distinguer les affectations de variables et de signaux.
5. Construire la file des transactions planifiées.
6. Décomposer l’instant en cycles delta.
7. Vérifier les listes de sensibilité.
8. Rechercher les délais inertiels ou transport.
9. Examiner les attributs temporels et le chronogramme.
10. Ajouter des assertions et rapports ciblés.
Checklist de simulation
- Les signaux sont-ils initialisés ?
- Les délais sont-ils destinés à la simulation uniquement ?
- Les impulsions courtes doivent-elles être filtrées ou transmises ?
- Les assertions attendent-elles la stabilisation des deltas ?
- Les listes de sensibilité sont-elles complètes ?
- Une boucle combinatoire empêche-t-elle la stabilisation ?
- Le niveau de simulation répond-il à la question posée ?
Erreurs fréquentes
Erreur | Conséquence | Correction |
|---|---|---|
| Confondre transaction et événement | Mauvaise lecture de 'active et 'event | Vérifier si la valeur change |
| Relire un signal juste après <= | Ancienne valeur observée | Attendre un delta ou utiliser une variable |
| Utiliser after pour créer un retard matériel | RTL non portable | Compteur synchrone |
| Oublier le filtrage inertiel | Impulsion manquante | Utiliser transport si nécessaire |
| Liste de sensibilité incomplète | Simulation incohérente | process(all) |
| Boucle combinatoire | Deltas infinis | Rompre la boucle par un registre ou un délai de test |
| Confondre fonctionnel et temporel | Conclusion incorrecte | Choisir le bon modèle |
Synthèse du chapitre
Notion | Résumé |
|---|---|
| Transaction | Mise à jour planifiée sur un pilote. |
| Activité | Application d’une transaction. |
| Événement | Changement effectif de valeur. |
| Inertiel | Retard avec rejet possible des impulsions courtes. |
| Transport | Transmission de toutes les transactions. |
| Cycle delta | Étape d’ordonnancement sans avance du temps. |
| Signal | Mise à jour différée. |
| Variable | Mise à jour immédiate. |
| 'last_value | Valeur avant le dernier événement. |
| 'stable | Absence d’événement pendant une durée. |
| 'quiet | Absence de transaction pendant une durée. |
| Simulation temporelle | Modèle incluant des délais technologiques. |
Autoévaluation
1. Une transaction produit-elle toujours un événement ?
Réponse : Non, seulement si la valeur effective change.
2. Quel retard est utilisé par défaut ?
Réponse : Le retard inertiel.
3. Quel retard transmet les impulsions courtes ?
Réponse : Le retard de transport.
4. Un cycle delta fait-il avancer le temps ?
Réponse : Non.
5. Quand un signal affecté devient-il visible ?
Réponse : Lors d’une phase de mise à jour ultérieure.
6. Quand une variable devient-elle visible ?
Réponse : Immédiatement dans le processus.
7. Que retourne 'last_value ?
Réponse : La valeur avant le dernier événement.
8. Quelle différence existe entre 'stable et 'quiet ?
Réponse : 'stable surveille les événements ; 'quiet surveille les transactions.
9. Une simulation RTL inclut-elle les délais de routage ?
Réponse : Non, pas automatiquement.
10. Quelle analyse vérifie systématiquement les chemins temporels ?
Réponse : L’analyse temporelle statique.
Exercice de consolidation
Analyser le circuit suivant lorsque a passe de 0 à 1. Déterminer les cycles delta nécessaires et expliquer la valeur affichée par le report.
| Énoncé | VHDL |
| signal a : std_logic := '0'; signal b : std_logic := '0'; signal c : std_logic := '0'; process(a) begin b <= not a; c <= b; report "b=" & std_logic'image(b) & ", c=" & std_logic'image(c); end process; |
| Correction synthétique | Analyse |
| -- Pendant l'activation déclenchée par a : -- b et c conservent leurs anciennes valeurs. -- b <= not a est planifié pour un delta suivant. -- c <= b utilise l'ancienne valeur de b. -- Le report affiche donc les anciennes valeurs. -- Une nouvelle activation nécessite que les signaux lus -- figurent dans la sensibilité, ou l'usage de process(all). |
Suite du cours — Transition vers la suite Après le modèle de simulation, le cours peut aborder les règles de VHDL synthétisable, l’inférence matérielle, les latches, l’optimisation et la lecture des rapports de synthèse. |