Vériﬁcation fonctionnelle des systèmes numériques

Vérification fonctionnelle des systèmes numériquesIntroduction

Yann Thoma

Reconfigurable and Embedded Digital Systems InstituteHaute Ecole d’Ingénierie et de Gestion du Canton de Vaud

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License

Février 2017

Y. Thoma (HES-SO / HEIG-VD / REDS) Vérification fonctionnelle Février 2017 1 / 75

1 Introduction

2 Vérification formelle

3 Vérification par simulation

4 Vérification automatique

5 Bancs de tests

6 Vérification par émulation

7 Langages

Introduction

But de la vérification

Répondre à 2 questions

Est-ce que ça marche?Est-ce qu’on est sûr?Vraiment?Non, mais vraiment vraiment?Sans plaisanter?

Introduction

Est-ce que ça marche?

Est-ce qu’on est sûr?Vraiment?Non, mais vraiment vraiment?Sans plaisanter?

Introduction

Est-ce que ça marche?Est-ce qu’on est sûr?

Vraiment?Non, mais vraiment vraiment?Sans plaisanter?

Introduction

Est-ce que ça marche?Est-ce qu’on est sûr?Vraiment?

Non, mais vraiment vraiment?Sans plaisanter?

Introduction

Est-ce que ça marche?Est-ce qu’on est sûr?Vraiment?Non, mais vraiment vraiment?

Sans plaisanter?

Introduction

Est-ce que ça marche?Est-ce qu’on est sûr?Vraiment?Non, mais vraiment vraiment?Sans plaisanter?

Introduction

Vérification : oui, mais ...

On vérifie ...Quoi?Pourquoi?Quand?Comment?

Cette question sera centrale durant ce cours

Introduction

Première question: Quoi?

Circuits programmablesASICDans le cadre de ce cours, seulement des circuits digitauxLa vérification du logiciel est également importante

N’entre pas dans le cadre de ce coursOffre plus de flexibilité et d’observabilitéUn patch, c’est si facile...

Vraiment?

Introduction

Vérification du bon fonctionnement du systèmeQu’est-ce que cela signifie?Vérification de chaque module

Vérification exhaustive possible?

Un détecteur de flanc:

Vérification exhaustive: OK

Un additionneur 64-bits:

Vérification exhaustive: Non2128 = 3.4× 1038

combinaisons d’entrées...

Introduction

Vérification du bon fonctionnement du systèmeQu’est-ce que cela signifie?Vérification du système entier (System on Chip, par exemple)

Impossible de faire une vérification exhaustive⇒ Choix de cas intéressants⇒ Vérification aléatoire

http://www.xbitlabs.com/news/mobile/display/20080603141353_Nvidia_Unleashes_Tegra_System_on_Chip_for_Handheld_Devices.html

Introduction

Vérification du bon fonctionnement du systèmeQu’est-ce que cela signifie?Tendance actuelle: Power aware verification

SOCs ont plusieurs alimentationsCertains sous-systèmes peuvent être déconnectés ponctuellementA la frontière du digital et de l’analogique

http://www.techdesignforums.com/practice/technique/emulation-system-level-power-verification/

Introduction

Question: Pourquoi?

Dépannage d’un PLD programméTrès coûteuxVoire impossible

Dépannage d’un ASICTrès coûteux (en temps et argent)Refonte du circuit

Vérification indispensable pour valider le systèmeNécessite des outils performantsUne méthodologie rigoureuse

La vérification est le défi de la conception des systèmesnumériques

Introduction

Vérification: concept

Buts1 Vérifier la conformité du système avec le cahier des charges2 Détecter les erreurs au plus vite3 Assurer un fonctionnement correct après synthèse et intégration

Difficulté1 Maîtriser les coûts de la vérification

Environ 50-60% du temps ingénieur2 Garantir un fonctionnement correct

Introduction

Question: Quand?

Il semble évident d’essayer de détecter les erreurs le plus vitepossibleTests unitaires sur les modules au fur et à mesure de laconception/implémentationTests systèmes dès que possible

Nettement plus délicats à mettre en placeTemps de simulation importantsQuand? La nuit...

Pour un ASICLorsque le circuit est fondu, c’est trop tard...Tous les tests doivent être fait avantPrévoir la possibilité de tester après (cas d’un prototypenotamment)Concept intéressant: Design for Test

