Diplomaterv. Készítette:

Átírás

1 Budapesti Műszaki és Gazdaságtudományi Egyetem Villamosmérnöki és Informatikai Kar Méréstechnika és Információs Rendszerek Tanszék Mikrorendszer megvalósítása FPGA környezetben Diplomaterv Készítette: Czakó Péter V.évf. villamosmérnök hallgató Konzulens: Dr. Fehér Béla, docens Méréstechnika és Információs Rendszerek Tanszék május

2 Nyilatkozat Alulírott Czakó Péter, a Budapesti Műszaki és Gazdaságtudományi Egyetem hallgatója kijelentem, hogy ezt a diplomatervet meg nem engedett segítség nélkül, saját magam készítettem, és a diplomatervben csak a megadott forrásokat használtam fel. Minden olyan részt, melyet szó szerint, vagy azonos értelemben, de átfogalmazva más forrásból átvettem, egyértelműen, a forrás megadásával megjelöltem. Czakó Péter 1

3 Tartalomjegyzék 1. TARTALMI ÖSSZEFOGLALÓ ABSTRACT BEVEZETÉS A DIPLOMATERV FELÉPÍTÉSE AZ INTEGRÁLT ÁRAMKÖRÖK FEJLŐDÉSE FPGA ESZKÖZÖK FELÉPÍTÉSE BEÁGYAZOTT PROCESSZOROK A PicoBlaze processzor A 8051 mikrokontroller Xilinx MicroBlaze és Altera Nios Aquarius és C AZ XR16-OS PROCESSZOR ISMERTETÉSE A PROCESSZOR ÁLTALÁNOS TULAJDONSÁGAI UTASÍTÁSRENDSZER BELSŐ FELÉPÍTÉS ELVÉGZETT MÓDOSÍTÁSOK LEÍRÁSA Szorzó egység hozzáadása Barrel shifter hozzáadása Az osztás utasítás megvalósításának vizsgálata Megszakításkezelés Külső-belső buszok vezérlése XSOC RENDSZER SZINTŰ ISMERTETÉSE EREDETI KIALAKÍTÁS BUSZRENDSZER XSOC busz átalakítása Buszciklusok MEMÓRIATÉRKÉP PERIFÉRIÁK Utasítás és adat memória UART Hétszegmenses kijelző interfész Kapcsolók, ledek SRAM vezérlő Megszakításvezérlő egység Töréspont logika Időzítő számláló

4 Órajel leosztó modul JAVASLAT SYSTEMVERILOG NYELV ALKALMAZHATÓSÁGÁRA A RENDSZERHEZ TARTOZÓ SZOFTVER ESZKÖZÖK AZ ASSEMBLER ÉS LINKER ISMERTETÉSE (XR16.EXE) A C FORDÍTÓ (LCC-XR16.EXE) Illesztés menete SZOFTVER RÉSZEGYSÉGEK ALKALMAZÁS FEJLESZTÉS TÁMOGATÁSA MEGSZAKÍTÁSRENDSZER SZOFTVERTÁMOGATÁSA A GRAFIKUS SZOFTVERFEJLESZTŐ KÖRNYEZET A KOMMUNIKÁCIÓ FELÉPÍTÉSE KÜLSŐ FORDÍTÓ ESZKÖZÖK PARAMÉTEREZÉSE GRAFIKUS KÖRNYEZET FELÉPÍTSE Projekt fájl ablakok Terminál ablak Rendszer ablakok FUNKCIÓK RÖVID LEÍRÁSA TOVÁBBFEJLESZTÉSI LEHETŐSÉGEK ÁBRAJEGYZÉK TÁBLÁZATOK JEGYZÉKE IRODALOMJEGYZÉK

5 1. Tartalmi összefoglaló A mikroprocesszoros rendszerek tervezése során egyre jobban figyelembe kell vennünk az FPGA eszközök fejlődése által biztosított lehetőségeket, miszerint a teljes áramköri struktúra megvalósítható egyetlen újraprogramozható áramkörön belül. A belső logikai erőforrásokat felhasználva tetszőleges tulajdonságokkal rendelkező rendszerek is kialakíthatóak. Az iparban széles körben elterjedt, nagyteljesítményű SOPC megoldások azonban igen nagy komplexitásúak, és a velük történő tervezés teljes elsajátításához hosszú betanulási idő szükséges. A diplomaterv célja egy olyan SOPC rendszer ismertetése, továbbfejlesztése és szoftvertámogatásának kialakítása, amely egyfajta előkészítésként szolgálhat az ipari alkalmazások megismeréséhez. A kialakítandó oktatási rendszer alapvető követelménye a könnyű áttekinthetőség és gyors elsajátíthatóság, valamint a szolgáltatások terén nyújtott hasonlóság a nagy FPGA gyártók által támogatott rendszerekhez Abstract The design of microprocessor controlled systems needs us to consider the evolution of FPGA devices, which provides the opportunity to implement the whole system in one reprogrammable integrated circuit. Using the inner logic resources, a system can be designed having various optional properties. The widely used, high-end SOPC solutions are very complex, and therefore mastering the design tools perfectly takes a long time. The aim of this Thesis is to demonstrate, improve and create software support for an existing SOPC solution, which can be used as a learning point for the high-end industrial applications. The fundamental requirements of this educational system are clarity, short learning time and the functional similarity with the systems supported by the large FPGA manufacturing companies. 4

6 2. Bevezetés 2.1. A diplomaterv felépítése Ebben a fejezetben áttekintem az FPGA eszközök fejlődése által nyújtott lehetőségeket a beágyazott rendszerek fejlesztése terén, és bemutatom az újraprogramozható környezetben elterjedt processzorkialakításokat. A harmadik fejezetben részletesen ismertetem az általam választott CPU megoldás, az xr16 eredeti tulajdonságait, valamint a rajta elvégzett különböző módosításokat. A negyedik fejezet a processzor köré épített SOPC rendszer ismertetésével foglalkozik, ahol részletesen tárgyalom a buszrendszer kialakítását, valamint az egyes csatlakoztatott periféria elemek belső felépítését. A rendszerhez tartozó szoftvertámogatás leírása található az ötödik fejezetben. A hatodik fejezet témája az általam kialakított, grafikus szoftverfejlesztő környezet működésének és részegységeinek leírása. Végül a hetedik fejezetben a rendszer továbbfejlesztési lehetőségeit vizsgálom meg Az integrált áramkörök fejlődése Az elmúlt évtizedekben bámulatos fejlődésen ment keresztül az integrált áramkörök gyártástechnológiája. Gordon Moore az Intel cég egyik alapítójának 1965-ös megfigyelése alapján, az egy eszközben realizálható, minimális költséggel előállítható tranzisztorok száma 24 hónaponként megduplázódik. Ez nem csupán az egy lapkára integrálható tranzisztorok mennyiségét jelenti, hanem azt a sűrűséget, amikor a legkisebb az egy tranzisztorra eső gyártási költség. Az optimális érték fölött is lehet még növelni a tranzisztorok számát, viszont a gyártás során keletkező nagyobb számú meghibásodással járó veszteség növelni kezdi a költségeket. Ezt az empirikus megfigyelést nevezte el 1970-ben az amerikai Caltech egyetem professzora, Carver Mead, az azóta szinte fejlesztési irányelvként használt Moore-törvénynek. [1] 5

7 1. ábra: Moore-törvény Az elmúlt több mint 40 év alatt a fejlődés követte is a korábban megjósolt trendet (1. ábra). Míg 1965-ben csak néhány száz tranzisztor alkotott egy integrált áramkört, addig az Intel által fejlesztett legmodernebb processzorokban több mint 1 milliárd tranzisztor található. [2] A processzorok ilyen ütemű fejlődése természetesen a többi integrált áramkör fejlődését is magával hozta. Az 1980-as évek végén, a 90-es évek elején felmerült a kérdés, hogy milyen funkcionalitással lehetne teljes mértékben kihasználni az integráció nyújtotta lehetőségeket. A gondot az jelentette, hogy a digitális tervezésben használt módszerek és eszközök által, eredményesen kihasználható tranzisztorok száma jóval kevesebb volt, mint a technológia által biztosított mennyiség. A probléma megoldását az eszközök programozhatóságának megteremtése nyújtotta. Ennek hatására születtek meg a különféle programozható logikai áramkörök, többek között az FPGA-k is. [3] 2.3. FPGA eszközök felépítése A rövidítés a következő angol kifejezést takarja: Field Programmable Gate Array. Ez szószerinti fordításban mező-programozható kapu halmaz, bár a magyar szaknyelvben nincsen megfelelő kifejezés az ilyen áramkörök megnevezésére. Ezek az eszközök olyan programozható logikai áramkörök, melyek több ezer ugyanolyan építőelemből állnak, amiket egy belső, konfigurálható huzalozási pálya köt össze. Az 6

8 eszköz által megvalósított digitális funkcionalitást tehát végsőrorban nem a gyártó, hanem a felhasználó határozza meg. 2. ábra: FPGA belső felépítése Az FPGA eszközök alapegysége a logikai cella. Funkcióját tekintve ez az egység lényegében néhány bináris bemenetből állítja elő a felhasználó által meghatározott logikai kimeneti értéket. Lehetőség van még az így kapott kombinációs eredmény regiszterben történő eltárolására is, amellyel így nagyon könnyen kialakíthatóak órajellel működtetett szinkron hálózatok. Fizikailag a logikai cellát úgynevezett Look-Up-Table (LUT) valósítja meg, ami a bemenetek alapján egy táblázatból kikeresi a megfelelő kimeneti értéket. A táblázat tartalmát a felhasználó által definiált funkcionalitás határozza meg. Két logikai cella összekapcsolásából jön létre egy úgynevezett szelet (slice). [4] A cellák között húzódó vezetékezési pályák kereszteződési pontjaiban, úgynevezett kapcsoló dobozok (switch box) találhatóak, amelyek programozott módon megteremtik az összeköttetést a megfelelő vezetékszakaszok között. A logikai cella és a programozható vezetékezés segítségével tetszőleges funkcionalitást tudunk létrehozni. 3. ábra: Kapcsoló dobozok belső kialakítása 7

9 Az FPGA eszközöket használó digitális fejlesztéshez bonyolult tervező programok tartoznak, amelyek a funkcionális leírások alapján képesek az eszközön belüli különböző táblázatok és kapcsolók megfelelő beállítására Beágyazott processzorok A technológia fejlődési üteme lehetővé tette, hogy az FPGA eszközökön belül egyre komplexebb digitális áramköröket, akár beépített processzorokat is ki lehessen alakítani. Ezzel lehetőség nyílt a teljes digitális rendszer, a vezérlő egység és a köré épített perifériák egy áramkörön belüli megvalósítására. Az így kialakított rendszereket SOPC, azaz System On a Programmable Chip kifejezéssel illetik. Egy FPGA-ba ágyazott processzor nagymértékben növeli a tervezési szabadságot. Azáltal, hogy a processzor köré épített periféria egységeket tetszőlegesen alakíthatjuk, sőt akár saját periféria egységet is illeszthetünk a közös belső buszrendszerhez, nagymértékben megnő a flexibilitás. Lehetőség van a hardver-szoftver szétválasztás rugalmasabb kezelésére is, hiszen ha egy szoftver algoritmus túl bonyolult és sok számítási kapacitást igényel, azt az FPGA-n belül egy gyors segédprocesszorral elvégeztethetjük, csökkentve ezzel a futási időt. A teljes rendszer FPGA-ban történő megvalósítása emellett csökkenti a gyártás során felhasznált komponensek számát, így csökkenthető a hordozó kártya mérete és ezzel az előállítási költség is. Természetesen hátrányai is vannak egy SOPC rendszernek, hiszen a készen kapható megoldásokkal ellentétben, hosszú tervezési időt kell fordítanunk a rendszer kialakítására. Emellett a fejlesztést segítő szoftver eszközök igen nagy komplexitásúak, ezért nagy odafigyelést követelnek a tervezőtől. [5] Az SOPC rendszert irányító processzorok fizikai megvalósításnak két módja lehetséges a programozható áramkörön belül: kemény-magos (hard-core), és lágymagos (soft-core). Az előbbit az FPGA-ban egy dedikált szilícium felületen valósítják meg, míg az utóbbit a meglévő logikai erőforrások felhasználásával állítják össze. A kemény-magos processzorok nagyobb működési frekvenciával és kisebb fogyasztással rendelkeznek, viszont a lágy-magos megoldással a kívánt igényeknek megfelelően konfigurálni tudjuk a beépíteni kívánt processzor tulajdonságait. Ez roppant módon növeli a tervezés flexibilitását, hiszen csak a megvalósítandó feladat végrehajtásához szükséges funkciókat kell realizálnunk, a processzor kihasználatlan részei pedig nem foglalják el feleslegesen a rendszer erőforrásait. [5] 8

10 A továbbiakban ismertetek néhány széles körben elterjedt lágy-magos processzorkialakítást, majd ezek közül részletesen elemzem az általam választott, oktatási célra szánt struktúrát A PicoBlaze processzor Az Xilinx által fejlesztett 8 bites, lágy-magos, csökkentett utasításkészletű (RISC) processzor volt az első, amely megkezdte térhódítását a mikrokontrollerek FPGA-ban való realizálásának piacán. Nemsokára számos területen elterjedt a használata, és újabb igények születtek nagyobb és komplexebb processzorok megvalósítására. [6] 4. ábra: PicoBlaze processzor külső interfésze A PicoBlaze tervezésének fő szempontjai a hatékonyság és az alacsony beépítési költség, vagyis a kis erőforrás igény. Összesen 96 szelet (slice), azaz 192 logikai cella az erőforrás igénye, ami a Spartan-3-as FPGA családon belül az XC3S50-es eszköznek 12,5%-át, az XC3S5000-nek pedig csak 0,3%-át foglalja el. Legfőbb jellemzői: - 16 darab bájt szélességű belső regiszter bit széles utasítás a belső blokk RAM-ban, ami FPGA konfigurációkor automatikusan betöltődik - Bájtos aritmetikai, logikai egység (ALU) Carry és Zero jelzőbitekkel - Belső, 64 bájtos úgynevezett scratchpad RAM az átmeneti tárolásokra - Automatikus, 31 elem mélységű verem (stack) a szubrutinhívások kezeléséhez 9

11 - 256 ki- és 256 bemeneti port - Kiszámítható teljesítmény, mivel minden utasítás végrehajtása 2 órajelet igényel - Gyors válasz a megszakításkérésekre (legrosszabb esetben 5 órajel) - Assembler és utasítás szimulátor 5. ábra: PicoBlaze processzor belső kialakítása A processzort legfőképpen kisebb vezérlési feladatok ellátására, kommunikációs csatornák közötti protokoll konverzióra ajánlják. Az összetettebb funkciókra célszerű lehet egyszerre több PicoBlaze processzor használata, amelyek egymás között kisebb részegységekre osztják a teljes feladatot. (pl. kijelző- és billentyűzetvezérlés, valamint rendszermenedzsment) Utasításkészlete viszonylag egyszerű, könnyen áttekinthető. Az aritmetikai utasítások közül csak összeadás és kivonás műveletekkel rendelkezik, szorzást és osztást nem tartalmaz, ami érthető a kis erőforrásigényre történő optimalizálás miatt. Emellett a logikai, programvégrehajtást befolyásoló, tárolást, elővételt végző utasítások a szükséges funkcionalitást tökéletesen biztosítják. [7] A 8051 mikrokontroller Természetesen lehetőség van olyan mikrokontrollerek lágy-magos verzióinak FPGA-ba építésére, amelyeket általában külön tokozott alkatrészként használnak 10

12 beágyazott rendszerekben. Ezzel a megoldással megvalósul a komponensek számának csökkentése, anélkül, hogy át kelljen térni egy másik processzorcsalád használatára. 6. ábra: 8051-es processzor külső interfésze Az ipari alkalmazásokban rendkívül elterjedt 8051-es, 8 bites mikrovezérlőnek is van FPGA-ba építhető változata. Ennek a processzornak a lágy-magos változatát többek közt az Altera cég szolgáltatja. Legfontosabb jellemzői: - teljes mértékben megegyezik a 8051-es szabvánnyal - 6,7-szer gyorsabb, mint a külön tokozott változat - 64 KB utasítás memória - Akár 16 MB külső és 256 bájt belső adatmemória - 4 órajel hosszúságú szorzás, és 5 órajeles osztás műveletek - Számos beépített periféria egység (16 bites időzítők, soros port, I2C) - Külső társprocesszor segítségével lebegőpontos műveletek végzése A 8051-es mikrokontroller példáján láthatjuk, hogy milyen sok előnye van az FPGA-ban történő implementálásnak. Amellett, hogy kisebb helyet foglal el a teljes megvalósított rendszer egy hordozó kártyán, még látványos sebesség növekedéssel is számolhatunk. Ez nagymértékben abból adódik, hogy a processzor jeleit nem kell a 11

13 tokozáson kívülre vezetni, mint a korábbi esetben, így nagymértékben csökken a vezetékezés kapacitása, ezáltal nő az elérhető sebesség. [8] Xilinx MicroBlaze és Altera Nios Mindkét nagy FPGA forgalmazó természetesen rendelkezik még komplexebb processzorcsaládokkal is. Ezek a lágy-magos processzorok már igen bonyolult fejlesztőkörnyezetek által támogatottak, magas szintű, C és C++ nyelven programozhatók, és bizonyos képességeik opcionálisan beépíthetők, ezáltal roppant flexibilisek is. Az előző két processzortól eltérően a hardver leírása és a különféle szoftver eszközök nem ingyenesen hozzáférhetőek. Rendszerint az SOPC rendszerek tervezéséhez használt fejlesztői környezetből is ezeket a processzorokat tudjuk felhasználni. A Xilinx esetén ez a környezet az Embedded Development Kit (EDK), míg az Altera-nál az SOPC Builder. A MicroBlaze processzor összesen 32 darab 32 bites általános célú regiszterrel rendelkezik, adatszélessége és RISC utasításkészletének elemei is szintén 32 bitesek. Állítható lépésszámú (3 vagy 5 lépcsős) futószalaggal, opcionális szorzó, osztó, léptető és lebegőpontos számokat kezelő egységgel is rendelkezik. Emellett még számos egyéb funkciót is engedélyezhetünk, mint például külső buszinterfész vagy gyors memóriabusz használatát, gyorsítótárat (cache), kivételek kezelését, sőt bizonyos utasítások támogatását is állíthatjuk. A memória használata Harvard-architektúrát követ, vagyis az utasítás- és adatmemória külön egységeket képeznek. 7. ábra: MicroBlaze belső kialakítása 12

