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

[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)

[paolo.oliva2]

Originariamente inviato da Scrambler77

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

Premetto che non voglio fare polemica.
Vedi... io faccio delle distinzioni ben precise.
L'architettura P4 di per sé non era sbagliata, se Intel fosse arrivata ai 5GHz sul silicio come prevedeva, ma un procio con IPC inferiore (che non necessariamente si traduce in architettura sbagliata) se non lo aiuti con un clock maggiore, è chiaro che può solo perdere. Il P4 ha perso con il K8 non per un'architettura sbagliata da sola, ma nell'integrazione del silicio, che non è riuscito a dare quel clock sufficente a sopperire il minor IPC.
Chiaramente la differenza di IPC era di gran lunga superiore a quella degli A64... perché neanche ad arrivare a 4GHz è servito.
Però anche se fosse arrivata a 5GHz con il P4, di fondo comunque l'architettura aveva dei limiti propri.
Il Phenom è da considerare in modo molto diverso, perché si il clock basso non ha certo contribuito, ma il silicio di sé per sé non ha permesso di sfruttare il procio come l'architettura poteva... ma non stiamo parlando di frequenze da capogiro, ma di frequenze in linea con il silicio.
L'IPC che si incrementa nel 45nm non è solo per la L3 (e lo vedremo con il Deneb a 45nm senza L3), ma per tutta una serie di mancanze di silicio che hanno introdotto un vallo di bug e sicuramente latenze molto alte. Ma è sbagliato attribuire l'IPC basso del Phenom 65nm con la progettazione.
Io per architettura considero le potenzialità di elaborazione del procio date dai registri, la cache, e tutto l'interfacciamento verso l'esterno.
Da questo punto di vista, tutta l'architettura del K10 è uguale al Deneb, ma il 45nm permette TDP inferiori, L3 più grande e un'insieme di latenze inferiori che nel complesso aumentano l'IPC. E qui riscopriamo le potenzialità del Phenom, appunto nato in cattiva luce per problemi del 65nm di AMD.
Le potenzialità dell'architettura del Phenom le vediamo in tutto e per tutto in ambito server, e che il progetto Phenom è stato premiato come progetto dell'anno, è già una riprova a ciò che dico.
Poi se consideri il Nehalem, ha molte più cose in comune con il Phenom che con il Core2... e specialmente tutta la parte I/O del procio non ha nulla a che vedere con il Core2 e invece molto con il Phenom.
Infatti io reputo il Nehalem la risposta Intel nel mercato server, in quanto, e qui è proprio problema di limiti di progettazione, con il Core2 anche a 3,2GHz con sistemi a 4 proci non c'era possibilità di contrastare AMD appunto per i limiti di I/O, di un progetto che è per desktop ma per la sua natura non si accosta facilmente all'ambiente server.
Da questa ottica, se il Deneb arrivasse ad un IPC uguale al Penryn e con un clock almeno in linea, l'architettura del Deneb verrebbe fuori, perché già che il progetto si dimostri polivalente, cioé ottimi risultati in ambito server e almeno uguali in ambito desktop, è senz'altro meglio di un Penryn ottimo in desktop e deludente in ambito server.
Qui non sto parlando di chi è primo, secondo, terzo... si sta parlando solo di architettura. Per questo architettura "ad capocchiam" non la digerisco.... . Ed anche "deludente", come hai riscritto, ti torno a ripetere che non è l'architettura, quanto il silicio... non confondiamo le pere con le mele. Se Io mettessi un Nehalem con silicio che mi dasse latenze superiori e clock massimo a 1,5GHz, sarebbe un procio deludente, si, ma per architettura o per silicio?

[Mercuri0]

Originariamente inviato da Scrambler77

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

Nah, stupidaggini. E se ne sono sentite tante stupidaggini su questa storia (toms lasciava intendere che ATI non l'avesse e usasse dei laboratori di prototipazione )

I simulatori sono tanti comunque: cad e simulatori di sistema, cad e simulatori di architettura, cad e simulatori di logica, cad e simulatori di circuito, cad e simulatori di layout (disegno).

Dal layout poi viene generato un circuito che considera e schematizza i componenti parassiti (per esempio la lunghezza di un collegamento), e si verifica e si risimula a ciclo modificando dove serve al livello che serve.
Oggi questi parametri possono essere infilati anche nel simulatore di logica, una volta estratti dal simulatore di layout.

Va da sé che il simulatore di layout ha bisogno di dati dalla fonderia: non è che nVidia può fare un simulatore da sola.

[Mercuri0]

Originariamente inviato da paolo.oliva2

Ma è sbagliato attribuire l'IPC basso del Phenom 65nm con la progettazione.

Nella progettazione entrano anche i limiti del silicio. Il Pentium4 è fallito sostanzialmente perché lntel ha sbagliato la previsione sui suoi futuri processi tecnologici.

Anche l'architettura è subordinata ai limiti della costruzione.
Altrimenti si progetterebbero processori senza cache

Nel Phenom AMD ha privilegiato i server nell'architettura. Ad esempio il TLB, che non è un bug ma una funzione, serve per la virtualizzazione, dove gli Opteron eccellono.. Di sicuro se avessero pensato ai desktop avrebbero tirato fuori qualcosa di diverso.

[Scrambler77]

Originariamente inviato da Mercuri0

Nah, stupidaggini. E se ne sono sentite tante stupidaggini su questa storia (toms lasciava intendere che ATI non l'avesse e usasse dei laboratori di prototipazione )

I simulatori sono tanti comunque: cad e simulatori di sistema, cad e simulatori di architettura, cad e simulatori di logica, cad e simulatori di circuito, cad e simulatori di layout (disegno).

Dal layout poi viene generato un circuito che considera e schematizza i componenti parassiti (per esempio la lunghezza di un collegamento), e si verifica e si risimula a ciclo modificando dove serve al livello che serve.
Oggi questi parametri possono essere infilati anche nel simulatore di logica.

Va da sé che il simulatore di layout ha bisogno di dati dalla fonderia: non è che nVidia può fare un simulatore da sola.

Infatti, il simulatore di cui si sta dotando è di terzi, un software capace di calcolare...:

"...impedance mismatch, reflections, electromagnetic coupling, crosstalk, and microwave frequency attenuation due to the skin effect and dielectric loss tangent ecc..."

per ottenere...:

"fast "what-if" design-space exploration using circuit-level models that can be verified against measured data and EM simulation of the artwork"

Tutto ciò si dice consumare parecchie risorse computazionali, al punto di necessitare di interi sistemi Tesla impegnati full-time per giorni...

In ogni caso, una simulazione del genere dovrebbe dare l'opportunità ai progettisti di scovare e risolvere in fase progettuale bugs come il TLB e gli altri emersi in questi giorni...

Per chi fosse interessato: http://www.electronicsweekly.com/Art...-simulator.htm