Process de fabrication

[Yasko]

On réclamait le topic, le voici créé à l'occasion de la publication (/leak ? /fake ?) de cette hypothétique roadmap du process Intel jusqu'à 2022 :




Quelqu'un pour commenter les différentes lignes et valeurs ?

4 nm... Je crois me rappeler qu'en dessous de 10-20 nm, ce serait difficile du fait des courants de fuite / épaisseur des gates...
C'est ce FinFET qui rend ça possible ?

Bon, pour ne pas pinner un 1er post de noob, j'ai tout de même fait mes devoirs :
http://en.wikipedia.org/wiki/Multigate_device
FinFET y est expliqué, et effectivement le but est de mettre plusieurs gates.
Ce qui est étrange est qu'il est indiqué qu'Intel a justement choisi de ne pas parler de FinFET pour leur techno tri-gate.
Ils ont changé ? La roadmap est un fake ?

Il y a quelques docs sur le site d'Intel :
http://www.intel.com/technology/sili...rated_cmos.htm
http://download.intel.com/technology...efing_0606.pdf
http://download.intel.com/technology..._VLSI_0606.pdf

Et ça, qui link également les pages sur InSb :
http://www.intel.com/technology/sili...htm?iid=SEARCH

[fefe]

Les gates font deja 5 atomes d'epaisseur depuis 2 generations et ne changeront probablement plus de beaucoup, c'est pas comme si il y avait de la marge .

Ca ressemble a un slide de quelqu'un de marketing qui a decide que Intel continuerait le regime du Tick-Tock jusqu'en 2022.

Il n'y a absolument aucune info sur ce slide, les technos de 2014 et 2016 sont certainement prevues (bien force avec des cycles de dev de 5 a 8 ans) et le reste ressemble a du copier coller.

[Alexko]

La source d'origine (a priori) : http://www.hardware.info/en-US/news/...o_4nm_in_2022/

The roadmap features a light-blue seperation, to which Intel responded that the tick-tock strategy will be under fire after 2012. Though transistors of 16 and even 11 nm are theoretically possible at this point, the 8 nm process will require another technological breakthrough. It's still unclear how transistors at this size are to be realised. The blue part of the roadmap is to be perceived as an extrapolation of the results of past years.

Pendant qu'on y est, TSMC promet de commencer la production en 28 nm dès la fin de Q1'10 : http://www.tgdaily.com/content/view/43732/135/

Vu que les produits 40 nm n'apparaîtront en volume sur le marché qu'en octobre, j'ai des doutes...

[Neo_13]

Le triple gate, ça envoie du bois, mais c'est la misère en prod...

Pour InSb, J'y crois pas une seconde dans les CPU à milliards de transistors avant 2016, 2014 si on compte l'avance d'intel sur les labos de n'importe où ailleurs.

[hellsing]

Les gates font deja 5 atomes d'epaisseur depuis 2 generations et ne changeront probablement plus de beaucoup, c'est pas comme si il y avait de la marge .

Tu es sur de ça?
Pour moi 4nm=40A(angstrom) donc 40 atomes.

Concernant tout ces niveaux de métaux je commence à me demander si c'est réellement utile, mis à part rajouter des masques.

[fefe]

Je parlais de l'epaisseur d'isolant entre la source et le drain. Pour ton calcul, l'espacement entre 2 atomes de polysilicium crystallin classique est >0.5nm (cf wikipedia silicon - lattice spacing) donc 4nm dans ce cas fait ~7 atomes et 3nm pour 5 atomes.

Les nouveau niveaux de metaux sont indispensables pour etre capable d'utiliser tous ces transistors dans un design realiste. Le dernier niveau de metal reste a peu pres constant d'un process a l'autre, sinon les interconnexions a longue distance dans le die seraient beaucoup trop lentes. Conclusion a chaque fois que tu shrink tes transistors, si tu shrink tous tes niveaux de metal, ton delai augmente (pas le delai de commutation d'un transistor, juste le delai de propagation du signal sur une piste de metal du a l'augmentation de R vu que RC est constant et C diminue avec la taille de la piste). Donc tu shrink ton metal aussi et rajoute un niveau qui fait la meme taille que dans le process precedent. Vu qu'ajouter un metal coute tres cher, ils ne le font pas systematiquement...