14 Az SOPC rendszer kialakításhoz a MicroBlaze az IBM által fejlesztett Core Connect buszrendszer egy módosulatát használja. A Core Connect 3 busztípusa a lokális busz (PLB), a chip-en belüli periféria busz (OPB) és a vezérlő regiszter busz (CRB) közül az OPB-t valósítja meg a processzor. [9] 8. ábra: Nios processzor belső kialakítása Az Altera Nios processzora sok tulajdonságában hasonlít a fenti MicroBlaze-re, de bizonyos területeken eltér vetélytársától. A Nios 16 és 32 bites változatban is kapható, de mindkét esetben 16 bites utasításokkal rendelkezik. A RISC architektúrájú pipeline processzor és utasításkészlete a magas szintű nyelvek támogatásához lett kialakítva. Itt is lehetőségünk nyílik néhány szolgáltatás használatának állítására, mint például gyorsítótár, vagy a kivételek kezelése. Regiszterkészlete egészen speciális, mivel 128, 256 vagy akár 512 regiszterrel is rendelkezhet, amelyből aktuálisan mindig csak 32-t használ. A 32 méretű regiszterablakok közötti váltást általában szubrutinhívások, vagy megszakítások indukálják. A regiszterek alkalmazását pedig külön használati konvenció is megköti, miszerint az R31-R24 regiszterek a bemeneti, az R23-R16 a lokális, az R15-R8 a kimeneti, míg az utolsó R7-R0 regiszterek a globális értékek tárolására szolgálnak. Az 13

15 ablakok között átfedés van, mivel a váltás során csak 16 regiszterrel kerül arrébb a vizsgált tartomány, ezzel valósítják meg a függvények közötti paraméter átadást. 9. ábra: Regiszterek közötti váltás A memória és a perifériák elérése az Altera által fejlesztett saját Avalon buszán keresztül történik. Ez egy viszonylag egyszerű kialakítású szinkron buszrendszer, amelyen bájtos, fél-szavas (16 bites) és szavas (32 bites) hozzáférést is meg tudunk valósítani. Részletesebb ismertetését majd a buszkialakítások vizsgálatánál tárgyalom. [10] Aquarius és C16 A korábban ismertetett két 32 bites processzor igen komoly hardver- és szoftverfejlesztési támogatással rendelkezik. A hallgatóknak igen fontos lehet ezeket a rendszereket közelebbről is megismerni, ezáltal képet alkothatnak az iparban legelterjedtebb FPGA-ba ágyazott processzorok segítségével történő fejlesztés menetéről. Mivel a komplex fejlesztőrendszerek elsajátítása igen nehéz feladat, ezért célszerű először egy kisebb bonyolultsági fokú processzort és a hozzá tartozó fejlesztőkörnyezetet megismerni. A 8 bites nagyon egyszerű és a 32 bites komplex rendszerek között ésszerű alternatívát nyújtanak a 16 bites processzorok. Ezek használata az iparban ugyan nem olyan elterjedt; mégis, oktatási célokra, a 32 bites processzorok megismerésének előkészítésére tökéletesen alkalmasak. 14

16 A digitális rendszerek fejlesztéséhez számtalan hasznos információ, esetleg kész alkalmazás vagy beépíthető hardver modul található az interneten. Legnagyobb gyűjtőhelye az efféle forrásoknak az úgynevezett OpenCores szervezet honlapja. [11] Természetesen nyílt forráskódú lágy-magos processzorokat is találunk ezen az oldalon. Ezek közül számtalan olyan megoldás van, amelyek még csak kezdeti stádiumban tartanak, vagy több hibát is tartalmaznak, viszont vannak teljesen kész megvalósítások is. Ezek közül két figyelemreméltó processzor-kialakítás az Aquarius és a C16. Az Aquarius fantázianevű processzor tulajdonképpen a Hitachi majd később a Hitachi és a Mitsubishi félvezetőkkel foglalkozó csoportjának egybeolvadásával a Renesas Technology által forgalmazott SuperH-2 mikrokontroller utasításkészletére épülő, 5 lépcsős futószalaggal rendelkező RISC CPU megoldás. Az eredeti processzorhoz használt C fordító természetesen az FPGA-ba ágyazott kialakítással is kompatibilis. A teljes megvalósítás Verilog nyelvű forrásai, valamint a dokumentációk és a szoftver eszközök ingyenesen letölthetők az OpenCores honlapról. Utasításai 16 bitesek, belső regiszterkészlete 16 darab 32 bit széles regisztert tartalmaz. A processzor belső busz kialakítása szintén 32 bites, amely nagyobb sávszélességű adatfeldolgozási feladatokat támogat, például jelfeldolgozó processzorokban (DSP) alkalmazott szorzás és összeadás (MAC) műveletek végrehajtását. Megszakításkérés és kivételek kezelését is támogatja. A megszakítások 16 szintes prioritással rendelkezhetnek. Emellett még van egy külön, nem maszkolható megszakításkérő (NMI) bemenete is, amelynek prioritása maximális (16), így mindig elfogadásra kerül. 10. ábra: Aquarius processzor belső kialakítása 15

17 Adatfeldolgozó (Data Path) egysége tartalmazza a belső 16 darab általános célú, a státusz, a programszámláló, a megszakításokhoz tartozó és a globális báziscímet tartalmazó regisztereket. Itt található még a műveletek elvégzéséhez használt aritmetikai, logikai egység (ALU), a létető, az osztó és a komparátor egységek. Külön szorzó egységgel rendelkezik, ami a 16x16 bites szorzásokat 1, míg a 32x32 bites szorzásokat 2 órajel alatt végzi el. A dekóder modul végzi az utasítások értelmezését, ezáltal ez az egység irányítja a processzor tényleges belső működését. A processzor a külvilággal WISHBONE buszon keresztül tartja a kapcsolatot, ami az OpenCores szervezet által fejlesztett, ingyenes, chipen belül történő kommunikációhoz használt szabvány. A hardver kialakításhoz nem csak a processzormag tartozik, hanem tartalmaz még UART-ot, ROM és RAM memóriákat, valamint megszakítás és kivételkezelő egységet is. A rendszerhez tartozó szoftver eszközök részben Windows, részben pedig Unix környezetet igényelnek; ehhez a Cygwin program használatát ajánlja a tervező. A C nyelvű programokat a GNU gcc fordító alakítja át assembly kódra. A rendszer igen jó tulajdonságokkal rendelkezik, egyetlen hátránya a nagy erőforrás igény. A tervező a rendszert egy Xilinx VirtexE XCV300E FPGA eszközön valósította meg, és ennek erőforrásait szinte teljesen felemésztette. A szintézis során az FPGA eszközben elfoglalt terület minimalizálása esetén 2635 (86%), míg sebességre történő optimalizáláskor 2753 (90%) szeletet emésztett fel csak a processzormag megvalósítása. A hallgatók számára elérhető Spartan-3-as FPGA (XC3S200) nem rendelkezik ilyen erőforrásokkal (1920 slice), tehát ez a processzor használatát teljesen lehetetlenné teszi oktatási célokra. [12] A C16-os processzor szintén egy ingyenesen elérhető lágy-magos processzor. A tervezőmérnök célja legfőképpen az volt a fejlesztés során, hogy C programok írását minél jobban támogassa. Összesen 3 regisztert tartalmaz csak a processzor: LL bal operandus, RR jobb operandus és eredmény, SP verem mutató (stack pointer). A regiszterek számának drasztikus csökkentésével, operációs rendszer futtatásakor az egyes folyamatok (task) közötti váltás ideje lényegesen rövidül, mivel ilyen esetekben az összes regisztert menteni kell. A fejlesztő az utasításkódok kialakítása során is azt a döntést hozta, hogy a különböző jelzőbiteket teljesen elhagyja, és ahelyett, hogy egy összehasonlítás (CMP) utasítással állítaná be ezeket feltételes elágazásokhoz, inkább külön reláció operátorokat (>,<, stb.) vezetett be. A processzor köré épített rendszerhez tartozik még UART, hétszegmenses kijelző, amelyen a programszámláló értékét 16

18 láthatjuk, valamint egy 16 bites számláló. A rendszer egyik legfőbb hátránya a meglehetősen hiányos dokumentáció, és a VHDL nyelvű megvalósítás, tekintettel arra, hogy az egyetemen a hallgatók a Verilog hardver leíró nyelvet sajátítják el tanulmányaik során. [13] 3. Az xr16-os processzor ismertetése Az FPGA eszközökben megvalósított lágy magos kialakítások közül, az xr16-os megnevezésű processzor egy viszonylag egyszerű, mégis rengeteg pozitív tulajdonsággal rendelkező megoldás. Oktatási célra tökéletesen alkalmas, mivel a rendszer könnyen áttekinthető, ingyenesen hozzáférhető, Verilog nyelvű kialakítás, dokumentációja pedig kielégítően részletes. 11. ábra: xr16 eredeti és átalakítás utáni külső interfésze 3.1. A processzor általános tulajdonságai A tervező, Jan Gray célja lényegében az volt, hogy létrehozzon egy csökkentett utasításkészletű (RISC), 16 bites, egész számokon operáló C programokat futtatni képes processzort. Ennek megfelelően a processzor összesen 16 darab 16 bit széles belső regiszterrel rendelkezik illetve a működést vezérlő utasítások is 16 biten kódoltak. A regiszterek közül viszont néhánynak dedikált szerepe van, tehát ezeket csak korlátozott módon használhatjuk fel saját célra. Az R0-ás regiszter csak olvasható és dedikáltan a konstans 0 értéket tárolja, ami nem feltétlenül jelent hátrányt, mivel ezt a tulajdonságot 17

19 a programozás során esetenként igen előnyösen ki is tudjuk használni. A programszámláló értékét megszakításkérés érvényre jutásakor az R14-es, szubrutin híváskor pedig az R15-ös regiszterbe menti a processzor, mivel erre a célra nincsen külön belső tároló. A stack pointer pedig az R13-as regiszterben található. [14] A műveletetek végrehajtását egy háromszintű pipeline, azaz futószalag segíti, melynek a különböző lépcsői az utasítás beolvasása, dekódolása valamint végrehajtása. Beolvasáskor a processzor előveszi a memóriából az adott címen lévő utasítást és megnöveli a programszámláló értékét 2-vel. A dekódolás során értelmezi a beolvasott parancsot és előkészíti a megfelelő operandusokat a művelethez. Végül pedig elvégzi azt a végrehajtás ütemben, azaz kiválasztja a megfelelő eredményt és beírja azt a regisztertömb megfelelő helyére. Ugrás és szubrutinhívás utasításoknál a PC értéke egyenlő lesz a belső ALU által számolt összeggel. Tárolás és betöltés esetén a megadott cím lesz az összeg, a futószalag működése pedig leáll a következő ciklusra, amíg lezajlik a memória hozzáférés. A processzor a működéséhez szükséges utasításokat és adatokat egy közös memóriából veszi elő, azaz a rendszer kialakítása Neumann-architektúrát követ. Ennek a közös memóriának a címtartománya összesen 64K, ami a teljes 16 bites címezhetőségből adódik, másik jellemzője pedig a bájtos (8 bites) illetve szavas (16 bites) hozzáférés. Természetesen a processzor még rendelkezik megszakításkérés (interrupt request) bemenettel is, ami a pipeline struktúrából következően 3 utasítás múlva jut érvényre illetve újabb 3 utasítás a futószalag újratöltése. Az eredeti processzor struktúra kialakításához a tervező a XC4000E-s Xilinx FPGA család tagjait választotta, ahol processzorhoz felhasznált erőforrások összesen 258 darab 4-bemenetű, 52 darab 3-bemenetű LUT-ot, 165 tárolót (flip-flop), valamint a nagy impedanciás vezetékezéshez 112 darab 3-állapotú meghajtót igényeltek. [15] 3.2. Utasításrendszer A 16 bites utasítások kódolása igen kompakt, vagyis az utasítások szinte teljesen lefedik a teljes 16 bites tartományt. A parancsok általános felépítése a 4 bites utasításkódból illetve az utasítástól függően operandusokból vagy alutasításkódokból tevődik össze. 18

20 A processzor aritmetikai műveleteit (összeadás, kivonás) 3-operandusos formában hajtja végre, azaz a 2 operanduson elvégzett művelet eredménye egy harmadikba kerül. R D = R A op R B / konst R D : az eredmény regiszter; R A,R B : operandus regiszterek; op: az elvégzendő művelet; konst: a B operandus helyén állhat konstans érték is; Alapesetben a művelet utolsó operandusa lesz a 4 bites konstans, viszont ha a kívánt érték kilóg ebből az ábrázolási tartományból, akkor szükség van egy 12 bites konstans előtét utasításra, ami az operandus felső 12 bitjét tartalmazza, majd ezután végezzük el a tényleges műveletet a maradék 4 bites konstans értékkel. Ebben az esetben ezt a két utasítást elemien kell kezelni, vagyis a konstans előtét és a tényleges művelet között nem szakítható meg a program futása. A 4 bites konstansok értelmezése is többféle módon történhet. Először is az aritmetikai műveletekhez a (-8)-(+7) előjeles ábrázolási tartományt használhatjuk, míg logikai műveleteknél előjel nélkül 0-15 értékek között értelmezzük. Emellett még megjelenhet ez a konstans érték szavas értékek tárolásakor, illetve ugró utasításoknál is. Ilyenkor az előtöltés szükségességének csökkentése érdekében 0 és 30 között mozoghat a konstans értéke úgy, hogy a legalsó bitet a 4. helyiértékként értelmezzük, melynek szemléltetését a következő ábrán láthatjuk. X ábra: Konstans érték értelmezése szavas műveleteknél A logikai műveletek végrehajtása csak 2 operandust használ, mivel a művelet eredménye felülírja az egyik bemenő paramétert (a korábbi egyenletben R D = R A ). 19

21 Hasonlóan az aritmetikai műveletekhez, itt is helyettesíthető konstanssal a második operandus. A léptetés vagy eltolás (shift) operátor is egy 0-15-ös tartományban mozgó állandót vár második paramétereként, viszont a processzor eredeti belső kialakításában csak egyszeri léptetés volt megvalósítva. A gépi utasításokat generáló assembler úgy kezelte ezt a hiányosságot, hogy annyiszor megismételte az eltolást egymás után, amennyi a kívánt érték volt. A programvégrehajtást befolyásoló utasítások között megtalálhatóak a szokásos feltételes elágazás, ugrás és szubrutinhívás funkciók is. Érdekesség, hogy a processzor belső jelzőbitjeit csak az aritmetikai utasítások állítják, ezzel alkalmazkodva a C fordító azon tulajdonságához, hogy minden feltétel kiértékelés előtt elvégez egy összehasonlítás műveletet. A másik sajátosság az, hogy a szubrutinhíváshoz tartozó effektív cím érték csak 12 bites, ami a szubrutin kezdőcímének felső 12 bitjét tartalmazza. Ennek megfelelően az egyes szubrutinok kezdőcíme kizárólag 16-tal osztható érték lehet, így tehetjük csak meg azt a feltételezést, hogy az alsó 4 címbit mindig nulla lesz. A tervező ezt a kompromisszumot hozta annak érdekében, hogy a szubrutinhívások csak egy utasítást vegyenek igénybe. Utasításkód [15:12] [11:8] [7:4] [3:0] Assembly Jelentés 0 Rd Ra Rb add rd,ra,rb Összeadás 1 Rd Ra Rb sub rd,ra,rb Kivonás 2 Rd Ra Konst addi rd,ra,konst Összeadás konstanssal 3 Rd Típus Rb {and, or, xor, andn, adc, sbc} rd,rb Logikai művelet 4 Rd {andi, ori, xori, andni, adci, sbci, Típus Konst Logikai művelet slli, srai, srli} rd,konst konstanssal 5 Rd Ra Konst lw rd,konst(ra) Szó betöltése 6 Rd Ra Konst lb rd,konst(ra) Bájt betöltése 7 8 Rd Ra Konst sw rd,konst(ra) Szó tárolása 9 Rd Ra Konst sb rd,konst(ra) Bájt tárolása A Rd Ra Konst jal rd,konst(ra) Ugrás és linkelés {br, brn, beq, bne, bc, bnc, bv, B Típus Eltolás bnv, blt, bge, ble, bgt, bltu, bgeu, bleu, bgtu} címke Feltételes elágazások C Konstans call címke Szubrutinhívás D Konstans imm konst Konst[15:4] előtöltése E F 1. Táblázat: Az xr16 utasításkészlete 20

22 Meg kell még említenünk, hogy az assembler kibővíti a viszonylag szűk utasításkészletet úgynevezett pszeudo-utasításokkal is. Ezek tulajdonképpen nem valódi új utasítások, hanem csak a meglévő parancsok bizonyos fajta használatának álnevei, amik könnyebbé teszik a megírt assembly program olvashatóságát. [14] Mnemonik nop mov rd, ra cmp ra,rd subi rd,ra,konst cmpi ra,im lea rd,konst(ra) lbs rd,konst(ra) j addr ret reti Leképezés and r0,r0 add rd,ra,r0 sub r0,ra,rb addi rd,ra,-konst addi r0,ra,-konst addi rd,ra,konst lb rd,konst(ra) xori rd,0x80 subi rd,0x80 jal r0,addr jal r0,0(r15) jal r0,0(r14) 2. Táblázat: Pszeudo-utasítások 3.3. Belső felépítés A processzor belső kialakítása két fő egységből tevődik össze, a vezérlőből (control) és az adatfeldolgozó (datapath) egységből. Az előbbi felelős az utasítások beolvasásáért, dekódolásáért és a megszakítások kezeléséért, az utóbbi pedig végrehajtja az előző modulból érkező jelek alapján a megfelelő műveleteket. [16] REG VEZÉRLÉS DIN (UTASÍTÁS) KONSTANS ADDR DMA ÉS IRQ VEZÉRLŐ MŰVELET TÍPUS ADATFEL- DOLGOZÓ DOUT BUSZ VEZÉRLÉS PC VEZÉRLÉS DIN (ADAT) STÁTUSZ 13. ábra: Vezérlő és adatfeldolgozó kapcsolata 21

