Cours #8 Flot de conception d’un circuit numérique

Cours #8 Flot de conception d’un circuit numérique

Plan pour aujourd’hui Rappels: sections 4.1-4.3
Simulation fonctionnelle d’un modèle VHDL: sections 4.4 et 7.3 Synthèse: section 4.5 Implémentation (4.6), métriques (4.7) et configuration (4.8) + Des parenthèses sur VHDL, des précisions sur les notes de cours, des trucs pour utiliser Active-HDL, et des exemples!

Décomposition architecturale Introduction et coûts
(notes, section 4.1) Décomposition architecturale Introduction et coûts La conception d’un système numérique doit se baser sur une bonne compréhension des requis et des spécifications. Le coût associé à un changement suit en général une relation exponentielle avec le temps. Il est avantageux de ne pas avoir à faire de changements tard dans le développement d’un produit. Étape où le changement est nécessaire Coût relatif Définition des requis et spécifications 1 Conception 10 Prototypage 100 Production 1000 Distribution 10000+

Décomposition architecturale Décomposition en modules
(notes, section 4.1) Décomposition architecturale Décomposition en modules La conception débute par une décomposition du système en ses modules principaux et par une description abstraite de leur comportement. Pour déterminer la bonne granularité des modules, on peut observer trois principes : La cohésion : chaque module ne devrait réaliser qu’une seule fonction ou des fonctions similaires; La taille : un module ne devrait pas être trop grand ni trop petit; tous les modules du système devraient être de tailles comparables; et Des interfaces claires : chaque module devrait avoir des interfaces claires avec les autres modules, ce qui permet de mieux gérer la complexité du système au complet.

Décomposition en modules: exemple
B. Kommadi, The Iphone after 2 weeks, Toolbox for IT, 2007/08/16. Consulté le 24 nov. 2008, tiré de

Décomposition architecturale Partitionnement
(notes, section 4.1) Décomposition architecturale Partitionnement Le partitionnement consiste à déterminer comment chaque module et sous-module sera implémenté: ‘en logiciel’ sur un processeur à usage général; ‘en matériel’ sur un processeur spécialisé. La décision de placer un module d’un côté ou de l’autre est difficile et nécessite de faire des compromis en termes de précision des calculs, puissance consommée, taille du système et taux de traitement.

Décomposition architecturale Modélisation à haut niveau
(notes, section 4.1) Décomposition architecturale Modélisation à haut niveau Il est utile de modéliser le comportement d’un module à un niveau élevé avant d’en entreprendre une description détaillée. On peut utiliser: un langage comme C ou Python; un environnement complet comme Matlab; un outil spécialisé. À cette étape, il est utile de garder en tête des principes d’implémentation matérielle comme la façon de représenter des nombres. Le modèle peut déjà inclure ces considérations lors de l’analyse de performance. C’est aussi à l’étape de modélisation qu’on développe un banc d’essai et des cas de test contenant des stimuli et des réponses attendues en vue de la vérification. Le fait de développer un modèle et son banc d’essai confirme que les spécifications du design sont suffisamment claires et bien comprises pour mener à bien le développement du module.

Flot de conception de circuits numériques
(notes, section 4.2) Flot de conception de circuits numériques

Description de circuits numériques
(notes, section 4.3) Description de circuits numériques La description du module peut se faire par une combinaison de code HDL dans plusieurs langages, de schémas, diagrammes d’états ou encore flots de données. Source: Maxfield, © Mentor Graphics, 2004

Simulation fonctionnelle d’un modèle VHDL Introduction
(notes, section 4.4) Simulation fonctionnelle d’un modèle VHDL Introduction La simulation du code HDL permet au concepteur de vérifier que la description est conforme aux spécifications. Un simulateur travaille avec la description intermédiaire produite par un compilateur à partir de code HDL. Le simulateur nécessite qu’on force la valeur de certains signaux (habituellement les ports d’entrée du circuit à simuler), par le biais d’un banc d’essai ou d’outils de simulation. Du point de vue du simulateur, le banc d’essai et le modèle à simuler sont fusionnés. Le simulateur évalue comment les signaux forcés se propagent dans le circuit et il calcule la valeur de tous les signaux qui en dépendent. Le simulateur présente les résultats de la simulation via: un chronogramme; un tableau; des messages à la console; un fichier.

Simulation fonctionnelle d’un modèle VHDL Problème fondamental
(notes, section 4.4) Simulation fonctionnelle d’un modèle VHDL Problème fondamental VHDL permet de décrire des circuits numériques, où plusieurs événements peuvent se produire simultanément. La simulation est faite sur une station de travail dotée d’un microprocesseur qui traite l’information de façon séquentielle. Le problème fondamental de la simulation de code VHDL sur une station de travail consiste à simuler la concurrence d’événements sur une machine séquentielle. 1 3 Tâche 1 Tâche 2 Tâche 3 Tâche 4 …. 4 2 Comment simuler ceci avec cela?

