Eindhoven University of Technology MASTER Analyse en ... · Analyse en implementatie van IDaSS...

Eindhoven University of Technology

MASTER

Analyse en implementatie van IDaSS bouwstenen in VHDL

Peerbooms, M.J.M.

Award date:1991

Link to publication

DisclaimerThis document contains a student thesis (bachelor's or master's), as authored by a student at Eindhoven University of Technology. Studenttheses are made available in the TU/e repository upon obtaining the required degree. The grade received is not published on the documentas presented in the repository. The required complexity or quality of research of student theses may vary by program, and the requiredminimum study period may vary in duration.

General rightsCopyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright ownersand it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights.

• Users may download and print one copy of any publication from the public portal for the purpose of private study or research. • You may not further distribute the material or use it for any profit-making activity or commercial gain

Auteur

Titel

Type

Technische Universiteit Eindhoven

Faculteit der Elektrotechniek

Vrije Studierichting der Informatietechniek

Marc Peerbooms

Analyse en implementatie van IDaSS

bouwstenen in VHDL

Afstudeerverslag 3 oktober 1991.

Afstudeerhoogleraar:

Coach:

Prof. M.P.J. Stevens

Ing. P.H.A. van der Putten

Ir. F.P.M. Budzelaar

The departement of Electrical Engineering of the Eindhoven University of Technology does not accept any

responsibility regarding the contents of student project or graduation reports.

Samenvatting

Het ontwerpen van een digitaal I.e. kan men zien als een traject tussen een beginpunt

(het idee) en een eindpunt (de implementatie). Er lopen meerdere paden tussen begin

en eindpunt. Zo kunnen er verschillende strategieen worden gevolgd (TOP-DOWN,

BOTTUM-UP) en kunnen bij bepaalde strategieen verschillende tools worden gebruikt.

Ben van die tools is de hardware beschrijvingstaal VHDL. Met behulp van deze tool

komt men vanuit het oorspronkelijke idee na verloop van tijd op een structuur

(beschrijving) van basis bouwstenen, waarvan de correctheid door verificatie/simulatie

is aangetoond. Deze structuur van basis bouwstenen (waarvan de elementen in een

library zijn opgeslagen) is automatisch om te zetten in een bruikbare layout.

Een andere tool die kan worden gebruikt is het Interactive Design and Simulation

System (IDaSS). Ook hiermee komt men na verloop van tijd op een structuur van basis

bouwstenen, waarvan de correctheid door simulatie is aangetoond. De directe koppeling

naar een realisatie/layout is hier echter nog niet aanwezig.

Deze koppeling zou tot stand kunnen worden gebracht indien wordt gepoogd om van de

basis bouwstenen in IDaSS een beschrijving te genereren in VHDL. In dit verslag wordt

hiertoe een eerste aanzet gedaan. Moeilijkheid hierbij is, dat de basis bouwstenen in

IDaSS een relatief hoog niveau van abstractie hebben en dat implementatie van basis

bouwstenen applicatie - afhankelijk is.

Er is een analyse gedaan van enkele RAM architecturen alsmede een LIFO (queue) en

een FIFO (stack). Daarnaast werd een VHDL - beschrijving gemaakt en getest van deLIFO.

Lijst van figuren

Lijst van figuren

Figuur 2.1. Modellering Hatley & Pirbhai . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Figuur 2.2. Link tussen H&P en VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Figuur 3.1. IDaSS bouwsteen: RAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Figuur 3.2. IDaSS bouwsteen: ROM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Figuur 3.3. IDaSS bouwsteen: LIFO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Figuur 3.4. IDaSS bouwsteen: FIFO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Figuur 3.5. IDaSS bouwsteen: CAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Figuur 4.1. Synchroon en Asynchroon RAM . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Figuur 4.2. IDaSS model van een RAM 22

Figuur 4.3. Eenvoudig model RAM 23

Figuur 4.4. Arch. RAM Single write single read, WA < > RA 24

Figuur 4.5. Basismodel RAM met Busy signalen . . . . . . . . . . . . . . . . . . . . . . . . 25

Figuur 4.6. Basis architectuur RAM, sequentiele oplossing 25

Figuur 4.7. Structuur van de arbiter 27

Figuur 4.8. FSM diagram seq. oplossing 27

Figuur 4.9. Architectuur registered oplossing 29

Figuur 4.10. State diagram registered oplossing . . . . . . . . . . . . . . . . . . . . . . . . . 29

Figuur 4.11. Blokdiagram Registered oplossing . . . . . . . . . . . . . . . . . . . . . . . . . 30

Figuur 4.12. Volledig parallel met schakelnetwerk. 31

Figuur 4.13. Volledig parallel, gecascadeerd 32

Figuur 4.14. Volledig seriele oplossing 33

Figuur 4.15. Model bestaand LIFO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Figuur 4.16. IDaSS model van LIFO 35

Figuur 4.17. Lifo met IdaSS functies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Figuur 4.18. Interne structuur LIFO 37

Figuur 4.19. Blokschema van LIFO met extra leespoort 38

Figuur 4.20. Architectuur van LIFO met extra leespoort . . . . . . . . . . . . . . . . . . 39

Figuur 4.21. Basisvoorstelling FIFO 40

Figuur 4.22. Architectuur eenvoudig FIFO 41

Figuur 4.23. Echte architectuur FIFO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Figuur 4.24. Model FIFO met extra leespoort . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Figuur 5.1. Ontwerp traject in de implementatie - fase. . . . . . . . . . . . . . . . . . . . 45

Figuur 5.2. Hierarchie in VHDL - beschrijving . . . . . . . . . . . . . . . . . . . . . . . . . 46

1

Lijst van figuren

Figuur 5.3. NetedjSymed hierarchie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Figuur 5.4. Ret systeem in zijn omgeving 48

Figuur 5.5. Blokschema geheugenjregister structuur . . . . . . . . . . . . . . . . . . . . . 52

Figuur 5.6. Geheugenblok 53

Figuur 5.7. Geheugenelement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Figuur 5.8. Register_Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Figuur 5.9. Schrijf selectie blok (Wr_Sel) 59

Figuur 5.10. Geheugencel (Ramcel) 60

Figuur 5.11. Lees selectie blok (Rd_Sel) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Figuur 5.12. Register 61

Figuur 5.13. Schakelmatrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

Figuur 5.14. Control functie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Figuur 5.15. Decoder_Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Figuur 5.16. Principe van overall timing 67

Figuur 5.17. Timing Memory_Block 68

Figuur 5.18. Timing register blok 69

Figuur 5.19. Timing Decoder_Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

ii

Lijst van tabellen

Lijst van Tabellen

Tabel I. Modelvergelijking RAM's 21

Tabel II. Uitgangssignalen per state 28

Tabel III. Bepaling TOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Tabel IV. Operaties en TOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Tabel V. Schrijven bussen bij verschillende operaties . . . . . . . . . . . . . . . . . . . . . 56

Tabel VI. Waarheidstabel Rd Sel blok . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Tabel VII. Selectietabel 64

Tabel VIII. Waarheidstabel Cnt_Opcode 65

Tabel IX. Waarheidstabel fe}ogica 66

Tabel X. Waarheidstabel adres decoder 66

111

--------------------- Inhoudsopgave

Inhondsopgave

1. Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2. Modelleringsmethoden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.1. Methode van beschrijven van Hatley & Pirbhai. . . . . . . . . . . . . . . . . . 2

2.2. VHDL beschrijving 4

2.3. De link 4

2.4. Problemen en conclusies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3. IDaSS Basis Bouwstenen 7

3.1. Overzicht IDaSS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.2. RAM 9

3.3. ROM 11

3.4. LIFO 12

3.5. FIFO 14

3.6. CAM 16

4. Hardware structuren. 17

4.1. Het multi - ported probleem. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.2. Model van bestaande RAM - architecturen 19

4.3. Model van een 'ideaal' RAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.4. Ram: Single Read, Single Write RA < > WA 23

4.5. RAM; Single write, Single read, toegestaan: WA = RA . . . . . . . . . . 24

4.5.1. Sequentiele oplossing 25

4.5.2. Registered 28

4.5.3. Forced Output Oplossing 30

4.6. Meerdere poorten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.6.1. Volledig parallel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.6.2. Volledig sequentiele oplossing 32

4.7. Model bestaande LIFO 34

4.8. LIFO met IDaSS functies 36

4.9. LIFO met extra leespoort 38

4.10. Eenvoudig FIFO 40

IV

--------------------- Inhoudsopgave"

4.11. FIFO met extra schrijfpoort.

5. VHDL Implementatie LIFO .

5.1. Het ontwerptraject. .

5.2. De ontwikkelomgeving. . .

5.3. Niveau O......................••.............•........

5.4. Niveau 1 .

5.4.1. Voorwaarden - controle .

5.4.2. Geheugen functie. . .

5.4.3. Controle - functie. . .

5.5. Niveau 2 .

5.5.1. Geheugen - functie .

5.5.1.1. Schrijf selectie blok .

5.5.1.2. Geheugencel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.5.1.3. Lees selectie blok .

4.5.1.4. Registers. . .

5.5.1.5. Schakelmatrix .

5.5.2. Control functie .

5.5.2.1. Counter .

5.5.2.2. Fe_Logic .

5.5.2.3. Adres decoder .

5.6. Timing

6. Tests .

43

44

44

45

474851

52

57

57

57

59596061

626364

65

65

67

70

7. Conclusies . .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. 72

Literatuur 73

Appendices

v

Inleiding

1. Inleiding

De laatste fase van een studie elektrotechniek/informatietechniek aan de Technische

Universiteit Eindhoven bestaat uit het volbrengen van een afstudeerproject. Zo'n

afstudeerproject kan worden volbracht binnen een van de vakgroepen van de faculteiten

Elektrotechniek of Wiskunde & Informatica. De duur van zo'n project omvat minimaal

26 weken. Dit project werd uitgevoerd binnen de vakgroep Digitale Systemen (EB) van

de faculteit elektrotechniek.

Binnen de vakgroep Digitale Systemen houdt men zich o.m. bezig met het gestructureerd

ontwerpen van digitale ic's. Dit houdt in dat, via een top - down methode, de

functionaliteit van een bepaald ontwerp wordt gesplitst in steeds kleiner wordende

deelontwerpen. Dit proces wordt voortgezet totdat men op het niveau van bibliotheek

elementen uitkomt.

Een van de tools (op hoog niveau) die wordt gebruikt binnen de vakgroep is het IDaSS

pakket. Dit pakket biedt op interactieve wijze de mogelijkheden tot het ontwerpen en

simuleren van digitale systemen. Echter, het pakket gaat uit van een aantal basis

bouwstenen van relatief hoog (abstractie) niveau. Dit hoge niveau uit zich met name in

een multi - ported toegang tot de blokken (bouwstenen). De implementatie zelf is niet

het grootste probleem, echter weI dat er evenzovele oplossingen bestaan als er

applicaties zijn voor een blok.

Dit verslag zal een aantal geheugen elementen behandelen die IDaSS gebruikt, en er

wordt gepoogd, met het oog op voorgaande om zo universeel mogelijke ontwerpen terealiseren.

1

Modelleringsmethoden

2. Modelleringsmethoden

Er werd in het begin van mijn afstuderen gepoogd om met de modelleringsmethode van

Hatley en Pirbhai modellen te genereren van de IDaSS bouwstenen. Dit gaf echter

nauwelijks een bevredigend resultaat. In dit hoofdstuk wordt betoogd waarom de

methode voor dit onderwerp niet erg geeigend was. Om te kunnen begrijpen wat het

oorspronkelijke idee was en waarom dat idee 'faalde' beginnen we met een korte

beschrijving van de methode van Hatley & Pirbhai en van VHDL

2.1. METHODE VAN BESCHRIJVEN VAN HATLEY & PIRBHAI.

Bij het ontwerpen van complexe systemen, of dit nu Ie's zijn of grote systemen als

besturingen voor vliegtuigen, bestaat er in de beginfase het probleem om bepaalde

ideeen die een ontwerper heeft, concreet op papier te krijgen. De heren Hatley en

Pirbhai liepen ook tegen dit probleem aan en beschreven in hun boek 'Strategies for real

time system specification' een gestructureerde methode om ideeen op papier te zetten.

Zonder in teveel details te treden zullen we een korte beschrijving van de methode

geven.

De methode beschrijft twee belangrijke zaken. Ten eerste moet gedefinieerd worden wat

het systeem moet doen. Dit wordt vastgelegd in het requirements model. Ten tweede moet

worden gedefinieerd hoe het systeem gestructureerd moet worden. Dit staat beschreven

in het architectuur model.

De systeem requirements worden vastgelegd door een gelntegreerd model dat twee

aspecten van het systeem beschouwt: Er wordt een model gemaakt van het functionele

gedrag (informatie verwerking), en er wordt een control model gemaakt. Beide modellen

worden grafisch (met boIlen) weergegeven, en zijn hierarchisch van aard (figuur 2.1). Het

requirements model wordt opgesteld, onafhankelijk van latere implementatie - details.

De feitelijke functionaliteit van de afzonderlijke blokken is van primair belang.

Een en ander wil zeggen dat men begint met een beschrijving van het systeem op het

hoogste niveau. Hiervan wordt dus een functioneel (data context diagram) en een control

model (control context diagram) van gemaakt. Het top - level model beschrijft de

2

Data Flow


Control Flow

; .

t::: :::;.

n n·············:\~~~

Figuur 2.1. Modellering Hatley & Pirbhai

interactie van het systeem met zijn omgeving en wordt daarom ook weI context model

genoemd.

Daarna worden beide diagrammen opgesplitst in afzonderlijke functies. De control en

de data diagrammen tonen telkens de zelfde functionele bollen, aIleen de

informatiestromen zijn telkens anders. Hieruit blijkt dat het splitsen van het geheel in

twee modellen geen functionele waarde heeft, maar dat het slechts dient om de

overzichtelijkheid van de methode te vergroten.

Bij elke splitsing in deel functies moet ervoor worden gezorgd dat de beschrijving

consistent wordt gehouden, dat wi! zeggen dat er op een lager gelegen niveau precies

evenveel flows in en uit het geheel gaan als op een hoger niveau. Dit consistent houden

noemen we balanceren.

De hierarchie wordt voortgezet tot het niveau, waarin een bol met bepaalde

functionaliteit niet meer kan worden gesplitst in deel processen (functies). In dat geval

kan van zo'n bol een specificatie worden opgesteld omtrent zijn gedrag. Betreft het een

functie uit de data diagrammen, dan noemen we zo'n beschrijving een PSPEC. Betreft

het een functie uit de control diagrammen, dan spreken we van een CSPEC. Samengevat

bestaat een beschrijving m.b.v. de methode van Hatley en Pirbhai uit een

(gebalanceerde) boomachtige structuur van functies, waarbij de bladeren van de boom

3


zijn beschreven in een CSPEC of een PSPEC. De boomachtige structuur wordt grafisch

weergegeven, terwijl de data en control flows in een library zullen worden opgenomen.

In het architectuurmodel wordt beschreven welke functionele blokken bij elkaar horen,

en hoe deze zijn verbonden (elektrischejmechanischejoptische link). Ookworden bussen

gedefinieerd en structuur aangegeven. M.a.w. er wordt, eventueel technologie

afhankelijk aangegeven wat de architectuur van het te ontwerpen systeem zal worden.

Er wordt in het architectuurmodel gebruik gemaakt van de functionele blokken die

werden beschreven in het requirements model.

2.2. VHDL BESCHRIJVING

VHDL (VHSIC Hardware Description Language) is een beschrijvingstaal waarmee o.a.

digitale systemen kunnen worden beschreven. De taal is hierarchisch en kan werken met

een combinatie van gedrag- en structuurbeschrijvingen in een programmatekst. De TOP

DOWN ontwerpstrategie wordt hiermee goed ondersteund. Dientengevolge heeft de taal

wat betreft opbouw sterke overeenkomsten met de beschrijvingsmethode van Hatley en

Pirbhai.

In eerste instantie wordt een te ontwerpen systeem op hoog niveau functioneel

beschreven, zonder implementatie details te verwerken. Een ontwerp wordt hierna

geanalyseerd en gecontroleerd of het aan de gestelde eisen voldoet. (Vergelijk dit met

de Hatley & Pirbhai context diagrammen)

Deze beschrijving van het totale systeem kan worden verfijnd. Met elke stap in het

proces van verfijning worden meer implementatie details aangebracht terwijl de

abstractie steeds meer verdwijnt. Hogere niveaus zijn abstracties van de lagere (vgl

Hatley & Pirbhai). Bij een verfijning ( =VHDL beschrijving) bestaat uit een of meerdere

parallelle processen (of statements). Elk van die processen is dan weer een 'blok' met

sequentiele statements.

Tussen de verschillende niveaus van abstractie moet een 'link' worden gelegd, zodat een

simulator weet dat een bepaald blok verder is verfijnd in een andere beschrijving.

2.3. DE LINK

Zoals reeds in de vorige paragraaf werd opgemerkt hebben de methode van Hatley &

Pirbhai en de taal VHDL een vergelijkbare structuur. Het idee aan het begin van deze

afstudeeropdracht was dan ook (zie figuur 2.2) om uitgaande van de methode van Hatley

en Pirbhai een VHDL - beschrijving te genereren. De verbinding tussen beide methoden

4


zou dan als voIgt worden gelegd.

Indien men het oorspronkelijke systeem modelleert met Hatley en Pirbhai~ kan er als

voIgt een overstap naar VHDL worden gemaakt. De processen (die parallel opereren)

binnen H&P worden 'gelmplementeerd' d.m.v. componenten ofwel parallelle structuren

in VHDL. De PSPECs worden ge'implementeerd d.m.v. de sequentiele statements vanVHDL. Op deze manier is er dus een eenduidige relatie te leggen tussen de

beschrijvingsmethode van H&P en de beschrijvingstaal VHDL.

2.4. PROBLEMEN EN CONCLUSIES.

De gedachte die werd beschreven in de vorige paragraaf, werd ook toegepast op de

bouwstenen van IDaSS. Er werd een poging ondernomen om een RAM (met meerdere

poorten) te beschrijven in H&P. Er rezen echter een paar problemen. Hieronder staan

de conclusies aangaande deze problemen.

· De functionaliteit van de bouwstenen van IDaSS liet zich als geheel redelijk

goed beschrijven. Echter de IDaSS bouwstenen waren van redelijk eenvoudig

niveau, zodat echte deelfuncties niet of nauwelijks te onderscheiden waren. Dit

heeft tot gevolg dat een eventueel ge'introduceerde hierarchie al snel erg

geforceerd aandoet, als die al te realiseren is.

· Implementatiedetails die later weI in VHDL beschreven zullen worden zijn erg

moeilijk met de standaard methode te beschrijven. De methode van H&P is een

vrij grove methode. Als voorbeeld kan men nemen de uitwerking van

architecturen voor de RAM in hoofdstuk 4. In §4.5.1. tim 4.5.3 zijn architecturen

beschreven voor verschillende implementaties van een bouwsteen. In H&P zijn

dit soort kleine details zeer moeilijk aan te geven.

· Timing wordt binnen H&P slechts op het hoogste niveau beschouwd, terwijl

binnen VHDL zich ook interne timing problemen voordoen. Als voorbeeld

kunnen we de uitgewerkte LIFO van hoofdstuk 5 nemen. Deze is opgedeeld in

enkele functionele blokken. De uitgangen van sommige blokken zijn invoer voor

andere blokken. Hieraan zijn bepaalde timing - voorwaarden verbonden. Dezevoorwaarde zijn niet te beschrijven binnen H&P, aangezien daar alleen de timingop context niveau wordt beschouwd.

Samengevat kan men stellen dat de toepasbaarheid van de beschrijvingsmethode van

H&P zich voor grote ontwerpen reeds meermaals bewezen heeft. Voor kleine ontwerpen,

5


Parallelle Processen

::::::::::::::::> 810ck :Process:

Figuur 2.2. Link tussen H&P en VHDL

ParallelSequentieel

zoals de bouwstenen binnen IDaSS bleek de methode echter veel te grof en er werd

daarom van af gezien. (Overigens mag er bij vermeld worden dat ook de heren Hatley

en Pirbhai reeds in hun boek aangeven dat de methode vooral bedoeld is voor grote,

onoverzichtelijke ontwerpen).

De bouwstenen werden nu geanalyseerd met een soort ad hoc methode. Met het gezonde

verstand werden de verschillende bouwstenen geanalyseerd en beschreven. Daarbij werd

weI steeds een zelfde 'lijn' van beschrijven aangehouden om het overzicht intact tehouden

6

IDaSS Basis Bouwstenen

3. IDaSS Basis Bouwstenen

Het Interactive Design and Simulation System, kortweg IDaSS, is een interactieve, on

line ontwerp en simulatie omgeving voor digitale circuits. Het is een ontwikkeling van

ir. A. Verschueren van de vakgroep Digitale Systemen. am een volledig beeld te krijgen

van deze afstudeeropdracht is het wenselijk om inzicht te krijgen in de mogelijkheden

die het IDaSS pakket biedt. Daartoe dient voornamelijk de eerste paragraaf van dit

hoofdstuk. De volgende paragrafen beschrijven dan de bouwstenen die van belang zijn

voor nadere beschouwing in dit verslag.

3.1. OVERZICHT IDASS.

IDaSS is een pakket waarmee velerlei soorten digitale systemen kunnen worden

ontworpen en gesimuleerd. In hoofdzaak is het pakket echter bedoeld voor VLSI en

ULSI ontwerpen, met een voorkeur voor hardware die bedoeld is voor data processing.

Zowel synchrone ontwerpen als ook asynchrone ontwerpen zouden kunnen worden

ondersteund. Dat laatste is echter naar mijn memng met helemaal hard te maken, gezien

de mamer waarop asynchroniteit wordt gemodelleerd binnen IDaSS, maar daarover later

meer. Met de versie die werd beschouwd tijdens dit afstudeerwerk konden asynchrone

ontwerpen die interne terugkoppellussen bevatten nog met worden gesimuleerd omdat

de simulator binnen het pakket deze taak met ondersteunde.

Een ontwerp binnen IDaSS wordt beschreven als een hierarchie van schema's, met een

boomachtige structuur. Elk schema is opgebouwd uit een of meerdere elementen, die

grafisch ingevoerd dienen te worden. Voor het invoeren van de elementen wordt gebruik

gemaakt van de Smalltalk/V omgeving, die gebruikt kan worden op PC - AT klasse

computers.

De beschikbare elementen (bouwstenen/blokken) die binnen een schema kunnen worden

gebruikt zijn zullen kart worden genoemd. In het algemeen geldt voor alle blokken dat

zij een of meerdere functies kunnen uitvoeren, of zich in een (van meerdere) statekunnen bevinden.

1. Schema. Omdat IDaSS hierarchisch van aard is kunnen binnen een schema

complete andere schema's worden geplaatst. De diepte van de 'nesting' is hierbij

in principe ongelimiteerd. De bedoeling van deze hierarchische mamer van

7


beschrijven is het groeperen van andere blokken, zodat op deze manier een top

