Főkonstruktőr

A számítógépeinkben használt mikroprocesszorokról – ha egyáltalán tudomást veszünk róluk – néhány világos szempont alapján szoktunk ítéletet mondani. Ilyen az általunk fontosnak tartott alkalmazásokban nyújtott teljesítmény, a fogyasztás és esetleg a túlhajthatóság. Hogy egy adott chip e szempontok szerint végül hogy teljesít, az azonban rendkívül sok tényezőtől – sőt véletlentől – függ. Ezek java részét a tervezés során meghozott döntések befolyásolják.

A tervezés és a gyártás folyamatáról azonban többnyire csak keveset tudunk, talán azért is, mert a nagy bonyolultságú integrált áramkörök fejlesztésének és előállításának Magyarországon nincs hagyománya. Ennek ellenére dolgoznak olyan szakemberek hazánkban, akik közeli kapcsolatban állnak e területtel. Egyiküket, Fischer Eriket, a Sun Microsystems Kft. műszaki igazgatóját kérdeztük arról, hogy hogyan is készülnek a komplex processzorok.

Egy mikroprocesszor útja az ötlettől a megvalósításig alighanem hosszú. Hol kezdődik?

Egy új, nagy teljesítményű processzor tervezése időigényes folyamat, általában 3-5 évet vesz igénybe. A munka úgy indul, hogy összeáll egy öt-hat fős team, egy főkonstruktőr (chief architect) és még négy-öt olyan szakember, akiknek már van tapasztalata a CPU-tervezésben.

Mi az ő feladatuk? Az általános irányvonalak – például hogy többmagos vagy többszálú legyen a chip – meghatározása?

Igen, ők fektetik le a fő irányvonalakat. Ez körülbelül egy 40 000 paraméteres tervezési tér, amelyben szimuláció nélkül lehetetlen mozogni. Hogy egy egyszerű példát mondjak: a cache-tervezés önmagában 40-50 paraméter. Ezeket kell úgy összerostálni, hogy az előző generációhoz képest legalább egy kétszeres szorzót kapjunk.

Teljesítményben?

Igen, teljesítményben. A tervezés indulásakor minden új processzortól azt várják, hogy legalább 100 százalékkal teljesítsen jobban a korábbi generációnál.

Ebben a fázisban elemzik azokat az ötleteket is, amelyek az egyetemeken előkerültek. Az akadémiai elképzeléseknek azonban az az előnye, ami a hátránya: nem kell őket szilíciumban megvalósítani. A szakirodalomban leírt megoldások körülbelül 90 százaléka használhatatlan, mert a kivitelezésük fizikailag lehetetlen. Azaz amikor eljutunk odáig, hogy 90, 65 vagy 45 nanométeres technológiával meg kellene effektíve csinálni őket, kiderül, hogy ez lehetetlen. Hiába, ma a tudományos életben a szimulációs munkák igen ritkán jutnak el odáig, hogy az ötleteket ilyen alacsony szinten is modellezzék.

Ettől függetlenül nem kell azt gondolni, hogy a kutatás fölösleges, hiszen ahogy telik az idő, fejlődik a gyártástechnológia, a teóriák úgy csorognak vissza a tervezésbe. Nagyon sok jó ötlet születik, amelyeket részben vagy egészben föl lehet használni a gyakorlatban.

Tehát a kurrens tudományos eredmények mérlegelése is része ennek a stációnak?

Természetesen. Ez egy egy-két éves gondolkodási folyamat, amelyet a nagy cégeknél segít az, hogy komoly tapasztalatokra lehet támaszkodni, mert mindennek van előélete. Elengedhetetlen például, hogy legyenek releváns minták arra vonatkozóan, hogy hogyan működnek az alkalmazások egy adott processzoron. Ezeket általában ún. trace-ekkel vizsgálják, melyek egy adott alkalmazás utasításfolyamának a mintái – például egymilliárd utasítás egy Oracle-benchmarkból. Ilyen alkalmazásszeleteken próbálják felmérni egy későbbi fázisban azt, hogy mire lesz képes az új processzor a jelenlegi chipekkel összehasonlítva.

Ezek megléte tehát feltétele a tervezési munka megkezdésének?