Simulation d’un modèle avec son banc d’essai Exemple
(notes, sections 4.4 et 7.3) Simulation d’un modèle avec son banc d’essai Exemple library ieee; use ieee.std_logic_1164.all; entity demodelaidelta is port( A : in STD_LOGIC; B : in STD_LOGIC; F : out STD_LOGIC ); end demodelaidelta; architecture flot of demodelaidelta is signal S1, S2, S3, S4 : STD_LOGIC; begin S3 <= not(B and S1); S4 <= not(S2 and A); F <= not(S4 and S3); S1 <= not(A); S2 <= not(B); end flot; signaux forcés library ieee; use ieee.std_logic_1164.all; entity demodelaidelta_tb is end demodelaidelta_tb; architecture TB_ARCHITECTURE of demodelaidelta_tb is signal A, B, F : STD_LOGIC; begin UUT : entity demodelaidelta(flot) port map (A, B, F); A <= '0' after 0 ns; B <= '1' after 0 ns, '0' after 10 ns; end TB_ARCHITECTURE; À t = 10 ns, un changement sur l’entrée B entraîne des changements simultanés sur les signaux S2 et S3, puis sur la sortie F. Comment simuler cette concurrence d’événements?

Simulation d’un modèle VHDL Listes d’événements et de dépendances
(notes, section 7.3) Simulation d’un modèle VHDL Listes d’événements et de dépendances Un simulateur de modèle VHDL doit simuler l’opération d’événements concurrents et leur assigner des « moments » où ils se produisent. Le fonctionnement du simulateur repose sur trois concepts fondamentaux : une liste d’événements; une liste des dépendances des signaux; et, le concept des délais delta. Le simulateur maintient en tout temps une liste d’événements à simuler. Un événement est un changement de valeur à apporter à un signal, comme le faire passer de ‘1’ à ‘0’. La liste des dépendances des signaux indique au simulateur, pour chaque signal, la liste des signaux dont il dépend. Cette dépendance est indiquée explicitement ou implicitement dans le code par la liste de sensitivité des processus. Lorsqu’un événement se produit sur un signal, le simulateur ajoute l’évaluation des signaux qui dépendent de ce signal à la liste des événements à simuler. F <= not(A and (B xor not(C))); process (A, B, C) begin end process;

Simulation d’un modèle VHDL Le concept de délai delta ()
(notes, section 7.3) Simulation d’un modèle VHDL Le concept de délai delta () Le délai delta ( ) est un mécanisme abstrait pour permettre la simulation d’événements concurrents par un procédé séquentiel. Le simulateur peut traiter plusieurs événements simultanés un à la fois grâce aux délais delta. Un délai delta est un temps infinitésimalement court nécessaire à l’évaluation d’un événement. Certaines assignations de signaux peuvent avoir lieu à des temps précis, par exemple en utilisant la clause after. Il est possible que plus d’un signal change de valeur à un moment donné. Il est possible que plusieurs événements soient simulés tour à tour en plusieurs délais delta consécutifs avant que la valeur de tous les signaux ne se stabilise. Du point de vue du temps de simulation, la somme de tous ces délais delta reste nulle.

(notes, section 7.3) Simulation d’un modèle Exemple - détails de la simulation avec délais deltas À t = , initialisation de la simulation (tout à ‘U’) À t = , assignation de 01 à AB À t = , S1, S2 et S4* prennent leur valeur À t = , S3 prend sa valeur À t = , F prend sa valeur À t = 10 ns + 0 , assignation de 0 à B À t = 10 ns + 1 , S2 et S3* prennent leurs nouvelles valeurs À t = 10 ns + 2 , F prend sa nouvelle valeur * À ces moments, le simulateur a assez d’information pour calculer la valeur du signal parce qu’un ‘0’ à l’entrée d’une porte NON-ET implique automatiquement un ‘1’ à sa sortie

n ×  = 0 unités de temps: exemple avec « collapse deltas »
(notes, section 7.3) n ×  = 0 unités de temps: exemple avec « collapse deltas » Démonstration avec Active-HDL.

Simulation d’un modèle VHDL Déroulement global de la simulation
(notes, section 7.3) Simulation d’un modèle VHDL Déroulement global de la simulation Au temps 0, le simulateur place, sur la liste des événements: les processus; les assignations concurrentes; et, les instanciations de composantes. Un des événements est choisi et est exécuté. L’exécution de cet événement peut engendrer de nouveaux événements qui sont placés sur la liste des événements, au temps 0 +  ou plus tard, tel que spécifié par une clause after. Les autres événements du temps 0 sont exécutés à leur tour, et d’autres événements sont ajoutés à la liste des événements au temps 0 +  ou plus tard. Quand tous les événements du temps 0 ont été exécutés, le temps de simulation est avancé au temps 0 + , et le processus recommence. Le cycle se répète tant que la liste des événements contient encore des événements à traiter à un temps 0 + n. Ensuite, le temps de simulation est avancé selon le moment du prochain événement dans la liste des événements. Le cycle se répète tant que la liste des événements n’est pas vide.