23 Az adatfeldolgozóban találhatóak a regiszterek, a programszámláló (PC) és az aritmetikai-logikai egység (ALU). A programvezérléshez szükséges státuszjelek is itt állítódnak elő, amelyeket vissza kell csatolni a vezérlő egységbe, hogy az megfelelő döntést hozhasson a következő lépés végrehajtását illetően. Itt található még az eredménykiválasztó multiplexer is, ami a vezérlő egységből kapott jelek alapján tudja, hogy melyik művelet eredményét kell a kimenetén megjelenítenie. Az eredeti megvalósításhoz tartozott még egy beépített DMA kiszolgálási lehetőség is, ami akár 15 DMA csatornát is képes volt lekezelni. A módosítások során ezt a lehetőséget eltávolítottam a rendszerből, mert az esetleges DMA kezelést majd egy külső vezérlő fogja lebonyolítani. Ezzel csökkent a processzor hardverigénye, mivel a korábban használt 16 mélységű regiszter tömb helyett, amiben a csatornákhoz használt címek illetve a PC foglalt helyet, most csak a programszámlálónak kell egy külön 16 bites regiszter. Az új megoldásnak megfelelően a DMA kérés és elfogadás mechanizmusát is módosítanom kellett. Ennek részletes ismertetése majd a buszstruktúra kialakítását tárgyaló fejezetben következik. Elöljáróban itt csak annyit célszerű megemlíteni, hogy a processzor teljesen leállítja a belső működését DMA kérés érzékelésekor, kiadja az elfogadás jelet, majd ha a kérés lezajlott, a program ott folytatódik, ahol abbamaradt. 14. ábra: Az eredeti xr16 adatfeldolgozó egységének belső felépítése 22

24 A műveletek elvégzésének gyorsítása érdekében az adatút egység rendelkezik egy előtöltést biztosító multiplexerrel (FWD). Ez az előtöltés akkor szükséges, ha az éppen végrehajtandó művelet felhasználja az előző eredményét. Így ilyenkor nem kell megvárnunk, amíg az eredmény eltárolódik a regiszter tömbben, hanem egyszerűen a multiplexeren keresztül visszacsatoljuk az adatútba. Viszont ez az előtöltés csak az A operandusra működik. Az assembler mindenképpen megpróbálja kihasználni az előtöltést esetleges operandus átrendezéssel, viszont ha ez nem megvalósítható, akkor az egymást követő utasítások közé be kell iktatnunk egy NOP utasítást. Operandus átrendezés addi r1,r1,1 addi r1,r1,1 add r2,r3,r1 add r2,r1,r3 NOP beszúrása addi r1,r1,1 addi r1,r1,1 add r2,r1,r1 nop add r2,r1,r Elvégzett módosítások leírása A processzor belső működésén végrehajtott módosítások legfőbb célja a korábbiakban említett egyszerűsítés, valamint a hallgatók számára elérhető, Spartan-3 XC3S200 típusú FPGA eszközök támogatása volt. Emellett kijavítottam a megszakításkezelés során fellépő hibákat, valamint bővítettem a processzort szorzás és egy utasításciklusos, többpozíciós léptetés (barrel shift) műveletekkel a gyorsabb működés érdekében. Az új műveletek hozzáadása a rendszerhez igen sokrétű módosítást igényelt a vezérlő és az adatút egységben egyaránt. Mindezek mellett természetesen még a processzorhoz tartozó assemblert és C fordítót is át kellett szerkeszteni, hogy értelmezni tudják, illetve megfelelő gépi kóddal helyettesítsék ezeket az új parancsokat. Ebben a fejezetben csak az első lépést fogjuk tárgyalni, a szoftver eszközök módosításának leírását pedig majd az 5. fejezet tartalmazza. 23

25 Szorzó egység hozzáadása Egy processzor tervezése során igen kompromisszumos döntés a szorzó egység beépítése, hiszen általában nagy hardver erőforrást igényel, viszont a különböző szoftver algoritmusok lényegesen megnövelik a programok méretét és futási idejét is. Esetünkben, mivel a processzort egy Spartan-3-as (XC3S200 típusú) FPGA-ba ágyazva szeretnénk elhelyezni, nem okoz akkora problémát a hardver megoldás, mivel az FPGA 12 darab belső, 18x18 bites szorzóval rendelkezik. Ezt természetesen 16x16 bites szorzásra használjuk majd a felső bitek elhagyásával. Ilyenkor viszont még mindig kétféle lehetőség áll előttünk a szorzás hardveres beépítésére. Az egyik, hogy egy külső műveletvégző egységnek átadjuk a szorozni kívánt paramétereket, majd az eredményt kiolvassuk belőle, a másik pedig, hogy új utasításként felvesszük a processzor parancskészletébe. Az utóbbi megoldás mellett döntöttem, mivel ez egy igen jó lehetőség is volt arra, hogy feltérképezzem a processzor teljes belső működését. Először is az utasításkészletben meg kell vizsgálni, hogy hol van szabad hely a kódmezőben az új műveletek felvételéhez. Jelen esetben mivel a szorzást 3 operandusú műveletként tervezzük beilleszteni, ezért három lehetőség adódott erre az 1. számú táblázat alapján: a 7-es, az E és az F operációkódok. Ebből a háromból az E kódra esett a választás. Meg kell említenem, hogy csak a regiszterek közötti szorzást építettem be a processzorba külön utasításként, ezért a konstanssal való szorzást a fordító kezeli le úgy, hogy kívánt értéket betölti majd egy átmeneti regiszterbe. Miután definiáltuk az utasítás helyét az utasításkészletben, meg kell vizsgálnunk, hogy a szorzáshoz hasonló 3 operandusú utasítások milyen változásokat idéznek elő a vezérlő egység működésében. Elsősorban be kell építenünk a szorzást is az utasítás dekódolásba, tehát fel kell ismernie a dekódernek a megfelelő operációkódot, valamint az eredmény kiválasztó multiplexernek tudnia kell, hogyha a végrehajtott utasítás kódja a szorzás, akkor a kimenetén a szorzó egységből kapott eredmény jelenjen meg. Az adatfeldolgozó modulban kell ténylegesen megvalósítanunk magát a szorzó egységet. Mivel 16 bites egész számok között végezzük el a szorzást, ezért ügyelnünk kell arra, hogy a szorzás eredménye 32 bites lesz. Ilyenkor az alsó 16 bitet kell vennünk eredménynek, hogy ne lépjük túl az ábrázolási tartomány határait. Ez a korlátozás természetesen nem jelent különösebb problémát a negatív számok szorzásánál sem. A vezérlő egységben az eredmény multiplexer választó bemenetei közé már felvettük a 24

26 szorzást, tehát az adatútban már csak a megfelelő eredmény bemenetre kell vezetnünk a szorzó egység kimenetét Barrel shifter hozzáadása A léptetés művelet az eredeti processzorkialakításban úgy működött, hogy egyszerre mindig csak eggyel tudtuk léptetni az adott regiszter tartalmát. Mivel assembly programozás során értelemszerűen megadhattunk egy 1 és 15 közötti konstans értéket a léptetésre, ezért ezt az assembler leképezte annyi eggyel történő léptetésre, amennyi a konstans értéke volt. Ennek a kiküszöbölésére született meg az igény az úgynevezett barrel shifter egység beépítésére, melynek segítségével egy utasítással egyszerre többet is tudunk léptetni. Kétféle lehetőséget vizsgálhatunk meg az új belső egység beépítése során. Az egyik, hogy egy külön léptető modult építünk be a processzorba, párhuzamosan a szorzó és ALU egységekkel, vagy magát a szorzót használjuk fel egy kis kiegészítéssel erre a célra. Az első esetben a Verilog nyelvű működési leírás igen egyszerű, viszont a hardver igénye sokkal magasabb ennek a realizációnak. A második esetben a leírás bonyolultsága megnő, és a processzor adatútjába illesztés is komolyabb munkát igényel, viszont lényegesen kevesebb erőforrást használunk. Az alábbi összefoglaló táblázat tartalmazza a két megvalósítás néhány jellemző adatát. Külön léptető modul Léptetés szorzóval Erőforrások 72 slice (130 LUT) 11 slice (19 LUT) + 1 szorzó Késleltetés 6,12 ns 4,8 ns* * az operandus regiszterezése miatt csak a szorzó egység késleletése 3. Táblázat: Barrel shifter kialakításának adatai Mivel minden szempontból optimálisabb megoldást biztosít a már felhasznált erőforrások más célra való alkalmazása, ezért a második lehetőséget választottam. Ebben az esetben a szorzó egység egyik bemenete lesz maga az eltolni kívánt paraméter, a másik pedig az eltolás mértékéből számolt 2-hatvány. A művelet eredménye az első operandus regiszterében tárolódik. R = * 2 D R D SH 25

27 Az SH paraméter az eltolás utasítás konstans értékét jelöli, ami balra lépetetésnél a 1 15 tartományban, míg jobbra léptetésnél a (-1) (-15) értékek között mozog. Tehát lényegében ezt az utasításba kódolt 4 bites konstans értéket kell átalakítanunk 2-hatvánnyá, attól függően, hogy jobbra vagy balra léptetünk. A balra léptetés során ez nem okoz igazán gondot, hiszen egy dekóder segítségével a 4 bites értékből előállítjuk a kívánt 2 hatványt, majd ezt a B-operandusba vezetve elvégezzük a szorzást. A szorzó egység kimenetének alsó 16 bitjén jelenik meg a végeredményként kapott eltolt érték. A jobbra léptetéshez a szorzó egység felső 16 bitjének értékét használjuk, ezért a bemeneti konstans paraméter 2-es komplemensét vezetjük rá a dekóderre, majd ezután végezzük el a szorzást. Az alábbi példa segítségével könnyebben megérthetjük a működés menetét. Léptessük az alábbi bináris értéket 4-gyel jobbra: (1486) 1. Vegyük a 4 kettes komplemensét: = 1100 (12) 2. Végezzük el a dekódolást a kapott értékre: (2 12 ) 3. Szorozzuk meg a két értéket egymással: 1486 * 2 12 = = Jól láthatjuk, hogy a szorzás után kapott eredmény felső 16 bitje ténylegesen megegyezik az elvárt eltolt értékkel. Problémát jelenthet még az aritmetikai jobbra léptetés, ahol a szám előjele nem változik a léptetés során, vagyis a legfelső bit értéke mindig azonos marad. Ennek a megoldására egy 16*16 méretű ROM memória egységet használtam fel, amelynek kimenetén megjelenik a megfelelő előjel kiterjesztés. A ROM címzését az eltoláshoz használt konstans paraméter szolgáltatja. A memória kimenetét és a szorzó egység felső 16 bitjét logikai VAGY kapcsolatba kell hoznunk, és ekkor megkapjuk a jobbra léptetés eredményét. A programozás során korábban ügyelnünk kellett arra, hogy a processzorban csak a konstanssal való eltolás volt implementálva, a regiszter-relatív léptetés viszont nem. Tehát a következő utasítássorozatot hatására a C fordító egy függvényhívást generált, ahol a későbbiekben szoftveresen megoldhattuk volna ezt a problémát. 26

28 unsigned int C; int A,B; A = B << C; /* B-t léptetjük C értékével balra */ Mivel a rendszerbe már beépítettem a gyors shiftelés lehetőségét, adott volt az új típusú utasítások felvétele is. Az utasításkészletben ezek a 3-as utasításkód csoportjába vettem föl, ahová a többi 2 regiszteres művelet is tartozik. Konstanssal való léptetés során az assembler és a C fordító is jól jár el, ha nem megfelelő értékkel akarunk léptetni; mindkettő hibát generál, illetve az utóbbi a 0-val való léptetést egyszerűen kioptimalizálja. Viszont a regiszter relatív léptetés során szembekerülünk azzal a problémával, hogy a fordító nem tudja, milyen értéket is tartalmaz a regiszter. Tehát nem szól, ha 0-val, 16-nál nagyobb értékkel, vagy esetleg negatív számmal szeretnénk eltolni az adott regiszter tartalmát. A probléma kiküszöbölésére azt a megoldást választottam, hogy hardveresen kezeljük le az ilyen lehetőségeket, de emellett természetesen a programozó felelőssége is, hogy odafigyeljen a léptetés operandusaira. Mivel a léptetés értelmezési tartománya 1 és 15 közé esik, ennél fogva a 15-nél nagyobb léptetésre az eredmény logikai léptetéseknél 0, aritmetikai jobbra léptetésnél pedig az előjel értékének megfelelően 0 vagy -1 lesz. Ez matematikailag is helyes, hiszen ilyen esetben már a regiszterben csak az újonnan beléptetett értékek vannak, tehát minimum 16 darab 0 vagy negatív szám aritmetikai jobbra léptetésekor 16 darab 1-es. Hibás programok írásakor előfordulhat, hogy az eltolás operandusa nem előjel nélküli szám, azaz lehet negatív érték is. Mivel a hardverben mindenképp előjel nélküli számként kezeljük az eltolás értékét, így ez negatív számoknál természetesen 15-nél nagyobb pozitív értéket fog adni a kettes komplemens ábrázolásból fakadóan. Ezek alapján ugyanúgy érvénybe lépnek az előző megkötések. Itt esetleg még felmerülhetett volna az a megoldás is, hogy ilyenkor az ellentétes irányú léptetést hajtjuk végre, de így zavaró lett volna programozáskor, hogy egy << operátor jelenthet akár jobbra léptetést is. 27

29 Végül, ha 0-val szeretnénk eltolni az adott számot, akkor értelemszerűen az eredeti értéket kapjuk vissza. Ez balra léptetés esetén egy 1-gyel való szorzás, míg jobbra léptetésnél egy nal való szorzásnak felel meg. Az utóbbit 16 bites értékek mellett nem tudnánk megtenni, ezért kihasználjuk még a szorzó áramkör egyik bemenetének 17. bitjét is. Ez a bit viszont szigorúan csak akkor veheti fel a logikai magas értéket, ha a jobbra léptetés operandusa 0, minden más esetben pedig alacsony állapotban marad. A szorzás és a barrel shift megvalósítása, valamint a többi átalakítás során az adatfeldolgozó egységbe beépített módosításokat (szürke) láthatjuk a következő ábrán. 15. ábra: Az xr16 adatfeldolgozó egysége a módosítások után Az osztás utasítás megvalósításának vizsgálata Az új utasítások felvétele során felmerült még az osztás művelet hardveres beépítése is a rendszerbe. Ennek megvalósítására egy olyan algoritmust kerestem, amely egy fixen letárolt érték illetve egy szorzás művelet segítségével képes előállítani az osztás eredményét. Az osztás megvalósításához csak 1 belső blokk RAM egységet terveztem felhasználni, ami összesen 2 kilobájt memóriát jelent. A teljes pontossághoz az összes reciprok érték tárolására lett volna szükség, ami 16 bites értékekből fakadóan 64 kilobájt memóriát emésztett volna fel, ami messze felülmúlja az adott Spartan-3 28

30 FPGA kapacitását. A Taylor-sorral való közelítést kihasználó, futószalagos osztási algoritmus vizsgálata mellett döntöttem. [17] 16. ábra: Az osztási algoritmus A képletben Y h egy olyan bináris szám, melynek felső p bitje megegyezik az Y érték felső bitjeivel, a többi bit értéke 0, Y l -re pedig az Y l = Y-Y h egyenlet teljesül. Így csak p bites szélességben kell eltárolnunk a reciprok értékeket, ami nagyban csökkenti a szükséges memória méretét. A p értéke a rendelkezésre álló memória és a pontosság függvényében változtatható. Az algoritmus 32 bites, lebegőpontos számokkal dolgozik ezért a fixpontos, 16 bites számokra történő konvertálás során normalizálásra is szükségeltetik. A processzorban az osztás műveletéhez 2 új utasítás felvételét terveztem. Az egyik a megfelelő osztó paraméter előkészítését látta volna el, a másik pedig egy speciális szorzás, ahol az eredmény a felső 16 bit értéke lett volna. A normalizálás hatásának visszaállítására használt jobbra léptetéssel együtt az osztás összesen 3 utasításciklust vett volna igénybe. A rendelkezésre álló szűkös memória kapacitás miatt olyan pontosságbeli hiányosságok adódtak, amelyek lehetetlenné tették az algoritmus alkalmazását. A hibák fő természete az volt, hogy a memóriában eltárolt paraméterek bitszélessége túl kevés volt, ezért bizonyos osztásoknál ugyanazon paraméter mellett az eredmény 1-gyel kevesebb, míg másoknál pedig 1-gyel több volt az elvártnál. Hiába növeltem vagy csökkentettem az eltárolt paraméter értékét, mindig adódtak olyan eredmények, amelyek nem egyeztek meg az elvárttal. Végeredményben, mivel a hardveres megvalósítás nem nyújtott kielégítő eredményeket, ezért továbbfejlesztési tervként az osztás művelet szoftverben történő implementációja mellett döntöttem. 29

