[Thread Ufficiale V3.0] AMD K10 Phenom Quad/Triple/Dual Core

[paolo.oliva2]

Originariamente inviato da Scrambler77

Ma che significa "step successivo del silicio"??

Lo stepping di una cpu è la versione della cpu stessa. Uno stepping successivo risolve problemi di tipo funzionale (i bugs) e introduce miglioramenti costruttivi (ottimizzazione dei path, riduzione dei consumi, aumento delle frequenze) rispetto al precedente.

Un bug funzionale non si risolve semplicemente ristampando la cpu. Credi davvero che al microscopio un E6600 B2 è uguale ad un E6600 G0?

Quando leggi "AMD fixes the TLB errata in silicon" non significa che ha soltanto ristampato la stessa CPU. E' stata certamente revisionata (nuovo step, appunto) a livello hardware per risolvere il problema (ma a quanto pare introducendone altri ).

Da quello che so io, quando il filmware è quello e si perfeziona il silicio per ridurre i bug, si ha la stessa lettera con numeri differenti, tipo B0 BA B2 B3....
Quando cambia la prima lettera, es C0, cambia anche l'architettura. Ad esempio il C0, C1 C2 Deneb, l'architettura è uguale al 100%, ma si cerca di far combaciare le caratteristiche dell'architettura alle caratteristiche del silicio, il che non vuol dire cambiare architettura, mentre Chiaramente da BX a CX è cambiata architettura e giustamente è cambiata la lettera iniziale. Se avessero portato il B3 tale e uguale sul 45nm, l'avrebbero chiamato B4... non C0.
Non puoi paragonare in questa logica il B2 e B3 con il E6600 B2 e G0, in quanto cambiando anche la prima lettera, vuol dire che sono intervenuti anche nell'architettura.

Riassumendo, per me, la lettera rappresenta lo studio dell'architettura, il numero o lettera aggiuntiva, rappresenta lo step, che è una modifica del silicio ma non dell'architettura. Le ottimizzazioni, non sono cambiamenti di architettura, se fanno parte di step, ma solo ottimizzazioni di latenze e cose similari.
Il cambiamento di architettura, inteso come modifiche alla cache, ai registri doppi o comunque cose che richiedono la riprogettazione a monte, appunto per diversificarli, si cambia la prima lettera.
Una cosa è B2-B3 e tutta unalta B3-C0, come nel tuo esempio E6600 B2 e E6600 C0

[Scrambler77]

Originariamente inviato da paolo.oliva2

Da quello che so io, quando il filmware è quello e si perfeziona il silicio per ridurre i bug, si ha la stessa lettera con numeri differenti, tipo B0 BA B2 B3....
Quando cambia la prima lettera, es C0, cambia anche l'architettura. Ad esempio il C0, C1 C2 Deneb, l'architettura è uguale al 100%, ma si cerca di far combaciare le caratteristiche dell'architettura alle caratteristiche del silicio, il che non vuol dire cambiare architettura.
Non puoi paragonare in questa logica il B2 e B3 con il E6600 B2 e G0, in quanto cambiando anche la prima lettera, vuol dire che sono intervenuti anche nell'architettura.

"Changes in the number (for example, A3) indicate minor design changes, whilst changes to both the letter and number are made following more extensive changes (for example, B2). "

Non c'è connessione precisa tra lettera e numero. In ogni caso, un cambio di stepping significa correggere il design hardware precedente. L'architettura è un'altra cosa, che evidentemente confondi con il disegno. La stessa architettura puoi disegnarla in vari modi (sul silicio). Un moltiplicatore sbloccato è probabilmente una pista interrotta (come avveniva in alcuni athlon, ricordi), di certo non è una modifica architetturale.

Non ho trovato scritto da nessuna parte che i bug di phenom sono riconducibili solo ed esclusivamente ad un problema di silicio utilizzato. Il problema è ciò che ci disegni sopra.

[capitan_crasy]

Originariamente inviato da Scrambler77

Ma che significa "step successivo del silicio"??

Lo stepping di una cpu è la versione della cpu stessa. Uno stepping successivo risolve problemi di tipo funzionale (i bugs) e introduce miglioramenti costruttivi (ottimizzazione dei path, riduzione dei consumi, aumento delle frequenze) rispetto al precedente.

Un bug funzionale non si risolve semplicemente ristampando la cpu. Credi davvero che al microscopio un E6600 B2 è uguale ad un E6600 G0?

Quando leggi "AMD fixes the TLB errata in silicon" non significa che ha soltanto ristampato la stessa CPU. E' stata certamente revisionata (nuovo step, appunto) a livello hardware per risolvere il problema (ma a quanto pare introducendone altri ).