Simulation d’un modèle VHDL Un autre exemple
(notes, section 7.3) Simulation d’un modèle VHDL Un autre exemple library IEEE; use IEEE.STD_LOGIC_1164.ALL; entity add3bits is port ( Cin : in std_logic; X : in std_logic; Y : in std_logic; Cout : out std_logic; S : out std_logic ); end add3bits; architecture flotdonnees2 of add3bits is signal T1 : std_logic; signal T2 : std_logic; signal T3 : std_logic; begin S <= T1 xor Cin; Cout <= T3 or T2; T1 <= X xor Y; T2 <= X and Y; T3 <= Cin and T1; end flotdonnees2; library IEEE; use IEEE.STD_LOGIC_1164.all; entity add3bitsTBsimple is end add3bitsTBsimple; architecture arch1 of add3bitsTBsimple is signal Cin, X, Y, Cout, S : std_logic; begin UUT : entity add3bits(flotdonnees2) port map (Cin, X, Y, Cout, S); Cin <= '0' after 0 ns; X <= '0' after 0 ns, '1' after 10 ns; Y <= '0' after 0 ns; end arch1; Liste (tableau) des dépendances des signaux Signal Dépend de S T1 , Cin Cout T3, T2 T1 X, Y T2 T3 Cin, T1 Donner la liste des événements. Montrer l’évolution de la simulation dans le temps.

Simulation d’un modèle VHDL Un autre exemple
(notes, section 7.3) Simulation d’un modèle VHDL Un autre exemple Liste des événements À t = , initialisation de la simulation (tout à ‘U’) À t = , assignation de 000 à X, Y, Cin À t = , évaluation des signaux T1, T2, T3 et S (provoquées par les changements sur X, Y, Cin) À t = , évaluation de T3, S et Cout (provoquées par les changements sur T1, T2, T3) Aucun nouvel événement n’est ajouté à la liste d’événements. À t = 10 ns + 0 , assignation de 1 à X À t = 10 ns + 1 , évaluation de T1 et T2 (provoquées par le changement sur X) À t = 10 ns + 2 , évaluation de T3 et de S (provoquées par le changement sur T1) Signal Dépend de S T1 , Cin Cout T3, T2 T1 X, Y T2 T3 Cin, T1

(notes, section 7.3) Assignations à des objets des catégories signal et variable dans un processus À l’intérieur d’un processus, les énoncés sont exécutés de façon séquentielle. Les assignations à des objets des catégories variable et signal sont traitées différemment. Quand la cible est une variable, celle-ci prend immédiatement la valeur qui lui est assignée. Pour un signal, l’assignation est placée sur la liste des événements: au temps courant +  (clause implicite after 0 ns); ou, au moment spécifié par une clause after explicite. L’évaluation des énoncés du processus se poursuit ensuite. Les assignations de valeurs à des signals ne sont effectuées que lorsqu’elles sont tirées de la liste des événements: après la fin de l’exécution du processus; ou bien, pendant la suspension de l’exécution du processus par un énoncé wait. process (A, B, T1) begin T1 <= A and B; T2 <= not(T1); end process; process begin T1 <= A and B; T2 <= not(T1); wait on A, B, T1; end process; Équivalence

(notes, section 7.3) Valeur d’expressions contenant des objets des catégories signal et variable dans un processus Quand Variable Signal Au début de la première exécution du processus Valeur d’initialisation dans la déclaration, ou valeur par défaut correspondant au type. Au début des autres exécutions du processus Valeur à la fin de la dernière exécution Valeur assignée après la fin de la dernière exécution Pendant l’exécution d’un processus qui ne contient pas d’énoncé wait Dernière valeur assignée Valeur au lancement du processus Pendant l’exécution d’un processus qui contient un ou des énoncés wait Valeur au lancement du processus ou bien dernière valeur assignée juste avant l’énoncé wait qui précède l’expression

(notes, section 7.3) signals et variables dans un processus: exemple Donner un chronogramme pour v1, s1, s2, s3 et s4 entity demoprocessus is end demoprocessus; architecture arch of demoprocessus is signal s1 : integer := 100; signal s2, s3, s4 : integer := -100; begin process variable v1 : integer := 2; begin while (v1 >= 0) loop s2 <= v1 + 5; v1 := v1 - 1; s3 <= v1 + 5; s1 <= s1 + 1; s4 <= s3 + s2; wait for 5 ns; s3 <= s3 + v1; s4 <= s3; end loop; wait for 100 ns; end process; end arch; v1 s1 s2 s3 s4

signals et variables dans un processus: exemple
(notes, section 7.3) signals et variables dans un processus: exemple entity demoprocessus is end demoprocessus; architecture arch of demoprocessus is signal s1 : integer := 100; signal s2, s3, s4 : integer := -100; begin process variable v1 : integer := 2; begin while (v1 >= 0) loop s2 <= v1 + 5; v1 := v1 - 1; s3 <= v1 + 5; s1 <= s1 + 1; s4 <= s3 + s2; wait for 5 ns; s3 <= s3 + v1; s4 <= s3; end loop; wait for 100 ns; end process; end arch;

Parenthèse: Valeurs par défaut d’objets en VHDL
(pas dans les notes) Parenthèse: Valeurs par défaut d’objets en VHDL Lors de la simulation, un objet déclaré sans initialisation de valeur se voit assigner une valeur par défaut qui dépend de son type. La valeur par défaut correspond à la borne gauche du type (type T, valeur T’left). La borne gauche dépend de la déclaration du type. Exemples: Type Valeur par défaut boolean FALSE natural positive 1 integer typiquement -231 std_logic ‘U’ std_logic_vector « UUU….U »

