Implementering av ROM med låg effektförbrukning

Implementering av ROM med låg effektförbrukning

Mikael Sundquist Anders Ousbäck

LITH-ISY-EX-ET-0243-2002 2002-05-12

Implementering av ROM med låg effektförbrukning

Examensarbete utfört i Elektroniksystem vid Linköpings Tekniska Högskola

av

Mikael Sundquist

Anders Ousbäck

LITH-ISY-EX-ET-0243-2002 Handledare:

Oscar Gustafsson

Examinator:

Mark Vesterbacka

Avdelning, Institution Division, Department Institutionen för Systemteknik Avdelningen för Elektroniksystem Datum Date 2002-05-13 Språk Language Rapporttyp Report category ISBN X Svenska/Swedish Engelska/English Licentiatavhandling

X Examensarbete ISRN LITH-ISY-EX-ET-0243-2002

C-uppsats

D-uppsats Serietitel och serienummer_{Title of series, numbering} ISSN Övrig rapport

_ _ _ _

URL för elektronisk version

http://www.ep.liu.se/exjobb/isy/2002/243/

Titel

Title

Implementering av ROM med låg effektförbrukning Implementation of a ROM with low power consumption

Författare

Author

Mikael Sundquist, Anders Ousbäck

Sammanfattning

Abstract

Detta examensarbetet har gått ut på att konstruera ROM-minnen med liten effektförbrukning.Genom att vi undersökt olika geometriska strukturer i form av

kolumnuppdelning så har simuleringsresultaten visat god geometri med liten strömförbrukning. Därefter har minnesarean delats in i olika block med den valda geometrin där endast det blocket som är adresserat aktiveras dvs när blocken är i passiva läge drar de ej ström. Blockindelning och kolumnuppdelning kontrolleras av de mest signifikanta bitarna i adressen.

In this thesis we have designed and developed a static ROM with low power

consumption.Through examining different geometrical structures by splitting up the columns in the memory array we have, through computer simulation, found the best geometry with respect to power dissipation. In addition we have partitioned the memory array into several blocks with the optimal geometry, enabling us to switch off the memory blocks not beeing addressed and thereby lowering the power consumption even further. The column and block partitioning is controlled by the most significant address bits.

Nyckelord

Keywords

Effektförbrukning, geometrier, kolumnuppdelning, blockindelning, inverterare, buffrar, raddekoder, multiplexer, ROM-matris, passtransistor, resistanser

1

Innehållsförteckning

Sammanfattning . . . 5

1

Inledning . . . 7

1.1 Förord . . . 7 1.2 Bakgrund . . . 7 Historik . . . 7

Bakgrund inför projektet . . . 7

1.3 Specifikation . . . 7

Implementering av RAM/ROM med låg effektförbrukning . . . . 7

Arbetsbeskrivning . . . 8

2

Programvaror . . . 9

2.1 Emacs. . . 9 2.2 Cadence . . . 9 2.3 C++ . . . 9 2.4 VHDL . . . 9

2.5 Modelsim compiler och simulator . . . 10

2.6 Nanosim. . . 10 2.7 Framemaker . . . 10 2.8 CorelDRAW . . . 10

3

Skriptspråket skill . . . 11

3.1 Presentation . . . 11 3.2 Programexempel . . . 11

4

Arbetsgång . . . 17

4.1 Inläsning på området och problemlösningsmetodik . . . 17

4.2 Överskådlig struktur . . . 17

5

ROM-minnets uppbyggnad. . . 19

5.1 ROM-minnets grundprincip. . . 19

Inverterare . . . 19

Raddekoder och buffer . . . 19

Generering och design av raddekoder . . . 21

5.2 ROM-matris. . . 21

Generering och konstruktion av ROM-matris . . . 22

6

Åtgärder för effektbesparing. . . 23

6.1 Två metoder . . . 23

6.2 Kolumndekoder . . . 23

Realisering . . . 24

6.3 Blockuppdelning . . . 26

Blockmultiplexer . . . 26

Blockaktiverare . . . 27

7

ROM-minnets geometriska strukturer . . . 33

7.1 Grundstruktur. . . 33

7.2 Kolumnuppdelad struktur . . . 34

7.3 Blockindelad struktur (partitionering) . . . 35

7.4 Kolumn och blockuppdelad struktur . . . 36

7.5 Kolumn och blockindelning m h a C++ . . . 37

Textfil . . . 37

Kolumnuppdelning . . . 37

Blockuppdelning . . . 39

8

Skapa nytt ROM . . . 41

8.1 Tillvägagångsätt. . . 41 8.2 Exempel på generering . . . 41 8.3 Tillhörande Vhdl-modell . . . 42

9

Simulering. . . 43

9.1 Simuleringsmetodik. . . 43 9.2 Optimering. . . 44 9.3 Simuleringresultat . . . 45 9.4 Grafer simuleringar . . . 46 Strömförbrukning . . . 46 Fördröjning . . . 48

10

Slutsats . . . 51

10.1 Effektförbrukning . . . 51 10.2 Egna kommentarer. . . 51 Förbättringar . . . 51

11

Litteraturlista. . . 53

Appendix A. . . 54

A.1 Layout för ettcell (raddekoder) . . . 54

A.2 Layout för nollcell (raddekoder) . . . 55

3

A.9 Layout för resistans (ROM-matris) . . . 62

A.10 Layout för ROM-minnesmatris . . . 63

A.11 Layout för passtransistor (kolumndekoder). . . 64

A.12 Layout för komplett mux (kolumndekoder) . . . 65

A.13 Layout för blockaktiverare (blockdekoder) . . . 66

5

Sammanfattning

Detta examensarbetet har gått ut på att konstruera ROM-minnen med liten effektförbrukning. Genom simulering av olika geometriska strukturer för kolumnuppdelning så har vi funnit en geometri med liten effektförbrukning. Därefter har minnesarean delats in i olika block med den valda geometrin där endast det blocket som är adresserat aktiveras med mindre effektförbrukning som följd. Blockindelning och kolumnuppdelning kontrolleras av de mest signi-fikanta bitarna i adressen.

7

1 Inledning

1.1

Förord

Vi vill här passa på att visa vår uppskattning till personalen vid avdelningen för elektroniksystem som har varit till stor hjälp i många lägen då vi har kört fast. Vi vill också tacka vår handledare Oscar Gustafsson samt vår examinator Mark Ves-terbacka för alla konstruktiva idéer. Grundläggande kunskaper i främst digital-teknik fordras för att man helt ska kunna följa med i rapporten.

1.2

Bakgrund

1.2.1

Historik

Förr i tiden var det inte lika lätt ta med sig den elektriska utrustningen då apparaterna ofta drog mycket ström. Batterierna var stora och tunga med kort livslängd. Idag är det annorlunda med små och smidiga apparater. Batterierna är laddningsbara med lång livslängd. Den mobila användningen ökar var dag och behovet av längre standbytid verkar sakna gränser. De flesta mobila apparaterna använder sig mer eller mindre av minneshantering som t ex mobiltelefoner, spel, GPS, datorer och andra elektroniska apparater.

1.2.2

Bakgrund inför projektet

Uppgiften presenterades av Mark Vesterbacka på Elektroniksystems hemsida. Vi fann den intressant dels för att vi nyligen arbetat med ett projekt i digitala kretsar, dels för att vi var införstådda i ROM-minnets grundläggande principer. Arbetet passade också bra eftersom vi sökte en lämplig uppgift för två personer.

