Philips ontwerpt asynchroon werkende ARM-processor

Handshake Solutions, een divisie van Philips, is samen met ARM bezig met het ontwerp van een asynchrone processor. In een asynchroon ontwerp is er geen klok aanwezig. Het grote voordeel hiervan is dat transistors alleen schakelen als dit echt nodig is. Omdat transistors alleen energie verbruiken als deze geschakeld worden, kan hiermee heel wat energie worden bespaard. Een bijkomend voordeel is de verminderde elektromagnetische straling die de cpu uitzendt ten opzichte van een synchrone cpu. Het nadeel is echter dat het ontwerp van de chip een stuk moeilijker is.

De cpu zal overweg kunnen met de vijfde versie van de ARM-instructieset. Daarnaast zal er ondersteuning voor Thumb en DSP-extensies aanwezig zijn. Het is de bedoeling dat de chip een plek vindt in draagbare apparatuur, zoals PDA's en telefoons. De processor kan net als andere ARM-processors in licentie worden genomen door microelektronicafabrikanten en zal ergens in het eerste kwartaal van 2005 beschikbaar komen.

Synchroon (links) vs asynchroon circuit (rechts). De schakelende transistors zijn met rode punten aangegeven.

Reacties (44)

[colleoni]

Grappig, Arm was hier reeds in 1990 bezig, ten tijde van de RISC OS machines van Acorn. De chip heette toen ARM Amulet1, daarna kwam er nog een Amulet2 en dit is dan de Amulet3? zie ook http://www.cs.man.ac.uk/apt/old/projects/AMULET1_uP.html

[Verwijderd]

Een zéér interresante ontwikkeling die er al een tijd aan zat te komen.

Als iets dergelijks in een PC zal kunnen worden toegepast, zal dit energie schelen, en theoretisch een enorme snelheidsboost kunnen betekenen, immers nu moeten onderdelen op elkaar wachten.

Voor erwinb (wat zijn die rode vlekjes?):

edit: lam hoor, je post aanpassen.

[justice strike]

het bestaat al heel lang asynchrone processoren. Het is alleen ontzettend moeilijk deze te ontwikkelen.

Er zijn namelijk nog steeds conflicten die je moet op lossen. bijvoorbeeld, stel je moet wachten op de gegevens van een andere transistor, kan je dan ook gegevens aannemen? omdat er geen klok is weet jij niet hoelang het duurt voordat de andere transistoren klaar zijn met hun werk, dus kan jij ook niet weten of je zelf sneller klaar zou kunnen zijn dan datgene waar je op wacht.

Dit zijn maar een paar voorbeelden. Overigens is het wel leuk om te zien hoe deze discussie op meerdere lagen in de informatica worden gevoerd. namelijk niet alleen voor asynchrone processoren ook asynchrone communicatie, asynchroon distributed computing etc... en telkens duiken min of meer dezelfde problemen op.

[erwinb]

Als de clock van extern komt, hoe kunnen er dan transistoren schakelen?

[Rataplan]

Als de clock van extern komt, hoe kunnen er dan transistoren schakelen?

Door alle logica zelf een resultaat-gereedsignaal te laten produceren.

Zwaar versimpeld voorbeeld: stel dat je twee getallen bij elkaar wilt optellen. Als het 'adder'-circuit klaar is met het optellen, dan produceert hij behalve de lijntjes met het resultaat, zélf een signaal op een apart lijntje (ook een soort klokpuls, eigenlijk) dat het volgende stuk logica aanzet, bijvoorbeeld om het resultaat naar het geheugen te transporteren.

In een 'normale' chip wacht die volgende logica eerst rustig de volgende clockpulse af. Nadeel daarvan is dat alle componenten elke cycle zo'n pulse te verwerken krijgen, en er maar heel weinig dan ook daadwerkelijk iets doen.

Een asynchrone cpu is in theorie (!) dus niet alleen zuiniger (omdat alleen die componenten worden ingeschakeld die iets moeten doen) maar ook sneller dan een synchrone (omdat alle instructies precies zoveel tijd gebruiken als ze nodig hebben).

Maar om al die logica goed op elkaar aan te laten sluiten is vers twee, natuurlijk.