Et si la simulation n’avance que par des deltas?
(notes, section 7.3) Et si la simulation n’avance que par des deltas? Il est possible, lors de la simulation d’un modèle, que la valeur de certains de ses signaux ne se stabilise pas. Par exemple, un circuit peut inclure un chemin de rétroaction qui le fait entrer en oscillation. Le temps de simulation n’avance alors qu’en deltas. Un simulateur doit pouvoir détecter cet état de chose, s’arrêter lui-même et afficher un message d’erreur. Problème si C a une valeur initiale de 1 puis passe à 0 (en supposant que la porte NON-OU n’a pas de délai).

Parenthèse: Des détails, des détails … et des mises en garde
(pas dans les notes) Parenthèse: Des détails, des détails … et des mises en garde Il y a plusieurs façons de décrire un comportement donné en VHDL. On peut remplacer la liste de sensitivité d’un processus par un énoncé wait. (avec trois variations: wait for, wait until, wait on). On peut avoir une liste de sensitivité non complète (qui n’inclut pas tous les signaux qui font partie d’expressions dans le processus). Ces approches ne sont pas recommandées pour du code qui doit être synthétisé. process(A, B) begin T1 <= A and B; T2 <= not(T1); end process; process begin T1 <= A and B; wait for 0 ns; T2 <= not(T1); end process; process begin wait on A, B, T1; T1 <= A and B; T2 <= not(T1); end process; process (A, B, T1) begin T1 <= A and B; T2 <= not(T1); end process; process begin T1 <= A and B; T2 <= not(T1); wait on A, B, T1; end process; process begin wait until A = B; T1 <= A and B; T2 <= not(T1); end process;

(notes, section 4.5) Synthèse de code VHDL La synthèse du code VHDL est effectuée par un synthétiseur. Le processus de synthèse peut être décomposé et effectué en plusieurs passes. Ce processus est très complexe sauf pour les circuits les plus simples. Le produit du synthétiseur est communément appelé «liste des interconnexions» (netlist): les composantes de base et les liens qui les relient. Après le processus de synthèse, il est possible d’obtenir un estimé de la performance et des coûts du circuit.

Modélisation en VHDL pour la synthèse
(notes, section 4.5.2) Modélisation en VHDL pour la synthèse La synthèse d’un circuit numérique consiste à obtenir une description du circuit en termes de composantes et d’interconnexions à partir de sa spécification dans un langage de description matérielle. Le défi du synthétiseur est de réussir à modéliser le comportement sous-entendu par le code et d’inférer un circuit conforme à celui-ci. Le défi du concepteur de circuits numériques est de décrire ses intentions d’une façon non ambigüe pour le synthétiseur. Une approche qui fonctionne consiste à tout d’abord décomposer le circuit en blocs de base correspondant à des composantes logiques connues, puis à produire une description en fonction de ces blocs. La norme de l’IEEE définit le sous-ensemble de VHDL qui est (devrait être …) supporté par les outils de synthèse commerciaux. La documentation accompagnant le synthétiseur utilisé est pratique pour connaître exactement les parties du langage qui sont supportées ou non, les formulations préférées pour représenter une structure donnée, ainsi que les directives particulières supportées par le synthétiseur.

Exemples de code ambigu ou non synthétisable - 1
(notes, section 4.5.2) Exemples de code ambigu ou non synthétisable - 1 library ieee; use ieee.std_logic_1164.all; entity registremanque1 is port ( clk, D : in std_logic; Q : out std_logic ); end registremanque1; architecture arch of registremanque1 is begin process(clk) if (rising_edge(CLK) or falling_edge(CLK)) then Q <= D; end if; end process; end arch; entity boucledynamique is port ( x0, xmax : in integer range 0 to 255; somme : out integer range 0 to 65535 ); end boucledynamique; architecture arch of boucledynamique is begin process(x0, xmax) variable sommet : integer; sommet := 0; for k in x0 to xmax loop sommet := sommet + k; end loop; somme <= sommet; end process; end arch; Ne respecte pas les patrons pour la description de registres. Boucle à bornes indéfinies.

Exemples de code ambigu ou non synthétisable - 2
(notes, section 4.5.2) Exemples de code ambigu ou non synthétisable - 2 library ieee; use ieee.std_logic_1164.all; entity deuxsourcesetpire is port ( A, B, C, D, CLK : in std_logic; F : out std_logic ); end deuxsourcesetpire; architecture arch of deuxsourcesetpire is begin F <= CLK and (C or D); process(CLK) if (rising_edge(CLK)) then F <= A or B; end if; end process; end arch; library ieee; use ieee.std_logic_1164.all; entity registremanque is port ( clk, reset, enable, D : in std_logic; Q : out std_logic ); end registremanque; architecture arch of registremanque is begin process(clk, reset) if (rising_edge(CLK) and reset = '0' and enable = '1') then Q <= D; end if; end process; end arch; Deux sources pour le même signal. Utilisation du signal d’horloge dans une expression (synthétisable, mais …) Ne respecte pas les patrons pour la description de registres.