1.3

Specifikation

1.3.1

Implementering av RAM/ROM med låg effektförbrukning

En stor del av effektförbrukningen i integrerade kretsar förbrukas i RAM och ROM. Det är därför viktigt att hålla nere effektförbrukningen i dessa komponen-ter. Detta kan t ex göras genom att man försöker partitionera minnesarrayer och adressavkodare i lämpliga delar och bara aktivera de block som behövs.

1.3.2

Arbetsbeskrivning

Arbetsuppgiften består i att studera olika tekniker för att minska effektförbruk-ningen i RAM och ROM-kretsar. En parametriserbar layoutgenerator för RAM och ROM ska sedan konstrueras i vilken de intressantaste teknikerna implemen-teras. Målet är att få fram ett statiskt ROM-minne med så låg effektförbrukning som möjligt. Det skall heller inte finnas några gränser för hur stort det kan göras. Ytterligare krav är att implementeringen ska utföras i en AMS 0.35 µm tekno-logi. Matningsspänningen ska vara 3.3 V. Det primära är inte snabbheten utan effektförbrukningen.

9

2 Programvaror

2.1

Emacs

Emacs har använts flitigt som texteditor för all typ av kodning. De inbyggda funktionerna i Emacs har underlättat arbetet genom att t ex göra kodningen mera lättläst som färgindelningar mm.

2.2

Cadence

Cadence är ett program för elektronikkonstruktion där man kan jämföra schema (symbolisk nivå) med layout (realiseringsnivå) och göra realistiska simuleringar. Vi har valt att konstruera ROM-minnet i form av layout (se appendix A). Simule-ringen har skett från layouten där vi har extraherat en nätlista i spiceformat som läses in av simuleringsprogrammet Nanosim. Vi har också simulerat de logiska funktionerna direkt från layouten.

2.3

C++

Vi har valt att använda det omfattande högnivåspråket C++ för hantering av text-filer. Språket är enkelt att förstå och hanterar algoritmer utan alltför många kom-mandorader. En nackdel med språket är att det väldigt ofta går att kompilera med exekveringsfel som följd dvs programmet går att köra men resultatet blir inte all-tid vad man har tänkt sig.

2.4

VHDL

VHDL står för VHSIC (Very High Speed Integrated Circuits) Hardware Descrip-tion Language och är ett ganska nytt programspråk. VHDL har sitt ursprung från amerikanska försvaret och har stora likheter med Ada. Språket utvecklades för att standardisera beskrivningen av digitala och på senare tid även analoga kretsar. Vid simuleringen av de färdiga ROM-layouterna har använts en VHDL-modell av ROM-minnet för direkt jämförelse av utdata för ett givet stimuli. Detta har givit möjlighet både till verifiering av funktionen (jämförelse av utdata) samt uppskattning av fördröjningstider i de olika ROM-strukturerna. Det sistnämnda gjordes eftersom VHDL-modellens utdata är idealt (saknar fördröjning) varför man kan utläsa fördröjningstiderna genom jämförelse med simuleringsresultatet.

2.5

Modelsim compiler och simulator

Modelsim (Mentor Graphics) är en simulator för bland annat VHDL. Vi har använt Modelsim för Kompilering och simulering vilket snabbt har gett anvis-ningar om syntaxfel i koden. För att undersöka utsignalerna på grafisk form har vi tagit hjälp av Vsim (simulator i Modelsim). Simuleringsfilerna är skrivna i så kallade do-filer då det är många parametrar som ska sättas i vilka man kan ange simuleringstid, simuleringsparametrar och insignaler. Modelsim genererar en vcd-fil som ger korrekt utdata som sedan jämförs med den framsimulerade out-filen från Nanosim (se stycke 2.6). De båda filerna kan ses från ett vågfönster där man grafiskt ser fördröjningarna hos det framtagna ROM-minnet.

2.6

Nanosim

Nanosim är ett program som tidigare var känt under namnet Powermill vilket används för simulering på kretsnivå. För att simulera strömförbrukning vid olika geometrier har vi använt Nanosim. Med tanke på storleken på våra layouter har Nanosim jobbat mycket snabbt. Nanosim använder sig av en Spicenätlista som kan genereras från layouten. Det går betydligt fortare att simulera mha nanosim än att simulera direkt från Cadence inbyggda simuleringsfunktioner.

2.7

Framemaker

FrameMaker är ett program för bland annat ordbehandling från Adobe. Rappor-ten som ni håller i handen är skrivet i detta program. Jämför man med Microsoft Word så är det inte lika många funktioner som är helautomatiska, utan här får man tänka till.

2.8

CorelDRAW

Coreldraw är ett trevligt vektorbaserat ritprogram i Windows miljö. Alla illustra-tioner som visas i rapporten är gjorda mha av Coreldraw och sparade som eps (postscriptformat).

11

3 Skriptspråket skill

3.1

Presentation

Skill är ett skriptspråk som hör till Cadence i vilket funktioner kan fördefinieras för att exempelvis generera stora arrayer bestående av många celler (jfr L-språket i Led). Förutom möjligheten att instansiera celler finns ett stort antal funktioner för att hitta och skapa objekt, exempelvis ledningar och kontakter, på olika nivåer i en layout-struktur. Skill har använts för att generera alla dynamiska strukturer, d v s raddekoder, ROM-matris, kolumndekoder samt block och block-dekoder.

3.2

Programexempel

I Skill fördefinieras alltså funktioner som laddas i Icfb-fönstret (logg- och kom-mandofönstret) med kommandot loadi("sökväg/filnamn") och sedan exekveras i samma fönster genom anrop med funktionsnamnet följt av inparametrarna inom parentes. En funktion börjar i regel med ett kommando som öppnar en cv (cell-view). Exempel:

cv=dbOpenCellViewByType("<bibliotek>" "<cellnamn>" "layout" "maskLayout" "w").

Därefter deklareras de instanser som ska användas. Detta görs i princip med samma kommando men med skillnaden att endast bibliotek, cellnamn och layout (anger att layout-mode ska användas) ges som argument:

inst=dbOpenCellViewByType("<bibliotek>" "<cellnamn>" "layout")

Instansieringen sker med kommandot

inst_1=dbCreateInst(cv <inst-namn> ‘nil list(x y) "R0" 1)

där “inst-namn” är det namn instansen givits vid deklarationen i början och x och y de koordinater instanserna ska ges i cv. Mha en enkel for-sats kan sedan ett godtyckligt antal av en och samma instans läggas ut. Exempel:

cv=dbOpenCellViewByType("new_lib" "cell_array" "lay-out" "maskLay"lay-out" "w")

cell_a=dbOpenCellViewByType("new_lib" "cell_a" "lay-out")

for(i 1 n

inst=dbCreateInst(cv cell_a ‘nil list(10*i 0) "R0" 1)

) )

Ovanstående funktion öppnar cv:n cell_array och instansierar cell_a n antal gånger. Instanserna läggs ut längs x-axeln med 10 µm mellanrum. Vill man t ex instansiera tre celler anropas funktionen med

gen(3)

i icfb-fönstret sedan filen som innehåller koden har laddats. Resultatet illustreras i figuren nedan.

