460 likes | 576 Views
Descrieri structurale. Configuratii. Capitolul 5. Cuprins. 5.1. Descrieri structurale 5.2. Parametri generici 5.3. Configuratii. 5.1. Descrieri structurale. Descriere structurala = atunci cind o arhitectura este modelata sub forma unui set de componente legate prin semnale.
E N D
Descrieri structurale. Configuratii Capitolul 5
Cuprins • 5.1. Descrieri structurale • 5.2. Parametri generici • 5.3. Configuratii
5.1. Descrieri structurale • Descriere structurala = atunci cind o arhitectura este modelata sub forma unui set de componente legate prin semnale. • Comportarea arhitecturii nu rezulta in mod explicit din descrierea ei structurala • Instructiunea de baza: • instructiunea de instantiere de componente (component instantiation statement) • Este o instructiune concurenta • In partea de declaratii a arhitecturii apar declaratiile de componente
Declaratia de componente component_declaration::= COMPONENT component_name [IS] [GENERIC(list_of_generics);] [PORT(list_of_ports);] END COMPONENT [component_name];
Declaratiile de componente • Numele de componenta din declaratia de componenta poate fi acelasi sau diferit de numele entitatii care ii este asociata componentei. • Daca este diferit atunci arhitectura se poate compila, dar nu se poate simula (decit daca exista si o configuratie). • Porturile au nume, tip si mod (directie) • Declaratiile de componente pot aparea si in PACKAGE DECLARATION • Daca package-ul e vizibil in arhitectura atunci nu mai trebuie declarata componenta in arhitectura
Instructiunea de instantiere de componente component_instantiation_statement ::= label: component_name [GENERIC MAP (generic_association_list)] [PORT MAP(port_association_list)] ;
Instantierea de componente • Instructiunea de instantiere de componenta are obligatoriu eticheta: • Eticheta poate fi orice identificator legal si este considerata numele instantierii de componenta • Numele componentei trebuie sa fie acelasi cu numele din declaratia de componenta • Clauza PORT MAP face asocierea intre porturile formale si cele actuale.
Porturi • Porturile formale sint cele din declaratia de componenta • Porturile actuale pot fi: • Porturi ale entitatii pe care o modelam • Semnale interne ale acesteia. • Pentru un port formal de intrare un port actual poate fi si o expresie. • Ca port actual se poate folosi si cuvintul cheie OPEN, adica portul respectiv e neconectat • Un port de intrare poate fi lasat OPEN doar daca la declararea sa se specifica o valoare initiala • Nu poate fi lasat neconectat un port care e unconstrained array • Orice alt port poate fi lasat neconectat.
Modurile porturilor • IN: portul poate fi doar citit, nu si scris • E implicit, adica, daca nu se precizeaza modul unui port, acesta va fi considerat IN • OUT: portul poate fi doar scris, nu si citit • INOUT: poate fi atit citit cit si scris • Poate avea mai multe drivere, caz in care trebuie sa fie semnal rezolvat. • BUFFER: poate fi atit citit cit si scris • Poate avea un singur driver • Unui port formal BUFFER i se poate asocia un port actual tot de mod buffer sau un semnal intern.
PORT MAP • Asocierile din clauza PORT MAP pot fi facute: • Pozitional • Dupa nume. • La asocierea pozitionala • Se specifica doar numele portului actual • Din pozitia pe care apare se stabileste carui port formal ii este asociat • Ordinea trebuie sa corespunda cu ordinea porturilor din declaratia de componenta.
PORT MAP • La asocierea dupa nume: • se specificanume_port_formal => port_actual • Nu conteaza ordinea in care sint scrise porturile • Fiecare port formal din asocierea dupa nume este vizibil doar in respectiva instructiune de instantiere de componenta. • Asocierea pozitionala poate genera erori greu de depanat ! • Reguli de asociere • 1. Trebuie sa coincida tipul portului formal si al celui actual • 2. Daca portul formal se poate citi atunci si portul actual trebuie sa se poata citi; daca portul formal poate fi scris, atunci si portul actual trebuie sa poata fi scris.
PORT MAP • Regulile de asociere sint valabile atit pt maparea pozitionala cit si pt maparea dupa nume. • Se considera ca un semnal intern poate fi atit citit cit si scris => acesta se poate asocia oricarui port formal daca tipurile lor corespund. • Consecinte ale regulilor: • Daca un port actual are modul OUT atunci el nu poate fi asociat unui port formal IN sau INOUT • Daca un port actual are modul IN atunci nu poate fi asociat unui port formal OUT sau INOUT. • Daca un port actual are modul INOUT el poate fi asociat unui port formal avind modul IN, OUT sau INOUT • Se pot face asocieri de porturi si pentru • vectori (de ex de biti): x(3 DOWNTO 1) => y, unde y este BIT_VECTOR(2 DOWNTO 0) • Sau bucati de vectori: a(4 downto 1) => b(5 downto 2);
PORT MAP (actualizat) • Conform editiei din 2002 a “1076 IEEE Standard VHDL Language Reference Manual”: • Pt un port formal de mod IN actualul poate avea modul IN, INOUT sau BUFFER • Pt un port formal de mod OUT actualul poate fi OUT, INOUT sau BUFFER • Pt un port formal de mod INOUT actualul poate fi INOUT sau BUFFER • Pt un port formal de mod BUFFER, actualul poate fi OUT, INOUT sau BUFFER
Exemplu: generatorul de paritate Fig 5 (dupa fig 2.3 din [EKP98]). Generatorul de paritate modificat V(3) s1 V(2) par s3 xor1 inv1 V(1) xor3 impar s2 V(0) xor2 Reluam exemplul cu generatorul de paritate descris structural, dar ii adaugam si o iesire pentru paritate impara, numita impar, care are valoarea ‘1’ atunci cind vectorul de intrare v contine un numar impar de biti de ‘1’). Se pune problema care este modul portului impar al entitatii parity_gen ? Nu poate fi nici IN, nici OUT, doar INOUT sau BUFFER. In acest caz e mai potrivit modul BUFFER deoarece nu vrem ca un semnal extern sa comande acest port, adica vrem ca semnalul impar sa aiba o singura sursa.
ENTITY circ_paritate IS PORT(v: IN BIT_VECTOR(3 DOWNTO 0); par: OUT BIT; impar: BUFFER BIT); END circ_paritate; ARCHITECTURE struct OF circ_paritate IS COMPONENT xor_gate IS GENERIC(del: TIME:=3ns); PORT(x1,x2: IN BIT; y: OUT BIT); END COMPONENT; COMPONENT inv_gate IS GENERIC(del: TIME:=4ns); PORT(x: IN BIT; y: OUT BIT); END COMPONENT; SIGNAL s1, s2, s3: BIT; BEGIN xor1: xor_gate PORT MAP(y => s1, x2=> v(2), x1=> v(3));-- mapare dupa nume xor2: xor_gate PORT MAP(v(1), v(0), s2); --mapare pozitionala xor3: xor_gate PORT MAP(x1=>s1, x2=>s2, y=>impar); --corect conform standardului, dar nu si pt VeriBest !! inv1: inv_gate PORT MAP(x=>impar, y=>par);
-- secventa care e acceptata de VeriBest: --xor3: xor_gate PORT MAP(x1=>s1, x2=>s2, y=>s3); --inv1: inv_gate PORT MAP(x=>s3, y=>par); --impar<=s3; END ARCHITECTURE struct; CONFIGURATION cfg_circ_paritate OF circ_paritate IS FOR struct FOR ALL: xor_gate USE ENTITY WORK.poarta_xor(behave); END FOR; FOR inv1: inv_gate USE ENTITY WORK.inversor(behave); END FOR; END FOR; END CONFIGURATION;
ENTITY test IS END; –- dupa [EKP98] ARCHITECTURE test OF test IS COMPONENT circ_paritate IS PORT(v: IN BIT_VECTOR(3 DOWNTO 0); par: BUFFER BIT; impar: OUT BIT); END COMPONENT; SIGNAL vector: BIT_VECTOR(3 DOWNTO 0); SIGNAL paritate_para, paritate_impara: BIT; BEGIN et: circ_paritate PORT MAP(vector, paritate_para, paritate_impara); vector <= "0000", "0001" AFTER 20ns, "0010" after 40ns,"0011" AFTER 60ns, "0100" after 80ns,"0101" after 100ns, "0110" after 120ns, "0111" after 140ns, "1000" after 160ns, "1001" after 180ns, "1010" after 200ns, "1011" after 220ns, "1100" after 240ns, "1101" after 260ns, "1110" after 280ns, "1111" after 300ns; END; CONFIGURATION cfg_test OF test IS FOR test FOR all: circ_paritate USE CONFIGURATION WORK.cfg_circ_paritate; END FOR; END FOR; END CONFIGURATION;
5.2.Parametri generici (Generics) • Sint folositi pt a transmite valori catre componente • Prin declararea unui parametru generic se creeaza • Un obiect din clasa constantelor • Avind modul IN (poate fi doar citit) • Este vizibil in toate arhitecturile entitatii • Valoarea unui generic poate fi specificata: • In declaratia de entitate • In declaratia de componente • in instructiunea de instantiere de componente • In configuratii • Fiecare caz le poate suprascrie pe cele de dinainte • Este o eroare daca un generic nu este initializat
Parametri generici • In instantierile de componente: • Specificarea valorii cu GENERIC MAP • Se poate face pozitional sau dupa nume • Parametrul generic actual va fi o valoare • Daca numele parametrului generic din declaratia de componenta difera de cel din declaratia de entitate atunci, pt a putea simula arhitectura, trebuie sa existe si o configuratie • In configuratie se va face asocierea (legarea - binding) intre cele doua nume ale param generici
Parametri generici • Rezulta ca in configuratii GENERIC MAP poate face doua lucruri: • Asocierea (binding) intre parametrul generic din declaratia de componenta si cel din declaratia de entitate • Maparea unei valori • In general parametrii generici sint folositi pt a specifica intirzieri, dar au si alte utilizari: • Se poate parametriza numarul de intrari al unei porti sau ale unui circuit • Se poate parametriza dimensiunea unui registru, a unei magistrale, a unui ALU, etc.
Exemplu: poarta cu N intrari ENTITY generic_or_gate IS GENERIC( del: TIME:=5ns; n: INTEGER:=2); PORT(x: IN BIT_VECTOR(n-1 DOWNTO 0); y : OUT BIT); END generic_or_gate; ARCHITECTURE behave OF generic_or_gate IS BEGIN PROCESS(x) VARIABLE: temp: BIT:=‘0’; BEGIN temp:=‘0’; FOR i IN n-1 DOWNTO 0 LOOP temp:=temp OR x(i); EXIT WHEN temp=‘1’; END LOOP; y<= temp AFTER del; END PROCESS; END ARCHITECTURE;
Exemplu de registru ENTITY registru IS GENERIC(n: NATURAL:=8); PORT( intrare_paralela: IN BIT_VECTOR(n-1 DOWNTO 0); iesire_paralela: OUT BIT_VECTOR(n-1 DOWNTO 0); reset, clock, comanda1, comanda2: IN BIT; intrare_seriala: IN BIT); END registru;
5.3. Configuratii • Au doua utilizari: • Fac legatura intre o entitate si una din arhitecturile sale (exemplul cu gen paritate) • Fac legatura intre componente si perechile entitate - arhitectura corespunzatoare • In descrieri structurale • E utilizarea tipica • Exista: • Configuration specification • Configuration declaration
Configuratii • Configuration specification • Asocierile se fac direct in arhitectura • Utila pentru proiecte mici (daca se fac modificari atunci trebuie recompilata arhitectura) • Configuration declaration • Este o unitate de proiectare separata • Avantaj: nu necesita recompilarea arhitecturii daca se fac modificari • O instantiere de componenta nu poate fi legata (asociata) atit in configuration specification cit si in configuration declaration, ci doar in una din acestea.
Configuratii • Exista doua stiluri de configuratii: • Cu perechi entitate-arhitectura • Se foloseste USE ENTITY WORK.entit(arhitect); • Stilul lower level configuration: • Se folosesc configuratii pt a lega componente de entitati; • In forma: USE CONFIGURATION WORK.nume_configuratie; • Diferenta intre cele doua stiluri apare daca arhitectura entitatii asociata componentei e descrisa structural
Configuratii: exemple Presupunem ca avem o poarta inversor numita inv, avind o intrare a si o iesire b, ambele de tip BIT, ca in figura urmatoare: a b Fig 6. Inversor inv Presupunem ca avem si o entitate test, fara porturi, care contine o componenta numita neg, ce va fi asociata entitatii inv, si doua semnale interne, s1 si s2, conectate ca in figura urmatoare: s1 s2 et test Fig 7. Entitatea test ce contine inversorul
Configuratii: exemple ENTITY inv IS GENERIC(tp: TIME :=5ns); PORT(a: IN BIT; b: OUT BIT); END ENTITY inv; ARCHITECTURE beh OF inv IS BEGIN b <= NOT a AFTER tp; END ARCHITECTURE beh; ARCHITECTURE alta OF inv IS BEGIN … END alta; CONFIGURATION inv_cfg OF inv IS FOR beh END FOR; END CONFIGURATION inv_cfg;
Configuration specification: exemplu ENTITY test IS END test; ARCHITECTURE netlist_config_spec OF test IS COMPONENT neg IS GENERIC (tp: TIME :=3ns); --GENERIC(tp1: TIME :=3ns); PORT(x: IN BIT; y : OUT BIT); END COMPONENT; SIGNAL s1, s2: BIT; FOR et:neg -- FOR ALL:neg -- FOR OTHERS:neg USE ENTITY WORK.inv(beh) --USE CONFIGURATION WORK.inv_cfg GENERIC MAP(tp =>7ns)-- GENERIC MAP(tp => tp1) PORT MAP(a=>x, b=>y); BEGIN et: neg GENERIC MAP(10ns) PORT MAP(s1,s2); END ARCHITECTURE;
Configuration specification Sintaxa: FOR list_of_component_labels: USE ENTITY entity_name[(architecture_body)] [GENERIC MAP(generic_association_list)] [PORT MAP(port_association_list)]; list_of_component_labels: - e lista etichetelor instructiunilor de instantiere de componenta - poate fi in forma: - et1, et2, et3: - ALL: - OTHERS: Instantieri diferite ale aceleiasi componente pot fi legate la entitati diferite. De asemenea limbajul permite legarea unor componente diferite de aceeasi entitate (daca nr si tipul porturilor permite) - pt depanare, dar e confuz !
Configuration specification • Se poate si: • USE WORK.ALL; -- inainte de entitate sau arhitectura cu config specification • USE ENTITY inv(beh) GENERIC MAP() PORT MAP(); • Asocierea parametrilor generici poate avea doua semnificatii: • Se suprascrie valoarea anterioara a parametrului generic • Se asociaza param generici din entitate cu cei din declaratia de componenta atunci cind au nume diferite (in exemplu, daca la COMPONENT neg am fi avut GENERIC (tp1: TIME: = 3ns) atunci in configuratie trebuia sa avem: • GENERIC MAP(tp => tp1) • PORT MAP: face legatura intre porturile din entitate si cele din declaratia de componenta, atunci cind au nume diferite • Portul formal e cel din entity declaration, iar cel actual e cel din declaratia de componenta (in PORT MAP avem (port_formal => port_actual) • Dezavantajul la configuration specification este ca atunci cind se fac schimbari (unei componente i se asociaza o alta entitate sau arhitectura) va trebui recompilata intreaga arhitectura. Acest dezavantaj e inlaturat de configuration declaration.
Configuration declaration: exemplu ARCHITECTURE netlist_config_decl OF test IS COMPONENT neg IS GENERIC (tp: TIME :=3ns); --GENERIC(tp1: TIME :=3ns); PORT(x: IN BIT; y : OUT BIT); END COMPONENT; SIGNAL s1, s2: BIT; BEGIN et: neg GENERIC MAP(10ns) PORT MAP(x=>s1,y=>s2); END ARCHITECTURE; USE WORK.ALL; CONFIGURATION cfg_test OF test IS FOR netlist_config_decl FOR et: neg USE ENTITY inv(beh) GENERIC MAP(tp=>5ns) PORT MAP(a=>x, b=>y); --FOR ALL: neg USE CONFIGURATION inv_cfg GENERIC --MAP(tp => tp1) PORT MAP(a=>x, b=>y); END FOR; END FOR; END CONFIGURATION;
Configuration declaration:sintaxa CONFIGURATION configuration_name OF entity_name IS block_configuration END [CONFIGURATION][configuration_name]; block_configuration::= FOR block_name component_configurations block_configurations END FOR; Unde block_name poate fi - numele unei architecture body (intotdeauna pt cel mai exterior bloc din configuration declaration - eticheta unei instructiuni BLOCK (nu discutam acest caz) - eticheta unei instructiuni GENERATE (nu discutam acest caz)
Configuration declaration: sintaxa • component_configuration::= • FOR list_of_component_labels: component_name [binding_indication;] • [block_configuration] • END FOR; • Daca apare block_configuration in component configuration atunci aceasta defineste asocierile (bindings) componentelor de pe urmatorul nivel ierarhic. • Pentru binding_indication exista urmatoarele forme (aceasta e valabil si pt configuration specification): • USE ENTITY nume_entitate[(nume_arhitectura)]; • USE CONFIGURATION nume_configuratie;--lower level configuration • USE OPEN; -- adica nu se asociaza nici o entitate respectivei componente !! • Legarea (binding) se va face eventual mai tirziu (de ex in cazul configuratiei incrementale)
Lower level configuration Urmatorul exemplu scoate in evidenta diferenta intre lower level configuration si configuratii de tip perechi entitate-arhitectura, in cazul unei descrieri structurale pe mai multe niveluri. Entitatea test din exemplele anterioare este componenta unei alte entitati, numita big_test, care nu are porturi, conform figurii urmatoare: test Fig 8. Entitatea big_test, ce contine entitatea test din fig 7. a b et et1 big_test Se prezinta cite un exemplu de configuratie de tip lower level, respectiv cu perechi entitate(arhitectura) pentru configuratia entitatii big_test.
Entitatea big_test cu arhitectura ei si configuratie in stilul lower level configuration: ENTITY big_test IS END big_test; ARCHITECTURE netlist OF big_test IS COMPONENT test IS END COMPONENT; BEGIN et1: test END ARHITECTURE netlist; CONFIGURATION cfg_big_test OF big_test IS FOR netlist FOR ALL: test USE CONFIGURATION WORK.cfg_test; END FOR; END FOR; END CONFIGURATION;
O alta configuratie, in stilul entitate-arhitectura: CONFIGURATION cfg_big_test_2 OF big_test IS FOR netlist FOR ALL: test USE ENTITY WORK.test(netlist_config_decl); -- generic map sau/si port map daca era cazul FOR netlist_config_decl FOR et: neg USE ENTITY WORK.inv(beh) PORT MAP(a=>x, b=>y); END FOR; --daca erau si alte componente mai avem --FOR all: compo-- --END FOR END FOR; END FOR; END FOR; END CONFIGURATION; A doua configuratie (cfg_big_test_2 ) e mai lunga, dar mai flexibila deoarece componentele interne (in acest caz doar neg) pot fi asociate intr-un mod mai flexibil unor perechi entitate(arhitectura).
Reguli de legare implicita • Pt a evita scrierea unor secvente lungi de cod, limbajul are citeva reguli de legare implicita a componentelor: • Pt o instantiere de componenta: • 1. Daca exista si este vizibila o entitate care are acelasi nume ca si componenta, atunci componenta va fi legata de entitate. Daca nu exista o astfel de entitate, atunci in mod implicit apare USE OPEN • 2. Daca entitatea de la regula 1 are mai multe arhitecturi, atunci se foloseste ultima arhitectura compilata. Este o eroare daca entiatatea nu are nici o arhitectura compilata. • 3. Pentru fiecare port sau generic din instantierea de componenta trebuie sa existe in entitate un port sau generic care sa corespunda ca nume, tip si mod. Daca un generic sau port din entitate nu este asociat, atunci este tratat ca si OPEN. Daca asocierea de porturi / generice nu poate fi facuta, atunci se semnaleaza eroare.
Instantiere directa Nu se mai declara componente in partea de declaratii a arhitecturii, iar asocierea (binding) cu perechile entitate(arhitectura) se face direct in instructiunea de instantiere de componente. Exemplu: ARCHITECTURE netlist3 OF test IS SIGNAL s1,s2: BIT; BEGIN et: ENTITY WORK.inv(beh) PORT MAP (a=>s1, b=>s2); --et: CONFIGURATION WORK.inv_cfg PORT MAP(s1,s2); END ARCHITECTURE netlist3;
Instantiere directa: sintaxa Sintaxa instructiunii de instantiere de componenta din instantierea directa: component_label: ENTITY entity_name[(architecture_name)] [GENERIC MAP (generic_association_list)] [PORT MAP (port_association_list)]; Sau: component_label: CONFIGURATION configuration_name [GENERIC MAP (generic_association_list)] [PORT MAP (port_association_list)];
Configuratii incrementale • In VHDL exista asa-numita configuratie incrementala, adica: • Exista configuration specification, dar nu e completa (nu s-a facut legarea tuturor porturilor si genericelor sau exista porturi sau generice OPEN) • Aceasta legare se poate face mai tirziu, in configuration declaration • Se pot chiar suprascrie valorile unor parametri generici din configuration declaration. • In configuration declaration nu mai e nevoie de USE ENTITY deoarece entitatea apare in configuration specification.
Analogia placa-soclu-circuit • Propusa de Alex Stanculescu • O entitate care are o descriere structurala poate fi comparata cu o placa pe care se realizeaza o schema • Arhitectura entitatii ar corespunde etapei de conectare a soclurilor circuitelor prin trasee de cablaj: • Instantieri de componente = socluri • PORT MAP = trasee • In acest moment placa nu este functionala pt ca nu au fost puse circuitele in socluri • Aceasta etapa corespunde configuratiei -> se realizeaza functionarea placii (in VHDL se face legarea componentelor de entitati).
Functii de conversie in configuratii In practica pot aparea situatii in care porturile componentei si cele ale entitatii asociate sa aiba tipuri diferite. Pentru a putea face asocierea trebuiesc utilizate functii de conversie in configuratie. Exemplu: ENTITY circuit IS PORT(q: INOUT std_logic; clk, reset: IN std_logic; iesire: OUT std_logic); END ENTITY; Entitatea circuit va fi asociata unei componente (denumita tot circuit) dintr-o descriere structurala in care se lucreaza cu tipul mvl in loc de std_logic. Presupunem ca intr-un package avm functiile de conversie: - to_mvl ();--face conversie de la std_logic la mvl - to_std_logic();-- face conversie de la mvl la std_logic
Functii de conversie in configuratii PACKAGE conversii IS FUNCTION to_mvl(x: IN std_logic) RETURN mvl; FUNCTION to_std_logic(x: IN mvl) RETURN std_logic; END PACKAGE; PACKAGE BODY conversii IS …. END PACKAGE BODY; USE ….--pt a face vizibile tipurile std_logic si mvl ENTITY x IS END; ARCHITECTURE y OF x IS COMPONENT circuit IS PORT(ctr: INOUT mvl; clk, res: IN mvl; ies: OUT mvl); END COMPONENT;
Functii de conversie in configuratii BEGIN …. END ARCHITECTURE; CONFIGURATION cfg_x OF x IS FOR y FOR ALL: circuit USE ENTITY WORK circuit(arhitectura) PORT MAP( to_mvl(q) => to_std_logic(ctr), clk => to_std_logic(clk), reset => to_std_logic(res), to_mvl(iesire)=>ies); END FOR; END cfg_x; Conform analogiei, entitatea e in “soclul” componenta, deci: - pentru intrari, conversia e dinspre tipul portului componentei spre cel al entitatii - pentu iesiri e dinspre tipul portului entitatii spre cel al componentei - pentru porturi INOUT apar ambele functii de conversie, dupa directia de curgere a informartiei.
COMPONENT circuit clk ENTITY circuit clk ies iesire reset q res ctr Fig 9. Functii de conversie in configuratii.
Functii de conversie • Functiile de conversie se pot utiliza de fiecare data cind se face o asociere de generice, porturi sau parametri in: • Apeluri de funcii • Apeluri de proceduri • Port map • Generic map