[Arieke]

Switching activity (power) is shown in red

De plaatsen waar stroom is vereist tijdens het uitschakelen van de transistor.

[off topic]Wel mooi gedaan 4 dezelfde de posts in minder dan 1 minuut[off topic]

[Cyberamp]

Activiteit van transistors

"Synchronous vs. Asynchronous: Switching activity (power) is shown in red"

[GoodspeeD]

Synchroon (links) vs asynchroon circuit (rechts). De schakelende transistors zijn met rode punten aangegeven.

[nvidia]

Klikt ontzettend leuk maar ik vrees als men deze cpu's zal willen maken de prijs stukken omhoog zal gaan zoals in post gemeld.

Natuurlijk is dit altijd leuk voor de computergebruiker qua temperatuur en stroomverbruik. Of de consument daar een meerprijs voor WIL geven is dan de vraag! Ik zou dit wel doen maar als ze toch de prijs zo laag mogelijk proberen drukken ookal ligt deze wel wat hoger (10
%) hoger dan de prijs van een gewone cpu!!

[OruBLMsFrl]

Er zijn altijd bedrijven die bijvoorbeeld de langste stand-by tijd willen claimen. Mijn Philips Xenium 9@9++ (wat een naam) heeft een stand-by tijd van meer dan een maand... denk dat die wel gaan voor een iets duurdere cpu die minder stroom vreet. Maar ja, het is dan ook een toestel voor een bepaalde markt, niet voor pubers die graag foto's MMS'sen .
Een telefoon heeft deze CPU misschien niet nodig? Misschien voor video (via UMTS) wel, anders zijn er vast wel PDA fabrikanten die zo lang mogelijk met de batterij willen doen...

[Luxx]

In princiepe hoeft de prijs dus niet hoger te liggen. De energie voordelen en het achterwege laten van de klok leiden tot mogelijk kleinere processoren. Je kan alleen veel minder "standaard blokken" aan elkaar plakken. Omdat asynchroon ontwerpen erg nieuw is, wordt dit veel minder gedaan, en daarom is het (ontwerpen) op het moment veel duurder. Ook ontstaan er allerlei timings problemen, die het ontwerp complexer maken.
In moderne processoren zouden er echter enorme voordelen kunnen ontstaan bij een asynchroon ontwerp. Het is daarom zeker geen gekke gedachte om in ieder geval hier in de toekomst naar te blijven kijken.

[Horus]

Denk niet dat er zo gauw een asynchrone pentium oid zal verschijnen. Het is namelijk razend ingewikkeld zodat een moderne PC cpu met z'n uitgebreidde instructieset niet echt haalbaar is.

[OruBLMsFrl]

Misschien heb je gelijk, misschien ontdekt morgen iemand een techniek om handig van een high-level VHDL beschrijving direct een asynchrone chip te maken... na nano tubes en quantum technieken lijkt me een dergelijke uitvinding niet eens zo vreemd meer. Zodra bedrijf A met techniek A snellere CPU's kan maken, dan komt bedrijf B prompt met een aankondiging van techniek B, waarmee een vergelijkbare snelheidswinst te behalen valt.
Op dit moment is het misschien de moeite van het ontwerpen niet eens voor Intel en AMD, zo'n asynchrone chip... kost misschien ook een (paar) jaar extra, ik weet het niet. Wat ik wel weet is dat het gegeven genoeg tijd en investeringen zeker niet onmogelijk zal zijn om een dergelijke chip te maken.
Ze hebben het nu echter goed voor elkaar, met gezonde winstmarges, dus waarom de markt verpesten door dat soort technieken uit te brengen. Volgens mij zou met een milieubelasting van 10 euro per Watt (15 Watt scheelt 150 euro per CPU) na een jaar best een aankondiging van een asynchrone CPU kunnen komen hoor...

[Verwijderd]

Een ARMv5 is niet zo heel veel minder ingewikkeld dan een moderne PC cpu.
Sterker nog, daar kun je gewoon een PC mee bouwen. Heb er hier een naast me staan, heeft bijna alles behalve een videokaart (besturing via telnet) en draait Windows CE.

[Verwijderd]

