Tecnologia Thyristor-RAM per le soluzioni GlobalFoundries

Tecnologia Thyristor-RAM per le soluzioni GlobalFoundries

GlobalFoundries e T-RAM Semiconductor annunciano un accordo per l'utilizzo della tecnologia Thyristor-RAM in prodotti costruiti dalla prima con tecnologie a 32 e 22 nanometri

di pubblicata il , alle 16:29 nel canale Private Cloud
 

GlobalFoundries e T-RAM Semiconductor Inc. hanno annunciato un accordo di joint development incentrato sull'utilizzo della tecnologia Thyristor-RAM di T-Ram all'interno della tecnologia produttiva a 32 nanometri e a 22 nanometri che GlobalFoundries sta sviluppando all'interno delle proprie fabbriche per l'utilizzo su prodotti di propri clienti.

Come noto, GlobalFoundries è stata originata dalla divisione di AMD tra parte ingegneristica e vendite e quella produttiva, quest'ultima confluita all'interno di GlobalFoundries. Il principale, e di fatto al momento attuale, cliente di questa azienda è ovviamente AMD, che figura tra i soci; GlobalFoundries sta attivamente operando proponendosi sul mercato quale foundry player, cioè azienda capace di produrre tecnologia sviluppata da terze parti.

L'utilizzo di tecnologia Thyristor-RAM permetterà di sviluppare prodotti, con i futuri processi produttivi prima indicati, nelle quali un elevato quantitativo di memoria cache potrà venir implementato, senza limitazioni in termini sia di superficie del die occupata sia di consumo.

Questa tecnologia potrebbe venir utilizzata attivamente da AMD per le proprie soluzioni CPU costruite con tecnologia a 32 nanometri, aprendo spazio alla integrazione di cache in quantitativi più elevati rispetto a quanto sia possibile attualmente con le tecnologie a disposizione, ferma restando la superficie complessiva del die e quindi il numero complessivo di processori ottenibili per ogni Wafer. Al momento attuale AMD non ha fornito alcun tipo di conferma ufficiale in questa direzione.

Questa tecnologia, stanto a quanto anticipato da GlobalFoundries, apre spazi di utilizzo interessanti anche in design system on a chip per netbook, smartphones e in generale per dispositivi di ridotte dimensioni dove buona potenza di elaborazione ed elevata autonomia devono andare di pari passo.