Le système embarque de la logique permettant de le tester durantson fonctionnementPermet de faire du diagnosticExemple: JTAG, BIST

Introduction

Conception/Vérification: décomposition

ValidationDesign

Sytème

Sous-sytèmes

Modules

Introduction

ValidationDesign

Sytème

Erreur Détection

Erreur

Sous-sytèmes

Modules

Introduction

ValidationDesign

Sytème

Modèle de

spécification

Sous-sytèmes

Modules

Introduction

Vérification: les 2 questions

Les deux grandes questions de la vérification

1 Est-ce que ça marche?Est-ce que le système fonctionne correctement?Les erreurs sont-elles correctement détectées?

Exemple de banc de test qui passe tous les tests

entity MonSuperDesign_tb isend MonSuperDesign_tb;

architecture MaSuperArchitecture of MonSuperDesign_tb isbegin

process isbegin

report "Everything is fine";end process;

end MaSuperArchitecture;

2 Est-ce qu’on est sûr? (a-t-on fini?)A-t-on réalisé assez de tests?Facile avec un petit design, très difficile avec un design complexe

Introduction

Les deux grandes questions de la vérification1 Est-ce que ça marche?

Est-ce que le système fonctionne correctement?Les erreurs sont-elles correctement détectées?

process isbegin

Introduction

Est-ce que le système fonctionne correctement?

Les erreurs sont-elles correctement détectées?

process isbegin

Introduction

process isbegin

Introduction

process isbegin

Introduction

process isbegin

2 Est-ce qu’on est sûr? (a-t-on fini?)

A-t-on réalisé assez de tests?Facile avec un petit design, très difficile avec un design complexe

Introduction

process isbegin

2 Est-ce qu’on est sûr? (a-t-on fini?)A-t-on réalisé assez de tests?

Facile avec un petit design, très difficile avec un design complexe

Introduction

process isbegin

Introduction

Vérification: évolution de la complexité

http://www.eetimes.com/electronics-blogs/other/4209669/FPGAs-advance–but-verification-challenges-increase

Introduction

Question: Comment?

Choix du langageVHDLSystemVerilogSystemC...

Choix de la méthodologieUVMVMMSpécifique...

Choix technologiqueVérification formelleVérification basée sur la simulationVérification par émulation...

Choix interactifManuelAutomatique

Introduction

Question: Comment?

Choix du langageVHDLSystemVerilogSystemC...

Choix de la méthodologieUVMVMMSpécifique...

Choix technologiqueVérification formelleVérification basée sur la simulationVérification par émulation...

Choix interactifManuelAutomatique

Introduction

Défis de la vérification: choix de méthode

Le choix d’une solution pour la vérification doit prendre en compteles paramètres suivants:

ComplétudeMaximiser les fonctionnalités (scénarios) de design testées

RéutilisabilitéMaximiser la réutilisabilité du code pour de futurs projets

EfficienceMinimiser l’effort à fournir et automatiser un maximum

ProductivitéMaximiser le travail produit manuellement

Performance du codeMinimiser le temps de calcul nécessaire à la vérification

Introduction

Vérification fonctionnelle: approches

Vérification formelleTentative de prouver mathématiquement le bon fonctionnement dusystème

Vérification basée sur la simulationTentative de prouver le bon fonctionnement du système en lesimulant

Vérification par émulationTentative de prouver le bon fonctionnement du système enl’émulant

Vérification formelle

Concept: Prouver mathématiquement que le design est correct!Se base sur la logique mathématique

Logique propositionnelleLogique des prédicats

Semblable à la preuve automatique de théorèmes

Exemples de propositions

A⇒ B est équivalent à A ou Bmodus ponens: Si A et A⇒ B, alors Bmodus ponens: peut s’écrire: (A et A⇒ B)⇒ Bcontrapositive de l’implication: (A⇒ B)⇔ (B ⇒ A)Tiers exclu: A ou A

Par la contrapositive de l’implication, la proposition "Tout ingénieurdocumente son code" est équivalente à "Tout code non documenté estécrit par un non-ingénieur"

Diagramme de Venn: A et B

Imaginez: A ≡ est un animal, et B ≡ est noir