non fare il polemico con me...
Lo sai benissimo cosa significa "step successivo del silicio".
AMD non ha progettato il K10 per ottenere il BUG 298, ma questo problema l'hanno scoperto e poi corretto lavorando sulla qualità del silicio non modificando l'architettura...

[maporca]

Mi e' venuto un dubbio nel guardare le performance fatte con il phenom e le MB con il sb600 vs. quelle con il sb750.

con l'sb750 si sale in frequenza RS. molto meglio che con il sb600.
anzi sembra che con Sb600 si possa arrivare SOLO fino ad un certo punto.

Eh.. ma .. allora come siamo messi coi deneb futuri ad elevata frequenza ?
A patto che l'alimentazione sia corretta, ad esempio io ho una asus M3A32-MVP Deluxe/WiFi-AP che supporta anche i 140W, se poi l'sb600 limitasse la possibilita' di deneb a frequenza alta , ecco che la compatibilita' sarebbe solo virtuale.
Leggo di phenom FX a 4GHz. ma l'sb600 permette si arrivare a 4ghz ?
in realta' la M3A32-MVP Deluxe/WiFi-AP e' phenomFX ready ma se da molte parti con Sb600 non si riesce ad andare sopra i 3.2 e con problemi, come si potra' montare ,nonostante i 140W possibili, un phenom FX ? e magari anche i deneb 45nm non FX ma sopra i 3ghz.

l'offerta sarebbe limitata ai deneb 2.8 - 3 Ghz ?

Ecco .. ho sto dubbio.
non parlo di OC !! eh. parlo di stock. ma se sb600 on oc non tiene sopra i 3.2 come potra' farlo a stock a 3.5 - 4 ?

[Mercuri0]

Originariamente inviato da capitan_crasy

Il problema è il silicio!
Il famoso BUG 298 e quelli antecedenti sono stati corretti/fixati attraverso uno step successivo del silicio non alla correzione dell'architettura K10.

Naaah, concordo con Scrambler. Dire "nuovo step di silicio" vuol dire che è una cosa che non può essere corretta con un aggiornamento del firmware (err... microcodice), ma che richiede delle correzioni "hardware".

Queste correzioni possono essere al livello del disegno geometrico del processore (che quindi servirebbero a correggere problemi di "processo") oppure anche al livello logico, cioè "architettura", anche se spostare 2 transistor non cambia certo l'architettura...

Originariamente inviato da Scrambler77

No Paolo, quei bug sono vizi di progettazione, non riconducibili al silicio. Se AMD continua a progettare le sue CPU "ad capocchiam", la vendita delle fab non servirà a niente...

A me un pò pare che ormai abbiamo tutti l'abbonamento ai PDF degli errata di AMD mentre ignoriamo quelli di lntel. Per esempio io quando ho scoperto che il no-execution bit è non funzionante su praticamente tutti i Core2, sono rimasto sorpreso che nessuno ne abbia parlato granché

[Scrambler77]

Originariamente inviato da capitan_crasy

non fare il polemico con me...
Lo sai benissimo cosa significa "step successivo del silicio".
AMD non ha progettato il K10 per ottenere il BUG 298, ma questo problema l'hanno scoperto e poi corretto lavorando sulla qualità del silicio non modificando l'architettura...

1) io non faccio il polemico con nessuno
2) stai ancora una volta confondendo l'architettura di una cpu con il suo design sul silicio. Sono 2 cose molto diverse, seppur collegate. Lo stepping di una architettura è una miglioria a livello di design, non una modifica dell'architettura.

Il bug si è verificato durante lo speeding della cpu, e lì si sono accorti che era necessario un workaround software per evitarlo. Successivamente hanno revisionato (sul silicio) quella parte del disegno, con il nuovo stepping.

A livello progettuale mi pare ovvio che AMD non abbia volutamente provocato quel bug, ma ha sbagliato il disegno dell'architettura stampato sul silicio. L'ha risolto successivamente revisionando il suo design (nuovo stepping) e migliorando la qualità dei materiali utilizzati...

Spero di essere stato chiaro...

[Spitfire84]

Interessante recensione (a parte l'ultima pagina dove non si capisce na cippa ) sul multitasking:

http://en.hardspell.com/doc/showcont...42&pageid=3301

[paolo.oliva2]

Originariamente inviato da Scrambler77

1) io non faccio il polemico con nessuno
2) stai ancora una volta confondendo l'architettura di una cpu con il suo design sul silicio. Sono 2 cose molto diverse, seppur collegate. Lo stepping di una architettura è una miglioria a livello di design, non una modifica dell'architettura.