down ontwerp strategie wordt ondersteund.

2. State Machine Controller. Een state machine controller is een state machine,

die het gedrag van andere blokken binnen het schema kan bei'nvloeden. Een state

machine wordt beschreven door in een aparte taal een beschrijving van alle states

te geven.

3. Operator. De 'operators' modelleren alle asynchrone elementen binnen een

schema, en kunnen dus als blokje combinatorische logica worden beschouwd. Het

aantal inputs en outputs is in principe weer ongelimiteerd. Een operator kan

meerdere gebruiker gedefinieerde functies bevatten, maar kan er maar een

tegelijk uitvoeren.

4. Register. Dit blok modelleert een master/slave register met een maximale

breedte van 64 bits. Naast de gewone register - inhoud wordt ook een semafoor

bit bijgehouden, dat kan worden gebruikt voor synchronisatie - doeleinden bij

bijvoorbeeld implementatie van handshake protocollen e.d. Het bit wordt gezet

bij het laden van een waarde in het register en kan worden gereset m.b.v. een

speciale ingang.

S. Buffer. Dit blok modelleert een unidirectionele 3 - state bus buffer, waarbij

input en output bussen dezelfde breedte hebben.

6. Constant generator. Met dit blok kunnen constanten in het ontwerp worden

gei'njecteerd.

7. Geheugens. Deze groep van blokken komt in de volgende paragrafen nader aan

de orde. Gekozen kan worden uit:. RAM

. ROM

· CAM (Associatief geheugen)

· LIFO (Stack)

· FIFO (Queue)

Toch nog enige algemene opmerkingen betreffende geheugens in IDaSS. De

geheugen grootte is bij de huidige versie van IDaSS beperkt tot 2048 woorden,

van maximaal 64 bits breedte. Geheugens kunnen 'met de hand' worden gevuld

en meestal kan ook de waarde die een geheugen krijgt na een reset door de

gebruiker worden bepaald.

8


• Wll'i tIL.Addll'EoSSJ Read---.Addll'ess.J. •

• Data_InJ Data_OutJ

• Wll'i tEo---.Addll'EoSS...N Read---.Addll'ess-H •

• Data_In...N Data_Out-H

RAM

DatA_OutJixJ

Da.tA_OutJixJ(

Figuur 3.1. IDaSS bouwsteen: RAM

3.2. RAM

Het RAM in IDaSS modelleert een multiported Random Access Memory. In figuur 3.1

staat een typisch IDaSS RAM afgebeeld.

Lezen gebeurt asynchroon, de output voIgt direct op het aanbieden van een adres op een

adreslijn. Het aantallees- en schrijfpoorten is in principe ongelimiteerd. Er bestaan twee

soorten leespoorten:

* Leespoorten waaraan bij elke geheugen toegang een adres moet worden

meegegeven. Zo'n leespoort bestaat dus uit een adres ingang en een data uitgang.

Er kunnen onbepaald veel van dit soort poorten worden toegevoegd aan een

RAM in IDaSS. (Weergegeven met Read Address l..Read Address M resp- - - -Data Out l..Data Out M)- - --* Leespoorten, die zijn vastgelegd op een bepaald adres in het geheugen. Er hoeft

dus ook geen adres ingang aanwezig te zijn voor zo'n leespoort, slechts data

uitgangen (weergegeven met Data_Out_Fix_l..Data_Out_Fix_K)

Schrijven in het RAM gebeurt synchroon met de systeemklok. Ook het aantal

schrijfpoorten is ongelimiteerd.

. Schrijfpoorten bestaan uit een adres ingang en een data ingang. (weergegeven

door Write_Address_l..Write_Address_N resp. Data_In_1..Data_In_N).

De uitgaande signalen (dus Data_Out_l..M en Data_Out_Fix_l..K) zijn Of three - state

uitgangen of continuo

De schrijfpoorten krijgen een default attribuut mee, dat aangeeft of door deze poort

wordt geschreven bij de volgende klokslag of niet (write resp. nowrite). Het is mogelijk

door middel van de control ingang (weergegeven met Control_In) of tekstueel om een

poort een ander attribuut te geven gedurende de volgende klokslag. De control ingang

9


heeft een variabele breedte binnen IDaSS, en kan bestaan uit een enkele signaallijn, of,

en dat is logischer bij meerdere poorten een complete bus, waarover stuursignalen

worden gegeven. We zeggen dan ook dat een RAM de volgende commando's accepteert:

• write: Aile schrijfpoorten die default het nowrite attribuut hebben, krijgen

gedurende de volgende klokslag het write attribuut. Data van deze poorten wordt

dan bij de volgende klokslag in het geheugen gezet.

• write <poortnaam >: De schrijfpoort met de naam <poortnaam> die default

het attribuut nowrite moet hebben krijgt gedurende de volgende klokslag het

attribuut write. Dit modelleert een write - Hjn (fysisch) bij een schrijfpoort die

aangeeft dat data beschikbaar is en dat die in het geheugen gezet dient te

worden.

· nowrite: Analoog aan write. De data wordt nu niet geschreven

· nowrite <poortnaam >: analoog aan write <poortnaam >.

D.m.v. de control ingang kunnen ook de 3 - state poorten worden gestuurd.

Indien aan een RAM schrijf- of leespoorten worden toegevoegd, kan de gebruiker de

breedte van de adresbus opgeven. Deze breedte mag afwijken van de breedte die

noodzakelijk is om het gehele geheugen aan te spreken. Is de bus smaller, dan kan men

niet het gehele geheugen via die adresbus aanspreken. Is de bus breder dan produceert

IDaSS 'UNK' waarden voor plaatsen die niet in het geheugen zijn gedefinieerd.

10


Read~dd:ress:J •Data_OutJ

ROM

ReadJdd:ress~ •Data._OutJi

Figuur 3.2. IDaSS bouwsteen: ROM

3.3. ROM

Een ROM wordt binnen IDaSS gemodelleerd als een multiported Read Only Memory.

In figuur 3.2 staat een typisch IDaSS ROM afgebeeld.

Een ROM is een wezen een RAM waarop het niet mogelijk is om schrijfpoorten te

definieren. Daarnaast is en verschil met een RAM dat er maar een soort leespoort

bestaat, de adresseerbare leespoort. Deze bestaat net als bij een RAM uit een adres

ingang (weergegeven met Read_Address_l..Read_Address_N) en een data uitgang

(weergegeven met Data_Out_l..Data_Out_N).

Net als bij het RAM is er ook een control ingang aanwezig. Hiermee kunnen geen

andere commando's worden gegeven dan de 'enable' of 'disable' commando's aan de

(eventueel aanwezige) 3 - state uitgangen.

11


:ReadJlddroessJ •Data_OutJ

Read--Addroess.J4 •Data_Out.J4

LIFOData_OutJixJData_OutJix----"

Figuur 3.3. IDaSS bouwsteen: LIFO

3.4. LIFO

Het LIFO modelleert een First In First Out stack geheugen voor algemeen gebruik. In

figuur 3.3 is een typische IDaSS LIFO gegeven.

Een LIFO kan een enkele schrijfpoort bevatten. Bij een LIFO bestaat die slechts uit een

data ingang (weergegeven met Data_In). Met deze ingang kunnen datawoorden op de

kop van de stack worden geschreven (het adres van het bovenste veld van de stack wordt

aangeduid met Top Of Stack = TOS). Een LIFO heeft ook een leespoort die verbonden

is met TOS. Deze leespoort bestaat dus uit alleen een data uitgang (Weergegeven met

Main_Data_Out).

Daarnaast kunnen een onbeperkt aantal leespoorten worden toegevoegd. Er bestaan

twee soorten leespoorten:

. Leespoorten die bestaan uit een adres ingang (weergegeven met

Read_Address_1 .. Read_Address_N) en een data uitgang (weergegeven met

Data_Out_l..Data_Out_N). Geadresseerd wordt relatieft.o.v. de waarde TOS. Dat

wi! zeggen dat TOS het address '0' heeft

. Leespoorten die alleen bestaan uit een data uitgang. (weergegeven met

Data_Out_Fix_l..Data_Out_Fix_M). Deze hebben een vast adres, relatief t.o.v.

TOS. Het is niet toegestaan om twee 'vaste' uitgangen naar hetzelfde adres te

laten wijzen. Daarbij wordt de Main Read port ook als een vast adres (met adres

= 0) gezien.

Het LIFO gedraagt zich als een logisch geheugen, dat wil zeggen dat indien gepoogd

wordt om te lezen 'voorbij' de huidige inhoud van de LIFO aan de uitgang 'UNK'

waarden worden geproduceerd.

Via de control ingang (weergegeven d.m.v Control_In) kunnen aan een LIFO de

12


volgende commando's worden gegeven:

•Reset: Maakt de LIFO volledig leeg. Dit commando heeft een hogere prioriteit

dan aIle andere (nog te beschrijven) commando's en kan dus worden gezien als

een asynchrone reset. In een eventuele implementatie kan dit commando een

aparte ingang krijgen.

• Push: Bij het actief worden van de volgende klokperiode wordt de waarde die

aanwezig is aan de data ingang (Data In) op de stack gezet. Deze operatie is niet

toegestaan indien de LIFO reeds volledig gevuld is.

• Pop: Bij het actief worden van de volgende klokperiode wordt de inhoud van

TOS van de stack verwijderd. Deze operatie is niet toegestaan bij een lege LIFO.

• Replace: Bij het actief worden van de volgende klokperiode wordt de inhoud

van TOS vervangen door de waarde die aanwezig is aan de data ingang

(Data_In). Dit commando staat in feite gelijk aan het uitvoeren van een 'pop' en

een 'push' commando binnen een klokslag. Deze operatie is niet toegestaan

indien het LIFO leeg is.

• Popreplace: Bij het actief worden van de volgende klokslag wordt de inhoud

van het veld onder TOS vervangen door de waarde die staat aan de data ingang

(Data_In). Dit commando is in feite gelijk aan het uitvoeren van de commando's

'pop' en 'replace' binnen een klokslag. Dit commando mag alleen worden

uitgevoerd indien er minstens twee woorden in de LIFO staan.

• Swap: Bij het actief worden van de volgende klokperiode wordt de inhoud van

het veld TOS met de inhoud van het veld direct onder TOS verwisseld. De

inhouden van adres 0 en adres 1 worden dus verwisseld. Dit commando mag

aIleen worden uitgevoerd indien er minstens twee woorden in de LIFO staan.

•Pop2: Bij het actief worden van de volgende klokperiode worden de inhouden

van adres 0 en adres 1 van de stack verwijderd. Dit komt neer op het uitvoeren

van twee 'pop' operaties binnen een klokperiode. Er moeten minstens twee

waarden op de stack staan voor executie van dit commando.

•Pushcopy: Bij het actief worden van de volgende klokperiode wordt de waarde

van TOS (adres 0) gekopieerd en op de stack gezet. De stack mag niet leeg zijn

en de stack mag niet vol zijn voor executie van dit commando.

Een controller kan, naast de kop van de stack ook het huidige aantal elementen op destack uitlezen.

13


MAinJ)At~Out

DAta_OutJixJData._OutJix-"

Read-J'cld:ressJ •

DlIItlll_OutJ

Read-J'cld:ress~ •

Data_Out~FIFO

Figuur 3.4. IDaSS bouwsteen: FIFO

3.5. FIFO

Het FIFO modelleert een First In First Out 'elastisch buffer' geheugen voor algemeen

gebruik. Een typisch IDaSS FIFO is weergegeven in figuur 3.4.

Een FIFO kan een enkele schrijfpoort bevatten. Bij een FIFO bestaat die slechts uit een

data ingang (weergegeven d.m.v. Data_In). Met deze ingang kunnen datawoorden

worden toegevoegd aan de 'tail' van de queue. De FIFO heeft ook een leespoort die

verbonden is met de 'head' van de queue. Deze leespoort bestaat uit alleen een data

uitgang (weergegeven d.m.v. Main_Data_Out)

Naast deze twee poorten kunnen een onbeperkt aantalleespoorten worden toegevoegd.

Er bestaan twee soorten leespoorten:

. Leespoorten die bestaan uit een adres ingang (weergegeven met

Read_Address_1..Read_Address_N) en een data uitgang (weergegeven met

Data_Out_1..Data_Out_N). Geadresseerd wordt relatief t.o.v. de 'head' van het

geheugen (telkens het veld dat het langste in de queue staat). De 'head' heeft

adres O•

. Leespoorten die aIleen bestaan uit een data uitgang (weergegeven met

Data_Out_Fix_1..Data_Out_Fix_M). Deze hebben een vast adres t.o.v. de 'head'

van de queue. Het is ruet toegestaan om twee 'vaste' uitgangen naar hetzelfde

adres te laten wijzen. De main read port wordt daarbij ook gezien als vast uitgang

met relatief adres O.

De FIFO gedraagt zich als een logisch geheugen, dat wil zeggen dat indien wordt

gepoogd om te lezen 'voorbij' de huidige inhoud van de FIFO aan de uitgang 'UNK'

waarden worden geproduceerd.

Via de control ingang (weergegeven met Control_In) kunnen aan een LIFO de volgende

14


commando's worden gegeven:

•Reset: Maakt de FIFO volledig leeg. Dit commando heeft een hogere prioriteit

dan alle ander (nog te beschrijven) commando's en kan dus worden gezien als een

asynchrone reset. In een eventuele implementatie kan dit commando een aparte

ingang krijgen.

• Write: Bij het actief worden van de volgende klokslag wordt de waarde die

aanwezig is aan de data ingang (Data In) toegevoegd aan de 'tail' van de FIFO

(dat wil zeggen op het eerst volgende vrije adres). Het is Diet toegestaan om in

een volledig gevuld FIFO te schrijven. Dit commando kan worden gecombineerd

met het 'read' commando, en heeft een lagere prioriteit dan het 'reset'

commando.

• Read: Bij het actief worden van de volgende klokslag wordt de waarde aan de

'tail' van het FIFO verwijderd (adres 0). Dit commando heeft Diets uit te staan

met het 'enable' maken van de main read port. Dit commando mag Diet gegeven

worden indien de FIFO geheel leeg is.

Een controller kan de 'head' van de FIFO lezen, als ook het huidige aantal datawoordenin de FIFO

15


Read.Jlddl"essJ •Read..J)ataJ

Read.Jlddl"ess-H •Data_Out~

CAM

• Matoh_Input

• Match_S-R

• Ho-"latch_SJ

• Ho-"atoh_Input

• Ma tchJ1asl<_1 n

• Matoh.J)ata_In

c Con1;rol_In

Figuur 3.5. IDaSS bouwsteen: CAM

3.6. CAM

Een Contents Addressable Memory modelleert een geheugen type dat datawoorden kan

adresseren door de bits in deze datawoorden te vergelijken met een bepaald referentie

woord. In figuur 3.5 is een typische IDaSS CAM gegeven.

Behalve de extra leespoorten is een CAM binnen IDaSS volledig synchroon, d.w.z. aIle

commando's worden uitgevoerd bij de eerstvolgende klokflank nadat het commando

werd gegeven.

Als een datawoord in het geheugen overeenkomt met een bepaald 'match datawoord'

op de plaatsen waarvoor de bits'!' zijn in een 'match mask woord', dan noemen we dit

datawoord 'matching'. Zowel het 'match data' woord als het 'match mask' woord kunnen

worden gegeven via een input poort

Verder zijn nog beschikbaar: informatie over het aantal woorden dat 'matchte' en de

plaat waar die woorden staan.

Verder kunnen er asynchrone leespoorten aan de CAM worden gehangen, die het

geheugen direct geadresseerd uitlezen (Read_Address_1..N resp Data_Out_1..N)

De woorden die aan het (gemaskeerde) referentiewoord voldoen kunnen allen woord

voor woord worden uitgelezen.

Voor een meer gedetailleerde beschrijving verwijs ik naar de IDaSS handleiding, omdat

het CAM voor ons verder toch met van belang is.

16

Gegeven:

Hardware Structuren

4. Hardware structuren.

In dit hoofdstuk zal een overzicht worden gegeven van de analyse van enkele uitgewerkte

blokken. Per blok zal, uitgaande van het meest uitgebreide model (conform Idass),

worden geprobeerd tot een zo realistisch mogelijk model te komen. D.w.z. dat de analyse

gebeurt met in het achterhoofd, dat het uiteindelijke ontwerp ook zal moeten kunnen

worden gerealiseerd. Van de beschikbare basisbouwblokken binnen IDaSS zuBen er drie

worden behandeld, de RAM, de LIFO en de FIFO. Dit heeft als reden dat de LIFO en

de FIFO qua architectuur het meest interessant zijn (althans dat was de verwachting voor

het begin van de opdracht). Daarbij komt dat binnen de architectuur van de LIFO en

de FIFO altijd RAM aanwezig moet zijn, vandaar dat ook dit blok werd beschouwd. Wat

betreft de andere blokken: de operator en de FSM zijn te implementatie - afhankelijk

om er een algemeen model van de maken. Register en buffer waren in eerste instantie

niet interessant genoeg, en tenslotte kan van de CAM gezegd worden dat dit een mooi

vervolgonderzoek zou zijn, uitgaande van de opgedane ervaring met de wat eenvoudiger

blokken als de RAM/LIFO/FIFO.

4.1. HET MULTI· PORTED PROBLEEM.

Bij veel van de te ontwikkelen structuren stuiten we op het probleem dat een structuur

multi - ported moet zijn. Dit probleem kunnen we algemeen als voIgt omschrijven.

. N Processen, te weten: Proces 1, Proces 2, ..., Proces N. Elk proces kan

op willekeurige momenten toegang vragen tot een van de M (gedeelde)

resources

. M Resources. Elk van deze resources kan op elk moment slechts service

verlenen aan 1 proces.

Bij 'normale' operatie van het systeem zijn er geen problemen te verwachten. Echter

indien gelijktijdig twee processen toegang vragen tot een resource dient er een

eenduidige afspraak te zijn hoe deze situatie wordt afgehandeld. We spreken dan ook

we van een arbitrage probleem.

Bij het oplossen van het arbitrage - probleem dient rekening gehouden te worden met:

. Wat is 'gelijktijdig': er dient dus een tijdsinterval te worden afgesproken

waarbinnen twee aanvragen nog als 'gelijktijdig' worden beschouwd. Dit

17

Hardware Structuren

tijdsinterval zal meestal 0 naderen.

. Een oplossing dient 'Fair' te zijn, d.w.z. dat er geen situatie mag ontstaan

waarin aanvragen van een bepaald proces geheel niet meer afgehandeld worden.

In dit licht, (we komen er later nog op terug), is het wellicht verstandig om een keuze

te maken tussen synchrone en asynchrone ontwerpen.

In een asynchroon ontwerp zullen alle acties plaatsvinden ten gevolge van transities in

signaal-lijnen. Dit heeft als gevolg dat het tijdstip waarop aan bepaalde voorwaarden

wordt voldaan niet eenduidig is vastgelegd. Het kost in het algemeen dan ook meer

moeite (en dus ook meer hardware) om een asynchroon ontwerp correct te realiseren.

Ook het bovengenoemde probleem van gelijktijdigheid is dan vrij moeilijk.

In een synchroon ontwerp zullen alle acties plaatsvinden als gevolg van een transitie van

een kloksignaal. Het moment waarop dit gebeurt ligt precies vast, zodat een gebruiker

er voor kan zorgen dat bepaalde waarden van signalen aanwezig zijn. In dat geval is ook

het probleem van gelijktijdig arriveren van signalen opgelost. Immers, indien beide

signalen tijdens een kloktransitie aanwezig waren, zijn ze gelijktijdig opgetreden.

In dit verslag is het arbitrage probleem te projecteren op de volgende situatie. De M

resources worden voorgesteld als de M geheugenplaatsen in een RAM. De processen

kunnen worden voorgesteld door de lees- en schrijfpoorten. Het arbitrage probleem

treedt nu op indien er twee aanvragen voor toegang komen voor een adres in het

geheugen binnen een heel klein interval ~T, uitgaande van asynchroon ontwerp en indien

2 aanvragen actief zijn bij een kloktransitie in geval van synchrone ontwerp.

Er zijn in wezen twee mogelijke strategieen (als uitersten) die een oplossing vormen

voor dit probleem.

1) sequentiele oplossing. Deze gaat uit van een voorkeurmechanisme (zoals bijvoorbeeld

round robin, write first, etc.). Een proces dat aan bepaald voorwaarden voldoet, krijgt

voorrang op het andere proces dat in een wachtrij wordt gezet. De arbiter die voor deze

keuze zorgt is volledig eenduidig bepaald. Er zijn voldoende strategieen die ervoor

zorgen dat deze oplossing aan de eis van fairness voldoet.2) parallelle oplossing. Deze gaat ervan uit dat indien er bijvoorbeeld drie aanvragen

gelijktijdig moeten worden behandeld, dit ook moet kunnen, desnoods door

verdrievoudiging van de resources. Aile drie de aanvragen worden (zonder

voorkeursbehandeling) gelijktijdig geaccepteerd en verkrijgen gelijktijdig service. (althans

18

Hardware Structuren

voor het oog van de waarnemer buiten de resource, hoe zoiets dan intern verloopt doet

niet terzake)

Bij de verschillende architecturen die worden behandeld werd steeds een afweging

gemaakt tussen beide oplossingen.

4.2. MODEL VAN BESTAANDE RAM· ARCHITECTUREN

Om uiteindelijk een realisatie te krijgen van een RAM die voldoet aan de algemene

verwachtingen zuBen we in eerste instantie de basisfuncties van een RAM bespreken,

zoals die algemeen aanvaard zijn. Er bestaan dan twee soorten RAM, namelijk

synchroon en asynchroon. In figuur 4.1 zijn van beide principes blokdiagrammen gegeven

Het RAM is als voIgt opgebouwd:

We zien twee belangrijke blokken. Ten eerste is er het eigenlijke geheugen, de geheugen

matrix. Datawoorden zuHen in dit blok worden bewaard. Ten tweede onderscheiden we

een controle - blok, dat zorgt voor:

1) Een correcte aansturing van de geheugen matrix

2) Een correcte afhandeling van aanvragen voor geheugen toegang en de op het

geheugen gedefinieerde operaties.

ZoaIs we later zuHen zien, zijn er wat architectuur betreft voor punt 1 niet veeI

keuzemogelijkheden, maar Iaat punt 2 weI een £link aantaI varianten toe. Het eerste

RAM RAM

Data_Out

Memory

Matrix

/":::..

a IJ: '" 7-[ ....... Control Logic

"-[

...v

ressAdd

Dat

Memory

Matrix

/:::..

In " 7-....

I ...Control Logic