C V

Origo

Instans Instans Instans

13

Om man anger ett namn vid instansieringen av cell_a i ovanstående funktion istället för "‘nil" får instansen ett s k ROD-namn. ROD står för Relative Object Design och detta namn gör instansen tillgänglig för ett flertal så kallade ROD-kommandon. Vill man t ex dra en ledning mellan instanserna kan kommandot rodCreatePath användas. För att det ska fungera måste varje instans ges ett unikt namn, varför man i detta fall måste indexera instanserna. Funktionen sprintf kombinerar en godtycklig sträng med t ex en variabel:

sprintf(nil "cell_%n" a) => (om a = 0) cell_0 (%n anger att variabeln är en siffra).

Har vi skapat terminaler i cell_a och givit dem ROD-namn kan vi använda dessa för att ange start och slutpunkt för ledningen, vilket är praktiskt eftersom vi slip-per ta reda på absoluta koordinater. Låt oss säga att vi har skapat en interminal "in" och en utterminal "out". Vill vi dra en ledning från utterminalen i varje instans till efterföljande interminal i lagret "MET1" kan vi ge kommandot rodCreatePath( ?layer "MET1" ?width 1 ?pts list(rodGetObj(sprintf(nil "cell_%n/out" a) cv)~>"cC" rodGetObj(sprintf(nil "cell_%n/in" a+1) cv)~>"cC") ?cvId cv ).

rodGetObj-kommandot används för att hitta ROD-objekten och "cC" pekar ut objektets mittpunkt i horisontal och vertikalled (center Center). Kommandot kan naturligtvis även det läggas i en for-sats för att utföras ett visst antal gånger. Koden kan i sin helhet se ut så här:

procedure(gen(n)

cv=dbOpenCellViewByType("new_lib" "cell_array" "lay-out" "maskLay"lay-out" "w")

cell_a=dbOpenCellViewByType("new_lib" "cell_a" "lay-out")

inst=dbCreateInst(cv cell_a sprintf(nil "cell_%n" i) list(i*10 0) "R0" 1) ) for(i 1 n-1 rodCreatePath( ?layer "MET1" ?width 1 ?pts list(rodGetObj(sprintf(nil "cell_%n/out" i) cv)~>"cC" rodGetObj(sprintf(nil "cell_%n/in" i+1) cv)~>"cC") ?cvId cv ) ) ).

I figur 3.2 visas resultatet av ledningsdragningen mha rodCreatePath-komman-dot (jämför med figur 3.1).

C V

Origo

Cell_2 Cell_3 Cell_1

15

En annan viktig skill-funktion är möjligheten att justera exempelvis instanser efter andra ROD-objekt. Detta ger stor flexibilitet och är viktigt vid design av större, hierarkiskt uppbyggda layouter eftersom färre absoluta koordinater behö-ver användas.

17

4 Arbetsgång

4.1

Inläsning på området och problemlösningsmetodik

Arbetet inleddes med en studie av artiklar som vår handledare delade ut. Därefter sökte vi kunskap på internet. Tidigare kurslitteratur och besök på bibliotek användes under inläsningsfasen. Vi hade också kunskaper från tidigare kurser. Problemlösningsmetodiken bygger på bottom-up modellen. Man börjar med att konstruera små celler som testas och provkörs. Efter hand länkar man samman cellerna i stora byggblock som också testas. Därefter instansieras blocken i större system där buffrar, matning, resistanser och andra byggblock kopplas samman. Byggblocken ligger på olika layoutnivåer, dvs att man länkar samman små celler i en nivå, som i sin tur blir instanser i högre nivåer osv. Det betyder att det blir enkelt att gå ner i de olika nivåerna och justera.

4.2

Överskådlig struktur

Mycket av förberedelserna inför layouten ligger i att strukturera så att inte led-ningar i samma lager korsar med varandra. Det var något som vi lade ned mycket arbete på. Att skissa på papper blev en bra grundmall till layouten. Det är dock inte alltid så lätt att förutse hur de högre nivåerna utvecklas, men att följa sina strukturella förberedelser i den mån det går är att föredra och sparar tid.

19

5 ROM-minnets uppbyggnad

5.1

ROM-minnets grundprincip

5.1.1

Inverterare

På ingången (adresserna Ax) till raddekodern sitter CMOS-inverterare (se figur 5.1).

Figur 5.1 Inverterare på ingången till raddekodern

5.1.2

Raddekoder och buffer

För varje specifik adress (Ax) finns det bara en ordlinje som ger en etta på utgången (se fig 5.2 och fig 5.3). Dessa ordlinjer (Rx) är också ingångar till ROM-minnet. För att få en nolla ut från raddekodern krävs att minst en av n-transistorerna leder. p-n-transistorerna fungerar som resistanser. För att få en san-ningstabell enligt fig 5.2 krävs det en placering av transistorer som visas av rad-dekodern (se figur 5.3). För att enklare se rarad-dekoderns funktion finns en siffra i varje cell som representerar sanningstabellens adresser (Ax) och dess invers (se figur 5.3), fast läses omvänt, dvs från höger till vänster.

Ut

Figur 5.2 Funktionstabell för raddekoder 0 0 0 1 1 0 1 1 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 R1 R2 R3 R4 A2 A1 2 adressbitar 4 ordlinjer R1 R2 R3 R4 Vdd Vdd Vdd Vdd A1 A2 0 1 0 1 1 1 1 1 1 1 0 0 0 0 0 0 /A1 _/A2 Raddekoder

21

Buffrarna består av två kaskadkopplade CMOS-inverterare. Den första invertera-ren är mindre än den andra för att inte belasta utsignalen från raddekodern. Buff-rarnas uppgift är att förstärka utsignalen från raddekodern.

Figur 5.4 Buffer mellan raddekoder och ROM-matris

5.1.3

Generering och design av raddekoder

Raddekodern består av många sammankopplade celler (mindre layouter). Matri-sens storlek beror av antalet adresser (ingångar) som bestäms av antalet rader i ROM-minnet. Realiseringen sker mha Cadence och placeringen av cellerna styrs av en algoritm skriven i Skill. De olika cellerna finns i början av appendix A och beskrivs som nollcell och ettcell. Cellerna är konstruerade så att transistorerna kan variera i storlek. Alla ledningar är av minsta bredd (0.4 µm) där det går.

5.2

ROM-matris

ROM-matrisen liknar raddekodern, och man kan göra direkta jämförelser mellan de två. P-transistorerna agerar även här som resistanser och NMOS-transisto-rerna leder spänningen till jord se figur 5.5. Utgången på ROM-matrisen har en ordlängd på 4 bitar (C1-C4) enligt fig 5.5. Placeringen av n-transistorerna beror på utdata. För en viss specifik adress får vi en etta ut från raddekodern, dvs ord-linjen (Rx) blir hög. Därefter följer man ordord-linjen horisontellt ut i rommatrisen och applicerar en transistor där man vill att bitlinjen (Cx) ska vara noll.

Ut In

Figur 5.5 Funktionstabell med tillhörande ROM-minnesmatris

R1 R2 R3 R4 C1 C2 C3 C4

1 0 0 0

0 1 0 0

0 0 1 0

0 0 0 1

0 1 0 1

0 0 1 1

1 0 0 1

0 1 1 0

A1

A2

0 0

0 1

1 0