B A et B

Diagramme de Venn: A ou B

Imaginez: A ≡ est un animal volant, et B ≡ est un animal qui nage

B A ou B

Diagramme de Venn: A⇒ B, A ou B

Imaginez: A ≡ est un corbeau, et B ≡ est noir

B A ou B

Implication

Exemple de A⇒ B est équivalent à A ou BJe suis étudiant de CSF⇒ J’ai suivi le cours BSLest équivalent àJe ne suis pas un étudiant de CSF OU j’ai suivi le cours BSL

Bizarre, non?Attention, en logique il s’agit d’un OU non exclusif, alors que dansle langage courant nous utilisons plutôt le OU exclusif

De Morgan: A + B = AB

Donc: A⇒ B est équivalent à ABJe suis étudiant de CSF⇒ J’ai suivi le cours BSLest équivalent àIl est impossible que je sois un étudiant de CSF et que je n’aie passuivi le cours BSL

Implication

Schémas de déduction élémentaires de la logiquepropositionnelle (1)

Γ représente une liste quelconque d’hypothèses⊥ représente une proposition fausse

Γ ;A ` A Vérité d’une hypothèse

Γ ` BΓ ;A ` B Vérité a fortiori

Γ ` A Γ ` BΓ ` A et B

Introduction de et

Γ ` A et BΓ ` A

Γ ` A et BΓ ` B Elimination de et

Γ ` A

Γ ` A ou B

Γ ` B

Γ ` A ou BIntroduction de ou

Γ ` A ou B Γ ;A ` C Γ ;B ` C

Γ ` CDisjonction des cas

Γ ;A ` B

Γ ` A⇒ BIntroduction de⇒

Γ ` A Γ ` A⇒ B

Γ ` BModus Ponens

Γ ` A Γ ` nonA

Γ ` ⊥Introduction de ⊥

Γ ` ⊥

Γ ` BEx falso quodlibet

Γ ;A ` ⊥

Γ ` nonARéduction à l’absurde J

Γ ;nonA ` ⊥

Γ ` ARéduction à l’absurde K

Γ ` A⇒ B Γ ` B ⇒ A

Γ ` A⇔ BIntroduction de⇔

Γ ` A⇔ B

Γ ` A⇒ B

Γ ` A⇔ B

