IBM EinsTuner software optimaliseert chip-designs

Zoals algemeen bekend is, bestaat een chip uit transistors. Groepjes van transistors vormen poorten (gates) die logische operaties als NAND of NOR uitvoeren. Groepen van deze gates stellen op hun beurt weer optellers, buffers, multiplexers of andere bewerkingen voor. Het ontwerp van een chip gebeurt echter niet op poortniveau. Met behulp van een hardware beschrijvingstaal als VHDL of Verilog worden de functies van een chip beschreven. Deze beschrijving wordt doormiddel van een synthese programma in de eigenlijke poorten omgezet. Dit is vergelijkbaar met het schrijven van een programma in C dat door een compiler in assembly wordt omgezet. Van de veel voorkomende logische bewerkingen zoals optellen, aftrekken, delen of vermenigvuldigen, maar ook geheugens, heeft de synthese tool de beschikking over een bibliotheek met onderdelen waarin deze functies op transistorniveau zijn geoptimaliseerd. Maar er zijn ook blokken die je niet in zo'n bibliotheek tegen zult komen omdat ze afhankelijk zijn van het ontwerp. Een voorbeeld hiervan is de registerfile. De registerfile is een stukje geheugen waarin alle registers van een CPU staan opgeslagen. Daar deze registerfile bij bijna elke bewerking geraadpleegd wordt, is het dan ook belangrijk dat deze zo snel als technisch mogelijk is. Dit soort blokken wordt dan ook met de hand ontworpen waarbij elke transistor getweaked wordt op snelheid, energieverbruik of grootte.

Het probleem is echter dat het optimaliseren van deze blokken tijdrovend is. Als het echter aan IBM ligt, zijn deze custom blokken binnenkort verleden tijd. Op SiliconStrategies.com kunnen we namelijk lezen dat IBM op de grootste microelectronica conferentie van de wereld, DAC (Design Automation Conference), een tool zal presenteren die een customblok kan optimaliseren. De tool, EinsTuner genaamd, neemt een schema van het ontwerp en een lijstje met parameters en na enkele uren stampen komt er een geoptimaliseerd blok uitgerold. IBM claimt dat ze de tool al met succes ingezet hebben bij het ontwerp van de Freeway System 390 mainframe processor, de Regatta Power4 server processor en een low-power-consumption PowerPC controller.

Reacties (34)

arcadis 6 juni 2002 20:20

Dit betekent dus dat IBM een manier gevonden heeft om goedkoper processoren te ontwikkelen. Als ik het goed begrijp kunnen ze dus de ontwikkeltijd behoorlijk verkorten.
Hopelijk gaat dit zich weerspiegelen in goedkopere proc's.

roelio @arcadis • 6 juni 2002 20:32

goedkopere processoren? Dat denk ik niet. Wel op kortere termijn snellere of minder energie verbruikende processoren, maar de prijs van processoren wordt toch voor een groot deel bepaald door researchkosten en een markt-afroom strategie.

NB: Deze software zorgt er niet voor dat de researchkosten zeker weten flink dalen.

Stephan Oudmaijer @roelio • 6 juni 2002 21:28

toch denk ik het wel, optimaliseren kost vaak de meeste tijd! En ook snap ik niet waarom processoren hierdoor sneller zouden worden, er wordt alleen bespaard op tijdrovende klussen.

Even als reactie op het bericht hieronder: zeker als het goedkoper wordt om te produceren zal de consument direct hier iets van merken. Kijk bijvoorbeeld maar eens naar de overstap van .18 naar .13 productie van processoren. Daar konden ineens meer processoren gebakken worden uit het zelfde formaat waffer, wat direct prijsvoordeel oplevert.

Ik denk dat chipbakker veel sneller proef samples kunnen bouwen, wat het ontwikkel traject veel sneller zal laten verlopen. En uiteindelijk kosten besparend zal werken.

roelio @Stephan Oudmaijer • 6 juni 2002 21:36

En zelfs al zouden de designkosten dalen, dan nog geldt voor de meeste processoren die nu op de markt zijn (zie Intel) nog steeds een soort afroom-strategie waardoor er waarschijnlijk voor ons niets goedkoper wordt.

Auteur

Ralph Smeets @roelio • 6 juni 2002 21:44