Il bug si è verificato durante lo speeding della cpu, e lì si sono accorti che era necessario un workaround software per evitarlo. Successivamente hanno revisionato (sul silicio) quella parte del disegno, con il nuovo stepping.

A livello progettuale mi pare ovvio che AMD non abbia volutamente provocato quel bug, ma ha sbagliato il disegno dell'architettura stampato sul silicio. L'ha risolto successivamente revisionando il suo design (nuovo stepping) e migliorando la qualità dei materiali utilizzati...

Spero di essere stato chiaro...

Ma scusa... con quella frase stai dicendo appunto che hanno migliorato il silicio, non riprogettato l'architettura... e perché? Io cosa dico? Allora non è la progettazione ad capocchiam come hai scritto prima, ma al limite il silicio ad capocchiam, ma su questo mi sembra che siamo d'accordo... tutt'altro se affermi che l'architettura del Phenom è ad capocchiam.... mi sembrano cose piuttosto diverse... Come hai scritto prima, i bug li imputi alla progettazione ad capocchiam di AMD e "non cambierà nulla anche se vende le fabbriche....", su questo credo che non trovi d'accordo nessuno (a parte i fun avversi )

[Scrambler77]

Originariamente inviato da paolo.oliva2

Ma scusa... con quella frase stai dicendo appunto che hanno migliorato il silicio, non riprogettato l'architettura... e perché? Io cosa dico? Allora non è la progettazione ad capocchiam come hai scritto prima, ma al limite il silicio ad capocchiam, ma su questo mi sembra che siamo d'accordo... tutt'altro se affermi che l'architettura del Phenom è ad capocchiam.... mi sembrano cose piuttosto diverse...

E' diverso. Io non sto dicendo che hanno migliorato "solo" il silicio. Sicuramente (mi auguro) hanno migliorato i materiali, anche per dare a Phenom qualche mhz in più, ma i bugs funzionali non si risolvono SOLO migliorando i materiali utilizzati.

Nel mio post originale, col termine "progettazione ad capocchiam" intendevo proprio la "traduzione" dell'architettura K10 in un disegno geometrico da portare sul silicio, evidentemente sbagliata (ad capocchiam).

Infatti ho aggiunto che, (seppur non sia convinto in quale fase della realizzazione si collochi la progettazione del layout della cpu), se i disegni della cpu li fornisce AMD, la vendita delle fabs non serve a nulla se poi fornisce disegni "bacati" al produttore... anzi...

Non ho mai detto che, seppur deludente, l'archiettura K10 sia a "ad capocchiam".

Ps: @Mercurio o Ratatosk - che voi sappiate, il disegno (destinato alla litografia) della cpu (o delle gpu, non penso cambi granchè) viene fornito dalle aziende fabless o se ne occupa l'azienda che possiede la fab (TSMC ad esempio)?

[Mercuri0]

Originariamente inviato da paolo.oliva2

? Allora non è la progettazione ad capocchiam come hai scritto prima, ma al limite il silicio ad capocchiam

Penso che il termine "ad capocchiam" sia il problema della discussione.

Bug ce ne sono e ce ne saranno sempre in ogni processore, ad capocchiam o non ad capochiam che sia la progettazione.

[capitan_crasy]

Originariamente inviato da Scrambler77

1) io non faccio il polemico con nessuno
2) stai ancora una volta confondendo l'architettura di una cpu con il suo design sul silicio. Sono 2 cose molto diverse, seppur collegate. Lo stepping di una architettura è una miglioria a livello di design, non una modifica dell'architettura.

Il bug si è verificato durante lo speeding della cpu, e lì si sono accorti che era necessario un workaround software per evitarlo. Successivamente hanno revisionato (sul silicio) quella parte del disegno, con il nuovo stepping.

A livello progettuale mi pare ovvio che AMD non abbia volutamente provocato quel bug, ma ha sbagliato il disegno dell'architettura stampato sul silicio. L'ha risolto successivamente revisionando il suo design (nuovo stepping) e migliorando la qualità dei materiali utilizzati...

Spero di essere stato chiaro...

Chiariamo con un esempio:
AMD introdurrà il core Istanbul con 6 core a metà 2009.
L'architettura K10 verrà "modificata" per accogliere due core in più!
Per "modificata" intendo rivista e corretta prima sulla carta poi sul silicio.
AMD con il BUG 298 ha corretto la CPU sul silicio non "modificando" l'architettura K10!
Per modifica del silicio intendo che AMD individuato il BUG, ha modificato e migliorato il silicio ( di conseguenza anche lo "stampo"), ma non ha corretto l'architettura K10 in quando il BUG non era un errore di progettazione.
Ci sono alcuni BUG quali 254,264 e 309 la quale la patch FIX l'hanno "integrata" nella CPU, cioè i BUG non è stato risolti.
In questo caso però è probabile che il problema non sia risolvibile con il processo produttivo a 65nm.

