Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 11 reacties

Tijdens het VLSI-symposium dat dinsdag op Hawaii van start gaat, presenteert Intel verschillende papers over nieuwe technieken op het gebied van chipdesign en procestechnologie.

Op het symposium zal Intel onder meer een nieuw type 'floating body cell'-geheugen uit de doeken doen. Fbc-geheugen wordt gezien als een potentiële kandidaat om embedded dram of cachegeheugen te vervangen omdat voor een enkele geheugencel slechts één transistor nodig is. Ter vergelijking: voor sram zijn zes transistors nodig per geheugencel terwijl dram-geheugen één transistor en één condensator nodig heeft. Het weglaten van de condensator is mogelijk doordat transistors die middels een soi-procedé gebakken zijn, ook lading kunnen opslaan.

Intels nieuwe type fbc-geheugen (schematisch)In 2006 presenteerde Intel het eerste fbc-geheugen, dat gebruikmaakt van twee gates. De nieuwe geheugencel gebruikt slechts één gate en is volgens Intel aanzienlijk kleiner dan de tot nu toe gepubliceerde fbc-geheugens. Het geheugen is geschikt voor chips die gebakken worden met een 15nm-procedé en een enkele geheugencel is kleiner dan een honderdste vierkante micrometer.

Naast het fbc-geheugen zal Intel ook verschillende technieken uit de doeken doen die het energieverbruik moeten verminderen en de prestaties moeten maximaliseren. Door variaties in het productieprocedé, het voltage of de temperatuur is er een zekere marge tussen het minimale voltage dat een chip nodig heeft om correct te functioneren en het daadwerkelijke voltage dat gebruikt wordt. Een stap om het gat tussen deze twee waardes te dichten is de ontwikkeling van een robuust type sram-geheugen dat overweg kan met deze variaties. Het nieuwe type geheugen zou zesentwintig keer betere foutkarakteristieken hebben waardoor een lager voltage gebruikt kan worden.

Ook bij de bepaling van de maximale snelheid van de communicatie tussen verschillende chips wordt uitgegaan van een zekere veiligheidsmarge. Om dichter bij de maximaal haalbare snelheid te komen wil Intel de chips uitrusten met logica die onder andere de jitter op het communicatiesignaal meet zodat de optimale timings en kloksnelheden kunnen worden gekozen. Verder zal Intel tijdens het symposium meer details vrijgeven over de microarchitectuur van de Nehalem en het 45nm high-k + metal gate productieprocedé dat gebruikt zal worden om deze processor te fabriceren.

Schematische voorstelling guardband bij communicatiekanaal
Moderatie-faq Wijzig weergave

Reacties (11)

Single gate cache, dat zal erg snel zijn minder onderdelen is altijd sneller, en geschikt voor 15nm, betekend dat dat Intel denkt vorbij de 22nm grens te kunnen schalen?

Het lijkt me geweldig om dit ook echt te zien maar zo als met de 45nm technologie zal het er niet snel aan zitten te komen het duurt zeker wel een jaar of 2-3 voor we dit ook in consumenten processors zullen zien. Dit natuurlijk omdat Intel dit pas sind kort van het lab naar de ontwerp tafel heeft kunnen verhuizen en dus pas voor een of zelfs twee generaties later een ontwerp zal hebben dat hier mee werkt.

De andere technologie klinkt een beetje als een open deur in trappen, natuurlijk kun je door jitter te meten de maximale snelheid verbeteren. Het nieuwe aan de techniek is dat Intel schijnbaar instaat is dit op een betrouwbare wijze te doen zonder de overdrachts snelheid of de verwerking van het signaal te beinvloeden en dat is toch wel een verbetering.

45nm, waarom zijn ze nog niet bezig met 32nm in deze presentaties... betekend dat een tegenslag of willen ze eerst nog wat meer 45nm verkopen voor ze veder schalen naar kleiner. Ik vind het raar dat ze al een jaar geleden ongeveer melden dat ze een 32nm doorbraak hadden en dat we snell 32nm zouden mogen verwelkomen maar dat ze nu toch nog steeds 45nm proberen te pushen.
dat gaat toch altijd zo je moet eerst het geld terug verdienen uit je oudere onderzoek dus zullen ze eerst heel wat geld willen verdienen aan de 45nm voor ze de volgende techniek gaan uit brengen of de concurent zet wat nieuws op de markt waardoor je eerder je iets minder oude onderzoek moet uitbrengen.

