Facilitarea Procesului de Invatare a Limbajului Vhdl

CUPRINS

Cap. 1. INTRODUCERE…………………………………………………………..1

Cap. 2. TEHNICI DE SIMULARE………………………………………. …….2

2.1.Notiuni generale……………………………………………….…..……2

2.2.Etapele simularii……………………………………………….……….6

Cap.3.SISTEMUL DE DEZVOLTARE VISUAL C++ 4……………..9

3.1.Scurta prezentare despre Bibliotecile MFC……………..….9

3.2. Arhitectura Document/View………………………………10

3.3. Prezentarea claselor din MFC folosite in proiect……… …13

3.4. Lucrul cu proiectele………………………………………..26

Cap. 4. PREZENTAREA LIMBAJULUI VHDL

4.1. Caracteristici……………………………………………………..……28

4.2. Elemente de baza………………………………………………..……31

4.3. Stiluri de modelare……………………..……………………………33

4.4. Modelarea structuralã………………………………………..……..36

Cap.5. DESCRIEREA PROGRAMULUI

5.1.Introducere…………………………………………………41

5.2.Descrierea programului……………………………………42

5.3.Editarea si gestionarea schemei logice…………………….44

Cap.6. REZULTATE………………………………………………………….…..48

Cap.7. CONCLUZII…………………………………………………………..…..50

Bibliografie……………………………………………………………………….…..51

=== VDIPL ===

CUPRINS

Cap. 1. INTRODUCERE…………………………………………………………..1

Cap. 2. TEHNICI DE SIMULARE………………………………………. …….2

2.1.Notiuni generale……………………………………………….…..……2

2.2.Etapele simularii……………………………………………….……….6

Cap.3.SISTEMUL DE DEZVOLTARE VISUAL C++ 4……………..9

3.1.Scurta prezentare despre Bibliotecile MFC……………..….9

3.2. Arhitectura Document/View………………………………10

3.3. Prezentarea claselor din MFC folosite in proiect……… …13

3.4. Lucrul cu proiectele………………………………………..26

Cap. 4. PREZENTAREA LIMBAJULUI VHDL

4.1. Caracteristici……………………………………………………..……28

4.2. Elemente de baza………………………………………………..……31

4.3. Stiluri de modelare……………………..……………………………33

4.4. Modelarea structuralã………………………………………..……..36

Cap.5. DESCRIEREA PROGRAMULUI

5.1.Introducere…………………………………………………41

5.2.Descrierea programului……………………………………42

5.3.Editarea si gestionarea schemei logice…………………….44

Cap.6. REZULTATE………………………………………………………….…..48

Cap.7. CONCLUZII…………………………………………………………..…..50

Bibliografie……………………………………………………………………….…..51

CAPITOLUL 1

INTRODUCERE

Prezentul proiect a fost realizat sub indrumarea d-lui prof. dr. ing. MIRCEA STRATULAT, caruia ii multumim pe aceasta cale pentru sprijinul acordat si sugestiile date pe intreaga perioada de elaborare a acestui proiect.

Ideea care a stat la baza acestei lucrari a fost facilitarea procesului de invatare a limbajului VHDL, in special in faza de inceput a acestui proces, respectiv de a reduce timpul necesar programatorilor in limbajul VHDL pentru descrierea structurala a unor circuite simple. Scopul este primordial didactic, utilizatorii avind posibilitatea de a urmari descrierea unor entitati mai complexe pe baza componentelor acestora.

Se ofera in plus posibilitatea integrarii optime a proiectarii cu productia, prin reducerea timpului necesar testarii. Testarea fiind o latura importanta a procesului de cercetare, cat si a procesului de proiectare, se impune ca aceasta sa fie cat mai eficienta si mai scurta, oferind in plus si solutiile de defecte existente intr-un circuit. Folosind posibilitatile de simulare oferite de limbajul VHDL, se pot evita timpii de testare de lunga durata, precum si constructia unor circuite complicate in schema testorului.

CAPITOLUL 2

TEHNICI DE SIMULARE

2.1.NOTIUNI GENERALE

Simularea circuitelor logice este un capitol de baza în domeniul cercetarii stiintifice, al proiectãrii si testarii automate a circuitelor. Simularea logica presupune douã etape principale: etapa de verificare a proiectului si etapa de generare-validare a testelor functionale.

Etapa de verificare a proiectului cuprinde urmãtoarele;

– verificarea corectitudinii proiectului , înainte de trecerea la realizarea practicã (implementare).

-determinarea rãspunsului unui subansamblu în diferite conditii electrice si logice, statice si dinamice.

In etapa de generare a testelor, simularea logicã presupune generarea secventelor stimul test pentru diferite conditii de defecte în vederea stabilirii documentatiei de întretinere a proiectului logic.

Simulatorul logic constituie un element eficace de analizã si verificare a proiectului logic al unui sistem numeric si stabileste o legãturã între proictant si constructor, astfel prin utilizarea unui simulator se poate observa corectitudinea schemei din punct de vedere functional si constructiv , urmând ca în urma confirmãrii corectitudinii schemei sã se treacã la realizarea practicã. Etapa de realizare practica

este succedata de o etapã de verificare într-o schema de testor automat.

Simularea logica ocupa un loc important în procesul de cercetare stiintificã, putând fi folosita în orice domeniu de activitate , prin elaborarea de programe adecvate fiecãrui domeniu ce necesitã folosirea unor astfel de algoritmi.

In general, un program de simulare calculeazã semnalele pe liniile de legãturã dintre circuite în cadrul unei scheme logice pentru stãri si intrãri diferite.

In cazul schemelor sincrone, timpul este tratat ca o variabilã discretã si valoarea semnalelor prezintã interes doar la anumite momente de timp. Pentru schemele asincrone trebuie luatã în considerare si posibilitatea unui timp critic. In cadrul procedurii de simulare se pãstreazã caracteristicile diferitelor circuite logice componente (de exemplu: timpii de comutare ai portilor elementare).

Simularea circuitelor digitale fãrã investitii hard permite utilizarea unui program de bazã C.A.D.(Computer Aided Design) si care trebuie sã rezolve problemele de codificare si memorare a semnalelor întru-n simulator logic.Un astfel de sistem C.A.D. poate fi folosit atât în cercetare,cât si în învãtãmânt.

Simularea numericã este folositã pentru verificarea proiectului numeric, înaintea etapei de fabricare. Vom prezenta în continuare diferite tehnici de simulare.

tehnicã de simulare foloseste semnalele unor anumite linii din schemã pentru a da stãrile initiale si intrãrile. In urma simulãrii se recurge la o comparare între semnalele de iesire ale circuitului normal si

ale circuitului cu defect. Astfel se determinã circuitul defect si momentul la care apare defectiunea; aceste informatii pot fi folosite pentru realizarea dictionarului de defecte, detectate cu ajutorul unui set de teste dat.

Presupunem cã schimbarea intrãrii s-a întâmplat la momente fixe si doar valorile stationare ale semnalului ne intereseazã, ca în cazul functionãrii sincrone. In acest caz , metoda de simulare îmbunãtãteste calculul la iesirea fiecãrei porti din circuit fãcând uz de intrãrile si de tipul portilor. Simularea pentru orice moment este completã când iesirile tuturor portilor au fost obtinute si adaptate cu intrãrile si tipul portii.Dar aceastã procedurã se dovedeste insuficientã în urmãtoarele situatii :

-timpul de iesire al unei porti este calculat în functie de ordinea în care sunt simulate portile din schema (o poartã se simuleazã dupã ce au fost simulate portile ce pot afecta comutarea acesteia).

-este necesarã determinarea valorilor unei porti cand intrãrile acesteia nu au fost modificate în urma aplicãrii unor noi vectori test.

Se poate îmbunãtãti eficienta simulãrii prin organizarea descrierii schemei în asa fel încât o poartã sã nu poatã fi simulatã , în timp ce toate portile alimentate sunt simulate. Aceasta se poate realiza pentru circuite fãrã reactie prin aranjarea portilor pe nivele, nivelul de porti începînd de la nivelul mai mic spre cel mai mare al portii alimentate. La intrarea circuitului (intrarea primarã) se atribuie nivelul 0. La circuitele cu reactie, bucla de reactie este presupusã deschisã înaintea nivelului atribuit. Deci nivelul atribuit la o poartã depinde de locul unde bucla este întreruptã.

O îmbunãtãtire în vitezã poate fi obtinutã prin calcularea stãrilor numai pentru portile pentru care una sau mai multe intrãri au fost shimbate (Menon , 1965 ; Cheng 1970).Aceastã tehnicã este cunoscutã sub denumirea de traseu selectiv (selectiv trace).