[Mercuri0]

Originariamente inviato da Scrambler77

Ps: @Mercurio o Ratatosk - che voi sappiate, il disegno (destinato alla litografia) della cpu (o delle gpu, non penso cambi granchè) viene fornito dalle aziende fabless o se ne occupa l'azienda che possiede la fab (TSMC ad esempio)?

Ci sono varie modalità, ma nel caso full-custom (che è il nostro) il disegno deve farlo chi progetta i chip. La fonderia fornisce delle "regole di layout" che devono essere rispettate, e che vengono passate al CAD che si usa per il disegno.

Ci sta che si possano pure fare accordi con la fonderia per usare strutture "non ortodosse" per fare qualcosa di particolare. In quel caso la fonderia non ti assicura che quel che venga fuori funzioni.

Quindi per design "extremi" è comunque richiesta una collaborazione tra fonderia e progettisti fuori dalla portata dei comuni mortali.

[Scrambler77]

Originariamente inviato da Mercuri0

Ci sono varie modalità, ma nel caso full-custom (che è il nostro) il disegno deve farlo chi progetta i chip. La fonderia fornisce delle "regole di layout" che devono essere rispettate, e che vengono passate al CAD che si usa per il disegno.

Ci sta che si possano pure fare accordi con la fonderia per usare strutture "non ortodosse" per fare qualcosa di particolare. In quel caso la fonderia non ti assicura che quel che venga fuori funzioni.

Quindi mi pare di capire (come pensavo) che generalmente è l'azienda fabless che fornisce il disegno, altrimenti non c'è alcuna garanzia che il progetto finito funzioni come previsto, con conseguenti problemi di natura economica.

Quindi AMD che vende le fab, dovrà occuparsi di fornire alla fab un disegno conforme alle regole di layout ed il più esente possibile da errori di design. Ora capisco la vera utilità dei simulatori di nvidia.

Pertanto, nel caso del TLB, AMD non avrebbe mai potuto rivalersi sull'azienda "FAB" in quanto si tratta di un errore progettuale e non di realizzazione... o sbaglio?

[Mercuri0]

Originariamente inviato da capitan_crasy

Ci sono alcuni BUG quali 254,264 e 309 la quale la patch FIX l'hanno "integrata" nella CPU, cioè i BUG non è stato risolti.

Questo mi sfugge: se metti un fix correggi il bug, a prescindere da dove ce lo metti.

Al massimo si può dire che il fix riduce le prestazioni rispetto alle attese.

[viscm]

Originariamente inviato da capitan_crasy

Chiariamo con un esempio:
AMD introdurrà il core Istanbul con 6 core a metà 2009.
L'architettura K10 verrà "modificata" per accogliere due core in più!
Per "modificata" intendo rivista e corretta prima sulla carta poi sul silicio.
AMD con il BUG 298 ha corretto la CPU sul silicio non "modificando" l'architettura K10!
Per modifica del silicio intendo che AMD individuato il BUG, ha modificato e migliorato il silicio ( di conseguenza anche lo "stampo"), ma non ha corretto l'architettura K10 in quando il BUG non era un errore di progettazione.
Ci sono alcuni BUG quali 254,264 e 309 la quale la patch FIX l'hanno "integrata" nella CPU, cioè i BUG non è stato risolti.
In questo caso però è probabile che il problema non sia risolvibile con il processo produttivo a 65nm.

Esempio idiota Capitan , quindi perdonatemi la serie di strafalcioni che scriverò):
Amd capisce che l'errore 298 è dato dal fatto che il transistor X è troppo vicino a quello Y e a causa delle correnti residue ecc ecc , quindi decide di ''spostarlo" leggermente nello stampo.

Tu come definiresti questa soluzione, una modifica di progettazione o di silicio?

[viscm]

Originariamente inviato da Spitfire84