Parenthèse: la norme IEEE 1076.6-2004
(notes, section 4.5.2) Parenthèse: la norme IEEE IEEE Standard for VHDL Register Transfer Level (RTL) Synthesis “This document specifies a standard for use of VHDL to model synthesizable register-transfer level digital logic. A standard syntax and semantics for VHDL register-transfer level synthesis is defined. The subset of the VHDL language, which is synthesizable, is described, and nonsynthesizable VHDL constructs are identified that should be ignored or flagged as errors.”

Parenthèse: la documentation de XST
(notes, section 4.5.2) Parenthèse: la documentation de XST « The XST User Guide: Describes Xilinx® Synthesis Technology (XST) support for Hardware Description Language (HDL), Xilinx devices, and design constraints for the Xilinx ISE® Design Suite software Discusses FPGA and CPLD optimization and coding techniques when creating designs for use with XST » Le document fournit beaucoup d’exemples sur la façon de coder différents modules matériels. -- 4-bit Unsigned Up Accumulator with Asynchronous Reset -- library ieee; use ieee.std_logic_1164.all; use ieee.std_logic_unsigned.all; entity accumulators_1 is port(C, CLR : in std_logic; D : in std_logic_vector(3 downto 0); Q : out std_logic_vector(3 downto 0)); end accumulators_1; architecture archi of accumulators_1 is signal tmp: std_logic_vector(3 downto 0); begin process (C, CLR) if (CLR=’1’) then tmp <= "0000"; elsif (C’event and C=’1’) then tmp <= tmp + D; end if; end process; Q <= tmp; end archi;

Types utilisés pour la synthèse
(notes, section 4.5.3) Types utilisés pour la synthèse Les types std_logic ou std_logic_vector ne devraient être utilisés que pour des valeurs logiques. Pour représenter des nombres pour les ports d’une entité, les types préférés sont tirés du package numeric_std : unsigned pour une interprétation non signée signed pour une interprétation signée en complément à deux. Pour représenter des signaux internes d’un module, on a avantage à utiliser les types plus abstraits comme integer, character ou string, même s’il est plus difficile de retrouver ces signaux pour débogage dans les produits de la synthèse ou de l’implémentation. Pour les constantes et les paramètres d’un module, on peut en général utiliser tous les types abstraits supportés par VHDL, comme real, integer, ou string.

Parenthèse: Exemple de code utilisant les types character et string
(notes, section 4.5.3) Parenthèse: Exemple de code utilisant les types character et string library ieee; use ieee.std_logic_1164.all; use ieee.numeric_std.all; entity banderolev2 is Port ( reset, clk : in STD_LOGIC; charout : out unsigned(7 downto 0) ); end banderolev2; architecture arch of banderolev2 is constant message : string := "bonjour et bienvenue!"; begin process (clk, reset) variable index : integer range 1 to message'length; if (rising_edge(clk)) then if reset = '1' then index := 1; else charout <= to_unsigned(character'pos(message(index)), 8); if index = message'length then index := index + 1; end if; end process; end arch; ========================================================================= Advanced HDL Synthesis Report Macro Statistics # ROMs : 1 21x8-bit ROM : 1 # Counters : 1 5-bit up counter : 1 # Registers : 8 Flip-Flops : 8 * Low Level Synthesis * WARNING:Xst: FF/Latch <charout_7> (without init value) has a constant value of 0 in block <banderolev2>. This FF/Latch will be trimmed during the optimization process. Optimizing unit <banderolev2> ... Mapping all equations... Building and optimizing final netlist ... Found area constraint ratio of 100 (+ 5) on block banderolev2, actual ratio is 0. Final Macro Processing ... Final Register Report # Registers : 12 Flip-Flops : 12

Fils modélisés par les catégories signal et variable
(notes, section 4.5.4) Fils modélisés par les catégories signal et variable En général, l’utilisation de la catégorie signal résulte en un fil concret dans un module. C’est moins souvent le cas pour la catégorie variable, à cause du traitement différent de ces deux catégories. library ieee; use IEEE.STD_LOGIC_1164.ALL; entity demoSignalVariable is port ( A, B, C, D: in std_logic; F1, F2 : out std_logic ); end demoSignalVariable; architecture demo of demoSignalVariable is signal S1, S2 : std_logic; begin S1 <= A and B; S2 <= S1 or C; F1 <= S2 nand D; process(A, B, C, D) variable V : std_logic; V := A and B; V := V or C; V := V nand D; F2 <= V; end process; end demo;

Opérateurs synthétisables
(pas dans les notes) Opérateurs synthétisables La plupart des synthétiseurs peuvent synthétiser des circuits matériels qui réalisent les opérateurs suivants: logique: and, or, nand, nor, xor, xnor, not relation: =, /=, <, <=, >, >= concaténation: & arithmétique et décalage: +, - ,*, abs /, rem, mod et **, si l’opérande de droite est une constante égale à une puissance de 2 (parce que …) sll, srl, sla, sra, rol, ror Les opérateurs ne sont pas définis pour tous les types, il faut utiliser les librairies correspondantes. … parce qu’il n’y a pas (pour l’instant, en 2014), de modules matériels simples sur les FPGAs qui permettent d’effectuer ces opérations.