Dit soort blokken wordt dan ook met de hand ontworpen waarbij elke transistor getweaked wordt op snelheid, energieverbruik of grootte.
[...]
De tool, EinsTuner genaamd, neemt een schema van het ontwerp en een lijstje met parameters en na enkele uren stampen komt er een geoptimaliseerd blok uitgerold.

Je kunt dus kiezen om sommige blokken kleiner te maken. Dit resulteerd in een kleinere chip en dus meer chips per wafer. Productiekosten per wafer zijn altijd hetzelfde, maar je kunt wel meer chipjes per wafer verkopen, dus minder kosten per wafer.

En ook snap ik niet waarom processoren hierdoor sneller zouden worden, er wordt alleen bespaard op tijdrovende klussen.

Bij het optimaliseren van een blok kun je ervoor kiezen dat de tijd van de operatie van het blok kleiner wordt. Hierdoor kan de klok dus omhoog geschroeft worden en heb je dus een snellere processor.

iKiddo @Ralph Smeets • 8 juni 2002 20:09

Maar die keuzes kunnen nu ook al gemaakt worden! Het enige verschil is nu dat je na het maken van die keuzes je het alleen in de software hoeft in te voeren, in plaats van het je engineers hier vele uren over moet laten denken.
Het is dus eigenlijk onzin om te zeggen dat dit programma de chips sneller of kleiner zal maken.

ajslaghu @arcadis • 6 juni 2002 23:04

Met NOR poorten alleen kan je elke processor bouwen. Waar maken ze zich druk over :-)

(misschien dat PII al een voetbalveld groot is)

wederom een leuk feitje om te weten.

RickN 6 juni 2002 23:32

Als dit echt zo goed werkt als ze beweren zou dit in bepaalde gevallen een behoorlijke snelheidswinst op kunnen leveren. Echter, voor je op zo'n laag niveau gaat optimaliseren, is het belangrijk dat je design op gateniveau efficient in elkaar zit. Daar zijn ook tools voor (ambit, synopsys), maar ik kan uit ervaring zeggen dat de kwaliteit van die optimalisaties vaak om te janken is. Zelf zou ik dus ook enthousiaster zijn geweest over een tool die gate level optimalisaties goed aan zou pakken, omdat de snelheids winst die bereikt kan worden met transistor level optimalisaties voor veel doorsnee embedded systemen helemaal niet zo belangrijk zijn. Als je bekijkt hoeveel méér standard cell designs er worden gemaakt dan full custom designs, blijkt al wel dat deze manier van het onderste uit de kan halen vaak helemaal niet nodig is.

edit:
Misschien heb ik iets te vroeg geblaat. In het artikel wordt vermeld dat de tool ook met standard cells om kan gaan. Dat zou natuurlijk heel mooi zijn, aangenomen dat ie het beter doet dan de huidige tools.

Harry_Sack @RickN • 7 juni 2002 04:50

--------------
Als dit echt zo goed werkt als ze beweren zou dit in bepaalde gevallen een behoorlijke snelheidswinst op kunnen leveren. Echter, voor je op zo'n laag niveau gaat optimaliseren, is het belangrijk dat je design op gateniveau efficient in elkaar zit. Daar zijn ook tools voor (ambit, synopsys), maar ik kan uit ervaring zeggen dat de kwaliteit van die optimalisaties vaak om te janken is.

----------------

Om nog maar over software bugs te zwijgen, welk programma controleert het programma? Je zou onderhand gaan denken dat er meer registerruimte moet worden vrijgemaakt om de bugs te onderdrukken dan dat het een succes wordt. Aan de andere kant, als je een 386 als voorbeeld neemt, kun je wel een basis leggen, of dat optimaal is, moet zich nog maar zien te bewijzen.

Helaas zijn er nog geen neurale netwerken die het probleem voor ons op kunnen lossen.

Auteur

Ralph Smeets @Harry_Sack • 7 juni 2002 07:43

Je kunt het geoptimaliseerde blok met equivalents checking met je originele RTL vergelijken en zo garanderen dat beiden gelijk zijn.

dirkpostma @RickN • 7 juni 2002 17:37

Een beetje background info:

Traditionele flow van RTL naar layout is:
1) Men neme een RTL beschrijving
2) Synthetiseer deze naar een gate-level netlist
3) Optimaliseer netlist
4) Plaats de cellen
5) Routeer
6) Kijk of het worst-timing path je timing budget haalt
7) Zo niet, ga terug naar 3), en vertel 3) dat hij die ene worst timing path optimaliseert

Ofwel: veel (langzame) iteraties zijn nodig. Het langzaamste pad bepaalt de snelheid van de processor. Als je 1 miljoen paden hebt van 1 ns (1 GHz) en ééntje doet er 3 ns (333 MHz), dan is de max. klok freq. van je processor toch 333 MHz...

Synopsis en Cadence, momenteel de grootste leveranciers van commercieel beschikbare Design Automation tools doen het (voorlopig althans) nog op deze manier.

Verder is echter een trend gaande: een paar jaar geleden was de delay van een gate de beperkende factor. Tegenwoordig worden de wires (capaciteit!) die de gates verbinden steeds meer de beperkende factor wat betreft timing. Bij .18 processen is het ongeveer gelijk, maar bij .13 is het zeker de wire-delay die het meest zorg draagt voor slome paden.

EinsTuner maakt hier gebruik van. Door een gate groter te maken kan deze een wire sneller aansturen. Dit kost (veel) oppervlakte, maar dit komt wel de timing ten goede. Aan de andere kant kunnen bij de niet-kritische paden hele kleine transistoren gebruikt worden. Ofwel: door transitoren gedurende de flow van RTL naar layout dynamisch te sizen kunnen chips veel beter (en efficienter) geoptimaliseerd worden.

[Conclusie]
Ik weet zeker dat tools als EinsTuner zeer belangrijk zijn voor vooruitgang in IC ontwerp. Helaas gebruikt IBM de tools alleen intern en verkoopt de techniek (nog?) niet aan fabrikanten van grote IC's. Een wel beschikbare tool die gebruik maakt van variabele gate-sizing is "Blast Chip" van Magma Design Automation, zie http://www.magma-da.com/ Deze tool is alleen iets minder geavanceerd als EinsTuner, maar heeft in vergelijking met Synopsis en Cadence zeker een voorsprong voor het ontwerpen van .13 proces IC's doordat langdurige iteraties niet meer nodig zijn. Gevolg: goedkopere en snellere processoren.

Auteur

Ralph Smeets @dirkpostma • 7 juni 2002 23:21

Een aantal tools ontwikkeld voor intern gebruik worden ook aan een aantal geselecteerde microelectronica fabrikanten gelicenseerd. De Genesys testgenerator, zie: http://www.haifa.il.ibm.com/projects/verification/genesys.html is hier een voorbeeld van. Deze generator is ontwikkeld voor het genereren van tests voor de PowerPC en wordt door sommige microelectronica fabrikanten gebruikt om testen voor hun CPU's te schrijven en te genereren. De propertie checking tool RuleBase ( http://www.haifa.il.ibm.com/projects/verification/RB_Homepage/index.ht ml ) is een ander voorbeeld. De gebruikte taal Sugar om properties te beschrijven is zelfs door het Accelera comitee gekozen als IEEE standaard voor het beschrijven van properties. En last but not least, ik heb zelf vier jaar geleden als ingenieur bij STMicroelectronics mee mogen helpen aan Genevieve, http://www.haifa.il.ibm.com/projects/verification/genevieve.html, waarin ST, IBM en LEDA (ondertussen overgenomen door Synopsys) samenwerkten. Het zou me dus niet verwonderen dat EinsTuner aan sommige fabrikanten gelicensed wordt.

Verwijderd 6 juni 2002 20:22

Volgens mij heeft er iemand iets heel moeilijks proberen uit te leggen maar is dit (voor mij) niet gelukt!
sjees snap er geen biet van..

Maar goed toch bedankt voor de moeite

Auteur

Ralph Smeets @Verwijderd • 6 juni 2002 20:43

Tja, een samenvatting van een vier jarige hogeschool opleiding digitaal ontwerpen is nogal moeilijk. Ik heb geprobeert om het zo algemeen als mogelijk te houden, maar dat blijft moeilijk

Vergelijk het maar eens met het schrijven van een programma:
Stel je voor dat je een programma schrijf in C. Een bepaald gedeelte moet snel zijn en hiervoor gebruik je in dat geval in-line assembly code. Bij digitaal ontwerpen is dit bijna hetzelfde. Stel je nu eens voor dat er een tool is die deze tijdrovende assembly code voor je schrijft.