11 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
Foglia Morta19 Maggio 2009, 17:09 #1
Qui: http://www.pcper.com/article.php?ai...xpert&pid=3 si dice che potrebbe essere utilizzata anche con processi produttivi Bulk , quindi anche gpu volendo.
RV770 ha più di 5 MB di cache L2 dedicati ai 4 memory controller ( http://www.appuntidigitali.it/3887/...one-di-memoria/ ). Sarebbe interessante sapere quanto si guadagna in densità ( MB / mm^2 ) e se le performance sono accettabili per questo tipo di utilizzo
alesc19 Maggio 2009, 17:31 #2
E la fantomatica Z-Ram che fine ha fatto? C'entra niente con questa?
bjt219 Maggio 2009, 19:06 #3
In pratica la cella è un Thyrisistore, ossia una serie di 4 giunzioni p,n,p,n bipolari.

Una giunzione p-n è un diodo.
Una serie p-n-p o n-p-n è un bjt.
Una serie n-p-n-p è un thyrisistore.

Questi sono usati nei regolatori di velocità per trapano e in alcuni dimmer per lampadine. Ma ovviamente sono versioni di potenza.
Tramite un thyrisistore e una capacità parassita fanno una cella RAM, occupando lo spazio di 2 transistor. E' compatibile con i processi BULK e SOI, la cella ha una forma regolare e quindi questo facilita il layout dei cavi di collegamento e aumenta lo yield. Le celle 6T (a loro dire) diventano più "delicate" al diminuire del processo, perchè la variazione della tensione di soglia dei transistors e altri effetti, abbassano la probabilità di avere una cella funzionante. Invece le T-RAM dovrebbero addirittura migliorare la "qualità" allo scalare del processo. Unito alla forma regolare, dovrebbe consentire di avere grandi cache con alto yield. Se questo è vero, allora ciò spiega perchè ci si è fermati a 8MB di cache L3 con il processo a 45nm, quando ci sono CPU (come gli Itanium o i POWER 6) con anche 36MB di cache L3, mi pare prodotte a 65nm o 90nm...
Per quanto riguarda le prestazioni, queste dovrebbero essere comparabili a quelle di una cella SRAM normale.
La densità dovrebbe essere 4 volte quella delle celle SRAM. Quindi ci possiamo aspettare cache da 24MB della stessa dimensione di quelle da 6MB a 45nm e magari cache da 32MB nelle CPU da 32nm...
In più ha il vantaggio dei bassi consumi...


La Z-RAM è invece una cella a 1 transistor. E' in pratica una normale memoria DRAM. E può essere implementata solo nel SOI.
Pleg19 Maggio 2009, 20:08 #4
Originariamente inviato da: bjt2
Le celle 6T (a loro dire) diventano più "delicate" al diminuire del processo, perchè la variazione della tensione di soglia dei transistors e altri effetti, abbassano la probabilità di avere una cella funzionante.


E' vero, non e' solo "a loro dire"
La diminuzione della dimensione dei MOS aumenta le loro variazioni, e diventa piu' difficile costruire uan cella affidabile (e se ne devi mettere insieme qualche milione, e garantire una resa per cella del 99.999%, diventa difficile!). E la diminuzione della tensione di alimentazione non aiuta per nulla.



Originariamente inviato da: bjt2
...allora ciò spiega perchè ci si è fermati a 8MB di cache L3 con il processo a 45nm, quando ci sono CPU (come gli Itanium o i POWER 6) con anche 36MB di cache L3, mi pare prodotte a 65nm o 90nm...


Bisogna anche vedere costi e vantaggi: in varie recensioni qui su HW si e' visto che passare ad es. da 4 a 6/12 MB di L2 fa guadagnare pochi %, e il costo invece cresce assai.
max847219 Maggio 2009, 22:48 #5
Originariamente inviato da: Pleg
E' vero, non e' solo "a loro dire"
Bisogna anche vedere costi e vantaggi: in varie recensioni qui su HW si e' visto che passare ad es. da 4 a 6/12 MB di L2 fa guadagnare pochi %, e il costo invece cresce assai.


Infatti l'aumento della cache non ha senso.

Le possibili applicazioni che mi vengono in mente sono:

- CPU con più transistor, visto che a parità di cache questa occupa meno spazio, quindi più "potenti"

- CPU complessivamente più piccole, quindi più economiche

- CPU che necessitano di ospitare più degli attuali 4 core...con lo spazio guadagnato, ci infilano altri 2/4 core e siamo tutti contenti.
maumau13819 Maggio 2009, 23:00 #6
Aaaaaaahhhhhhhhhhhhh,
mi piacerebbe tanto sapere di cosa state parlando .
Comunque qualcosina l'ho capita.
Sulle velocità non si sa niente?

Originariamente inviato da: max8472
Infatti l'aumento della cache non ha senso.

Le possibili applicazioni che mi vengono in mente sono:

- CPU con più transistor, visto che a parità di cache questa occupa meno spazio, quindi più "potenti"

- CPU complessivamente più piccole, quindi più economiche

- CPU che necessitano di ospitare più degli attuali 4 core...con lo spazio guadagnato, ci infilano altri 2/4 core e siamo tutti contenti.


Propendo di più per la terza ipotesi, in quanto aumentando i core devono aumentare anche la cache, e farlo senza ingigantire troppo i chip può essere un vantaggio
killer97820 Maggio 2009, 07:35 #7
Cache + grande in minor spazio, bene bene. Mi chiedevo cosa avesse fatto AMD delle vecchie acquisizioni, appunto brevetti su Z-RAM e company, non è stata a dormire
lucusta20 Maggio 2009, 10:24 #8
no Pleg,
il quantitativo di caches e' sempre apprezzato, ma dipende strettamente dall'ambito di utilizzo del processore.
se prendi un nuovo athlon II X4 e lo condronti con un phenom II X4, essendo il primo senza L3 che nel secondo e' di ben 6MB, le sue prestazioni saranno decisamente ridotte in applicazioni che richiedono salti incondizionati (calcoli scientifici, statistici, giochi, database...), nelle applicazioni che sfruttano calcoli ricorsivi, specialmente algoritmati, come ad esempio la codifica, la differenza e' praticamente nulla, a meno di non avere un set d'istruzioni che superi i 512KB della L2 che sta' su ogni processore dell'AIIx4.
il PIIx4 e' comunque limitato anche nei calcoli con salti incondizionati, in quanto la sua L3 e' comunque piccola rispetto alla potenza elaborativa dei 4 core (haanno fame e non hai spazzio per mettergli i dati!); maggiorare la L3 da 6 a 12MB incrementerebbe, e non di poco, l'uso di quel processore negli ambiti sopra descritti, che pur esseendo un x86, percio' con codice nativo che richiede ottimizzazioni che non sempre vengono o possono essere operate, lo renderebbe una CPU decisamente appetibile in ambito server computazionale.
la principale evoluzione prestazionale pero' si otterrebbe sui registi, la L1 e la L2; avere un AIIx4 con 4 core che hanno registri quaadruplicati, una L1 da 512KB ed una L2 da 2MB per singolo processore, potrebbe non far rimpiangere affatto la caches di 3° livello condivisa dei phenom...
dal lato intel, pensa ad un c2d con L1 che passa da 64Kb a 256Kb, o soprattutto ad un atom, che essendo una CPU in order di caches ne avrebbe bisogno a vagonate, che passa da 56Kb a 232Kb, con in piu' un abbassamento di latenza (2 transistor contro un array di 8) e soprattutto di consumo..

il giovamento di tale tecnologia e' applicabile sia a processori per i netbook che a quelli per i supercomputer.
Pleg20 Maggio 2009, 11:24 #9
Originariamente inviato da: lucusta
no Pleg,
il quantitativo di caches e' sempre apprezzato, ma dipende strettamente dall'ambito di utilizzo del processore.


Esatto: e se guardi recensioni recenti qui su HW, il raddoppio di cache porta di solito pochi % in piu' di prestazioni. Quindi, per l'uso comune, 6 MB di cache L2 o 12 non fanno molta differenza (anzi, peggiorano il rapporto performance/watt).



Originariamente inviato da: lucusta
le sue prestazioni saranno decisamente ridotte in applicazioni che richiedono salti incondizionati (calcoli scientifici, statistici, giochi, database...), nelle applicazioni che sfruttano calcoli ricorsivi, specialmente algoritmati, come ad esempio la codifica, la differenza e' praticamente nulla, a meno di non avere un set d'istruzioni che superi i 512KB della L2 che sta' su ogni processore dell'AIIx4.


Scusa, non ho capito nulla.
1. I calcoli scientifici sono tra quelli che hanno meno salti incondizionati (e anche condizionati) di tutti: di solito sono floating point intensive, con block size grossi.
2. Cosa significa "set d'istruzioni" che supera i 512kiB ? Intendi dire il working set?
3. Quale "codifica"? Video? Applicazioni multimediali intense (come appunto codifica/decodifica video) beneficiano poco delle cache (nonostante la gran mole di dati da processare) perche' la data locality e' ridotta.



Originariamente inviato da: lucusta
il PIIx4 e' comunque limitato anche nei calcoli con salti incondizionati, in quanto la sua L3 e' comunque piccola rispetto alla potenza elaborativa dei 4 core (haanno fame e non hai spazzio per mettergli i dati!)


Cosa c'entrano i jump/branch colla dimensione del working set?


Originariamente inviato da: lucusta
maggiorare la L3 da 6 a 12MB incrementerebbe, e non di poco, l'uso di quel processore negli ambiti sopra descritti, che pur esseendo un x86, percio' con codice nativo che richiede ottimizzazioni che non sempre vengono o possono essere operate, lo renderebbe una CPU decisamente appetibile in ambito server computazionale.



Questo e' ancora piu' oscuro: perche' l'ISA x86 si presterebbe poco a ottimizzazioni (rispetto a quali ISA?)? Di che genere?
BTW, di supercomputer costruiti con Opteron/Xeon ce ne sono parecchi, qualis arebbero le limitazioni?



Originariamente inviato da: lucusta
la principale evoluzione prestazionale pero' si otterrebbe sui registi, la L1 e la L2; avere un AIIx4 con 4 core che hanno registri quaadruplicati, una L1 da 512KB ed una L2 da 2MB per singolo processore, potrebbe non far rimpiangere affatto la caches di 3° livello condivisa dei phenom...


Parli dei registri fisici? Che vantaggio avresti a quadruplicare i registri rinominati senza allargare anche l'Instruction Window e il Reorder Buffer... e quindi tutto il datapath? E poi cosa fai, un superscalare a 8 vie? Un incubo di progettazione (per non parlare del testing), senza grossi benefici.


Originariamente inviato da: lucusta
dal lato intel, pensa ad un c2d con L1 che passa da 64Kb a 256Kb,


E la latenza? Qual e' la latenza di queste nuove memorie? Non possiamo fare la L1 piu' grossa, se aumenta la latenza.



Per quel che riguarda il numero di core, invece: e' vero che potrebbe essere utile ridurre la cache e usare l'area per avere piu' core, ma bisogna tenere conto di almeno due cose:
- all'aumentare dei core (anzi, dei thread che girano contemporaneamente) il trashing della cache cresce; non e' chiaro quanto sia utile avere una cache grossa, contro invece una piu' piccola ma molto piu' associativa (ad es. una Pseudo-Fully-Associative Cache)
- all'aumentare dei core diventa piu' difficile mantenere la coerenza e consistenza della memoria; oltre 16, diventa alquanto difficile
lucusta20 Maggio 2009, 21:56 #10
Originariamente inviato da: Pleg
Esatto: e se guardi recensioni recenti qui su HW, il raddoppio di cache porta di solito pochi % in piu' di prestazioni. Quindi, per l'uso comune, 6 MB di cache L2 o 12 non fanno molta differenza (anzi, peggiorano il rapporto performance/watt).


..e che dipende dall'applicazione che sta' computando, e quante ne sta' compuntando nello stesso momento (parliamo di multitherad, ma il multi tasking lo lasciamo indierto?)




Originariamente inviato da: Pleg
Scusa, non ho capito nulla.
1. I calcoli scientifici sono tra quelli che hanno meno salti incondizionati (e anche condizionati) di tutti: di solito sono floating point intensive, con block size grossi.
2. Cosa significa "set d'istruzioni" che supera i 512kiB ? Intendi dire il working set?
3. Quale "codifica"? Video? Applicazioni multimediali intense (come appunto codifica/decodifica video) beneficiano poco delle cache (nonostante la gran mole di dati da processare) perche' la data locality e' ridotta.

1)esempio matlab non e' propriamente parco di risorse;
2)no, non il working set, ma esattamente le istruzioni da eseguire.
3) infatti la differenza tra' avere zero MB di L3 o 24MB di L3 e nulla.