Így van. Ennek az infrastruktúrának a felépítése, ha nulláról kellene kezdeni, hónapokat venne igénybe, de a processzortervezéssel foglalkozó nagy cégeknél mindez már adott. Így indulhat meg az az egy-két éves koncepcionális tervezés, amelyről beszéltem. Ezt követően a team fölszaporodik körülbelül 20-30 emberre – persze a létszám gyártótól függően változhat. A Pentium Pro esetében például a szimulátor mindössze hat ember munkája volt.

Nagyjából ez volt az az időszak, a P5 (Pentium) és P6 (Pentium Pro) architektúra között, amikor a néhány százezres tranzisztorszám hirtelen több millióra ugrott...

Ez igaz, de félrevezető is egyben, mert ezeknek a tranzisztoroknak a java része memória. Annak a tervezése viszont rendkívül egyszerű, mert csak hattranzisztoros cellákat kell egymás mellé pakolni, hiszen a gyorsítótárakban használt SRAM egy bitje – általában – hat tranzisztorból áll. Ebből már lehet kalkulálni. Persze a redundanciát is bele kell számolni, mert redundancia nélkül ma nem lehet gyártani. Ez is egy tervezési paraméter, hogy mekkora redundanciára van szükség.

Azaz eleve több memóriát tesznek a processzorba?

Persze. Minden esetben több cache van a processzorban, mint amennyit használnak, a többit deaktiválják. És az mindig komoly kérdés, hogy mennyi legyen a redundancia. A mai, több megabájtos cache-ek esetében gyártótól függően ez néhány százaléktól tíz százalékig terjed. Erre azért van szükség, mert a gyártásnak van egy haranggörbéje. Amiből a legtöbbet akarják gyártani, azt kell a haranggörbe közepére pozicionálni, hogy az garantáltan jó legyen. Pontosan annyi redundanciát terveznek hozzá, amennyi ehhez szükséges. Mert mindegyik chipen van hiba. Ma a fejlett gyártástechnológiával gyártott, 130-140 négyzetmilliméternél nagyobb integrált áramkörök mindegyikében van gyártási hiba. Ezek nem fatális hibák, de mivel a cache nagy felületet foglal el, nagyobb eséllyel is lesz hibás – ezért fontos a redundancia.

Út a maszkig

Visszatérve a tervezés folyamatára, a 20-30 főre bővült csapatra milyen feladat vár?

Ez a team készíti el az ún. ciklushelyes szimulátort, amely pontosan úgy viselkedik, mint ahogy a processzor fog: képes utasítások feldolgozására, programok futtatására. Egy jól megírt szimulátoron be lehet bootolni egy operációs rendszert, lehet futtatni egy Solarist például.

A szimulátor maga jellemzően egy elosztott rendszeren fut, a Sunnál 2000 gépből áll ez a farm. Az egyenértékű órajel azonban még így is csak néhány megahertz közelében van, ami jól mutatja a ciklushelyes szimuláció óriási erőforrásigényét. Ezen az elosztott rendszeren futtatják – operációs rendszeren vagy közvetlenül – azokat a trace-eket, amelyeket begyűjtöttek, és vizsgálják, hogy milyen gyorsan dolgozik a processzor, hogyan működnek az egyes komponensek. Az eredmények alapján pedig úgy módosítják az eredeti terveket, hogy a kívánt célkitűzésekhez közelebb kerüljenek. Amikor aztán sikerül elérni egy többé-kevésbé elfogadható konszenzust a teljesítmény szempontjából – és ebbe nemcsak a mérnököknek van beleszólása, hanem a menedzsmentnek és a marketingnek is –, elkezdődhet a tényleges fizikai tervezés.

Ekkor a tervezőgárda létszáma fölszalad több száz emberre, akik együtt dolgoznak a chip gyártásával megbízott félvezetőgyártóval. Ezért nem olyan triviális a gyártóváltás, ahogy sokan gondolják. A fórumokban gyakran felmerül az az érv, hogy ha az egyik gyártó nem tudja elkészíteni a chipet, majd legyártatják egy másikkal. Egy ilyen váltás legalább egy évet vesz igénybe, és egyáltalán nem is biztos, hogy sikeres lesz. Mert ahány gyártó, annyiféle gyártási technológia létezik, aminek az elérhető frekvenciában, disszipációban és számos más tekintetben is vannak következményei.

Gondolom, az sem mindegy, hogy a processzort tervező cégnek van-e saját gyára...

Ez nem számít. Ebben a fázisban, amikor a több száz fős mérnökcsapat logikai áramkörök – de még mindig nem tranzisztorok – szintjén megalkotja a processzort, már csak úgy lehet dolgozni, hogy tudják: ki fogja a chipet legyártani. Itt ugyanis már a gyártó ún. libraryjeit, elektronikai könyvtárait kell felhasználni a munka során.