[ ...ress

...

Data

Add

Clk Wr Rd Cs Wr Rd Cs

Figuur 4.1. Synchroon en Asynchroon RAM

19

Hardware Structuren

RAM is een synchroon RAM, hetgeen wil zeggen dat het de erop gedefinieerde

operaties synchroon met de klok uitvoert, dus bij een transitie van de klok van '0' naar

'1'. De operaties worden aIleen dan uitgevoerd indien de lijn CS actief is. In dat laatste

geval kunnen op het geheugen de volgende operaties worden uitgevoerd:

. READ:

Deze operatie maakt het mogelijk om een datawoord, dat in de geheugen

matrix staat op de plaats die wordt aangegeven door het adreswoord op

de adresbus 'ADDRESS', over de databus 'DATA_OUT' naar de

buitenwereld te transporteren.. WRITE:

Deze operatie maakt het mogelijk om een datawoord van de buitenwereld

over de databus 'DATA_IN' naar het geheugen te transporteren. Het

datawoord zal worden weggeschreven op de plaats die wordt aangegeven

met een adreswoord op de adresbus 'ADDRESS'.

Voor een asynchroon RAM geldt in principe hetzelfde, zij het dat de operaties nu niet

synchroon met de klok worden uitgevoerd, maar op een transitie van de CS lijn. Ook is

het mogelijk dat zelfs de CS lijn ontbreekt, en dat de waarden van bussen veranderen

na het verstrijken van een bepaalde tijd nadat een adres veranderde. Aan de hand van

deze beschrijving kan het volgende worden opgemerkt:

1) De bussen Data_In en Data_Out worden in de praktijk veelal gecombineerd

tot een bus, waarover data in beide richtingen kan worden getransporteerd.

Indien ook Read en Write lijn tot een lijn worden gebundeld, is er in elk geval

impliciet geen write/read conflict, immers write en read sluiten elkaar volledig

uit, en bestaan er ook geen bus conflicten.

2) Door voornoemde bundeling van signalen is het dus ook niet mogelijk om

gelijktijdig zowel een lees actie als een schrijf actie, op verschillende adressen tebewerkstelligen.

4.3. MODEL VAN EEN 'IDEAAL' RAM

Indien we het model voor een RAM volgens IDaSS en het model van een bestaand

RAM naast elkaar leggen zien we dat beide modellen, hoewel ze in principe een blokje

modelleren met dezelfde functionaliteit, op zeer cruciale punten van elkaar verschillen.

Een vergelijking van beide modellen wordt gemaakt in tabel I

20

Hardware StmcturenTabel I. Modelvergelijking RAM's

Model RAM Volgens IDaSS Model bestaand RAM

· Multiple Read poorten · 1 Read Poort· Multiple Write poorten · 1 Write Poort· Adres bussen allen gescheiden · Gecombineerde Adresbus voor

Read/Write Adressen· Databussen allen gescheiden · Gecombineerde DataBussen· Geen arbitrage voor read/ · Door combinatie signalen

write conflicten ingebouwd impliciete arbitrage.

Het blijkt dus dat, op het punt van de arbitrage na, het IDaSS model het 'ideale beeld'

levert van een RAM (in dit geval het meest uitgebreide model). Dat wil zeggen dat er

een onbeperkt aantal lees- en schrijfpoorten kan worden toegevoegd. Deze zijn

gescheiden, hetgeen busconflicten (mits bussen met extern verkeerd verbonden zijn)

uitsluit. Ons doel kunnen we dus verwezenlijken indien we het IDaSS model zouden

kunnen implementeren (volgens welke strategie dan ook) en daarbij ook nog eens binnen

het RAM voor een afdoende afhandeling konden Zorgen van het arbitrage probleem.

Combineren we nu het IDaSS model met ooze wens het arbitrage probleem op te lossen

komen we tot een RAM dat er uitziet als weergegeven in figuur 4.2. Allereerst zien we

dat het RAM is verdeeld in twee zijden. Aan een zijde visualiseren we het proces dat in

het RAM wil schrijven, aan de andere zijde het proces dat uit het RAM wil lezen.

Daarbij is te zien dat de klok die IDaSS weI heeft maar daar niet zichtbaar is in een

IDaSS schema, als lijn aan de RAM is verbonden. De controle - poort die IDaSS had,

is vervangen door een aantal 'write' lijnen, die in wezen dezelfde functie hebben. (In

feite kunnen we ons de controle - ingang voorstellen als een bus van controle lijnen)

We zullen nu proberen om tot een architectuur te komen die zoveel mogelijk het

bovenstaande ideaal beeld benaderd. We beginnen met een architectuur die een totaal

gestripte versie is van het bovenstaande ideaal beeld. Dit lijkt nogal een forse sprong,

maar we zullen zien dat dit teruggaan naar zeer primitieve vormen ook zijn voordelen

oplevert. Onderweg zullen we enkele architecturen verder uitwerken dan andere. Dit

heeft een tweetal redenen. Ten eerste kan meteen bij een beschouwing van een

architectuur blijken dat ze met de huidige technologie met erg reeel zal zijn. Ten tweede

21

Wf_Address_l __'/

Wr_Data_lWr_1

Wf_Address_N__,.r

Wr_Data_N

WeN

RAM

Hardware Structuren

,,-__ Rd_Address_l

Rd_Data_1~-- Rd_1

'r--- Rd_Address_M

Rd_Data_M~-- Rd_M

Fix_Data_1IE--- Rd_Fix_l

elk Fix_Data_Kl- Y':::-- Rd_Fix_K

Figuur 4.2. IDaSS model van een RAM

is het mogelijk dat ik bepaalde architecturen nog niet nader heb onderzocht wegens

tijdgebrek bij het afstuderen. Ret wil dan echter niet zeggen dat die architecturen niet

de moeite waard zijn. In voorkomende gevallen zal ik pogen een zo eerlijk mogelijk

beeld te geven van waarom een architectuur niet verder is uitgewerkt en of het wenselijk

is dit alsnog te doen.

22

Hardware Structuren

Write_Address

'"[v v

RAM"[ J

v "

/1\ /1\

Wr Rd

Figuur 4.3. Eenvoudig model RAM

4.4. RAM: SINGLE READ, SINGLE WRITE RA < > WA

We kiezen de strategie BOTfUM-UP en beginnen dus met een RAM met zo min

mogelijk eisen. Daartoe beperken we ons voorlopig tot een RAM met 1 sehrijfpoort en

1 read poort. (Zowel een sehrijfpoort als een leespoort bestaat uit een adres bus en een

databus.) Daarmee redueeren we de 'outline' van het RAM zoals is weergegeven in

figuur 4.3. We eisen bovendien dat het adres waarop wordt gesehreven, niet gelijk is aan

het adres waarop wordt gelezen.

De arehiteetuur van deze eel is redelijk eenvoudig te realiseren In figuur ? is daartoe een

eerste aanzet gedaan.

We zien daarin N geheugen elementen die elk 1 compleet datawoord kunnen bevatten.

Om zo'n element van een nieuwe waarde te kunnen voorzien, dienen we een element

te kunnen seleeteren. Daartoe wordt een adres aangeleverd via de adresbus. Dit adres

wordt in een adres - decoder omgezet in een signaal dat een enkele eel kan seleeteren.

Als daarmee ook nog het write signaal aetief wordt gemaakt kan de eel de data van de

databus overnemen. Aan de leeszijde gebeurt in wezen hetzelfde. Hierbij laten we even

volledig buiten besehouwing of het RAM synehroon dan weI asynehroon werkt en gaan

er even van uit dat indien het RAM synehroon is het write signaal kan worden

voorgesteld als een wired - and van de signalen 'Write', 'Cs' en 'Clk'.

23

Hardware Structuren

Wr Rd

Figuur 4.4. Arch. RAM Single write single read, WA < > RA

In het geval van een asynchroon RAM bestaat het write - signaal uit een lijn.

We zien dus dat in de meest primitieve (niet triviale) vorm een RAM kan worden

opgebouwd uit:

· Geheugencel

· Adresdecoder

· Enkele 'AND' poorten

· Een aantal bussen

In een echte realisatie komen daarbij nog de nodige busdrivers, output buffers e.d., maar

dat is nu niet van belang, het gaat om de principes.

4.5. RAM; SINGLE WRITE, SINGLE READ, TOEGESTAAN: WA =RA

We gaan nu een stap verder. We willen nu een RAM modelleren, met een schrijfpoort,

een leespoOft, waarbij willekeurig mag worden gelezen en/of geschreven, dus het RAM

zorgt voor een correcte verwerking van de situatie waarbij het schrijfproces toegang

vraagt tot het zelfde adres als het leesproces. (WA=RA). Ten behoeve van deze

arbitrage introduceren we twee nieuwe signalen die aan de buitenwereld kenbaar maken

of het RAM bezig is met een proces of niet. (zie figuur 4.5) Deze signalen zijn

Busy_Write en Busy_Read. Indien een proces willezen in het geheugen, en dit levert een

24

Hardware Structuren

Write_Address

Busy_Write

.... ....I

v

.... RAM ...,

L--., ",/ "l

....- ......-... ,

11\ /\

Wr Rd

Data_Ou.t

Busy_Read

Figuur 4.5. Basismodel RAM met Busy signalen

conflict op omdat er reeds op hetzelfde adres wordt geschreven, dient Busy Read hoog

te worden. Een analoge redenatie kan worden opgesteld voor Busy_Write.

4.5.1. SEQUENTIELE OPLOSSING

Deze oplossing is de meest voor de hand liggende. In figuur 4.6 is de structuur van deze

oplossing gegeven. We zien in deze figuur twee belangrijke blokken.

. Het eigenlijke geheugen. Dit is in principe het zelfde geheugen als werd

besproken in § 4.4. Er kan in dit geheugen geschreven en gelezen worden, mits

het maar niet op het zelfde adres is.

. Een arbiter. Deze arbiter zorgt voor een correcte afhandeling van de aanvragen

; __ ,~ ~

c=~==:::t:~ ~t::====l¢ Data_OutMemory

Cells

Write_Address

Busy_Write ARBITER

Wr Rd

Read_Address

Busy_Read

Figuur 4.6. Basis architectuur RAM, sequentiele oplossing

25

Hardware Structuren

voor lezen en schrijven.

Zoals in § 4.1 al werd aangegeven hebben we in principe de keuzen uit twee ontwerp

principes: synchroon en asynchroon ontwerpen. Daarin werd betoogd dat indien men

asynchroon probeert te ontwerpen, men rekening dient te houden met extra inspanningen

t.o.v. de situatie waarin men synchroon ontwerpt. Het kost bij een asynchroon ontwerp

meer moeite om een correcte implementatie te vinden voor het arbitrage probleem dan

bij een synchroon ontwerp.

Er is daarom gekozen voor de aanname dat 'write' en 'read' opdrachten (Wr en Rd)

synchroon met een ldok zullen arriveren. Dit komt ook overeen met het IDaSS model,

waar weliswaar het lezen asynchroon gebeurt, maar de leesopdrachten (die niet met de

hand worden gegeven) synchroon arriveren. Er is dus in feite geen sprake van echte

asynchroniteit binnen IDaSS.

We stellen dus dat de Wr(ite) en de R(ea)d lijn op gezette tijden actiefworden. Indien

Wr en Rd actief worden voor hetzelfde adres zal eerst een van beide (volgens een

bepaald voorkeursmechanisme) afgehandeld moeten worden. Daarna moet de ander nog

worden verwerkt. Het is dus noodzakelijk om de Wr en de Rd opdracht in een flipflop

te bewaren en pas weer te resetten indien de opdracht werd verwerkt. Pas dan mag weer

een nieuwe opdracht aanvaard worden.

Uitgaande van bovenstaande onderstelling kunnen we het arbiter blok weergeven als is

gedaan in figuur 4.7. We zien daarin een comperator die de aangeboden adressen met

elkaar vergelijkt. De uitkomst voor deze vergelijking en daarbij de signalen Wr en Rd

vormen de inputs voor de finite state machine die moet beslissen over het lezen enschrijven.

Als strategie voor de finite state machine kan worden gekozen uit verschillende opties.

1) Write gaat altijd voor. Dat wil zeggen dat bij een adres conflict er eerst wordt

geschreven en dan pas gelezen. Komt er echter na de verwerking meteen weer een

schrijfopdracht voor hetzelfde adres (niet erg waarschijnlijk, maar het kan), dan wordt

er meteen weer geschreven.

2) Read gaat altijd voor. Bij een adres conflict wordt er altijd eerst gelezen. Komt er

daarna weer een leesopdracht voor het zelfde adres (zonder dat de schrijfopdracht is

verwerkt) dan wordt deze opdracht weer eerst verwerkt.

26

Hardware Structuren

Wdt. R.d

F1NITESTATEMACBlNE

Wr Rd

Figuur 4.7. Structuur van de arbiter

3) Write gaat de eerste keer voor. Dat wi! zeggen dat bij een adres conflict de eerste

keer eerst wordt geschreven, en meteen daarop volgend de leesopdracht wordt afgewerkt,

ook indien inmiddels voor hetzelfde adres een nieuwe schrjjfopdracht aanwezig was.

4) Read gaat de eerste keer voor. Analoog aan punt 3.

Ret diagram behorende bij strategie no. 1. is weergegeven in figuur 4.8.

WRE

WE + WRE--

Figuur 4.8. FSM diagram seq. oplossing

27

Hardware Structuren

Hierin wordt de aanwezigheid van een Wr(ite) - signaal aangegeven met W, de

afwezigheid met Not(W). Analoog de signalen Equal (E) en R(ea)d (R). In de Write

state is het Write - uit signaal hoog en Read - Vit laag. De waarden van de signalen

Read en Write die naar het eigenlijke geheugen worden gestuurd kunnen voor elke state

in onderstaande tabel worden afgelezen.

Tabel II. Vitgangssignalen per state

Read Write

Write State 1 0

Read State 0 1

Read&Write State 1 1

Voor de architectuur van het eigenlijke geheugen wordt verwezen naar figuur ? Deze

heeft dezelfde architectuur.

4.5.2. REGISTERED OPLOSSING

Een andere oplossing voor het adres - conflict wordt in deze paragraaf gegeven. De

contouren van het RAM blijven in dit geval hetzelfde. Intern is er in de bus die data

naar het geheugen transporteert een latch opgenomen. We zien dit in figuur 4.9

De binnenkomende databus bevat nu een latch. Bij normale operatie (d.w.z. er is geen

adres conflict) is deze latch transparant. Komt er echter een lees en een schrijfaanvraag

voor het zelfde adres, dan wordt gelijktijdig de te schrijven data in de latch bewaard en

de data uitgelezen. Is de leesactie gereed, dan wordt de data die voorlopig in de latch

werd bewaard alsnog in het geheugen gezet. We zien dus dat er een extra signaal

benodigd is om de latch te sturen. Verder is de opbouw van het blok arbiter analoog aan

dat van de sequentiele oplossing.

De finite state machine bevat nu echter weI een extra state zoals is te zien in figuur 4.10

op de volgende pagina. Deze state is ervoor bedoeld om met behulp van de latch de

schijf -en leesopdracht gelijktijdig te verwerken.

28

Hardware Structuren

...................__ .-...

Write_Address

Busy_WriteARBITER

/ /1\

Wr Rd

Figuur 4.9. Arcbitectuur registered oplossing

Verder zullen de signalen weer zijn weergegeven als in bet vorige state diagram. D.w.z.

dat bet optreden van een Wr - actie wordt weergegeven met W, en bet niet optreden

van Wr - actie wordt weergegeven met NOT(W). Analoog de signalen Read (R) enEqual (E).

Figuur 4.10. State diagram registered oplossing

29

Hardware Structuren

Write_Address

Busy_Write

r 1\ -"

