Fulcrum demonstreert asynchrone 0,13µ chip

SiliconStrategies.com bericht dat Fulcrum Microsystems bekend heeft gemaakt succesvol asynchrone chips te hebben gebakken met behulp van een 0,13 micron productieprocédé. De chips, bedoelt voor de communicatiemarkt, bevatten de volledig asynchrone Nexus crossbar switch block. Deze bleek in staat 800Gbit per seconde te verstouwen bij een voedingspanning van 1,2V en een energieverbruik van 4Watt.

Fulcrum logo Praktisch alle hedendaagse chips zijn synchroon wat betekend dat elke actie uitgevoerd door de chip precies moet gebeuren binnen een vaste tijdseenheid, namelijk één klokpuls. Het grote voordeel van een asynchrone chip is dat alle afzonderlijke delen van de chip precies op de maximale snelheid lopen onafhankelijk van de voedingsspanning of temperatuur. Er hoeft dus niet gewacht te worden op een klokpuls, zodra het circuit klaar is met een berekening kan begonnen worden met de volgende berekening.

Het probleem van een asynchrone chip is wel het complexe design. Aangezien er geen klokpuls is om het circuit mee te synchroniseren is het lastig om alle onderdelen van de chip met elkaar te laten samenwerken. De oplossing die Fulcrum hiervoor heeft bedacht is het gebruik van logische elementen met niet twee, maar drie mogelijke toestanden. Naast de gebruikelijke true en false-waarde is er ook een draadje aanwezig voor een ready-signaal. Hiermee wordt voorkomen dat de chip probeert logische functies uit te voeren terwijl de invoer nog niet compleet is.

Volgens Fulcrum presteert het asynchrone design aanzienlijk beter dan synchrone designs met een vergelijkbare complexiteit. Een ander voordeel is dat de circuits geen enkele stroom verbruiken als ze niet aan het rekenen zijn waardoor het energieverbruik lineair schaalt met de activiteit van de chip.

Werking synchrone en asynchrone chips geillustreerd

Lees meer

Reacties (27)

Verwijderd 7 maart 2003 01:56

De oplossing die Fulcrum hiervoor heeft bedacht is het gebruik van logische elementen met niet twee, maar drie mogelijke toestanden.

Dit is toch inherent aan asynchrone ontwerpen? misschien dat ze er iets aan verbeterd hebben...

ieg is 800 Gigabit/seconde niet nix. Dus dat asynchroon performance kan halen is bij deze bewezen.
Nu nog hopen dat ook complexere ontwerpen (zoals intel x86) asynchroon kunnen worden ontworpen, zou een zegening zijn voor de gehele it industrie.

voor zover ik begreep kost asynchroon werken ongeveer twee maal zoveel transistoren (ivm de ready state), dus een ontwerp wordt navenant (kwadradisch?) complexer.

Hiervan een mooi commercieel toepasbaar produkt van maken is zeker een prestatie. Wel frappant dat het zo'n vage naam is als fulcrum die het doet, en niet IBM.

Verwijderd @Verwijderd • 7 maart 2003 14:09

Wat ze eraan verbeterd hebben is dat hun logic delayinsensitive is, dwz dat niet alleen op vertragingen van andere logicabrokken wordt gewacht, maar ook de vertragingen als gevolg van signaalpropagatie door lange signaalpaden.

Ze claimen dat men in de ontwerpfase daardoor totaal geen rekening hoeft te houden met timing, wat het gebruikmaken van grotere hoeveelheden transistoren vergemakkelijkt. (Zij zeggen dat er een kwadratisch verband is tussen complexiteit - transistorcount - en ontwerptijd.)

Verder heeft de delayinsensitivity nog een voordeel: het wordt in sterke mate proces-onafhankelijk. Ga je dus van 180nm naar 130nm dan hoef je (bijna) geen redesign te doen en de boel loopt gewoon harder.