Synthèse: boucles et conditions
(notes, section 4.5.5) Synthèse: boucles et conditions À l’intérieur d’un processus, on peut utiliser des boucles et des conditions pour modéliser le comportement d’un circuit. Les boucles sont une manière compacte de représenter plusieurs énoncés reliés logiquement entre eux. Les paramètres d’exécution de la boucle doivent prendre des valeurs statiques au moment de la synthèse. Les boucles sont implémentées en les déroulant: les énoncés d’assignation qu’elles contiennent sont répliqués, un pour chaque itération de la boucle. Pour les circuits combinatoires, les conditions permettent d’effectuer un choix. L’énoncé case a l’avantage de représenter des choix qui sont mutuellement exclusifs et qui ont la même préséance. Il correspond assez exactement à l’action d’un multiplexeur. L’énoncé if, est plus général avec les clauses elsif ainsi qu’une clause else. Il est possible de l’utiliser pour donner préséance à certaines conditions par rapport à d’autres. Cela peut résulter en un circuit plus complexe que nécessaire, parce que le comportement décrit peut être plus restrictif que ce que le concepteur a en tête. Case est un meilleur choix quand on n’a pas besoin de priorité!

(notes, section 4.5.5) Exemple de code synthétisable utilisant des boucles et des conditions avec priorité library ieee; use ieee.std_logic_1164.all; use ieee.numeric_std.all; entity unsigned2dec is port( nombre : in unsigned(9 downto 0); centainesBCD, dizainesBCD, unitesBCD : out unsigned(3 downto 0); erreur : out std_logic ); end unsigned2dec; architecture arch of unsigned2dec is begin erreur <= '1' when nombre >= 1000 else '0'; process(nombre) variable n, c, d, u : natural := 0; n := to_integer(nombre); c := 0; for centaines in 9 downto 1 loop if n >= centaines * 100 then c := centaines; exit; end if; end loop; n := n - c * 100; d := 0; for dizaines in 9 downto 1 loop if n >= dizaines * 10 then d := dizaines; u := n - d * 10; centainesBCD <= to_unsigned(c, 4); dizainesBCD <= to_unsigned(d, 4); unitesBCD <= to_unsigned(u, 4); end process; end arch;

Inférence d’éléments à mémoire
(notes, section 4.5.6) Inférence d’éléments à mémoire Le processus de synthèse repose sur le principe de l’inférence de composantes matérielles à partir d’une description en code. Il est important de vérifier la documentation d’un outil de synthèse pour savoir quelle structure de langage utiliser pour obtenir le circuit désiré. À l’intérieur d’un processus, un élément à mémoire est inféré en VHDL si un objet des catégories signal ou variable se voit assigner une valeur dans un énoncé if-else, et que certains cas ne sont pas couverts. Les cas non couverts impliquent que l’objet doit conserver sa valeur, et donc un loquet est inféré. Il est donc très important de couvrir tous les cas possible avec une clause else ou when others, selon le cas, quand on ne désire pas qu’un loquet soit inféré.

Un loquet ou un multiplexeur ou les deux?
(notes, section 4.5.6) Un loquet ou un multiplexeur ou les deux? library ieee; use ieee.std_logic_1164.all; entity mystere1 is port (a, b, c: in std_logic; s : in std_logic_vector (1 downto 0); o : out std_logic); end mystere1; architecture archi of mystere1 is begin process (a, b, c, s) if (s = "00") then o <= a; elsif (s = "01") then o <= b; elsif (s = "10") then o <= c; end if; end process; end archi; library ieee; use ieee.std_logic_1164.all; entity mystere2 is port (a, b, c: in std_logic; s : in std_logic_vector (1 downto 0); o : out std_logic); end mystere2; architecture archi of mystere2 is begin process (a, b, c, s) if (s = "00") then o <= a; elsif (s = "01") then o <= b; elsif (s = "10") then o <= c; else o <= c; end if; end process; end archi;

Distinctions entre simulation et synthèse
(notes, section 4.5.7) Distinctions entre simulation et synthèse On remarque que la description du circuit en HDL peut être simulée et synthétisée. La simulation est normalement faite par un logiciel qui est exécuté sur un microprocesseur, alors que le but principal de la synthèse est d’obtenir un circuit matériel. La simulation sert à vérifier la description du système en différents points du flot. Il peut arriver qu’une étape du flot produise une description incorrecte, et la simulation permet de détecter cette erreur. Un circuit décrit en VHDL peut être parfaitement simulable et pas du tout synthétisable. Parfois, des erreurs dans la description du circuit ne sont découvertes que lors du processus de synthèse.