31 Megszakításkezelés Az xr16-os processzor a megszakításkéréseket az INT_REQ bemenetén fogadja szintérzékeny módon. Folyamatosan figyeli ezt a bemenetet, és ha megszakításkérés történt, azaz a bemenet logikai magas szintű, akkor megvizsgálja, hogy az éppen beolvasott utasítás megszakítható-e. Ez azt jelenti, hogy az aktuális utasítás és a következő utasítás közé beilleszthetjük a megszakítást, vagy a két utasítást elemien kell végrehajtani. 17. ábra: Megszakításkérés elfogadásakor az aktuális utasítás felülbírálása Ha megszakítható, akkor a következő utasítás helyett már egy jal r14,0x10(r0) utasítás kerül a futószalagra, melynek gépi kódja AE01. A processzor ezzel elmenti a programszámláló értékét a 14-es regiszterbe és a futást a hexadecimális 10-es címről folytatja, ahol az interrupt kiszolgáló rutin található. Ezt a mechanizmust követhetjük nyomon a 17. ábrán, ahol az IF_IR a beolvasott, az IR a ténylegesen futószalagra kerülő, az EX_IR pedig a dekódolás alatt lévő utasításkód. A nem megszakítható utasítások csoportjába tartozik az IMM, azaz a konstans előtét, az ugrás, a szubrutinhívás, valamint a különböző elágazások. Ilyen esetekben a kiszolgálás addig várakozik, amíg egy megszakítható utasítás nem következik. A konstans előtétnél egyértelmű, miért nem illeszthetjük be a megfelelő utasítást a végrehajtási sorba, viszont az utóbbi három azért nem megszakítható, mivel végrehajtásukkor kiürítik a pipeline-t. Vagyis ha be is illesztenénk egy ugrás után a megfelelő parancsot, akkor az nem jutna érvényre a kiürítés miatt. Az eredeti megvalósításban a megszakításkezelés igen hiányos volt, ezért sok módosítást igényelt. Először is az ugró utasítás nem volt felsorolva az interrupt-tiltó utasítások között, ezért bizonyos esetekben a megszakítás nem is működött megfelelően. Másodszor a processzor be tudott ragadni egy végtelen ciklusba, ha a megszakításkérő jel folyamatosan magas szinten volt. Ezt egy belső megszakítás 30

32 engedélyező jellel küszöböltem ki, ami letiltja a bemenetet addig, amíg egy korábbi megszakítás kiszolgálás alatt van. Ezt a tiltást a RETI utasítás végrehajtása oldja fel, viszont ezzel a megoldással nem tudunk többszintű megszakításrendszert kialakítani. Végül, mivel a processzorban nem volt implementálva a státuszjelek automatikus elmentése megszakításkéréskor, ezért az összes aritmetikai utasítás is blokkolta a kiszolgálást. Így a megszakításkérés elfogadása csak a logikai, illetve a beolvasás és tárolás utasítások végrehajtásakor történt, ami egy átlagos program esetén igencsak megnövelhette a megszakítás várakozási idejét. A tervező felmérése alapján, százalékos arányban láthatjuk, hogy átlagosan milyen utasításokból áll össze egy program. [14] A szavas betöltés (lw) 24%, a tárolás (sw) 13%, a regiszterek közötti másolás (mov) 12%, effektív cím betöltése (lea) 8%, szubrutinhívás (call) 8%, elágazás (br) 6%, összehasonlítás (cmp) 6%, a maradék 22%-ot pedig egyéb utasítások töltik ki. Ezek közül a mov, cmp és lea utasítások pszeudo-utasításként kivonásból és összeadásból valósulnak meg. Láthatjuk, hogy az aritmetikai utasítások megszakíthatóságának beépítésével a megszakíthatóság engedélyezésének időtartamát összesen 33%-kal sikerült javítani, ha a maradék 22%-ból feltételezzük, hogy ezek 1/3-a aritmetikai utasítás, a többi pedig logikai, vagy bájtos memória hozzáférés. Ezt a megoldást úgy építettem be a processzorba, hogy megszakítás elfogadáskor egy 4 bites regiszterben elmentem a státuszjeleket, és amikor a kiszolgálás lezajlott, egy multiplexer segítségével az eltárolt jelek kerülnek kiértékelésre. A multiplexer választó bemenetét egy olyan jel szolgáltatja, ami a RETI utasítás végrehajtását követő órajelben érvényes. A megszakítást kiszolgáló rutinból való visszatéréskor tehát minden esetben ügyelnünk kell arra, hogy a szokásos RET utasítás helyett a RETI utasítást használjuk, mivel ilyenkor a szokásos R15-ös helyett, az R14-es regiszterből veszi elő a processzor a PC értékét és emellett rengeteg belső jelet is szabályoz. Ha nem így járunk el, akkor nem tud folytatódni a program ott, ahol megszakadt. Még egy külön jellel kiegészítettem a processzort (IT_served), amelynek egy órajelig tartó magas állapota jelzi, hogy a processzor kiszolgálta az éppen aktuális megszakításkérést. Ezáltal az interruptot kérő perifériának nem kell külön a kiszolgáló rutinon belül nyugtázni kérésének elfogadását, hanem ez automatikusan megtörténik. Az IT_served jel hatására a periféria visszaállítja az IRQ kimenetét alacsony logikai szintre. 31

33 Külső-belső buszok vezérlése A processzor az eredeti kialakításban a külső és belső buszokat nagyimpedanciás módon, háromállapotú meghajtók segítségével kezelte. Mivel a processzort és a hozzá tartozó perifériákat egy Spartan-3-as eszközben implementálom, ezért ezt a megoldást át kellett strukturálni, mivel az adott FPGA eszköz nem tartalmaz ilyen meghajtókat. Ennek érdekében a ki- és bemeneti adatbuszt teljesen különválasztottam, és a több forrásból történő meghajtáshoz pedig egy multiplexert alkalmaztam. Ez a belső buszon a már korábban említett eredmény-kiválasztó multiplexer, a külső buszon pedig egy elosztott multiplexer logikai VAGY hálózataként jelenik meg. Ez azért elegendő, mivel az egyes külső periféria eszközök önmagukon belül kezelik le a kiválasztást. A buszrendszerrel kapcsolatos többi változtatást a következő fejezetben tárgyaljuk, hiszen ez inkább már a processzor rendszer szintű alkalmazásához kapcsolódik. 4. XSOC rendszer szintű ismertetése 4.1. Eredeti kialakítás Az xr16-os tervezője nem csak magát a processzort valósította meg, hanem egy külön kis SOC (System-On-Chip) rendszert alakított ki a CPU egység köré. Ennek legfőbb komponense a külső memóriavezérlő volt, mivel az xr16-os program- és adatmemóriájául egy, az FPGA-n kívül található külső SRAM szolgált. Emellett még volt a rendszerben egy 576x455 pixeles, monokróm VGA vezérlő, egy kis 16x16-os memória, valamint egy párhuzamos ki- és bemenet. A teljes rendszer egy külső oszcillátorról kapott 12 MHz-es órajelről működött. 32

34 18. ábra: XSOC eredeti kialakítása Amint az ábrán is látjuk, a memóriavezérlő és a processzor szinte egy közös egységet alkottak és ketten együtt irányították a rendszer működését. A processzor tulajdonképpen az adatbuszt kivéve az összes kimenetét a memóriavezérlőnek továbbította, ami végül előállította a tényleges cím- és vezérlőbusz jeleket. Tehát a memóriavezérlő igen sokféle feladatot látott el a külső SRAM jeleinek meghajtásán kívül: közvetlen kapcsolatban állt a VGA vezérlővel a képernyőfrissítéshez szükséges DMA kérések kezelésének biztosítására, belső címdekódolást végzett a perifériák kiválasztásához, valamint a külső és belső buszokat engedélyező háromállapotú meghajtók vezérlését végezte. [16] A hordozhatóság megteremtésének fő feladata tehát az volt, hogy a processzort függetleníteni lehessen a külső memóriavezérlőtől. Mivel ez a két egység oda-vissza kapcsolatban állt egymással, vagyis a memóriavezérlő jelei is befolyásolták a processzor belső működését, ezért azon kívül, hogy eltávolítottam a vezérlőt, annak néhány funkcióját a processzor magjába kellett beépítenem. Amint ez megvalósult, az xr16-os mag már egy külön egységben alkalmazhatóvá vált különféle beágyazott rendszerek vezérlésére. E mellett az átalakítás mellett egy egyszerűsített buszrendszer kidolgozása is elengedhetetlen volt a könnyebb áttekinthetőség és érthetőség végett. Mivel az FPGA-kba beépített belső blokk RAM memóriák megjelenése csak az újabb eszközökre jellemző, a külső SRAM memória helyett az átdolgozott kialakításban már ezt az egységet is használhatjuk utasítás- és adatmemóriaként. Ennek tartalmát a Verilog forráskódban inicializálni is tudjuk, ami ténylegesen az FPGA 33

35 konfigurációjakor történik meg. Ez a belső memória ugyan kisebb kapacitású, viszont az oktatási célra felhasznált rendszer számára tökéletesen elegendő, és gyorsabb elérést is biztosít. Az SRAM-ot természetesen továbbra is használhatjuk külső tárolóegységként. Végül mindezen változtatások mellett új periféria egységeket is terveztem a rendszer teljességének céljából. Természetesen a hallgatók későbbi tervezési feladatok során újabb, komplexebb eszközöket is illeszthetnek a rendszerhez Buszrendszer A system-on-chip rendszerek belső kommunikációjának megvalósítására számos buszkialakítás létezik. A lágy-magos processzorok ismertetése során megemlítettük a WISHBONE, az Avalon és CoreConnect buszrendszereket. Az előbbi egy ingyenesen használható szabvány, amelyet az OpenCores szervezet támogat, míg az utóbbi kettő a két nagy FPGA forgalmazó, az Altera és a Xilinx által használt kommunikációs szabványok. A WISHBONE busz egy igen flexibilis, szinkron, egyszerű összeköttetést biztosító kommunikációs felület. Az alapvető írási, olvasási ciklusokon kívül támogatja a blokkos átvitelt, valamint az olvasás-módosítás-visszaírás buszműveletet is. A busz adat- és címszélessége széles körben állítható. A háromállapotú meghajtók használatának elkerülésére külön ki- és bemeneti adatbuszt használ. A kommunikáció során úgynevezett kézfogás (handshaking) protokoll biztosítja a helyes működést különböző elérési sebességű perifériák esetén. Mester-szolga kialakítás jellemzi, ahol akár több mester eszköz is csatlakoztatható a rendszerhez. Ebben az esetben az arbitráció metódusát a végfelhasználó határozhatja meg. A WISHBONE használható még chipen kívüli kommunikációra is, természetesen lassabb működési sebesség mellett. [18] Az Altera által kifejlesztett Avalon busz, hasonlóan az előbbi kialakításhoz, egy szinkron, egyszerű, kevés logikai erőforrást használó buszkialakítás. Az alapvető adatszélesség 32 bites, de 8, 16 és 32 bites hozzáférést is biztosít. Az egyes bájtok kiválasztását külön bájt engedélyező jelek vezérlik. Támogatja a lassú periféria egységek kiszolgálását, valamint a több mester egység kiszolgálását. Ez utóbbi esetben az arbitráció a szolga egységekben történik, vagyis ők döntik el, hogy éppen melyik mester egység kérésére válaszolnak. A buszrendszer automatikusan generálja az adott 34

36 perifériákhoz tartozó kiválasztó jeleket, ezáltal egyszerűsödik a csatlakoztatni kívánt eszközök fejlesztése, mivel nincs szükség címdekódolásra. A buszhoz kapcsolódó egységek között támogatja a blokkos adatátvitel használatát. [19] A MicroBlaze processzorok által használt CoreConnect buszcsalád OPB buszrendszere sok hasonlóságot mutat a korábbi két megvalósítással. Szintén külön mester és szolga interfészt valósít meg a buszhoz való kapcsolódáshoz, várakozási ciklusokat biztosít lassú perifériák számára, valamint képes több mester egységet kezelni. Az adatszélesség itt is fixen 32 bites, viszont ez a buszstruktúra is támogatja a bájtos, 16 bites és 32 bites eléréseket. A perifériák kiválasztását elosztott címdekódolás biztosítja. [20] A rövid ismertetés alapján láthatjuk, hogy a chipen belüli kommunikációt biztosító szabványos buszrendszerek nagymértékben hasonlítanak egymásra, mégis apró különbségeik teszik őket egyedivé. Oktatási célra való alkalmazásuk viszont nem célszerű, mivel nagymértékben megnövelné a rendszer komplexitását. Az XSOC rendszer kialakítása során inkább a korábbi, egyszerű buszstruktúrát alakítottam át úgy, hogy az könnyen átlátható és érthető legyen XSOC busz átalakítása A processzor korábbi belső, bájtos adatpozíciót (MSB/LSB) választó jeleit (ud_t, ld_t, udld_t) teljesen eltávolítottam a rendszerből, mivel ezek csak származtatott jelek voltak a szavas (word_nxt) és olvasás (read_nxt) műveletet indikáló vonalakból. Az utóbbi jeleket pedig késleltetéssel, az aktuális buszciklusra jellemző értékekre változtattam. A korábbi addr_nxt, 16 bites címvezetékkel is hasonlóan kellett eljárni, valamint szét kellett választani az adatbuszt külön ki- és bemeneti vezetékekre, mivel a felhasznált Spartan3-as FPGA-n belül nincsenek háromállapotú meghajtók, amik ezt a kétirányú kezelést lehetővé tennék. Ezekhez a módosításokhoz természetesen figyelembe kellett venni, hogy a processzormag belső működését is át kellett szervezni, mivel ez nagymértékben a korábbi kialakításra épült. Így az új buszkialakítás a következő jelekből tevődik össze: clk 12 MHz-es globális órajel rst globális reset jel addr [15:0] 16 bites címvezeték 35

37 data [15:0] 16 bites adatvezeték (külön ki- és bemeneti) word 1: szavas hozzáférés, 0: bájtos hozzáférés rnw 1: olvasás, 0: írás dma_req, dma_ack direkt memória hozzáféréshez irq [7:0], irq_served [7:0] megszakításkérés és visszaigazolás nwait várakozás kérő jel lassú perifériákhoz A későbbi DMA használat biztosítására viszont még néhány kiegészítést kell tennünk a busz vezetékezéséhez. Mint ahogy azt már korábban említettem, a buszhoz kapcsolódó egyes perifériák adatkimenetei egy közös VAGY kapcsolaton keresztül hajtják meg a rendszerben az adatbuszt. Ez abban az értelemben felel meg multiplexelésnek, hogy egyszerre mindig csak a kiválasztott eszköz aktív, a többi egység pedig 0-t ad ki az adatkimenetén. A processzor cím és vezérlő jelei pedig nem közvetlenül kapcsolódnak a buszra, hanem logikai kapcsolatban állnak a későbbi DMA vezérlő vonalaival. A címvezetékek egy 16 bites logikai VAGY kapun keresztül csatlakoznak a közös buszra, így mikor a processzor vagy a DMA vezérlő inaktív állapotba kerülnek, a buszon 16 bites 0 értéket kell megjeleníteniük, hogy ne akadjon össze a vezérlés a másik master egységgel. A word és rnw jeleket pedig egy ÉS kapcsolaton keresztül kell a buszra kapcsolni, így ezeknek az inaktív állapotuk a logikai magas szint. Erre a busz vezérlésének átadásakor bekövetkező üres buszciklus miatt van szükség. Mivel a rendszerben még nincs implementálva a DMA vezérlő, ezért ennek a master egységnek a vezérlő jelei konstans inaktív értékre vannak huzalozva. 36

38 19. ábra: DMA kezelés megvalósításához a busz jelek kapuzása 20. ábra DMA kezelés során a busz átadásának lezajlása Érdekesség még, hogy az SRAM-ról belső, szinkron blokk RAM memóriára való áttérés még azt a módosítást is igényelte, hogy a buszhoz kapcsolódó master egységek az órajel felfutó éléről működnek, míg a slave eszközök az órajel lefutó élét használják. Így a memória elérése 1 órajel alatt történik, viszont a különböző setup és hold time értékeknek a fél órajel periódus hosszára kell megfelelniük. Ez nem jelent problémát, hiszen nem volt cél a processzor minél nagyobb sebességen történő működtetése, így ebbe a fél órajel periódusba bőven beleférnek ezek az időzítések. A buszciklusok szeparálása érdekében bevezettem még egy olyan kiegészítést, hogy a perifériák csak az órajel alacsony állapota mellett adnak ki aktív értéket. Így két olvasási ciklust a buszon egy fél órajelig megjelenő 16 bites 0 érték választ el egymástól. Írás során a master egység vezérli a kimeneti adatbuszt, és ilyenkor a busz értéke az egész ciklus alatt érvényes adatot tartalmaz. Ez a lassú periféria egységek 37

39 miatt fontos, hiszen ilyenkor írás alatt nem változhat meg a busz állapota. Ennek megvalósítására szolgál az úgynevezett NWAIT jel is, amely alacsony értékének hatására a master eszközök (jelen esetben a processzor) felfüggesztik belső működésüket, amíg a periféria el nem végezte a buszműveletet. A több bájtos rendszerekben problémát okozhat a különböző szélességű adatok kezelése. Ahogy azt már korábban láthattuk az egyes buszrendszerek ismertetése során, erre a problémára igen sokféle megoldás született. Esetünkben a word jel állapota jelzi, hogy az aktuális buszciklus 8 vagy 16 bites adatokra vonatkozik. Bájtos hozzáférésnél pedig a címbusz legalsó bitje dönti el, hogy éppen melyik bájt az aktív. A processzor úgynevezett big-endian címzési módszert használ, azaz a 16 bites busz felső bájtja a páros, míg az alsó bájtja az eggyel nagyobb páratlan címen érhető el. Nyolcbites perifériák esetén ügyelnünk kell arra is, hogy adatkimeneteiket az adatbuszt előállító VAGY kapu egyik portjának mindkét bájtjára párhuzamosan kell vezetni, így teremthetjük meg a processzor számára a 16 bites interfészt. A 16 bites hozzáféréseknél viszont arra kell figyelnünk, hogy szavakat mindig csak páros címen érünk el. Hibás program írásakor előfordulhat, hogy egy 16 bites értékhez páratlan címen akarunk hozzáférni, viszont ezt a lehetőséget a perifériák támogatásával minden esetben kerülni kell Buszciklusok Ismerve az új buszrendszer kialakítását, megállapíthatjuk, hogy a működés során a buszátadás és várakozás ciklusokon kívül 6-féle különböző buszciklus képzelhető el: Bájt olvasás / írás (LB/SB páros/páratlan) Word olvasás / írás (LW/SW) Figyelembe kell vennünk, hogy bájtos műveleteknél az adott bájt pozícióját a szón belül (MSB/LSB) a címbusz utolsó bitje határozza meg. A következő ábrákon szemléletesen végigkövethetőek a különféle buszciklusok, valamint megfigyelhetjük a processzor pipeline működéséből adódó egyes végrehajtási ütemeket. 38