Nog een voordeel is de spanningsonafhankelijkheid. Vanaf een zekere minimale spanning (threshold) werkt het spul, en loopt steeds sneller tot de maximale spanning (kaputt). Je kan op die manier een powermanagement doen die volledig gestuurd wordt door performance-behoefte.

Verwijderd @Verwijderd • 7 maart 2003 16:44

Wat ik nog niet helemaal begrijp is de relatie tussen spanning en snelheid. Bij een hogere spanning genereert het circuit ook meer warmte, en asynchrone schakelingen gaan sneller lopen naarmate ze koeler zijn, dus langzamer naarmate ze warmer worden. Je zou verwachten dat er een bepaald optimum zit in de aangeboden spanning.
'Overklokken' wordt er ieg wel makkelijker op, gewoon koelen tot -30 en het loopt vanzelf sneller

SnowDude @Verwijderd • 7 maart 2003 13:02

Klopt, maar in een synchrone processor zet heel veel transistoren om de klok overal gelijk te krijgen, ik dacht dat ongeveer een derde van de transistoren in de processor voor de klok is.

RickN 7 maart 2003 10:51

Wat betreft dat "overklokken"

In een synchroon design heeft een circuit tussen twee klokpulsen even de tijd om de combinatorische logica tussen twee flip-flops (=dataelement) te evalueren en dan op het einde het resultaat van die evaluatie in die flipflops op te slaan. Wil dit goed gaan, dan moet je je kloksnelheid zo kiezen dat zelfs het langszaamste pad in die combinatorische logica (zgn critische pad) geevalueerd kan worden in de tijd tussen twee klokpulsen. Bij het designen zal dus geprobeert worden dit critische pad zo klein mogelijk te maken om zo'n hoog mogelijke kloksnelheid te kunnen gebruiken. Overklokken in dit geval is niets anders dan iets minder conservatief zijn dan de ontwerpers in de veronderstelling dat het critische pad toch nog wel ietsje sneller kan dan wat de originele kloksnelheid doet vermoeden.

In een asynchrone chip is er geen klok; elementen wachten op elkaar tot het critische pad geevalueerd is. Dit kun je vergelijken met een synchroon design waarbij de kloksnelheid echt preciés is afgesteld op de latency van het critische pad.

De latency van combinatorische logica schaalt met de voedingsspanning. Door de voedingsspanning te verhogen, overklok je als het ware je asynchrone design, in die zin dat het design er sneller van wordt. (uiteraard gaan temp en energie verbruik omhoog)
In het geval van een synchroon design heeft het verhogen van de voedingspanning hetzelfde effect; de latency (vertraging) van het critische pad wordt kleiner en daarmee schep je meer ruimte om de kloksnelheid omhoog te gooien.

Dat asynchrone designs energie zuiniger zijn is bekend en de reden hiervoor is hoofdzakelijk dat alleen element die nodig zijn in een bepaalde berekening ook daadwerkelijk energie verbruiken.
Echter, hier bij Philips zijn ze al zeg 20 jaar bezig met een volledig ontwerppad voor asynchrone chips en de algemene overtuiging hier is dat asynchroon in principe geen snelheid voordeel boven synchroon hoeft te hebben. De reden hiervoor is simpel, element moeten elkaar laten weten dat ze klaar zijn, dit gebeurt met handshakes. Deze handshakes kosten tijd. Vergelijk dit met mijn vorige voorbeeld van een synchrone chip die zo agressief geklokt is dat het critische pad er preciés in past. In dit geval zou een asynchroon design niet sneller zijn, en zelfs langzamer, omdat je nog wat tijd kwijt bent voor je synchronisatie handshakes.

Op het gebied van area scoort een asynchroon design ook nog steeds slechter dan een synchroon design. Met name wanneer een design "testable" wordt gemaakt (dwz een soort debug info toevoegen) wordt het tientallen procenten groter dan een vergelijkbaar synchroon design.