(pas dans les notes) Parenthèse: résultats différents pour la synthèse et la simulation: comment les éviter Attention à la liste de sensitivité l’absence d’un signal dans la liste de sensitivité est importante pour le simulateur le synthétiseur suppose (en général) que le concepteur a fait une erreur: “Declare asynchronous signals in the sensitivity list. Otherwise, XST issues a warning and adds them to the sensitivity list. In this case, the behavior of the synthesis result may be different from the initial specification.” – XST User Guide, v , Apr. 2009 Énoncés wait: pas tenus en compte par le synthétiseur Quoi faire? Surveiller les avertissements du synthétiseur … Pour les processus décrivant des bascules: placer seulement clk et reset dans la liste de sensitivité Pour les processus décrivant de la logique combinatoire: placer tous les signaux faisant partie d’expressions dans la liste de sensitivité process(CLK, A) begin if rising_edge(CLK) then Z <= A; end if; end process; process(A, B) begin T1 <= A and B; T2 <= not(T1); end process; process (A, B, T1) begin T1 <= A and B; T2 <= not(T1); end process;

Parenthèse: résultats différents pour la synthèse et la simulation
(pas dans les notes) Parenthèse: résultats différents pour la synthèse et la simulation signal U2t : std_logic; -- ... process (clk) begin if rising_edge(clk) then U2t <= U1; end if; U2 <= U2t; end process; variable U3t : std_logic; U3t := U1; U3 <= U3t; Pour le signal U2, lors de la simulation l’assignation de valeur se fait sur un front descendant d’horloge, ce qui ne correspond absolument pas au produit de la synthèse.

(pas dans les notes) Synthèse: mot de la fin Le synthétiseur respecte un contrat, p. ex. la norme IEEE Un synthétiseur prend deux entrées: la description du design (code HDL source et librairies); et, une description des ressources disponibles dans la technologie ciblée. Les concepteurs de synthétiseurs sont des gens prudents. Les synthétiseurs n’infèrent que des modules qui peuvent être décrits sans ambiguïté. le code HDL doit être non ambigu; le code HDL doit correspondre à une structure disponible sur la technologie ciblée, exemples de cas à considérer: registre avec reset synchrone/asynchrone? registre actif sur un ou deux fronts d’horloge? type d’additionneur? division, reste, autres fonctions (sinus, log, tanh, médiane, etc.)? Pour écrire du « bon code » synthétisable, il faut donc bien connaître: le contrat respecté par le synthétiseur utilisé; et, la technologie ciblée.

Implémentation Dans l’étape d’implémentation, on:
(notes, section 4.6) Implémentation Dans l’étape d’implémentation, on: découpe la liste des interconnexions en composantes disponibles sur le circuit intégré cible (association); on choisit des endroits spécifiques sur la puce pour chaque composante (placement); et, on relie les ports des composantes par des chemins (routage). L’association n’est faite en général qu’une seule fois. Les étapes de placement et routage peuvent être répétées tant que les contraintes de temps et/ou d’espace ne sont pas satisfaites.

(notes, section 4.6.1) Association (1) Un synthétiseur produit en général une description du circuit en termes de composantes de base. Les composantes de base incluent, entre autres : des fonctions logiques comme ET, OU, OUX; des multiplexeurs et décodeurs; des additionneurs, soustracteurs, accumulateurs, multiplicateurs; des bascules et loquets; et, d’autres composantes comme des blocs de mémoire, des générateurs d’horloge et des tampons. Le processus d’association (mapping) consiste à associer des composantes de base à des blocs ou des groupes de blocs logiques du FPGA. Par exemple, un groupe de portes logiques peut être combiné en une seule table de conversion d’un bloc logique.

(notes, section 4.6.1) Association (3) Le processus d’association est rendu plus complexe quand une fonction logique a plus d’entrées que les tables de conversion des blocs logiques. Il faut alors que l’outil d’association fasse un partitionnement et une distribution de ces fonctions Ce processus peut être très complexe parce qu’il n’y a pas nécessairement qu’une seule solution. L’outil doit alors se baser sur des contraintes d’optimisation imposées par l’utilisateur, comme une réduction de l’espace utilisé ou une réduction des délais de propagation.

(notes, section 4.6.2) Placement (1) Le processus de placement consiste à choisir un endroit spécifique sur le FPGA pour chacune des ressources nécessaires. Le processus de placement est très complexe. En pratique, on voudrait que des blocs qui communiquent entre eux soient disposés près les uns des autres. De cette façon, on simplifierait la tâche du routeur et on diminuerait les délais dus aux interconnexions. Cependant, dans le cas d’une composante avec des liens vers beaucoup d’autres, ce n’est pas possible. De plus, si on utilise une grande proportion des ressources du FPGA (> 80%), le placeur n’a pas beaucoup de marge de manœuvre. Les algorithmes de placement utilisent souvent des méthodes heuristiques comme le recuit simulé.

(notes, section 4.6.2) Placement (2): exemples de placement de cinq blocs sur une surface de 5 × 3

Placement (3): Les objectifs
(notes, section 4.6.2) Placement (3): Les objectifs Les objectifs généraux du placement sont: garantir qu’un routage existe; minimiser la longueur des chemins entre les composantes; minimiser la consommation de puissance (moins pour FPGA); et, minimiser le bruit entre les signaux (moins pour FPGA). Les métriques suivantes peuvent permettre de comparer deux solutions de placement: la longueur totale des interconnexions; le délai le plus long; et, la congestion des interconnexions.