En als nu AMD en Intel een licentie nemen op deze technologie van Philips hebben alle partijen er baat bij. Wellicht dat een volgende generatie CPU's kan uitgerust worden met zowel deze techniek, als de reeds bestaande stroombesparende technieken (indien deze niet gewoon al een andere manier zijn van deze door Philips ontwikkelde techniek).

Op miljoenen transistors energie afsluiten zou wellicht kunnen zorgen dat we weer naar de normale situatie toegaan van passief koelen, of minder gigantische koelers, of water koeling etc.

[kaas-schaaf]

Het overclocken gaat er dan iig ook uit, asynchroon (dus zonder clock signal) kan -correct me if i'm wrong- niet op een hogere / lagere frequentie draaien omdat er dan wellicht transistoren zijn die niet snel genoeg / sneller gaan schakelen. Wat resulteert in een signaal dat niet over de gehele chip gelijk loopt. (vrij doodelijk voor je berekeningen op dat moment)

[kELAL]

Het overclocken gaat er dan iig ook uit, asynchroon (dus zonder clock signal) kan niet op een hogere / lagere frequentie draaien...

Neo, there is no spoon^H^H^H^H^Hfrequency! Ban het 'F-woord' uit je hersenpan, als je aan a-synchroon denkt; scheelt wat gedachten/taal kronkels...
Feit is dus, dat de exectutietijd van elke instructie nu louter bepaald wordt door de (volledig fysiek bepaalde) propagatietijd van de gebruikte deelschakeling, om 't even netjes uit te drukken...

Wat resulteert in een signaal dat niet over de gehele chip gelijk loopt.

Goh wat erg...
Maakt geen donder uit! Zowel microscopisch niet (asynchrone handshakes) als macroscopisch niet (out-of-order execution). Beiden helemaal niets nieuws in digitaal-land...

Zoals zagadka al opmerkte, is 't concept niets nieuws, maar 't mocht tijd worden dat 't 'n serieuze stap richting 'mainstream' maakt. Eindelijk van 't [MG]Hz- en 'half gebruikte' cycle gezijk af!

[marsattacks]

Je kunt een asynchrone CPU nog steeds 'opvoeren' door simpelweg het voltage op te krikken. De transistoren schakelen dan sneller, en dus ook de asynch-cascade.

[Sphere-]

Ik denk niet dat deze technologie in de nabije toekomst voor desktops komen omdat je dan waarschijnlijk gehele besturingsystemen en software opnieuw kan schrijven. ARM processoren zijn geheel anders dan x86 processoren

[Rukapul]

OS en applicatie software staan los van de onderliggende CPU. Linux draait bv zonder problemen op vele CPUs inclusief x86 en ARM.

Dat x86 toch niet zo snel asynchroon zult zien als een ARM heeft te maken met de complexiteit van de instructieset en overige architecturele aspecten (caches, pipelines, etc.). Dit is bij moderne x86 implementatie zoveel complexer (en groter) dan ARM implementaties dat het asynchroon maken veel meer werk is.

[MBV]

als ik code maak, en daar verschillende binary's van maak (linux-x86, linux-arm, ...) dan hoef ik nog steeds maar 1x de code te schrijven. Zonder de code opnieuw te schrijven kan het werken op een ander systeem.
Linux ombouwen naar een nieuw platform kost maanden, linux herbouwen kost 15 jaar...

Ook voor Microsoft moet het mogelijk zijn om te hercompileren voor een ander platform. Aangezien ze dit nog niet zo vaak hebben gedaan zal dat wel wat lastiger zijn...

[Verwijderd]

waarom zijn er dan voor x86 en ARM toch verschillende binaries?

juist, omdat het wel degelijk uit maakt...

[Confusion]

Verschillende binaries, dezelfde code, gecompileerd voor die instructieset. Iets dat op een synchrone ARM draait, draait ook op een asynchrone ARM. Debian draait er dus op.

[Dope-E]

Maar deze asynchrone cpu zal dus de ARM 5 instructieset ondersteunen... Dus alle bestaande software die hiervoor gecompileerd is zal dus gewoon werken lijkt mij.

De wijze waarop instructies worden uitgevoerd is niet interessant voor de software, als de instructieset maar klopt.