1 1

Vdd Vdd Vdd Vdd R1 R2 R3 R4 C1 C2 C3 C4 R

23

6 Åtgärder för effektbesparing

6.1

Två metoder

Vi ska här behandla de två metoder för effektbesparing som har undersökts i detta arbete.

En stor minnesstruktur med många ord men begränsad ordlängd, växer mycket snabbt "på höjden". Detta leder till långa ledningar med stora kapacitanser som följd. Skulle man kunna införa någon slags kolumndekoder, vilken skulle göra det möjligt att dela upp kolumnerna på flera delar borde kapacitanserna kunna minskas med effektbesparing som följd. Kan varje kolumn delas upp i två halvor kan höjden på minnesarean halveras, kan varje kolumn delas upp i fyra delar kan höjden reduceras till en fjärdedel osv.

Vidare skulle ett enda stort minnesblock innebära att en onödigt stor minnesarea är aktiv på en och samma gång, varför man borde kunna göra ytterligare effekt-besparingar genom att dela upp minnet på flera block som avaktiveras när de inte adresseras.

6.2

Kolumndekoder

6.2.1

Implementering

En kolumndekoder kan enkelt implementeras med en multiplexerstruktur bestå-ende av enkla passtransistorer av NMOS-typ. Med en adressbit på multiplexerin-gången kan varje kolumn delas i två halvor. Som illustreras i figur 6.1 läggs dessa bredvid varann med en passtransistor under varje "kolumnhalva", en med gate kopplad till adressbiten och den andra kopplad till addressbitens invers (A respektive /A i figuren). (I nedanstående figurer används transistorsymboler för att visa hur passtransistorerna läggs ut och kopplas rent fysiskt.)

Figur 6.1 En kolumn kan delas upp i två delar med en adressbit fördelad till

kolumndekodern

Behövs flera uppdelningar kan ytterligare nivåer av passtransistorer läggas ut, vilka väljer mellan ovanliggande passtransistorpar. På detta sätt uppnås en träd-struktur, med en adressbit samt dess invers kopplad till varje nivå.

6.2.2

Realisering

Kolumndekodern måste, precis som övriga minnesdelar, kunna genereras till godtyckligt format med varierande antal minnes och adressingångar. De indata som ska styra genereringen av kolumndekodern är dels antal kolumner på det ursprungliga ROM-minnet, dels antal bitingångar som ska överföras till kolumndekodern.

Ursprunglig kolumn Uppdelad kolumn

Utdata, en bit

Adressbit A

/A

25

passtransistorerna kopplas omväxlande till den inverterade respektive till den icke-inverterade adressledningen (figur 6.2).

Figur 6.2 Multiplexerstruktur med åtta ingångar, två utgångar samt två

adress-ingångar

Som framgår i figur 6.2 blir strukturen asymmetrisk, vilket gör att den längsta ledningsvägen (från ingångarna längst till vänster till utgångarna i figuren) blir onödigt lång. Därför tillbakajusteras passtransistorcellerna vilket ger strukturen enligt figur 6.3. Inverterare används slutligen både på in och utgång som buffer-steg.

A0

/A0

A1

/A1

Ut 2

Ut 1

Rom

Kolumn 1

Kolumn 2

Figur 6.3 Den slutliga multiplexerstrukturen till kolumndekoder för en kolumn

uppdelad i fyra delar (med två adressbitar)

6.3

Blockuppdelning

I ett stort ROM-minne skulle även en uppdelning på flera, var för sig frånkopp-lingsbara block, kunna vara fördelaktig eftersom en betydligt mindre minnesarea skulle behöva aktiveras på en och samma gång. För att denna princip ska fungera behövs dels någon form av "blockmultiplexer", som väljer utsignal från rätt min-nesblock, dels avstängningsbara adressingångar till delblocken, vilka styrs med "enable"-signaler. De adressbitar som ska adressera blocken ska alltså dels styra en blockmultiplexer som är kopplad till samtliga blockens utgångar, dels aktivera ingångarna på det adresserade minnesblocket.

6.3.1

Blockmultiplexer

Rom-matris Buffer inv Buffer inv Buffer

inv Bufferinv

Buffer inv Utdata A0 /A0 A1 /A1 Ut

27

dras rakt ned från blockutgång till motsvarande multiplexeringångs höjdläge, där den skarvas samman med en ledning i 3:e metallagret som dras horisontellt fram till ingången.

Figur 6.4 Som blockmultiplexer används samma struktur som för

kolumndeko-dern instansierad på höjden, dvs roterad 90 grader medurs

6.3.2

Blockaktiverare

Förutom blockmultiplexer ingår alltså en "blockaktiverare" per minnesblock i blockdekodern. Dessa placeras ut på varje block och aktiverar adressingångarna på endast det block som adresseras. För att detta ska fungera krävs ett "tristate"-steg på varje adressingång, samt en struktur som ger en hög "enable"-signal för en viss signal på blockadresseringsbitarna.

Rom1 Data ut A0 /A0 Buff inv Buff inv Buff inv Buff inv Buff inv Ut Buff inv Rom2 Ut

Tristate-steget består dels av en NAND-grind med ingångar för datasignal (D i figur 6.5 nedan) och icke-inverterad "enable"-signal, dels av en NOR-grind med ingångar för samma datasignal samt inverterad "enable"-signal. Dessa kopplas till p-sidan respektive n-sidan på en utgångsinverterare.

Figur 6.5 Kretsschema för "tristate"-steget

Med denna koppling stängs både p- och n-transistorn på utgångsinverteraren av när "enable"-signalen blir låg, vilket gör att utvärdet "fryses" vid det värde data-ingången hade då "enable" slog om. När "enable" är hög följer utvärdet datasig-nalen.

Funktionen illustreras i figur 6.6 nedan. För hög "enable"-signal följer alltså utsignalen datasignalens värde, för låg "enable"-signal blir utsignalen odefinie-rad (i praktiken "fryses" värdet på utgången då "enable"-signalen blir låg).

Enable

Out

&

Inv

29

Figur 6.6 Sanningstabell samt funktionsgraf för "tristate"-steget

För att få rätt "enable"-signal till varje block krävs en struktur som ser lite olika ut beroende på hur många block minnet delas upp på. I fallet med två block adresseras dessa med endast en adressbit, varför det räcker med att koppla en inverterare till "enable"-ingångarna på ena blocket och låta adressbiten gå in ickeinverterad på det andra (se figur 6.7). När adressbiten är låg aktiveras det ena blocket, när den är hög aktiveras det andra. I figur 6.7 illustreras fallet med två minnesblock och två adressingångar på vardera block. Eftersom det vänstra blocket använder inverterare "enablas" det när adressbiten är låg. När adressbiten är hög "enablas" det högra blocket.

Tristate

D

En

F

0

1

0

1

0

0

1

1

x

x

0

1

En

D

F

D

En

F

D

En

F

Figur 6.7 Blockaktiverare med endast inverterad respektive ickeinverterad

ingång

I fallet med fyra block används två adressbitar för blockadresseringen (se figur 6.9). För att erhålla en hög "enable"-signal för en viss adressignal används i detta fall en AND-grind med två ingångar. Inverterar vi båda insignalerna fås en hög "enable"-signal när båda adressbitarna är låga, inverterar vi ena insignalen men inte den andra får vi hög "enable" när endast ena adressbiten är hög, är båda insignalerna icke-inverterade fås hög "enable" när båda bitarna är höga, enligt funktionen för en AND-grind (illustreras kretsmässigt i figur 6.8 nedan).