40 19. ábra: Szavas írás (SW) buszciklus A 21. ábrán egy szavas írást láthatunk, ahol a 0x12ab adatot a 0x6040-es címre írjuk. Ahogyan az elvárható, a RNW jel alacsony, míg a WORD jel magas értékű. Ahogy azt már korábban említettük, a processzor a beírandó adatot és címet az órajel felfutó élére adja ki, míg az egyes periféria egységek a már stabilizálódott busz tartalmat az órajel lefutó élén olvassák be, ezáltal nem kell két órajelet várni az egyes buszműveletek végrehajtására. 20. ábra: Pipeline viselkedés és LW/LB buszciklusok Az 22. ábrán buszciklusok mellett nyomon követhetjük a pipeline struktúra működését is. A 0x0006-os memóriacímről beolvasott utasítás a 0x6100-as kódnak megfelelő LB utasítás, amelyet a nyilak által mutatott órajelekben a processzor beolvas, dekódol, majd végül végrehajt. A processzor utasításait LW buszciklus használatával olvassa be a 16 bites memóriából. Ennek megfelelően látjuk a vezérlőjelek magas állapotát, valamint, hogy a kiolvasott adat az órajel lefutó élére jelenik meg a buszon, majd fél órajelig aktív. 39

41 Az utasítás végrehajtásakor megtörténik a LB művelet, ahol látjuk, hogy a WORD jel alacsony értékű, a RNW pedig magas. A 8 bites perifériáról történő olvasás eredményezi, hogy a kimeneti adat az alsó és felső bájton is megjelenik. 21. ábra: Bájt írás páratlan címre Bájtos írásnál kétféle esetet kell még megvizsgálnunk, a páratlan illetve a páros címre írást. A két eset között egyedül az adatbusz működésében van különbség. Míg a 23. ábrán látható esetben a processzor a kimenetet az alsó bájtsávon jeleníti meg, addig páros címre történő íráskor (24. ábra) a kimenő adat mindkét bájtsávon megjelenik. Erre 8 bites perifériák használata esetén van szükség, mivel ezeket az adatbusz alsó bájtjára kapcsoljuk. A megfelelő vezérlőjelek természetesen alacsony értéket vesznek föl mindkét esetben. 22. ábra: Bájt írása páros címre 4.4. Memóriatérkép Mivel az egyes perifériák is a 64K hosszú memóriatartományban foglalnak helyet, vagyis a processzor nem tesz különbséget memória és periféria között, ezért új periféria illesztésekor célszerű tisztában lenni néhány címzési konvencióval, amelyet a következő ábra szemléltet. 40

42 23. ábra: Memóriatérkép A 25. ábrán láthatjuk, hogy a memória tartomány eleje a program- és adatmemóriaként is szolgáló belső blokk RAM-ok számára van fenntartva, mivel a reset vektor a 0-s, az interrupt belépési pont pedig a 0x0010-s címen található. A jelenlegi konfigurációban csak két blokk RAM-ot használunk fel (0x0000 0x0FFF), viszont az ábrán látható, hogy a Spartan-3-asban található összes (12) BRAM-ot felhasználva mekkora címtartományt foglalnánk el. A perifériák tartománya a 0x6000-s címtől a 0x7FFF-es címig terjed, ami várhatóan bőven elegendő az egyes perifériák belső regisztereinek elhelyezésére. A rendszerhez tartozó SRAM vezérlő segítségével lehetőségünk van a 0x8000-0xFFFF tartományt külső memória elérésére használni. A 32k-nál nagyobb memóriák elérésére biztosítjuk a lapozhatóságot. Jelenleg egy 128k-s SRAM-hoz összesen 4 lapot használunk. 41

43 4.5. Perifériák Számos új periféria készítése után a rendszer teljes felépítését a következő ábrán láthatjuk. A DMA vezérlő szaggatott körvonala jelzi, hogy ez jelenleg nincs megvalósítva. 24. ábra: Az XSOC rendszer az új periféria egységekkel A rendszerbuszhoz való kapcsolódáshoz a perifériák egy közös buszillesztő interfészt használnak, melynek Verilog nyelvű leírása a következő: 42

