Az Indilinx dili
A korábban szinte kizárólag memóriamodulokkal foglalkozó OCZ még 2009-ben indította útjára Vertex névre keresztelt SSD sorozatát; a családba tartozó meghajtókat a gyártó mind teljesítményben, mind árban a felsőkategóriába pozicionálta. Az SSD-piac rohamos növekedésével a vállalat tavaly év elején teljesen felhagyott a memóriák forgalmazásával, hogy összes erőforrásával a NAND flash alapú meghajtókra koncentrálhasson. Nem sokkal később ezt megerősítendő egy újabb nagy lépésre szánta el magát az OCZ, amikor felvásárolta a dél-koreai, Barefoot vezérlőlapkáról elhíresült Indilinxet. Az akvizícióval olyan értékes technológiákhoz jutott hozzá a gyártó, ami hosszútávon elengedhetetlen lehet az egyre ütőképesebb meghajtók fejlesztéséhez.
[+]
Természetesen a vállalatnak nem titkolt célja, hogy idővel az összes meghajtójában valamelyik, házon belül készített Indilinx vezérlő dohogjon. Az ominózus felvásárlás után tavaly novemberben meg is jelent az első ilyen meghajtó, mely az Octane nevet kapta. Ezen SSD vezérléséről az Indilinx Everest nevű chip gondoskodik, melyről sokáig azt gondolhattuk, hogy egy teljesen saját fejlesztés. Az igazságról a Vertex 4 megjelenése után hullott le a lepel, amikor hivatalos megerősítést nyert, hogy az Octane (és a Petrol) sorozatok gyakorlatilag az Intel 510 és Crucial M4 meghajtókból már jól ismert Marvell 88SS9174 chippel vannak szerelve. Természetesen azért akadnak különbségek, hisz a firmware legalább annyira fontos komponense egy ilyen meghajtónak, mint a kontroller, és ez viszont már teljesen házon belül született meg.
A vezérlő blokkdiagramja
Az új Vertex 4 esetében is hasonló a helyzet, bár ennél a sorozatnál már a Marvell legújabb, 88SS9187 típusjelzésű modelljét használta fel az OCZ, Everest 2 név alatt. A firmware itt is teljesen házon belül, a vállalt szája íze szerint készülhetett el. Érdekesség, hogy a vezérlőszoftverben egy kisebb gyári tuningot is alkalmaztak, amivel a Marvell által beállított 333 MHz-es alapórajelet 400 MHz-re emelték. A fenti diagramon látható, hogy a csatornák száma a SandForce-hoz hasonlóan itt is nyolc darabban merül ki. A firmware megalkotása közben az OCZ különösen nagy hangsúlyt fektetett a megbízhatóságra és az élettartamra; az ennek érdekében megszületett technológiákat Ndurance 2.0 gyűjtőnév alatt szedte csokorba a cég.
[+]
Mint azt jó néhányan már nyilván tudják, a SandForce egy tömörítő algoritmust használ, hogy a NAND lapkákba kevesebbet kelljen írni, ami egyrészt meggyorsítja a műveletet, másrészt kevesebb adat kevesebb cellát vesz igénybe, ami az élettartamra van jó hatással. Tömörítés nélkül (vagy tömöríthetetlen adat esetében) szinte mindig van egy bizonyos mértékű plusz művelet (overhead) írás közben. Ez jó esetben nem jelent túl nagy extra terhet az általunk okozott adatforgalmon túl, a kérdés csak az, hogy mekkora és milyen mértékű ez, tehát mennyi haszontalan írással számolhatunk. Itt pontos adatot ugyan nem közöl az OCZ, de állításuk szerint a minimálishoz közelire redukálták az értéket, tömörítés alkalmazása nélkül.
Teljesítmény és élettartam szempontjából sajnos a NAND lapkákra távolról sincs olyan pozitív hatással a csíkszélesség-csökkenés, mint a processzorokra. Az 50 nm-es MLC NAND lapkák még durván 10 000 írási ciklust viseltek el. Ez a szám 34 nm-en a felére, nagyjából 5000 környékére esett, míg 25 nm-en már csak 3000 körüli, és ha ez nem lenne elég, akkor még a szükséges hibajavítások (ECC) száma is drasztikusan nő a csíkszélesség csökkenésével. Ebből fakadóan a vezérlőknek egyre fejlettebb és hatékonyabb ECC algoritmusra van szükségük, hogy elboldoguljanak a legújabb lapkákkal is.
Erre született meg az úgynevezett Multi-Level ECC motor, mely a BCH (Bose-Chaudhuri-Hocquenghem) algoritmust alkalmazva akár 128 véletlenszerű bit korrekciójára is képes 1 kilobájtnyi adaton. Ez gyakorlatilag annyit jelent, hogy a kontroller képes lesz elboldogulni a 20 nanométeres NAND lapkák ilyen jellegű szükségleteivel is. Az Adaptive NAND Flash Managment, mely az írási műveletekhez szükséges feszültség finom szabályozásával és kifinomultabb jelfeldolgozással operál, szintén a NAND lapkák élettartamának maximalizálásáért került a rendszerbe. Végül még meg kell említenünk az RNA (Redundant NAND Array) technológiát, mely nem számít egy teljesen újkeletű megoldásnak. Ez a RAID 5 rendszerekhez némileg hasonló védelmet képes nyújtani, amennyiben egy cella vagy netán egy teljes NAND lapka használhatatlanná válna. Működésével blokkszinten csíkokra osztja (striping) a paritás információkat a meghajtóban található NAND lapkák között, hogy komolyabb probléma esetén az adatok még visszanyerhetőek legyenek.
Az Indilinx Everest 2 alapja
Végül, de nem utolsósorban a rendszerbe bekerült egy 256 bites AES titkosító motor is, mely a vezérlőn keresztül folyó összes adatot már kódolva írja ki a lapkákba.
A cikk még nem ért véget, kérlek, lapozz!