Γ ` B ⇒ AElimination de⇔

Vérification formelle: Property checking

Un détecteur de flanc montant

entity Detector isport(

Clk_i : in std_logic;Input_i : in std_logic;Detection_o : out std_logic

);end Detector;

architecture behave of Detector issignal reg_s: std_logic;

beginprocess(clk_i)begin

if rising_edge(clk_i) thenreg_s<=Input_i;

end if;end process;

Detection_o<=Input_i and not(reg_s);end behave;

Propriété à vérifierSi A = 1 alors au cycle d’horloge suivant: D = 0

⇔ (At−1 = 1)⇒ Dt = 0⇔ At−1 ⇒ Dt⇔ At−1 + Dt = 1

Quel design est le bon?

Propriété à vérifierSi A = 1 alors au cycle d’horloge suivant: D = 0⇔ (At−1 = 1)⇒ Dt = 0

⇔ At−1 ⇒ Dt⇔ At−1 + Dt = 1

Propriété à vérifierSi A = 1 alors au cycle d’horloge suivant: D = 0⇔ (At−1 = 1)⇒ Dt = 0⇔ At−1 ⇒ Dt

⇔ At−1 + Dt = 1

Propriété à vérifierSi A = 1 alors au cycle d’horloge suivant: D = 0⇔ (At−1 = 1)⇒ Dt = 0⇔ At−1 ⇒ Dt⇔ At−1 + Dt = 1

Propriété à vérifier: At−1 + Dt = 1

Dt = At · At−1

At−1 + Dt = At−1 + At · At−1

= At−1 + At + At−1

Dt = At · At−1

At−1 + Dt = At−1 + At · At−1

= At−1 + At + At−1

= At−1 + At 6= 1

Propriété non vérifiée

Dt = At · At−1

At−1 + Dt =

At−1 + At · At−1

= At−1 + At + At−1

Dt = At · At−1

At−1 + Dt = At−1 + At · At−1

= At−1 + At + At−1

= At−1 + At 6= 1

Dt = At · At−1

At−1 + Dt = At−1 + At · At−1

= At−1 + At + At−1

Dt = At · At−1

At−1 + Dt = At−1 + At · At−1

= At−1 + At + At−1

= At−1 + At 6= 1

Dt = At · At−1

At−1 + Dt = At−1 + At · At−1

= At−1 + At + At−1

Dt = At · At−1

At−1 + Dt = At−1 + At · At−1

= At−1 + At + At−1

= At−1 + At 6= 1

Dt = At · At−1

At−1 + Dt = At−1 + At · At−1

= At−1 + At + At−1

Dt = At · At−1

At−1 + Dt = At−1 + At · At−1

= At−1 + At + At−1

= At−1 + At 6= 1

Dt = At · At−1

At−1 + Dt = At−1 + At · At−1

= At−1 + At + At−1

Dt = At · At−1

At−1 + Dt = At−1 + At · At−1

= At−1 + At + At−1

= At−1 + At 6= 1

Dt = At · At−1

At−1 + Dt = At−1 + At · At−1

= At−1 + At + At−1

Dt = At · At−1

At−1 + Dt = At−1 + At · At−1

= At−1 + At + At−1

= At−1 + At 6= 1

Dt = At · At−1

At−1 + Dt = At−1 + At · At−1

= At−1 + At + At−1

Dt = At · At−1

At−1 + Dt =

At−1 + At · At−1

= At−1 + At + At−1

= At−1 + At 6= 1

Dt = At · At−1

At−1 + Dt = At−1 + At · At−1

= At−1 + At + At−1

Dt = At · At−1

At−1 + Dt = At−1 + At · At−1

= At−1 + At + At−1

= At−1 + At 6= 1

Dt = At · At−1

At−1 + Dt = At−1 + At · At−1

= At−1 + At + At−1

Dt = At · At−1

At−1 + Dt = At−1 + At · At−1

= At−1 + At + At−1

= At−1 + At 6= 1

Dt = At · At−1

At−1 + Dt = At−1 + At · At−1

= At−1 + At + At−1

Dt = At · At−1

At−1 + Dt = At−1 + At · At−1

= At−1 + At + At−1

= At−1 + At 6= 1

Dt = At · At−1

At−1 + Dt = At−1 + At · At−1

= At−1 + At + At−1

Dt = At · At−1

At−1 + Dt = At−1 + At · At−1

= At−1 + At + At−1

= At−1 + At 6= 1

Propriété à vérifier

At−1 · At ⇒ Dt

2 Propriété suffisent

At−1 · At ⇒ Dt

Si on prouve ces deux propriétés, le système est formellementcorrect

Vérification formelle: Conclusion

L’outil QuestaFormal, de Mentor, offre des possibilités devérification formelle

Se base sur des assertionsEst capable de prouver le bon fonctionnementSinon offre le chronogramme menant à l’erreur

La preuve mathématique reste la meilleure des preuves, mais...Non applicable pour des systèmes trop complexesNécessite de spécifier le système avec des assertions

Nous aborderons les assertionsExploitées durant la simulationEt en preuve formelle!

Pour le plaisir: paradoxe de Hempel

contrapositive de l’implication: (A⇒ B)⇔ (B ⇒ A)Donc, pour prouver A⇒ B, il suffit de prouver B ⇒ APar la contrapositive de l’implication, la phrase "Tous les corbeauxsont noirs" est donc équivalente à "Tout ce qui n’est pas noir n’estpas un corbeau".Chaque fois que nous voyons un corbeau noir, cela confirme"Tous les corbeaux sont noirs".Donc:Chaque fois que nous voyons quelque chose qui n’est pas noir etn’est pas un corbeau, cela confirme que "Tous les corbeaux sontnoirs"...

Vérification par simulation

Vérification par simulation: approches

Plusieurs manières d’aborder la simulation:Bancs de test dirigés (Directed testbench)

Scénarios prévusPar exemple: tests exhaustifs (!)

Basé sur la couverture et l’aléatoire (Coverage-drivenrandom-based)

Génération de stimuli aléatoiresTest de couverture pour décider de la fin de la simulation

Vérification basée sur les assertions (assertion-based)Assertions peuvent servir à une preuve formelleOu sont vérifiées par simulation

Les outils (langages) sont plus ou moins adaptés à l’une ou l’autreapproche

Objectifs de la simulation

Vérifier le fonctionnement logique du module ou du systèmeVérifier les caractéristiques dynamiques du module ou dusystème (temps d’exécution, fréquence maximum, ...)Dans les deux cas, une preuve écrite du résultat de simulationdoit être générée

Méthodologie de vérification

Vérification exhaustiveProblème NP-durEn général: impossibilité de tester toutes les possibilités, pour unsystème combinatoirePour un système séquentiel: encore pire

Vérifications classiquesTest de la description (transparent)

Vérification de toutes les lignes de la description (taux de couverture)Test du fonctionnement (boîte noire)

Vérification du fonctionnement du système sans tenir compte de ladescription interneDevrait être réalisé par un autre ingénieur

Nouvelles approchesAssertions, coverage-driven, ...

Méthodologie de vérification

Il faut éviter qu’un banc de test ne détecte pas une erreur defonctionnement ou de description

Il est facile de réaliser un banc de test qui ne détecte pas d’erreur...Rigueur nécessaire pour la mise au point du banc de testAuto-test du banc de test

Le banc de test modifie volontairement les sorties du design

Validation de la simulation

En vérification dirigée, la validation est donnée par:La liste des stimuli générés et les vérifications exécutées (fichiertestbench)Et la preuve écrite du résultat des vérifications (fenêtre log dusimulateur, fichier texte, HTML, ...)

En vérification aléatoire, la validation est donnée par:La liste des scénarios testés et les vérifications exécutées (fichiertestbench)Le taux de couvertureEt la preuve écrite du résultat des vérifications (fenêtre log dusimulateur, fichier texte, HTML, ...)

Vérification des timings

La vérification des timings est compliquée avec une simulationVHDLUne meilleure méthodogie:Conception Full synchrone

Simulation fonctionnelleAnalyse statique des timings

⇒ Fonctionnement garantiAttention toutefois aux entrées/sorties

Vérification automatique

Manuelle vs. automatique

Vérification manuelleForcer à la main les signaux d’entréeGrands risques d’erreurDifficulté à réexécuter le même scénarioVérification visuelle par le développeur, par le chronogramme desimulationFastidieux (temps perdu)

Vérification semi-automatiqueLes signaux d’entrée sont forcés automatiquementVérification du fonctionnement par le développeurRisque de mauvaise analyse par le "vérificateur"

But: vérification la plus complète possible du systèmeRésultat Go/No Go (OK, KO)Indication de l’instant d’une erreurPossibilité de stopper la simulation sur une erreurIndication du nombre d’erreurs totalPermet une re-vérification complète (Go/no Go) après unemodification ou une correctionLes interactions utilisateur doivent être minimisées

Nécessaire pour garantir la similarité des tests effectués

Simulation automatique: scripts

Une simulation doit pouvoir être lancée via des scriptsEvite des erreurs de manipulationSimplifie la vie

Exemple: sim.do

# définition de la librairie de travailvlib work# compilation du design à testervcom counter.vhd# compilation du banc de testvcom counter_tb.vhd# lancement de la simulationvsim work.counter_tb# ajout de tous les signaux au chronogrammeadd wave -r *# exécution de la simulationrun -all

Bancs de tests

Fonctionnement d’un banc de tests

Assignation des entrées du circuit à testerDétermination des valeurs des sorties attendues (références)Attente d’un délai

Permet l’évaluation des sorties par le circuit (temps de propagation)Vérification des sorties

Comparaison avec la référenceIndication claire en cas d’erreur

Bancs de tests

Vérification black/white/gray box

But d’un design: que les sorties soient correctesCertaines erreurs du design pourraient être ignorées

Erreurs jamais activéesErreurs qui ne se propagent pas jusqu’à la sortieErreurs qui s’annulent l’une l’autre

Black boxLa fonctionnalité n’est vérifiée qu’aux frontières du designTypiquement comparées à un modèle de référence

Bancs de tests

Black box

Seules les sorties sont analyséesDifficulté à trouver les sources d’erreursNécessité d’avoir un modèle de référence

Banc de test

Description despécification

Description VHDL àtester (synthétisable)

Générateur

de stimuli_sti

Vérification

des sorties

Bancs de tests

Black box

Banc de test

Générateur

de stimuli_sti

Vérification

des sorties

Bancs de tests

Black box

Banc de test

Générateur

de stimuli_sti

Vérification

des sorties

Bancs de tests

Black box

Banc de test

Générateur

de stimuli_sti

Vérification

des sorties

Bancs de tests

Black box

Banc de test

Générateur

de stimuli_sti

Vérification

des sorties

Bancs de tests

Black box

Banc de test

Générateur

de stimuli_sti

Vérification

des sorties

Bancs de tests

Black box

Banc de test

Générateur

de stimuli_sti

Vérification

des sorties

Bancs de tests

White box

L’intérieur du design est analyséRecherche d’erreurs facilitéPeut être limité pour des grands systèmes

Banc de test

Générateur

de stimuli_sti

Vérification

des sorties

Monitoring etassertions

Bancs de tests

White box

Banc de test

Générateur

de stimuli_sti

Vérification

des sorties

Bancs de tests

White box

Banc de test

Générateur

de stimuli_sti

Vérification

des sorties

Bancs de tests

White box

Banc de test

Générateur

de stimuli_sti

Vérification

des sorties

Bancs de tests

White box

Banc de test

Générateur

de stimuli_sti

Vérification

des sorties

Bancs de tests

White box

Banc de test

Générateur

de stimuli_sti

Vérification

des sorties

Bancs de tests

Grey box

Les sorties et l’intérieur du design sont analyséesCompromis entre les deux autres approchesPermet de limiter la vérification des sorties par l’analyse interne

Banc de test

Générateur

de stimuli_sti

Vérification

des sorties

Bancs de tests

Grey box

Banc de test

Générateur

de stimuli_sti

Vérification

des sorties

Bancs de tests

Grey box

Banc de test

Générateur

de stimuli_sti

Vérification

des sorties

Bancs de tests

Grey box

Banc de test

Générateur

de stimuli_sti

Vérification

des sorties

Bancs de tests

Grey box

Banc de test

Générateur

de stimuli_sti

Vérification

des sorties

Bancs de tests

Grey box

Banc de test

Générateur

de stimuli_sti

Vérification

des sorties

Bancs de tests

Grey box

Banc de test

Générateur

de stimuli_sti

Vérification

des sorties

Bancs de tests

Grey box

Banc de test

Générateur

de stimuli_sti

Vérification

des sorties

Bancs de tests

White/grey/black box: Effort

Challenge Black White Grey

Création d’un modèle de référence Haut Non Moyen

Ajout de moniteurs et assertions Non Haut Bas

Tracer un bug de la sortie à la source Haut Bas Bas

Vérifier l’implémentation des features Haut Bas Bas

Vérification par émulation

Constat: La simulation nécessite beaucoup de temps processeurSolution: Exploiter les FPGAs pour accélérer le processusDifficultés:

Temps de synthèse-placement-routageObservabilité (nombre d’entrées/sorties)Gestion des assertionsSe prête plutôt à des modèles black box

Solutions commerciales:Veloce, de MentorZeBu, de EvePalladium series, de Cadence

Langages

Langages pour la vérification

Projets de petite et moyenne tailleLangage VHDL Nouveauté: UVVM

Projets de taille moyenne à élevéeBesoin de

Modèles décrits à très haut niveau (transaction)Génération de stimuli aléatoiresVérification par assertions

Solutions actuellesSystemCPSL (assertions)

Nouveau langageSystemVerilog

Langages

Origine des langagesOrigin of the Species

HiLo Verilog

25 years25 years

HiLo Verilog

SuperLog

SystemVerilog

1980 1990 2000 2005

Functional Verification of Today’s and Tomorrow’s SoCs, Janick Bergeron, Synopsys, 2011

Langages

Origine des méthodologiesOrigin of the Species

AVMOVM UVMSV

8 years8 yearsTLM 1.0 TLM 2.0SC

8 years8 years

VMM 1.0 VMM 1.2

2002 2004 2006 2008 2010

Functional Verification of Today’s and Tomorrow’s SoCs, Janick Bergeron, Synopsys, 2011

Langages Evolution des usages

Etude sur l’évolution des usages

Publiée par MentorComparaison entre 2012 et 2016Designs FPGA et non-FPGA (ASIC)

https://blogs.mentor.com/verificationhorizons/blog/2016/08/08/prologue-the-2016-wilson-research-group-functional-verification-study/

SystemVerilog vs. VHDL

Source: http://www.design-reuse.com/articles/7844/

verification-ip-verification-ip--part-2-by-dr-aart-de-geus.html

SystemVerilog

Ce qu’il faut savoir de SystemVerilog pour la vérificationLangage orienté objetNotion de classe (monde logiciel)

HéritageCréation dynamique d’objets

Notion de module (monde matériel)Hiérarchie de composantsCréation statique

Notion d’interface (entre-deux mondes)Facilite la mise au point de bancs de tests

SystemVerilog

Langage orienté objetRéutilisation

Génération aléatoireNon contrainteContrainte

Gestion des assertionsFonctions de couvertureIdéal pour de la vérification aléatoireDes méthodologies ont été développées

Méthodologies SystemVerilog

Cadence: VMM (Verification Methodology Manual)Version 1.2http://www.vmmcentral.org/

Mentor: AVM (Advanced Verification Methodology)Version 3.0Terminé

Ensemble: OVM (Open Verification Methodology)Version 2.1http://www.ovmworld.org/

UVM (Universal Verification Methodology)Unification de VMM et OVMVersion 1.1http://www.uvmworld.org/Sera présentée durant le cours

Niveaux d’abstractions

Evolution des niveaux d’abstractions

Réutilisation: bibliothèque de VIPs

Méthodologie: UVM

Langage pour la vérif: SystemVerilog

Langages RTL: VHDL/Verilog

Méthodologie: UVM

Méthodologie TLM

Pour des systèmes complexes, la méthodologie Transaction LevelModeling permet:

Une meilleure modularitéUne meilleure réutilisabilitéDe découpler le niveau RTL d’autres niveaux d’abstraction

Concept:Monter en abstraction dès que possibleArriver dans le monde logiciel

SystemVerilog est fait pourVHDL s’en approche avec UVVML’avenir de la vérification est TLM

Vériﬁcation fonctionnelle des systèmes numériques

Documents

30/10/2012 Analyse fonctionnelle - Page perso M …michel.pendaries.pagesperso-orange.fr/ANALYSE FONCTIONNELLE.… · Analyse fonctionnelle Fondements ... • Exemple du tabouret

Cov Technologie Fonctionnelle Front...Technologie foncTionnelle – favoriser la réussiTe scolaire remerciemenTs Remerciements Le document Technologie fonctionnelle – Favoriser

Programmation Fonctionnelle

Cours d'Analyse Fonctionnelle

Programmation fonctionnelle - Boisvert · Programmation fonctionnelle Programmation fonctionnelle et création d'un langage orienté objet Sébastien Boisvert Http://boisvert.info

NEURO-ANATOMIE FONCTIONNELLE Professeur Outrequinsouliman1.free.fr/Cours - CES/Neuro-anatomie fonctionnelle (Pr Outrequin).pdf · 1 NEURO-ANATOMIE FONCTIONNELLE Professeur Outrequin

Analyse Fonctionnelle Bilan

Vériﬁcation des Systèmes Réactifs Temps-Réeljouannaud/articles/cours-verification.pdf · École Polytechnique Majeure 2 Spécialité Informatique Vériﬁcation des Systèmes

1 Analyse Fonctionnelle

++++ORTHESE fonctionnelle

Imagerie fonctionnelle cérébrale2

Bilan fonctionnelle

ANATOMIE FONCTIONNELLE

Extrait de la publication… · tielles, analyse fonctionnelle, théorie de l’approximation, méthodes numériques et applications des mathématiques à la mécanique et à la physique

Chaîne fonctionnelle

DOCUMENTATION FONCTIONNELLE

Intégration de techniques coopératives pour la vériﬁcation

Analyse fonctionnelle

Manuel sur les freins pneumatiques - lnevr.comlnevr.com/nv/data/pdf/manuel_freins.pdf · Table des matières Suite 4 Chapitre 9 9. Vériﬁcation et réglage des freins 33 9.1 Vériﬁcation

ORGANISATION FONCTIONNELLE