-"""V

>.. x.... ....0 ~ VI~

...,C'&

/.....Jo., ~ :::?1 ¢::r-v'

I 1\

/"F S M ,

f\ '1\

Read_Address

Busy_Read

Wr Rd

Figuur 4.11. Blokdiagram Registered oplossing

4.5.3. FORCED OUTPUT OPLOSSING

Een derde, en tevens laatste, oplossing voor het probleem van het adres conflict is

weergegeven in figuur 4.11.

Bij een adres conflict wordt nu de waarde die men wi! schrijven in het geheugen ook

meteen op de uitgang gedrukt. Ondertussen wordt ook de waarde in het geheugen

geschreven.

De arbiter heeft nu in plaats van een latch - enable signaal een extra signaal dat aan de

uitgang de keuze bepaald tussen data die uit het geheugen komt en data die direct van

de ingang afkomstig is.

Het state diagram is hetzelfde als van de registered oplossing, alleen wordt nu geen latch

- enable aangestuurd maar mux_enable.

Ook het basisgeheugen heeft wederom dezelfde architectuur als weergegeven in figuur

?

30

Hardware Structuren

4.6. MEERDERE POORTEN

In de vorige paragrafen is de structuur behandeld van een RAM waarbij 1 leespoort en

1 schrijfpoort aanwezig was, en waarbij beiden op het zelfde adres actief mochten zijn.

In principe hebben we dus op die manier een dual - ported RAM gecreeerd. IDaSS heeft

echter N poorten waarin gelijktijdig mag worden gelezen en geschreven. Wij hadden er

zelf de eis bij gehaald om ook de arbitrage door de RAM te laten afhandelen. In deze

paragraaf zullen geen volledig uitgewerkte structuren meer worden gepresenteerd maar

slechts aanzetten hoe een N - ported RAM zou kunnen worden gerealiseerd. We hebben

dan twee mogelijkheden. Beide worden in de volgende sub - paragrafen besproken

4.6.1. VOLLEDIG PARALLEL

We kunnen ons een RAM voorstellen waarbij het mogelijk is om met N poorten tegelijk

te lezen en te schrijven. We komen dan bij een model waarvan in figuur 4.12 het

blokschema is gegeven

Hierin zien we dat aan de schrijfkant N schrijfadressen worden aangeboden, tezamen

met N datawoorden. Een schakelnetwerk zorgt voor het bereiken van de afzonderlijke

cellen. Aan de schrijfzijde gebeurt iets dergelijks oak, maar nu worden daar leesadressen

gegenereerd, waarna de data weer naar buiten wordt gerouteerd. Om deze hele structuur

zou dan een arbitrage mechanisme moeten worden gebouwd, dat er voor zorgt dat geen

twee processen gelijktijdig toegang vragen tot een adres in het geheugen. Deze volledig

~ z - ::s...I 1 1 ..'.. .."" ..,"" .., "'" "'":J1 '<:l< <Il -<'"

1J!,I I I

.~..,

""~ ~ ~ ~

~

Write_Data_l Read_Data_l

Wl'ite_Data._N Read_Data_M

OE_l OE_M

Figuur 4.12. Volledig parallel met schakelnetwerk.

31

Hardware Structuren

parallelle oplossing is echter veel te duur aan hardware. In de eerste plaats worden de

schakelnetwerken erg groot voor n >2, en daarbij zal een arbitragemechanisme het

systeem zodanig vertragen dat de oplossing niet interessant is voor toepassing.

Een andere mogelijkheid wordt gegeven in figuur 4.13 en is in principe gelijk aan de

oplossing die werd gegeven in § 4.5. Echter de blokken die werden gebruikt in die

paragraaf worden nu in cascade gezet. In principe zou dit, met de nodige zorg voor hetontwerp weI te realiseren zijn, maar ook dit vergt ontzettend veel hardware en wordt

Figuur 4.13. Volledig parallel, gecascadeerd

bovendien ook erg traag.

4.6.2. VOLLEDIG SEQUENTIELE OPLOSSING

Naast een volledige parallelle oplossing voor dit probleem kunnen we ons een RAM

voorstellen met een schrijfpoort en een leespoort waaraan aan beide zijden een queue

wordt gehangen waarin meerdere processen hun aanvraag voor lezen en/of schrijven

kunnen deponeren. Deze aanvragen worden in een queue gezet ter lengte van het aantal

processen dat aan het ram hangt. AIle aanvragen worden volgens een bepaald

prioriteiten mechanisme afgehandeld.

Een en ander is weergegeven in figuur 4.14.

32

Hardware Structuren

.......................r··...

..-.._._ u····-i.·~·· ARBITER

HoP:::E--<ZoU r.I------i f------t..........• ·. f------i .

1------i ":...I------i ~ .. I------i ":...

Figuur 4.14. Volledig seriele oplossing

Er kleven aan deze oplossing enkele nadelen

· Een proces weet niet waar zijn opdracht in de queue staat, het is dus

onduidelijk wanneer een opdracht klaar zal zijn.

· Dientengevolge is niet op elk moment eenduidig te bepalen wat de inhoud van

het RAM zal zijn.

· De overhead van een queueing mechanisme is erg groot.

Door deze bezwaren is ook deze oplossing niet erg reeel. We sluiten met deze oplossing

het 'hoofdstuk' van de RAM's af.

33

Hardware Structuren

Data Out

LIFO1----..::;. Full

Empty

En Clk Op_Code

Figuur 4.15. Model bestaand LIFO

4.7. MODEL BESTAANDE LIFO

We zijn nu toegekomen aan het beschrijven van een andere structuur die in IDaSS wordt

gebruikt, namelijk de LIFO. In § 3.3. hebben we reeds het echte IDaSS model leren

kennen. Ook nu zullen we weer voor de volledigheid een model geven waaraan een

LIFO in normale werkelijkheid aan voldoet. Dit model werd overgenomen van J. Hink

in zijn afstudeerverslag "Data structures and VLSI"

We zien daarin twee databussen, Data_In en Data_Out, die zorgen voor het transport

van data van en naar het geheugen. De stack is bovendien synchroon, hetgeen betekent

dat alle operaties worden uitgevoerd op een transitie van de kIok 'elk', en bovendien

alleen dan indien het enable signaal '1' is. De lijnen Full en Empty geven de status van

de stack aan.

We willen dit weer vergelijken met de LIFO zoals die is gedefinieerd in IDaSS. We

krijgen dan een model zoals dat is weergegeven in figuur 4.16. Deze LIFO is, net als de

RAM ingedeeld in twee zijden. Aan de ene kant kan men zich een proces voorstellen

dat in de LIFO probeert te schrijven, aan de andere zijde een proces dat probeert te

lezen. In IDaSS worden sommige signalen tekstueel gegeven, namelijk de Reset, de KIok

en de Opcode. In dit model zijn deze lijnen echter fysisch weergegeven. Verder heeft dit

model dezelfde functionaliteit als de LIFO in IDaSS. We somrnen ze nogmaals op:

· 1 schrijfpoort, d.w.z. een databus waarmee men datawoorden op de stack

kunnen worden gezet.

· 1 Main readport, d.w.z. een databus die altijd de waarde van TOS weergeeft.

· 'Onbeperkt' aantal adresseerbare leespoorten, d.w.z. relatief t.o.v. de bovenkant

34

Hardware Structuren

van de stack kunnen velden van de stack worden uitgelezen via de aanwezige

extra databussen

. 'Onbeperkt' aantal vaste leespoorten, d.w.z. op een vaste afstand van TOS

kunnen velden worden uitgelezen.

De status - out informatie is binnen IDaSS weergegeven met een integer, die bet aantal

elementen in de stack weergeeft. We laten voorlopig nog in bet midden boe we de status

informatie weergeven. We zagen ecbter bij bet model van bet bestaande RAM dat bet

gebruikelijk is om aan te geven of een stack vol is of leeg, zonder precies aan te geven

boeveel elementen er exact in de LIFO zitten. We kunnen ecbter nu al opmerken dat

we aan de signalen Full/Empty alleen niet voldoende zullen bebben, immers er bestaat

een operatie POP2, waarbij bet nodig is dat er minstens twee elementen in de Stack

zitten. Daartoe zal een extra lijn aanwezig moeten zijn.

Mogelijke operaties op de stack zijn:

* Pusb * Popreplace

* Pop * PusbCopy

* Pop2 * Swap* Replace

Voor de definitie van deze operaties verwijs ik naar boofdstuk 3 waarin bet model vaneen LIFO volgens IDaSS wordt gegeven

Data In

LJ,F.O,

Fix_Data_l

Fix_Data_M

Q)'0oU

o!o

Figuur 4.16. IDaSS model van LIFO

35

Hardware Structuren

AIle operaties kunnen binnen 1 klokslag worden uitgevoerd. Net als bij de RAM treedt

hier ook weer het probleem op dat het model van IDaSS erg veel mogelijkheden biedt,

niet aIleen in het gebruik binnen IDaSS zelf, maar ook voor implementatie. We zullen

nu twee structuren bespreken van een LIFO, die weliswaar nog niet aIle kenmerken

hebben van het IDaSS model, maar die in elk geval t.o.v. het 'standaard' LIFO wat extra

functies hebben

4.8. LIFO MET IDASS FUNCTIES

We beginnen weer zo eenvoudig mogelijk en proberen daarna aan te geven hoe de

architectuur uitgebreid kan worden, in de richting van de IDaSS functionaliteit. We

beginnen dus met een architectuur te geven van een LIFO met 1 schrijfpoort en 1

leespoort (de main read port) waarbij echter weI aIle operaties die in IDaSS zijn

gedefinieerd kunnen worden toegepast.

Deze LIFO zal uitgebreid worden behandeld in hoofdstuk 5, vandaar dat de beschrijving

hier tamelijk beknopt zal blijven.

De structuur valt uit elkaar in twee grote functies. Ten eerste de eigenlijke

geheugenfunctie van de LIFO. Data wordt opgeslagen in het RAM (midden v.d. figuur

4.18). De verschillende operaties brengen de noodzaak met zich mee dat de waarde van

het bovenste veld van de stack (TOS) en de waarde van het veld dat daaronder ligt

(TOS-1) elders ook nog bewaard dienen te worden. Voor die taak zijn er twee registers

aanwezig, een voor de waarde van TOS de ander voor de waarde van TOS-l.

Voor de verschillende operaties is het noodzakelijk om de volgende bussen naar TOS

of TOS-1 te kunnen schrijven:

. Register 1

FullLIFO

Data Out

Rd

Empty

Near_Empty

Rst Op_code

Figuur 4.17. Lifo met IdaSS functies

36

Hardware Structuren

. Register 2

. Data In

Dit gebeurt op de stijgende flank van de Writeklok Clk_1. Na de Operatie dienen de

registers hun nieuwe waarde te krijgen. Dit gebeurt op de stijgende flank van de

Readklok CLK 2.

Om deze bussen naar het geheugen te schakelen is er een klein schakelnetwerk

aanwezig. Dit netwerk krijgt zijn commando's via een commando bus van de controller.

Ten tweede is er het controller - gedeelte dat bestaat uit het leveren van de nodige

stuursignalen aan het geheugen - gedeelte (inclusief aan het schakelnetwerk) en uit het

bijhouden van de adresteller die de plaats van TOS aangeeft. Bovendien wordt in het

controller gedeelte de status informatie gegenereerd

Er is voor het weergeven van de status informatie gekozen voor de gangbare methode

van aanduiden met behulp van Full/Empty. Te zien is echter ook dat er nog een vector

is die de status van de lIFO aangeeft namelijk Elem_0_1. Dit is noodzakelijk omdat

processen die het LIFO gebruiken dienen te weten of een bepaalde operatie die het wil

uitvoeren weI is toegestaan. Bij de operaties Pop2, Popreplace en swap is het

noodzakelijk dat er minstens twee elementen in de stack staan. Elem_0_1 wordt laag op

het moment dat aan deze voorwaarde is voldaan.

Reset

I<:====~:j::::::;> Data_OutData_In

Opcode Clk1 Clk2

Figuur 4.18. Interne structuur LIFO

37

Hardware Structuren

Een mogelijke architectuur wordt gegeven in hoofdstuk 4.

4.9. LIFO MET EXTRA LEESPOORT

Omdat IDaSS ook voor de LIFO een ongelimiteerd aantal leespoorten toestaat, wordt

hier een eerste aanzet gegeven van hoe een dergelijke extra leespoort zou kunnen

worden gemodelleerd. In figuur 4.19 is een blokschema weergegeven.

Ret verdient de aanbeveling om eerst hoofdstuk 4 geheel door te lezen, dan is het

volgende wat begrijpelijker.

In de implementatie van het andere LIFO werd gekozen om aan elke geheugencel een

selectie element te hangen. Dit heeft als voordeel dat de architectuur nu gemakkelijk

uitgebreid kan worden naar een model, waarbij een extra leespoort met vrij weinig

moeite kan worden geYmplementeerd. Naar het selectiemechanisme aan de leeszijde

moet nu een extra adreslijn worden gestuurd die een eel kan laten uitlezen. De inhoud

van deze eel wordt op een extra databus gezet. Er zijn nu weI wat meer

besturingssignalen nodig en een extra register, maar aan het principe van de werking

doet het niets af. Een en ander is weergegeven in de architectuur van figuur 4.20.

Met een zelfde hoeveelheid moeite is het mogelijk om meerdere poorten aan de LIFO

te hangen, d.w.z., aan de leeszijde. De vraag is alleen of dit bijzonder veel nut heeft.

Indien men zo'n extra poort wenst toe te voegen moet er aI, wat betreft applicatie, een

goede reden zijn om dit te doen. Men zou dan al moeten denken aan een applicatie

waarbij meerdere processen dezelfde stack gebruiken. Dit is echter niet erg waarschijnlijk

Wr

Fu.ll

.... ....

LIFO...

...... ........ ......

./ ....."-

~./

Address_IllData_Out

Rd

Figuur 4.19. Blokschema van LIFO met extra leespoort

38

Hardware Structuren

omdat het dan moeilijk is om consistent met de data om te gaan. Het ene proces weet

immers met of een ander proces wellicht data heeft toegevoegd en/of verwijderd.Clkl Clk2

Data_OutData_Out

Addres_In

Opcode

Figuur 4.20. Architectuur van LIFO met extra leespoort

39

FIFO

Hardware Structuren

Data_Out

Full

Empty

Figuur 4.21. Basisvoorstelling FIFO

4.10. EENVOUDIG FIFO

Ook hier beginnen we weer met een weergave zoals een FIFO in de praktijk wordt

gerealiseerd. Ook deze voorstelling (figuur 4.21) is overgenomen van J. Bink.

Hierin zien we de volgende signalen. Data in en Data Out zijn de databussen die zorgen- -voor het transport van data naar en van het geheugen. De FIFO is synchroon met de

klok elk, en daarbij is er een enable signaal gedefinieerd, dat de FIFO als geheel

selecteert.

Daarnaast kunnen aan dit FIFO twee commando's worden gegeven te weten:

. Write: De waarde die staat op de databus Data In wordt bij de volgende

transitie van de klok van 0 naar 1 toegevoegd aan de 'head' van bet FIFO, dit is

de eerst volgende vrije geheugenplaats.

. Read: De waarde die staat op de 'tail' van de FIFO wordt verwijderd. Dit beeft

met het uitlezen van de tail niets te maken!

Ook hiervan kunnen we een eenvoudig blokschema geven. Deze is weergegeven in

onderstaande figuur (4.22). We zien daarin weer het geheugen. Voor de adressering van

de velden 'bead' en 'tail' van de FIFO gebruiken we twee tellers. Deze tellers worden

aangepast na het geven van control signalen van de controller die aanwezig is in het blok

FSM. De status signalen worden gegenereerd aan de hand van de waarde van de tellers

in bet blok dat is weergegeven m.b.v. 'Full/Empty Logic'.

40

Hardware Structuren

Reset

Full

..................................•

RAM

r-r~~ ~L/ r-----r ..........!.l'L....L........ -r- "-

Write ReadTeller Teller

.... F S M

fFu11lEmpty

/ Logic ....Empty

Figuur 4.22. Arehiteetuur eenvoudig FIFO

Indien we voor het geheugen in figuur 4.22 de basisarehiteetuur invullen, resulteert dit

in figuur 4.23. De adresdeeoders zorgen voor de seleetie van telkens een eel, die

daarvoor is uitgerust met een blok eombinatorisehe logiea die ervoor zorgt dat een eel

geseleeteerd kan worden om te lezen of te sehrijven, en dit ook doet bij een transitie van

een klok van 0 naar 1. Bovendien zorgen deze blokken ervoor dat er geen buseonflicten

ontstaan door de uitgang hoog-ohmig te maken indien een eel niet werd geseleeteerd.

In principe hebben deze blokjes dus de zelfde funetionaliteit als de blokken Wr_Sel en

Rd_Sel in de LIFO (zie hiervoor ook hoofdstuk 5)

41

Hardware Strncturen

Reset

Full Empty

Op_Code

Figuur 4.23. Echte architectuur FIFO

42

Hardware Structuren

Reset

Full

--1+ RAM ¢

----r : .!.l~ ~ .

Write lAdder & f<;::==j::::::Jrreller Tel1er ~

FS MI'

"---~ FlJ.11/Emptyf--.,..---...Y

Logic

Op_Code

OffSet

Empty

Figuur 4.24. Model FIFO met extra leespoort

4.11. FIFO MET EXTRA SCHRUFPOORT.

Ook bij een FIFO is het bij IDaSS mogelijk meerdere leespoorten te definieren. In deze

paragraaf willen we kort aangeven hoe een dergelijke extra poort in de architectuur

gepast kan worden. Beschouwen we daartoe figuur 4.24. Hierin is dezelfde

basisarchitectuur weergegeven als van een FIFO met maar een leespoort. Omdat in

IDaSS de extra poorten adresseren relatief t.o.v. de head van de FIFO, moet het

mogelijk zijn om een offset te genereren en die bij het leesadres voor het RAM 'op te

tellen' Binnen het controle gedeelte van de FIFO zal dan weI voor een afdoende

ondersteuning van de extra leespoort gezorgd moeten worden. tevens is het dan zo dan

maar aan een poort tegelijk service kan worden verleend.

43

VHDL Implementatie LIFO

5. VHDL Implenlentatie LIFO.

In dit hoofdstuk zuHen we de implementatie behandelen van een van de

basisbouwblokken van IDaSS. De LIFO is door mij gekozen omdat deze mij het meest

interessant leek: Van de beschreven bouwblokken zijn er immers de meeste operaties

op gedefinieerd. Bovendien kan worden gezegd dat bij de vakgroep EB al reeds eerder

FIFO's zijn geanalyseerd en ontworpen.

Voorts moet worden opgemerkt er gewerkt werd met beta - releases van tools, zodat

daar enige problemen mee konden worden verwacht. Ook hiervan wordt verslag gedaan,

om bij vervolgonderzoek verrassingen te voorkomen

5.1. HET ONIWERPTRAjECT.

Bij de vakgroep Digitale Systemen, wordt sterk vastgehouden aan het principe van het

TOP - DOWN ontwerpen. Een ontwerp wordt hierbij ingedeeld in verschillende

abstractieniveau's. Elk niveau wordt functioneel beschreven en getest, waarbij

implementatie - details zo lang mogelijk uit het ontwerp worden geweerd. Hierdoor

verkrijgt men een overzichtelijk model, dat -indien nodig- eenvoudig kan worden

aangepast. In wezen zijn we met dit TOP - DOWN ontwerpen reeds begonnen met de

analyse van de functionaliteit van verschillende blokken op het hoogste niveau. De

methodiek laat zich echter ook goed toepassen in de implementatiefase. We zuHen dan

als voIgt te werk gaan:

1) We maken, uitgaande van het basismodel, een VHDL - beschrijving van de

LIFO.

2) We testen de VHDL - beschrijving m.b.v. de simulatie - tool Quicksim op

functionele correctheid.

3) Het model wordt opgesplitst in subfuncties. Elke subfunctie krijgt een eigen

VHDL beschrijving.

4) Stap 2 en 3 worden zolang herhaald, totdat we op het niveau zijn beland dat

werkelijke implementatie nagenoeg triviaal is.

5) AIle voorgaande subfuncties worden functioneel aan elkaar gehangen binnenVHDL

6) Het geheel van samenstellingen van subfuncties wordt met de zelfde stimuli

getest als het model van stap 1/2. Indien aHes correct is verlopen, vertonen het

model op het hoogste niveau en het model dat bestaat uit subfuncties volkomen

44


hetzelfde gedrag.

Een en ander is grafisch weergegeven in figuur 5.1.

1

Vhdl-bes eh%'.

tot ...... l

Quiel<:sim. Vhdl-bescht'.

subf''U.11. cties

Join

~od",ls

Test; Tocaal

Figuur 5.1. antwerp traject in de implementatie - fase.

5.2. DE ON1WlKKELOMGEVING.

Bij de ontwikkeling van de LIFO werd gebruik gemaakt van de volgende CAD

pakketten, allen beschikbaar op de Apollo - ring van de vakgroep.

. Het Mentor - Graphics System 1076 pakket (VHDL - Compiler en het

Quicksim simulatie pakket)

. Mentor - Graphics (NetEd & SymEd) Schematic Capture - pakket.

Het Mentor - Graphics pakket bestaat uit een groot aantal onderdelen. De modellen

kunnen o.m. worden beschreven in de (door IEEE gestandaardiseerde) beschrijvingstaalVHDL.

Nu bestaan er twee mogelijkheden om hierarchie in een ontwerp te brengen. We zullen

beide mogelijkheden kort bespreken.

De eerste mogelijkheid wordt gegeven door de beschrijvingstaal VHDL zelf (zie ook

figuur 5.2). Een ontwerp kan worden opgesplitst in verschillende modules. Elk van deze

modules kan weer worden opgesplitst, waardoor hierarchie in het ontwerp wordt

gebracht. De modules op een hoger niveau dienen echter weI gekoppeld te worden met

de modules op een lager niveau. Deze koppeling, die in 'standaard' - VHDL m.b.v.

component - dec1araties en instantieringen kan worden gerealiseerd (en dus volledig

tekstueel tot stand komt), werd door de gebruikte compiler nog niet ondersteund. (Het

betrof een beta - release van de compiler). Dit betekende dus, dat modules van een

ontwerp tekstueel niet konden worden samengevoegd.

45


ENTITY

Figuur 5.2. Hierarchie in VHDL - beschrijving

De tweede mogelijkheid om hierarchie (figuur 5.3) in het ontwerp te brengen werd door

een ander pakket van Mentor Graphics gegeven, namelijk het Schematic Capture pakket.

(Er is waarschijnlijk door Mentor Graphics om marketing redenen gekozen voor deze

omissie in de beta - release van de vhdl - compiler).

Een ontwerp wordt op het hoogste niveau van abstractie getekend binnen Neted, waarbij

ook inputs en outputs worden aangegeven. Zo'n tekening wordt ook weI 'sheet' genoemd.Hierarchie wordt tot stand gebracht door een sheet op te splitsen in deelsheets, waarbij

de correctheid van de koppeling tussen twee niveaus wordt geverifieerd door het ontwerp

met Expand 'plat' te slaan. De blokken die in de laagste niveau sheet staan, moeten in

VHDL worden beschreven. Om de koppeling tussen dit grafische pakket en de VHDL

beschrijving tot stand te brengen krijgen deze blokken een speciaal attribuut mee,

waaraan de simulator herkend dat het blokken met een vhdl - beschrijving betreft. Deze

methode van aanbrengen van hierarchie werd ook gebruikt voor het beschrijven van de

LIFO

Het Mentor - Graphics pakket bevat ook een bibliotheek met basis - componenten, zodat

een ontwerp tot op poortniveau kan worden uitgewerkt. Zover ben ik in mijn beschrijving

echter niet gegaan. Behalve de reeds genoemde beperkingen (components) van de beta

- release waren er nog meer binnen de compiler en de simulator. Hiervan is een klein

opsomming gemaakt die is opgenomen in Appendix A.

Mijn ontwerp van de LIFO bestaat uit drie niveaus, die in het vervolg van dit hoofdstukzuHen worden besproken.

46


---~--, ... _-----(-Neted Sheet':~-----'

... ' ...... ,~- ... _----------,'

/~ ...

[ $hdl ), ,, ,'~--~;~~._----~~

,,.,<-S-y~Ed Symb~i--~)

-.,---------------------'

Figuur 5.3. Neted/Symed hierarchie

5.3. NIVEAU O.

Op dit niveau bestaat het te ontwikkelen systeem uit het model van de LIFO met

daaromheen de buitenwereld, die wordt voorgesteld door twee processen, een bronproces

en een putproces.

Deze twee processen kunnen op twee verschillende manieren worden gerealiseerd. Ten

eerste is het mogelijk om ook een VHDL beschrijving te maken voor deze processen, en

daarin de stimuli voor de LIFO te verwerken. Ben nauwe interactie tussen deze twee

processen en de LIFO is dan noodzakelijk. Een andere manier is de ontwerper een lijstmet invoer - stimuli voor de simulator te laten leveren en daarna de uitvoer met de hand

te laten analyseren. Ret weglaten van een echte testomgeving heeft als voordeel dat we

vrij zijn in het kiezen van een 'externe' timing. Nadeel is echter dat een lijst van stimuli

niet erg flexibel is en al snel erg omvangrijk gaat worden voor grote ontwerpen.

Ret argument van de timing heeft mij doen besluiten om een lijst met stimuli tegenereren.

De ingangen en uitgangen zijn op dit niveau reeds gedefinieerd in het voorgaande. Bij

de implementatie werd ervoor gekozen het ontwerp zo flexibel mogelijk te houden. Deze

wens had nag veel verder doorgevoerd kunnen worden da nu al het geval is indien er

geen gebruik gemaakt had hoeven worden van een beta - release van de software. In dat

47


Status Status

LIFO DATA

Figuur 5.4. Het systeem in zijn omgeving

geval, zou met behulp van componenten het ontwerp veel meer variabel gehouden

kunnen worden

5.4. NIVEAU 1.

De LIFO heeft als hoofdfunctie het tijdelijk opslaan van data die wordt geleverd door

een bronproces. Daarna moet de data ook weer worden vrijgegeven aan een putproces.

Daarnaast zijn er enkele operaties gedefinieerd op het LIFO die betrekking hebben op

zowel data in de LIFO als op het transport van en naar de LIFO. Elk van deze operaties

willen we binnen een klokslag kunnen uitvoeren. Stellen we ons de stack voor als een

stapel van geheugenplaatsen. De bovenste gevulde geheugenplaats heet TOS. De

geheugenplaats onder TOS noemen we 'TOS-l'. De operaties zijn (indien er staat TOS

wordt het adres TOS bedoeld, TOS tussen haakjes geeft de inhoud aan van de

geheugenplaats met adres TOS, en TOS' betekent de nieuwe waarde voor TOS):

1) Push. Bij het actief worden van deze operatie wordt data van de buitenwereld naar

het RAM getransporteerd op de plaats TOS. TOS wordt met een verhoogd, waarna de

geheugenplaats gevuld kan worden.

Voorwaarde: Indien met deze operatie het geheugen vol raakt moet dit aan de

buitenwereld worden medegedeeld, en indien het geheugen reeds vol was, mag deze

operatie niet worden gebruikt.

TOS' := TOS + 1

(TOS') < = Data_In

2) Pop. Bij het actief worden van deze operatie wordt de bovenste waarde van de stack

48


uit het geheugen verwijderd. Dit komt neer op het met een verlagen van TOS.

Voorwaarde: Indien hiermee het geheugen leegraakt moet dit aan de buitenwereld

worden medegedeeld, en er moet minstens een element in het geheugen staan

TOS' := TOS-1

3) Replace. Bij het actief worden van dit commando wordt weer data van de

buitenwereld naar het RAM getransporteerd. TOS wordt niet verhoogd, dus de bovenste

gevulde geheugenplaats wordt overschreven.

Voorwaarde: Mag aIleen worden toegepast indien er minstens een geheugenplaats

gevuld is.

TOS':= TOS(TOS') < = Data_In

4) Popreplace. Bij het actief worden van deze operatie, dient de bovenste gevulde

geheugenplaats te worden weggegooid, terwijl de plaats daaronder vervangen dient teworden met de waarde op de databus. TOS wordt dus verlaagd, waarna data in hetgeheugen wordt geschreven.

Voorwaarde: Deze operatie mag slechts worden uitgevoerd indien er minstens tweegeheugenplaatsen gevuld zijn.

TOS' := TOS - 1

(TOS') < = Data_In

5) Pop2. De bovenste twee geheugenplaatsen dienen worden vergeten. TOS moet dusmet twee worden verlaagd.

Voorwaarde: Er dienen minstens twee geheugenplaatsen gevuld te zijn.TOS' := TOS - 2

6) Pushcopy: De waarde die in de bovenste gevulde geheugenplaats staat, moet nogmaals

op de stack worden gezet. Dus TOS moet worden verhoogd, waarna de waarde kanworden geschreven.

Voorwaarde: Er moet nog minstens een vrije geheugenplaats zijn en er moet ookminstens een element in het geheugen staan

TOS' := TOS + 1

(TOS') < = (TOS'-1)

49


7) Swap. Bij het actief worden van deze operatie worden de inhouden van de bovenste

twee geheugenplaatsen verwisseld. TOS blijft dezelfde geheugenplaats, maar krijgt alleen

een andere waarde.

Voorwaarde: Er dienen minstens twee geheugenplaatsen gevuld te zijn.

TOS' := TOS

HELPI < = (TOS')

HELP2 < = (TOS'-l)

(TOS') < = HELP2

(TOS'-l) < = HELPI

Vit de beschrijving van de operaties kunnen we de volgende eisen afleiden:

· Er moet een mechanisme bestaan om de bovenste geheugenplaats (TOS) te

selecteren.

· Er moet een mechanisme bestaan om de op een na bovenste geheugenplaats

(TOS-l) te selecteren.

· TOS moet:

* Met een kunnen worden verhoogd

* Gelijk kunnen blijven

* Met een kunnen worden verlaagd

* Met twee kunnen worden verlaagd.

· De waarde van de databus moet naar TOS kunnen worden geleid.

· De inhoud van TOS moet beschikbaar zijn. (O.m. om hem nogmaals op de

stack te kunnen zetten). Bovendien moet die waarde naar de nieuwe TOS kunnenworden geleid, of naar TOS-l

· De inhoud van TOS-l moet beschikbaar zijn (voor swap operatie). Deze inhoud

moet dus naar TOS kunnen worden geleid.

We zien dus twee belangrijke functies van de LIFO:

. Data - opslag. Hiertoe zal er een blok moeten zijn waarm data kan worden

opgeslagen.

. Control. Om de data opslag correct te laten verlopen en voor een correcte verwerking

van de operaties dient de LIFO voorzien te zijn van een controle eenheid.

50


5.4.1. VOORWAARDEN - CONTROLE.

Bij de verschillende operaties is het vaak nodig dat een bepaald aantal elementen in het

geheugen staan. De vraag is wie er verantwoordelijk is voor de controle op deze

voorwaarden. Er zijn dan twee mogelijkheden. Ten eerste kun je een mechanisme

bedenken dat de LIFO verantwoordelijk maakt voor deze controle. Maar dan bestaat er

het probleem dat je aan de buitenwereld moet mededelen dat een operatie niet werd

uitgevoerd. Dus op dat moment moet de buitenwereld deze informatie gaan verwerken

en andere actie ondernemen. Je schiet er dus eigenlijk niet veel me op indien deze

voorwaarden gecontroleerd en geweigerd worden. Handiger is dus de tweede

mogelijkheid om aIleen aan de buitenwereld informatie over de status van de LIFO te

geven. De beslissing om weI of niet een operatie uit te voeren kan dan op grond van die

informatie door de buitenwereld worden genomen. Voor deze oplossing is gekozen.

De informatie-vectoren dienen het volgende te kunnen weergeven:

1. De LIFO is VOL, (t.b.v push, pushcopy)

2. De LIFO is LEEG (t.b.v. pop, pushcopy, replace, swap) d.w.z. de LIFO bevat

niet minstens een element

3. De LIFO bevat minstens 2 elementen. (t.b.v. swap, popreplace)

We maken daartoe drie signalen:

· Full. Indien het geheugen op een plaats na vol is en indien er een operatie

actief wordt die TOS met een verhoogd, wordt Full hoog. Indien TOS niet gelijk

is aan Ram_Length wordt Full weer laag

· Empty. Indien het geheugen nog een gevulde plaats bevat, en een operatie

wordt actief die TOS met een verlaagd, wordt Empty hoog. Het geheugen bevat

dan geen gevulde plaatsen meer.

· Elem_0_1: Indien het geheugen nog twee gevulde plaatsen bevat en een

operatie wordt actief die TOS met een verlaagd, dan wordt Elem_0_1 hoog.

Elem_0_1 is dus hoog indien er 0 of 1 element in het geheugen zit. Elem_0_1 is

laag indien er minstens 2 elementen in het geheugen zitten.

51


5.4.2. GEHEUGEN FUNCTIE.

We zuHen nu op dit niveau de functie van het geheugen nader beschouwen. Vit de eisen

voIgt dat m.b.t. het geheugen:

1. De plaats TOS geselecteerd moet kunnen worden

2. De plaats TOS - 1 geselecteerd moet kunnen worden

3. Op zowel TOS als TOS-l geschreven moet kunnen worden, eventueel

gelijktijdig.

4. Waarde van bus Data_In er naar toe gevoerd moet kunnen worden

5. De inhouden van het veld TOS en TOS-l ergens beschikbaar moeten zijn en

naar het geheugen toegevoerd moeten kunnen worden.

We beginnen met 4 en 5. Als eis geldt dat we de operaties binnen een kIokslag willen

kunnen uitvoeren. Daarbij moeten we het probleem oplossen, dat we met swap een

hulpvariabele nodig hebben om de verwisseling correct uit te voeren. Met name deze

swap maakt het noodzakelijk om een terugkoppeling te hebben waarbij waarden in het

geheugen gelezen moeten worden en weer moeten worden teruggeschreven. Dit brengt

ons op het idee om de bovenste twee geheugenplaatsen na iedere operatie te kopieren

in twee aparte registers. We willen echter in een kIokslag ook een operatie uitvoeren.

Daartoe splitsen we de ldok in een twee - fasen kIok. Bij de eerste fase wordt data uit

de registers of databus (afhankelijk van de operatie) verwerkt naar het geheugen. Bij de

tweede fase wordt de nieuwe waarde van TOS en TOS-l weer in registers gezet. Zie

...~

TOS--..~

... ,. ... ,.I Register-lRegister I

...Memory

~

r-- '--- '---

..""l

Switch

Data Out

Figuur 5.5. Blokschema geheugen/register structuur

52


figuur 5.5. De waarde van het TOS register is dus tevens de waarde die op de databus

Data_Out moet worden gezet.

Dit houdt dus in dat er een aantal dingen gedaan moeten worden.

- Data moet worden opgeslagen. Zowel in het main memory als in de registers

- Data moet correct worden gerouteerd (bij elke operatie is een andere routering nodig,

zie tabel V) van register naar geheugen en van data}n naar geheugen. Hierover in het

volgende niveau meer, voorlopig volstaan we met de opmerking dat de routering correct

zal verlopen.

Dat brengt ons op punt 1,2 en 3. Er zjjn hiervoor principieel twee mogelijkheden.

A) Central control. Beschouw het geheugen als een standaard RAM en zorg er vanuit een

centrale plaats voor dat elke cel kan worden aangestuurd. Elke eel moet dan worden

uitgerust met een dubbele adresselectie (immers hij moet als TOS of als TOS-1 kunnen

worden geselecteerd) en met dubbele databus.

B) Distributed control. Hierbij is de controle verdeeld over aIle cellen die dan een stuk

intelligentie bevatten. Hierbij voer je dus in principe de opcode en aIle data toe aan aIle

ceIlen, die afhankelijk van de sequenties van opdrachten weten of ze actief moeten

worden of niet. Dit vereist meestal veel extra hardware, maar kan in sommige gevallen

toch interessant zijn.

Mijn oplossing houdt een beetje het midden tussen beide uitersten. Een eel krijgt de

volgende signalen/lijnen toegevoerd: (Zie figuur 5.6)

· Twee databussen, Bus In1 en Bus In2 (TOS bus resp TOS-1 bus)- -· Een adresbus, Adres_Sel, waarvan per cel slechts twee lijnen worden gebruikt.

· Selectiebus, Tos_Sel.

'"~I )

KI )

v v

"-I )

K GEHEUGEN BLOKI )v

Tos_Out

Tos-l_0ut

Figuur 5.6. Geheugenblok

53


Over de databussen wordt data (waar die ook vandaan komt, van registers of

buitenwereld) naar de eellen gevoerd. De adresbus bevat evenveel lijnen als er

geheugeneellen zijn, het eigenlijke adres is dus al gedeeodeerd. Indien er weinig eellen

zijn (zoals bij deze implementatie: 6) is dit qua oppervlakte de goedkoopste oplossing.

Indien er veel eellen zijn, is het nuttig om te bezien of het wat betreft oppervlakte niet

goedkoper is om elke eel zijn adres - decoder te geven en sleehts een niet gedeeodeerde

bus naar alle eellen te laten lopeno

Elke eel bevat een klein beetje logica, waarmee aan de hand van de adresbus kan

worden bepaald of een eel TOS is, TOS-l, of geen van beiden. Dit gaat als voIgt in zijn

werk. De adresbus bevat voor elke eel een lijn. Indien een eel wordt geseleeteerd door

zo'n lijn zijn er twee mogelijkheden (zie ook tabel III):

1) De bovenbuurman van de betreffende eel is niet geseleeteerd. In dat geval is

de eel zelf TOS. Immers voor TOS geldt dat het de bovenste eel van een stapel

is, dus als boven die eel geen andere eel werd geseleeteerd, en de eel zelf is weI

geseleeteerd, dan is de eel TOS.

2) De bovenbuurman van de betreffende eel is ook geseleeteerd. In dat geval is

de eel TOS-l. Voor TOS-l geldt immers dat er een gevulde eel boven hem ligt,

namelijk TOS. Indien dus de bovenbuurman van een eel geseleeteerd is, dan moetdit TOS zijn als de eel zelf geseleeteerd is.

Tabel III. Bepaling TOS

Zelf geseleeteerd: Bovenbuur geseleeteerd: eel is dan:

Nee Nee Nothing

Nee Ja Nothing

Ja Nee TOS

Ja Ja TOS-l

54


Een cel die TOS is haalt zijn data van de TOS databus, en een cel die TOS-l is haalt

zijn data van de TOS-l databus. IGjken we nu bij welke acties geschreven moet worden.(

Tabel IV)We zien dan dat er drie situaties bestaan. Ten eerste dat er helemaal niet hoeft worden

geschreven. Ten tweede dat aIleen TOS moet worden beschreven en als derde dat TOS

en TOS-l moet worden beschreven. Voor deze opties wordt een aparte commando - bus

gebruikt die naar aIle cellen wordt gevoerd, nl. Tos_Sel. We kunnen dus voor TOS_Sel

volstaan met 2 lijnen.

Tabel IV. Operaties en TOS

Schrijven TOS Schrijven TOS-l

PUSH 1 0

POP 0 0

REPLACE 1 0

POPREPLACE 1 0

POP2 0 0

PUSHCOpy 1 0

SWAP 1 1

Indien we nogmaals alles op een rij zetten hebben we nu een structuur gedefinieerd die

aan de volgende eigenschappen voldoet.

· We hebben een geheugen, waarin de plaatsen TOS en TOS-l kunnen worden

geselecteerd.

· We kunnen TOS en TOS-l beschrijven met een nieuwe waarde

· We kunnen TOS en TOS-l uitlezen en in twee registers zetten

· We kunnen met een nog nader te specificeren schakelnetwerk zowel de

registers weer in het geheugen schrijven als ook data van buiten de LIFO in het

geheugen schrijven. Tabel V bevat de informatie over welke waarden op een bus

moet worden gezet bij elke operatie. deze informatie zal worden gebruikt bij het

ontwerpen van het genoemde schakelnetwerk.

55


TabeI V. Schrijven bussen bij verschillende operaties

Waarde op TOS - bus Waarde op TOS-l bus

PUSH Data In D.C.

POP D.C. D.C.

REPLACE Data In D.C.

POPREPLACE Data In D.C.

POP2 D.C. D.C.

PUSHCOpy Register Tos D.C.

SWAP Register_Tos-l Register_Tos

D.C. = Don't Care

56


5.4.3. CONTROLE - FUNCTIE.

De controle - functie omvat drie belangrijke taken:

1) Uit het signaal opcode moeten controle - signalen worden gedestilleerd voorde afzonderlijke blokken. Zo moet TOS_Sel signaal worden gegenereerd, en moet

ook informatie worden afgegeven aan het geheugenblok betreffende de routering.

Immers bij de verschillende operaties willen we verschillende data op bussen

zetten.2) De controle functie omvat ook het genereren van Adr_sellijnen. Riertoe zal

er een teller binnen de controle functie aanwezig moeten zijn, evenals een adres

decoder. De precieze werking van de control - functie voIgt uit de eisen van de

LIFO en van de eisen van de geheugenfunctie als onderdeel van de LIFO en

zullen nader worden uitgewerkt op het volgende niveau .

3) Ret verschaffen van informatie over de status van de LIFO behoort ook tot de

taken van de controle - functie.

5.5. NIVEAU 2

In deze paragraaf zullen de twee functies (geheugen & control) nader worden uitgewerkt.

Daartoe zullen ze worden gesplitst in functionele blokken. Dit niveau van beschrijving

is terug te vinden in de Appendices in de tekening van de blokken & uiteindelijk in de

vhdl - beschrijving. We zullen beginnen met het beschrijven van de geheugenfunctie

5.5.1. GEHEUGEN - FUNCTIE

In de vorige paragraaf is beschreven aan welke eisen deze functie moet voldoen. In deze

subparagraafzal een mogelijke implementatie worden gegeven. Er zijn natuurlijk meerde

implementaties mogelijk (zie daarvoor ook vorige paragraaf).

We splitsen het de geheugenfunctie in het eigenlijke geheugen (Memory_Block) en in

blok waar de registers en een schakelnetwerk inzitten (Register_Block). Ret eigenlijke

geheugen bestaat uit elementen zoals weergegeven in figuur 5.7.

Daarin zijn te onderscheiden:

· Schrijf selectie blok (Wr_Sel).

· Eigenlijke geheugen element (Ramcel)

· Lees selectie blok (Rd_Sel)

57

§ 4.5.1.1

§ 4.5.1.2

§ 4.5.1.3

Clkl


Clk2

Data_In!

Data_In2

Tos Sel

Adr_Sel

I I~

v~ ~

V~

[

~v v K----v

Ramee!v

Wr_Se1 Rd Sel

Data_Ont!

Data_Ont2

Figuur 5.7. Geheugenelement

We zien dat het schrijfselectie blok geklokt is en de eigenlijke geheugencel niet is

verbonden met de klok. In principe zit de klok verwerkt in de signaallijn Write_Cel die

van het Wr_Sel blok naar de Ramcelloopt. Deze write_Cellijn kan dus worden gezien

als een wired - and van de klok Clk_1 en een enable lijn, die afhankelijk is van de logica

binnen het Wr Sel blok.

Ret Register Block wordt gesplitst in twee functionele delen (figuur 5.8)

, II"

..... IRegister IRegister I

•............~

.-.............Switch

Data Out

Data_In

Figuur 5.8. Register_Block

Daarin zijn te onderscheiden:

. De eigenlijke registers

. Schakelnetwerk

58

§ 4.5.1.4

§ 4.5.1.5


Adr_Sel(l:O)Tos_Sel(1:0)

elk

"- Write_Sel "-r

~v

r v

[or

AI

Data_Out

Figuur 5.9. Schrijf selectie blok (Wr_Sel)

5.5.1.1. SCHRIJF SELECTIE BLOK

Het schrijf selectie blok heeft twee functies.1) Selectie van de eigenlijke geheugencel. Indien het geheugenelement waar dit

schrijf selectieblok deel uitmaakt is geselecteerd om beschreven te worden geeft

het schrijf selectie blok de eigenlijke opdracht aan de geheugencel. Het blok doet

dit wanneer:

* Geheugenelement is geselecteerd als TOS (d.w.z. Adr_Sel(1:0) = '01')

en TOS moet worden beschreven (Tos_Sel(1:0) = 'xl')

* Geheugenelement is geselecteerd als TOS-1 (d.w.z. Adr_Sel(1:0) = '11')

en TOS-1 moet worden beschreven (Tos_Sel(1:0) = ' Ix')

Voor een exacte timing wordt verwezen naar paragraaf 5.6

2) Multiplexen van de databussen. Elk geheugen element is aangesloten op beide

databussen. Een bus vervoert de data die naar TOS moet worden geschreven de

andere bus vervoert data die naar TOS-1 moet worden geschreven. Indien het

geheugenelement is geselecteerd als TOS (Adr_Sel(1:0) = '01') moet de data van

databus Bus_In1 worden doorgevoerd naar Data_out. Indien het geheugenelement

geselecteerd is als TOS-1 moet de data van Bus_In2 naar Data_Out worden

doorgevoerd.

5.5.1.2. GEHEUGENCEL.

Dit is het basis-element van het geheugen. Er kan een compleet datawoord in worden

opgeslagen. De opslag van een woord gebeurt op de stijgende flank van de Write - lijn.

Enige tijd erna is ook de data op de uitgang van de eel beschikbaar. In wezen komt dit

neer op een rij asynchrone flipflops die reageren op een transitie van hun enable -

59

Data In

Write eel


Data Out

RAMCEL

Figuur 5.10. Geheugeneel (Rameel)

ingang. Er is voor gekozen om de data eontinu op de uitgang aanwezig te hebben. Dit

levert geen buseonflicten, immers in het blok Rd_Sel worden de waarden pas op een

gemeensehappelijke bus gezet.

5.5.1.3. LEES SELECTIE BLOK

Data In

elk

Bus_Out1

Bus_Out2

Figuur 5.11. Lees seleetie blok (Rd_Sel)

Dit blok heeft in wezen maar een funetie: het correct overnemen van data)n, en de

data van deze bus op bus out! resp bus outZ zetten, op de volgende manier- -

. Indien het geheugenelement waar dit blok deel van uitmaakt is geseleeteerd als

TOS (Adr_Sel(O:l) = '01') dan dient de waarde van Data_In naar Bus_OutI

gerouteerd te worden. De uitgang Bus_OutZ moet dan hoog-ohmig worden

gemaakt

. Indien het geheugenelement is geselecteerd als TOS-1 (Adr_Sel(O:l) ='11') dan

dient de waarde van Data_In naar Bus_OutZ gerouteerd te worden. Bus_Out!

dient dan hoog-ohmig te worden gemaakt.

60


. Indien het geheugen element niet als TOS of als TOS-l is geselecteerd

(Adr_Sel(O:l) = '10' I'00') dan dienen beide uitgangen hoog-ohmig te worden

gemaakt (om busconflicten te voorkomen). Een en ander is weergegeven in tabel

VI

Bus_Outl is aange~loten op het register dat de waarde van TOS moet bewaren,

Bus Out2 is aangesloten op het register dat de waarde van TOS-l moet bewaren.

Tabel VI. Waarheidstabel Rd Sel blok

Adr Sel Bus Outl Bus Out2

00 Hoog-Ohmig Hoog-Ohmig

10 Hoog-Ohmig Hoog-Ohmig

01 Data In Hoog-Ohmig

11 Hoog-Ohmig Data In-

Deze drie blokken samen vormen een geheugenelement. Indien meerdere van deze

geheugenelementen worden samengevoegd verkrijgt men een blok dat voldoet aan de

eisen van functionaliteit zoals die werden geteld in § 4.4.2.

4.5.1.4. REGISTERS.

Clk R.egister

Data Out

Figuur 5.12. Register

61


De registers hebben een standaard register - functionaliteit. D.w.z indien de klok hoog

wordt de waarde van de register_in bus moet worden overgenomen. Enige tijd later dient

die waarde ook op de uitgang van het register te verschijnen. Het register kan worden

ge'implementeerd met edge - triggered flipflops. Er zijn twee registers. Een register zal

de waarde TOS bewaren. De andere zal de waarde TOS-1 bewaren. Indien er een

asynchrone reset komt zal de inhoud van de register onbekend. Immers na een reset is

er geen waarde voor TOS gedefinieerd. Het empty - signaal is hoog, waaruit de

buitenwereld kan afleiden dat de data op de Data_out bus niet geldig is. Daarom is het

niet noodzakelijk de registers te resetten. Voor een uitgebreide beschrijving van de

timing wordt verwezen naar § 5.6

5.5.1.5. SCHAKELMATRIX

Bus Ini

Bus In2 SWITCH

Bus_Out2

Op_Code

Figuur 5.13. Schakelmatrix

De schakelmatrix kent de volgende functionaliteit. Er zijn drie operatie - modes. Ten

eerste moet het mogelijk zijn om data van de Data_In (= Bus_In1) bus (buitenwereld

data) naar Bus_Outl te schakelen. Dit is nodig voor de operaties Push, Replace,

Popreplace. Bus Out1 is verbonden met de Tos Bus van het geheugen. Ten tweede moet- -het mogelijk zijn om de waarde van Register 1 naar Bus_Outl te schakelen. Dit is

noodzakelijk voor de operatie Pushcopy. De oude waarde van TOS (die is opgeslagen

in register 1) wordt dan naar de nieuwe plaats TOS geschreven. Als derde moet het

mogelijk zijn om Register 1 (=Bus_1n2, die de oude waarde van TOS bevat) met

Bus_OutZ en Register 2 (= Bus_1n3, die de oude waarde van TOS-1 bevat) met

Bus_Outl te verbinden. Dit is noodzakelijk voor de swap operatie. Voor de operaties

No_Op, Pop, Pop2 doet het er niet toe hoe er geschakeld wordt: de informatie van de

bussen wordt dan toch niet gebruikt door het geheugenblok.

62


Dit sluit de beschrijving van de geheugen functie af. De VHDL beschrijving van de

blokken Register, Switch (schakelnetwerk), Wr_Sel, Ramee! en Rd_Sel zijn te vinden in

de appendices. We hebben gezien dat voor een correcte aansturing van het geheel de

volgende signalen noodzakelijk zullen zijn:· Adres_Sel(Ram_Length-l:O): Voor de adressering van de geheugenelementen.

Elk geheugenelement maakt gebruik van twee lijnen van deze bus.

· Tos_Sel(l:O): Commando - bus, waarover informatie wordt gestuurd die

aangeeft of TOS of TOS-l moet worden beschreven

· Reg_Opcode(l:O): Commando - bus die de routering - informatie aan het

Register Block doorgeeft.

5.5.2. CONTROL FUNCTIE.

FullEmptyElem 0 1 Decoder

Blok

Control Blok

Op_Code

ResetClk

Figuur 5.14. Control functie

Ook de control functie bevat twee blokken. Ten eerste een blok dat (Decoder blok)

zorgt voor het bijhouden van de adresteller en het decoderen van het adres naar een

adresbus. Ten tweede een blok dat zorgt voor de distributie van de volgende controlesignalen:

· Tos Sel: Reeds behandeld

· Cnt_Opcode: Dit signaal (dat wordt afgeleid uit Opcode) geeft aan welke teller

- operatie moet worden uitgevoerd (no_op, up, down, down2, rst). Aangezien er

vijf mogelijkheden bestaan hebben we 3 lijnen volgens tabel VIII

· Reg Opcode: Er bestaan daarvoor vier mogelijkheden, Data In To Busl,- - - -Pushcopy, Swap en RST. Welke waarde van Reg_Opcode bij welke operatie hoort

is weergegeven in Tabel VII Omdat het vier mogelijkheden betreft zal in de

uiteindelijke implementatie kunnen worden volstaan met een commando bus van

63


2lijnen.

Tabel VII. Selectietabel

Cnt Opcode Reg Opcode

NOP No Op D.C.

PUSH Up Data In= >Busl-POP Down D.C.

REPLACE No op Data In= >Busl

POPREPLACE Down Data In= >Busl

POP2 Down2 D.C.

PUSHCOPY Up Pushcopy

SWAP No_Op Swap

Dit tweede blok zorgt ook voor de verwerking van de asynchrone reset. Hiervoor is in

de VHDL - beschrijving een proces opgenomen dat reageert op veranderingen in dereset - lijn. Indien deze lijn hoog wordt, wordt aan het decoder - blok een Rst - opcode

gegeven, waarna de adresteller op nul wordt gezet. Hiermee is het LIFO leeg gemaakt.

Rest ons nog de beschrijving van het eerste blok binnen de control - functie, het

bijhouden van de adresteller en het decoderen van het adres. Deze functie is in de

appendix opgenomen als het blok Decoder_Block en heeft de onderstaande structuur.

5.5.2.1. COUNTER

Deze counter telt tot het aantal elementen in het RAM (in deze implementatie tot 6

dus) De counter herkend de volgende opcode:

· Noop: De tellerwaarde blijft gelijk

· Up : De tellerwaarde wordt met een verhoogd.

· Down: De tellerwaarde wordt met een verlaagd

· Down2: De tellerwaarde wordt met twee verlaagd

· Rst: De tellerwaarde wordt op nul gezet

64


Adr_Se1(5;O)

Full

Empty

<Adres_Decoder

/'~

.A/'~

I..- Fe_Logic~

Counter .A

"/\

Clk

Figuur 5.15. Decoder_Block

Deze opcodes zijn gecodeerd zoals is weergegeven in tabel VII

Tabel VIII. Waarheidstabel Cnt_Opcode

Cnt Opcode

No Op 000

Up 001

Down 010

Down2 011

Reset 111

De opcode worden uitgevoerd op de flank van de klok die ook naar Counter gaat. Voor

een exacte beschrijving van de timing wordt verwezen naar §4.6

5.5.2.2. FE LOGIC

Dit blok zorgt voor het genereren van de signalen Full, Empty en Elem 0 1. Met wat

eenvoudige combinatorische logica kunnen deze signalen worden afgeleid van de waarde

van de teller.

5.5.2.3. ADRES DECODER

De adres_decoder decodeert het adres dat door de counter wordt geleverd tot de juiste

waarden volgens tabel X.

65

Tabel IX. Waarbeidstabel fe}ogicaVHDL Implementatie LIFO

Tellerwaarde Full IEmpty IElem 0 1

000 011

001 001

010 000

011 000

100 000

101 000

110 100

Tabel X. Waarbeidstabel adres decoder

Tellerwaarde Adres Sel(0:5)

000 000000

001 000001

010 000011

011 000110

100 001100

101 011000

110 110000

Er is bierin te zien dat een patroon van twee I-en door bet adreswoord loopt. Indien

meer dan 6 gebeugenplaatsen bescbikbaar zijn is bet aantal gebeugenplaatsen gelijk aan

bet aantal bits in bet adreswoord.

66


5.6. TIMING.

Tot slot van dit hoofdstuk wil ik de timing van het geheel bespreken. Reeds vermeld

werd dat er gebruik gemaakt dient te worden van een twee fasen klok.

In principe wordt er op de volgende manier getimed:

Bij de stijgende flank van Clk_1 worden waarden in het main memory geschreven. Bij

de stijgende flank van elk_2 worden de registers 1 en 2 van hun nieuwe waarden

voorzien.

Figuur 5.16 geeft het principe van de timing weer.

Rameel _/"----t_J"--__J'-__..J'-__

Register __--' '__~'~_---''---_---J'--

Figuur 5.16. Principe van overall timing

Voordat er kan worden geschreven, moet aan de volgende voorwaarden worden voldaan:

· Nieuwe data moet beschikbaar zijn uit het Register_Block voor het

Memory_Block, dus moet data uit de registers ofvan de buitenwereld beschikbaar

zijn op de Bus In1 en Bus In2 van het Memory block.- - -· Afhankelijk van de gebruikte opcode moet een nieuwe waarde voor TOS_Sel

beschikbaar zijn op de betreffende bus.

· Een nieuwe waarde uit de adres decoder moet gereed zijn.

Deze voorwaarden dienen vervuld te zijn voor de stijgende klokflank van Clk_1

Wat betreft het Iezen geldt dat Adr_Sel nog beschikbaar moet zijn op het moment dat

Clk_2 hoog wordt. De bussen Tos_Out en Tos-1_Out zullen geldige data bevatten enige

tijd nadat Clk_2 hoog werd. Dit resulteert in de timing voorwaarden van het geheugen,

zoals die zijn weergegeven in figuur 5.17.

67


Adr_Se1 ..J VVV' v \.....:.V-=al::.::id__----'l~v '" v 'oJ v'---_

......................................" ".rI ,----...,,, '""

Tos_Se1 ..Bus In! .Bus::::I.1l2 ..

Tos Se1Tos:1_Se,----\.~~--------<,

Figuur 5.17. Timing Memory_Block

We weten nu wanneer de waarden uit de registers beschikbaar moeten zijn en wanneer

de nieuwe waarden voor plaatsing in de registers gereed zijn. Hieruit kunnen we de

voorwaarden voor het register blok afleiden.

Aangezien de waarden van de bussen TOS en TOS-l slechts beperkte tijd beschikbaar

zijn, en daarna hoogohmig worden (om busconflicten te voorkomen) dient het

registerblok deze data op de dalende klokflank van elk_2 moeten overnemen. Daartoe

dient de routeringsinformatie reeds aanwezig te zijn, hetgeen betekend dat Reg_Opcode

v66r het laag worden van elk 2 aanwezig dient te zijn. In dat geval zal Bus Outl en- -Bus_Out2 beschikbaar zijn na het dalen van Clk_2 en ruimschoots voor de stijgende

klokflank van Clk_1. Indien we er van uitgaan dat data van de buitenwereld wordt

meegenomen op het moment dat de switch schakelt dien de data op Data_In beschikbaar

te zijn voor het stijgen van klokflank Clk_2. Een en ander is weergegeven in figuur 5.18.

Omdat we weten dat Adr_Sel aanwezig moet zijn tot na het stijgen van Clk_2, kunnen

we die triggeren voor een nieuwe waarde op het dalen van klokflank van Clk 2. Dit

betekent dat indien we veronderstellen dat de adres decoder binnen het Decoder Block

een asynchroon element is, dat Count_Out getriggered kan worden op de dalende

klokflank van CLK_2. Dit geeft weer een voorwaarde voor Cnt_Opcode, die dus

beschikbaar moet zijn voor deze dalende flank. Het blokje FE Logic laten we gelijktijdig

actief worden met het daadwerkelijk schrijven in het geheugen, dus bij de stijgende flank

van Clk_1. Figuur 5.19 geeft de timing van de het decoder blok.

68


Switl:hMode

Tos_BusTos-i_Bus

RegisterlRegister2

r---+-- .

'---''rl-- ..

.................,-,,--\1--_ .

'---'t---..... . .

·················,---d-----It·························· .••••....••••••••••_--J '--_---f .

....................-------, J..--;f---- .

...................... -1\.+-__ .

....................--- tl----- .

...................... -1\. .

Figuur 5.18. Timing register blok

I

Tel1erwaarde

Adres_Select

~L.:>,----__----JI IL---_)

------""""\ ~--1-----_ ,