Inv Rom 1 Data ut Rom 2 Data ut A0 A1 A2 _{A0 A1} A2 Tristate Tristate Enable Enable

Ut

A

B

31

Figur 6.9 Principskiss för blockaktiverare till fyra block

För att kunna adressera ytterligare block läggs flera AND-grindar till. För åtta block krävs två grindar (se figur 6.10), för sexton block tre grindar osv. I figur 6.9 nedan illustreras fallet med 8 block och två adressingångar på varje block. För att kunna adressera ett block i detta fall krävs alltså tre adressingångar på blockde-kodern (adress A2 - A4). Eftersom det är lämpligt att adressera första blocket med A2 - A4 = 0, inverteras alla blockadresseringssignalerna. I påföljande block (Rom 2) går signalen A2, som är den minst signifikanta av blockadresseringsbi-tarna in ickeinverterad, vilket innebär att detta block adresseras av A2 = 1, A3 = A4 = 0. De påföljande blockaktiverarna utformas på samma sätt så att blocken adresseras i tur och ordning efter en uppräknande adressignal.

Inv

Rom 1

Data ut

A0

A1

A2

Tristate Inv

A3

&

Rom 2

Data ut

A0

A1

A2

Tristate Inv

A3

&

Inv

Rom 3

Data ut

A0

A1

A2

Tristate

A3

&

Rom 4

Data ut

A0

A1

A2

Tristate

A3

&

Enable Enable Enable Enable

Figur 6.10 Blockaktiverare för åtta minnesblock Inv Rom 1 Data ut A0 A1 A2 Tristate Inv & Enable Inv Rom 1 Data ut A0 A1 A2 Tristate Inv

& &&

Inv Inv

A3

A4

Data ut A0 A1 A2 Tristate Inv & Enable Data ut A0 A1 A2 Tristate Inv

& &&

A3

A4

Data ut A0 A1 A2 Tristate & Enable Data ut A0 A1 A2 Tristate

& &&

A3

A4

...

Rom 8

Rom 2

Inv Inv

33

7 ROM-minnets geometriska strukturer

7.1

Grundstruktur

I fig 7.1 nedan visas en sammankopplad raddekoder och ROM-matris. Detta block är en grundstruktur, utan kolumnuppdelning eller partitionering av min-nes-arrayer. I samtliga exempel som följer kommer utdata vara oförändrad, bara minnesareans geometri förändras. Innehållet i varje ROM-matris är också illus-trerat i form av binära tal, för att åskådligöra hur innehållet förändras med bibe-hållen utdata.Vad som inte framgår i figurerna är de buffrar (se ROM-minnets uppbyggnad tidigare i rapporten) som ska finnas mellan raddekoder och ROM-matris. Figur 7.1 Grundstruktur

Rad-Dekoder

Romminne

A1

A2

R2

C1

C2

A3

R1

R3

R4

R5

R6

R7

R8

Data ut

1

0

0

1

1

0

0

1

1

0

1

0

1

1

0

0

7.2

Kolumnuppdelad struktur

För att öka förståelsen hur kolumnuppdelningen fungerar beskrivs principen när-mare i stycke 7 (kolumn och blockindelning mha C++) samtidigt med fig 7.1 och 7.2. Kolumnuppdelningen (av grundstrukturen) enligt fig 7.2 halverar antalet cel-ler i kolumnerna, och utgången på ROM-minnet har fått en adressavkodare i form av en multiplexer (kolumndekoder). Närmare beskrivning av multiplexer beskrivs under stycke 6.2 (kolumndekoder). Kolumnuppdelning medför att man kan ändra ROM-minnesareans geometri. Man får på så vis möjligheten att hitta en geometri med låg effektförbrukning. Den mest signifikanta biten är ansluten till adressavkodaren och antalet rader i ROM-minnet har reducerats. Antalet minskade rader i ROM-minnet beror på antalet ingångar till multiplexern.

Kolumndekoder Rad-Dekoder Mux Romminne A1 A3 A2 R1 R2 R3 R4 C1 C2 C3 C4 Data ut 1 1 0 0 0 1 1 0 1 1 0 1 0 0 1 0

35

7.3

Blockindelad struktur (partitionering)

Betrakta fig 7.2. Denna partitionerade struktur innebär att man delar in ROM-minnet i 2 olika block, dvs vi har delat grundstrukturen (se fig 7.1) på mitten. Utgångarna till minnesareorna har nu fått en blockdekoder (se stycke 6.3 block-uppdelning). Partioneringen bör medföra lägre effektförbrukning, då man inte aktiverar oanvända block. Vilka block som är aktiva eller inte bestäms av de mest signifikanta adressbitarna som styr en adressavkodare (blockväljare och blockak-tiverare).

Figur 7.3 Blockindelad struktur

Rad-Dekoder Romminne A1 A2 C1 C2 Rad-Dekoder Romminne A1 A2 C1 C2 A3 R1 R2 R3 R4 Data ut Blocdekoder Mux

R5

R6

R7

R8

1

0

0

1

1

0

0

1

1

0

1

0

1

1

0

0

7.4

Kolumn och blockuppdelad struktur

Att konstruera ROM-minnen mha kolumnuppdelning och blockindelning med-för många olika geometriska alternativ. Detta ökar möjligheten att hitta en struk-tur som drar lite effekt. I fig 7.3 visar vi hur grundstrukstruk-turen (se fig 7.1) kan delas upp i två block och hur minnesarean kan kolumnuppdelas i varje block, (varje kolumn har halverats). Blockdekodern kontrolleras av den mest signifikanta adressbiten medan kolumndekodern kontrolleras av den näst mest signifikanta adressbiten.

Figur 7.4 Kolumn och blockuppdelad struktur

Kolumndekoder Rad-Dekoder Mux Romminne A1 A3 A2 C1 C2 C3 C4 Data ut Kolumndekoder Rad-Dekoder Mux Romminne A1 A2 R1 R2 C1 C2 C3 C4 Blockdekoder

Mux

1 1 0 0 0 0 1 1 1 1 0 1 1 0 0 0 R3 R4

37

7.5

Kolumn och blockindelning m h a C++

7.5.1

Textfil

När ROM-minnet ska konstrueras läses en textfil in i skillprogrammet. Filen ger information om det ska vara en transistor eller inte för varje bit i ROM-minnet. När vi vill ha en nolla ut från ROM-minnet ska en transistor läggas i position. ROM-minnets struktur består av en matris som innehåller transistorer med eller utan mellanrum. Mellanrummen utgör ettor på utgången. Högst upp i textfilen finns ett tal som representerar antal ettor och nollor i x-led. Andra talet represen-terar antal rader i y-led. Därefter anges själva ROM-innehållet. Var gång som en etta eller nolla läses in från textfilen stegar sig skillprogrammet fram i matrisen. När en nolla påträffas skapas en transistor. Nedan visas ett exempel på en textfil. 5 8 01101 01101 01111 01010 10111 01101 00001 01000

7.5.2

Kolumnuppdelning