Ma egyébként mindenki azt gondolja, hogy az Intelnek van a legjobb technológiája. De ez nem igaz – ma már nem. Ma a tajvani cégek, a TSMC, a UMC és a többi távol-keleti gyártó lényegesen jobb technológiát tud felmutatni. Sokkal hamarabb volt például működőképes 65 nanométeres gyártásuk, és most már kacsingatnak a 45 nanométer felé. Meglehet, hogy az Intel készített először 45 nanométeren labormintákat, de a nagy bonyolultságú integrált áramkörök sorozatgyártásában valószínűleg nem ők lesznek az elsők.

Ez egy új fejlemény. Néhány éve még az IBM volt az egyik, ha nem „a” legfejlettebb félvezetőgyártó, a Sun is gyártatott velük chipeket. Akkoriban próbát tettünk a tajvani gyártókkal is. Volt egy olyan processzorunk, amelyet az egyik tajvani szerződéses gyártóhoz igazítottunk, de végül nem tudták legyártani – csúfos kudarc lett a vége. Ez mára megváltozott. Az NVIDIA és az ATI is megmaradt a tajvani szerződéses gyártóknál, pedig ma már a grafikus processzorok esetében is beszélhetünk 700 millió tranzisztorról. Most tehát láthatóan ott megy a legjobban – hogy ez így marad-e, az más kérdés.

Erről valóban ritkán hallani. De térjünk vissza a processzortervezés folyamatához! Megvolt tehát a ciklushelyes modell...

Igen, mondjuk C-ben. Ekkor a több száz fősre duzzadt dizájnteam valamilyen hardverleíró nyelven – leggyakrabban Verilogban – elkészíti a processzor modelljét. A Sun Niagara esetében a funkcionális és viselkedésbeli modell forrása – amely publikus, bárki által letölthető – tömörítve körülbelül 2, kitömörítve 5-6 megabájt. Ebben vezetékek, multiplexerek és ehhez hasonló viszonylag kis egységek szintjén van modellezve a processzor.

Kétmagos processzorok a szilíciumszeleten (Fotó: Sven Döring, AMD)

Ennek alapján el lehet készíteni a chipet?

Igen. A Verilog kódot be kell töltetni egy elektronikus tervezésautomatizálási (EDA) eszközbe, amely tudja azt olvasni. Ehhez szükség van a gyártó összes libraryjére is. Ha mindez megvan, el lehet készíteni a levilágításhoz szükséges maszkot. De a maszk elkészítése előtt akad még tennivaló: például ellenőrizni kell a chipet jelintegritás, jel-zaj viszony szempontjából, és egyáltalán meg kell vizsgálni, hogy úgy működik-e, ahogy terveztük. És akkor iterálunk. Ha kiderül például, hogy nem lehet elérni a 2 GHz-es működési frekvenciát, fel kell tenni a kérdést: vajon elfogadható-e az 1,8 GHz? És így tovább. Ez egy játék, egy néhány éves játék.

Néhány éves?

Bizony. A koncepcionális tervezés egy-két évet vett igénybe, ez a stáció pedig még legalább másfél év – ha nem merül fel komolyabb probléma. Ha igen, akkor tovább nyúlik a folyamat.

Ebben a fázisban már mérnökök dolgoznak?

Áramkör-technológiai mérnökök, olyan emberek, akik integrált áramköröket tudnak tervezni, ismerik a modellező szoftvereket, a Verilogot, és tudják, hogy a tranzisztorok szintjén hogyan lehet megvalósítani a chipet. Ilyen szakembereket nálunk a Műegyetem mikroelektronikai, technológiai tanszékén képeznek. A belőlük álló több száz fős csapatnak körülbelül másfél-két éves munka elkészíteni az ún. tape-outot. Ez alapján készül el a maszk, amelyet le lehet adni a félvezetőgyártónak. Aztán pedig bízni kell abban, hogy a chip működni fog, és viszonylag kevés hiba maradt benne.

Ha jól tudom, a gyártás hetekig tart?

Hónapokig. A gyártási folyamat általában egy-két hónap.

Egy tesztpéldány elkészítése például...