44 module periferia( input clk, input rst, input word, input rnw, input [15:0] addr, input [15:0] din, // írható perifériáknál input irq_served // megszakítást használó perifériáknál input dma_ack, //DMA-t használó perifériáknál output irq, // megszakítást használó perifériáknál output dma_req, //DMA-t használó perifériáknál output nwait, // lassú periféria esetén várakozáskérésre output [15:0] dout,... // a további, perifériára jellemző jelek ); parameter BASE_ADDRESS = 16'hxxxx; // alapértelmezett báziscím wire sel =addr[15:x]==(base_address >>X); // X: 2 X szó lefoglalása; reg [15:0] to_dout; // kimeneti regiszter assign dout = ~clk & sel & rnw? to_dout : 16'b0; // kimenet engedélyezés... // egyedi viselkedés leírása Attól függően, hogy ki- vagy bemeneti, 8 esetleg 16 bites perifériáról van szó, az adatbuszokhoz való csatlakozás változhat. Ha egy periféria nagyobb címtartományt foglal el, akkor a cím kiválasztást értelemszerűen módosítanunk kell. Az egyedi viselkedés leírásába tartozik természetesen a buszra kapcsolt to_dout regiszter értékeinek megfelelő beállítása is. Új periféria illesztésekor jó példaként szolgálhatnak a már meglévő egyszerű eszközök, mint a ledeket vagy kapcsolókat kezelő modulok. Az egyes perifériákhoz tartozó memóriacímeket az egységek Verilog nyelvű leírásában külön-külön is beállíthatjuk, viszont lehetőség van a rendszert összefogó fő modulban (xsoc.v) is megadni a megfelelő cím értékeket. Ez az utóbbi a javasolt megoldás, hiszen így sokkal könnyebben átlátható a teljes rendszer felépítése. A következőkben külön-külön ismertetem a jelenlegi kialakításban résztvevő periféria egységek működését. 43

45 Utasítás és adat memória 25. ábra: Utasítás- és adatmemória belső kialakítása Az utasításokat és adatokat a processzor egy belső blokk RAM memóriákból kialakított 4 kilobájt méretű terültről olvassa be. Amint azt a 25. ábrán is láthattuk, a processzor címtartományában a 0x0000-0x0FFF között érhető el a belső BRAM. A memória a többi perifériával közös adatbuszra kapcsolódik, nincs külön dedikált utasítás- és adatmemória busz. A processzor belső állapotai alapján el tudja dönteni, hogy éppen utasítást vagy adatot olvas be. Ezt a memóriaterületet két különálló, 8 bit szélességű memóriából alakítottam ki, melyek egymással párhuzamosan kapcsolva működnek. Ezáltal valósul meg a szavas és bájtos elérhetőség. A fejlesztés során a memória programmal való feltöltéséhez készítettem egy hex2brams nevű parancssori alkalmazást, amely HEX fájl formátumból blokk RAM tartalommá képes alakítani a programot. A kimeneti fájlban külön, elválasztva jelenik meg az MSB és az LSB blokk RAM-ok tartalma, amelyet a Verilog nyelvű leírásban be kell illesztenünk a BRAM inicializáló szekciójába. Ez a tartalom az FPGA eszköz konfigurációja után automatikusan elérhető, tehát lényegében egy ROM-szerű program memóriát valósít meg. 44

46 UART 26. ábra: UART belső felépítése A soros port-on való kommunikálást egy makró definíciókból álló, VHDL nyelven leírt UART egység teszi lehetővé. Az adó és vevő egység egyaránt 2 külön modulból tevődik össze, egy soros port kezelő részből és egy 16 karaktert tárolni képes FIFO-ból. [21] A VHDL kódot egy Verilog nyelvű leírásba ágyaztam, mivel hozzá kellett illeszteni egy adatátviteli sebességet (baud rate) beállító részegységet, valamint össze kellett kötni az xr16-os processzor buszrendszerével. A 12 MHz-es rendszer órajelből leosztva a soros kommunikáció as bit/másodperc sebességen, 8 adatbiten, paritás nélkül és 1 stop bit (8N1) használatával zajlik. IE: megszakítás engedélyezés DP: új adat érkezésének jelzése BF: tároló tele BH: tároló félig Hozzáférés Bitkiosztás Cím Név mód méret tx_data R/W 8 Soros adat kiküldése +1 tx_status R 8 BF BH +2 rx_data R 8 Legrégebbi fogadott adat +3 rx_status R/W 8 IE DP BF BH 4. Táblázat: UART belső regiszterei 45

47 A soros port olvasása működhet interruptosan, illetve lekérdezéses módszerrel. Az utóbbit akkor tehetjük meg, ha a processzornak van ideje ciklusosan beolvasni az UART vevő státusz bájtját. Ha adat érkezik a bejövő pufferbe, akkor azt a DP jel magas állapota jelzi. Ha lassabb órajelről működik a rendszer, vagy a végrehajtott program csak ritkán fordul a soros porthoz, akkor célszerűbb bevezetni a megszakításos kiolvasás használatát. A processzoron futó programok debuggolására az UART egység tartalmazza azt a funkciót, hogy egy ESC karakter fogadása esetén interruptot kér. Ennek engedélyezésére és tiltására az IE jel szolgál Hétszegmenses kijelző interfész BUSZ BUSZ INTERFÉSZ MUX 27. ábra: Hétszegmenses kijelző interfész belső felépítése A perifériák között megtalálható még egy hétszegmenses kijelző interfész is, amely általános 16 bites perifériaként kapcsolódik a processzor busz vezetékeihez. A modul az anódok vezérléséhez szükséges órajelet belül állítja elő, így valósul meg az időmultiplex meghajtás. Célszerű ezt az órajelet 100 Hz 1 khz-es tartományban tartani, mert így a frissítésből adódó vibrálást az emberi szem már biztosan nem tudja követni. A jelenlegi konfigurációban ez 1 khz-re van kapcsolva, így az egyes anódok 250 Hz-cel frissülnek. 46

48 A kijelző képes megjeleníteni 16 bites adatokat hexadecimális formában, valamint egy üzemmód váltással (mode) külön tudjuk kezelni az egyes anódok vezérlését. Cím Név Hozzáférés mód méret +0 anode0 R/W 8 +1 anode1 R/W 8 +2 anode2 R/W 8 +3 anode3 R/W 8 +4 hex_data R/W mode R/W 8 Leírás 0. anód szegmenseinek vezérlése 1. anód szegmenseinek vezérlése 2. anód szegmenseinek vezérlése 3. anód szegmenseinek vezérlése Hexadecimális adat megjelenítése 0: egész számok, 1: külön anódok 5. Táblázat: Hétszegmenses kijelző belső regiszterei Kapcsolók, ledek A rendszerhez tartozik még két 8 bites általános bemeneti és kimeneti periféria, ami a 8 kapcsoló illetve a 8 LED kezelésére szolgál. Ezek az egységek jó mintaként szolgálhatnak további perifériák rendszerillesztési kérdéseinek megoldásához. Az egyes egységek olvasását és írását a hozzájuk tartozó báziscím bájtos elérésével tehetjük meg SRAM vezérlő BUSZ BUSZ INTERFÉSZ SRAM INTERFÉSZ 28. ábra: SRAM vezérlő belső felépítése 47

49 A külső SRAM egység egy hagyományos aszinkron 128K x 8 bites, 10ns ciklusidejű memória. Ennek elérésére elő kell állítani a megfelelő engedélyező (cs, we, oe), cím illetve adat jeleket. A vezérlő a busz nwait jelén keresztül tud várakozást kérni az előírt buszciklus végrehajtására. így az SRAM vezérlőnek van ideje lekezelni a hozzá tartozó memóriát. Mivel a külső memória mérete nagyobb, mint amit a teljes címtartománnyal elérhetünk, ezért 4 memória lapot rendeltem hozzá az SRAM-hoz. Az egyes lapok között a vezérlő báziscímen található belső regiszterének írásával váltogathatunk. A külső memória tartalmát a 0x8000 és 0xFFFF címek között érjük el. Az olvasás bájtos és szavas elérés során is csak 1 órajelet vesz igénybe, viszont az írás bájtos esetben 2, szavas esetben pedig 3 órajeles művelet. Az utóbbi esetekben kell a busz várakozáskérő jelét logikai magas értékre állítani. Az alábbi három ábrán nyomon követhetjük az SRAM vezérlését szavas olvasás, szavas írás, valamint bájtos írás buszciklusok esetén. 29. ábra: SRAM vezérlő jelek változása szavas olvasás esetén 48

50 30. ábra: SRAM vezérlő jelek változása szavas írás esetén 31. ábra: SRAM vezérlő jelek változása bájtos írás esetén Cím Név Hozzáférés mód méret Leírás +0 page_sel R/W 8 Memória lapok kiválasztása 0x8000-0xFFFF SRAM R/W 8 / 16 Külső SRAM elérése 6. Táblázat: SRAM vezérlő belső regiszterei 49

51 Megszakításvezérlő egység BUSZ BUSZ INTERFÉSZ 32. ábra: Megszakításvezérlő belső felépítése A vezérlő 8 különböző megszakításkérést tud lekezelni fix prioritásos, vektoros formában, melyek elfogadása nem preemptív módon működik. Az egyes IRQ bemeneteket egy belső regiszter adott bitjének állításával lehet engedélyezni, valamint az egység rendelkezik még egy olyan regiszterrel is, amely a beérkező megszakításkérő bemenetek állapotát mutatja. A vezérlő a processzortól egy nyugtázó jelben megkapja, ha az adott interrupt kiszolgálása befejeződött, és ezt a jelet továbbítja az éppen kiszolgált egység felé, ami a periférián belül törli a megszakításkérést. A processzor számára egy másik belső regiszterben található a vector_offset 16 bites változó, ami azt az információt hordozza, hogy a bejövő 8 interrupt közül éppen melyikhez tartozó kiszolgáló rutint hajtsa végre a processzor. A regiszter alsó 4 bitjén jelenik meg a megszakítás sorszámának kétszerese, míg a felső 12 bit konstans 0 értéket vesz fel. Ennek a relatív értéknek a segítségével tudja a processzor, hogy a regiszterek mentése után a vektortáblában melyik kiszolgáló rutint kell végrehajtania. Az IT rendszerhez tartozó szoftvertámogatás részletes ismertetése az 5.5 fejezetben olvasható. 50

52 Cím Név Hozzáférés mód méret +0 vector_offset R IRQ_en R/W 8 +3 IRQ_status R 8 Leírás Aktuális IT vektorhoz tartozó eltolás Megszakítás engedélyezés Beérkező IRQ jelek állapota 7. Táblázat: Megszakításvezérlő belső regiszterei Töréspont logika BUSZ BUSZ INTERFÉSZ 33. ábra: Töréspont logika belső felépítése A programok debuggolását nagyban elősegítő periféria egység figyeli a címbusz tartalmát, és ha az megegyezik az előre beállított töréspont értékkel, akkor interruptot kér a processzortól. Ez lehetőséget biztosít arra, hogy a program működését egy adott ponton megállítsuk és megfigyeljük a rendszer és a processzor pillanatnyi belső állapotait. Ezek alapján verifikálhatjuk a program helyes működését és végigkövethetjük a rendszer reakcióit is a megadott parancsokra. A pipeline működésből adódóan megeshet, hogy a töréspont logika olyankor is kér megszakítást, amikor az adott címről beolvasott utasítás nem hajtódik végre. Ez abban az esetben fordulhat elő, ha például egy ugrás utasítást hajtunk végre. Ilyenkor ugyanis az ugrás után következő 2 utasítást is beolvassa a processzor, azaz megjelenik az utasítások címe a buszon viszont ezeket már nem fogja végrehajtani. Ezt a hiányosságot úgy lehetne kiküszöbölni, ha egy bonyolultabb töréspont logikát építenénk 51

53 be magába a processzorba. Ilyenkor, viszont ha nem akarjuk debuggolni a programot, akkor feleslegesen növelnénk meg a processzor hardverigényét. Kompromisszumos megoldásként inkább maradtam az első megvalósításnál, ahol a programfejlesztés során tisztában kell lenni a töréspont használatának fenti tulajdonságával. Cím Név Hozzáférés mód méret Leírás +0 match_reg R/W 16 komparálási cím +2 IRQ_en R/W 8 0.bit: megszakítás engedélyezés 8. Táblázat: Töréspont logika belső regiszterei Időzítő számláló BUSZ BUSZ INTERFÉSZ 34. ábra: Időzítő számláló belső felépítése A mikroprocesszoros rendszerek alapvető perifériaeleme az időzítő (timer) egység. Ennek segítségével állíthatóak be különböző hosszúságú várakozási idők, valamint esetleges operációs rendszer használatnál, az időzítő generálja a belső ütemezéshez szükséges jeleket. Ez egy viszonylag egyszerű 16 bites timer egység, de az alapvető funkciókat tökéletesen ellátja. Egy 10 bites előosztó szolgáltatja a különféle órajeleket a széles tartományban való időzítés eléréséhez. Kétféle módban működhet az időzítő: törli a 52

54 számláló értéket, ha egyezés volt (clear on compare match), vagy folytatja tovább a számolást. IE: megszakítás engedélyezés MD: mód választás (0-folytonos számlálás, 1-egyezéskor törlés) PRESC: órajel előosztó Cím Név Hozzáférés mód méret Leírás +0 match_reg R/W 16 Komparálási érték +2 counter R/W 16 Számláló aktuális értéke control R/W 8 IE MD PRESC 9. Táblázat: Időzítő számláló belső regiszterei PRESC Leírás Számláló tiltása clk/ clk/ clk/ clk/ clk/ clk/ clk/ Táblázat: Előosztó értékei Órajel leosztó modul Ugyan nem kimondottan periféria egység, de mégis meg kell említenünk az órajel leosztó modult, mert nélküle nem is működhetne a rendszer. Ez az egység egy DCM-et (Digital Clock Manager) tartalmaz, amely előállítja a pontos 12 MHz-es órajelet. A tényleges órajel frekvenciából (a Spartan-3-as kártya esetében 50 MHz-ből) történő leosztáshoz a szorzás és osztás paramétereket a rendszert összefogó fő modulban adhatjuk meg (adott esetben ez 6-tal szorzást és 25-tel való osztást jelent) Javaslat SystemVerilog nyelv alkalmazhatóságára A SystemVerilog nyelv használatával lehetőségünk nyílik az FPGA eszközökön belül megvalósított rendszerek magasabb szintű leírására. Így nagymértékben csökken a szükséges kód mennyisége, és egyúttal javul a rendszer áttekinthetősége is. Ez a leírási mód nem egy teljesen újfajta szintaktikával rendelkező nyelv, hanem amint az a 53

55 nevéből is adódik a Verilog hardver leíró nyelvre alapul. Így megőrzi az ezzel való kompatibilitást amellett, hogy számos új funkcionális elemet épít a nyelvbe. Legfőbb előnyei, hogy az SOPC rendszerekben használt komponensek közötti kommunikációt egy közös interfész megvalósításával egyszerűen biztosítani lehet, valamint ezzel a módszerrel tetszőleges buszstruktúra kialakítható. Ezáltal a huzalozás, és a hozzá tartozó protokollt megvalósító logikai elemek egy külön blokk formájában illeszthetők a rendszerbe. Ez elrejti a tényleges alacsony szintű megvalósítást, ami növeli az átláthatóságot és lehetővé teszi a rendszer magas szintű tervezését. A buszrendszer kialakításához két új nyelvi elem nyújt segítséget: az interfész és a buszlogika. Az előbbi teszi lehetővé, hogy a buszhoz tartozó jeleket csak egy helyen kelljen deklarálni, ezáltal csökken a redundancia, valamint a könnyebb javíthatóság. A buszhoz kapcsolódó egységek portlistájában interfész alkalmazásakor nem kell felsorolnunk az összes vezetéket, amelyek száma, komplex rendszerek esetén igen nagy is lehet hanem elegendő csak magát az interfészt behelyettesítenünk. Az interfész leírásán belül a kommunikációhoz használt protokollt megvalósító függvényeket definiáljuk, így az egyes periféria eszközöknek nem kell ismerniük magukat a buszhoz tartozó jeleket, elegendő csak ezeket a függvényeket meghívniuk. A buszlogika alkalmazásával fedhetjük el a rendszer leírásakor a különböző buszok alacsony szinten kódolt multiplexelését, az esetleges arbitrációt és annak mechanizmusát. Ez a megoldás nem csökkenti ugyan a kód mennyiségét, viszont az egységbe zárás növeli az áttekinthetőséget, és csökkenti a hibák lehetőségét is. Korábban láthattuk (17. ábra), hogy a buszvezetékek összekapcsolása során ügyelnünk kell azok megfelelő kapuzására. A következő ábrán az egyes modulok a buszlogikával a különböző interfészeken keresztül tartják a kapcsolatot, így a hardver leírása során nem kell bonyolult vezetékezést kialakítanunk. 54

56 35. ábra Buszlogika beillesztése külön modulként Lehetőségünk van még kevésbé magas szintű nyelvi elemek használatára is a kialakítás során, amelyek szintén csökkentik a szükséges begépelendő kód mennyiségét, ezáltal a redundanciát is. Ez az új nyelvi elem az implicit port huzalozás megvalósítása. Az egyes rendszer elemeket összefogó top esetünkben xsoc nevű modulban a huzalozási rendszer leírásához minden eszköz port listájában le kell írnunk a huzalozáshoz használt vezeték nevét. A System Verilog lehetőséget biztosít arra, hogy a portnév és a vezeték nevének egyezősége esetén nincs szükség a szokásos.portnév(vezetéknév) leírásra, hanem elegendő a.portnév használta. Ennek egy további változata, hogyha több ilyen vezetéknév-portnév párra teljesül az azonosság, akkor.* (pont csillag) jellel az összes pár helyettesíthető egyszerre. Ha vannak olyan jelek amelyek neve nem egyezik, akkor azokat továbbra is név szerint kell bekötni a huzalozási rendszerbe. Az alábbi 3 leírási mód teljesen egyenértékű. xsoc_in8 #(.BASE_ADDRESS(16'h6020)) switches (.clk(clk),.rst(rst),.word(word),.rnw(rnw),.addr(addr),.dout(dout_sw),.in8(switch)); xsoc_in8 #(.BASE_ADDRESS(16'h6020)) switches (.clk,.rst,.word,.rnw,.addr,.dout(dout_sw),.in8(switch)); xsoc_in8 #(.BASE_ADDRESS (16'h6020)) switches (.*,.dout(dout_sw),.in8(switch)); 55

57 Az XSOC rendszerben alkalmazott buszkialakítás igen egyszerű, és új periféria egységek csatlakoztatása sem okoz különösebb problémát mintaként használva a korábban elkészített komponenseket viszont a hordozhatóság, és a még könnyebb megérthetőség szempontjából megfontolandó a fenti System Verilog nyelvi elemek használata. A rendszer kialakításához használt fejlesztőrendszer (Xilinx ISE Project Navigator 8.2) sajnálatos módon nem támogatja a System Verilog nyelvet, ezért a teljes projektet át kellene ültetni egy másik környezetbe. [22] 5. A rendszerhez tartozó szoftver eszközök A korábbiakban megismert hardver felépítés egy igen összetett, sokféle feladatra alkalmas rendszer, viszont kijelenthetjük, hogy önmagában használhatatlan. Ha nincsen jó szoftvertámogatás egy rendszerhez, akkor bármilyen jó is lehet a hardver, egyáltalán nem fogjuk tudni kihasználni a képességeit. A processzor által vezérelt rendszerekben a központi egységen futó programok létrehozására mindenekelőtt szükségünk van egy assembler programra, ami a szöveges formában megadott utasításokból gépi kódot képes generálni. Egy assembly nyelven megírt program viszont igen komoly hardverismeretet igényel, hosszú a fejlesztési ideje, és egyáltalán nem hordozható, azaz nem futtathatjuk ugyanazt a programot egy másik típusú processzoron. Magasszintű beágyazott rendszereknél legelterjedtebb esetben C nyelven írt program viszont sokkal gyorsabban fejleszthető, hordozható, hiszen csak rendszer specifikus utasításokat tartalmaz, processzor specifikusakat viszont nem. Ennek hátránya, hogy egy igen bonyolult C fordítót kell a saját rendszerünkhöz igazítani, ami esetenként komoly feladatot jelenthet. Az assembly nyelvű programozással szemben pedig a lefordított kód hatékonyságában marad alul. Beágyazott rendszerekben előszeretettel alkalmazzák a két metódus keverékét, ahol az időkritikus részeket assembly nyelven, míg a program többi részét C nyelven írják meg. Egy processzor tervezésekor megfontolandó, hogy az adott eszközt milyen nyelven fogják programozni, mert az utasításkészlet megfelelő kialakításával elősegíthetjük egyik vagy éppen a másik módszert. Esetünkben az xr16-os processzor tervezője a C nyelvű programozhatóságot tartotta szem előtt. Ennek fényében elhagyhatta például a belső műveletek eredményére vonatkozó információt hordozó státuszregisztert, mivel ehhez C nyelven sosem fogunk tudni hozzáférni. Emellett még 56

58 megtehette azt az egyszerűsítést is, hogy csak az összeadás és kivonás műveletek állítják az előbbi jelző biteket, mivel minden feltételvizsgálatkor a C fordító be fog illeszteni a kódba egy összehasonlítás gyakorlatilag egy kivonás utasítást. Az alábbiakban ismertetem az xr16-oshoz tartozó assembler és C fordító alkalmazásokat, valamint az általam fejlesztett, úgynevezett debugger monitor programot, ami programok fejlesztését támogatja azáltal, hogy teljes működésüket követhetővé teszi a rendszeren belül Az assembler és linker ismertetése (xr16.exe) Ez az alkalmazás fordítja át a processzor által értelmezhető bináris formába a szövegesen megadott utasításokat. Érdekessége még az xr16-hoz tartozó assemblernek, hogy ellentétben az általános szokásokkal itt maga az assembler tölti be a linker szerepét is. Tradicionális esetben a C fordító által generált assembly fájlból az assembler egy effektív címek nélküli, úgynevezett tárgykód (object) fájlt generál, majd egy külön linker kapcsolja össze az egyes fájlokat, és számolja ki a tényleges címeket. Esetünkben az assemblernek meg kell adni az összes projektben résztvevő assembly fájlt fordításra, valamint ez fogja meghatározni azt is, hogy az egyes utasítások milyen memóriacímre kerülnek. Ezek alapján a program kimenetei a memórialista (LST), ami megmutatja, hogy melyik utasítás milyen címre került a fordítás után, valamint a gépi utasításkódokat tartalmazó HEX fájl. A memórialistában nyomon követhetjük a korábban említett pszeudo-utasítások behelyettesítését is. Az assembler maga egy igen egyszerű, C nyelven megírt program, aminek forráskódját a tervező mellékelte a rendszerhez, így egy későbbi kiegészítéshez újra tudjuk fordítani a programot. Erre szükségem is volt, hiszen mikor a processzort kiegészítettem az új szorzás és léptetés utasításokkal, az assemblert is meg kellett tanítani, hogy fel tudja dolgozni a szövegfájlban talált utasításokat. Ehhez természetesen teljesen fel kellett térképezni a program belső működését, melyet az alábbiakban röviden ismertetek, hogy segítséget nyújtson későbbi továbbfejlesztés esetén. Az assembler a parancssorban megadott egy vagy több szövegfájlban egyesével végigvizsgálja a sorokat. Itt címkéket és utasításokat különböztet meg. Az előbbiek esetén tesz egy bejegyzést a szimbólumtáblázatba, ahol majd később ki kell számolnia 57

59 az effektív címeket; az utóbbiaknál pedig egy nagy case szerkezetben kiválasztja, hogy mit is kell majd valójában gépi kódként behelyettesítenie. Olyan utasításoknál, amelyek címszámítást igényelnek (elágazás, ugrás, függvényhívás), szintén tesz bejegyzést a szimbólumtáblába. Ebben a case szerkezetben kellett elhelyeznem az új műveleteket, valamint fel kellett őket venni a processzor utasításait tartalmazó felsorolások közé, amelyek alapján az effektív gépi kódot generálja a fordító. Ezekhez az asm.c és xr16.h fájlokat kellett módosítanom. Itt nagyon figyelnünk kell, hogy az adott utasítás sorszáma, vagyis gépi kódja megfeleljen a processzorban deklarált értéknek. Minden új módosítást megjegyzésekkel jelöltem a program forráskódjában, így a későbbiekben ez már nagyon egyszerűen megtehető. Korábban a fordító nem tudta kezelni a távoli elágazás utasításokat, azaz, ha egy elágazás argumentuma kilógott a (-128) (+127)-es tartományból, akkor hibát jelzett. Ennek a hibának a kiküszöbölésére használtam egy másik fejlesztő által előkészített FARBRANCH utasításokat, amelyek ténylegesen egy ellentétes irányú elágazásból, valamint a kívánt címre történő ugrásból állnak össze. fblt L2 bge skip bge skip j L2 imm L2 15:4 skip: jal r0,l2 3:0 (r0) skip: Mivel az effektív címek kiszámolása csak a fordítási folyamat legvégén történik, ezért a hibás elágazás utasításokat már nem tudjuk szoftveres úton kicserélni. A jelzett hibás elágazások helyére BRx helyett FBRx utasítást kell írnunk, ahol x az elágazás típusa, majd újra kell fordítanunk az assembly fájlokat. Az assembler eredetileg tartalmazott még egy nagyon egyszerű szimulátor programot is, ami tulajdonképpen egy szövegfájlba ki tudta írni a programvégrehajtás órajelenkénti menetét. Igen nagy hiányossága volt, hogy nem tudott sem megszakításokat sem pedig külső bemeneteket kezelni, tehát például nem lehetett megadni neki, hogy a perifériákról milyen értékeket olvasson be. Ezt a szimulátort nem frissítettem az új utasításokkal, így hibát jelez, ha ilyen utasításokat talál a programkódban. Mivel készítettem a rendszerhez sokkal fejlettebb alkalmazásfejlesztési eszközöket, ezért a későbbiekben ennek a programrésznek a használatát nem javaslom, és nem is tervezem támogatni. 58

60 Van néhány hiányossága is az assemblernek, mivel a dokumentációban ugyan hivatkoznak rá, de nem lehet külön megadni, hogy melyik assembly programrész milyen típusú (adat, vagy kód) memóriaterületre kerüljön. Ennek segítségével akár külön lehetne választani az adat és utasításmemóriát, így lehetőség lenne a Harvardarchitektúra kialakítására. A másik hibája pedig, hogy nem lehet megadni, hogy a lefordított programkód milyen címtől kezdődjön. Tehát bármilyen utasítássort is írunk, az mindig a 0-s memóriacímen fog kezdődni. [14] 5.2. A C fordító (lcc-xr16.exe) A magas szintű programozáshoz elengedhetetlen a már korábban említett C fordító használata. A széles körben ismert GCC fordítót már számos nagyobb processzorcsaládhoz igazították hozzá; a tervező az illesztés bonyolultsága miatt inkább a kevésbé ismert, viszont egyszerűen portolható LCC fordítót választotta a célra. [23] Egy C fordító fő feladata, hogy a C nyelven megírt programokat az adott processzor által kezelhető, érthető assembly nyelvű formába alakítsa. Így lehetőségünk van ugyanazon program futtatására több különböző platformon, amire assembly nyelven nem lehetne módunk. Ezzel ugyan nagyon flexibilissé válik a programok fejlesztése, viszont helyenként mégis jobb alternatívát nyújt az assembly programozás. Olyan esetekben fordulhat ez elő, ahol például időkritikus alkalmazásokat fejlesztünk. A C nyelven leírt programokból nem tudunk egyszerűen következtetni a futási időre, mivel a fordítótól függ, hogy éppen milyen optimalizálással tudta átalakítani az adott funkcionalitást assembly utasításokká. Emellett, az assembly nyelven megírt program általában sokkal kevesebb műveletből tevődik össze, mivel olyan utasításokat is ki tudunk használni, amit C programozás során nem is tudunk leírni. Erre jó példaként szolgálhat az AVR mikroprocesszoroknál használt SWAP utasítás példája, ahol a 8 bites operandus alsó és felső 4 bitjét megcseréljük. 59

61 36. ábra: SWAP utasítás C és assembly nyelvű leírása Rendszerint a programok olyanok, hogy a teljes futási ciklusuk alatt csak bizonyos időlimiteket kell betartaniuk, ezért azt a megoldást szokták alkalmazni, hogy a program teljes leírását C nyelven végzik, az időkritikus szekciókat pedig assembly utasításokként illesztik be a C kódba. Sajnos erre az LCC esetében nincs lehetőség. Visszatérve a C nyelvű programok hordozhatóságára, az egyes eszközök megkülönböztetését úgy végezhetjük, hogy először telepítjük a megadott processzorhoz tartozó specifikus bináris fájlokat, majd fordításkor egyszerű paraméterezéssel kiválasztjuk a céleszközt. Egy C fordító rengeteg, szintén C nyelvű forráskódból tevődik össze, valamint egy úgynevezett machine description fájlból, ami hordozza a kiválasztott processzorra jellemző összes tulajdonságot. Tehát ezek alapján a megfelelő végrehajtható fájlok generálása viszonylag egyszerűen zajlik, mivel csak ezt a leíró fájlt kell kicserélnünk, majd újra kell fordítanunk a teljes projektet. Ez a machine description fájl tartalmazza a processzor olyan specifikus tulajdonságait, mint például a regiszterek száma, adatok bitszélessége, stb., valamint azt, hogy milyen típusú C műveletekhez milyen konkrét assembly nyelvű utasítást kell hozzárendelnie a fordítónak Illesztés menete A fentiek alapján evidens, hogy az xr16-os processzorhoz is a tervezőnek készítenie kellett egy ilyen leíró fájlt, majd újra kellett fordítania az LCC-hez tartozó C 60

62 nyelvű forrásokat, melynek eredményeként megkapta a végrehajtható fordítóprogramot. Az LCC fordító korábban támogatott processzorcsaládjai közül a MIPS leírója szolgált alapul az xr16.md fájl készítéséhez. Itt át kellett írni a korábbi adatszélességet 32-ről 16 bitesre, valamint a regiszterek számát is csökkenteni kellett. Ezek után a tervező a következő regiszter konvenciókat választotta a programok kezeléséhez: [14] Regiszter Funkció Mentési eljárás r0 konstans 0 érték - r1 assembler számára fenntartva - r2 függvény visszatérési érték - r3 első paraméter hívó menti r4 második paraméter hívó menti r5 harmadik paraméter hívó menti r6 átmeneti tároló hívó menti r7 átmeneti tároló hívó menti r8 átmeneti tároló hívó menti r9 átmeneti tároló hívó menti r10 lokális változó hívott menti r11 lokális változó hívott menti r12 lokális változó hívott menti r13 stack pointer (sp) hívott menti r14 megszakítás visszatérési cím - r15 szubrutin visszatérési cím hívott menti 11. Táblázat: Regiszterhasználati konvenciók Ez egy igen fontos lépés az illesztésnél, mivel ezek alapján tudja a C fordító, hogy hogyan kezelje a programok általános működését. Például, hogy milyen változókat tároljon regiszterekben, melyeket pedig a stack területen, vagy milyen regiszterek használhatóak fel függvények kezelésére és így tovább. Nem megfelelő regiszter hozzárendeléssel komolyan ronthatjuk a lefordított programok hatékonyságát. Végül pedig össze kell kapcsolni a megfelelő művelettípusokat a hozzájuk tartozó assembly utasításokkal. A következő példán láthatjuk, hogy hogyan is jelenik meg ez az xr16-os processzor leíró fájljában. 61

63 37. ábra: Utasítások leképezése assembly kódra a leíró fájlban Az új szorzás és regiszter-relatív léptetés utasításokat is hasonlóan kellett beilleszteni a leíróba. A korábbi rendszerben az ilyen műveletek esetén egy függvényhívást helyettesített be a C fordító, így jelezve, hogy az adott utasítás megvalósítását szoftveres úton akarjuk megoldani. Ez a megoldás még mindig igaz az osztás és maradékképzés műveletekre, valamint néhány 32 bites adatszélességet használó műveletre is. (pl. maradékképzésre: a = b%c call _modi2) Az LCC újrafordításához a Visual Studio 6-os programot használtam, ennek is egy parancssori fordítóját, mivel a tervező is ezt ajánlotta a felhasználói dokumentációban. Az újrafordítás menete, hogy az lcc 4.1. forrásfájljait bemásoljuk egy meghajtón egy src nevű könyvtárba, ezen belül pedig létrehozunk még egy build almappát is. Ez utóbbit hozzáadjuk a rendszer környezeti változóihoz, majd végrehajtjuk a fordítást a rendszerhez adott makefile-lal, ami tartalmazza a különböző fordítási paramétereket. Ennek eredményeképpen a megadott build könyvtárban létrejönnek az adott végrehajtható programok, amik már az xr16-os processzort támogatják. [15] Az LCC fordító egy könnyen kezelhető, aránylag megbízható C fordító, a használata során viszont fény derült néhány hibára. A legfőbb hiányossága a függvényhívások terén adódik, mivel a fordító pre-processzora nem szűri ki azt a hibát, hogy nem deklarált függvényt hívunk meg. Így előfordulhat olyan eset is, hogy ugyanazt a függvényt többféle paraméterezéssel akarjuk használni, ami ugye a C nyelv határain belül nem megengedett, vagy akár az adott függvény nem is létezik. A másik probléma, hogy hibát jelez, ha egy függvényen belül inicializálni próbálunk egy char típusú, 1-nél nagyobb elemszámú tömböt. Ezeket a későbbiekben korrigálni kell, de 62

64 ahhoz a C fordító tüzetesebb vizsgálata szükséges, ami meghaladja ennek a diplomatervnek a kereteit Szoftver részegységek A C nyelven megírt alkalmazás azonban önmagában még nem futtatható a processzoron, mivel számos, hardverhez kapcsolódó beállítást nem tudunk magas szintű nyelven megadni. Ezek közé tartozik a reset utáni viselkedés leírása, a stack pointer inicializálása, valamint a megszakítások kezelése. Erre a célra szolgál az úgynevezett C runtime library, azaz C futtatási környezet. Ez egy assembly nyelven megírt programrészlet, ami a fordítás során a C nyelvről lefordított kód elé kerül majd az utasításmemóriában. Mivel a reset esemény lezajlása után a program futása a 0-s címtől kezdődik, ezért ez a programrész inicializálni tudja a beállításokat, és ezután már kezdődhet is a felhasználói program végrehajtása. Attól függően, hogy éppen milyen környezetben szeretnénk futtatni a programunkat, többféle lehetőség közül választhatunk. A minimális beállításokat tartalmazó környezet (CRT0) csak a stack pointert állítja be a kezdeti címre. Mivel a stack terület az alacsonyabb címek felé növekszik, ezért a rendszerben a mutató alapértéke a közös utasítás- és adatmemória utolsó szavas címe (0x0FFE) lesz. Ennek beállítása után pedig egy ugrás utasítás következik a main függvényre, ahol elkezdődik az alkalmazás futtatása. Mivel a megszakításokat nem kezeli ez a környezet, figyelni kell arra, hogy a megszakításvezérlő ne engedélyezze a kéréseket, hiszen ez hibás végrehajtást eredményezne. A következő szint (CRT1) az előzőeket kiegészítve már rendelkezik interrupt kezeléssel, viszont csak 1 kiszolgáló rutint tartalmaz. Erre akkor lehet szükség, ha a processzor köré épített rendszer nem tartalmazza a külső megszakításvezérlőt, és az egyetlen megszakításkérés vonal közvetlenül a processzor IRQ bemenetéhez kapcsolódik. A harmadik fokozat (CRT2) már tartalmazza a megszakításvezérlő által biztosított 8 különböző forrás kiszolgálási lehetőségét is. Ebben a környezetben az egyes kiszolgáló rutinokat az isrx neveken tudjuk elérni, ahol X az adott kérés sorszáma. Az utolsó környezet (CRT3) pedig a szoftverfejlesztés támogatását célozza meg. Ez felhasználja a külső töréspont logikát és megszakításvezérlőt is, tehát csak ezzel a 63

65 hardver felépítéssel alkalmazható. A reset lezajlása után a kezdeti stack pointer inicializáláson kívül még töréspontot helyez el a main függvény kezdőcímére, és engedélyezi a 0-s megszakítást is, amire a töréspont logika IRQ jele kapcsolódik. Ezáltal a program indításakor azonnal egy töréspont-megszakítás generálódik, leállítva a felhasználói program futását, ami lehetővé teszi a későbbi lépésenkénti vizsgálatot. A programfejlesztés könnyítése céljából a szoftverkialakításhoz tartozik még egy úgynevezett könyvtári függvényeket tartalmazó kiegészítés is (libxr16). Ezt opcionálisan hozzácsatolhatjuk a megírt programhoz, hiszen ebben olyan hasznos funkciók találhatóak, mint a soros port kezelése, valamint egy úgynevezett debugger monitor is, aminek ismertetése a következő fejezet témája. A soros portról karakterek egyesével történő beolvasása, kiírása támogatott; illetve még egy leegyszerűsített printelő függvényt is biztosítottam, amivel egyszerű szöveget tudunk küldeni a soros portra. A normál C könyvtárban megadott printf függvény megvalósítása igen nagy erőforrást igényelne, ezért ezt a funkciót nem implementáltam. A későbbiekben ennek a könyvtárnak a része lehet még a különféle osztási műveletek szoftveres megvalósítása, adott idejű várakozást biztosító függvények, esetleg még a dinamikus memóriafoglalás megoldása is. Ez a kiegészítés azért nem magában a CRT-ben található, mivel így ezek a függvények C nyelven is megírhatók, módosíthatók. Esetleges változtatáskor pedig csak újra kell fordítani az adott forrásfájlt az LCC segítségével. Az CRT3 és a libxr16 használata a teljes 4 KB-os programmemóriából összesen 512 bájtot emészt fel. A C nyelvű programfejlesztéshez még nagy segítséget nyújt a rendszerhez adott header fájl (xsoc.h), ami tartalmazza a teljeses XSOC rendszer jellemzőit. Itt megtalálhatóak az egyes perifériák címei, belső regiszterei, valamint még a hétszegmenses kijelző karakteres vezérléséhez egy betűkészlet is. A címeket makróként használva férünk hozzá az egyes periféria eszközökhöz, vagyis például a ledekre történő íráshoz a felhasználói programban csak azt kell leírni, hogy LED = 3, ahelyett, hogy *(char*)0x6030 = 3. Így a programkód sokkal olvashatóbb lesz, és esetleges hardvermódosítások után pedig csak ezt a fejléc fájlt kell frissítenünk az új értékekkel Alkalmazás fejlesztés támogatása A fentiek alapján már rendelkezünk az xr16-os processzorhoz tartozó C fordítóval és assemblerrel, valamint a megfelelő hardver kialakításhoz illő 64

66 futtatókörnyezettel is, tehát megkezdhetjük a processzoron futó alkalmazások fejlesztését. Ilyenkor viszont még szembetaláljuk magunkat azzal a problémával, hogy a lefordított gépi kódot bele kell töltenünk az utasításmemóriába. Emellett fontos az is, hogy a megírt program szemantikai helyességét ellenőrizni tudjuk, vagy az esetleges hibákat könnyen kideríthessük. Ezen problémák megoldására 3 különböző komplexitású lehetőségünk adódik. Az első, hogy az assembler által generált HEX fájlt betöltjük a Verilog nyelven leírt blokk RAM-ok inicializáló szekciójába, és újraszintetizáljuk a teljes hardver projektet. Ezután a kész FPGA tartalmat letöltve az adott eszközbe, azonnal elindul az alkalmazás a processzoron. Ehhez a megoldáshoz készítettem egy úgynevezett hex2brams.exe programot, ami az első paraméterként megadott HEX fájlból memóriatartalmat készít. Mivel az utasításmemória 2 darab 8 bit széles RAM-ból épül föl, ezért a program a kimenetként (második paraméter) megadott szövegfájlban is ilyen formában hozza létre az inicializáló szakaszokat. Ezt utána már csak be kell másolni az adott memóriák Verilog leírásába. Ez a megoldás ugyan igen egyszerű lépéseken alapszik, azonban a rendszer teljes újragenerálása nagyon sok időt vesz igénybe. Emellett még nagyon nehézkes a program futásának vizsgálata is, mivel semmilyen információt nem tudunk visszanyerni a hardverből. Ezért lényegében ez a megoldás csak arra szolgál, hogy olyan induló programtartalommal töltsük fel a memóriát, ami már teljesen hibátlan. A második lehetőség, hogy egy úgynevezett debugger monitor programot működtetünk a processzoron, ami egyfajta futtatókörnyezetként szolgál az alkalmazói programok fejlesztéséhez. Általában olyan funkciókat biztosít, mint például programletöltés és futtatás, memóriatartalom lekérdezés, lépésenkénti programvégrehajtás, stb. Így a tényleges hardverben nyomon tudjuk követni a program viselkedését, ezzel támogatva a hibák keresését. Nagymértékben gyorsítja az alkalmazások fejlesztését, mivel azonban a debugger monitor is a programmemóriába kerül, ezért csökkenti a futtatható alkalmazói programok méretét. A felhasználóval történő kommunikációt általában a soros port biztosítja. A számítógépen futó terminál program segítségével különböző, általában azonos formátumú parancsokat megadva érjük el a kívánt funkciókat, például a letöltést (download) egy d betű elküldésével. Viszont minél több funkciót szeretnénk beépíteni, annál nagyobb részt fog elfoglalni a memóriából csak a debugger és annál kisebb lehet a felhasználói program. 65

67 Egy alapfunkciókkal rendelkező monitor programot készítettem a rendszerhez, ami képes volt HEX fájl tartalom letöltésére, a memória szavas és bájtos írására és olvasására. A parancsok értelmezése és a HEX fájl szöveges formátumból bináris értékekké konvertálása önmagukban nem komplex feladatok, mégis igen sok utasítással írhatók csak le. A programmemóriában ez egy 1,7 kilobájtos területet foglalt el, míg a rendszer jelenlegi memóriakapacitása összesen csak 4 KB. Ez azt jelenti, hogyha még további funkciókkal bővítettem volna a debuggert, akkor az akár több mint a teljes memória felét is elfoglalhatta volna. Ez a hatalmas erőforrásigény az alkalmazásfejlesztést nemhogy elősegítette, hanem inkább korlátozta volna. Mivel az alkalmazói program megírását jellemzően egy számítógépen végezzük, aminek a rendszerhez képest minden téren jóval nagyobb a kapacitása, ezért célszerű lehet ennek az erőforrásait is kihasználni a program futásának vizsgálatára. Ezt úgy lehet megvalósítani, hogy a számítógép elvégzi a bonyolultabb műveleteket, míg a céleszközön csak egy nagyon egyszerű szolga program fut, aminek segítségével a számítógép végre tudja hajtatni a megfelelő parancsokat. Ennek a szolga programnak az erőforrásigénye jóval kisebb, mégis a számítógép segítsége miatt jóval bonyolultabb feladatokat is el tudunk végezni, mint az előbbi esetben. A mai követelményeknek is jobban megfelel, mivel sokkal könnyebben és látványosabban tudjuk szemléltetni a belső állapotokat, mint korábban. Egy grafikus környezet használata jóval gyorsabban elsajátítható, mint egy bonyolult parancssori alkalmazás, ezért ez sem hátráltatja a programfejlesztést. Ennek a számítógépen futó programnak a kifejlesztése ugyan sokkal több időt vesz igénybe, mint a korábbi két megoldás megvalósítása, de a fenti előnyök miatt végül ezt a megoldást választottam. Részletes ismertetése a grafikus környezetre vonatkozó, 6. fejezet témája lesz Megszakításrendszer szoftvertámogatása A processzorok megszakításstruktúráját általában két nagyobb csoportba oszthatjuk: lekérdezéses, és vektoros. Az előbbi kialakítás általában 1 közös megszakításkérő bemenettel rendelkezik, amire az összes periféria egy logikai kapun keresztül kapcsolódik. Akármelyik periféria is kért megszakítást, a program végrehajtása a közös kiszolgáló rutinra ugrik, ahol egyesével le kell kérdezni az összes perifériát, hogy éppen ő kért-e interruptot. A lekérdezések sorrendje egy fix prioritásos rendszert alakít ki, hiszen ha egyszerre érkezik 2 különböző kérés, akkor az jut érvényre 66

68 előbb, amelyiket korábban kérdezzük le. Ez a módszer ugyan csökkenti a komplexitást, hiszen csak 1 bemenetre van szükségünk, viszont sok megszakításkérő forrás esetén nagymértékben megnyújthatja a kiszolgálási időt. T kiszolg = T vár + T ment + n*t lekérd T kiszolg : a megszakítás beérkezésétől a kiszolgáló rutin meghívásáig eltelt idő T vár : a megszakítás beérkezésétől az elfogadásig eltelt idő T ment : a belső állapot mentéséhez szükséges idő T lekérd : az egyes források lekérkedéséhez kellő idő n: a magasabb prioritású források száma A másik megvalósítás a vektoros megszakításkezelés. Ilyenkor minden megszakításhoz külön bemenet tartozik, hogy egyértelműen azonosítani lehessen, hogy éppen melyik forrásból érkezett a kérés. Ilyen esetben megszakításkor a programszámláló értéke egy megszakításvektorokat tartalmazó táblázat megfelelő címére ugrik, ahol az adott interruptot kiszolgáló rutin meghívása található. A kiszolgálási idő minden megszakításforrásra azonos lesz, hiszen a fenti egyenlet utolsó tagját elhagyhatjuk, viszont nyilvánvalóan a hardver bonyolultsága nő a kérés forrásának automatikus felismerése miatt. Az xr16-os processzor megszakításrendszerének tervezésekor oktatási mintarendszer lévén fontos szempont volt a bővíthetőség és az egyszerű használat. A korábbi megszakításrendszer összesen 1 kérést tudott kezelni, ami indokolta volna az első, lekérdezéses módszer használatát, viszont ez számos problémát hordozott magában. Ha új megszakításkérő perifériát csatlakoztatott volna a felhasználó a rendszerhez, akkor a processzor futtatókörnyezetébe is bele kellett volna építenie annak lekérdezését. Ezen kívül még az összes lekérdezett periféria címe fixen bele lett volna kódolva a futtatókörnyezetbe, tehát az ezekhez kapcsolódó hardverkiépítésben bekövetkezett változást abban is frissíteni kellett volna. Ezen okok miatt döntöttem a vektoros megszakításkezelés mellett. A források számának bővítésére készítettem a külső megszakításvezérlő periféria egységet, amely már 8 interrupt kérő bemenettel rendelkezik és fix prioritásos módon engedélyezi a különböző forrásokból érkező kéréseket. A megszakítások engedélyezése nem preemptív módon történik, vagyis az éppen futó kiszolgálást nem 67

69 tudja egy magasabb prioritású kérés megszakítani. A preemptív kezeléshez a processzoron belül külön belső regiszterre lenne szükség, ami jelzi, hogy éppen melyik megszakítási szint van kiszolgálás alatt. Emellett még egy belső, szoftveresen állítható megszakítás engedélyező jel is elengedhetetlen lenne. Ezek a kiegészítések lehetővé tennék az egyes interruptok lezajlásának vizsgálatát is, hiszen így ezeket is lehetne akár lépésenként végrehajtani, viszont nagymértékben növelnék a rendszer komplexitását, ezért végül nem implementáltam őket. A megszakítás hatására a programszámláló értéke a hardverben kódolt 0x0010- es értéket fogja felvenni, ahol megkezdődik az összes interrupttal kapcsolatos tevékenység elvégzése. Ezek közé tartozik a regiszterek mentése, az interrupt kezelő függvény meghívása, a regiszterek visszaállítása, valamint visszatérés a program megszakítás előtti pontjára. A regiszterek eltárolása egy 15*2 bájtos, előre lefoglalt területre történik, mivel a 16 regiszterből az R0 értéke konstans 0. Elegendő lenne viszont ilyenkor csak azokat a regisztereket tárolni, amelyeket a C fordítóhoz tartozó regiszter konvenciók alapján (11. táblázat) a hívó függvény köteles menteni (caller save). A hívott függvény által használt callee save regiszterekről a kiszolgáló rutin biztosan gondoskodni fog. Későbbi debuggolási okokból viszont az összes regiszter tartalmának ismerete és esetleges állítása is igen fontos lehet. A vektoros kialakítás miatt meg kell tudnunk határozni, hogy pontosan melyik forrásból is érkezett a kérés. Mivel a processzornak csak egy megszakításkérő bemenete van, ezért ezt az információt a külső megszakításvezérlő egyik regiszterének olvasásával tudjuk lekérdezni. A regiszter tartalma tulajdonképpen egy vektortáblacímet tartalmaz, ahol a megfelelő kiszolgáló rutinok címei találhatóak. Lényegében a vektortáblában minden kiszolgáló rutinra egy függvényhívás szerepel, melyek utasításkódjában található 12 bites konstans hordozza a megfelelő függvény címét. Tehát az interrupt vezérlőből kapott címről beolvashatjuk a kiszolgáló rutin címét egy regiszterbe, majd ezt 4-gyel balra léptetjük, hogy az effektív 16 bites címet megkapjuk. Ezek után egy ugrás és linkelés (JAL) utasítással meghívjuk a megfelelő kiszolgáló rutint az előre feltöltött regiszterben tárolt címről, ami elvégzi az adott megszakításhoz tartozó feladatokat. A kiszolgálás lezajlása után visszaállítjuk a regisztereket, majd egy RETI utasítással folytatjuk a program futtatását onnan, ahol az megszakadt. A 40. ábrán részletesen nyomon követhetjük a megszakítás menetét. 68

70 UGRÁS A 0x0010-ES CÍMRE REGISZTEREK MENTÉSE IT VEZÉRLŐ LEKÉRDEZÉSE FŐPROGRAM MEGSZAKÍTÁS UGRÁSI CÍM KIKERESÉSE A VEKTORTÁBLÁBÓL VISSZATÉRÉS RETI UTASÍTÁSSAL UGRÁS A KISZOLGÁLÓ RUTINRA REGISZTEREK VISSZAÁLLÍTÁSA KISZOLGÁLÓ RUTIN 38. ábra: Megszakításkérés kiszolgálásának menete Erre a többlépcsős ugrási kialakításra azért van szükség, mert a program írásakor nem lehet meghatározni az egyes kiszolgáló rutinok helyét a memóriában. Ezzel a megoldással viszont minden fordításkor a helyes memóriaérték kerül bele a vektortáblába. Az assemblernek van egy olyan hibája, hogy nem figyelmeztet, ha ugyanazt a címkét többször is deklaráltuk a programban, hanem egyszerűen csak a legutolsó bejegyzés effektív címét helyettesíti be az adott hivatkozások helyére. Ezt a tulajdonságot viszont a megszakításoknál előnyösen tudjuk kihasználni. Ha egy megszakítást nem akarunk kezelni és nem írjuk meg C nyelven a hozzá tartozó kiszolgáló rutint, akkor a fordítás során hiba keletkezik, mivel a vektortáblában definiálva van az adott rutinra való ugrás. Ezt elkerülendő, előre megadjuk az összes függvényt, amelyek mind csak egy return utasítást fognak tartalmazni. Így ha olyan megszakítás érkezik, amit nem kezelünk, az sem fog gondot okozni. Amennyiben pedig kezelni akarjuk az adott forrást, akkor a C-ben megírt függvény már egy későbbi bejegyzés lesz a kódban, ezért a megszakítás beérkezésekor már ez hajtódik végre. 69

71 A megszakításrendszer fenti kialakítása megfelel a kiindulási céloknak, vagyis könnyen illeszthetünk új megszakításkérő perifériát a rendszerhez, és egyszerűen megírhatjuk az adott interruptot kezelő szoftvert is. Esetleges hardver átalakításkor csak arra kell figyelnünk, hogy a futtatókörnyezetben az interruptvezérlő címét frissítsük. 6. A grafikus szoftverfejlesztő környezet Amint azt korábban említettem, a szoftverfejlesztés támogatására egy számítógépen futó grafikus környezetet terveztem. Ennek a felületnek számtalan funkciót kell ellátnia: forrásfájlok szerkeszthetősége, lefordítása, programletöltés, regiszterek tartalmának megjelenítése, memóriatartalom kijelzése, töréspont elhelyezése a programban, léptetés, stb. A szoftver futásának végigkövetését egy szimulátor segítségével is megtehetnénk, viszont a processzor és a hozzá kapcsolódó rendszer modellezése egy igen komplex feladat lenne. Emellett még a bővíthetőséget is korlátozza, hiszen egy esetleges új hardver periféria egység felvételekor annak teljes modelljét be kellene építenünk a szimulátorba is. A másik lehetőség a programok vizsgálatára a tényleges rendszerben történő tesztelés (in circuit debugging). Ezzel a módszerrel a fejlesztés mobilitása csökken, hiszen mindenképp szükség van magára a vizsgált hardverre is, viszont bizonyosak lehetünk benne, hogy a kapott viselkedés a valós működést mutatja. Mivel itt nincs szükség modellek építésére, ez nagymértékben egyszerűsíti magát a fejlesztőrendszert, azonban ki kell alakítanunk egy kommunikációs protokollt a programfejlesztéshez használt számítógép és a hardver egység között A kommunikáció felépítése Az általánosan elterjedt debugger programokhoz hasonlóan, itt is a soros porton keresztül létesítünk kapcsolatot a számítógép és a vizsgált eszköz között. A kommunikációban a számítógép adja ki a parancsokat, míg az xr16-on futó program szolgaként végrehajtja azokat. A hardver platformon futó program egyszerűsítése érdekében igen kevés, összesen 5 parancs áll rendelkezésünkre, viszont már ezekkel is végre tudjuk hajtani az összes, fentiekben felsorolt feladatot. A memória szavas és bájtos írásán és olvasásán kívül még a futtatás opció került bele a szolgaprogramba. A 70

72 rendszer működése a korábban említett CRT3-as futtatókörnyezetet használatát igényli a könyvtári függvények kiegészítésével. Az xr16-on a már korábban említett debugger monitor szolgálja ki a számítógép kéréseit. A monitor program futása a 0-s megszakítás hatására indul el. Ezt a megszakítást két periféria egység kérheti: a töréspont logika és a soros port kezelő periféria. Az előbbi abban az esetben, ha a beállított cím megegyezik a buszon látható értékkel, míg az utóbbi akkor, ha a soros vonalon egy ESC karakter érkezett. Mivel a program megszakításként fut, ezért az 5.5. fejezetben tárgyaltak szerint a megszakítás beérkezésekor aktuális regiszter értékeket egy fix memóriaterületre menti a processzor. Korábban láthattuk, hogy a különféle perifériák belső regiszterei is a 64 kilobájtos memóriatartományba ágyazottan helyezkednek el. Világosan láthatjuk, hogy a különféle memóriaműveletek elegendő funkciót biztosítanak a regiszterek, a perifériák és a memória vizsgálatához egyaránt. A debugger parancsainak felépítése 3 részből tevődik össze: a parancskódból, a cím- és az adatmezőből. A cím utóbbi két értéke mindenképp 16 bites, ezért ez nyilvánvalóan két soros karakterből tevődik össze, ahol a felső bájt érkezik először. Az adat értéke lehet 8 illetve 16 bit hosszúságú egyaránt, attól függően, hogy bájtos vagy szavas írást hajtunk végre. Az alábbi összefoglaló táblázatban szerepelnek a debugger által támogatott parancsok. Parancs kód cím adat szavas írás "0" 16 bit 16 bit bájtos írás "1" 16 bit 8 bit szavas olvasás "2" 16 bit - bájtos olvasás "3" 16 bit - visszatérés "4" Táblázat: A debugger parancsai A debugger futásának kezdetekor letiltja a töréspont és a soros port megszakításokat. Ezzel a lépéssel nem okozhat problémát, ha a soros porton további ESC karakternek megfelelő érték érkezik, például memória írásakor. Ezek után egy ESC karakter soros küldése jelzi a számítógép felé, hogy a rendszer készen áll a parancsok fogadására. A programfejlesztő környezet letöltés, periféria, memóriaterület, és regisztertartalom-vizsgálat, valamint töréspont-elhelyezés funkcióihoz a kommunikáció során elegendő az egyszerű szavas vagy bájtos hozzáférés alkalmazása. Az éppen 71

73 vizsgált program folytatásához természetesen a 4-es kódú parancsot küldi el a számítógép az xr16-os processzornak. A töréspont nélkül futó program megállítását a soros porton küldött ESC karakterrel tehetjük meg. A program léptetése már két műveletet igényel. A debuggerbe való belépéskor, a megszakítás miatt az R14-es regiszter tartalmazza azt a címet, ahová majd vissza kell térnie a programnak. Ha ezt a címet állítjuk be a következő töréspontnak, majd kiadjuk és végrehajtjuk a folytatás parancsot, akkor azonnal törésponti megszakítás generálódik. Így közvetlenül egy utasítás végrehajtása után visszalépünk a debugger programba. A vizsgált program újraindítása is két parancsból tevődik össze. Elsőként felülírjuk 0-val az R14-es regiszter tartalmát az elmentett memóriaterületen, majd kiadjuk a folytatás parancsot. Ezáltal a program nem onnan folytatódik, ahol megszakadt, hanem a 0-s címről újra kezdődik a futás. Ez gyakorlatilag olyan hatással bír, mintha egy hardver reset zajlott volna le a rendszerben. Tehát a CRT3-as futtatókörnyezetből adódóan töréspontot helyezünk el a main függvény belépési pontjára, így induláskor azonnal egy 0-s prioritású megszakítás keletkezik, ami által újra visszalépünk a debuggerbe Külső fordító eszközök paraméterezése A C nyelvű programok fejlesztéséhez természetesen használnunk kell a külső fordító programokat, az LCC-t és az assemblert is. Ezek paraméterezése az egyszerűbb kezelés érdekében a felhasználói felület használata során nem állíthatók a felhasználó által. A programok telepítése során a számítógép környezeti változói közé bekerül az LCC fordító bináris fájljait tartalmazó könyvtára is, amit később a parancssorból a %LCCDIR% utasítással érhetünk el. Az LCC fordítót úgy állítottam be, hogy az egy egyedi C forrást assembly fájlra fordítson, úgy, hogy a C forrássorok kommentként egy ; karakter után bekerüljenek az assembly kódba. Ezáltal érthetőbbé válik a lefordított kód a debuggolás során. Ezt a fordító a debuggolást segítő pozíció információk (LOC) beszúrásával teszi, amit a felhasználói felület automatikusan eltávolít, mivel ezeket nem használja, és csak rontják az olvashatóságot. [24] Ezek után az LCC beállításai a következők: %LCCDIR%\lcc-xr16 -Wf-g,; -S forrás.c 72

74 Az így lefordított assembly forrásfájlt az assembler összekapcsolja a CRT3 futtatókörnyezettel és a libxr16 könyvtári fájllal, mivel ezek biztosítják a program vizsgálatát a debugger monitor segítségével. Így az assemblert az alábbi módon kell paraméterezni: %LCCDIR%\xr16 CRT3.s libxr16.s forrás.s -lst=forrás.lst -hex=forrás.hex A korábban említett farbranch utasítások kezelése automatikus, vagyis a grafikus környezet megteszi a távoli ugrások megfelelő helyre történő beillesztését, majd újrafordítja a programot. Erről a lépésről egy információs felület tájékoztatja a felhasználót Grafikus környezet felépítse A grafikus felhasználói felületet a Microsoft által biztosított.net 2.0 keretrendszeren (dot net framework) belül, Visual C# nyelven fejlesztettem. A fejlesztéshez az ingyenesen elérhető Microsoft Visual C# Express programot használtam. A.NET számos beépített nyelvi elemmel rendelkezik, amelyek nagymértékben elősegítik a felhasználói felületek kialakítását. A keretrendszer a JAVA nyelvhez hasonlóan több operációs rendszert is támogat, de mivel a hallgatók számára is a Windows XP operációs rendszer a legelérhetőbb, ezért a többi platformhoz való illesztéssel a grafikus felület készítése során nem foglalkoztam. A grafikus felület kialakításakor fontos szempont volt, hogy a mikrokontrollerek körében elterjedt szoftverfejlesztő környezetekhez hasonló funkciókkal rendelkezzen. Természetesen a diplomaterv keretein belül nem kivitelezhető egy hasonló komplexitású rendszer, viszont a kifejlesztett program az oktatás során felmerülő igényeket megfelelően kielégíti. A program hivatalos nyelvének az angolt választottam, mivel bizonyos szakkifejezéseknek nincs pontos magyar megfelelője. Ezáltal az angol szaknyelv elsajátítását is segíti, ami a mai mérnöki világban elengedhetetlen. 73

75 39. ábra: A grafikus szoftverfejlesztő környezet Kompatibilitási szempontból a grafikus felület minimális méretét úgy állítottam be, hogy az 800*600 pixeles felbontás esetén se lépje túl a képernyő határait. Ennél alacsonyabb szabványos képernyőbeállítást nem támogat a rendszer. A Windows platformon futó programoknál látott szokásos eszköztáron Fájl és Szerkesztés menükön kívül még a szoftverfejlesztéshez tartozó fordítás (Build) és hibakeresés (Debug) valamint a beállításokhoz használt (Settings) menük találhatók a felület fejlécében. Mindezek mellett találunk még egy névjegyet is, ami információval szolgál a felület verziójával kapcsolatban. A funkciók gyorsabb elérését gyorsbillentyűk és ikonok is segítik, amelyek az általánosan elterjedt konvenciókat követik. Az ikonok kialakításánál törekedtem a fejlett szoftverfejlesztő eszközökkel való hasonlatosságra, így könnyítve az eligazodást a programban. A felület elrendezése 5 különböző részből tevődik össze. Ezek három fő csoportba sorolhatók: projekt fájlok, a rendszer belső tulajdonságait jelző ablakok, és a terminál. 74

76 Projekt fájl ablakok A legfontosabb, a szoftverek fejlesztéséhez használt ablak található középen. Ez két külön lapból áll, melyek között a lapok tetején található fülek segítségével válthatunk. Az első lapot kiválasztva az aktuális forrásfájlt láthatjuk, illetve szerkeszthetjük. Ez egy igen egyszerű szövegszerkesztő, amelyben a szokásos kivágás, másolás, beillesztés, visszavonás és újra végrehajtás funkciók érhetők el. Ehhez az ablakhoz tartozik még a sor (Line) és oszlop (Column) értékeket megjelenítő két státuszjel is, a grafikus felület alsó szegmensében. A szerkesztő ugyan lehetővé teszi a programok fejlesztését, viszont a C nyelvű programozáshoz sokkal összetettebb, és a fejlesztést jobban segítő eszközök használata ajánlott. Ezek a külső szoftverek olyan támogatást nyújthatnak, mint például a C nyelvi elemek kiemelése, zárójel-párok jelzése, előre beépített nyelvi struktúrák használata, stb. 40. ábra: LST fájl megjelenítő ablak A második lap mutatja a program lefordítása után kapott LST fájl tartalmát, ahogy azt a 42. ábrán láthatjuk. A különböző színek könnyítik a programsorok áttekinthetőségét. Piros szín jelzi a globális változók, valamint a függvények neveit. Zöld színnel látjuk a kommenteket és kék szín mutatja a különböző forrásfájlok határait, 75

77 valamint a hibaüzeneteket. A program futásának vizsgálata során ebben az ablakban sárga csík jelzi a következő végrehajtandó utasítást. A kódban töréspontot úgy helyezhetünk el, hogy a kívánt sorra az egérrel duplán kattintunk. Ezt szintén dupla klikk hatására tudjuk megszüntetni. Egyszerre csak 1 töréspont helyezhető el a kódban, amit sötétvörös csík jelez az aktuális soron Terminál ablak A terminál ablak igen egyszerű. A beírt szöveget az aktuálisan beállított soros porton továbbítja a rendszer felé, míg a fogadott karaktereket automatikusan megjeleníti az ablakban. Mivel a soros port látja el az xr16-on futó debugger monitorral való kapcsolattartás feladatát is, ezért amíg az ilyen irányú kommunikáció zajlik, a terminál használata nem engedélyezett. Amint a vizsgálandó programot futtatni kezdjük, a soros port újra elérhetővé válik Rendszer ablakok A belső állapotokat megjelenítő csoport a felületen jobboldalt található, és 3 részből tevődik össze. A legfelső ablak tartalmazza a rendszerben található perifériák belső regisztereinek állapotát. A periféria egységek között szintén fülek segítségével válthatunk. 41. ábra: Perifériák belső regisztereit mutató ablak A rendszer bővíthetőségét 4 előre adott periféria sablonnal biztosítottam, melyek tulajdonságai a beállítások menüben változtathatóak. Ezek az úgynevezett UserIO perifériák alapértelmezésben 4 belső, csak olvasható, 16 bites regiszterrel rendelkeznek, amelyeket a felhasználó a későbbiekben tetszés szerint átállíthat. A belső regiszterek címkiosztása folytonos a báziscímtől kezdve. 76

78 42. ábra: Felhasználó által készített perifériák beállításai Az itt kiválasztott paramétereket a program egy xsoc.dat fájlban tárolja el, így kilépéskor nem vesznek el a beállításaink. Ha a grafikus környezet indításakor nem áll rendelkezésre ez a dat fájl, akkor a rendszer létrehoz egy újat az alapbeállításoknak megfelelő értékekkel. A használat demonstrálása érdekében a rendszerhez tartozó időzítő számláló belső regisztereit is jelenleg így jeleníti meg a rendszer. A periféria egységekhez tartozik még a különböző címek beállítására szolgáló ablak. 43. ábra: Periféria címek beállításai A középső szekció mutatja meg a processzor regisztereinek tartalmát. Ezek hexadecimális formában jelennek meg alapértelmezésben, viszont lehetőségünk van többféle ábrázolásmód használatára. Az egér jobbgombjának kattintásával egy előugró menüből választhatunk az előjeles decimális, előjel nélküli decimális, valamint a hexadecimális formátumok közül. Az adott regiszterhez beállított formátum 77

79 azonosítását színek is segítik. Halványkék háttér jelzi az előjeles számokat, halványpiros az előjel nélkülieket valamint fehér a hexadecimális értékeket. Ha a kurzort az egyes regiszterek fölé visszük, segédinformációként megjelenik, hogy a C fordító milyen szerepkörben használja fel az aktuális regisztert. A regiszterek értékének változtatását az Enter billentyű megnyomásával hagyjuk jóvá. Az előzőleg beolvasott értéktől való eltérést félkövér betűtípus jelzi. 44. ábra: Processzor regisztereinek megjelenítése Az alsó és egyben utolsó része a felhasználói felületnek a memóriatartományt megjelenítő ablak. A megadott címtől kezdve lehetőségünk van szavas és bájtos kiolvasásra egyaránt, amelyet a READ gomb megnyomásával, vagy egy Enter leütéssel kezdeményezhetünk. A kiolvasott címtartomány 256 bájt. A memóriatartalom átírásához az egérrel duplán kell kattintanunk a kívánt memóriaértékre, ami ilyenkor azonnal szerkeszthetővé válik. Az új értéket szintén az Enter billentyűvel érvényesíthetjük Funkciók rövid leírása A felhasználói felület fejlesztése során a biztonságos használat kialakítása is fontos szempont volt. Ez lényegében azt takarja, hogy a felhasználó bizonyos funkciókhoz csak a megadott lépésekben fér hozzá. Legfontosabb lépésként meg kell teremteni a kapcsolatot a számítógép és a vizsgálandó rendszer között. Ezt kábelek csatlakoztatása után a megfelelő soros port kiválasztásával érhetjük el. Nem megfelelő beállítások esetén a felhasználói felület hibaüzenetet küld. A soros port kommunikációs sebessége nem változtatható, konstans as értékre van beállítva. 78