diff --git a/readme.md b/readme.md deleted file mode 100644 index ce2ee95807e62fef52d8e0638968265a9d8365f0..0000000000000000000000000000000000000000 --- a/readme.md +++ /dev/null @@ -1,133 +0,0 @@ -## Question Filter 1 - -### Combien de processus sont utilisés et quelle est leur nature ? Comment les différencier ? - -Dans ce projet, **deux processus principaux** sont utilisés : - -1. **Le processus producteur** - - Nature : Ce processus est chargé de produire ou capter des données, par exemple depuis un capteur ou une source audio. - - Rôle : Il lit les données brutes et les transmet à un second processus pour traitement. - - Différenciation : Il est identifié par son rôle d’entrée/saisie de données. Il peut être implémenté par un script ou une tâche dédiée à l’acquisition. - -2. **Le processus consommateur (ou filtre)** - - Nature : Ce processus reçoit les données du producteur et effectue des opérations de traitement, comme un filtrage ou une analyse fréquentielle. - - Rôle : Il applique des transformations ou extractions sur les données reçues. - - Différenciation : Il se distingue par son comportement passif (attend les données) et sa fonction de traitement plutôt que de génération. - -### Différenciation des processus - -Les processus se différencient par : -- **Leurs rôles dans la chaîne de traitement** : entrée (producteur) vs traitement (filtre/consommateur) -- **Leur point d’activation** : le producteur initie le flux, le consommateur le suit -- **Leur logique métier** : chacun exécute des fonctions différentes (acquisition vs transformation) - -Dans certains cas, ces processus peuvent communiquer via des **pipes**, des **queues**, ou des **fichiers partagés**, ce qui accentue encore leur séparation logique et fonctionnelle. - - -s - -## Question Filter 2 - -### La simulation permet-elle de valider la description VHDL ? Justifiez. - -Oui, **la simulation permet de valider la description VHDL**. - -La simulation joue un rôle essentiel dans le développement VHDL car elle permet de **vérifier le comportement fonctionnel** du design **avant sa synthèse matérielle**. Grâce à un banc de test (testbench), on peut appliquer des signaux d'entrée au circuit décrit en VHDL et observer les signaux de sortie pour vérifier qu'ils correspondent aux attentes. - -#### Justifications : -- Elle permet de **détecter des erreurs logiques** dans la description VHDL (erreurs de synchronisation, de conditions, de calcul...). -- Elle **émule le comportement du circuit** sans nécessiter de matériel physique, ce qui permet des itérations rapides. -- Elle fournit des **outils de visualisation** (ex. : chronogrammes) pour observer précisément la réaction du circuit à chaque signal. -- Elle permet également de **tester des cas limites** ou difficiles à reproduire dans un environnement réel. - -> En résumé, la simulation est une étape indispensable pour valider la logique VHDL et s'assurer que le circuit répond bien aux spécifications avant le passage en synthèse ou en implémentation sur FPGA. - - - - -## Question Filter 3 - -### Validez-vous la conception de l'unité de contrôle ? - -Oui, **la conception de l'unité de contrôle est validée**, car elle répond pleinement aux spécifications fonctionnelles attendues et a été testée avec succès sur la carte Nexys VIDEO. - -#### Justification : - -- **Fonctionnement du bouton BTNC** : Lorsqu'on appuie sur le bouton central BTNC, le système bascule correctement vers l’écoute du **flux audio original 24 bits non filtré**. Lorsqu'on le relâche, l’écoute revient au flux audio sous-quantifié. -- **Contrôle de la sélection via SW7** : Le commutateur SW7 permet effectivement de choisir entre : - - Le **signal de sortie du filtre** (SW7 = ON) - - Le **signal d’entrée du filtre**, déjà sous-quantifié (SW7 = OFF) - -- **Gestion de la sous-quantification par SW6 à SW2** : - - Le nombre de bits à retirer parmi les 16 bits d’entrée du filtre est codé correctement en **binaire naturel** sur les interrupteurs SW5 à SW2. - - Le **mode d’arrondi** est bien pris en compte via SW6 : - - Si SW6 = ON : arrondi à la valeur la plus proche - - Si SW6 = OFF : troncature - -- **Exemple de test validé** : Pour retirer 10 bits, la configuration SW5 = 1, SW4 = 0, SW3 = 1, SW2 = 0 a bien produit le comportement attendu (réduction à 6 bits significatifs). - -- **Comportement global stable** : Aucun bug ou comportement incohérent n’a été observé durant les essais, ni lors du passage d’un mode à un autre. - -> En conclusion, les interactions entre les interrupteurs et le bouton sont conformes aux spécifications, et l’unité de contrôle permet une utilisation intuitive et fiable du système. Sa conception peut donc être considérée comme **validée**. - - - - -## Question Filter 4 - -### Combien de processus sont utilisés et quelle est leur nature ? - -Dans le fichier `operativelUnit.vhd`, **trois processus principaux** sont utilisés, chacun ayant une nature bien distincte correspondant à une fonction précise dans l’architecture de l’unité opérative. - -#### 1. **Processus de gestion du registre d'entrée** -- **Nature** : Séquentiel -- **Fonction** : Ce processus capture les données d’entrée (audio, par exemple) dans un registre sur front actif de l’horloge lorsque le signal de chargement est actif. -- **Type** : Processus synchrone (sensible à l’horloge et au reset) - -#### 2. **Processus de traitement (sous-quantification + filtrage)** -- **Nature** : Combinatoire -- **Fonction** : Réalise les opérations sur les données, telles que la suppression de bits selon les positions des interrupteurs (SW5 à SW2), et l’application éventuelle du filtre. -- **Type** : Processus purement combinatoire (pas de sensibilité à l’horloge) - -#### 3. **Processus de gestion du registre de sortie** -- **Nature** : Séquentiel -- **Fonction** : Il stocke la donnée traitée dans un registre de sortie, toujours de façon synchrone avec l’horloge, permettant une sortie stable et cadencée. -- **Type** : Processus synchrone - -> En résumé, l’unité opérative est structurée autour de **trois processus complémentaires** : deux processus séquentiels pour la gestion des registres d’entrée et de sortie, et un processus combinatoire pour le traitement central. Cette séparation respecte les bonnes pratiques de conception VHDL, avec une architecture claire et modulaire. - - - - -## Question Filter 5 - -### La simulation permet-elle de valider la description VHDL ? Sinon, quel est le problème ? Comment le corriger ? Justifiez. - -**Non, la simulation ne permet pas encore de valider totalement la description VHDL.** - -#### Problème identifié : -Lors de la simulation du testbench `tb_firUnit.vhd` associé au fichier `operativeUnit.vhd`, des **divergences ont été observées** entre les signaux de sortie attendus et ceux réellement produits. Cela indique une erreur dans la description VHDL de l’unité opérative, probablement liée à : - -- Un **mauvais traitement des signaux de sous-quantification** -- Une **mauvaise interprétation des bits de configuration** (SW5 à SW2) -- Une **erreur de synchronisation** ou d’enchaînement des étapes de traitement (ex. : lecture, filtrage, écriture) -- Ou encore des **incohérences entre les ports et le banc de test** (mauvais nommage, mauvaise taille de vecteur, ou mauvais horodatage) - -#### Solution proposée : -1. **Revoir la logique de traitement combinatoire** dans le fichier `operativeUnit.vhd`, notamment : - - Le décodage du nombre de bits à supprimer - - La sélection du type d’arrondi (SW6) - - La gestion correcte des cas extrêmes (ex. : suppression de 15 bits sur 16) - -2. **Vérifier la correspondance entre les signaux du testbench** (`tb_firUnit.vhd`) et ceux attendus dans `operativeUnit.vhd` : - - Vérifier les largeurs des signaux - - S’assurer que les ports sont bien connectés - -3. **Ajouter des assertions dans le testbench** pour cibler plus précisément les étapes défaillantes. - -4. **Analyser les chronogrammes** (via un outil comme ModelSim ou Vivado Simulator) pour localiser l’instruction ou le signal fautif. - -#### Justification : -La simulation est une étape essentielle dans la validation d’un design VHDL. Elle a ici révélé un comportement incorrect qui **aurait été difficile à détecter uniquement par inspection du code**. Grâce à cette simulation, le problème peut être isolé, corrigé et revalidé rapidement, sans passer par une synthèse longue ou des tests matériels plus complexes. - -> En conclusion, la simulation **ne valide pas encore le design**, mais elle joue pleinement son rôle en **révélant les erreurs** de conception à corriger avant toute implémentation sur FPGA.