Photo d'une section de die ou on voit de maniere assez evidente que les metaux superieurs sont vraiment gros. Je n'ai pas pu retrouver de photos a la meme echelle comparant 2 generations du process d'un constructeur, mais c'est souvent assez explicite (d'ailleurs sur cette photo c'est assez etonnant les basses couches de metal font toutes la meme taille alors que sur des process comme TSMC ca decroit progressivement).

Edit: il devait etre tard quand j'ai ecrit ca, javais du mal a me comprendre.

[hellsing]

Ok, j'avais confondu la taille du noyau (110pm) et le lattice spacing (500pm), de plus étant sur une techno vieille, j'avais zappé qu'on était passé à l'hafnium et tout ça.

Pour les niveaux de métaux je te fais confiance, ne bossant pas dans le numérique, on n'a pas de problème de réduction de taille de pistes (plus elles sont grosses plus on passe une patate en courant)

[Alexko]

Petite question : je sais que les I/O et compagnie scalent très mal quand on passe d'un process à l'autre, mais à quel point au juste ? Par exemple un bus mémoire de 128 bits prendra exactement la même place en 65 et 45 nm ? Ou on gagne quand même un peu, genre 10 % ?

Je me pose cette question un peu par curiosité pure, et un peu parce que j'ai l'impression qu'on va dans le mur sur les GPU : le GT200b par exemple a un bus de 512 bits et fait 460 mm² (de mémoire). Bon, le GT300 passe à la GDDR5 pour accomoder ses plus gros besoins en BP, mais après on fait comment ? La puissance brute croît plus vite que la vitesse de la RAM, d'où le passage en quelques années de bus 64 bits à 512 bits sur les GPU.

[Yasko]

Tu parles du bus en lui-même, des pistes ? (vu qu'il n'y a pas de transistor sur un bus)
J'aurais tendance à dire que la taille du bus (largeur/ épaisseur des pistes, espacement entre pistes) dépend des besoins du protocole de transport de ce bus (tension, fréquence, modulation, etc.) et est indépendant de la taille des transistors / finesse de gravure du process (pour un bus de données du moins, pour les pistes Vcc, vu que les transistors fonctionnent à une tension plus basse, on doit pouvoir augmenter un peu la résistance des pistes en diminuant leur "section").

Le meilleur moyen de réduire la taille d'un bus doit être d'augmenter la bande passante par piste (en modifiant le protocole de transport donc et/ou ses caractéristiques électriques, voire même sa nature, cf optronique). Par exemple, passage d'un bus parallèle vers série.
Enfin bon, je dis ça mais j'en sais rien.

[fefe]

La vitesse de la DDR augmente de ~15%/an, la surface consommee reduit de 25%/an sauf les I/O ou c'est plutot 5% (une fois de temps en temps c'est mieux car tu emploies une nouvelle techno plus couteuse). Donc oui si tu traces ces 3 courbes, tu vois qu'a terme il y a un probleme pour les GPUs.

Ce probleme existe depuis tres longtemps, c'est pour ca que les CPUs ont des caches (ajoute au fait que la latence de la DRAM ne change pas, juste sa capacite et sa bande passante, mais ca les GPUs s'en foutent)...

[Alexko]

Tu parles du bus en lui-même, des pistes ? (vu qu'il n'y a pas de transistor sur un bus)
J'aurais tendance à dire que la taille du bus (largeur/ épaisseur des pistes, espacement entre pistes) dépend des besoins du protocole de transport de ce bus (tension, fréquence, modulation, etc.) et est indépendant de la taille des transistors / finesse de gravure du process (pour un bus de données du moins, pour les pistes Vcc, vu que les transistors fonctionnent à une tension plus basse, on doit pouvoir augmenter un peu la résistance des pistes en diminuant leur "section").

Le meilleur moyen de réduire la taille d'un bus doit être d'augmenter la bande passante par piste (en modifiant le protocole de transport donc et/ou ses caractéristiques électriques, voire même sa nature, cf optronique). Par exemple, passage d'un bus parallèle vers série.
Enfin bon, je dis ça mais j'en sais rien.

Je parle du contrôleur mémoire et surtout de l'interface qui va avec, pardon pour l'abus de langage.
Par contre, un bus série pour la RAM, ça ne risque pas de massacrer les latences ?

La vitesse de la DDR augmente de ~15%/an, la surface consommee reduit de 25%/an sauf les I/O ou c'est plutot 5% (une fois de temps en temps c'est mieux car tu emploies une nouvelle techno plus couteuse). Donc oui si tu traces ces 3 courbes, tu vois qu'a terme il y a un probleme pour les GPUs.