Een ander punt waar asynchroon beter scoort dan synchroon is EMR (electro magnetic radiation) een synchrone chip zend een soort radiogolven uit, met een vrij hoge intensiteit op bepaalde frequenties, juist door de synchroniserende klok. In een asynchroon design is de energie van die straling veel gelijkmatiger over het frequentie spectrum verdeelt en zul je weinig pieken in het frequentiespectrum zien. Dit is een interesante eigenschap als je je chipje b.v. vlak in de buurt van een stukje rf-tranceiver logica in je mobieltje wilt stoppen.

Tenslotte wil ik nog even melden dat het mij telkens verbaast hoe er als een soort heilige graal over zo'n asynchroon designtje als dit wordt gesproken, terwijl je gewoon naar Philips toe kunt stappen met de specificatie van je IC en afhankelijk van de complexiteit implementeren ze binnen een paar maanden een asynchrone variant ervan. Met, weer, de kanttekening dat je er dan rekening mee moet houden dat je design trager en groter is dan dan de synchrone variant, maar wel energiezuiniger.

Munters @RickN • 7 maart 2003 12:18

Perfecte uitleg RickN: complimenten.

Een aanvulling: wanneer de chip te groot wordt, gaat de snelheid van de stroom een aanzienlijke rol spelen. Een synchrone klok moet deze tijd ook altijd wachten (wachten tot het signaal dus overal op de chip aangekomen is, hetgeen de reden is dat het kloksignaal momenteel op 1 van de middelste pinnen aangeboden wordt).

Wanneer de miniaturalisatie niet veel verder kan, zal de kloksnelheid daarom ook niet veel hoger kunnen.
En dat is dan het moment dat de asynchrone variant weer meer in beeld komt.

bramfm @RickN • 8 maart 2003 16:01

Een ander punt waar asynchroon beter scoort dan synchroon is EMR (electro magnetic radiation) een synchrone chip zend een soort radiogolven uit, met een vrij hoge intensiteit op bepaalde frequenties, juist door de synchroniserende klok. In een asynchroon design is de energie van die straling veel gelijkmatiger over het frequentie spectrum verdeelt en zul je weinig pieken in het frequentiespectrum zien. Dit is een interesante eigenschap als je je chipje b.v. vlak in de buurt van een stukje rf-tranceiver logica in je mobieltje wilt stoppen.

Waar, maar niet zaligmakend. Bij een synchroon design is vaak te voorspellen waar de rotzooi zich bevindt, en er kan dus rekening mee te gehouden worden door harmonischen buiten de te ontvangen band te houden (bv door aanpassen van de clock frequentie van de micro). Bij asynchroon wordt de rotzooi willekeurig over de gehele band verdeeld, het is dan te ook verwachten dat een beperkte hoeveelheid "noise" ook in de te ontvangen band terecht komt. Dit hangt dan ook nog af van de spanning, process technologie en temperatuur. Door het hanshake principe zijn er echter dubbel zoveel handelingen nodig om data te verwerken, dus in praktijk _hoeft_ het niet altijd gunstiger te zijn.
Ben zelf altijd zeer enthousiast geweest over a-synchrone technologie, echter notabene onze EMC expert heeft dit enthousiasme getemperd met bovenstaande bevindingen.

Verwijderd 7 maart 2003 00:34

Dit bericht had ik al eerder gelezen bij Scientific American.
http://www.sciam.com/article.cfm?articleID=00013F47-37CF-1D2A-97CA809E C588EEDF&pageNumber=1&catID=2

Trouwens Philips heeft dit al eerder gedaan voor onderdelen voor sommige semafoons en Sun heeft het in hun UltraSpart IIIi zitten. Voordeel van asynchrone systemen is dat het veel energie en hitte bespaart, naast een potentiele snelheids winst.

DeTrucIs 7 maart 2003 09:28