Originariamente inviato da: Pleg
Cosa c'entrano i jump/branch colla dimensione del working set?


multitasking, scusa, mi sono espresso male, intendevo parlare di piu' applicazioni all'unisono con alto sfruttamento della ram.

Originariamente inviato da: Pleg
Questo e' ancora piu' oscuro: perche' l'ISA x86 si presterebbe poco a ottimizzazioni (rispetto a quali ISA?)? Di che genere?
BTW, di supercomputer costruiti con Opteron/Xeon ce ne sono parecchi, qualis arebbero le limitazioni?


esistono ISA migliori e piu' snelle per il puro calcolo computazionale; dipende strettamente dall'aspetto pratico dell'applicativo.
un simulatore, tipo earth simulator, credo che funzioni molto meglio in puro risc che in x86.
poi, che i processori X86 siano arrivati ad essere i progessori general porpouse piu' veloci, e' un'altro punto di discussione..



Originariamente inviato da: Pleg
Parli dei registri fisici? Che vantaggio avresti a quadruplicare i registri rinominati senza allargare anche l'Instruction Window e il Reorder Buffer... e quindi tutto il datapath? E poi cosa fai, un superscalare a 8 vie? Un incubo di progettazione (per non parlare del testing), senza grossi benefici.


non so.. molto meno spazio sul die occupato dalla caches permette l'implementazione di altre tecnologie... (come giustamente riprendi tu piu' sotto con l'uso di piu' core).