Ce probleme existe depuis tres longtemps, c'est pour ca que les CPUs ont des caches (ajoute au fait que la latence de la DRAM ne change pas, juste sa capacite et sa bande passante, mais ca les GPUs s'en foutent)...

C'est bien ce que je me disais. Du coup qu'est-ce que ça veut dire pour l'avenir, qu'on va devoir mettre de gros caches sur les GPU ? Sur les CPU on a encore la place de rajouter des canaux si nécessaire, même sur Bloomfield avec ses trois canaux DDR3, et de toute façon les besoins en BP n'augmentent pas très vite (à part sur les applis qui scalent très bien avec le nombre de cores). Mais sur les GPU, on a bien + 50 % de performances par an avec ce que ça implique niveau BP, et pratiquement plus de place pour mettre un bus plus gros. En même temps, est-ce que de gros caches aideraient vraiment ? Avec un bon prefetching ça permettrait peut-être de minimiser les pics de demande de BP, mais un GPU ça réutilise rarement les mêmes données, non ?

Désolé, ça part un peu en HS, là.

[Møgluglu]

C'est bien ce que je me disais. Du coup qu'est-ce que ça veut dire pour l'avenir, qu'on va devoir mettre de gros caches sur les GPU ? Sur les CPU on a encore la place de rajouter des canaux si nécessaire, même sur Bloomfield avec ses trois canaux DDR3, et de toute façon les besoins en BP n'augmentent pas très vite (à part sur les applis qui scalent très bien avec le nombre de cores).

La grosse différence, c'est que pour le CPU, la latence est au moins aussi importante que la bande passante, alors que comme dit fefe le GPU s'en fout.
Du coup les GPU ont ~10 fois plus de bande passante que les CPU de génération/gamme équivalente. Mais aussi ~10 fois plus de latence, ce qui fait que les recettes utilisées peuvent difficilement être réutilisées sur CPU.

En passant, sur Bloomfield, quelle est la bande passante maxi exploitable?
Doc a mesuré 16 Go/s en lecture :
http://canardpc.com/dossier-58-400-N...s_memoire.html
On doit pouvoir faire mieux avec des instructions de prefetch sur les 4 cores, mais combien?
Quand on compare les bandes passantes il faut prendre en compte le fait qu'un GPU arrivera facilement à en exploiter 90%, le CPU beaucoup plus difficilement...

Hiroshige Goto qui parle de mémoire générique vs exotique, de DRAM on-package/on-die... :
http://pc.watch.impress.co.jp/docs/2.../kaigai483.htm
http://pc.watch.impress.co.jp/docs/c...24_153641.html

Aussi, comme la latence est due principalement à la longueur des fils, on arrive à un point où la DRAM devient plus rapide que la SRAM car plus dense. Donc on devrait commencer à voir arriver de la DRAM en cache de dernier niveau?

[Neo_13]

Aussi, comme la latence est due principalement à la longueur des fils, on arrive à un point où la DRAM devient plus rapide que la SRAM car plus dense. Donc on devrait commencer à voir arriver de la DRAM en cache de dernier niveau?

Ca m'étonnerait : le refresh bloque l'accès de façon franchement pénible.

[newbie06]

En passant, sur Bloomfield, quelle est la bande passante maxi exploitable?
Doc a mesuré 16 Go/s en lecture :
http://canardpc.com/dossier-58-400-N...s_memoire.html
On doit pouvoir faire mieux avec des instructions de prefetch sur les 4 cores, mais combien?

A priori le max théorique doit être 3 (channels) x 8 (64-bit) x 2 (double data) x 533 (fréqeunce) soit 25 Go/s ; mais le contrôleur mémoire ne limite-t-il pas ça par sa fréquence ?

Par ailleurs, je me demande s'il ne vaut pas mieux laisser faire le(s) prefetcher(s) HW pour atteindre la BP maximale...

[Møgluglu]

Ca m'étonnerait : le refresh bloque l'accès de façon franchement pénible.

Oui, mais ça ne ralentit que le pire cas, et c'est pas pire qu'un transfert séquentiel en tâche de fond. C'est pas comme si on avait l'habitude d'avoir des latences déterministes...

D'ailleurs, les PSRAM et autres 1T-SRAM arrivent bien à masquer complètement les refreshs?... (Évidemment ça a un coût....)