daarnaast wat hun natuurlijk laten zien is nog lang niet wat ze al kunnen het is gewoon een lekker makertje van dit gaat er aan komen over 2 a 3 jaar maar denk dat de ontwerpen die in de labs liggen waarschijnlijk al veel verder zijn maar dat moet je de consument natuurlijk niet vertellen want die voelen zich dan belazert dat ze nog van deze oude ontwikkeling gebruik moeten maken.

Moet zeggen als amd fan vindt ik dat intel de laaste tijd wel goed bezich is met nice ontwikkelingen zoals deze ik hoop dat deze twee bedrijven elkaar beetje blijven irriteren zodat ze beide scherp blijven om de andere te overtroeven zolang ze maar de kwaliteit in ogen houden
is dit nou eigenlijk voor een SSD ala flash
of is het vooral voor ram geheugen.
er wordt gemeld dat het om embedded ram en cache gaat.
weet iemand ook wanneer het mogelijk uitkomt .
ik vind het een mooie techniek maar kan weinig vinden.
behalve vergelijkbare artikelen. ( en patents online)

[Reactie gewijzigd door freaq op 17 juni 2008 08:16]

Het wordt gebruikt als cache geheugen in de processor, in het cache geheugen worden gegevens tijdelijk bewaard voorlaeer ze verwerkt worden door de processor. Ik dacht dat vooral bij intensieve database verwerkingen dit van groot belang was. Het is dus niet zoals SSD geheugen. :)
Alle verwerkingen gaan door die cache, niet enkel die van de database.
Op x86 processoren kan je anders nog steeds dit doen: (commentaar overdreven, ik betwijfel of iemand die assembly leest/code veel heeft aan een comment bij "jmp ax"...)
mov ax, 1234h # move something into ax
jmp ax # point EIP to ax

Op x86_64 lukt hetzelfde, maar dan met eax ipv ax.

Tadaa, geen cache gebruikt (processor beslist ook zelf niet om dat te gaan cachen) :-) met lds/lea/les kan je ook uit ram gaan lezen, zonder dat cache daar per se bij betrokken hoeft te worden.

In het gemiddelde gecompileerde C programma wordt regelmatig cache gebruikt (meer wel dan niet), maar cache is uiteindelijk maar een soort snelle, kleine, RAM. Er is niks wat onder standaard x86 NIET kan zonder cache dat wel kan met -- het gaat alleen wat trager zonder. Het is pas als je exotischere instructies begint te gebruiken dat cache nodig wordt: prefetch0 tot 2 (SSE), sfence (SSE), mfence en lfence (SSE2), en zo kan ik er nog wel een paar opnoemen.

Vergeet niet dat de eerste 80x86'en geen cache hadden. IIRC is het pas bij de i386SL dat je extern (en dan niet al te veel -- ordegrote 10 tot 100k) cache kon toevoegen.
Onzin. Alle instructies gaan door de instruction cache, zoals SMa ook al aangeeft. (Net zoals alle data door de data cache gaat). Het enige wat kan gebeuren is dat er een branch instruction, dus een (conditional) jump plaatsvindt waarop de branch predictor van de CPU niet goed heeft kunnen anticiperen. In dat geval vindt er een cache read miss plaats en moet de instructie eerst vanuit het RAM naar de cache gekopiëerd worden. In dat geval is het zo dat de cache geen performance winst heeft opgeleverd, maar de instructie gaat wel degelijk via de instruction cache naar de instruction pipeline.

[Reactie gewijzigd door Stamgastje op 17 juni 2008 10:04]

Zeg er eens bij over welke processor je het hebt? De 386EX op m'n zolder (embedded ding) en de 386SL ernaast (laptop) doen het prima. De DX had een page cache, en die was je dan ook nog eens niet verplicht te gebruiken.

Als je er voor de lol er van uitgaat dat je je processor uit real mode haalt (halen, dit is een activiteit, elke x86'er sinds de invoering van protected mode met de 286 begint nog steeds in real mode), dan zit je niet meer binnen mijn originele premisse van standaard x86, en dan gaat alles wat ik zei uiteraard niet op. Op dezelfde manier dat ik jouw premissen kan negeren, zeggen dat we het over Z80's hebben, en dan zijn je uitspraken over misses onzin ;)
En hoe denk je dat die instructies in de CPU om tot micro-ops te vertaald te worden terrecht komen?

Er bestaat ook zoiets als een instructie cache, een prefetch en dan hebben we het nog niet eens over de vertaal slag die nodig is om van je logische geheugen adres naar een fysiek adres te gaan; daar worden ook een heleboel cache regels (TLBs) voor gebruikt!

m.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True