Eficienta ei este uzual îmbunãtãtitã prin aranjarea portilor pe nivelele lor. Dacã iesirea portii sau intrarea primarã se schimbã , sunt identificate portile comandate de ea si acestea vor fi simulate.

Simularea unei porti individuale este realizatã în ordinea nivelului pe care îl ocupã , dar numai portile ale cãror intrãri s-au schimbat se vor simula. Bucla conduce spre identificarea portilor si simularea este repetatã dacã o linie de reactie a schimbat starea. La circuitele sincrone cu mai multe faze de tact, o crestere în vitezã se poate obtine prin simularea doar a acelor porti din schemã care se pot schimba în timpul tactului de faze particular din conditia respectivã.

Tehnicile de simulare se pot împãrti în douã clase, în functie de felul cum descrierea circuitului ce este simulat este utilizatã. O primã clasã se numeste “ simulator de comandã al compilãrii “ ( Compiler driver simulator ), în care circuitul descris este tratat ca program sursã într-un nivel de programare de nivel înalt. Procesul anterior simulãrii, ce este un compilator pentru limbajul de programare , genereazã coduri pentru simularea fiecãrui circuit. Simularea circuitului este deci executarea programului de compilare de cãtre preprocesor. Acest tip de simulator este eficient pentru scheme de capacitate moderatã (câteva sute de porti). Dezavantajul acestei metode este cã traseul selectiv nu poate fi utilizat. Un exemplu de astfel de simulator este analizorul secvential (Seshu si Freeman ,1962)

Clasa a doua a simulatoarelor cuprinde simulatoarele “Table driver simulator” (T.D.S.), în care circuitul descris este memorat sub formã de tabele. Programul de simulare foloseste tabele cu date de intrare. Se folosesc pentru scheme de mare capacitate, prin memorarea tabelelor cu date de intrare în memoria calculatorului. Dezavantajul este cã se cere un timp mai mare pentru încãrcarea datelor si folosirea traseului selectiv. Programul Armstrong (1968-1971) este un simulator TDS.

Simularea se realizeazã la diferite nivele de detaliu. Vom pune accent pe nivelul de poartã logicã elementarã , deoarece este mai utilã pentru generarea si verificarea testelor. La simularea circuitelor de mare anvergurã se poate realiza la anumite circuite din schemã simulare la nivel functional (functional level), iar la altele la nivel de poartã (gate level). Se presupune cã defectele sunt prezente doar în acele circuite care sunt simulate la nivel de poartã.

Desi simularea functionalã este mai simplu conceptual, existã o dificultate majorã în abordarea ei , în lipsa unei metode satisfãcãtoare de descriere a circuitului. Simularea functionalã este acceptatã sã fie restrictivã la circuite relativ simple ca registru de deplasare sau sumatoare.

2.2. ETAPELE SIMULARII

ANALIZA SI SINTEZA SCHEMELOR LOGIC

Schema se descompune în pãrti componente pentru a fi analizate în vederea întelegerii functionãrii sale. Sinteza schemei este o etapã a proiectãrii ce permite compunerea , combinarea pãrtilor ori a elementelor necesare realizãrii sistemului complet, urmãrindu-se totodatã dacã acesta atinge nivelul de performante propus. In ceea ce priveste sinteza sistemelor existã o varietate de opinii privind modul în care trebuie combinate componentele pentru realizarea structurii sistemului.

Elementele necesare pentru studiul unor scheme logice sunt :

– variabile de decizie si variabile de stare :

Prin variabilele de decizie, analistul poate lua decizii de continuare, oprire, schimbare a rutei de parcurs a procesului de simulare, în functie de valoarea lor la un moment dat. Variabilele de stare sunt dependente de variabilele de decizie si descriu starea unui element la un moment dat de timp, neputând fi controlate direct de analist.

Adesea clasificarea variabilelor în variabile de stare si variabile de decizie e arbitrarã; totusi, de îndatã ce se realizeazã o clasificare a lor, comportarea acestora este urmãritã pe baza unui algoritm bine definit. Aceastã urmãrire constituie o actiune importantã a fazei de analizã a proiectãrii logice a circuitului.

– realizarea unui model optimal :

Acest obiectiv implicã atât analiza, cât si sinteza si constã în dezvoltarea unui model conceptual care sã fie suficient de analog cu cel real.

– mãsurarea performanþelor :

De obicei, caracteristicile de performantã ale unui proiect se mãsoarã prin intermediul unei functii obiectiv.

– generarea alternativelor si a solutiei optime :

Se efectueazã o serie de rulãri ale programului de simulare pentru diferite valori ale variabilelor de intrare, rezultând la iesire o serie de alternative. Prin studiul comportãrii circuitului se alege cea mai bunã varianta.

PROIECTAREA SCHEMEI

In cadrul etapei de proiectare a schemei logice un prim obiectiv îl reprezintã formularea si analiza problemei, trebuind stabilite în detaliu toate aspectele problemei chiar dacã uneori o astfel de formulare se apropie de rezolvarea analiticã.

Se studiazã astfel comportarea diferitelor porti, conditii de comutare, timpi de comutare, efectele vizibile la iesire ale schimbãrii variabilelor de intrare, tehnici de reducere a datelor, de analizã si reprezentare a datelor de iesire, interpretarea rezultatelor.

Un al doilea obiectiv îl reprezintã memorarea si prelucrarea primarã a datelor. Se studiazã tehnicile de introducere a datelor, de initializare si setare a lor Datele de intrare pot fi, de exemplu, tipul portilor , intrãri , iesiri , pozitia portilor în cadrul schemei de simulare , timpi de comutare , caracteristici functionale, vectori de intrare pentru simularea logicã. Acestea se introduc de la tastaturã sau pot fi organizate în fisiere, tabele etc.

Pe baza datelor primare se pot aduce îmbunãtãtiri modelelor existente, se verificã si se valideazã proiectul. Se pot elimina acele date care sunt afectate de diferite tipuri de erori. In aceastã etapã se definesc parametrii si variabilele. Parametrii pot fi de exemplu timpii de comutare si caracteristicile de functionare ale portilor logice. Prin variabile se definesc mãrimile ce se modificã în cadrul procesului de proiectare, cum ar fi valoarea semnalelor pe liniile de legãturã ale schemei logice.

CAPITOLUL 3

SISTEMUL DE DEZVOLTARE VISUAL C++ 4

Desi programele secventiale sunt potrivite pentru explicarea unor concepte simple, cum ar fi elementele de baza ale limbajului C++,totusi functionarea lor nu este corespunzatoare in medii multitasking gen Microsoft Windows. Intr-un mediu Windows, toate resursele se folosesc in comun: tastatura, mouse-ul, chiar si utilizatorul. Programele scrise pentru Windows trebuie sa colaboreze cu Windows si cu alte programe care pot rula in acelasi timp.

Mediul de programare este orientat spre folosirea interna a MFC, ierarhia de clase fundamentala in jurul caruia sint realizate toate aplicatiile Microsoft pentru Windows .

3.1.SCURTA PREZENTARE A BIBLIOTECILOR MFC

Biblioteca de clse MFC este o colectie de clase MFC care simplifica scrierea programelor C++. Clasele incluse in biblioteca de clase MFC sunt dispuse in urmatoarele categorii:

Clase de uz general. In aceasta categorie intra clasele utilizate la manipularea fisierelor si a sirurilor.De asemenea, aceasta clasa include si o ierarhie de clase de exceptii(ex. CRrect, CPoint).

Clase de obiecte virtuale. Aceste clase manevreaza aproape orice este vizibil intr-un program Windows(ex. clasele de meniuri, grafica, ferestre, controale si obiecte de desenare.)

Clase de aplicatie. In aceasta categorie se includ clase care gestioneaza obiecte de nivel aplicatie(ex. siruri de executie, sau arhitectura Document/View.)

Clase de tip colectie. Aceste clase se folosesc pentru crearea de containere care stocheaza alte obiecte.

Clase OLE2.

Clase pentru baze de date. Asigura accesul la bazele de date.

Clase de control. Windows 95 a introdus un numar de controale noi (ex. vizualizari de liste, controale arborescentesi controale de progres). Aceste clase asigura un acces simplu la controale.

ClaseWindowsSocket. Aceste clase se folosesc pentru comunicatii de soclu. Soclurile sunt caracteristice comunicatiilor client/server si in retea.

Din mediul integrat Microsoft Developer Studio,componenta centrala a limbajului Visual C++4, avem acces la urmatoarele componente foarte utile:

programul AppStudio care permite editarea resurselor .

programul AppWizard care, pe baza unui dialog, genereaza un schelet al aplicatiei .

bare cu instrumente care pot fi configurate conform optiunilor utilizatorului .

3.2.ARHITECTURA DOCUMENT/VIEW

AppWizard foloseste clasele MFC pentru a crea aplicatii bazate pe arhitectura Document /View. Ideea de baza a acesteia este separarea claselor de manipulare a datelor de cele care trateaza interfata cu utilizatorul.