[Neo_13]

Moi ce que je constate, c'est qu'on passe de 6T vers du 8T et pas vers le 1T. Est ce que le 1T consomme autant que je sens ? (qui dit refresh dit conso, non ?)

[Møgluglu]

Par ailleurs, je me demande s'il ne vaut pas mieux laisser faire le(s) prefetcher(s) HW pour atteindre la BP maximale...

Il me semble bien que Sandra arrive à atteindre dans les 98%...
Au pif : http://www.madshrimps.be/?action=get...07&articID=928

Je suppose qu'ils utilisent du prefetching software réglé à la main, alors que Everest et le Doc utilisent le prefetcher hardware uniquement? Peut-être aussi que le nombre de cores utilisés est différent.
(c'est qui qui a un i7 et qui fait du multithreading ici? )

[newbie06]

J'y bosse Mais pour l'instant en single CPU, je suis à 10 Go/s en lecture sans preload...

[Møgluglu]

En transférant des mots de 32-bit?

Tu peux aussi essayer :
- En C, avec des mots de 32, 64-bit.
- Avec des intrinsics SSE, aligné ou pas (_mm_load_ps et _mm_loadu_ps).
- Avec des loads non temporels.
- Avec du prefetch, pour différentes distances de prefetch.
- Avec plusieurs threads, pour différentes tailles de blocs pour l'entrelacement...

Bon dimanche.

[newbie06]

Il me semble bien que Sandra arrive à atteindre dans les 98%...
Au pif : http://www.madshrimps.be/?action=get...07&articID=928

Là tu montres des résultats sur de la mémoire @1333, je donnais la BP @1066.

---------- Post ajouté à 14h34 ----------

En transférant des mots de 32-bit?

Tu peux aussi essayer :
- En C, avec des mots de 32, 64-bit.
- Avec des intrinsics SSE, aligné ou pas (_mm_load_ps et _mm_loadu_ps).
- Avec des loads non temporels.
- Avec du prefetch, pour différentes distances de prefetch.
- Avec plusieurs threads, pour différentes tailles de blocs pour l'entrelacement...

Bon dimanche.

Ralala, non la routine que j'ai récupérée utilise movdqa. Je pense que je vais passer à la version nt pour voir. Mais ça veut aussi dire que je dois apprendred du x86, et ça me file comme une envie de vomir

Là j'en suis à peu près à 17 Go/s sur 4 threads.

EDIT : Bon je n'arrive pas à monter plus haut même avec du prefetch explicite. J'imagine qu'il faut utiliser prefetchnta, mais avec quel stride?

[fefe]

Prefetch explicite sur un x86 recent = ralentissement a moins d'avoir un pattern d'acces qui ressemble a du random complet et que tu le connais a l'avance. Il te faut generer du code SSE 128 bits si tu veux monter haut en bande passante, donc intrinsics ou asm...

Le changementnt des 6T->8T n'a rien a voir avec le debit ou la latence, mais la tolerance des cells 6T aux bas voltages qui est mauvaise. Le resultat est que si tu as trop de cells 6T ca force le Vmin assez haut a moins d'avoir des quantite d'ECC massives et donc detruit la conso idle. Au final tu mets des cells 8T avec de l'ECC et tu gagnes >100mV sur ton voltage minimum.

Pour les GPUs, ils doivent tout de meme employer la meme techniques pour les IO que les CPUs. La GDDR et la DDR sont quasiment la meme chose, a part le fait que la GDDR reduit toutes les marges (donc en fait c'est plus dur). Le resultat est que un GPU aujourd'hui a des pads d'IO sur 100% de sa peripherie (sur le haut de gamme) et que tu ne peux plus augmenter la bande passante sans faire de gros investissements: tu peux consommer plus de rangees de pads, mais ca coute tres cher, et il y a un moment ou ca ne devient plus possible. De plus ces dies sont deja a la taille du reticule donc tu ne peux pas gagner d'espace pour les IOs en faisant un plus gros die. Il te reste le die stacking, avec un die specialise dans les IOs et des vias verticales vers tes circuits digitaux, mais c'est hors de prix a ces dimensions.
Les CPUs serveurs sont assez similaires aux GPUs en terme de problemes de bande passante, tu as suffisament de threads pour que ta latence ne soit plus trop un probleme et tu deviens limite par ta bande passante. Prend un double ou quadruple socket avec 4 channels de DDR sur chaque, tu vas vite te retrouver dans le domaine des GPUs en terme de bande passante (pas du plus haut de gamme, mais si tu compares a iso surface de silicone tu verras vite que la difference n'est pas d'un ordre de grandeur du tout sur les IOs).

[fefe]

Beaucoup de monde parle d'integrer de la 1T dans le CPU, mais il y a beaucoup de problemes associes. La densite est bonne mais le ratio n'a rien a voir avec 6 ou 8 (plutot 3), a moins d'etre pret a lui donner de tres gros voltages en entree, ce qui est sans interet car tu te retrouves vite avec une source de consommation enorme. Et meme une fois tes cells modifiees pour les bas voltages ca ne descend pas aussi bas que de la 8T donc il faut blinder l'ECC. Ensuite il faut refresh, ce n'est pas un probleme tant que tu accedes a toutes tes donnees (donc le refresh n'a pas d'impact sur ta bande passante pic) ou si ton cache est read only, mais ca devient vite une difficulte si tu comptes remplacer un cache actuel.

Ensuite avoir un process qui supporte les cells 1T le rend plus couteux qu'un process qui ne le supporte pas, donc a cout egal le die devra etre plus petit ce qui reduit encore plus l'avantage de la 1T (et donc ca ne marche que sur un die qui a beaucoup de cells memoire dessus). Au final ton avantage se retrouve a etre aux alentours de 2x, avec encore beaucoup de problemes associes. La bande passante que tu pourrais gagner du fait de cette densite accrue est perdue dans le controleur qu'il te faut implementer pour gerer refresh et compagnie, le power management... Ceci peut etre evite avec du die stacking (un die de DRAM un die avec les CPUs/PEs...) mais encore une fois ca coute tres cher aujourd'hui. Un jour ca deviendra plus avantageux que de la SRAM, mais ce n'est pas encore tout de suite.

[Neo_13]

Ma comparaison entre 6T, 8T et 1T était là pour souligner que le problème de densité parait secondaire par rapport à la baisse de conso pour les fondeurs, en ce moment...

Par contre je pensais pas que le ratio prenait en pratique une telle claque. (Et effectivement 1T = SOI, vu l'attrait d'intel pour la techno ...)

[Alexko]

Il me semble qu'IBM a mis de l'EDRAM sur son Power7. On verra ce que ça donne... Je me demande si AMD fera de même sur Bulldozer, puisqu'ils en sont probablement tout aussi capables qu'IBM.

[Neo_13]

Apparemment, oui... 32Mo.

Enfin, j'ai pas le culte d'IBM, même si je respecte (je sais que peu ici l'ont, voir aucun), mais juste pour le plaisir du troll gratuit : quand on voit le succès commercial du POWER qui devait tout nickay, et en particulier le x86, on peut s'interroger sur la perspicacité d'IBM dans les choix techniques et commerciaux. Et a priori power7 et opteron partageront le même socket, démontrant encore plus plus plus la confiance d'IBM (alors que c'est un contrat DARPA apparemment)

[DJ_DaMS]

On sort un peu du sujet ici, mais lors du dernier passage des gens d'IBM chez nous (on utilise des serveurs IBM-AMD Opteron), ils nous ont dit qu'il y a un froid entre IBM et AMD... (je n'en sais pas plus)

[Alexko]

http://www.realworldtech.com/page.cf...WT072109003617

Compte-rendu de l'IEDM par David Kanter.

[Eld]

quand on voit le succès commercial du POWER qui devait tout nickay, et en particulier le x86, on peut s'interroger sur la perspicacité d'IBM dans les choix techniques et commerciaux.

En même temps on sait bien que c'est pas en faisant un bon processeur qu'on va nickay le x86, même intel s'y est cassé les dents...

[newbie06]

En même temps on sait bien que c'est pas en faisant un bon processeur qu'on va nickay le x86, même intel s'y est cassé les dents...

Oh, je l'adore celle-là ! Je la note dans mes quotes, vraiment super

[Neo_13]

En même temps on sait bien que c'est pas en faisant un bon processeur qu'on va nickay le x86, même intel s'y est cassé les dents...

J'en suis bien conscient, mais ne crois pas que ça me fasse plaisir...

Il ne peut en rester qu'un (pour les "ordinateur") Ben je crois qu'avec le fail d'Alpha et l'EPIC FAIL d'EPIC...

Restera Mips en réseau et arm en embarqué.