Nuovo memory controller a 3 canali per i processori Intel Nehalem

Nuovo memory controller a 3 canali per i processori Intel Nehalem

Memory controller a 3 canali per alcune delle cpu Intel basate su architettura completamente rinnovata, attese per il 2008

di pubblicata il , alle 11:14 nel canale Processori
Intel
 
32 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
jappilas12 Giugno 2007, 22:57 #31
Originariamente inviato da: xeal
<cut>
E non mi stupirei nemmeno se CSI e HTT si assomigliassero un po' (non dico che si ripeterà la storia dei nomi già vista con EM64T e AMD64, ma potremmo andarci vicini).
no infatti ...che Hypertransport e Crime scene inv... pardon, Common System interconnect finiscano per assomigliarsi è pressochè certo
per vari motivi, primi tra tutti che entrambi assolvono alla stessa funzione e si sa dalle anticipazioni, di caratteristiche comuni (come, se non ricordo male, la possibilità di funzionare in assenza di piste perfettamente calibrate e parificate grazie a un accorgimento a livello di signaling )

sono però propenso a credere che intel implementerà CSI su tecnologia proprietaria (usando magari solo un sistema di signaling di "livello fisico" proprietario) perchè questo le consentirebbe, diversamente da una soluzione basata su uno standard aperto, di ricevere royalties dai produttori di chipset terzi ...
Per il discorso del trial channel: che stiano pensando ad una scalabilità dei core per multipli di 3 (o almeno ad un prossimo 6-core), con i canali attribuiti ad un singolo gruppo di core che se li contende (ad esempio, in un 6-core avrei 3 gruppi di 2 core, ciascuno con il suo banco di memoria "dedicato" - una specie di Numa "interno" per gli accessi in memoria dei core di uno stesso socket)?
credo non c' entri tanto il numero dei core, quanto l' intenzione di:
da un lato, trovare un compromesso che consenta di ottenere un' ampiezza di banda consistente senza raddoppiare il numero di piste on board / pin on package (che sarebbero circa 200 per ogni canale DDR ), mantenendo gestibile la complessità circuitale della piastra madre
nonchè introdurre (o se già presente, sfruttare più estensivamente) reti logiche quali crossbar o, meglio ancora, ring bus, che consentirebbero di disaccoppiare il numero di canali indipendenti dal resto dei componenti da servire (core di processori, ma anche periferiche attraverso il tunneling delle richieste DMA ) - questo consentirebbe di scalare, ma direttamente sulla banda fornita più che sul numero di core
Chissà (l'ho buttata giù così, magari non c'entra una mazza, e invece è solo un modo per aumentare la banda oltre i limiti del dual channel - anche se già un dual channel "completo", volendo, consente accessi indipendenti ai due canali)...
ricordavo che, almeno per quanto riguarda la serie 800 intel e gli athlon fx, il sottosistema di memoria dual channel era realizzato in lockstep, cioè come un unico canale a 128 bit composto da due da 64, con interleaving dei dati letti da o scritti in memoria ed esecuzione sincronizzata delle due "metà" della singola transazione ( questo sarebbe in effetti alla base della criticità della simmetria dei timings tra i moduli sull' uno e sull' altro canale)
non sono certo invece della situazione sulla serie intel 9xx e successivi 3x
La prima che hai detto, il corrispettivo di HyperTransport si chiamerà CSI, userà tecnologie all'avanguardia e scoprirà subito se un processore ruba la confettura (rigorosamente SantaRosa) agli altri - scusate, ma non ho resistito
xeal13 Giugno 2007, 03:59 #32
Originariamente inviato da: jappilas
sono però propenso a credere che intel implementerà CSI su tecnologia proprietaria (usando magari solo un sistema di signaling di "livello fisico" proprietario) perchè questo le consentirebbe, diversamente da una soluzione basata su uno standard aperto, di ricevere royalties dai produttori di chipset terzi ...


Si, in effetti Intel può permettersi un gioco di questo tipo, contrariamente ad AMD quando ha tirato fuori htt (ma anche x86-64, per certi versi), uno standard chiuso le avrebbe tagliato le gambe. Solo, dicevo che essendo le funzioni molto simili, essendosi dimostrato htt una soluzione valida, ed essendo Intel, quale membro del consorzio htt, in pieno diritto di sfruttare le conoscenze su questa tecnologia, mi sembrerebbe una scelta logica partire da quello che ha già (= conoscenza di htt) per "trarne ispirazione" (anche semplicemente prendendolo come riferimento valido per la struttura d'insieme, o per certi dettagli implementativi, come quello che dicevi) e personalizzare/differenziare la propria soluzione (molto probabilmente proprietaria) come si preferisce, vuoi per necessità tecniche, per introdurre qualcosa che meglio si adatti alle proprie architetture, o per "migliorare" qualcosa (sempre in funzione dei propri scopi), vuoi per questioni economiche.

introdurre (o se già presente, sfruttare più estensivamente) reti logiche quali crossbar o, meglio ancora, ring bus, che consentirebbero di disaccoppiare il numero di canali indipendenti dal resto dei componenti da servire (core di processori, ma anche periferiche attraverso il tunneling delle richieste DMA ) - questo consentirebbe di scalare, ma direttamente sulla banda fornita più che sul numero di core


In effetti pensavo a un disaccoppiamento di questo tipo, però ho pensato anche a un paio di altre cose:

1) finora il numero dei core è semplicemente raddoppiato (1->2->4), ma al prossimo "step" ci ritroveremo con 8 core, oppure potrebbe esserci un processore intermedio con 6 core? magari per questioni di simmetrie nel layout, eventualmente dovute all'introduzione del memory controller e della logica di comunicazione interna dei core (insieme ad una L2 più grande, o eventualmente a una L3, se prevista)?

2) una volta disaccoppiati i canali, come li sfrutto? con un arbitraggio "generalizzato", con i suoi pro e i suoi contro (latenze maggiori?), oppure con una qualche gerarchia dei componenti rispetto alla loro priorità di accesso a ciascun canale, in maniera analoga, se vogliamo, a quello che fa numa con più socket, ancora con dei pro e dei contro (come ogni scelta)?

Mettendo insieme i due dubbi ho pensato: un eventuale 6-core potrebbe sfruttare la soluzione con accesso gerarchico ai canali, avvantaggiandosi del rapporto intero tra le risorse e i canali, così come un 9-core, e così via (ma temo che potrebbe complicare un po' la vita allo scheduler lato software, ma forse non più di tanto). Per quanto riguarda il dma, non potrebbe sfruttare CSI "esternamente", un po' come accade per htt e le vga integrate (che non gravano sul controller integrato nelle cpu amd)?

ricordavo che, almeno per quanto riguarda la serie 800 intel e gli athlon fx, il sottosistema di memoria dual channel era realizzato in lockstep, cioè come un unico canale a 128 bit composto da due da 64, con interleaving dei dati[...]


Si, in effetti dovrebbe essere così. Se la memoria non mi inganna, il northbridge degli Nforce2 aveva un dual channel disaccoppiato, invece. Per quanto riguarda gli amd, ricordavo di aver letto di un disaccoppiamento dei due canali, però non saprei dire se sia stato implementato da "qualche parte", o se invece si trattava di una delle caratteristiche del progetto K8L (che poi, non ho ben capito come, si è trasformato in k10). Per i chipset Intel dopo la serie 800 non ricordo neanch'io.



No, guarda, non scherziamo con le cose serie: al prossimo nome strano che tirano fuori alla Intel io mi convincerò definitivamente che lo fanno apposta

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