Vi har valt att bearbeta textfilen med ett C++ program vid kolumnuppdelningen. I figur 7.5 beskrivs principen för hur kolumnuppdelning går till. Till vänster i figur 7.5 ses textfilen ovan i sitt begynnelsetillstånd. Pilarna visar placeringen av varje kolumndel efter kolumnuppdelningen (se till höger i figur 7.5)

Figur 7.5 Kolumnuppdelning av ROM-minne 5*8 till 20*2

Den nya filen har ett annat utseende som beror av hur man har kolumnuppdelat. Enligt exemplet med textfilen ovan har vi valt att kolumnuppdela varje kolumn 4 gånger med resultat enligt textfil nedan (se till höger i figur 7.5).

20 2

0 1 1 0 1

0 1 1 0 1

0 1 1 1 1

0 1 0 1 0

1 0 1 1 1

0 1 1 0 1

0 0 0 0 1

0 1 0 0 0

0

0 1 0

0

0 0 0

1 1

1 1

OSV

39

koder) på utgången som kontrolleras av de mest signifikanta adressbitarna. Kolumndekodern i detta exempel kräver två ingångar.

7.5.3

Blockuppdelning

Vi har även valt att behandla textfilen med hjälp av samma C++-program som till kolumnuppdelning vid blockuppdelning. Funktionen anropas med antal block som inparameter till C++-programmet. Då delas textfilen upp i det specifika antalet och nya filer skapas med de uppdelade blocken. I exemplet nedan skapas 2 block, dvs skillkoden läser sedan in två textfiler i stället för en. Varje block kolumnuppdelas för sig enligt ovanstående beskrivning (stycke 7.5.1 och 7.5.2). Förloppet kan betraktas enligt följande illustration (se textfil nedan). Textfilens begynnelsedata är samma som tidigare exempel och hanteras enligt samma prin-cip som i stycke 7.5.1 (Textfil).

Exempel på textfil för inläsning till C++-programmet då blockuppdelning öns-kas. 5 8 01101 01101 01111 01010 10111 01101 00001 01000

Det antal block man vill dela in textfilen i måste vara en potens av två. Det finns fyra möjliga val av blockindelningar enligt textfilen ovan: 1, 2, 4, och 8 block. Väljer vi ett block förblir textfilen oförändrad (se textfil ovan). Väljer vi 8 block blir det inte något att kolumnuppdela. Två block är ett val enligt detta exempel (se textfil nedan). Efter blockuppdelningen är textfilerna nedan redo att behand-las av skillkoden om så önskas. I annat fall kan man kolumnuppdela dem först

5 5 4 4 01101 10111 01101 01101 01111 00001 01010 01000

Efter blockindelningen kan man ange hur många gånger kolumnerna ska delas upp, i detta exempel delas kolumnerna upp två gånger (se textfilerna i exemplet nedan). Den enda skillnaden från fallet utan blockuppdelning är att det är två block som ska kolumnuppdelas lika fast med olika ROM-innehåll. När program-met exekverats skrivs de två färdiga textfilerna ut med olika namn så att skillpro-grammet kan skilja dem åt. Efter kolumnuppdelningen av de två

ROM-innehållen erhålls följande resultat:

10 10

2 2

0 0 1 1 1 1 0 1 1 1 1 0 0 0 1 0 1 0 1 1

41

8 Skapa nytt ROM

8.1

Tillvägagångsätt

För att skapa ett nytt ROM behövs tillgång till dels de filer som innehåller den aktuella skill-koden tillsammans med tillhörande celler, dels en textfil innehål-lande en matris med “ettor” och “nollor” som ska utgöra det binära innehållet i minnet. Följande punkter utförs för att skapa en ny minnes-layout.

1. Programmet “slice” anropas från terminalfönstret varefter följande indata anges

- Namn på den ROM-textfil som ska användas.

- Namn som den behandlade minnesinformationen ska tilldelas. - Antal block minnet ska delas upp på.

- Antal adressingångar som ska fördelas till kolumndekodern.

2. I icfb-fönstret i Cadence laddas topp-filen med kommandot loadi(“sökväg/ place.il”), där place.il är namnet på filen.

3. I samma fönster exekveras skill-koden med följande kommando:

run(“sökväg/namn på behandlad ROM-textfil” “antal ingångar på kol.dek.” “namn på ROM-layout” “antal block”).

För att genereringen ska fungera krävs att blockantalet är en potens av två (1, 2, 4, 8, 16 osv) samt att minst en adressingång lämnas till raddekodern, d v s att det sammanlagda antalet ingångar på block och kolumndekoder är färre än det totala antalet adressingångar. För ett minne med exempelvis åtta adressingångar kan m a o högst sju ingångar förläggas till kolumndekoder och blockdekoder. För två block skapas en ingång på blockdekodern, för fyra block två ingångar, för åtta block tre ingångar osv.

8.2

Exempel på generering

Här följer ett exempel på generering av en ny ROM-layout. Ett ROM-minne upp-delat på fyra block med två ingångar på kolumndekodern ska skapas. Textfilen där minnesinformationen ligger döptes i slice-programmet till bin_data, där även rätt antal ingångar på kolumndekodern samt rätt block-antal angetts. ROM-lay-outen ska döpas till ROM_1. Följande skrivs in i Cadence icfb-fönster:

1. loadi(“sökväg/place.il”)

En färdig layout ska nu (om allt har fungerat) ligga i det Cadence-bibliotek som angivits i place.il (se avsnittet om skriptspråket Skill).

8.3

Tillhörande Vhdl-modell

För att verifiera ROM-minnets funktion används en modell av minnet gjord i Vhdl. Vhdl-modellen beskriver endast minnet funktionsmässigt och har inget med den fysiska layouten att göra, varför den saknar det fysiska minnets fördröj-ningstider. Modellen kan därför användas som referens vid simulering både vad gäller funktionen (rätt utdata) och fördröjningstider. Som argument till Vhdl-modellen ges endast det aktuella ROM-minnets storlek, dvs antal rader i grund-uppförandet och antal bitar på utgången, samt själva minnesinformationen. Hur minnet är fysiskt upplagt med ovanstående kolumn- och blockuppdelning anges inte eftersom detta inte ska påverka minnets utdata för ett givet stimuli.

43

9 Simulering

9.1

Simuleringsmetodik

Figur 10.1 visar simuleringen i form av flödesschema. Vhdl-filen (se stycke 9.3) i toppen av flödesschemat beskriver beteendet hos ROM-minnet. Do-filen inne-håller simuleringsparametrar och insignaler samt simuleringstid. Rominnehålls-filen (se stycke 8.1) beskriver rommatrisen i form av ettor och nollor. Då

Modelsim har behandlat dessa tre filer kommer en resultatfil (vcd-fil) att skapas. Nästa steg är att låta Cadence skapa en spice-nätlista på även den resulterande layouten. Ett ytterligare steg måste göras innan Nanosim kan lämna resultat. Vtran som är en fil som översätter till ett format som nanosim kan förstå, måste behandla vcd-filen så stimuli kan skapas. Slutligen kommer Nanosim ge oss resultat i form av en log-fil som visar medelströmförbrukningen. Nanosim kom-mer också ge oss en utfil som direkt kan jämföra med vcd-filen i ett vågfönster. Där kan man se tidsförskjutningarna mellan vhdl-modellen och den framtagna layouten. Testsekvensen av simuleringen illustreras av följande flödesschema.