Originariamente inviato da: Pleg
E la latenza? Qual e' la latenza di queste nuove memorie? Non possiamo fare la L1 piu' grossa, se aumenta la latenza.


qui non credo che ti riuscirei a rispondere! pecco d'ignoranza.

Originariamente inviato da: Pleg
Per quel che riguarda il numero di core, invece: e' vero che potrebbe essere utile ridurre la cache e usare l'area per avere piu' core, ma bisogna tenere conto di almeno due cose:
- all'aumentare dei core (anzi, dei thread che girano contemporaneamente) il trashing della cache cresce; non e' chiaro quanto sia utile avere una cache grossa, contro invece una piu' piccola ma molto piu' associativa (ad es. una Pseudo-Fully-Associative Cache)
- all'aumentare dei core diventa piu' difficile mantenere la coerenza e consistenza della memoria; oltre 16, diventa alquanto difficile


permette pero' d'integrare, su x86, tecnologie migliorative (SOC), in cui il sistema richiede molti piu' buffer, preferenzialmente separati...
GPU, AudioPU, I/O e core logici integrati sullo stesso chip, ma come entita' separate, a cui servono, giustamente, buffer separati; meno dimensione per la caches, piu' possibilita' di implementazione...

Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".

La discussione è consultabile anche qui, sul forum.
 
^