(______....J '--_-\\- •••••••••••.••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••.\\------------\\1,.----- .

\X------------1'----- .

-----------.,1/1,.----- ··· ··· .

________--J\'-- .

Figuur 5.19. Timing Decoder_Block

Vit de voorwaarden van de voorgaande blokken voIgt automatisch de timing van het

controller blok. Daarbij geldt dat Reg_Opcode beschikbaar moet zijn voor het stijgen van

Clk_2. Cnt_Opcode moet beschikbaar zijn voor het dalen van Clk_2, maar mag ook

eerder aanwezig zijn. Tos Sel moest voor het stijgen van Clk 1 beschikbaar zijn. Hieruit- -voIgt dat indien zowel Data_In ais de opcode gegeven wordt voor de dalende klokflank

van Clkl (maar na de stijgende!), de timing compleet zal zijn.

69

Tests

6. Tests

De beschrijving van VHDL wordt geverifieerd m.b.v. het simulatie pakket Quicksim van

Mentor Graphics. Zoals reeds werd aangegeven betrof het ook hier een beta - release

van de software, waar een aantal functies nog niet van gerealiseerd waren of nog niet

betrouwbaar werkten. Desondanks waren de mogelijkheden om beschrijvingen te testen

groot.

Er zijn in principe twee mogelijkheden om een ontwerp te testen. De eerste bestaat er

uit dat een pure VHDL - tekst word gecompileerd en gesimuleerd. AIle interne signalen

zijn dan automatisch 'zichtbaar' voor de simulator. Echter met deze release van de

software was het alleen mogelijk om beschrijvingen te testen op een niveau. Er konden

immers geen componenten worden gedeclareerd. Dientengevolge is deze methode van

testen niet bruikbaar voor ons doel.

De tweede mogelijkheid wordt geschapen door de hierarchie grafisch weer te geven, een

'expand' en 'extract' toe te passen, en vervolgens aan de simulator aan te bieden. Op

deze manier zijn de bussen en signalen op het hoogste niveau bekend, en kunnen op

lagere niveaus zogenaamde 'probes' aan signalen en bussen worden gehangen. Op diemanier kunnen deze signalen zichtbaar gemaakt worden.

Tijdens het ontwerpen zijn telkens de afzonderlijke blokken op hun functionaliteit getest.

Deze tests zijn niet opgenomen in dit verslag.

De uiteindelijke test van de LIFO is weI opgenomen. In de appendix C staat de

bijbehorende invoerfile, als mede de uitvoer. De uitvoer is op twee manieren

weergegeven. Ten eerste is er een plot gemaakt van de meest 'elementaire' signalen,

waaraan de functionaliteit van de LIFO af te lezen is. Daarnaast is er een uitvoerfile diebinair de waarden van elk signaal aangeeft.

Met in het achterhoofd de functionaliteit van de LIFO moeten we het volgende testen:

. De correcte werking van de verschillende operaties. Dit betekent dat alle

operaties minstens een maal moeten worden uitgevoerd.

. De status vectoren moeten correcte uitvoer produceren. In de test moet de

LIFO dus van leeg naar vol en weer terug worden

70

Tests

Dientengevolge bestaat onze functionele test uit:

1) Start. Als opcode wordt initieel 'No_op' gebruikt. De stack is leeg, dus 'empty' en