[Schapie]

Ik denk niet dat meteen bij de volgende generatie zal worden geimpleteerd kijk maar eens naar enkele roadmaps van amd en intel. Voordat dit soort technieken op de desktop markt geintroduceerd worden zal er nog heel wat onderzoek en ontwikkeling gedaan moeten worden. Want je krijgt dan immers heel ander soort platform dat behoorlijk afwijkt van wat we nu gebruiken. (Op de desktop dan)

Ik denk zelf dat soort chips zeker de toekomst zullen hebben maar met toekomst denk ik wel dat daar zeker nog 5 tot 10 jaar ontwikkeling aan zit maar begrijp me niet verkeerd als dit goed wordt opgepikt kan dit zomaar dichter bij de 5 dan bij de 10 jaar zitten. Het lijkt mij zeker intresant om deze techniek bijvoorbeeld te combineren met nano en quantam technieken want op die manier krijg je zeer kleine cpu's met een zeer laag stroom verbruik.

[n4m3l355]

ik denk dat zowel amd als intel ook wel aan deze techniek zitten te werken maar dan voor hun type cpu's ik denk niet dat 'standaard' intels/amd's zich lenen voor deze techniek en dan toch wel een stevige wijziging nodig hebben. toch min of meer passen het al toe. niet gebruikte stukke core schakelen zich nu namelijk uit dit is natuurlijk effectiever en ik denk in de toekomst sneller aangezien je niet oneindig kan blijven upscalen. misschien dat dit trouwens ook mogelijk is met een netwerk dat de 'doorsturende' data snelheid/bussnelheid afhankelijk van de totale data dat men probeert te sturen?

[Verwijderd]

Hmm, zo erg nieuw is dit nu ook weer niet:

http://www.cs.man.ac.uk/apt/old/publications/papers/comcon94.html

Dateert uit 1994 en beschrijft

a fully asynchronous implementation of the ARM microprocessor

.

[FrankNStein]

ik had een paar jaar geleden ookal in Scientific American gelezen dat SUN ook bezig was met de ontwikkeling van Asynchrone chips...
Ik maar wachten en wachten, en me afvragen waarom ik er niks meer van hoorde..
nu gaat 'onze' Philips er gelukkig ook mee door

[NaliXL]

Deze manier van ontwerpen: zit je daarmee niet per definitie altijd aan de maximumsnelheid van een processor? Als je geen "tikken" gebruikt, ben je slechts beperkt door de snelheid van schakelen van de transistors lijkt me...?

[pietje63]

Wat ik me afvraag is hoe ziets met een while lus omgaat. Hiervoor heb je volgens mij toch een klok nodig die zegt "we we zijn weer 1 duizendste seconde verder laten we de conditie nog een keer controleren".

[jcvw]

Ook in een while lus is het moment waarop je weer test heel duidelijk niet tijd-afhankelijk, maar ``wat is er al gedaan'' afhankelijk.

while (conditie) do
statement
done

wordt zo:
conditie
statement
conditie
statement
etcetc totdat conditie false oplevert. Het is dus niet zo dat de conditie steeds weer wordt uitgerekend tijdens het uitvoeren van je statement. Pas als het statement gedaan is, gaan we weer een conditie uitrekenen.

[kELAL]

Ook in een while lus is het moment waarop je weer test heel duidelijk niet tijd-afhankelijk, maar ``wat is er al gedaan'' afhankelijk.

Genau, genau...

De enigste lussen, die bij een a-synchrone proc non-deterministisch gedrag vertonen, zijn delay-loops. Godzijdank... zijn we daar ook weer van verlost! Wat is er mis met hardware timers (en dan echt bruikbare, niet 1 enkele met een hele rare interval (hint: x86 platform)) en event-driven programmeren?

[Verwijderd]

Bij een while lus wordt de conditie pas opnieuw geevalueerd als het hele code blok binnen de lus doorlopen is of dit geforceerd wordt gedaan (continue). Overigens zou ik niet weten hoe compilers(/linkers) deze while loops precies omzetten naar machinecode.

edit: iemand was me voor... - consider not posted -

[Reb87]

de schakelende transistors (staat eronder)