Verwijderd @Ralph Smeets • 6 juni 2002 21:17

Tigger heeft gelijk, duidelijk uitgelegd. Thnx daarvoor.
Als ik het goed heb begrepen is dat register de bottleneck, en kan IBM die op een snellere manier een efficienter (zuiniger/sneller) register maken.

Auteur

Ralph Smeets @Verwijderd • 6 juni 2002 21:35

Let wel dat de registerfile een van de vele blokken is die geoptimaliseerd kan worden met EinsTuner. Andere blokken zoals custom multipliers kunnen er ook mee verbeterd worden.

Verwijderd @Ralph Smeets • 6 juni 2002 20:49

Petje af hoor. Ik vind het erg goed uitgelegd. Maar ik moet er bij zeggen dat ik computertechniek gestudeerd heb dus e.e.a. klinkt met niet onbekend in de oren. Toch vind ik dat het nog redelijk begrijpen uitgelegd is.

Verwijderd @Verwijderd • 6 juni 2002 20:43

Registers zijn eigenlijk gewoon stukjes geheugen die in de CPU zitten. Geheugens die niet adresseerbaar zijn via geheugenadressen (zoals normaal geheugen in je computer), maar een symbolisch naampje hebben (het beestje moet een naam hebben zodat de CPU weet in welk register een getal moet worden geschrven of gelezen). In de machinecode definitie van de CPU bestaan er dus instructies om getallen in die registers op te slaan, om er bewerkingen mee uit te voeren (tussenresultaten van berekeningen bijvoorbeeld), en om ze weer uit te lezen. Aangezien de registers rechtstreeks op de CPU zitten kan de CPU hier supersnel mee werken, vele malen snellen dan je normale geheugen. Want de geheugenbus draait vele malen langzamer dan de CPU kloksnelheid.

Jiriki @Verwijderd • 6 juni 2002 20:34

Wat is er van begrijp/weet, is dat de registers nodig zijn voor zo'n beetje alle bewerkingen. Als je twee getallen optelt komen die uit een register en het resultaat gaat naar een register.
Het is dus belangrijk dat die registers zo snel mogelijk zijn. Tot nu toe namen ontwerpers niet het risico dat CAD software die registers dus zo maar ergens neer zouden planten in een willekeurige vorm.
Deze IBM software zou daar dus rekening mee houden en optimaliseren op "snelheid, energieverbruik of grootte". Vergelijk het met een botsproef op een auto, het maakt nogal veel tijd en (dus) geld uit of dat in real-life of in de computer kan gebeuren.

-=bas=- 6 juni 2002 22:10

na enkele uren stampen komt er een geoptimaliseerd blok uitgerold

Klinkt als een botte-bijl-methode die gewoon alles probeert en de snelste oplossing presenteert

arjankoole @-=bas=- • 7 juni 2002 11:08

Klinkt als een botte-bijl-methode die gewoon alles probeert en de snelste oplossing presenteert

ik vermoed van niet, het optimaliseren van dergelijke blokken kost normaal gesproken al veel tijd, dus reken maar dat een computer programma er ook flink voor zal moeten gaan calculeren. (en misschien de chip emuleren om te testen)

Verwijderd 7 juni 2002 15:51

Toch kleven aan dit soort programma's ook een aantal gevaren. Het kan namelijk gebeuren dat er toch design fouten (was vroeger ook mogenlijk omdat dit werk door een mens werd uitgevoerd) er doorheenglippen maar niet worden opgemerkt omdat er teveel vertrouwen is in de gebruikte tool. Bij uitgebreide procs. is het vinden van een fout zowiezo moeillijk. Een fout die ook nog eens spannings of temperatuurafhankelijk is, is zo praktisch niet meer op te sporen. Indien je deze tool dan voor meerdere projecten hebt gebruikt ben je goed het haasje. Meerdere jaren werk worden dan obsolete + vindt de fout maar eens....

Mijn mening: het is fantastisch maar blijf behoorlijk sceptisch over de resultaten, vergeet niet dat een simulatie van de synthese dezelfde fout bevat als de synthese en deze dus niet kan weergeven.