Arhitectura Document/View este o modalitate de utilizare a codului pentru a reprezenta datele si a interactiona cu utilizatorul.(alte cadre–frameworks-trateaza ferestrele ca spatii care urmeaza a fi pictate). In arhitectura Document /View cadrul de lucru foloseste documentul nu fereastra .

Documentele sint clase folosite pentru reprezentarea datelor. Aceste clase stiu sa citeasca si sa scrie in si din fisiere, propriul continut, sa se actualizeze si sa se afiseze pe ecran. Vizualizarile (View) sint clase care afiseaza continutul documentelor.Spre exemplu, niste date pot fi afisate tabelar sau sub forma de grafice .Aceleasi date pot avea deci mai multe vizualizari. Modificarea unor date in tabel spre exemplu , comunica celorlalte vizualizari sa afiseze noile date (ceea ce determina actualizarile spre exemplu spre grafice). Arhitectura document/view face o distinctie clara intre date si afisarea acestora . De aceea programatorul trebuie sa gindeasca aplicatia in functie de aceasta filosofie.

Aceasta reprezentare ofera un inalt grad de abstractizare deoarece permite modificarea codului documentului fara a fi necesara modificarea codului pentru vizualizare .Document/View separa un document in patru clase principale:

O clasa document, derivata din CDocument

O clasa de vizualizare, derivata din CView

O clasa cadru, derivata din CFrameWnd

Oclasa de aplicatie, derivata din CWinApp

Fiecare dintre aceste clase are un anumit rol intr-o aplicatie MFC Document/View. Clasa document raspunde de datele dintr-un program. Clasa de vizualizare trateaza interactiunea dintre document si utilizator.Clasa cadru contine vizualizarea si alte elemente de interfata cu utilizatorul, cum ar fi meniurile si barele de instrumente.

Clasa de aplicatie este responsabila cu lansarea efectiva a programului, precum si cu tratarea unor interactiuni de uz general cu Windows.

Exista doua tipuri principale de programe Document/View:

SDI (Single Document Interface)

MDI (Multiple Document Interface)

Un program MDI permite folosirea mai multor tipuri de documente, fiecare document putind avea mai multe vizualizari. La un moment dat pot fi deschise mai multe documente, iar documentul deschis foloseset frecvent o bara de instrumente si meniuri personalizate, care satisfac necesitatile acelui document.

Unul dintre marile avantaje ale arhitecturii Document/View este acela ca imparte activitatea unui program Windows in categorii bine definite. Impartirea activitatii unui program contribuie la gestionarea mult mai eficienta a conceptiei acestuia.Extinderea programelor care folosesc arhitectura Document/View este relativ simpla, deoarece cele patru clase principale intercomunica prin intermediul unor interfete bine definite. De exemplu modificarea unei interfete utilizator pentru un program Document/View are efect numai asupra clasei sau claselor de vizualizare, nefiind necesare nici un fel de schimbari pentru clasele document, cadru sau de aplicatie.

Atat aplicatiile SDI, cat si MDI folosesc un obiect denumit sablon document pentru a crea o relatie intre o clasa vizualizare, o clasa document si o clasa cadru, precum si ca identificator pentru meniu, pictograme si alte resurse de program. Clasa CSingleDocTemplate se foloseste pentru aplicatiile SDI, iar clasa CMultiDocTemplate-pentru aplicatiile MDI. Aceste doua clase folosesc aceeasi clasa de baza, anume CDocTemplate.

Intr-un program MDI exista doua tipuri de ferestre cadru:cadrul principal,care include intreaga zona client, si cadrul descendent, care contine fiecare fereastra descendentMDI.

CChildFrame este o clasa inclusa in fiecare proiect MDI creat cu AppWizard, fiind derivata din CMDIChildFrame. Destinatia acestei clase este de a facilita adaptarea cadrului la necesitatile utilizatorului.

Fiecare fereastra descendent MDI are un cadru, care este posesorul butoanelorde maximizare, minimizare si inchidere, precum si cadrulu din jurul vizualizarii. Orice adaptare adusa cadrului se executa in clasa CChildFrame.

3.3.PREZENTAREA CLASELOR DIN MFC FOLOSITE IN PROIECT

Clasa CObject

Clasele aditionale sînt derivate din clasele parinte.CObject este una din clasele parinte utilizata intensiv în dezvoltarea aplicatiilor. CObject este definit în fisierul header afx.h . CObject deasemenea ofera si testare normala respectiv dinamica a tipului si serializare . Testarea dinamicã a tipului presupune ca tipul obiectului este determinat în timpul rularii . Starea obiectului poate fi salvata pe un mediu de stocare ca de exemplu un disc , printr-un concept numit persistenta. Persistenta obiectelor permite functiilor membre sa fie deasemenea persistente, permitînd încarcarea de date obiect .

Exemple de clase derivate din Cobject:

-CGdiObject si functiile lui membre permite entitatilor ca "creioane grafice", "pensule", si fonturi sa fie create si folosite în aplicaþii Windows .

-CWinApp -Mentine codurile de initializare , rulare si iesire pentru aplicatie .

-CWnd -Clasa parinte pentru toate ferestrele.

-CFrameWnd Clasa de baza folosita pentru programe bazate pe interfata monodocument (SDI).

-CMDIFrameWnd Clasa de baza folositã pentru programe bazate pe interfata multidocument (MDI).

-CMDIChildWnd Pentru ferestre "child" bazate pe interfata multidocument (Multiple Document Interface) .

-CDialog Pentru a crea ferestre de dialog nemodale

-CButton Pentru controale buton.

-CComboBox Pentru controale "combo box".

-CEdit Pentru controale de editare.

-CListBox Pentru controale de tip lista.

-CScrollBar Pentru bare de derulare.

-CStatic Pentru controale statice.

-CDC Pentru context de afisare.

-CClientDC Pentru context de afisare asociat unei zone client.

-CPaintDC Pentru context de afisare folosit de functii membru OnPaint ca de exemplu LineTo( ), Ellipse( ).

-CWindowDC Pentru context de afisare al întregii ferestre

-CGdiObject Pentru toate uneltele de desenare GDI

-CBitmap Pentru bitmap GDI

-CBrush Pentru "pensule" GDI

-CFont Pentru fonturi GDI

-CPen Pentru "creioane" GDI

-CMenu Pentru crearea de structuri de meniu

-CPoint Pentru coordonate punct într-un context dispozitiv. Nu este derivatã din clasa Cobject

-CRect Pentru regiuni rectangulare int-un context dispozitiv. Nu este derivatã din clasa Cobject

Clasa CDocument

Clasa CDocument furnizeaza functionalitatea de baza pentru clase document definite de utilizator . Un document reprezinta colectia de date pe care utilizatorul o acceseaza cu o comanda File Open si o salveaza cu o comanda File Save.

CDocument ofera suport pentru operatii standard ca crearea unui document, încarcarea sa, si salvarea acestuia. Mediul de lucru manipuleazã documente folosind interfata definita de CDocument.

O aplicatie poate suporta mai mult decît un tip de document, de exemplu, o aplicatie ar trebui sa aiba suport pentru documente spreadsheets si documente text. Fiecare tip de document are asociat un template document. Un document template specifica care resurse (de exemplu meniu, icon, sau tabela de acceleratori) este utilizata pentru acel tip de document. Fiecare document contine un pointer la obiectul asociat de tip CDocTemplate.

Utilizatorul interactioneazã cu un document prin obiectul CView asociat cu el. O vizualizare afiseaza o imagine a documentului într-un cadru fereastra si interpreteaza intrarea de la utilizator ca operatii asupra documentului. Un document poate avea multiple vizualizari asociate cu el. Cînd utilizatorul deschide o fereastra a documentului , mediul de lucru creaza o vizualizare si o ataseaza documentului. Template-ul document specifica care tip de vizualizare si cadru fereastra este utilizat pentru a afisa fiecare tip de document.

Documentele primesc permanent comenzi de la componentele interfetei utilizator standard (ca optiunea de meniu File Save) .Un document receptioneazã comenzi trimise de vizualizarea curenta Daca documentul nu interpreteaza o comanda primita aceasta este trimisa la template-ul document.

Cînd o data document este modificata, fiecare din vizualizari trebuie sã reflecte aceste modificari. CDocument furnizeaza functia membra UpdateAllViews pentru ca sa notifice vizualizarilor aceste schimbari astfel ca vizualizãrile sa se poata redesena daca e necesar. Mediul de lucru deasemenea atentioneaza utilizatorul sa salveze un fisier modificat înainte de a-l închide.

Clasa CDocTemplate

