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.