'Elem_0_1' zijn beide hoog, 'Full is laag'

2) Push de waarde '1' op de stack. De stack bevat nu een element. Dat wil zeggen dat

'Empty' nu laag wordt, 'Elem_0_1' blijft hoog.

3) Push de waarde '2' op de stack. De stack bevat nu twee elementen. Dat wil zeggen

dat nu ook 'Elem_0_1' laag wordt.

4) Push de waarde '3' op de stack.

I6) Push de waarde '6' op de stack. De stack is nu vol, dus zal 'Full' hoog worden.

7) Haal bovenste waarde van de stack (POP). Full dient nu weer laag te worden

8) Replace bovenste waarde van de stack met '7' (REPLACE)

9) Maak een kopie (PUSHCOPY) van bovenste waarde. De stack is nu weer vol, dus

Full wordt weer hoog

10) Haal waarde van stack en replace waarde met '8' (POPREPLACE)

11) Verwissel bovenste twee waarden (SWAP)

12) Haal 2 waarden van de stack (POP2)

13) Haal 2 waarden van de stack (POP2)

14) Haal 1 waarde van de stack (POP1)

De stack zal nu leeg zijn.

De bijbehorende invoerfile en uitvoerfiles (inclusief een plot van de traces) isopgenomen in de appendix C.

71

Conclusies

7. Conclusies

De TOP - DOWN strategie blijkt nuttig indien men een globaal inzicht in de

functionaliteit heeft van een complex ontwerp. Door zo'n ontwerp op te delen in

subfuncties krijgt men hanteerbare deelontwerpen. De methode van Hatley en Pirbhai

is daarbij een geschikte tool die ervoor kan zorgen dat de ontwerper overzicht behoudt.

De Bottum Up strategie blijkt nuttig indien men een bepaald model steeds verder wil

uitbreiden naar een complexere functionaliteit. Door telkens meer functies toe te voegen

heeft men in eerste instantie de basis goed in de vingers en kan men van redelijk

eenvoudige structuren verder bouwen aan complexere. De methode van Hatley en

Pirbhai leent zich voor deze strategie veel minder goed. Immers van de meest

eenvoudige ontwerpen kan men zich in een zeer vroeg stadium al een goede voorstelling

maken, hetgeen de methode van Hatley tot een kanon maakt waarmee men op een mug

schiet.

In dit verslag is een eerste aanzet gedaan tot het beschrijven van diverse mogelijke

architecturen voor de implementatie van bouwstenen van IDaSS. Verschillende

architecturen zijn niet aIleen nodig voor verschillende applicaties van een bouwsteen,

maar ook prestatie - eisen spelen een rol bij de keuze tussen verschillende architecturen.

Veelal zal een gekozen architectuur een compromis opleveren tussen snelheid en het

aantal poorten dat een bouwsteen heeft.

Van een RAM werden meerdere mogelijkheden gegeven om een arbitrage probleem op

te lossen. Van het LIFO en het FIFO werden enkele mogelijkheden bekeken, terwijl van

de LIFO ook een VHDL beschrijving werd gemaakt en door simulatie werd geverifieerd.

72

Literatuur

Literatuur

[BLADEL] Bladel, EM.A.M. en H.M. Spierings

Het beschrijven van digitale systemen in VHDL

Eindhoven University of Technology, maart 1991

[HATLEY] Hatley, Derek J. and Imtiaz A. Pirbhai

Strategies for real - time system specification

Dorset House Publishing, New York, 1987

[LIPSET] Lipsett, R., C. Schaefer and C. Ussery.

VHDL: Hardware description and design

Kluwer academic publishers Boston/Dordrecht/London, 1987

ISBN: 0-7923-9030-X

[MENTOl] MENTOR GRAPHICS SYSTEM - 1076™ users manual alpha release

[MENT02] MENTOR GRAPHICS SYSTEM - l076™ QUICKSIM FAMILY

reference manual & supplement

[MENT03] MENTOR GRAPHICS Training workbook for: An introduction to

modeling in VHDL with SYSTEM - 1076™

[RICHTE] Richter, R.

Structured Design of a Queue - Chip with emphasis on its Testability.

Eindhoven University of Technology, Aug. 1989

[VERSCH] Verschueren, A.C.

IDaSS for ULSI, Interactive Design and Simulation System for Ultra Large

Scale Integration.

Eindhoven University Of Technology, Eindhoven, July 1990

Appendix A

Appendix ABeperkingen in de beta - release van de Mentor-Graphics compiler.

De door mij gesignaleerde beperkingen en hun eventuele oplossingen worden hieronderopgesomd:

1) Component: - declarations- instantiations

Deze kunnen niet worden gebruikt. Hierdoor wordt het onmogelijk om tekstueelhierarchie in het ontwerp te brengen. Er zijn twee mogelijke oplossingen. De eerstebestaat hieruit dat men gebruik maakt van de mogelijkheid om een procedure tedefinieren. Deze procedures moeten zijn gedefinieerd in een package. (zie eventueel demanual van Mentor Graphics) In plaats van een instantiatie van een component binnende beschrijving van een systeem gebruikt men dan de invocatie van de procedure. Eenerg elegante methode is dit echter niet.De tweede methode, die tevens overzichtelijk werkt is om hierarchie aan te brengenmiddels het grafische invoersysteem Neted/Symed. De symbolen op het laagste niveauvan de hierarchie dienen een attribuut te krijgen dat aangeeft dat het gedrag van hetsymbool wordt beschreven door een vhdl beschrijving. Voor een complete beschrijvingvan hoe het een en ander in zijn werk gaat verwijs ik naar de verschillende manuals entutorials die binnen de vakgroep aanwezig zijn.

2) Attributen: - Zelf definieren- Standaard attributen zoals:

signal'quiet(t)signal'stable(t)signal'last event(t)signal'delayed(t)

Deze kunnen ook niet worden gebruikt, hetgeen zeer nuttige informatie over signalenonzichtbaar maakt voor de ontwerper. Voor mij was vooral het ontbreken van het"signal'stable(t)" attribuut lastig. Immers je wilt pas data van een bus gebruiken indiendie waarde gedurende enige tijd niet is veranderd. Dit nu moest ik simuleren doorvoldoende lang te wachten met uitlezen van een bus.3) Bij het invokeren van Quicksim is het mogelijk dat men een mededeling krijgt in detrend van:

incorrect port type for hdl instance

Deze melding kon ik niet terugvinden in de manuals, maar blijkt betrekking te hebbenop het type of de naam van pinnen aan symbolen, als voIgt:

. Als je twee pinnen het attribuut 'IN' meegeeft (het attribuut 'IN' of 'OUTmeegeven is verplicht voor quicksim) en beide pinnen met elkaar verbind, levertdit geen foutmelding of zelfs een waarschuwing op van de checker van Neted,

I

Appendix A

noch van 'Expand' of 'Extract'. Quicksim gaat er echter onherroepelijk van 'plat'.· Als je een pin (van een symbool!) een naam geeft die niet overeenstemt metde naam die je eraan geeft in VHDL krijg je dezelfde foutmelding.

4) Ret is binnen Neted en ook binnen VHDL mogelijk om abstracte datatypen tegebruiken. Bijvoorbeeld: Een instance heeft als poort: "Opcode". Ret is dan binnenVHDL toegestaan over een bus van de ene blok naar de andere waarden als 'push', 'pop'e.d. te sturen. Quicksim ondersteund dit maar tot op zekere hoogte. Ret is weItoegestaan om een enkele entity te voorzien van zo'n ingang, en hij mag ook gebruiktworden bij de simulatie van aIleen die entity. (Dus als je een simpel blokje wilt testen).Maak je nu echter een verbinding tussen twee van dit soort blokjes (met neted) danvindt quicksim het niet meer echt goed. De simulator start nog weI op, maar kent opeensde gedefinieerde datastructuur niet meer. Geconcludeerd mag worden dat bij eenhierarchische structuur aIleen bussen met als waarden qsim_state mogen wordengebruikt.

5) Ten aanzien van de bussen zijn er nog enkele kleine probleempjes. Ret zou inQuicksim mogelijk moeten zijn om een bus in een enkele opdracht van een nieuwewaarde te moeten voorzien. Dit gaat echter ergens binnen het pakket fout. Er zijn dantwee mogelijkheden waarop het fout kan gaan:

· Quicksim accepteert een opdracht in de trend van :Force Databus '00110011'

helemaal niet en geeft dus een foutmelding· Quicksim accepteert zo'n opdracht weI, maar voert hem fout uit, d.w.z. t.g.vvorige opdracht heeft de betreffende bus niet de waarde 00110011 maar iets heelanders

Bussen kunnen weI nieuwe waarden worden gegeven, maar dat dient dan bit voor bit tegebeuren. De bedoelde opdracht zal dan luiden:

Force Databus(O) 0Force Databus(l) 0Force Databus(2) 1Force Databus(3) 1Force Databus(4) 0Force Databus(5) 0Force Databus(6) 1Force Databus(7) 1

Pas op!! Ook in de VHDL beschrijving dient een assignment aan een bus bit voor bit tegebeuren!!!! Gebruik dus in plaats van:

Databus < = '00000000'

het volgende statement:For i IN 0 TO 8 LOOPDatabus(i) < = '0';END LOOP

II

Appendix A

Doet men dit niet dan is men ook weer niet zeker van een goede toekenning vanwaarden!

De volgende mankementen heb ik zelf niet aan den lijve ondervonden maar de herenSpiering en van Bladel weI. Ik verwijs daarom naar hun verslag.

6) Guard

7) Alias

8) Unconstrained array's, het gevolg hiervan is dat het ook niet mogelijk is sub - typeste definieren

9) Type conversion

10) Concatenation (&)

Het dient vermeld te worden dat bovenstaande lijst niet voIledig zal zijn, met name ophet gebied van de signaal attributen. Bovendien zijn niet aIle mankementen even ernstig.Het is echter zeer vervelend dat bussen waarden krijgen toegekend die. nietovereenstemmen met de waarden die de gebruiker aan een bus probeert te geven.

III

Appendix B: Adres decoder

APPENDIX B.VHDL BESCHRIJVINGEN

ADRES DECODER

USE std.standard.ALL;USE std.mentor_base.ALL;USE work.adres_decoder_pkg.ALL;

ENTITY Adres Decoder IS

•• Gebruikt packages standard.- mentor base_. en eigen package

PORT (Count InAdr Sal); -

END Adres_Decoder;

: IN Bus_LRL;: OUT Bus RL

