UMC tar i bruk 45 nm-teknikk

[int20h]

United Microelectronics (UMC) er nå klar til å ta i bruk 45 nm-teknologi i sin produksjon av SRAM-brikker.

Les mer

[G]

Er SRAM det som benyttes i RAM-brikker? Hva produserer UMC ellers av forskjellige produkter?

[Anders Jensen]

Eh.. Trodde en stund der at halvleder industrien var blitt snudd på hue, men så har altså ikke UMC tatt i bruk 45nm likevell.

 

Er SRAM det som benyttes i RAM-brikker? Hva produserer UMC ellers av forskjellige produkter?

7335064[/snapback]

SRAM benyttes ikke i vanlige minnemoduler fordi det er alt for dyrt og fordi det ikke kan levere samme kapasitet. En SRAM-celle (enhet som kan lagre 1 bit) tar omtrent 5 ganger så mye plass som en DRAM-celle. Derfor benyttes DRAM til RAM brikker. De får større kapasitet på samme areal og blir dermed også billigere.

 

SRAM benyttes blandt annet integrert på prosessor brikken i form av cache. SRAM er vesentlig raskere enn DRAM serlig når det kommer til latency. Om båndbredden er bedre for SRAM er litt vanskelig å si noe fornuftig om siden båndbredde i stor grad er "teknologi uavhengig" og mer implementasjons avhengig. DRAM kunne også hatt svimlende båndbredde om den var integrert på samme brikke som prosessoren. SRAM har imidlertid den fordelen at informasjonen i cellen ikke går tapt, selv ved lesing av cellen (den går riktig nok tapt om strømmen slås av). Dette skjer imidlertid for DRAM slik at en må ha et system internt i brikken for å skrive tilbake informasjon som er blitt lest. Dette bidrar til økt forsinkelse (latency) og serlig om en må lese og skrive til det samme adresseområdet rett etter herandre.

 

SRAM benyttes også som minne til en del høyytelse prosessorsystemer uten krav til stor lagringskapasitet slik som nettverksrutere.

Endret 22. november 2006 av Anders Jensen

[Quintero]

SRAM har imidlertid den fordelen at informasjonen i cellen ikke går tapt, selv ved lesing av cellen (den går riktig nok tapt om strømmen slås av). Dette skjer imidlertid for DRAM slik at en må ha et system internt i brikken for å skrive tilbake informasjon som er blitt lest. Dette bidrar til økt forsinkelse (latency) og serlig om en må lese og skrive til det samme adresseområdet rett etter herandre.

7335204[/snapback]

Det kan hende vi er på hver vår side, men jeg skjønner ikke hvordan en overgang fra lesing til skriving i samme adresseområde skal være noen worst-case, eller hvordan dette skal være spesielt relatert til minnecellenes oppbygning. Samme adresseområde tolker jeg som samme rad, og i det scenariet vil jeg snarere si at ulempen ved DRAMs krav til refresh kamufleres fordi raden ikke må lukkes, og deretter aktiveres igjen før skrivingen kan påbegynnes (og disse tilleggs-forsinkelsene er som du sier en betydelig ulempe ved DRAM). En rad-aktivering må jo i alle tilfeller inntreffe først, og med mindre skrive-kommandoen (som kommer etter lese-kommandoen) appellerer til en lukket rad i en hvilken som helst bank vil ikke en aktiv rad automatisk lukkes ved et skifte fra lesing til skriving. Det ville jo være lite effektivt.

 

Så lenge det ikke oppstår en Page Conflict (dvs at innholdet i Sense Amplifiers må skrives tilbake til minnecellene (tRP) slik at en annen rad deretter kan aktiveres (tRCD)), er det ingen ekstra forsinkelser involvert utover Bus Turnaround og Write CAS/Write Preamble (tDQSS). Og som vi ser på grafen må ikke disse inntreffe etter tur, så forsinkelsen/boblen på databussen kan være så liten som 0.75 tCK for DDR1. Så jeg kan ikke se at nevnte eksempel spesielt fremhever svakhetene til DRAM - slik jeg tolker det vil jeg heller hevde at de skjules i høy grad.

 

En Read-to-Write Turnaround til samme rad, eller et hopp til en hvilken som helst aktiv rad i andre interne banker, ser slik ut:

Endret 23. november 2006 av Quintero

[Storebj0rn]

Hva produserer UMC ellers av forskjellige produkter?

7335064[/snapback]

UMC er "bare" et independent foundry, dvs et "chiptrykkeri".

De produserer alt mulig rart av halvledere for diverse kunder. Det at de nå har greid å lage en 45nm chip er bare for å skryte til sine kunder... Kundene, som er chipdesignere, har fortsatt endel praktiske problemer de må løse før det kan lages brukbare produkter her...

[Anders Jensen]

Det kan hende vi er på hver vår side, men jeg skjønner ikke hvordan en overgang fra lesing til skriving i samme adresseområde skal være noen worst-case

7341188[/snapback]

Ja det der ble jo helt feil. Jeg må ha kortslutta en eller annen plass. Er ikke helt sikker på hva jeg tenkte. Det er jo helst ved hurtig endring av rad og kolonner at en vil få problemer. Eventuelt ved lesing fra samme sted rett etter hverandre. Litt søkt case kanskje?

[Quintero]

@ Anders Jensen:

 

Mtp de generelt gode mulighetene for å kamuflere interne forsinkelser, vil jeg si at Page Conflicts er de situasjonene som er minst gunstige for DRAM. Det at én rad om gangen må overføres til sense amplifiers, forsterkes, og gjenopprettes til minnecellene etter endt operasjon gjør jo at den spesifikke banken går på "tomgang" i noen sykluser. Hvor stor denne ulempen er, kommer mest an på antallet banker, antallet brikker, og hvordan kontrolleren organiserer dataene. For å gi flest mulig Page Hits og færrest mulig Page Conflicts hjelper det jo en hel del å ha mange banker å spre radene utover, slik at færrest mulig rader pr bank må konkurrere om å være den aktive. Ved bruk av Bank Interleaving vil det også være gode muligheter for å aktivere og lukke rader "i bakgrunnen" av overføringer, for det er jo uansett bare ett adresseområde som har tilgang til databussen til enhver tid. Bruk av Idle Cycle Limit gjør at rader forblir aktive etter endt overføring (med mindre det kommer en forespørsel rettet mot en annen rad i samme bank), dermed kan tRCD-forsinkelsen spares hvis noen andre kolonner skal leses innenfor ICL-intervallen.

 

Diagrammet gir en grei demonstrasjon på hvor effektivt det kan være å aktivere rader i påvente av ledige timeslots på databussen:

 

[Anders Jensen]

Du har vel ikke noe genialt lesestoff på minneorganisering å anbefale? Jeg skulle lest meg litt opp på dette.

[Quintero]

Vi har vel havnet et godt stykke utenfor tema i denne tråden, men jeg kan skumme igjennom "arkivet" og sende en PM etterhvert.