...két hónap, tipikusan két hónap. A Sunnál – ez publikus információ – január 5-én volt a Rock tape-outja, március közepén érkeztek meg az első minták. De a minta elkészítése ennél tovább is elhúzódhat, mert a gyártási tervbe be kell illeszteni a tesztchipet, hiszen csak úgy nem kopoghatok be a maszkokkal. Ezért előfordulhat, hogy egy-két hónapot is kell várni arra, hogy egyáltalán megkezdjék az önmagában is két hónapig tartó gyártást. Ez a mai csúcsprocesszorok – akár a Core 2 Duo, akár az Opteron, a Power vagy a SPARC – esetében ennyi időt vesz igénybe.

Természeténél fogva hibás

Egy tape-outból azonnal lehet működő processzor?

Szerencsés esetben igen. A processzor próbája az ún. bring-up, amely egy meglehetősen delikát folyamat. A Sunnál például az év elején készültek el a kétchipes SMP módon is működni képes és összesen 128 programszálat kezelő Victoria Falls mintái. Ott a bring-up első fázisában egy IC-t, egy magot és egy programszálat teszteltek. Amikor ez működött, következett az egy IC, egy mag, négy programszál. Majd egy IC, két mag, magonként egy programszál, és így tovább. Ez a folyamat néhány napig is eltart – a konkrét esetben másfél nap volt.

Ez egy apró lépésekből álló folyamat, amelynek során fokozatosan kapcsolják be az egységeket. A cache-t ilyenkor általában nem használják. Ma már az is egy fontos tervezési szempont, hogy a cache-ek degradálhatóak legyenek, hogy akár gyorsítótár nélkül is el lehessen indítani az áramkört, hiszen validálni elsősorban nem a memóriát, hanem a funkcionális egységeket kell. De ezeket is le lehet kapcsolni, egyáltalán mindent, ami a bring-upnál nem feltétlenül szükséges.

De még ha a chip működik, akkor is rengeteg hiba lehet benne. A Sunnál általában 80-100 hiba az általános, de valószínűleg máshol is ez a nagyságrend.

Az Intel és az AMD szokta is ezeket publikálni...

Nem azokat, amelyek még a tervezés közben kerülnek elő, hiszen itt még csak az első tape-outról beszélünk. És általában van még egy második is, ez az, amelyik – ha minden jól megy – gyártásba kerül. Ha nagyon komoly gondok kerülnek elő az elsőben, akkor további tape-outokra van szükség, amelyeket 1.1, 1.2 elnevezéssel látnak el. Általában a 2.0-sból vagy valamelyik későbbi tape-outból készül a végleges IC.

A kisebb bugokat ilyenkor nem javítják már – ezeket szokta publikálni az Intel és az AMD. Ezek a hibák általában szimulátorban jönnek elő, nem a gyakorlatban, például azért, mert valódi alkalmazásokban a fordító egyszerűen nem generál ilyen utasításszekvenciát. Erre nagyon jó példa az első UltraSPARC-generáció, amely 143-200 MHz-es tartományban működött. Ezeknek a chipeknek van egy olyan hibája a memóriakezelő egységben, amely csak 64 bites Solaris-kernel használata esetén jön elő. Ezért ezeket a processzorokat a Sun – amíg támogatta – csak 32 bites kernellel támogatta. Pedig a hiba csak szimulátorban került elő, egy kvázi értelmetlen utasításszekvencia esetében, igaz, ilyenkor a processzor gyakorlatilag lefagyott, csak ki-be kapcsolással lehetett megoldani a problémát. A gyakorlatban azonban nem volt olyan fordítóprogram, amelyik ilyen utasításszekvenciát generált volna, főként azért, mert a memóriakezelő egységet kellett vezérelni, ezt pedig az operációs rendszeren kívül más nem teszi. Nos, ilyen hibákat benne szoktak hagyni a chipben.

Az egyik régebbi gépem egy Ultra 1 munkaállomás volt, amelyben egy ilyen 167 MHz-es processzor működött, és nyolc év alatt egyszer nem futottam bele a bugba annak ellenére, hogy mindig 64 bites kernellel futtattam, sőt fejlesztés alatt álló kerneleket teszteltem rajta. Vagyis van ilyen hiba is. De van olyan is, amelyik adatvesztéssel vagy adatkorrupcióval jár. Az igen komoly probléma, azokat mindenképpen ki kell javítani.

Mint a Pentium-bug?^*