.- LRL = ROUND(Log(RL»-- RL = RamLength (=6)

ARCHITECTURE behavior1 OF Adres Decoder IS

BEGIN

: PROCESS (Count In)BEGIN -CASE Count In IS

WHEN "000" =>

Adres_Decoder_Oper

Adr Sel(O) < = '0' AFTER Adr Delay;Adr-Sel(1) < = '0' AFTER Adr-Delay;Adr-Sel(2) < = '0' AFTER Adr-Delay;Adr=Sel(3) < = '0' AFTER Adr=Delay;Adr Sel(4) < = '0' AFTER Adr Delay;Adr=Sel(5) < = '0' AFrER Adr=Delay;

WHEN "001" => Adr Sel(O) <= '1' AFTERAdr Delay;Adr-Sel(1) < = '0' AFTER Adr-Delay;Adr-Sel(2) < = '0' AFTER Adr-Delay;Adr-Sel(3) <= '0' AFTER Adr-Delay;Adr=Sel(4) < = '0' AFTER Adr=Delay;Adr_Sel (5) < = '0' AFTER Adr_Delay;

WHEN "010" = > Adr Sel(O) < = '1' AFTER Adr Delay;Adr-Sel(1) < = '1' AFTER Adr-Delay;Adr-Sel(2) < = '0' AFTER Adr-Delay;Adr=Sel(3) < = '0' AFTER Adr=Delay;Adr Sel(4) < = '0' AFTER Adr Delay;Adr=Sel(5) < = '0' AFTER Adr=Delay;

WHEN "011" = > Adr Sel(O) < = '0' AFTER Adr Delay;Adr-SeI(1) < = '1' AFTER Adr-Delay;Adr=Sel(2) < = '1' AFTER Adr=Delay;Adr SeI(3) < = '0' AFTER Adr Delay;Adr-Sel(4) < = '0' AFTER Adr-Delay;Adr=Sel(5) < = '0' AFTER Adr=Delay;

WHEN "100" = > Adr Sel(O) < = '0' AFTER Adr Delay;Adr=Sel(1) < = '0' AFTER Adr=Delay;Adr Sel(2) < = '1' AFTER Adr Delay;Adr-Sel(3) <= '1' AFTER Adr-Delay;Adr-Sel(4) < = '0' AFTER Adr-Delay;Adr=Sel(5) < = '0' AFTER Adr=Delay;

IV


WHEN "101" = > Adr Sel(O) < = '0' AFTER Adr Delay;Adr=Sel(1) < = '0' AFTER Adr=Delay;Adr_Sel(2) < = '0' AFTER Adr_Delay;Adr Sel(3) < = '1' AFTER Adr Delay;Adr-Sel(4) < = '1' AFTER Adr-Delay;Adr=Sel(5) < = '0' AFTER Adr=Delay;

WHEN "110" => Adr_Sel(O) < = '0' AFTER Adr_Delay;Adr Sel(1) < = '0' AFTER Adr Delay;Adr-Sel(2) < = '0' AFTER Adr-Delay;Adr=Sel(3) < = '0' AFTER Adr=Delay;Adr_Sel(4) < = '1' AFTER Adr_Delay;Adr_Sel(5) <= '1' AFTER Adr_Delay;

WHEN OTHERS = > NULL;END CASE;

END PROCESS Adres_Decoder_Oper;

Init : PROCESSBEGIN

FOR i IN 0 TO RL-1 LOOPAdr Sel(i) < = '0';END LOOP;WAIT;

END PROCESS Init;

END behavior1;

v

ADRES DECODER PACKAGE

USE std.standard.ALL;USE std.mentor_base.ALL;

PACKAGE adres_decoder_pkg IS


CONSTANTCONSTANTCONSTANTCONSTANT

RWRLLRLAdr_Delay

: INTEGER: INTEGER: INTEGER: Time

:= 8;:= 6;:= 3;:= 2ns;

TYPETYPETYPE

BUS RLDataBUS LRL

IS ARRAY(RL-1 DOWNTO 0)IS ARRAY(RW-1 DOWNTO 0)IS ARRAY(LRL-1 DOWNTO 0)

OF qsim state;

OF qsim=state;OF qsim_state;

VI

CLOCK

USE std.standard.ALL;USE std.mentor_base.ALL;USE work.clock_pkg.ALL;

Appendix B: Clock

ENTITY Clock ISPORT (

Clk 1Clk 2); -

END Clock;

: OUT qsim state;: OUT qsim=state

ARCHITECTURE behavior1 OF Clock ISBEGIN

Clk1 Operation: PROCESS- BEGIN

Clk_1 < = TRANSPORT '1' ;WAIT FOR Duty Period;Clk_1 < = TRANSPORT '0' ;WAIT FOR Off Duty Period;

END PROCESS Clk1_0peration;

Clk2_Operation : PROCESSBEGIN

Clk_2 < = TRANSPORT '0' ;WAIT FOR Twice Duty Period;Clk 2 < = TRANSPORT '1' ;WAIT FOR Duty Period;Clk_2 < = TRANSPORT '0' ;WAIT FOR Duty Period;

END PROCESS Clk2_Operation;

Init

END behavior1;

: PROCESSBEGIN

Clk 1Clk-2WAIT;

END PROCESS Init;

<= '1 ';<= '0';

VII

CLOCK PACKAGE


PACKAGE clock_pkg IS

CONSTANT Duty PeriodCONSTANT Twice Duty PeriodCONSTANT Off_Duty_Period

END clock_pkg;

: time .- 5 ns;: time .- 10 ns;: time .- 15 ns;

VIII

Appendix B: Clock

Appendix B: Counter

COUNTER

USE std.standard.ALL;USE std.mentor_base.ALL;USE work.my_counter_pkg.ALL;

ENTITY my_counter IS

PORT (ClkCnt OpcodeCount Out); -

END mLcounter;

: IN: IN: OUT

qsim state;Cnt_Mnmonicbus3;Bus Irl

ARCHITECTURE behavior1 OF my_counter IS

SIGNAL tempcount: integer;

BEGINcounter_operation: PROCESS(CLK)

BEGINIF CLK = '0' THEN

CASE tempcount ISWHEN 0 = > CASE Cnt Opcode IS

WHEN "001" => Tempcount <= Tempcount+1;Count Out(O) < = '1 ';Count-Out(1) < = '0';Coun(Out(2) < = '0';

-- Waarde voor UP III

WHEN "010" I "011" = > ASSERT falseREPORT "Something wrong UP";


WHEN 1 = > CASE Cnt Opcode ISWHEN "001" = > Tempcount< =Tempcount+ 1;

Count Out(O) < = '0';Count-Out(1) < = '1';Count-Out(2) < = '0';

- Waarde voor UP-I!!

WHEN "010" = > Tempcount< =Tempcount-1;Count Out(O) < = '0';Count-Out(1) < = '0';Count-Out(2) < = '0';

- Waarde voor down III

WHEN "011" = > ASSERT falseREPORT "Something wrong DOWN!";


WHEN 2 = > CASE Cnt_Opcode ISWHEN "001" = > Tempcount< =Tempcount+ 1;

Count Out(O) < = '1';Count-Out(1) < = '1';Coun(Out(2) < = '0';

-- Waarde voor UP !!!

IX

Appendix B: Counter

WHEN "010" = > Tempcount< =Tempcount-l;Count Out (0) < = '1 ';Count-Out(l) < = '0';Count-Out(2) < = '0';

- Waarde voor down !!!

WHEN "011" = > Tempcount< =Tempcount-2;Count Out(0) < = '0';Count-Out(l) < = '0';Count-Out(2) < = '0';

•• Waarde voor down2!1!


WHEN 3 = > CASE Cnt Opcode ISWHEN "DOl" = > Tempcount< =Tempcount+ 1;

Count Out(0) < = '0';Coun(Out(l) < = '0';Count Out(2) < = '1 ';

- Waarde voor UP-Ill

WHEN "OlD" = > Tempcount< =Tempcount-l;Count Out(0) < = '0';Coun(Out(l) < = '1';Count Out(2) < = '0';

-- Waarde voor down !!l

WHEN "011" = > Tempcount < = Tempcount-2;Count Out(0) < = '1 ';Count-Out(l) < = '0';Count-Out(2) < = '0';

-- Waarde voor down2!!!


WHEN 4 = > CASE Cnt Opcode ISWHEN "001" = > Tempcount< =Tempcount+ 1;

Count Out(0) < = '1';Count-Out(l) < = '0';Count-Out(2) < = '1 ';

•• Waarde voor UP-!!!

WHEN "OlD" = > Tempcount< =Tempcount-l;Count Out(0) < = '1 ';Count-Out(l) <= '1';Coun(Out(2) < = '0';

-- Waarde voor down !!!

WHEN "011" = > Tempcount < =Tempcount-2;Count Out(0) < = '0';Count-Out(l) <= '1';Count-Out(2) < = '0';

- Waarde voor down2!!!


WHEN 5 = > CASE Cnt Opcode ISWHEN "001" => Tempcount<=Tempcount+l;

Count Out(0) < = '0';Count-Out(l) < = '1';Coun(Out(2) < = '1 ';

x

Appendix B: Counter

-- Waarde voor UP III

WHEN "010" = > Tempcount< =Tempcount-l;Count Out(O) < = '0';Count-Out(l) < = '0';Count-Out(2) < = '1';

- Waarde voor down !!!

WHEN "011" = > Tempcount< =Tempcount-2;Count Out(O) < = '1';Count-Out(l) < = '1';Count-Out(2) < = '0';

-- Waarde voor down2!!1


WHEN 6 = > CASE Cnt Opcode ISWHEN "001" = > Assert false

REPORT "Something wrong UP";WHEN "010" => Tempcount<=Tempcount-l;

Count Out(O) < = '1';Count-Out(l) < = '0';Count-Out(2) < = '1';

-- Waarde voor down !!!

WHEN "011" = > Tempcount< = Tempcount-2;Count Out(O) < = '0';Count-Out(l) < = '0';Count-Out(2) < = '1 ';

-- Waarde voor dowrl2!!!



END IF;END PROCESS counter_operation;

RST_Operation

Init

END behaviorl;

: PROCESS(Cnt Opcode)BEGIN -IF Cnt_Opcode = "111" THEN

END IF;END PROCESS RST_Operation;

: PROCESSBEGINFor i IN 0 TO LRL-l LOOPCount Out(i) < = '0';END LOOP;tempcount < = 0;wait;END PROCESS init;

Tempcount < = 0;FOR i IN 0 TO LRL-l LOOPCount OutO) < = '0';END COOP;

XI

COUNTER PACKAGE


Appendix B: Counter

CONSTANTCONSTANTCONSTANT

RLRWLRL

: Integer := 6;: Integer := 8;: Integer := 3;

TYPE Bus LRL IS ARRAY(LRL-1 DOWNTO 0)TYPE Cn('Mnmonicbus3lS ARRAY(2 DOWNTO 0)

XII

OF qsim state;OF qsim=state;

Appendix B: Controller

CONTROLLER

USE std.standard.ALL;USE std.mentor_base.ALL;USE work.controller_pkg.ALL;

ENTITY controller IS

PORT (Clk 1Clk-2Cnt-OpcodeReg- OpcodeTos -SelResetOpcode);

: IN: IN: OUT: OUT: OUT: IN: IN

qsim state;qsim-state;Cnt Mnmonicbus3;Reg-='Mnmonicbus2;Bus2;qsim_state;Ctrl Mnmonicbus3

END controller;

ARCHITECTURE behavior1 OF controller IS

BEGIN

Reset_Operation : PROCESS(reset)BEGINIF reset = '1' THEN Cnt Opcode(O) < = '1' AFTER reset delay;

Cnt-Opcode(1) < = '1' AFTER rese(delay;Cnt-Opcode(2) < = '1' AFTER reset delay;Reg-='Opcode (0) < = '1' AFTER reset::.delay;Reg_Opcode(1) < = '1' AFTER reset_delay;

END IF;END PROCESS reset_operation;

Ctrl_Operation : PROCESS(Clk 1)BEGINIF Clk 1 = '0' THEN

- CASE (Opcode) IS•• Push:WHEN "001"

- Pop:WHEN "010"

- Replace

= > Cnt Opcode(O) < = '1' AFTER Ctrl Delay;Cnt Opcode(1) < = '0' AFTER Ctrl Delay;Cn(Opcode(2) < = '0' AFTER Ct(Delay;

- waarde voor up

Reg Opcode(O) < = '0' AFTER Ctrl Delay;Reg- Opcode(1) < = '0' AFTER Ctrl-Delay;

- waarcte voor dataln naar bus1 -

Tos Sel(O) < = '1' AFTER Ctrl Delay;Tos=Sel(1) < = '0' AFTER CtrCDelay;

= > Cnt Opcode(O) < = '0' AFTER Ctrl Delay;Cnt Opcode(1) < = '1' AFTER Ctrl Delay;Cn(Opcode(2) < = '0' AFTER CtrCDelay;

-- waarde voor down

Tos Sel(O) < = '0' AFTER Ctrl Delay;Tos=Sel(1) <= '0' AFTER CtrCDelay;

XIII

WHEN "011"

-- Popreplace:WHEN "100"

-- pop2WHEN "101"

-- swap:WHEN "110"

-- pushcopy:WHEN "111"

WHEN "000"


=> Cnt Opcode(O) < = '0' AFTER Ctrl Delay;Cnt Opcode(l) < = '0' AFTER Ctrl Delay;Cn(Opcode(2) < = '0' AFTER Ctrl=Delay;

-- waarde voor no_op

Reg Opcode(O) < = '0' AFTER Ctrl Delay;Reg=Opcode(l) < = '0' AFTER CtrCDelay;

- waarde voor dataln naar bus1

Tos Sel (0) < = ' l' AFTER Ctrl Delay;Tos=Sel(l) < = '0' AFTER Ctrl=Delay;

= > Cnt Opcode(o) < = '0' AFTER Ctrl Delay;Cnt Opcode(l) < = '1' AFTER Ctrl Delay;Cnt-Opcode (2) < = '0' AFTER Ctrl-Delay;

-- waarde voor down -

Reg Opcode(O) < = '0' AFTER Ctrl Delay;Reg-Opcode(l) < = '0' AFTER Ctrl-Delay;

-- waarde voor dataln naar busl -

Tos Sel(O) < = '1' AFTER Ctrl Delay;Tos=Sel(l) < = '0' AFTER Ctrl=Delay;

=> Cnt Opcode(O) < = '1' AFrER Ctrl Delay;Cnt Opcode(l) < = '1' AFTER Ctrl Delay;Cnt-Opcode(2) < = '0' AFTER Ctrl-Delay;

- waarde voor down2 -

Tos Sel(O) < = '0' AFTER Ctrl Delay;Tos=Sel(l) < = '0' AFTER CtrCDelay;

=> Cnt Opcode (0) < = '0' AFTER Ctrl Delay;Cnt Opcode(l) < = '0' AFTER Ctrl Delay;Cn(Opcode(2) < = '0' AFTER Ctrl=Delay;

- waarde voor no_op

Reg Opcode(O) < = '1' AFTER Ctrl Delay;Reg-Opcode(l) < = '0' AFTER Ctrl-Delay;

-- waarde voor swap -

Tos Sel(O) < = '1' AFTER Ctrl Delay;Tos=Sel(l) < = '1' AFTER CtrCDelay;

=> Cnt Opcode(O) < = '1' AFTER Ctrl Delay;Cnt Opcode(l) < = '0' AFTER Ctrl Delay;Cn(Opcode(2) < = '0' AFTER Ctrl=Delay;

- waarde voor up

Reg Opcode(O) < = '0' AFTER Ctrl Delay;Reg-Opcode(l) < = '1' AFrER Ctrl-Delay;

- waarde voor pushcopy -

Tos Sel(O) < = '1' AFTER Ctrl Delay;Tos=Sel(l) < = '0' AFTER Ct(Delay;

= > Cnt_Opcode(O) < = '0' AFTER Ctrl_Delay;

XIV

Init

END behavior1;


Cnt Opcode(1) < = '0' AFTER Ctrl Delay;Cnt-Opcode(2) < = '0' AFTER Ctrl-Delay;

-- waarde voor no_op -

Reg Opcode(O) < = '0' AFTER Ctrl Delay;Reg-Opcode(1) < = '0' AFTER Ctrl-Delay;

-- waarde voor dataln naar bus1 -

Tos Sel(O) < = '0' AFTER Ctrl Delay;Tos=Sel(1) < = '0' AFTER CtrCDelay;


END IF;END PROCESS Ctrl_Operation;

: PROCESSBEGIN

Cnt_Opcode(O) < = '0';Cnt_Opcode(1) < = '0';Cnt Opcode(2) < = '0';Reg-='Opcode(O) < = '0';Reg_Opcode(1) < = '0';Tos_Sel(O) <= '0';Tos_Sel(1) < = '0';wait;END PROCESS Init;

xv

CONTROLLER PACKAGE


PACKAGE controller_pkg IS



TYPETYPETYPETYPE

RWCtrl_DelayReset_Delay

Reg Mnmonicbus2Cnt -Mnmonicbus3Ctrl Mnmonicbus3Bus2

: Integer: Time: Time

:= 8;:= 2ns;:= 2ns;

IS ARRAY(1 DOWNTO 0)IS ARRAY(2 DOWNTO 0)IS ARRAY(2 DOWNTO 0)IS ARRAY(1 DOWNTO 0)

OF qsim state;OF qsim=state;OF qsim state;OF qsim=state;

END controller_pkg;

XVI

Appendix E: FE Logic

FE - LOGIC

USE std.standard.ALL;USE std.mentor_base.ALL;USE work.fe_logic_pkg.ALL;

ENTITY fe_logic IS

PORT (Clk 1Count InFullEmptyElem 0 1);

: IN: IN: OUT: OUT: OUT

qsim state;Bus LRL;qsim state;qsim state;qsim-state

END fe_logic;

ARCHITECTURE behavior1 OF fe_logic IS

BEGIN

fe_logic_oper : PROCESS(Clk 1)BEGIN -

IF Clk 1 = '1' THENCASECount in IS

WHEN "000" => Empty < = '1' AFTER Fe Delay;Elem 0 1 < = '1' AFTER Fe Delay;Full - - < = '0' AFTER Fe~Delay;

WHEN "001" => Empty < = '0' AFTER Fe Delay;Elem 0 1 < = '1' AFTER Fe Delay;Full - - < = '0' AFTER Fe~Delay;

WHEN "010" I "011" I "100" I "101" => Empty < = '0' AFTER Fe Delay;Elem 0 1 < = '0' AFTER Fe Delay;Full - - < = '0' AFTER Fe~Delay;

Init

END behavior1;

WHEN "110" => Empty < = '0' AFTER Fe Delay;Elem_0_1 < = '0' AFTER F~Delay;Full < = '1' AFTER Fe_Delay;

WHEN OTHERS => NULL;END CASE;END IF;END PROCESS fe_logic_oper;

: PROCESSBEGIN

Full <= '0';Empty <= '1';Elem_0_1 < = '1 ';

WAIT;END PROCESS Init;

XVII

Appendix B: FE Logic

FE-LOGIC PACKAGE


CONSTANTCONSTANT

fe_delayIrl

: Time: Integer

:= 2ns;:= 3;

TYPE Bus_lrllS ARRAY(LRL-1 DOWNTO 0) OF qsim_state;

-------------- XVIII --------------

Appendix B: Rameel

RAMCEL

USE std.standard.ALL;USE std.mentor base.ALL;USE work.rameei_pkg.ALL;

ENTITY Rameel IS

PORT (DinD-Outwrite);

: IN: OUT: IN

data;data;qSim_state

END Rameel;

ARCHITECTURE behavior1 OF Rameel IS

Signal Ram_Slice: data;

BEGIN

Write_Operation: PROCESS(Write)BEGIN

IF Write = '1' THENFor i IN 0 TO RW·1 LOOPRam Sliee(i) < = D In(i) AFTER Write Delay;ENDLOOP; - -

END IF;END PROCESS Write_Operation;

Out_Operation : PROCESS(Ram Slice)BEGIN -

For i IN 0 TO RW-1 LOOPD Out(i) < = Ram Slice (i);END LOOP; -

END PROCESS Out_Operation;

Init : PROCESSBEGIN

FOR i IN 0 TO RW·1 LOOPRam_Slice (i) < = '0';D Out(i) < = '0';END LOOP;wait;

END PROCESS (nit;

END behavior1;

XIX

RAMCEL PACKAGE


PACKAGE Ramcel_pkg IS

Appendix B: Rameel


Write_DelayRead_DelayRW

: Time: Time: Integer

:= 2ns;:= 2ns;:= 8;

TYPE

END Ramcel_pkg;

Data IS ARRAY (RW-1 DOWNTO 0) OF qsim_state;

xx

Appendix B: Register

REGISTER

USE std.standard.ALL;USE std.mentor base.ALL;USE work.reg_ister_pkg.ALL;

ENTITY reg_ister IS

PORT (Reg InReg-OutClk -);

: IN: OUT: IN

data;data;qsim_state

END reg_ister;

ARCHITECTURE behavior1 OF reg_ister IS

BEGIN

Reg_Operation

Init

END Behavior1;

: PROCESS(clk)BEGIN

IF Clk = '0' THENFOR i IN 0 to RW·1 LOOPReg Out (i) < = TRANSPORT Reg In(i) AFTER Reg Write Delay;ENDLOOP; - --

END IF;END PROCESS Reg_Operation;

: PROCESSBEGIN

FOR i IN 0 TO RW·1 LOOPReg_Out(i) < = 'Z';END LOOP;wait;

END PROCESS Init;

XXI

REGISTER PACKAGE


Appendix B: Register

CONSTANTCONSTANT

Reg Write DelayRW- -

: Time: Integer

:= 2ns;:= 8;

TYPE data IS ARRAY (RW-1 DOWNTO 0) OF qsim_state;

XXII

Appendix B: Rd_Sel

RD SEL

USE std.standard.ALL;USE std.mentor_base.ALL;USE work.rd_sel_pkg.ALL;

ENTITY rd sel ISPORT f

Bus InBus-Out1Bus Out2Clk -

Adr Sel); -

END Rd_sel;

: IN: OUT: OUT: IN: IN

data;data;data;qsim_state;bus2

ARCHITECTURE behavior1 OF Rd Sel ISBEGIN -

Rd Sel Operation : PROCESS(clk)- - BEGIN

IF elk = '1' THENCASE (Adr_Sel) ISWHEN "01" => For i IN 0 TO RW·1 LOOP

Bus Out1 (i) < = transport Bus In (i) AFTER Bus Setup Time;END LOOP; - --

WHEN "11" = > For i IN 0 TO RW-1 LOOPBus Out2(i) < = transport Bus In(i) AFTER Bus Setup Time;END LOOP; - --

WHEN "00" => NULL;

WHEN "10" => NULL;

WHEN OTHERS => ASSERT FalseREPORT "Illegal values Address Select Unes"SEVERITY Note;

END Case;

ELSE IF elk = '0' THENFOR i IN 0 TO RW-1 LOOPBus Out1 (i) < = 'Z' AFTER Bus Hold Time;Bus- Out2(i) < = 'Z' AFTER Bus-Hold-Time;END LOOP; - -

END IF;End IF;

END PROCESS Rd_Sel_Operation;

Init : PROCESSBEGINFOR i IN 0 TO RW·1 LOOP

Bus Out1 (i) < = 'Z';Bus- Out2~) < = 'Z';ENDLOOP;

wait;END PROCESS Init;

END behavior1;

------------- XXIII -------------

Appendix B: Rd_Sel

RD-SEL PACKAGE

USE std.standard.ALL;USE std .mentor_base.ALL;

CONSTANTCONSTANTCONSTANTCONSTANTCONSTANTCONSTANT

Read DelayWrite-DelayBus Setup TimeBus-Hold TimeRWRam_Length

: Time: Time: Time: Time: Integer: Integer

:= 2ns;:= 2ns;:= 2ns;:= 3ns;:= 8;:= 8;

TYPETYPE

data IS ARRAY (RW-1 DOWNTO 0)bus2 IS ARRAY (1 DOWNTO 0)

OF qsim_state;OF qsim_state;

-------------- XXIV --------------

Appendix B: Switch

SWITCH

USE std.standard.ALL;USE std.mentor base.ALL;USE work.switch_pkg.ALL;

ENTITY switch IS

PORT (Data InReg In1Reg-ln2Data Out1Data-Out2ClkReg Opcode); -

: IN: IN: IN: OUT: OUT: IN: IN

data;data;data;data;data;qsim state;Mnmonicbus2

END switch;

ARCHITECTURE behavior1 OF switch IS

SIGNAL switchmode

BEGIN

: opermode;

swi mode : PROCESS(clk)BEGINIF clk = '1' THEN

CASE (Reg Opcode) ISWHEN "00" = > switchmode < = mode1;

•• Waarde voor data in naar busOut1!1!

WHEN "01" => switchmode < = mode2;

- waarde voor swap opearatie!!

WHEN "10" => switchmode < = mode3;

- Waarde voor pushcopy operatie!

WHEN OTHERSEND Case;

= > NULL;

END If;END PROCESS swi_mode;

transfer : PROCESS(Data In,Reg In1,Reg In2)- BEGiN -

CASE switchmode ISWHEN mode1

WHEN mode2

WHEN mode3

END Case;END PROCESS transfer;

=> FOR i IN 0 TO RW-1 LOOPData Out1(i) < = Data InQ);

END LOOP;- -= > FOR i IN 0 TO RW-1 LOOP

Data Out1 (i) < = Reg In2(i);Data- Out2(i) < = Reg-ln1 Q);

END LOOP; - -=> FOR i IN 0 TO RW-1 LOOP

Data Out1 (i) < = Reg In1(i);END LOOP;- -

RST_Operation : PROCESS(Reg_Opcode)

xxv

Appendix B: Switch

BEGIN

Init

END behavior1;

IF Reg_Opcode = "11" THEN

END IF;END PROCESS RST_Operation;

: PROCESSBEGIN

FOR i IN 0 TO RW-1 LOOPData Out1 (i) < = '0';Data-Out2(i) < = '0';END-LOOP;WAIT;

END PROCESS Init;

FOR i IN 0 TO RW-1 LOOPData Out1 (i) < = '0';Data-Out2(i) < = '0';END-LOOP;

-------------- XXVI --------------

Appendix B: Switch

SWITCH PACKAGE


PACKAGE switch_pkg IS

CONSTANT

TYPETYPETYPE

END switch_pkg;

RW

dataMnmonicbus2opermode

: INTEGER

IS ARRAY (RW-1 DOWNTO 0)IS ARRAY (1 DOWNTO 0)IS (mode1,mode2,mode3);

:= 8;


-------------XXVII-------------

Appendix B: Wr_Set

WRITE SELECT

USE std.standard.ALL;USE std.mentor_base.ALL;USE work.wr_sel_pkg.ALL;

ENTITY Wr Sel IS

PORT (Bus In1Bus In2Adr -SelTos SelClk -

Write CelBus Out); -

: IN: IN: IN: IN: IN: OUT: OUT

data;data;bus2;bus2;qsim_state;qsim state;data -

ENDWr_Sel;

ARCHITECTURE behavior1 OF Wr Sel IS

BEGIN

Wr Sel Operation: PROCESS(Clk)- - BEGIN

IF elk = '1' THENCASE (Adr Sel) ISWHEN "01" = > CASE (TOS_Sel) IS

WHEN "00" => NULL;

WHEN "01" = > For i IN 0 TO RW-1 LOOPBus Out(i) < = Bus In1 (i) ;

END LOOP; -Write_Cel < = Transport '1' After Write_Delay;

WHEN "11" => For i IN 0 TO RW·1 LOOPBus Out(i) < = Bus In1(i) ;

END LOOP; -Write_Cel < = Transport '1' After Write_Delay;

WHEN "10" = > NULL;

WHEN OTHERS = > ASSERT FalseREPORT "Illegal values TOS. sel. lines"SEVERITY note;

END CASE;

WHEN "11" => CASE (TOS Sel) ISWHEN "00" => NULL;

WHEN "01" = > NULL;

WHEN "10" => NULL;

WHEN "11" => For i IN 0 TO RW-1 LOOPBus Out(i) < = Bus In2(i);

END LOOP; -

--------------XXVIII-------------

Appendix B: Wr_Set

Write_Cel < = Transport '1' After Write_Delay;

WHEN OTHERS => ASSERT FalseREPORT "Illegal values TOS. sel. lines"SEVERITY note;

END CASE;

WHEN "00" = > NULL;

WHEN "10" => NULL; -- NIET GES.

WHEN OTHERS => ASSERT FalseREPORT "Illegal values Addr. sel. lines"SEVERITY note;

END CASE;

ELSE IF Clk = '0' THENFOR i IN 0 TO RW-1 LOOP

Bus_OutO) < = 'Z';END LOOP;Write_Cel < = '0' AFTER Write_Delay;

END IF;END IF;END PROCESS Wr_Sel_Operation;

Init : PROCESSBEGIN

FOR i IN 0 TO RW-1 LOOPBus Out(i) < = 'Z';

END LOOP; -Write_Cel < = '0';wait;

END PROCESS Init;

END behavior1;

------------- XXIX -------------

WRITE SELECT PACKAGE


Appendix B: Wr_Set

CONSTANTCONSTANTCONSTANTCONSTANT

Write_DelayRead DelayRam'=-LengthRW

: Time: Time: Integer: Integer

:= 2ns;:= 2ns;:= 8;:= 8;

TYPETYPE

DataBus2

IS ARRAY (RW-1 DOWNTO 0)IS ARRAY (1 DOWNTO 0)

xxx


Appendix C

# Dit is een file met test - stimuli om de complete lifo te testen# Voor de opcode geldt:# No_Op 000# Push 001# Pop 010# Replace 011# Popreplace 100# Pop2 101# Swap 110# Pushcopy 111

# Voor Cnt Opcode (er kan een probe aan worden gehangen) geldt:# No Op 000# Up- 001# Down 010# Down2 011# Reset 111

# Voor Reg_Opcode (Kan ook een probe aan worden gehangen) geldt:

Appendix C

####

Data into bus1SwapPushCopyReset

00011011

Transcript onEnv /InitializePROBe adr Sel -30.0,3S.0,ViewPROBe cnt-opcode -20.0,-32.S,ViewPROBe reg:opcode 22.S.-37.S,View

VIEw Sheet" 'Memory Block'PROBe Adsell -SS.0,-90.0,View#2PROBe Adsel2 -S7.S,-SO.0,View#2PROBe Adsel3 -SS.0,-10.0,View#2PROBe Adsel4 -S7.S,30.0,View#2PROBe AdselS -SS.0,70.0,View#2PROBe Adsel6 -S7.S,110.0,View#2

PROBe Din Rl -20.0,-7S.0,View#2PROBe Din-R2 -22.S,-3S.0,View#2PROBe Din-R3 -22.S,S.O,View#2PROBe Din=R4 -22.S,4S.0,View#2PROBe Din Rs -22.S,8S.0,View#2PROBe Din=R6 -22.S,12S.0,View#2

PROBe wrl -20.0,-8S.0,View#2PROBe wr2 -22.S,-45.0,View#2PROBe wr3 -22.5,-S.0,View#2PROBe wr4 -22.S,3S.0,View#2PROBe wrS -20.0,7S.0,View#2PROBe wr6 -22.S,11S.0,View#2

PROBe Dout Rl 17.5,-75.0,View#2PROBe Dout-R2 2O.0,-3S.0,View#2PROBe Dout-R3 22.5,5.0,View#2PROBe Dout-R420.0,45.0,View#2PROBe Dout-R5 20.0,85.0,View#2PROBe Dou(R6 17.5,12S.0,View#2

PROBe GND -67.5,107.5,View#2

-------------- XXXI

Appendix C

View sheet " 'Register_Block'

PROBe reg_Out2 10.0,-7.5,View#3

# Verdere initializatie...Force Opcode(O) 0Force Opcode(1) 0Force Opcode(2) 0

Force Reset 0

Force Data In (0) 0Force Data-In(1) 0Force Data-In (2) 0Force Data-In(3) 0Force Data-In(4) 0Force Data-In(5) 0Force Data-ln(6) 0Force Data=In (7) 0Clock Period 20Force Clk_1 1 0 -RepeatForce Clk_1 OS-RepeatForce Clk_2 0 0 -RepeatForce Clk 2 1 10 -RepeatForce Clk=2 0 15 -Repeat

Trace GNDTrace Clk 1 Clk 2 Data In Opcode Reset Data Out Full Empty Elem 0 1trace GND - - - - -

Trace Bus 1 Bus 2 Tos Bus Tos-1 Bus Adr Sel Tos Sel Cnt Opcode Reg Opcodetrace GND - - - - - - -

trace Adsel1 Adsel2 Adsel3 Adsel4 Adsel5 Adsel6trace GNDTrace Din R1 Din R2 Din R3 Din R4 Din R5 Din R6trace GND - - - - -

Trace wr1 wr2 wr3 wr4 wr5 wr6Trace GNDtrace Dout R1 Dout R2 Dout R3Dout R4Dout R5Dout R6Trace GND - - - - -

List binary Clk_1 Clk_2 Data_In Opcode Reset Data_Out Full Empty Elem_0_1 -c

RUN 21

# Push Operatie:Force Opcode(O) 1Force Opcode(1) 0Force Opcode(2) 0

Force Data In(O) 1Force Data=ln(1) 0Force Data In (2) 0Force Data=ln(3) 0Force Data In(4) 0Force Data-In(5) 0Force Data-In (6) 0Force Data=In (7) 0

RUN 20# Er staat Nu 1 element op de stack.

Force Data In (0) 0Force Data='n(1) 1Force Data_In (2) 0

--------------XXXII--------------

Appendix C

Force Data In (3) 0Force Data-In (4) 0Force Oata-ln(5) 0Force Data-In(6) 0Force Data='n (7) 0

RUN 20# Er staan nu 2 elementen op de stack

Force Data In (0) 1Force Oata-ln(1) 1Force Data-In(2) 0Force Data-In(3) 0Force Data-In (4) 0Force Data-In (5) 0Force Data-In (6) 0Force Data=In (7) 0


Force Data In (0) 0Force Data-In(1) 0Force Data-In(2) 1Force Data-In (3) 0Force Data-In(4) 0Force Data-In (5) 0Force Data-In (6) 0Force Data=In (7) 0


Force Data In(O) 1Force Data-In(1) 0Force Data-In(2) 1Force Data-In (3) 0Force Data-In (4) 0Force Data-In(5) 0Force Data-In(6) 0Force Data-In (7) 0RUN 20 -

# Er staan nu 5 elementen op de stack

Force Data In (0) 0Force Data-In(1) 1Force Data-In(2) 1Force Data-In (3) 0Force Data-In(4) 0Force Data-In (5) 0Force Data-In (6) 0Force Data-In(7) 0RUN 20 -

# Er staan nu 6 elementen op de stack

# Pop Operatie:Force Opcode(O) 0Force Opcode(1) 1Force Opcode(2) 0RUN 20

# Er staan nu nag 5 elementen op de stack

# Replace Operatie:Force Opcode(O) 1

-------------XXXIII-------------

Appendix C

Force Opcode(1) 1Force Opcode(2) 0

Force Data In (0) 1Force Data-In(1) 1Force Data-In(2) 1Force Data-In(3) 0Force Data-In(4) 0Force Data-ln(5) 0Force Data-In (6) 0Force Data=In (7) 0run 20

# Er staan nag steeds 5 elementen op de stack

# PushCopy Operatie:Force Opcode(O) 1Force Opcode(1) 1Force Opcode(2) 1

Force Data In (0) 0Force Data-ln(1) 0Force Data-In (2) 0Force Data-ln(3) 1Force Data-In(4) 0Force Data-In(5) 0Force Data-ln(6) 0Force Data=In (7) 0RUN 20

# Er staan nu weer 6 elementen op de stack

# PopReplace Operatie:Force Opcode(O) 0Force Opcode(1) 0Force Opcode(2) 1

Force Data In (0) 1Force Data=ln(1) 0Force Data In (2) 0Force Data='n (3) 1Force Data In(4) 0Force Data-In(5) 0Force Data-In (6) 0Force Data=In (7) 0RUN 20

# En nu staan er dus nog maar 5 op stack

# Swap:Force Opcode(O) 0Force Opcode(1) 1Force Opcode(2) 1RUN 20

# POP2 Operatie:Force Opcode(O) 1Force Opcode(1) 0Force Opcode(2) 1run 20

# nog naar 3 overrun 20

# Nog maar 1 over

Template write list 11066 -session datawrite list - /vhdljneted_Iifo/d%utput.list -page -replace -session_data

--------------XXXIV--------------

Appendix C

# USER: marcp.afst.none.243ED# DESIGN: / /ebo/users/marcp/vhdl/neted_Iifo/lifo/design.erel# REV: 26# VERSION: LOGIC SIMULATION SERVER V7.0 3.18 Sat Nov 11 12:58:03 PST 1989# DATE: Thursday, October 3, 1991 13:2:31 -# SCALE USER TIME: OO0סס1.0 NS# TIME STEP: 0.100000# TRANSPORT SWITCH: Inertial delays# SPIKE MODEL: SUPpres# TIMING MODEL: Typical Timing Model

0.01 0 oo000סס0 000 0 XXXXXXXXz 0 1 15.0 0 0 oo00סס00 000 0 XXXXXXXXz 0 1 110.00 1 oo0סס000 000 0 XXXXXXXXz 0 1 115.00 0 00000000 000 0 XXXXXXXXz 0 1 120.01 0 00000000 000 0 XXXXXXXXz 0 1 121.0 1 0 oo01סס00 001 0 XXXXXXXXz 0 1 125.0 0 0 oo1סס000 001 0 XXXXXXXXz 0 1 130.00 1 00000001 001 0 XXXXXXXXz 0 1 135.0 0 0 00000001 001 0 XXXXXXXXz 0 1 140.01 0 oo1סס000 001 0 XXXXXXXXz 0 1 141.01 0 00000010 001 0 XXXXXXXXz 0 1 142.0 1 0 00000010 001 0 XXXXXXXXz 0 0 145.0 0 0 00000010 001 0 XXXXXXXXz 0 0 150.00 1 00000010 001 0 XXXXXXXXz 0 0 155.00 0 00000010 001 0 XXXXXXXXz 0 0 157.00 0 00000010 001 0 oo01סס00 0 0 160.0 1 0 00000010 001 0 oo1סס000 0 0 161.0 1 0 00000011 001 0 00000001 0 0 162.0 1 0 00000011 001 0 00000001 0 0 065.0 0 0 00000011 001 0 00000001 0 0 070.0 0 1 00000011 001 0 00000001 0 0 075.0 0 0 00000011 001 0 00000001 0 0 077.0 0 0 00000011 001 0 00000010 0 0 080.0 1 0 00000011 001 0 00000010 0 0 081.01 0 00000100 001 0 00000010 0 0 085.00 0 00000100 001 0 00000010 0 0 090.00 1 00000100 001 0 00000010 0 0 095.00 0 00000100 001 0 00000010 0 0 097.00 0 00000100 001 0 oo11סס00 0 0 0100.0 1 0 00000100 001 0 00000011 0 0 0101.0 1 0 00000101 001 0 00000011 0 0 0105.00 0 00000101 001 0 00000011 0 0 0110.00 1 00000101 001 0 00000011 0 0 0115.00 0 00000101 001 0 00000011 0 0 0117.0 0 0 00000101 001 0 00000100 0 0 0120.0 1 0 00000101 001 0 00000100 0 0 0121.0 1 0 00000110 001 0 00000100 0 0 0125.00 0 00000110 001 0 00000100 0 0 0oo100000סס130.0010000011000100

135.00 0 00000110 001 0 00000100 0 0 0137.00 0 00000110 001 0 00000101 0 0 0140.0 1 0 oo110סס0 001 0 00000101 0 0 0141.0 1 0 00000110 010 0 00000101 0 0 0142.01 0 oo110סס0 010 0 oo101סס0 1 0 0145.00 0 00000110 010 0 00000101 1 0 0150.00 1 00000110 010 0 00000101 1 0 0155.00 0 00000110 010 0 oo101סס0 1 0 0157.00 0 00000110 010 0 00000110 1 0 0160.0 1 0 00000110 010 0 00000110 1 0 0161.01 0 00000111 011 0 00000110 1 0 0162.01 0 00000111 011 0 00000110 0 0 0165.00 0 00000111 011 0 00000110 0 0 0

--------------xxxv--------------

TIME AClk 1AClk-2

AData In

AOpcode AFullAReset AEmpty

AData Out AElem 0 1

Appendix C

170.00 1 00000111 011 0 oo0110סס 0 0 0175.00 0 00000111 011 0 00000110 0 0 0177.00 0 00000111 011 0 oo0101סס 0 0 0180.0 1 0 00000111 011 0 00000101 0 0 0181.01 0 00001000 111 0 00000101 0 0 0185.00 0 00001000 111 0 00000101 0 0 0190.00 1 00001000 111 0 00000101 0 0 0195.00 0 00001000 111 0 00000101 0 0 0197.00 0 oo1000סס 111 0 00000111 0 0 0200.0 1 0 00001000 111 0 00000111 0 0 0201.01 0 00001001 100 0 00000111 0 0 0202.0 1 0 00001001 100 0 00000111 1 0 0205.00 0 oo1001סס 100 0 00000111 1 0 0210.00 1 00001001 100 0 00000111 1 0 0215.00 0 00001001 100 0 00000111 1 0 0220.0 1 0 00001001 100 0 00000111 1 0 0221.0 1 0 00001001 110 0 00000111 1 0 0222.01 0 00001001 110 0 00000111 0 0 0225.00 0 00001001 110 0 00000111 0 0 0230.00 1 00001001 110 0 oo111סס0 0 0 0235.0 0 0 00001001 110 0 00000111 0 0 0237.00 0 00001001 110 0 00001001 0 0 0240.0 1 0 00001001 110 0 00001001 0 0 0241.01000001001101000001001000245.00 0 00001001 101 0 00001001 0 0 0250.00 1 00001001 101 0 oo1001סס 0 0 0255.00 0 00001001 101 0 00001001 0 0 0257.00 0 00001001 101 0 00000100 0 0 0260.0 1 0 00001001 101 0 00000100 0 0 0265.00 0 00001001 101 0 00000100 0 0 0270.00 1 00001001 101 0 00000100 0 0 0275.00 0 00001001 101 0 00000100 0 0 0277.00 0 00001001 101 0 oo011סס0 0 0 0280.0 1 0 00001001 101 0 oo11סס00 0 0 0

TIME AClk 1AClk-2

AData In

AOpcode AFullAReset AEmpty

AData Out AElem 0 1

--------------XXXVI--------------

I Memory_BlockTOS-1 __ ut (RW-1: 0)

ICl l<_1TOS_Out (RW-1: 0) I---

"0 "0 "0....

"0.... ;.;

r-- Cll<-2 I , I..J X xES .... ES ES.... .... ... C\ICll 0> c: c:1/), 1/)1 ...., ....,<- III ., .,.., Q :> :><: -ן m CD

Em p t y<~=r--~---1-----4

Adr _Sel [RL-1: 0)

~ u11 <1-<'~---.J----+-----+----1F u1 pee 0 de r _B~ 0 cko

~Eilloty ell

'C'Qu

Elem_O_1 Co

... ")OJ

1 ....:>I. :>I. c:.... .... uu '-'

"0 0

... .... TOSJn (R -1: 0)

~ ~ -ES a:... ';;;TOS-1_In(~W-1:0).... ....:> :>0, 0\

; ; Data_In [RW-1: 0)CD Oata5n (RW-1: 0) I-------<Q:..J

Oata_out (RW-1: O)I-------C>~Register-Slock Data_Out (RW-1: 0)

Reg_OPcode (1:0) ell<

f--Clk-2

Reg_Opcode (1: 0)

Opcode (2: 0)Opc ode (2: 0)!-------<0:::1

ResetReset f--------<C---.J

6-I~

......u

TUEEB

lL1FO - Level 1

·p-"""" _ --_._ .. -- _-_. -- ..

!M. Peerbooms··....-.. _.. _-_ .. --_ - .

lOktober 1991

Switch 'MlItl

OataJnIRII-I:OJ I CJ iJata_In (RW-1: oj

Data Out (RW-1: 0)

ItlR.oJnl (RII-I: 0) I I I R.OJJut (RII-I: 0)

~ 1mClk

OUTBus __Ou t 1 (RW-1: 0) cr----l OataJJuU(RII-I: 01

, Reg_ister _1 'hdll ttlR.oJ" (RII-I: 0) TOS_In (RW-1: oj

RaoJn2(RII-I: 01 I ItlOataJJut2 rRII-S: 0)

I Reg_ister _2 Shdll ItlR.oJn (RII-I: 0)

InCD

Bus ~Ou t 2 (R W- 1: 0)

----1Cm

OUT

Clk R.oJlocad.U: 01

OUTR.OJlut (RII-I: 0)

ClkItl

~---

TOS-1_In (RW-1: oj

...._ -f-- ...O~3:~ :Dr:. : CDr+: : to. .0: -0: J-J-

a: m: illm:m: rrJ: : m. ---, .

.J: J

I-»:O-llto: o1tDto! ° ! I---'~: 3: 0

UJi n• A

Itl

elk

ttl

QReg_Opcode (1: oj

Adr _5 e 1 (R L- 1: 0)

OUT

Ael~.Jlel (RL-1: 0)

Adres_Decoder Shell

Clk 1

IN

IN

Full

Ern p t y <::] --!

Full

E80ty

Shell OUT

Count-OutILRL-1:0)

INCnt_Opcode (2: 0) Dl>------------_

IN

Cnt-Oocooe (2: 0)

elk

Counter Shell

TUEl~.~.~.~.~.=~..~~.~.~.~..~..i M. PeerboomsEB ~.-.--..--.--- - .10ktober 1991,

~-------------::--=--_._~--~~--,--,

r-----------" BU"l_J ... t (RW -t: 01,.BUOf J''lt: fflW-t: (l11-''''''''__~I_''_

r------------""',,,-, B1i'l .Tn~ IllW ·1: 01

BII~ putt IRW ·t: ('I-l'l~"~------'"

r~(I.<W-1:0) 1-=~__--,-,1Pll'l .Tn(II''''·1:01U .(lut /riw ,1: (\, OPT IN

f1tJ~ .(llJt:~ IRW·· 1: f·I-- ~

t'llr

I--+-+--+---j--""'I"',,'-! RUOf .In t fRW -t: (11

larrCe 15 ShOl

W,.!te .C'1I Write(illl' frS

-------_.. -

Bus _.{lvt rQW- t: (II 1-l';:;,,:-:,,-----:,"',,--1 U .~ ~~l:-!~WO_\: O)I-"O''''II:----:'~tl flll"! .Tn rRW ·1: (II

'"_________ ....ell(

BU!t J1lJt21nw-t: 0\.0-1)",---1-+-..1

Write

laniCe 14 Shdl

Wl"'lte ..eel __OllT

IB~: -;':~;~"~·~~1-o"I",,-----,I-+......jI--1fllJ~ _out Iqw-t: 011-,,= -<[1 Jrl (~W·l: oj 1----, .,.,., fill" .In IAW-t: 0)

our Hr u .chit'IUI·I:O] [Hll lr~

I-+--+--='N r,cl.

1-+-1-+--+---:,"",,"" eUlI __r·n tRW-t: [11

I--+-!--+----,''''N,-! fhJq ..fr\2 tRw- t: 01

_",,,j-_.--,"'""" Ad,. ..Se 1 It: 01

~-~ TOIII; .~el rl: 01IN Wr..,Sc13shdl

[lIlTW"\t ft

lanlCe 13 ShOl

ell!'! .(lllt2r"w·t:('I- +~I___I

r.lk

~---'-

I-+-I-+--I----:,"'N"" eu!, . .'nt rQW-I: 01

r---~'--

eu~._otltt IRW-I: (l1-I""""-----,I-+......j~_1

'N..- -,-. b": lk Wl"'itfJ .Cel __ .~

OUI IIIWrot-:e

nanCe11shOic •..• __ • __

8us J1ut2IRW-l: ()1_---+-..1~""(llIr

~---

1--/--+--+-......jL---I"N"- Bu!\! ._.tn 1 rAW-I: ('1

I--I--+--+--,"N'- eU!!I._In2 lRW-t: 01

1--+--..1---r=N Dr.lk W"'He .cel~r~- - - IN../.:::>1---:-::- o\d,. _~e 1 f t: 01W~ fos_Sel ft: 01

IN W~""~O!",,I

w,.t to

~amce 10 Shdl---- ----=:;.;

Bu!\! J lut2 (RW- t: ('I--U'~lf---I-+~

1-

<;;; c; ;; <;

kI

~I , ;; Me mo r y B10 c

, ,:Y .J

TUEIE :Y

~ !;" ~ - - ~ ~::J

" ';! " "..............-._-.. _-......__.__ ._-_ ...._--.......

0, ...M Pe bo J, ", ", "'I "'I e r 0 ms '"I , °1.. .. .><

~.,

EB.>< rn rn

::J ~ 0 0 0

'" 0' u ,- .-........................_---.- ............._..... 1)\)\;- C CJ (J Q Ok tober 199 1

Eindhoven University of Technology MASTER Analyse en ... · Analyse en implementatie van IDaSS...

Documents

Transcript of Eindhoven University of Technology MASTER Analyse en ... · Analyse en implementatie van IDaSS...