CDocTemplate este o clasa abstracta care defineste functionalitatea de baza pentru "template-uri" document . De obicei se creaza unul sau mai multe "template-uri" document în implementarea functiei InitInstance a fiecarei aplicatii . Un template document defineste relatiile între trei tipuri de clase.Aplicatia creata trebuie sa aiba un template document pentru fiecare document care îl suporta. Fiecare document template este responsabil cu crearea si manipularea fiecarui document dupa tipul sau .Template-ul document stocheaza pointeri la obiectele CRuntimeClass pentru clasele document, vizualizare si cadru fereastra. Aceste obiecte CRuntimeClass sînt specificate cînd se construieste un document template.

Template-ul document contine identificatorul resurselor utilizate cu tipul documentului (ca de exemplu meniu, icon, sau tabela de taste acceleratoare . Template-ul document contine deasemenea siruri de caractere ce contin informatii aditionale despre tipul documentului .

Deoarece CDocTemplate este o clasa abstracta, aceasta nu se poate utiliza direct. O aplicatie tipica utilizeaza una sau doua clase derivate CDocTemplate furnizate de Microsoft Foundation Class Library : CSingleDocTemplate, care implementeaza o interfata monodocument si CMDIDocTemplate, care implementeaza o interfata multidocument.

Clasa CView

Clasa CView furnizeaza functionalitatea de baza pentru clasele view definite de utilizator . O vizualizare este atasata unui document si se comporta ca un intermediar între document si utilizator : vizualizarea trimite imagine a documentului pe ecran sau imprimanta si interpreteaza intrarile de la utilizator ca operatii asupra documentului .

O vizualizare este un "child" al unui cadru fereastra. Mai mult de o vizualizare poate sa împarta un cadru fereastra, ca în cazul ferestrei "split".

Relatia dintre o clasa fereastra , o fereastra cadru si o clasa document este stabilita de un obiect CDocTemplate . Cînd utilizatorul deschide o noua fereastra sau realizeaza un "split" pentru o fereastra existenta, spatiul de lucru construieste o noua vizualizare si o ataseaza documentului.

-Vizualizare poate fi atasata doar unui document, dar un document poate avea multiple vizualizari atasate acestuia. Spre exemplu daca documentul este afisat într-o fereastra "split" sau în mai multe ferestre "child" în cadrul unei interfete multidocument. Aplicatia poate suporta diferite tipuri de vizualizari pentru un tip de document dat. Aceste diferite tipuri de vizualizari pot fi puse în ferestre cadru separate sau în plane separate într-un singur cadru daca se foloseste o fereastra "split". O vizualizare poate fi responsabila de manipularea diferitelor tipuri de intrari ca tastatura, mouse sau intrari prin "drag-and-drop", ca si de comenzi date prin meniuri, bare de unelte sau bare de derulare . O vizualizare receptioneaza comenzile transmise de cadrul fereastra corespunzator ei. Daca vizualizarea nu interpreteaza o comanda, aceasta este transmisa la documentul ei asociat. O vizualizare manipuleaza mesajele prin intermediul hartii de mesaje.

-Vizualizarea este responsabila de afisarea si modificarea datelor documentului ,dar nu si de stocarea acestora. Documentul furnizeaza vizualizarea cu detaliile necesare despre datele sale. Se poate lasa ca vizualizarea sa acceseze direct datele membre ale documentului, sau se pot furniza functii membre în clasa document pentru clasa view. Cînd datele documentului se schimba, vizualizarea responsabila pentru schimbari de obicei apeleaza functia membra documentului CDocument::UpdateAllViews pentru documentul care notifica toate celelalte vizualizari apelînd functia membra OnUpdate pentru fiecare. Implementarea implicita a functiei OnUpdate invalideaza întreaga arie client de vizualizare. Se poate suprascrie aceasta functie pentru a invalida numai acele parti din regiunea client care corespund portiunilor modificate din document.

Clasa CFrameWnd

Clasa CFrameWnd determina functionalitatea unei interfete unidocument (SDI) . Pentru a crea o fereastra cadru se deriveaza o clasa din CFrameWnd . Se adauga variabile membru la clasa derivata pentru a stoca date specifice la aplicatiei . Se implementeaza o functie membru handler de mesaje si o harta de mesaje în clasa derivata pentru a specifica ce se întîmpla cînd mesajele sînt directate spre fereastra.

Cînd un obiect CFrameWnd contine vizualizari si documente, ele sînt create indirect de framework . Obiectul CDocTemplate realizeaza crearea cadrului, crearea continutului unei vizualizari, si conectarea vizualizarii la documentul potrivit. Parametrii constructorului CDocTemplate specifica CRuntimeClass al celor trei clase implicate (document, cadru-frame si vizualizare-view) . Un obiect CRuntimeClass este folosit de mediul de lucru pentru a crea dinamic noi cadre cînd se specifica de utilizator , de exemplu folosind comanda File New sau comanda Window New pentru un program multidocument .

O clasa fereastra cadru derivata din CFrameWnd trebuie sa fie declarata cu DECLARE_DYNCREATE. Nu se foloseste operatorul C++ delete pentru a distruge o fereastra cadru. Se foloseste în acest scop CWnd::DestroyWindow. Implementarea în CFrameWnd a PostNcDestroy va sterge obiectul C++ cînd fereastra este distrusa. Cînd utilizatorul închide cadrul fereastra, handler-ul implicit OnClose va apela DestroyWindow .

Clasele prezentate pîna acum sînt folosite de AppWizard pentru a construi un schelet al aplicatiei . În continuare sînt prezentate si alte clase importante incluse în MFC si care sînt folosite în implementarea proiectului EcgManager.

Clasa CDialog

Clasa CDialog este derivata din CWnd. O cutie de dialog este un tip special de fereastra . Pentru a crea o cutie de dialog se deriveaza o clasa din CDialog sau se foloseste una din clasele pentru cutii de dialog standard ca deschidere sau salvare în fisier, tiparire, selectie de culori, sau fonturi, operatii de cautare si înlocuire sau pentru operatii OLE .

CDialog este clasa de baza pentru toate cutiile de dialog modale sau nemodale.CDataExchange realizeaza schimbul de date si valideaza informatiile pentru cutii de dialog.

Clasa CButton

Clasa CButton furnizeaza functionalitate controalelor buton. Un control buton este o mica fereastra "child" rectangulara care poate fi facuta pornit/stins. Butoanele pot fi utilizate singure sau în grup si pot avea o eticheta sau pot aparea fara text. Un buton de obicei îsi

schimba aspectul cînd utilizatorul apasa pe el. De obicei butoanele sînt de tip check box, radio button si pushbutton.

Clasa CComboBox

Clasa CComboBox furnizeaza functionalitate unei combo box. Un combo box este un list box combinat fie cu un control static, fie cu un control de editare. Portiunea list box a controlului va fi afisata cînd utilizatorul selecteaza butonul cu sageata. Optiunea curent selectata din list box este afisata în controlul static sau de editare .Deasemenea daca controlul combo box are stilul drop-down utilizatorul poate tasta caracterul initial al uneia din optiunile din lista.

Clasa CEdit

Clasa CEdit furnizeaza functionalitatea controlului de editare. Un control de editare este o fereastra "child" drepunghiulara în care utilizatorul poate introduce text. CEdit include multe functionalitati din CWnd. Pentru a seta si obtine text dintr-un obiect CEdit, se folosesc functiile membre SetWindowText si GetWindowText, care seteaza sau obtine întregul continut al controlului de editare, chiar în cazul în care acesta este unul multilinie. Deasemenea , daca un control de editare este multilinie, se obtin si seteaza parti ale controlului text apelînd functiile membre GetLine, SetSel, GetSel si ReplaceSel.

CListBox

Clasa CListBox furnizeaza functionalitatea pentru un list box. Un control list box afisesza o lista de entitati ca fisiere, pe care utilizatorul le poate vedea si selecta. Într-o lista cu simpla selectie, utilizatorul poate selecta doar o singura entitate. Într-o lista cu selectie multipla, mai multe entitati pot fi selectate. Cînd utilizatorul selecteaza o optiune, ea este evidentiata si list box trimite un mesaj de notificare ferestrei parinte. Pentru a utiliza un list box într-un dialog template , trebuie sa se declare o variabila list-box în clasa dialogului , în clasa dialog, apoi se utilizeazã DDX_Control în functia DoDataExchange pentru a conecta variabila membra la control.

Clasa CScrollBar

Clasa CScrollBar ofera functionalitate unui control scroll-bar. Se poate crea un control scroll-bar în doi pasi .

Mai întîi se apeleaza constructorul CScrollBar pentru a construi obiectul CScrollBar, apoi se apeleaza functia membra Create pentru a crea controlul scroll-bar si a-l atasa obiectului CScrollBar.

Clasa CStatic

Clasa CStatic furnizeaza functionalitatea unui control satic. Un control static afiseaza un text, dreptunghi, icon,cursor, bitmap sau metafisier. El poate fi folosit la etichete, box-uri sau alte controale separate. În mod normal un control static nu primeste nici o intrare si nu furnizeaza nici o iesire. Oricum el poate notifica ferestrei parinte clicul de mouse daca este creat cu stilul SS_NOTIFY .

Se creeaza un obiect CStatic în doi pasi . Mai întîi se apeleaza constructorul pentru a construi obiectul CStatic, apoi se apeleaza functia membra Create pentru a crea controlul static si a-l atasa la obiectul CStatic.

Clasa CDC

Clasa CDC defineste o clasa a unui obiect context-dispozitiv. Un obiect CDC furnizeaza functii membre pentru lucrul cu contexte dispozitiv ca display sau imprimanta , ca si functii pentru lucrul cu un context de afisare asociat cu regiunea curenta a unei ferestre. Toate operatiile de desenare se realizeaza prin intermediul functiilor membre ale unui obiect CDC. Clasa CDC furnizeaza functii membre pentru operatii context-dispozitiv, lucrul cu unelte de desenare, selectie de obiecte GDI, si lucrul cu culori si palete. Deasemenea furnizeaza functii membre pentru obtinerea si setarea atributelor de desenare, mappare, conversii de coordonate, lucrul cu regiuni, clipping, desenare de linii si desenare de forme simple, elipse si poligoane. Functiile membre sînt deasemenea furnizate pentru a afisa text, lucru cu fonturile, utilizarea instructiunilor pentru imprimanta, scrollare si redarea metafisierelor.Pentru a utiliza un obiect CDC , el trebuie construit si apoi se apeleaza functiile membre care utilizeaza contextul dispozitiv.

Pentru utilizari specifice biblioteca MFC furnizeaza cîteva clase derivate din CDC. CPaintDC încapsuleaza apelul lui BeginPaint si EndPaint. CClientDC manipuleaza un context de afisare cu o zona client a fereastrei. CWindowDC manipuleaza un context de afisare asociat cu o întreaga fereastra. CMetaFileDC asociaza un context dispozitiv cu un metafisier.CDC contine doua contexte dispozitiv , m_hDC si m_hAttribDC, care la crearea unui obiect CDC refera acelasi dispozitiv.CDC directeaza toate apelurile iesire GDI la m_hDC , si ale celor mai multe apeluri de atribute GDI la m_hAttribDC. (Un exemplu al unui apel de atribut este GetTextColor, pe cînd SetTextColor este un apel iesire GDI).

Clasa CFont

Clasa CFont încapsuleaza un font GDI si furnizeaza functii membre pentru manipularea fonturilor.

Pentru a utiliza un obiect CFont, se construieste un obiect CFont si se ataseaza un font Windows acestuia cu CreateFont, CreateFontIndirect, CreatePointFont sau CreatePointFontIndirect, si apoi utilizeaza functii membre ale obiectului pentru a manipula fontul. Functiile CreatePointFont si CreatePointFontIndirect sînt de obicei mai usor de folosit ca CreateFont sau CreateFontIndirect pentru ca ele realizeaza conversia automata pentru înaltimea fontului de la marimea unui punct la unitati logice .

Clasa CPen

Clasa CPen încapsuleaza un creion (pen) GDI.

Clasa CPoint

Clasa CPoint este similara cu structura Windows POINT :

typedef struct tagPOINT {

LONG x;

LONG y;

} POINT;

Structura POINT defineste coordonatele x si y ale unui punct.Clasa CPoint include deasemenea functii pentru a manipula structurile CPoint si POINT.Un obiect CPoint poate fi utiliza la fel cum este utilizata o structura POINT. Operatorii acestei clase care interactioneaza cu o "marime" accepta obiectul CSize sau structura SIZE.Aceasta clasa este derivata din structura tagPOINT. Numele tagPOINT este un nume mai putin utilizat pentru structura POINT. Aceasta înseamna ca datele membre ale structurii POINT ,x si y sînt date membre accesibile ale CPoint.

Clasa Crect

Clasa CRect este similara cu structura Windows RECT. CRect deasemenea include functii membre pentru a manipula obiecte CRect si structuri Windows de tip RECT.

Structura RECT are urmãtoarea forma:

typedef struct tagRECT {

LONG left;

LONG top;

LONG right;

LONG bottom;

} RECT;

Aceasta defineste coordonatele colturilor stînga-sus si dreapta-jos ale dreptunghiului . Un obiect CRect poate fi folosit ca parametru al unei functtii fie o structura RECT, LPCRECT sau LPRECT .

Aceasta clasa este derivata din structura tagRECT. Aceasta înseamna ca datele membre (left, top, right si bottom) ale structurii RECT sînt datele membre accesibile ale CRect. O clasa CRect contine variabile membre care definesc punctele stînga-sus si dreapta-jos ale unui dreptunghi .

3.4. LUCRUL CU PROIECTE

Visual C++ organizeaza programele in proiecte. Un proiect se numeste aici workspace . Acesta este format din fisierele sursa ale unei aplicatii, impreuna cu specificatiile de construire ale unui program .Un proiect poate avea mai multe destinatii , construite din fisiere sursa.

Fiecare destinatie este formata dintr-un set de elemente, cum ar fi aplicatia care va fi construita, platforma pe care va rula, instrumentele folosite pentru construirea aplicatiei . Includerea posibilitatilor de precizare a unor surse multiple permite extinderea domeniului unui proiect, pastrind acelasi cod sursa . Accesul la informatii legate de proiect (clase ,resurse , fisiere) se realizeaza prin intermediul ferestrei –proiect care permite vizualizarea (prin dublu click pe elementul selectat) in mai multe moduri

CAPITOLUL 4

PREZENTAREA LIMBAJULUI VHDL

Denumirea VHDL provine de la titlul “VHSIC Hardware Description Language”, unde VHSIC reprezintã “Very High Speed Integrated Circuits”. VHDL este un limbaj de descriere hardware care poate fi utilizat pentru a modela un sistem digital la diverse nivele de abstractizare, extinse de la nivel algoritmic la nivel de porti. Complexitatea sistemului digital modelat poate varia de la o simplã poartã la un întreg sistem electronic digital. Sistemul digital poate fi descris si ierarhic. Temporizarea poate fi modelatã explicit in aceeasi descriere.

Limbajul VHDL poate fi privit ca o integrare a mai multor limbaje: limbaj secvential, limbaj concurent, limbaj net-list, specificãri de temporizare si limbaj pentru generarera formelor de undã.

Datoritã complexitãtii sale, limbajul are constructii care permit programatorului sã exprime comportarea concurentã sau secventialã a unui sistem digital cu sau fãrã temporizare. In plus, el permite modelarea sistemului ca o interconexiune de componente. Forme de undã de test pot fi generate folosind aceleasi constructii. Toate constructiile mentionate pot fi combinate in vederea obtinerii unei descrieri care sã cuprindã întregul sistem într-un singur model.

Limbajul nu defineste doar sintaxa, ci si semantici de simulare pentru fiecare constructie a imbajului. De aceea, modele scrise în acest limbaj pot fi verificate folosind un simulator VHDL. Este un limbaj puternic tipizat si deseori este prolix de scris. El mosteneste multe din caracteristicile sale, în special partea de limbaj secvential, din limbajul de programare Ada. Deoarece VHDL permite un domeniu extins de posibilitãti de modelare, este deseori dificil de înteles. Totusi este posibil sã se asimileze rapid un subset nucleu al limbajului care este mai usor de înteles fãrã a învãta caracteristicile mai complexe. Acest subset este în general suficient pentru a modela majoritatea aplicatiilor. Oricum, limbajul complet are suficientã putere pentru a capta descrierile celor mai complexe cip-uri pentru un sistem în totalitate electronic.

4.1.CARACTERISTICI

Se vor prezenta în continuare posibilitãtile majore furnizate de limbaj, împreunã cu caracteristicile care îl deosebesc de celelalte limbaje de descriere hardware.

Limbajul poate fi folosit ca un mediu de interacþiune între distribuitorii de cip-uri si utilizatorii instrumentelor CAD (computer-aided design). Diferiti distribuitori de cip-uri pot sã furnizeze descrieri VHDL ale componentelor lor proiectantilor de sisteme. Utilizatorii instrumentelor CAD îl pot folosi pentru a capta comportamentul proiectului la un înalt nivel de abstractizare pentru simulare functionalã.

Limbajul poate fi folosit si ca un mediu de comunicare între diferite instrumente CAD si CAE (computer-aided engineering). De exemplu, un program de captare schematicã poate fi folosit pentru a genera o descriere VHDL a proiectului, care poate fi folosit ca intrare pentru un program de simulare.

Limbajul permite ierarhii, ceea ce înseamnã cã un sistem digital poate fi modelat ca un set de componente interconectate; fiecare componentã, la rândul sãu, poate fi modelatã ca un set de subcomponente interconectate.

Limbajul permite o metodologie de proiectare flexibilã: de sus în jos, de jos în sus sau mixt.

Limbajul nu este specific unei anumite tehnologii, dar poate suporta caracteristici specifice unei anumite tehnologii; de asemenea, poate suporta tehnologii hardware variate; de exemplu, se pot defini noi tipuri logice si noi componente sau se pot preciza atribute specifice unei anumite tehnologii. Fiind independent tehnologic, acelasi model poate fi sintetizat în librãrii ale unor distribuitori diferiti.

El permite modele cu temporizare atât sincronã, cât si asincronã.

Diferite tehnici de modelare digitalã, cum ar fi descrieri de masini cu stãri finite, descrieri algoritmice sau ecuatii booleene, pot fi utilizate prin intermediul acestui limbaj.

Limbajul este disponibil publicului, lizibil uman, lizibil pentru masini si, mai ales, nu este brevetat.

Este un standard IEEE si ANSI; de aceea, modelele descrise folosind acest limbaj sunt portabile.

Limbajul permite trei stiluri de baza diferite de descriere: structural, prin flux de date, respectiv comportamental. Un proiect poate fi realizat în orice combinatie a acestor trei stiluri descriptive.

El suportã un domeniu larg de nivele de abstractizare, extinzîndu-se de la descrieri comportamentale abstracte pânã la descrieri foarte precise la nivel de poartã. Totusi, nu permite modelãri la nivel de tranzistor sau mai jos de acest nivel. Oferã posibilitatea ca un proiect sã fie captat la un nivel mixt utilizînd un limbaj coerent unic.

Utilizînd acest limbaj pot fi modelate proiecte de dimensiuni arbitrare, neexistînd limitãri impuse de limbaj în ceea ce priveste dimensiunea unui proiect.

Existã elemente în cadrul limbajului care faciliteazã modelarea proiectelor pe scarã largã ; de exemplu, componente, functii, proceduri, pachete (“packages”).

Pot fi scrise bãnci de test utilizînd acelasi limbaj pentru a testa alte modelãri VHDL.

Intârzierile de propagare nominale, întârzierile minimale si maximale, temporizarea de setare si mentinere, constrângerile de temporizare si detectia vârfurilor pot fi descrise foarte natural în acest limbaj.

Se pot utiliza generice si atribute pentru informatii statice sau în descrierea unor proiecte parametrizate .

O modelare poate sã descrie nu doar functionalitatea proiectului, ci poate sã continã informatii chiar despre proiect prin atribute definite de utilizator, cum ar fi suprafata totalã si viteza.

Pentru a descrie componente ale unor librãrii de la diferiti distribuitori se poate utiliza un limbaj comun. Instrumente care înteleg modelãri VHDL nu vor avea dificultãti în citirea de modelãri de la o varietate de distribuitori atâta timp cât limbajul este un standard.

Modelãrile scrise în acest limbaj pot fi verificate prin simulare deoarece sunt definite semantici precise de simulare pentru fiecare constructie a limbajului.

Modelãri comportamentale care corespund unui anumit stil de descriere de sintezã permit sinteza în descrieri la nivel de poartã.

Posibilitatea de a defini noi tipuri de date permite descrierea si simularea unei noi tehnici de proiectare la un înalt nivel de abstractizare fãrã nici o grijã în ceea ce priveste detaliile de implementare.

Abstractizari hardware: VHDL este folosit în descrierea unui model pentru un dispozitiv hardware digital. Acest model specificã imaginea externã a dispozitivului si una sau mai multe imagini interne. Imaginea internã a dispozitivului specificã functionalitatea sau structura, pe când imaginea externã specificã interfata prin care dispozitivul comunicã cu celelalte modele din mediul sãu.

In VHDL, fiecare model de dispozitiv este tratat ca o reprezentare distinctã a unui dispozitiv unic, numit în textul modelãrii entity. Pot exista modelãri multiple ale unui dispozitiv, fiecare model de dispozitiv reprezentînd o entitate distinctã din punctul de vedere al VHDL, desi în realitate ele reprezintã acelasi dispozitiv hardware.

Entitatea este astfel o abstractizare hardware a disozitivului hardware actual. Fiecare entitate este descrisã folosind un model, care conþine o imagine externã si una sau mai multe imagini interne. In acelasi timp, un dispozitiv hardware poate fi reprezentat de una sau mai multe entitãti.

4.2. ELEMENTE DE BAZA ALE LIMBAJULUI

Asa cum s-a mentionat anterior, sistemele digitale modelate prin descrieri VHDL pot fi de complexitate variabilã, de la o simplã poartã logicã pânã la un sistem electronic complet. O abstractizare hardware a sistemului se numeste entitate. O entitate X, atunci când este folositã într-o altã entitate Y, devine componentã a entitãtii Y. De aceea, o componentã este de asemenea o entitate, în functie de nivelul la care se încearcã modelarea.

Pentru descrierea unei entitãti, VHDL prezintã cinci tipuri distincte de constructii de bazã, numite unitãti de proiectare. Acestea sunt:

1. Declaratia de entitate

2. Corpul arhitecturii

3. Declaratia de configuratie

4. Declaratia de pachet

5. Corpul pachetului

O entitate este modelatã folosind o declaratie de entitate si cel putin un corp de arhitecturã. Declaratia de entitate descrie imaginea externã a entitãtii (de exemplu, numele porturilor de intrare si de iesire), iar corpul arhitecturii contine descrierea internã a entitãii. O declaratie de configuratie este utilizatã pentru a crea o configuratie pentru o entitate. Aceasta specificã alegerea unui corp de arhitecturã din mai multe corpuri de arhitecturã care pot fi asociate cu o entitate. Ea poate specifica de asemenea legãtura dintre componentele utilizate în corpul arhitecturii selectate cu alte entitãti. O entitate poate avea oricâte configuratii distincte.

Odatã ce o entitate a fost modelatã, ea trebuie sã fie validatã de sistemul VHDL. Un sistem VHDL tipic constã dintr-un analizor si un simulator.

Analizorul preia una sau mai multe unitãti de proiectare conþinute într-un singur fisier si le compileazã într-o librãrie de proiectare, dupã validarea sintaxei si parcurgerea unor verificãri de semanticã. Librãria de proiectare este o zonã din mediul gazdã (mediul ce suportã sistemul VHDL) în care sunt stocate unitãtile de proiectare compilate.

O entitate este simulatã de cãtre simulator, ea fiind reprezentatã de o pereche entitate-arhitecturã sau de o configuratie. Simularea se realizeazã preluîndu-se descrierea compilatã din librãria de proiectare si apoi parcurgîndu-se urmãtorii pasi:

1. Elaborare

2. Initializare

3. Simulare

4.3. STILURI DE MODELARE

Detaliile interne ale unei entitãti sunt specificate în corpul unei arhitecturi utilizînd apelînd la oricare dintre urmãtoarele stiluri de modelare:

1. Ca un set de componente interconectate (pentru a reprezenta structura)

2. Ca un set de instructiuni de asignare concurente (pentru a reprezenta fluxul de date)

3. Ca un set de instructiuni de asignare secventiale (pentru a reprezenta comportamentul)

4. Ca o combinatie oarecare a celor trei de mai sus.

MODELARE PRIN FLUX DE DATE

In acest stil de modelare, fluxul de date prin entitate este exprimat folosind instructiuni concurente de asignare de semnale. Structura entitãtii nu este explicit specificatã, dar ea poate fi dedusã implicit. Un exemplu de arhitecturã care utilizeazã acest model este:

architecture A_HALFADD of HALFADD is

begin

SUM<=A xor B after 8 ns;

CARRY<=A and B after 4 ns;

end A_HALFADD;

Acest model este descris folosind douã instructiuni concurente de asignare de semnale. Intr-o astfel de instructiune, simbolul “<=” implicã asignarea unei valori la un semnal. Valoarea expresiei din partea dreaptã a instructiunii este calculatã si asignatã semnalului din partea stângã, numit semnal tintã. O instructiune concurentã de asignare de semnal este executatã doar atunci când oricare dintre semnalele folosite în partea stângã prezintã un eveniment, ceea ce înseamnã cã valoarea semnalului se schimbã.

Informatiile de întârziere de propagare sunt incluse în instructiunile de asignare de semnal utilizînd clauze after.

Instructiunile de asignare de semnale fiind concurente, ordinea în care acestea apar în corpul arhitecturii nu este importantã. Semantica acestei comportãri concurente indicã faptul cã simularea este dependentã de evenimente si cã timpul simulãrii avanseazã la urmãtoarea unitate de timp când un eveniment este programat sã survinã.

MODELARE COMPORTAMENTALA

Spre deosebire de stilul de modelare prin flux de date, a cãrui prezentare generalã s-a fãcut anterior, modelarea comportamentalã precizeazã comportarea unei entitãti printr-un set de instructiuni care sunt executate secvential într-o ordine specificatã. Acest set de instructiuni secventiale, care sunt specificate în interiorul unei declaratii de proces, nu specificã explicit structura entitãtii, ci doar functionalitatea sa. O declaratie de proces este o declaratie concurentã care poate sã aparã în interiorul corpului unei arhitecturi.

Cuvântul cheie process este urmat de o listã de semnale, specificate între paranteze, aceasta numindu-se lista de senzitivitate a semnalului. Declaratia de proces este apelatã ori de câte ori survine un eveniment pe oricare dintre semnalele din aceastã listã.

In partea declarativã a declaratiei de proces apar si variabile, acestea diferind substantial de semnale prin faptul cã li se asigneazã valori instantaneu, spre deosebire de semnale cãrora întotdeauna li se asigneazã valori cu o anumitã întârziere (specificatã de utilizator sau asa-numita întârziere delta, care este întârzierea implicitã). Pentru a asigna valori variabilelor se utlizeazã operatorul de atribuire :=, iar pentru semnale este utilizat simbolul compus <=. Variabilele declarate în interiorul unui proces au domeniul limitat la acel proces.

Asignãrile de semnale se executã secvential independent sau dacã un eveniment survine pe oricare dintre semnalele din expresia din partea dreaptã a instructiunii de asignare.

Un proces poate sã nu continã o listã de senzitivitate explicitã, dacã în interiorul sãu existã instructiuni wait. Este important de retinut cã un proces nu se terminã niciodatã. Intotdeauna este ori în executie, ori suspendat. Toate procesele sunt executate o datã pe parcursul fazei de initializare a simulãrii, înainte de a fi suspendate. De aceea, un proces fãrã listã de senzitivitate si fãrã instructiuni wait nu se va suspenda niciodatã.

In subcapitolul urmãtor se va prezenta mai pe larg stilul de modelare care este de fapt rezultatul acestui proiect, modelarea structuralã.

MODELARE MIXTA

Este posibilã aparitia tuturor celor trei stiluri de modelare prezentate anterior în corpul unei singure arhitecturi. Astfel, în corpul unei arhitecturi se pot utiliza instructiuni de initializare (care reprezintã structura), instructiuni secventiale de asignare de semnale (reprezentînd flux de date), respectiv declaratii de proces (reprezentînd comportamentul).

4.4. MODELARE STRUCTURALÃ

Intr-o descriere structuralã, o entitate este modelatã ca un set de componente conectate prin semnale. Comportamentul unei entitãti nu rezultã explicit din modelarea sa. Instantierile componentelor reprezintã mecanismul primar pentru a descrie un astfel de model de entitate.

O componentã instantiatã într-o descriere structuralã trebuie mai întâi sã fie declaratã printr-o declaratie de componentã. O astfel de declaratie cuprinde numele si interfata componentei. Interfata specificã modul si tipul porturilor. Sintaxa unei declaratii de componentã într-o formã simplã este :

component component_name [is]

[port (list_of_interface_ports) ;]

end component [component_name];

Numele componentei poate sã facã referintã sau nu la numele unei entitãti existente deja într-o librãrie. Dacã nu face o astfel de referintã, el trebuie asociat explicit unei entitãti; altfel modelul nu poate fi simulat (modelul poate fi totusi analizat). Informatia de legãturã poate fi specificatã folosind o configuratie, despre configuratii se vor da detalii ulterior.

Lista porturilor de interfatã specificã numele, modul si tipul pentru fiecare port al componentei într-o manierã similarã celei specificate într-o declaratie de entitate. Numele porturilor pot fi de asemenea diferite de numele porturilor entitatii asociate (nume diferite de porturi pot fi mapate într-o configuratie). Declaratiile de componente apar în partea declarativã a corpului unei arhitecturi. Alternativ, ele mai pot sã aparã în declaratia unui pachet. Elementele declarate într-un pachet pot deveni vizibile în corpul oricãrei arhitecturi utilizînd clauzele library ºi use. Avantajul acestui concept este cã pachetul poate fi folosit în comun de alte unitãti de proiectare si aceste declaratii de componente nu mai trebuie sã fie specificate în fiecare unitate de proiectare.

O instantiere de componentã defineste o subcomponentã a entitãtii în care apare. Ea asociazã semnalele din entitate cu porturile acelei subcomponente. Formatul unei instantieri de componentã este:

component_label: component_name [port map (association_list)]

Eticheta componentei poate fi orice identificator legal si poate fi consideratã ca numele unei instante. Numele componentei trebuie sã fie numele componentei declarate mai înainte printr-o declaratie de componentã. Lista de asociere asociazã semnalele în entitate, acestea fiind numite parametri actuali, cu porturile componentei, numite parametri formali. Un parametru actual poate fi un semnal. Un parametru actual pentru un port de intrare poate fi si o expresie. De asemenea, un parametru actual poate fi cuvântul cheie open pentru a indica un port care nu este conectat.

Existã douã moduri de a realiza asocierea parametrilor formali cu cei actuali: asociere pozitionalã, respectiv asociere de nume.

In asocierea pozitionalã, o listã de asociere este de forma:

actual_1, actual_2,…, actual_n

Fiecare parametru actual în instantierea componentei este asociat dupã pozitie cu portul corespondent în declaratia de componentã. Astfel, primul port din declaratia componentei corespunde primului parametru actual din instantierea componentei, al doilea port celui de-al doilea parametru actual s.a.m.d. De aceea, ordonarea parametrilor actuali este importantã.

Dacã un port din instantierea componentei nu este conectat la nici un

CAPITOLUL 5

PREZENTAREA PROGRAMULUI

5.1. ELEMENTE INTRODUCTIVE

Proiectul consta intr-un program realizat in limbajul Visual C++4, fiind utilizata biblioteca de clase MFC (Microsoft Foundation Classes). Aceasta biblioteca este construita plecand de la modelul de programare Document/View. Mediul Developer Studio din Visual C++ include un instrument folosit pentru crearea unei aplicatii “schelet”, acest instrument fiind asa-numitul “vrajitor” de aplicatii, AppWizard. Utilizarea acestui instrument pentru crearea codului de baza intr-un program reprezinta cea mai rapida modalitate de scriere a programelor in maniera Document/View.

Ideea de baza a arhitecturii Document/View este separarea claselor de manipulare a datelor de clasele care trateaza interfata cu utilizatorul. Aceasta separare permite fiecarei clase sa se concentreze asupra efectuarii unei singure sarcini, cu un set de interfete definite pentru interactiunea cu celelalte clase implicate in program.

AppWizard pune la dispozitia utilizatorului mai multe tipuri de programe generice, acest proiect fiind realizat ca Multiple Document (MDI), adica un program care poate controla in acelasi timp mai multe documente diferite.

Denumirile variabilelor si ale functiilor respecta regula HN (Hungarian Notation) si conventiile MFC. Configurarea claselor utilizate in program si adaugarea de clase noi se realizeaza prin intermediul asa-numitului “vrajitor” de clase, ClassWizard. Aceasta facilitate contribuie la eliminarea erorilor la scrierea codului, deoarece cea mai mare parte a acestuia poate fi scrisa in mod automat. In plus, ClassWizard permite urmarirea si procesarea mesajelor de fereastra printr-un simplu clic.

5.2. DESCRIEREA PROGRAMULUI.

Programul genereaza, pe baza unei scheme proiectate de utilizator, un cod VHDL simulabil, corespunzator unei descrieri structurale a schemei respective.

Exista o librarie de entitati puse la dispozitia utilizatorului, care devin disponibile prin selectia optiunii “Load All Entities” din meniul “File”. Inserarea unei entitati in schema se face prin selectarea optiunii “Entity” din meniul “Insert” sau prin apasarea butonului “Entity” din bara de instrumente. Apasarea acestui buton are ca efect afisarea unei casete de dialog, care permite selectarea unei anumite entitati si a unei anumite arhitecturi pentru respectiva entitate, in cazul in care entitatea prezinta mai multe arhitecturi.

Porturile unei entitati pot avea trei moduri: IN, OUT, respectiv INOUT. Fiecare noua entitate va prezenta porturi proprii de interactiune cu exteriorul, diferite de porturile entitatilor componente. Inserarea unui port in schema se realizeaza prin selectarea optiunii “Port” din meniul “Insert” sau prin apasarea butonului “Port” din bara de instrumente. Aceasta va avea ca efect afisarea unei casete de dialog prin care utilizatorul poate selecta: numele portului, implicit un sir de caractere sugerind modul ultimului port inserat in schema si un numar corespunzator numarului de porturi cu acel mod inserate in schema pana in acel moment; modul portului respectiv (IN, OUT, INOUT), cu doua optiuni pentru sens, astfel incat schema sa fie desenata optim; tipul portului (BOOL, INT, REAL sau un tip definit de utilizator, restrictii in acest sens aparind doar la conectarea porturilor).

Porturile, atat cele interne apartinind unor entitati componente, cat si cele externe, se conecteaza prin semnale..

Entitatile, porturile si semnalele sunt obiecte ale claselor CEntity, CPort, respectiv CSignal, acestea fiind clase derivate din clasa de baza CObject, care defineste toate interfetele folosite la serializarea obiectelor in sau dintr-un obiect CArchive.

Programul mai permite selectarea optiunilor “Grid”, “Zoom In” si “Zoom Out”, reprezentind facilitatile de afisare a grilei, de micsorare, respectiv de marire a schemei .

Dupa inserarea tuturor entitatilor componente necesare, a tuturor porturilor de interactiune cu exteriorul si dupa trasarea semnalelor corespunzator conexiunilor preconizate in schema, utilizatorul poate declansa generarea automata a codului VHDL pentru schema proiectata.

Declararea entitatii cuprinde, pe langa numele acesteia, lista porturilor sale externe. In lista porturilor, al carei inceput este marcat prin cuvantul cheie PORT, sunt precizate pentru fiecare port numele, modul si tipul. Porturile de acelasi mod si tip sunt grupate impreuna, precizindu-se distinct doar numele lor.

Descrierea arhitecturii consta, pe langa numele arhitecturii, intr-o declarare a listei de semnale care realizeaza conexiunile dintre porturi cu precizarea tipului pentru aceste semnale, urmata de o lista de componente ale entitatii, inceputul acestei liste fiind marcat de cuvantul cheie COMPONENT. Pentru fiecare entitate componenta sunt precizate porturile externe corespunzatoare. Corpul arhitecturii incepe prin cuvantul cheie BEGIN, urmat de lista componentelor propriu-zise, pentru fiecare dintre acestea fiind precizat tipul (cu semnificatia anterior mentionata) si o harta a porturilor in care fiecare port este asociat unui semnal. Inainte de a se inchide corpul arhitecturii, fiecare semnal din lista de semnale este asociat cu unul sau mai multe porturi ale noii entitati.

In configuratia noii entitati, pentru fiecare arhitectura posibila a entitatii si pentru fiecare componenta a arhitecturii curente se precizeaza tipul componentei si arhitectura aleasa.

Codul VHDL astfel generat va fi acceptat de limbajul VHDL si pentru fiecare port de intrare al unei entitati se pot asigna valori. Se declanseaza o analizare a componentelor, apoi a intregii entitati, dupa care se poate declansa simularea.

5.3.EDITAREA SI GESTIONAREA SCHEMEI LOGICE

Editarea si gestionarea schemei logice se realizeaza in Limbajul

Visual C++ pentru programarea sub Windows.

In VHDL entitatea (“entity”) este unitatea fundamentala de proiectare. Fiind considerata un “black-box”, ea este specificata prin nume si prin legaturile cu exteriorul, reprezentate de porturi.

Limbajul VHDL permite ierarhii, ceea ce inseamna ca un sistem digital poate fi modelat ca un set de componente interconectate; fiecare componenta, la randul sau, poate fi modelata ca un subset de componente interconectate.

In proiectul prezentat, folosim descriera structurala a limbajului VHDL, unde o entitate este modelata ca un set de componente conectate prin semnale.

Pornind de la aceste carecteristici ale limbajului VHDL, se construiesc structurile de date : “Entity”, “Port”, “Signal”, fiind colectii de tip lista CObList, clasa oferita de MFC.

Structura de date entitate:

In figura, se arata structura interna o unei entitati: o lista de entitati componente si o lista de porturi interne, care comunica intre ele printr-o lista de semnale.

Ierarhic, o noua entitate se construieste folosind o lista de entitati, componentele noii entitati, si o lista de porturi, care reprezinta comunicarea cu exteriorul. Legaturile: porturi – entitati si entitate- entitate, se realizeaza prin semnale.

Initial exista o biblioteca predefinita de entitati, care va fi completata cu noi entitati construite pe baza celor initiale.

Entitatea este implementata de catre clasa “CEntity”, clasa derivata din CObject, unde se definesc urmatoarele operatii:

AddPort(); – auduga la lista tuturor porturilor noul port introdus, actualizind in acelasi timp si numarul de porturi.

Draw(); -realizeaza efectiv desenarea entitatii.

Calc(); -se calculeaza dimensiunea entitatii, tinind cont de dimensiunea grid-ului (facilitate oferita de program).

FindPort(); -Cauta si returneaza portul pe care ma aflu cu mouse-ul.

SetLPortPos(); -Folosita in functia Draw(), pentru a seta pozitile porturilor entitatii, din lista de porturi.

Serialize(); -Functia ofera posibilitatea de salvare intr-un fisier si refolosire.

Clasa CPort, derivata di CObject, implementeaza structura de date “Port”. Penrtu un port se precizeaza modul, care poate fi IN, OUT, sau INOUT, tipul si numele portului.

Exista posibilitatea de a alege intre un port (TIP_BIT) care se conecteaza cu alte porturi printr-un singur semnal, si o magistrala pe 8 biti (TIP_BYTE). Iar un port are intotdeauna o referinta la semnal.

Structura de date “Signal” este implementata folosind clasa derivata din CObject, CSignal. Un semnal este realizat pe segmente, folosind in acest scop un tablou de segmente de dimensiune 100. Iar in vederea trasarii semnalului se retine un pointer la primul port, si un pointer la ultimul port.

Gestionare acestor structuri se realizeaza in clasa de vizualizare a programului CGenView.

Modul in care entitatile componente si porturile comunica intre ele prin semnale se prezinta in urmatoarea figura:

CAP.6

REZULTATE

Se prezinta etapele:

Construire schema – generare cod VHDL – simularea codului generat.

Folosind facilitatile oferite de program se construieste o schema reprezentand un “Half Adder”, folosind entitatile componente “and_gate” si “sae” reprezentind portile logice “SI” si ”XOR”. In vederea simularii, se va genera intr-o prima faza codul VHDL corespunzator schemei. Acesta este preluat de VHDL, realizindu-se simularea proprizisa.

Figure 1. Half_adder

ENTITY half IS

PORT( i1, i2 : IN bit ;

sum, carry : OUT bit );

END half;

ARCHITECTURE Ahalf OF half IS

SIGNAL sig1, sig2, sig3, sig4 : bit ;

COMPONENT and_gate

PORT( c : OUT bit ;

a, b : IN bit );

END COMPONENT;

COMPONENT sae

PORT( c : OUT bit ;

a0, a1 : IN bit );

END COMPONENT;

BEGIN

and_gate_2:and_gate

PORT MAP( b=>sig1, a=>sig2, c=>sig4);

sae_1:sae

PORT MAP( a1=>sig1, a0=>sig2, c=>sig3);

carry<=sig4;

sum<=sig3;

sig2<=i2;

sig1<=i1;

END Ahalf;

CONFIGURATION Chalf OF half IS

FOR Ahalf

FOR and_gate_2 :and_gate

USE ENTITY WORK.and_gate(asi);

END FOR;

FOR sae_1 :sae

USE ENTITY WORK.sae(sae_a);

END FOR;

END FOR;

END Chalf;

Figure 2. Generarea Codului VHDL corespunzator Half_adder-ului

CAPITOLUL 7

CONCLUZII

In acest proiect s-a incercat implementarea unei interfete grafice pentru limbajul VHDL cat mai sugestive si mai usor de utilizat, care sa fie disponibila in scop didactic.

In momentul in care s-a inceput elaborarea proiectului existau deja astfel de interfete grafice, realizate profesional de firme de software, dar achizitionarea acestora ar fi implicat costuri mari.

Proiectul poate fi imbunatatit ulterior prin extinderea setului de facilitati oferite, pentru o utilizare cat mai eficienta a complexitatii limbajului VHDL.

De exemplu, se poate încerca generarea automatã a unui cod care sã reprezinte o modelare comportamentalã sau prin flux de date.

BIBLIOGRAFIE

1. M. STRATULAT–”Tehnica impulsurilor”, vol.I si vol.II

2. J. ASHENDEN–”The VHDL Cookbook”, Dept. Computer Science, University of Adelaide, South Australia 1990

3. J. BHASKER–”A VHDL Primer”, Prentice Hall PTR, Englewood Cliffs, New Jersey

4. M. WILLIAMS–”Bazele Visual C++ 4”, Ed. Teora

Bucuresti 1997