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
Modelleringsmethoden
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
Modelleringsmethoden
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
Modelleringsmethoden
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
Modelleringsmethoden
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
IDaSS Basis Bouwstenen
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
IDaSS Basis Bouwstenen
• 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
IDaSS Basis Bouwstenen
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
IDaSS Basis Bouwstenen
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
IDaSS Basis Bouwstenen
: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
IDaSS Basis Bouwstenen
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
IDaSS Basis Bouwstenen
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
IDaSS Basis Bouwstenen
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
IDaSS Basis Bouwstenen
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 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
VHDL Implementatie LIFO
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
VHDL Implementatie LIFO
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
VHDL Implementatie LIFO
---~--, ... _-----(-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
VHDL Implementatie LIFO
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
VHDL Implementatie LIFO
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
VHDL Implementatie LIFO
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
VHDL Implementatie LIFO
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
VHDL Implementatie LIFO
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
VHDL Implementatie LIFO
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
VHDL Implementatie LIFO
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
VHDL Implementatie LIFO
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
VHDL Implementatie LIFO
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
VHDL Implementatie LIFO
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
VHDL Implementatie LIFO
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
VHDL Implementatie LIFO
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
VHDL Implementatie LIFO
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
VHDL Implementatie LIFO
. 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
VHDL Implementatie LIFO
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
VHDL Implementatie LIFO
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
VHDL Implementatie LIFO
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
VHDL Implementatie LIFO
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
VHDL Implementatie LIFO
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
VHDL Implementatie LIFO
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
VHDL Implementatie LIFO
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
Appendix B: Adres decoder
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
Appendix B: Adres decoder
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
USE std.standard.ALL;USE std.mentor_base.ALL;
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 OTHERS = > NULL;END CASE;
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 OTHERS = > NULL;END CASE;
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 OTHERS = > NULL;END CASE;
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 OTHERS = > NULL;END CASE;
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 OTHERS = > NULL;END CASE;
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 OTHERS = > NULL;END CASE;
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!!!
WHEN OTHERS = > NULL;END CASE;
WHEN OTHERS = > NULL;END CASE;
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
USE std.standard.ALL;USE std.mentor_base.ALL;
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"
Appendix B: Controller
=> 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;
Appendix B: Controller
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;
WHEN OTHERS = > NULL;END CASE;
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
USE std.standard.ALL;USE std.mentor_base.ALL;
PACKAGE controller_pkg IS
Appendix B: Controller
CONSTANTCONSTANTCONSTANT
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
USE std.standard.ALL;USE std.mentor_base.ALL;
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
USE std.standard.ALL;USE std.mentor_base.ALL;
PACKAGE Ramcel_pkg IS
Appendix B: Rameel
CONSTANTCONSTANTCONSTANT
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
USE std.standard.ALL;USE std.mentor_base.ALL;
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
USE std.standard.ALL;USE std.mentor_base.ALL;
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;
OF qsim state;OF qsim=state;
-------------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
USE std.standard.ALL;USE std.mentor_base.ALL;
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
OF qsim state;OF qsim=state;
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
RUN 20# Er staan nu 3 elementen op de stack
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
RUN 20# Er staan nu 4 elementen op de stack
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