Ook blijft het belangrijk voordurend onderzoek te plegen naar verbeteringen van het programma omdat je anders technologisch op hetzelfde punt blijft hangen.

RickN @Verwijderd • 7 juni 2002 19:18

Hier ben ik het niet zo mee eens. Optimalisatie tools in het algemeen worden al jaren met veel succes gebruikt in chip design. De meeste stappen in het process dat Dirk Postma schetste zijn absoluut niet meer met de hand uit te voeren, daar zijn tools gewoon noodzakelijk. Daarnaast zullen de transformaties die zo'n tool toepast de functionaliteit niet aantasten, net zo als een compiler dat niet doet (binnen bepaalde optimalisatie grenzen.) In ieder geval is het mogelijk om het optimaliseren te beperken tot dergelijke transformaties. Mocht er toch een foutje in sluipen (wat dus eigenlijk uitgesloten is) zijn er tests genoeg om ze te vinden. Ze vinden het ook als er ergens een transistortje niet goed schakelt door een fabricage fout dussuh...

Die gasten van Magma waren laatst trouwens ook op de TU/e. Ik heb er zelfs nog mee geluncht (niet mee gepraat, ik was daar voor een promotie plaats en kwam toevallig met ze aan één tafel te zitten) Ik hoorde later van de mensen waar ik wel voor kwam dat ze het optimaliseren bij Magma veel gestructureerder aan aan het pakken zijn dan in de huidige pakketen. Ik kreeg de indruk dat we nog veel van die mensen kunnen verwachten.

Verwijderd @RickN • 9 juni 2002 19:13

Ik ga tot een bepaald niveau met je mee (ook ik gebruik soortgelijke tools) en ik begrijp dat deze processen geautomatiseerd moeten worden (kan ook niet anders gezien de complexiteit). Dat is mij allemaal wel duidelijk echter betwijfel ik dat je alle fouten die zo een tool zou kunnen maken kan testen zeker als je de identieke algorithmes gebruikt voor de synthese en de test. Een honderd procent werkende tool bestaat per definitie niet omdat de transformatie in software wordt beschreven en per definitie is software niet 100% testbaar.

Ook ga je er vanuit dat een transformatie in alle gevallen onfeilbaar is, dit vind ik een erg gevaarlijk statement.

"Ze vinden het ook als er ergens een transistortje niet goed schakelt door een fabricage fout dussuh..."

net zoals de eerste Pentium chips zeker (die met het rekenprobleempje). Bovendien kost het je een extra run naar de Foundry wat erg kostbaar is.

Wat ik wil zeggen met mijn verhaal is dat een 100% vertrouwen in dergelijke tools gevaarlijk is ...

Ik ben blij dat ze het bij Magma veel gestructureerder aanpakken helaas geeft ook dit geen 100% garantie. Het schrijven en ontwikkelen van dit soort tools blijft mensenwerk en dus per definitie feilbaar en ik blijf bij mijn statement : "fantastisch maar blijf sceptisch".

The Collector 6 juni 2002 20:40

mmm, iets voor AMD misschien, komen ze toch nog optijd met die hamer

Luxx @The Collector • 6 juni 2002 21:46

Ik mag toch hopen dat die hammer op papier inmiddels al wel werkt:-)

memphis @The Collector • 6 juni 2002 22:59

Misschien iets om over de Intel P4 te halen, kunnen ze de uitkomst direct als een P5 op de markt pleuren

dirkpostma 7 juni 2002 17:05

Visweswariah will present a paper at DAC on how to coordinate EinsTuner with manufacturing techniques, so that variations in manufacturing can be taken into account when tuned circuits are used widely in a design.
Cool...

Met Chandu V. drink ik tegenwoordig wel eens koffie

Hij is namelijk een paar maanden gastdocent aan de TU Eindhoven en toevallig ben ik momenteel in die groep een afstudeerprojectje aan het doen

Hele gave kerel! Hij moest wel 2 weken naar Amerika, en nu lees ik waarom (alsof ik dat nog niet wist ;-) )

Ik zal zo eens gaan reageren op een aantal reacties...

TMDevil

6 juni 2002 21:16

Ik denk eigenlijk dat we hiervan weinig te zien krijgen tenzij je een IBM chip gaat gebruiken... ik neem namelijk niet aan dat zo zo iets zo maar gaan verkopen....