Figur 10.1 Flödesschema Sim Cadence Nanosim Model-Vtran Vcd (C++) Kolumn -uppdelning Resultat Skill Vtran Nätlista Vhdl Vtran Cfg Cmd Vec Rom Dofil Innehåll Rom Rom Rom

9.2

Optimering

Målet med vår simulering är att hitta en geometri som drar så lite ström som möjligt. Till hjälp har vi kolumnuppdelning och blockuppdelning (partitione-ring). Med hjälp av dessa metoder har vi ett stort antal geometrier att tillgå. För att hitta en effektiv och snabb väg till låg strömförbrukning började vi med att upprepa simuleringen av ett block. ROM-innehållet varierade då mellan fyra olika minnesmatriser, fast med samma antal adresser och ett varierande antal kolumner. Stimuli till samtliga ROM-minnen var oförändrat under hela simule-ringen. Geometrin innan kolumnuppdelningen på samtliga rominnehåll är 512 rader, samt 4, 8, 12 och 16 kolumner. Väljs många ingångar till kolumndekodern blir geometrin på ROM-matrisen en liggande rektangel, i annat fall en stående. Efter ca 15 simuleringar blev svaret tydligt. Alla fyra filerna uppvisade samma mönster, dvs när ROM-matrisen var som mest kvadratisk drog den också minst ström (se tabell 10.3). Därefter valde vi att använda kvadratiska partitioneringar. I början av uppdelningen (partitioneringen) lyckades vi inte reducera strömmen. Den visade sig istället öka med antalet block. Felet låg i att P-transistorerna (resistanserna) i raddekodern och ROM-matrisen belastades hela tiden. Vi åtgär-dade problemet med att låta den inverterade enable-signalen från blockaktivera-ren även styra jordningen till gaten på p-transistoblockaktivera-rena, dvs resistanserna. Den inverterade signalen fanns redan tillgänglig då tristate-logiken på adressingång-arna redan använder sig av signalen. Då problemet var åtgärdat sjönk strömför-brukningen kraftigt (se tabell 10.3). Tanken var att vi skulle partionera samtliga ROM-innehåll, men ett problem uppstod. Cadence fick problem med att skriva ut nätlistan då antalet block blev stort. Det verkade som att inte minnet räckte till. Men det väsentligaste var ju att se om partioneringen sänkte strömförbruk-ningen, vilket man tydligt kan se i tabell 10.3 att så är fallet. Vad som saknas i simuleringen är antalet block där strömförbrukningen ökar, dvs ledningarna till blocken blir för långa eller att blockväljaren blir för stor.

45

9.3

Simuleringresultat

Tabellen enligt fig 10.2 innehåller resultat från samtliga simuleringar. I första kolumnen från vänster kan storleken på rommatrisen utläsas. Därefter antal block (partitioner), muxingångar till kolumndekodern, kolumner per block, rader per block, strömförbrukning och fördröjning. Viktigt att notera är att det verkar finnas ett samband då simuleringen närmar sig ett kvadratiskt singelblock, dvs att inte bara strömförbrukningen minskar utan även fördröjningen. Då blockanta-let ökar för rommatris (512*8) minskar strömförbrukningen och fördröjningen ökar.

Närmare beskrivning av simuleringsvärdena nedan kan ses i grafer i fig 10.3-10.6.

Figur 10.2 Tabell över simuleringsresultat

512*4

512*8

512*12

512*16

3

4*

5

2

3*

4

5

3*

2*

2*

1*

1*

1*

2

3*

4

2

3*

4

1

1

2

4

8

16

32

1

1

16.3

13.1

16

29

19.5

19.6

29.7

13.3

9.9

7.09

8.49

5.9

----30.9

22.6

25.7

32.9

26

33.5

Rader*kolumner Begynnelseminne Mux-ingångar

64

32

16

128

64

32

16

32

32

16

32

16

8

128

64

32

128

64

32

Block Kolumner_{/ Block} Rader_/Block Förbrukning_mA Fördröjning_nS

32

64

128

32

64

128

256

64

32

32

16

16

16

48

96

192

64

128

256

6.63

6.48

9.33

9.03

6.80

10.76

14.70

8.80

8.20

9.09

8.75

11.47

----9.00

6.70

10.30

9.00

8.36

13.40

9.4

Grafer simuleringar

9.4.1

Strömförbrukning

Fig 10.3 illustrerar att ju närmare en kvadratisk minnesarea (minnesmatris) man kommer, ju lägre blir strömförbrukningen. Två eller mindre muxingångar ger en stånde rektangulär minnesarea, medan 4 eller flera muxingångar ger en liggande rektangulär minnesarea. Tre muxingångar uppvisar närmast en kvadratiska min-nesarea. Värdena som har använts till grafen kan ses i tabellen fig 10.2 och är tagna från rommatris 512*8 singelblock.

Figur 10.3 Graf över strömförbrukning med avseende på antal muxingångar

Muxingångar Rader I mA 30 20 10 2 128 3* 64* 4 32 5 16

47

Fig 10.4 illustrerar att dela upp minnesarean i många block, ger minskad ström-förbrukningen. Blocken är kvadratiska med identisk area. Värdena som har använts till grafen kan ses i tabell (fig 10.2) och är tagna från rommatris 512*8.

Figur 10.4 Strömförbrukning med avseende på antal kvadratiska block I mA 15 10 5 20 Antal Kvadratiska block 1 2 4 8 16

9.4.2

Fördröjning

Figur 10.5 illustrerar fördröjningen på utsignalen mellan vhdl-modellen och det konstruerade romminnet. Ju närmare en kvadratisk minnesarea (minnesmatris) man kommer, desto mindre blir fördröjningen. Två eller mindre muxingångar ger en stånde rektangulär minnesarea, medan 4 eller flera muxingångar ger en liggande rektangulär minnesarea. Tre muxingångar ger den mest kvadratiska minnesarean och har minst fördröjning. Värdena som använts till grafen kan ses i tabellen (fig 10.2) och är tagna från rommatris 512*8 singelblock.

Figur 10.5 Graf över tidsfördröjning med avseende på antal muxingångar

Muxingångar Rader nS 15 5 10 2 128 3* 64* 4 32 5 16 Fördröjning

49

Fig 10.6 illustrerar fördröjningen på utsignalen mellan vhdl-modellen och det konstruerade romminnet Blocken är kvadratiska med identisk area. Värdena som har använts till grafen kan ses i tabellen i fig 10.2 och är tagna från rommatris 512*8.

Figur 10.6 Graf över tidsfördröjning med avseende på antal block

10 6 8 12 Antal Kvadratiska block 1 2 4 8 16 nS Fördröjning

51

10 Slutsats

I detta arbete har två metoder för effektbesparing i en ROM-struktur undersökts. Båda metoderna (kolumn och blockuppdelning) har visat sig effektiva, trots att de layouter vi har använt vid simuleringen inte direkt har varit optimala m a p ledningslängd och andra faktorer.

Vad gäller kolumnuppdelningen, som ger möjlighet att dimensionera minnesma-trisen på olika sätt, kan främst konstateras att en geometri som närmar sig kva-dratisk minnesmatris är eftersträvansvärd. Även fördröjningstiderna blev lägre vid kvadratisk minnesmatris jämfört med grundutförandet.

