Tecnologia Thyristor-RAM per le soluzioni GlobalFoundries

[Redazione di Hardware Upg]

Link alla notizia: http://www.hwupgrade.it/news/busines...ies_29027.html

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

Click sul link per visualizzare la notizia.

[Foglia Morta]

Qui: http://www.pcper.com/article.php?aid...e=expert&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/g...ne-di-memoria/ ). Sarebbe interessante sapere quanto si guadagna in densità ( MB / mm^2 ) e se le performance sono accettabili per questo tipo di utilizzo

[alesc]

E la fantomatica Z-Ram che fine ha fatto? C'entra niente con questa?

[bjt2]

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.

[Pleg]

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.

[max8472]

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.

[maumau138]

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

[killer978]

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

[lucusta]

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.

[Pleg]

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

[lucusta]

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...

[Pleg]

Originariamente inviato da lucusta

un simulatore, tipo earth simulator, credo che funzioni molto meglio in puro risc che in x86.

Earth Simulator e' cosi' veloce perche' usa processori vettoriali (NEC SX-6).
Per quel che riguarda processori superscalari, non c'e' cosi' tanta differenza tra avere un'ISA RISC e una CISC --- dopo il front-end (fetch + decode) fanno praticamente lo stesso lavoro.