Erg duidelijk plaatje (itt wat velen vinden :-) Voor de synchrone pipeline zijn twee plaatjes gebruikt, zoals de metronome (klok) aangeeft.
Echter het feit dat asynchroon sneller is dan synchroon (je moet dan de emmers op de grond neerzetten) wist men al in de 18e eeuw, toen de brandweer nog geen slangen had. Daarbij werd ook al gebruik gemaakt van het asynchroon doorgeven van emmers.

T.T. 7 maart 2003 00:12

Grappig plaatje, maar volgens mij klopt de analogie niet helemaal?
Het plaatje illustreert een rij mensen die emmers doorgeven. Aangezien er maar één rij is, zal de snelheid afhangen van het langzaamste element (persoon). Wanneer iedereen synchroon werkt, dan wordt er optimaal gepresteerd, want niemand hoeft op een ander te wachten.
In de asynchrone toestand moeten mensen op de langzaamste in de schakel wachten, dat is dus niet sneller dan wanneer ze synchroon zouden werken.

Een asynchrone processor heeft natuurlijk wel voordelen zoals Hielko aangeeft

In een processor zijn meerdere rijen en moeten mensen meerdere taken vervullen (om maar in de beeldspraak van een rij mensen te blijven).

0rbit @T.T. • 7 maart 2003 00:16

Nee, het plaatje is niet al te verhelderend, maar feit is wel dat de langzaamste persoon in de keten na een tijdje met een stapel emmers staat. Er wordt dus niet gewacht. Er wordt dan gewoon een extra mannetje op die positie gezet. (Om de analogie in stand te houden...)

Op deze manier werkt iedereen op zijn eigen (maximale) tempo en hoef je dus niet alles net iets trager te laten werken dan de traagste man.

Al met al heb je daar dus wel voordeel van

Asynchrone CPU's op dit principe zijn natuurlijk ideaal; Ze lopen niet meer vast als je ze 'overklokt'. Je moet ze gewoon beter koelen en iets meer sap geven; ze worden vanzelf sneller, maar nooit zo snel dat ze over hun nek gaan...

Verwijderd @0rbit • 7 maart 2003 01:19

Hoezo overclocken????

Als ik het goed heb is er bij een asynchroon circuit geen clock aanwezig en loopt dus de chip altijd op de maximal haalbare snelheid. vgl een enkele en-poort of exor-poort. deze hebben hun output asap na een verandering op de ingang. Dit soort asynchrone chips werken dus ook zo asap, maar bepaalde delen gebruiken dus een soort handshake om te bepalen wanneer data valide is.

meest ideale is dat er veel minder stroom loopt dan bij een vergelijkbaar synchroon ontwerp. Voor zover ik weet boet je wel een beetje in op die grootte (iets meer silicium oppervlak). De chips zullen dien ten gevolge wat duurder zijn dan de synchrone broertjes.

Verwijderd @Verwijderd • 7 maart 2003 02:17

Maar als de processor net zo snel werkt als er data aangeleverd wordt, zal je wel de aanlevering moeten beperken, anders raakt de cpu oververhit. Ga je die beperking opschroeven heb je je cpu dus overgeklokt.

draadjelos585 @Verwijderd • 7 maart 2003 09:03

Helaas... Hij werkt zo snel als ie kan, als je dus te snel data aanlevert is hij nog bezig met de vorige taak en moet de data wachten.

Hmmm, je zou kunnen zeggen dat de processor dan de data 'underclockt'

Verwijderd @T.T. • 7 maart 2003 09:19

ja, aan het plaatje te zien zitten er in het synchrone geval veel meer emmers in de pijplijn, ofwel een betere benutting van de capaciteit. Maar ach, het is maar een 'artist impression'.

Aangezien er maar één rij is, zal de snelheid afhangen van het langzaamste element (persoon). Wanneer iedereen synchroon werkt, dan wordt er optimaal gepresteerd, want niemand hoeft op een ander te wachten.
In de asynchrone toestand moeten mensen op de langzaamste in de schakel wachten, dat is dus niet sneller dan wanneer ze synchroon zouden werken.