Interessante recensione (a parte l'ultima pagina dove non si capisce na cippa ) sul multitasking:

http://en.hardspell.com/doc/showcont...42&pageid=3301

Veramente interessante.

Praticamente negli ambiti testati l'x3 con 400 mhz in meno batte sempre il 7200

e costa pure 27 $ in meno.

Ma non dovevano essere delle sole questi x3???

Tutto ciò a default naturalmente.

[Scrambler77]

Originariamente inviato da viscm

Veramente interessante.

Praticamente negli ambiti testati l'x3 con 400 mhz in meno batte sempre il 7200

e costa pure 27 $ in meno.

Ma non dovevano essere delle sole questi x3???

Tutto ciò a default naturalmente.

Io ho sempre sostenuto che la moltiplicazione dei cores è la strada (giusta) intrapresa. C'è solo da attendere la graduale (ma secondo me inevitabile) parallelizzazione del software.

[maporca]

Originariamente inviato da maporca

Mi e' venuto un dubbio nel guardare le performance fatte con il phenom e le MB con il sb600 vs. quelle con il sb750.

con l'sb750 si sale in frequenza RS. molto meglio che con il sb600.
anzi sembra che con Sb600 si possa arrivare SOLO fino ad un certo punto.

Eh.. ma .. allora come siamo messi coi deneb futuri ad elevata frequenza ?
A patto che l'alimentazione sia corretta, ad esempio io ho una asus M3A32-MVP Deluxe/WiFi-AP che supporta anche i 140W, se poi l'sb600 limitasse la possibilita' di deneb a frequenza alta , ecco che la compatibilita' sarebbe solo virtuale.
Leggo di phenom FX a 4GHz. ma l'sb600 permette si arrivare a 4ghz ?
in realta' la M3A32-MVP Deluxe/WiFi-AP e' phenomFX ready ma se da molte parti con Sb600 non si riesce ad andare sopra i 3.2 e con problemi, come si potra' montare ,nonostante i 140W possibili, un phenom FX ? e magari anche i deneb 45nm non FX ma sopra i 3ghz.

l'offerta sarebbe limitata ai deneb 2.8 - 3 Ghz ?

Ecco .. ho sto dubbio.
non parlo di OC !! eh. parlo di stock. ma se sb600 on oc non tiene sopra i 3.2 come potra' farlo a stock a 3.5 - 4 ?

up

[Mercuri0]

Originariamente inviato da Scrambler77

Quindi mi pare di capire (come pensavo) che generalmente è l'azienda fabless che fornisce il disegno, altrimenti non c'è alcuna garanzia che il progetto finito funzioni come previsto, con conseguenti problemi di natura economica.

Quindi AMD che vende le fab, dovrà occuparsi di fornire alla fab un disegno conforme alle regole di layout ed il più esente possibile da errori di design. Ora capisco la vera utilità dei simulatori di nvidia.

I "simulatori di nvidia" ce l'hanno anche AMD e lntel, eh, e chiunque altro si metta a progettare chip . Coi costi e i tempi che ci sono per la prototipazione, progettare senza simulare è da folli.

Faccio presente che anche per le aziende con fab non funziona in maniera tanto diversa: ci sono ingegneri che fanno l'architettura, simulazione, altri che fanno i disegni, simulazione, e poi si passa alla fonderia. Mica uno solo fa tutto

L'organizzazione fab/fabless è una questione principalmente economica: va da sé che le aziende con fab hanno un miglior canale di comunicazione tra gli i progettisti e i "processisti" (ma non è detto che questo canale non lo si possa creare tra due aziende differenti), e che un'azienda con fab può spingere l'evoluzione dei processi in una direzione "comoda" ai progettisti.

Ma anche qui, può essere fatto anche da un'azienda fabless che ha un grosso potere contrattuale nei confronti della fonderia.

Pertanto, nel caso del TLB, AMD non avrebbe mai potuto rivalersi sull'azienda "FAB" in quanto si tratta di un errore progettuale e non di realizzazione... o sbaglio?

Mah, i casi in cui ci si possa rivalere sulla fonderia sono veramente pochi. Anche perché se un processo di produzione fa schifo, te lo dicono prima.

Le fonderie sono in competizione tra loro per chi fornisce il miglior processo: una azienda fabless può scegliere la fonderia "migliore".

A me comunque il bug TLB sembra un problema di logica, non di "silicio". (e anche i limiti "del silicio" si considerano nell'architettura, eh)

[Scrambler77]

Originariamente inviato da Mercuri0

I "simulatori di nvidia" c'è l'hanno anche AMD e lntel, eh, e chiunque altro si metta a progettare chip . Coi costi che ci sono per la prototipazione, progettare senza simulare è da folli.

Ovvio... ma leggevo tempo addietro che il software di simulazione utilizzato da nvidia è particolarmente potente rispetto ai classici ADS...

P.S: mi correggo... sarà utilizzato nel 2009.

Originariamente inviato da Mercuri0

A me comunque il bug TLB sembra un problema di logica, non di "silicio". (e anche i limiti "del silicio" si considerano nell'architettura, eh)