Az egy tervezési probléma. A Pentium Pro főkonstruktőre, Robert Colwell – aki időközben már otthagyta az Intelt – írja a könyvében, hogy ez a hiba egyszerűen abból adódott, hogy menet közben megváltoztatták a tesztmintákat, és ezért ennek a funkciónak a tesztelése kimaradt. Ez egy rosszul megtervezett tesztszekvenciának volt az eredménye. Mivel a chipeket és a teszteket is emberek tervezik, ilyesmi előfordul. Itt sem ez volt a probléma, hanem az, hogy az Intel ezt megpróbálta takargatni.

Úgy tudom, mire a bug nyilvánosságra került, már ki is javították...

Erre vannak az ún. steppingek, chiprevíziók. Ilyeneket főként az Intel és az AMD készít. A Sunnál ez nem jellemző; ritkán előfordul ugyan, de nem annyira a hibák, mint inkább gyártástechnológiai váltás teszi szükségessé a steppingek kiadását. Kétségtelenül megvan annak az előnye, ha egy cég kezében van az operációs rendszer, a hardver és a processzor is. Meg lehet nézni a Solaris-kernel forrását: ebben vannak olyan megjegyzések, hogy az itt következő szoftverfixek ennek és ennek a hardverhibának a javításai. Például egy versenyhelyzetet el lehet kerülni egy időzítéssel, amely ugyan lelassítja az operációs rendszert, de nem történik adatvesztés. Az ember inkább kiad egy kernelpatchet, mint visszahív egymillió processzort. A mi esetünkben éves szinten egymillióról beszélünk, az Intelnél nyolcvan-száz millióról.

Az Intel és az AMD BIOS-ban is szokott hibákat javítani.

A PC-n ez az elsődleges interfész, amellyel kommunikál az operációs rendszer, ezért a hibákat ott is lehet javítani. De van a processzorokhoz letölthető mikrokód is, ott is történhetnek javítások. A gyártók ezeket a kerülőutakat a volumen miatt eleve beletervezik a chipekbe: ilyen mennyiségű eladásnál a hibákat flexibilisen kell tudni javítani, hogy – ha lehet – ne kelljen a terméket visszahívni.

Tehát általában 80-100 körül van hibák száma a processzorokban...

Igen, és ezek remélhetőleg viszonylag jelentéktelen hibák. Ha nem, ha komoly bugokat találnak, akkor készíteni kell egy közbülső tape-outot is, egy 1.1-est vagy még egy 1.2-est is. Egy tape-out legyártása két-három hónap, a hibás tervezés tehát darabonként ennyi késéssel jár. Így jutunk el végül a 2.0-ig, amelyből legyártják a kereskedelmi forgalomba kerülő processzorokat.

Ezek után a csapat létszáma ismét lecsökken, 50-100 emberre – az ő dolguk a karbantartás, a menet közben felfedezett hibák és az egyéb problémák kezelése. Ezek a szakemberek mind részt vettek a chip tervezésében, ezért ki tudják javítani a bugokat. Az ő munkájuk eredményeként készülnek az újabb steppingek.

De steppingek kiadására sor kerülhet akkor is, ha például a gyártó cég módosított valamit a gyártási technológián. Ez annyira szorosan összefügg a tervezéssel, hogy ilyenkor a terveket hozzá kell igazítani a változtatásokhoz, sőt az is lehet, hogy emiatt bizonyos dolgokat fizikailag át kell tervezni a processzorban. Merthogy itt mindig a gyártástechnológia határán mozgunk. Én ezért szoktam a processzortervezést tour de force-nak, erőgyakorlatnak hívni.

A módosítások pénzügyi vonzata sem elhanyagolható, gondolom.

A maszkok ára 90 nanométernél egymillió dollár körül van – egy maszké. 65 nanométernél ez 1,2 millió dollárra, 45-nél pedig közel kétmillió dollárra szökik fel.

A processzortervezés tehát nem olcsó mulatság...

Úgy szokták becsülni, hogy egy ötéves CPU-tervezési projekt nagyságrendileg 100-200 millió dollárba kerül. Nagyságrendileg. Nem véletlen, hogy processzortervezéssel ma már viszonylag kevesen foglalkoznak.

Barna József

^*Az Intel Pentium processzorok első szériájának súlyos hibája, amelynek folytán egyes lebegőpontos osztások elvégzésekor hibás eredményt adott vissza a chip. Az 1994-ben felfedezett bug a processzort készítő Intelnek a termékcseréknek és a megsemmisített készleteknek köszönhetően 475 millió dollárjába került.