Dat laatste zal ook het geval zijn in de synchrone toestand, T.T. De kloksnelheid zal moeten worden aangepast op degene die het langzaamst in die synchrone toestand kan werken: ofwel de hele keten zal daar last van ondervinden. In het asynchrone geval zullen de onafhankelijke elementen maximaal presteren zolang de aanvoer van data >= aan de verwerkingssnelheid en het bij de afvoer naar het volgende element niet stokt.

Tsjee, wat zo'n plaatje niet kan doen. Je kan er een studie aan wijden.

Munters @T.T. • 7 maart 2003 12:08

Nee T.T. het is precies andersom: bij de synchrone versie moet de beweging (klok) zo zijn dat de langzaamste het ook nog red.

En om dan bij het plaatje (zeer onduidelijk m.i. trouwens) te blijven: de emmertjes hoeven bij de synchrone variant helemaal niet gevuld te zijn.

Gwaihir @T.T. • 7 maart 2003 04:42

Plaatje is inderdaad onduidelijk. Het bijzondere zit 'em erin dat in de onderste situatie maar één rij mensen nodig is om emmers in twee richtingen tegelijk te verplaatsen (zie de klein grijze pijltjes onder ieder persoontje). In de bovenste situatie zijn daar twee rijen volk voor nodig, omdat iedereen in zo'n rij netjes hetzelfde moet doen (synchroon moet handelen).

Strebor

@Gwaihir • 7 maart 2003 09:57

Sorry... fout.

De bovenste twee rijen zijn dezelfde, echter een halve klokpuls verschoven in tijd. Eerst geven de mannetjes synchroon de emmers door naar rechts en zetten hem neer. Vervolgens draaien ze weer terug naar links om de volgende klaarstaande emmer op te pakken.

De onderste geeft aan dat de mannetjes onafhankelijk van elkaar zo snel mogelijk de emmers doorgeven en weer terugdraaien om klaar te staan voor de volgende emmer.

Ruudjah 7 maart 2003 00:12

Als ik dit goed begrijp is dit dus best wel een doorbraak in de chip-industrie? Ik geloof laatst gelezen te hebben dat chips die asynchroon werken nogal een achterstand hadden op het gebied van ontwikkeling; je kon de ontwikkeling van a-synchrone chips vergelijken op het niveau van de synchrone chips van de jaren 80... toch?

Verwijderd @Ruudjah • 7 maart 2003 08:02

Behalve dat je een nieuwe ontwerp methodologie moet leren, is het valideren van een asynchrone schakeling veel moeilijker dan van een synchrone.

dr snuggles 7 maart 2003 14:04

Deze bleek in staat 800Gbit per seconde te verstouwen bij een voedingspanning van 1,2V en een energieverbruik van 4Watt.

Dit zegt mij niets. 800Gbit = 100GByte. Klinkt als enorm veel.

Maar ik zou vergelijkende scores willen hebben. Hoeveel trekt bijv. een p4 op 2,5ghz

nIghtorius @dr snuggles • 7 maart 2003 17:52

Bij de pentium 4's..

de 100 * 4 Mhz variant trekt: 3,125 GB/s
de 133 * 4 Mhz variant trekt: 4,164 GB/s

de toekomstige 200 * 4 Mhz variant trekt: 6,25 GB/s

berekening is (FSB * 4 * (64 /

) = antwoord in megabytes per sec.

als voor de grap neemt dat een P4 2,5Ghz een FSB had 2,5Ghz die niet quadpumped was. dus dat er in één klokslag 8 bytes verwerkt konden worden krijgen we de volgende topspeed:

18,626 GBytes per second.

i.a.w.: 800GBit is aso veel.. vooral als het geen parallelle ontwerp is.