Även blockuppdelningen hade alltså positiv inverkan på effektförbrukningen, efter vissa förbättrande åtgärder (se optimering, kapitel 10.2). Här ökade dock fördröjningstiderna betydligt vid stigande antal minnesblock.

10.1

Effektförbrukning

Effektförbrukningen kan enkelt erhållas om man multiplicerar strömförbruk-ningen med matningsspänströmförbruk-ningen (3.3V). Den lägsta effekten vi fick fram var 19.5 mW samt som mest 98 mW för ett ROM-minne med 512 rader och 8 kolumner (se tabell fig 10.3).

10.2

Egna kommentarer

10.2.1

Förbättringar

Den blockindelningsfunktion vi har använt oss av lägger ut minnesblocken på en linje, vilket naturligtvis inte är det optimala. Kunde blocken läggas ut i en kva-dratisk matrisform skulle förmodligen stora vinster kunna göras, eftersom led-ningslängderna skulle kunna minskas drastiskt. Vissa modifieringar skulle troligtvis behöva göras internt i blocken för att detta skulle kunna genomföras. Bl a skulle de metall-3-ledningar som används inom blocken troligtvis behöva tas bort för att underlätta ledningsdragning tvärs över blocken.

53

11 Litteraturlista

Cmos Digital Integrated Circuits,

Kang, Sung-mo och Leblebici, Yusuf (1999) Introduction to Skill

Emil Hjalmarson (2001-02) Starting up Cadence

Jacob Wikner (2001) Open book main menu Cadence

Appendix A

A.1 Layout för ettcell (raddekoder)

Ettcellen genereras (efter algoritm i skill) och kopplas samman lodrät och vågrät, och bildar en matris. Ettcellen ger en etta ut på ordlinjen från raddekodern.

55

A.2 Layout för nollcell (raddekoder)

Nollcellen är en ettcell som innehåller NMOS-transistor. Nollcellen används då man önskar en nolla ut på ordlinjen från raddekodern. Nollcellen appliceras på samma sätt som ettcellen (se appendix A1)

A.3 Layout av resistans (raddekodern)

Layouten består i huvudsak av en PMOS-transistor vilken (efter algoritm i skill) används som resistans och sitter på ordlinjerna till raddekoderna, dvs mellan vdd och ordlinjerna.

57

A.4 Layout för inverterare (raddekoder)

Layouten består av två kaskadkopplade inverterare. Inverterarna genereras (av en algoritm i skill) och används på adressingången till raddekodern (se stycke 5 romminnets uppbyggnad figur 5.3).

A.5 Layout för dubbelbuffer

Layouten består av två buffrar som arbetar oberoende av varandra. Pga utrym-messkäl valde vi att göra två buffrar samtidigt så att de kan ligga nära varandra. Var buffer för sig består av två inverterare som är kaskadkopplade, där första inverteraren är mindre än den andra (se stycke 5.1.3 Buffer och fig 5.4). Buffern är kopplad på raddekoderns utgång (ordlinje) dvs mellan raddekoder och ROM-minne. Totalt består layouten av 8 transistorer varav 4 är n-mos och 4 p-mos.

59

A.6 Layout för komplett raddekoder

Layouten nedan är en komplett raddekoder med ettceller, nollceller, resistanser, inverterare och dubbelbuffrar (se appendix A1, A2, A3, A4 och A5). Längst upp på layouten ses inverterarna som är kopplade till minnesarean (ett och nollcells-matrisen). Till vänster om layouten ses resistanserna och till höger om layouten dubbelbuffrarna. De tjockare linjerna är vdd och jordledningar.

A.7 Layout för ettcell (ROM-matris)

Denna ettcell genereras (från en textfil som läses in av skill) och kopplas sam-man lodrät och vågrät, och bildar en matris (minnesarea). Ettcellen ger en etta ut på datalinjen, dvs utdata. Ettcellslayouten för raddekodern (se appendix A1) är vriden 90 grader medurs vid jämförelse med ROM-matrisens ettcell.

61

A.8 Layout för nollcell (ROM-matris)

Nollcellen är en ettcell med en applicerad NMOS-transistor. Nollcellen används då man önskar en nolla ut på datalinjen, dvs utdata. Nollcellen appliceras på samma sätt som ettcellen (se appendix A7). Nollcellslayouten för raddekodern (se appendix A2) är vriden 90 grader medurs vid jämförelse med ROM-matri-sens nollcell.

A.9 Layout för resistans (ROM-matris)

Layouten genereras och appliceras som resistanser och sitter på datalinjerna till raddekoderna, dvs mellan vdd och datalinjerna. Den enda skillnaden jämfört med raddekoderns resistans är att de har olika orientering, dvs ordlinjen är hori-sontell i stället för vertikal samt vdd-linjen vertikal i stället för horihori-sontell.

63

A.10 Layout för ROM-minnesmatris

Minnesmatrisen nedan är en komplett minnesarea med ettceller, nollceller och resistanser, (se appendix A.7, A.8 och A.9). Längst upp på layouten ses resistan-serna som är kopplade mellan ett och nollcellsmatrisen och vdd. Den tjocka leda-ren överst i figuleda-ren är vdd och längst ned finns jordledningen.Till vänster i

layouten (de 3 icke kopplade polyledningarna) kopplas ordlinjerna från raddeko-dern.

A.11 Layout för passtransistor (kolumndekoder)

Passtransistorcellen består av en NMOS-transistor, gate-kontakt till adressled-ning samt en PD C-kontakt.

65

A.12 Layout för komplett mux (kolumndekoder)

Kolumndekoder med 16 ingångar, fyra utgångar samt två adressingångar. Pass-transistorcellerna (se appendix A.11) ligger mitt i strukturen omgivna av in och utbuffrar samt inverterare till adressingångarna.

A.13 Layout för blockaktiverare (blockdekoder)

Blockaktiverare med en adressingång samt två "tristate"-steg (till höger). I bilden syns också den buffer som mha signalen "enable-invers" stänger av ROM-min-nets matning när blocket inte adresseras (längst till vänster).

67

A.14 Layout för blockväljare (blockdekoder)

Blockväljaren har i princip samma struktur som kolumndekodern roterad 90 gra-der (för att ungra-derlätta ledningsdragningen mellan blockutgångarna och blockde-koderingångarna).

På svenska

Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare – under en längre tid från publiceringsdatum under förutsättning att inga extra-ordinära omständigheter uppstår.

Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för ick-ekommersiell forskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns det lösningar av teknisk och administrativ art.

Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för upphovsmannens litterära eller konst-närliga anseende eller egenart.

För ytterligare information om Linköping University Electronic Press se för-lagets hemsida http://www.ep.liu.se/

In English

The publishers will keep this document online on the Internet - or its possible replacement - for a considerable time from the date of publication barring excep-tional circumstances.

The online availability of the document implies a permanent permission for anyone to read, to download, to print out single copies for your own use and to use it unchanged for any non-commercial research and educational purpose. Sub-sequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional on the consent of the copyright owner. The pub-lisher has taken technical and administrative measures to assure authenticity, security and accessibility.

According to intellectual property law the author has the right to be men-tioned when his/her work is accessed as described above and to be protected against infringement.

For additional information about the Linköping University Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its WWW home page:http://www.ep.liu.se/

Mikael Sundquist Anders Ousbäck