Elektronika, 5. gyakorlat: algoritmikus C szintézis Bevezetés A digitális elektronikai rendszerek bonyolultsága és a gyors technológiai fejlődés folyamatos kihívás elé állítja a tervezőket, mert a tervezési módszereknek is fejlődniük kell a technológia fejlesztésének sebességével. Emiatt a tervezés egyre magasabb szinten történik, amelyből automatikus eszközök végzik az alacsonyabb szintű reprezentációk előállítását. Egy integrált áramkör esetén a legalacsonyabb szintű reprezentáció az ún. layout, amely nem más, mint az egyes rétegeken megvalósított alakzatok geometriai leírása, ennek segítségével közvetlenül készíthetők el az egyes litográfiai lépésekhez szükséges maszkok. A tervezés azonban sokkal magasabb szinten kell, hogy történjen, valójában layout-ot csak analóg CMOS áramkörök esetében terveznek kézzel. Digitális rendszerekben a tranzisztor szintű tervezést viszonylag hamar felváltotta a kapu szintű tervezés, majd az 1990-es évektől kezdve gyakorlatilag a digitális tervezés egyet jelentett a rendszer valamilyen hardver leíró nyelven (a továbbiakban HDL, pl. Verilog, VHDL) történő leírásával, innentől kezdve viszont a tervezés teljesen automatikusan történik. A hardver leíró nyelvű leírásból logikai szintézissel kapjuk meg kapuszintű reprezentációt, a kapukat a chip felszínén automatikus eszközök elhelyezik és összehuzalozzák, ez a folyamat az ún. place and route. Ez a folyamat teljesen automatikusan történik, a tervező által felügyelt határok között, általában több iterációs ciklusban. A hardver leíró nyelvek sajátossága, hogy szinkron hálózatok tervezésére alkalmasak, amely regiszterekből és kombinációs hálózatokból áll. A logikai szintézis csak a hardver leíró nyelv egy szűkebb részhalmazából képes a kapuszintű leírást előállítani. Ez a szint az ún. register-transfer-level (RTL) szint, amely leírja az adatfolyamot a regiszterek között. A hardver leíró nyelven történő reprezentáció hátránya, hogy egyben az architektúrát is meghatározza. Tekintsünk például egy egyszerű példát, adjunk össze négy számot. Ezt a feladatot megoldhatjuk pl. három kétbemenetű összeadóval, de megoldhatjuk egy akár összeadóval is, ha a működést három órajelciklusra bontjuk szét. Nyilvánvaló, hogy az első megoldás gyors lesz, a második megoldás pedig erőforrás takarékos. Az architektúra későbbi megváltoztatása a hardver leíró nyelven történt leírás megváltoztatásával jár. Az előbbi példánál maradva, az egy összeadót tartalmazó megoldáshoz állapotgépet (FSM) is kell készítenünk. Hamar felmerült az igény, hogy a rendszert még magasabb szinten leírva, a tervező által kiválasztott architektúrájú HDL leírást automatikusan lehessen elkészíteni. Ez az ún. magas szintű szintézis, vagy más néven algoritmikus szintézis vagy viselkedési szintű szintézis. Ezek az eszközök az elmúlt néhány évben érték el azt a fejlettségi szintet, hogy általános célra használni lehet és képesek a hagyományos, HDL alapú eszközök kiváltása. Általában C/C++ nyelvű leírásból generálnak RTL szintű leírást, és eközben az architektúra kiválasztását a tervezőre bízzák. 1
Szinte minden neves EDA (Electronic Design and Automation) szoftvergyártó cég kidolgozta (megvette/kiszervezte stb.) a magas szintű C alapú szintézis eszközét: C-to-Silicon / Cadence Design Systems Catapult C / Calypto Synplicity C Compliler / Synopsis A C/C++ nyelv optimális választás a magas szintű leírásra, mivel 1. Kellően alacsony szintű programozási nyelv ahhoz, hogy a működést hardver szintre le lehessen bontani, de jóval egyszerűbb, mint a hardverleíró nyelvek többsége. 2. Másrészt nagymennyiségű, létező C kód áll rendelkezésre, így a korábbi, szoftveres megvalósítások (DSP, mikrokontroller stb.) hardverre portolása gyorsabb. A C/C++ nyelv egyetlen hátránya, hogy nem lehet pontosan reprezentálni az adatok bitszélességét, ami viszont a hatékony hardvertervezéshez elengedhetetlenül szükséges. Ezt a problémát a C++ eszközeivel lehet kezelni, és saját, megadott szélességű egész, illetve fixpontos valós számok megvalósítására megfelelő osztálykönyvtárak állnak rendelkezésre. A továbbiakban a C ill. C++ jelölést szinonimaként használjuk (hasonlóan a szoftvergyártók elnevezéseihez), mivel valójában nagyrészt C kódról van szó, a C++ eszközeit mindössze a tetszőleges hosszúságú adattípust megvalósító osztályok és a hozzá tartozó operátorok és sablonok használják, osztályhierarchiát, virtuális függvényeket és hasonlókat egyenlőre még ezektől az eszközöktől nem várhatunk el A C++ nyelv megfelelő osztálykönyvtárak használatával képessé tehető a digitális rendszer működésének pontos leírására. (itt a pontos leíráson azt értjük, hogy a leírás bit és késleltetés szinten teljes), ez az ún. System-C. Így lehetőség nyílik egy teljes rendszer hardver és szoftver komponenseinek egyidejű, a lefordított kód miatt gyors és magas szintű tesztelésére. Jelen segédanyagban meg sem kíséreljük sem a System C, sem a magas szintű szintézis alapjainak tudományos igényességű ismertetését, mindössze egy mintapéldán bemutatjuk a szintézis menetét és főbb jellegzetességeit, a Cadence cég C-to-Silicon termékének segítségével. A gyakorlat inkább bemutató jellegű, előkészített scriptek segítségével zajlik. 2
Mintapélda, egy egyszerű shift regiszter Tervezzünk meg egy egyszerű soros-párhuzamos átalakítás magas szintű leírását! A shift regisztert digitális technika tanulmányai alapján kapuszinten könnyen meg tudná valósítani és a Mérés Laboratóriumban megismert Verilog hardver leíró nyelven le is tudná írni. Legyen a shift regiszter az egyszerűség kedvéért 16 bites, az enable engedélyező jel hatására a serial_in bemeneten érkező bitet órajelenként shifteli. A reset szinkron, és alacsony aktív. A Verilog leírás RTL szinten valahogy így nézne ki: module shiftreg(input clk, input rst, input enable, input serial_in, output reg[15:0] data); always @(posedge clk) if (~rst) data <= 16'd0; else if (enable) data <= { data[14:0], serial_in ; endmodule Látható, hogy az adatfolyamot pontosan leírtuk, azaz pontosan definiáltuk, hogy az órajel felfutó élének hatására a kimeneti regisztert nullázni kell, ha a reset bemenet magas, ellenkező esetben pedig, ha a shift regiszter engedélyezett, a benne tárolt adatokat egy bittel balra léptetjük, majd a kimenet 0. bitjére a beérkező serial_in adatot másoljuk. Ezt a funkciót megvalósító függvényt C-ben valahogy így készítenénk el: unsigned short shiftreg( bool enable, bool serial_in, unsigned short data) { return enable? ( (data<<1) serial_in) : data; A következőket vehetjük észre: A függvény teljesen szabályos C++ kód, semmiféle kiterjesztés, szabványon kívüli eszköz, pragma stb. nincs benne, bár kihasználtuk, hogy a short pontosan 16 bites. A bit adattípust a C++ bool adattípusával reprezentáltuk. A működést egy függvény írja le meg, ezt a függvényt C eszközökkel tesztelhetjük, sokkal kényelmesebben, mintha HDL-ben tennénk. A bemeneteket érték szerint adjuk át. A kimenetet visszatérési értékként kapjuk. (vagy pointer ill. referencia) A következő lépés az, hogy ezt a C függvényt beburkoljuk, azaz készítünk egy System C osztályt, ami bit szinten definiálja a hardver portjait, azaz a be és kimeneteit. Egy ilyen burkoló osztály a következőképpen nézhet ki: 3
#include <systemc.h> #include "shiftreg.h" #ifdef _DEBUG #include <iomanip> using namespace std; #endif SC_MODULE(shiftreg_sc) // az SC_MODULE valojaban // egy sc_module-bol szarmaztatott osztaly { // input portok sc_in<bool> reset; sc_in<bool> enable; sc_in<bool> clk; sc_in<bool> serial_in; // output port sc_out<sc_uint<16> > shftreg; // belso regiszter unsigned short reg; // ez a fo metodus, amiben a mukodes zajlik. Ebben hivjuk meg az "eredeti" // C kodot. void shiftreg_cthread() { while (1) { if (reset.read() == 0) { reg = 0; // alacsony aktiv reset else { // az "eredeti" C kod meghivasa reg=shiftreg(enable.read(), serial_in.read(), reg ); // az eredmeny kiirasa shftreg.write(reg); #ifdef _DEBUG // az stdoutra a tesztelo kod cout << setw(10) << sc_time_stamp(); cout << setw(2) << enable; cout << setw(2) << reset; cout << setw(2) << serial_in; cout << setw(8) << hex << reg << endl; #endif wait(); // konstruktor SC_CTOR(shiftreg_sc) { // ez lesz a mukodest leiro metodus SC_CTHREAD( shiftreg_cthread, clk.pos()); // az orajel felfuto elere lesz erzekeny a modul ; #ifdef CTOS SC_MODULE_EXPORT(shiftreg_sc); #endif A működés a kommentek alapján nagy vonalakban követhető. Az sc_in<> és sc_out<> template-ek szolgálnak a hardware portjainak definiálására, a működést pedig egy ún. clocked thread írja le, ami egy szekvenciális hálózat leírására szolgál. (Ez nem operációs értelemben vett szál, hanem a SystemC 4
eseményvezérelt szimulációs kernele ezeket a metódusokat egy szimulációs időlépésben futtatja le.) Ez a szál az órajel felfutó élére érzékel egy eseményt, majd kiszámítja az eredményt. A szálban most az eredeti shiftregisztert megvalósító egysoros függvényt hívjuk meg, de könnyű elképzelni, hogy tetszőleges bonyolultságú C kód, pl. egy teljes JPEG dekóder beilleszthető. A szál egy végtelen ciklus, melynek végén a wait() fog várni az órajelre. A _DEBUG definiálásával a standard outputra kiírathatjuk a shiftregiszter állapotát. A System C modulunkat úgy tesztelhetjük, hogy példányosítjuk, a bemeneteket bekötjük és pl. a main függvényből jeleket kényszerítünk. Ez nem túl elegáns megoldás, mert teszteléshez érdemes lenne egy tesztelésre szolgáló modult, egy ún. testbench-et létrehozni, viszont egyszerűbb. Ez a működés jól követhető a letölthető anyagban lévő main.cpp file-ban. Fontos megérteni, hogy itt maga a lefordított FUTTATHATÓ FILE a SZIMULÁTOR! Az eredmény pedig tetszőleges lehet, van lehetőség hullámforma kimenetre is, a példa ezt is tartalmazza, de valójában bármi lehet. Tehát pl. a JPEG dekóder tesztelésekor a kimenet egy png file is lehet, amit a referencia képpel összehasonlítva tesztelhető, értékelhető a dekóder működése. A shiftregiszter esetében jól járunk a hullámforma kimenettel, de bonyolultabb rendszer esetén a tesztelés, hibakeresés, verifikáció magasabb szinten könnyebb. Ha a teljes rendszert sikerül System C nyelven leírni, akkor egy szinte tökéletes szimulációs eszközhöz jutunk. A rendszer főkonstruktőre azonosíthatja a gyenge pontokat, szabadon dönthet az egyes modulok hardver vagy szoftver megvalósításáról, mindezt egy C fordító és egy osztálykönyvtár segítségével. (gonosz megjegyzés: ingyen! bár a kereskedelmi szimulátorok általában gyorsabbak ) Mintapélda, 1. lépés C -> Verilog RTL Lépjünk be az src alkönyvtárba, fordítsuk le a kiadott kódot (make) és teszteljük a működést! Konvertáljuk a hullámforma kimenetet wlf formátumba, majd nézzük meg QuestaSim szimulátorral: /soft/mentor/mentor.sh vcd2wlf wave.vcd wave.wlf /soft/mentor/mentor.sh vsim & Töltsük be a wave megjelenítőbe a konvertált file-t és ellenőrizzük a működést! 5
1. ábra: a jelformák a QuestaSimben Remélhetőleg megfelelőnek találjuk és döntsünk úgy, hogy ez a modul hardware megvalósítást érdemel. Első lépésként egy magas szintű szintézis eszközzel a SystemC modulból RTL szintű, Verilog nyelvű leírást készítünk. Lépjünk vissza az src könyvtárból és indítsuk el terminálból a C-to-Silicon programot: /soft/cadence/run018.csh ctosgui & Írjuk be a parancssori beviteli mezőbe, hogy 2.ábra: A C-to-Silicon Compiler source ctos.tcl 6
Az előkészített script szintetizálni fogja a C kódot, majd megjeleníti. A gyakorlatvezető segítségével vizsgálja meg a Verilog kód működését! Mintapélda, 2. lépés Verilog RTL -> kapuszintű leírás A következő lépés a logikai szintézis: a register-transfer-level szintű leírásról áttérünk a strukturális leírásra, azaz összekötött valódi logikai kapukra. Ehhez a Cadence cég Encounter RTL compiler nevű programját használjuk. A ctos.tcl script generált egy rc.tcl scriptet. Nyissuk meg ezt a scriptet egy editorban (pl. gedit) és töröljük ki az utolsó sort (exit). Indítsuk el az RTL compilert! /soft/cadence/run018.csh rc -gui -files rc.tcl Az előkészített script alapján el fog készülni a strukturális leírás. A gyakorlatvezető segítségével nézze meg, hogy milyen időzítésekre lehet számítani, milyen kapukat használt fel a logikai szintézer a megvalósításhoz, stb. 3. ábra: Az RTL compiler által generált kapcsolási rajz 7
4. ábra: A felhasznált kapuk és a statisztika Az időzítési problémákra való figyelmeztetéssel ne törődjünk, egyrészt csak warning és mi tudjuk mit csinálunk, másrészt jogos: nem specifikáltuk sem a bemenet felfutását, sem pedig a modul kimenetének kapacitív terhelését. Ilyenkor az alapértelmezett értékekkel számol ez viszont a valóságban, ahol a helyzet nem biztos, hogy ilyen kedvező időzítési problémákhoz vezethet. Itt megállunk, a következő lépés a kapuk elhelyezése (place) és huzalozása (route) lenne az IC tervezésben. A kész, elhelyezett kapukat tartalmazó áramkört visszafejtve már pontos késleltetési információkhoz jutunk. Itt ellenőrizni kell, hogy a működés megfelelő-e, ha nem új kényszerítő feltételek mellett újra kell szintetizálni, majd elhelyezni és huzalozni az áramkört. Az RTL compiler elállíthatja az indító terminált. Gépeljük be vakon, hogy reset +enter, ez helyrehozza. 8
Feladatok Oldja meg a gyakorlatvezető által kijelölt feladatot! A kiadott kódot módosítsa, de a függvény neveken NE VÁLTOZTASSON. ( Paramétereket, adattagokat lehet változtatni, de a shiftreg és a shiftreg_cthread függvénynév maradjon meg különben változtatni kell a szintézis script-en, vagy kézzel kell szintetizálni ez sem bonyolult... de maradjon az egyszerűbbnél.) Tanácsok és kérések Ha állapotváltozót vesz fel, akkor az osztályban helyezze el és a függvénynek referenciaként adja át. (static nem szintetizálható) Csak standard C-t használjon, pl. a 0b111 alakú konstans megadást a GCC elfogadja, a CtoS nem. Ne felejtse el átírni a tesztelő kódot is a main.cpp file-ban. Addig NE IS PRÓBÁLKOZZON SZINTÉZISSEL amíg a SystemC modell nem működik helyesen. Amint egy eszközzel a munkát befejezte, lépjen ki belőle, hogy a licensz felszabaduljon. 1. KITT Reset hatására a shiftregiszter értéke 0x1 legyen! Az órajel felfutó élére a shiftregiszter egyet lépjen balra egészen az utolsó bit-ig, majd forduljon meg és az egyes bit most jobbra vándoroljon, majd a működés ismétlődjön. A regiszter szélességét a gyakorlatvezető fogja megadni. 2. Tripla KITT mint az első feladat, de egy három bit széles 111 mozogjon! 3. Körbeforgó shiftregiszter. Az MSB-n kilépett adat kerüljön vissza az LSB-re. 4. Egy lépés előre, kettő hátra : reset után a regiszter utolsó előtti bitje legyen 1. Az első órajelre a shiftregiszter egyet lép előre, a következő 2 órajel hatására pedig egy-egy lépést hátralép. 9