(notes, section 4.6.2) Routage (1) Le processus de routage consiste à établir des connexions entre les ressources. Le processus de routage est aussi très complexe, et est souvent basé sur des méthodes heuristiques. Le problème vient du fait qu’il existe un nombre limité de ressources d’interconnexions entre les blocs logiques d’un FPGA. Il peut donc être impossible de router un circuit étant donné un placement. Dans un tel cas, le placeur doit effectuer un nouveau placement pour donner plus de flexibilité au routeur. Le routeur doit router trois types de connexions: les horloges et les signaux de réinitialisation; les connexions entre les blocs logiques; les connexions entre les blocs logiques et les blocs d’entrée/sortiel

Routage (2): Réseau hiérarchique d’interconnexions du XC2VP30
(notes, section 4.6.2) Routage (2): Réseau hiérarchique d’interconnexions du XC2VP30 Longues lignes: toute la puce Lignes ‘hex’: chaque 3e ou6e bloc Lignes ‘double: chaque 2e ou 4e bloc Lignes directes entre CLBs voisins Lignes rapides: internes aux CLBs Xilinx, Virtex-II Pro and Virtex-II Pro X Platform FPGAs: Complete Data Sheet, Nov

Routage (3) Les objectifs du routage sont:
(notes, section 4.6.2) Routage (3) Les objectifs du routage sont: effectuer toutes les connexions nécessaires; minimiser la longueur totale des interconnexions; et, minimiser la longueur du chemin le plus long. Dans un FPGA, les connexions sont bien caractérisées et les délais et les longueurs des chemins sont bien connus.

Métriques de performance et simulation du circuit implémenté
(notes, section 4.7) Métriques de performance et simulation du circuit implémenté Une fois l’implémentation terminée, on obtient: un fichier qui décrit toutes les interconnexions et la configuration des blocs logiques; une liste des interconnexions annotée des délais des composantes et du routage; Les FPGAs ont une structure très régulière et la précision des délais est grande. On peut donc simuler cette liste des interconnexions avec le même banc d’essai initial pour observer le comportement réel du circuit. Cette simulation prend en général un ordre de grandeur supplémentaire en temps à faire que la simulation de la description initiale du circuit, à cause du grand nombre de composantes et de fils dont le simulateur doit tenir compte. On obtient aussi un rapport détaillé sur les ressources utilisées sur le FPGA, ainsi qu’une description du chemin critique avec le délai sur celui-ci. Si les spécifications ne sont pas rencontrées, on peut alors retourner à l’une des étapes du flot de conception pour corriger les problèmes.

Configuration du FPGA (1)
(notes, section 4.8) Configuration du FPGA (1) La dernière étape consiste en général à programmer le dispositif devant supporter le circuit ou à faire dessiner les masques qui permettront de construire des transistors à partir de semi-conducteurs dopés et d’isolants ainsi que les connexions métalliques qui les relieront. L’action de programmer un FPGA consiste à configurer tous ses blocs logiques, ses blocs d’entrées et sorties et ses interconnexions. Afin de programmer efficacement un FPGA, on peut imaginer que toutes les cellules de programmation sont placées en série. Un signal spécial permet de les placer en mode de programmation, où chaque cellule passe son contenu à la prochaine cellule à chaque coup d’horloge. Ce système permet d’effectuer la programmation du dispositif avec très peu de pattes : une pour le signal de programmation, une pour placer les cellules en mode de programmation, une pour lire le flux de bits de programmation pour fins de vérification, et une horloge de programmation.

Configuration du FPGA (2)
(notes, section 4.8) Configuration du FPGA (2) source : fig. 5-3, Maxfield, © Mentor Graphics 2004

Résumé: flot de conception
Notions à retenir et maîtriser Importance relative Énoncer et décrire Les principes de décomposition d’un système en ses modules Le problème du partitionnement Les besoin de la modélisation à haut niveau Les options de description d’un circuit numérique: schéma, HDL, diagramme d’états 10 2. Expliquer comment fonctionne la simulation d’un modèle VHDL, en décrivant: le problème fondamental, la liste d’événements, les listes de dépendances et le concept de délai delta. Appliquer ces principes à une simulation d’un circuit simple. 35 3. Expliquer comment fonctionne le processus de synthèse. Montrer pourquoi un code VHDL est synthétisable ou non. Écrire du code synthétisable en exploitant correctement les types, opérateurs et structures de contrôle de VHDL. 25 4. Implémentation: décrire et expliquer les objectifs et défis des sous-étapes d’association, de placement et de routage 20 5. Expliquer comment les métriques de performance et de coût sont obtenues et utilisées. 5 6. Expliquer comment le fichier de configuration est obtenu et comment la configuration d’un FPGA est effectuée. Total 100

Cours #8 Flot de conception d’un circuit numérique

Présentations similaires

Présentation au sujet: "Cours #8 Flot de conception d’un circuit numérique"— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back

Entrer

S'autoriser via un réseau social:

Cours #8 Flot de conception d’un circuit numérique

Présentations similaires

Présentation au sujet: "Cours #8 Flot de conception d’un circuit numérique"— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back