TKT-1230 Digitaalitekniikan laboratoriotyöt

Transkriptio

1 Go to Top TKT-1230 Digitaalitekniikan laboratoriotyöt Väylätyön jälkiselvitys Santtu Pajukanta Timo Viitanen

2 Mittaus 1 2*9=18=h'12, etsittiin siis ensimmäinen mov.b Rs, Rd-muotoinen käsky osoitteen h'20112 jälkeen. Yritettiin aluksi triggeriä jossa dataväylällä on 0CXX ja osoiteväylällä 11X. Tämä johti heti voittoon : Tulkataan näkymän verran mittausta konekielisiksi käskyiksi : 0CB0 0A09 mov.b R3L, R0H inc.b R1L 0890 add.b R1L, R0H 1009 shll.b R1L 0CC1 0A09 mov.b R4L, R1H inc.b R1L

3 0891 add.b R1L, R1H 1009 shll.b R1L 0CB0 mov.b R3L, R0H Koodi ei oikein näytä täysijärkiseltä : R0H:hon rakennetaan arvo, jota ei missään vaiheessa lueta ennenkuin se uudelleenkirjoitetaan. Mittaus 2

4

5

6 Etsittiin yksi käsky dataväylän triggerillä 15XX. Loput olivat, kuten tehtävänanto sanoo, 20 muistiosoituksen sisällä. Mitattiin käskyn hakuaika RD-signaalin laskevasta reunasta oikean arvon ilmestymiseen datalinjalle, mitä ohikulkeva assari piti hyvänä hakuajan mittarina. Ensimmäisten kahden käskyn hakeminen kesti 8 ns, kolmannen 12 ns. Käskyillä nollataan rekisterit R0L, R1L, ja R2L. Mittaus 3

7

8 Käytettiin triggereinä eri BRA-käskyjen ensimmäisten sanojen objektikoodeja, kunnes löydettiin oikeat. Ensimmäisen BRA-käskyn objektikoodi on 4010, ja se sijaitsee osoitteessa 1B4. Käskyn immediate-osa on h'10 eli 16. Käskyn jälkeen haetaan käsky (0000, nop) osoitteesta 1B6, ja vasta sen jälkeen siirrytään hakemaan seuraava käsky osoitteesta 1C6. Koska hitachi-assembly ei vaadi nop:ien lisäämistä hyppykäskyjen perään (toisin kuin esim. ARM), 1B6:sta luettu käsky jätetään oletettavasti käyttämättä. Toisen käskyn koodi on 5800FF30, missä immediate on FF30. Eli 16-bittiseksi kahdenkomplementtiluvuksi tulkittuna -208, heksana -d0. Tässä hyppy tapahtuu heti käskyn jälkeen ilman, että seuraavaa käskyä haettaisiin. Hyppykäskyn suoritusaika kuitenkin venyy yhden kellojakson verran normaalia pidemmäksi. Kummassakin tapauksessa päädytään käskyyn osoitteessa (hyppykäskyn viimeisen sanan osoite hyppykäskyn immediate-arvo). Ensimmäinen BRA vie laitteistoreferenssin mukaan väylän tiloihin R:W NEXT ja R:W EA, ja toinen tiloihin R:W 2nd, Internal operation ja R:W EA. R:W 2nd tarkoittaa selvästi käskyn jälkimmäisen puolikkaan lukemista. Yksinkertaisissa käskyissä jotka käsittelevät rekistereitä, kuten xor.b Re, Rd, on vain tila R:W NEXT, ja mukaan tulee R:W EA kun luetaan tai

9 kirjoitetaan muistipaikkaa. Ensimmäisestä BRA:ta suoritettaessa siis luetaan muistiin järjestyksessä seuraava käsky, ja samaan aikaan asetetaan uusi PC:n arvo. Oletettavasti myös asetetaan jokin taikabitti jonka ansiosta luettua käskyä kohdellaan NOP:na. Toisessa BRA:ssa taas luetaan koko käsky muistiin, lasketaan uusi PC:n arvo, ja luetaan muistiin käsky johon hypätään, samalla tavalla kuin useimpien käskyjen lopuksi luetaan muistiin seuraava käsky R:W NEXTillä. Mittaustulokset konekielikäskyinä : 4010 bra #+h' nop 1706 not.b R6H 0000 nop 1706 not.b R6H 5800FF30 FB10 FC20 0CB0 0A08 bra #-h'd0 mov.b #h'10, R3L mov.b #h'20, R4L mov.b R3L, R0H inc.b R0L 0880 add.b R0L, R0H 1008 shll.b R0L Mittaus 4

10 Käytettiin triggausehtona dataväylän arvoa h'6aa0, joka on alkupuoli "mov.b R0H, osoite"-muotoisesta käskystä. (Yritettiin ensin muita mov.b:n variantteja joissa kirjoitetaan R0H muistiin) Havaittiin, että näin löytyy juuri tämä haettu luvun h'17 kirjoitus. Luku kirjoitettiin osoitteeseen h'21a00. Käskyn suoritus poikkeaa kummastakin edellisen tehtävän bra-käskystä : käsky on kolmen sanan pituinen, mutta silti muistista luetaan seuraava käsky ennen sen suoritusta. Käskyn ensimmäinen sana luetaan muistiin samaan aikaan kun edellistä käskyä ollaan suorittamassa. Tämän jälkeen luetaan sanat 2-3, jonka jälkeen luetaan seuraava käsky (not.b R6H osoitteessa h'154), jonka jälkeen suoritetaan kirjoitus sanojen 2-3 osoitteeseen. Sitten aletaan suorittaa osoitteen h'154 not.b R6H:ta, ja samanaikaisesti hakea muistiin osoitteen h'156 not.b R6H:ta. Konekieliseksi tulkattuna : 6AA000021A00 mov.b R0H, #h'00021a not.b R6H

11 1706 (dataa) 1706 not.b R6H 0000 nop 1706 not.b R6H Kirjoituksen molemmin puolin satutaan lukemaan muistista käsky, jonka vasen tavu on sama kuin kirjoitettava data. Mittaus 5 + Asetettiin sample-periodiksi 104 ns ja triggeriksi osoiteväylän arvo 12C. Ensimmäiset 5 riviä näyttäisivät annetuilla symboleilla tältä (poislukien kontrollisignaalit jotka pysyvät samoina, ja kello jossa ei ole mitään järkevää sisältöä) : 0 0 s 12C mov.b R4L, R1H ns 12E inc.b R2L ns 130 add.b R2L, R1H

12 3 312 ns 132 shll.b R2L ns 134 add.b #6, R0H Näin näyttää saavan kätevästi ohjelman disassembly-listauksen, käskyjen muistiosoitteet, ja koodinpätkän suoritusajan. Yksi tämän tekniikan ongelma on, että mittaus voi osua invalidiin arvoon, kun dataväylän sisältö on vaihtumassa. Suuremmalla näytteenottotaajuudella nämä erottuvat selvästi, koska oikeasta dataväylän sisällöstä saadaan tasaisesti kymmeniä näytteitä, ja väärästä yksi tai kaksi. Lisäksi jos luetaan tai kirjoitetaan dataa jolla sattuu olemaan käskyn numeroarvo, disassemblyyn ilmestyy vastaava symboli. Tämän tosin näkee helposti osoiteväylältä. Ja osalla käskyistä on 104 ns:stä eroava suoritusaika, mikä näyttää listauksessa usean identtisen käskyn suoritukselta peräjälkeen. Olisi myös työlästä asettaa analysaattoriin kaikki asiaankuuluvat symbolit käsin. Terveemmältä tuntuisi kirjoittaa ohjelmanpätkä joka tunnistaa isommalla taajuudella otetusta listauksesta oikeat arvot ja käskyjen rajat, ja ajaa listaus sen läpi. Mittaus 7

13 Käytetyssä triggerissä odotetaan ensin, että osoitteeseen 500 kirjoitetaan sana: eli analysaattorin lukema osa osoiteväylästä on h'500, ja hwr ja lwr ovat 0. Tämän jälkeen triggeri laukeaa, kun on 49 kertaa tapahtunut nouseva kellonreuna samaan aikaan kun hwr ja lwr ovat 0, eli ollaan kirjoittamassa muistiin sanaa. Tätä testattiin ensin käyttämällä 49:n tilalla 1:tä ja 2:ta, jolloin saatiin taulukon toinen ja kolmas alkio. Mikä varmistettiin selaamalla puskuria taaksepäin. Tämä näyttää epäilyttävältä : luulisi, että ehto 2 laukeaisi kerran myös samalla kirjoituskerralla ehdon 1 kanssa. Näin ei kuitenkaan käy. Ehkä tällä on jotain tekemistä kelloehdon $-taikamerkin kanssa, joka poikkeaa muista signaaleista. 50. alkion osoite oli h'215b2. Alkion sisältö oli satunnaisesti joko h'9999 tai h'6666. Näköjään ohjelma käy taulukkoa toistuvasti läpi ja joka kierroksella not-aa sen sisällön. ( h'6=0110, not h'6 = 1001 = h'9 ). Artikkeli 1

14 Tutkimuksessa mitattiin eri 1Gb-verkkokorttien suorituskykyjä useilla serveritason emolevyillä. Suorituskyvyn mittareina käytettiin yksittäisen UDP-yhteydenoton latenssia, jatkuvan UDP-pakettivirran nopeutta, sekä PCI-väylän käyttöastetta. Latenssia mitattiin lähettämällä 1Gb-ethernetin yli toiselle järjestelmälle Request-Response UDP-viestejä, jotka vaativat tietyn kokoisen vastauksen. Tätä toistettiin tuhansia kertoja eri pakettikoilla, ja mitattiin joka havaintopisteestä viestin kiertoon kulunut aika. Nopeutta tarkasteltiin lähettämällä sarja tietynkokoisia paketteja tasaisin väliajoin, ja vaihtelemalla paketin kokoa ja väliaikaa. Näiden mittausten yhteydessä tarkasteltiin logiikka-analysaattorilla PCI-väylää. Eri tilanteissa tunnistettiin analysaattorin tulosteesta viive paketin lähetyksen alusta siihen, kun ethernet-kaapelilla aletaan lähettää. Tällä tavalla havaittiin mm. että eräällä kortti-emolevy-yhdistelmällä emolevy lähettää pci-viestejä verkkokortille nopeammin kuin kortti pystyy ottamaan niitä vastaan, mistä seuraa PCI STOP-signaaleja. Artikkeli 2 Tutkimuksessa tutkittiin, mihin aika kuluu TCP/IP-tietoliikenteen käsittelyssä Ultrix-käyttöjärjestelmän TCP/IP-protokollapinossa. Erityisesti pyrittiin selvittämään dataa muuttamattoman prosessoinnin yleisrasitteiden (non-data touching processing overhead ) osuutta tietoliikenteen käsittelyyn kuluvasta prosessoriajasta. Tutkimuksessa käytettiin logiikka-analysaattoria mittaamaan saapuvan tai lähtevän datapaketin käsittelyn eri vaiheisiin kuluvaa aikaa. Logiikka-analysaattori kytkettiin mittauksissa käytettävän tietokoneen I/O-väylään ja Ultrix-käyttöjärjestelmän ydintä muokattiin siten, että tietyissä kohdissa datapaketin käsittelyä I/O-väylään kirjoitettiin merkkiarvoja. Logiikka-analysaattori oli asetettu etsimään I/O-väylästä näitä merkkiarvoja ja tallentamaan väylällä esiintyneet merkkiarvot esiintymisaikoineen. Näin saatiin mitattua eri käsittelyvaiheisiin kuluvia aikoja. Koejärjestelyssä mittaustietokone, johon logiikka-analysaattori oli kytketty, oli yhdistetty FDDI-kuituverkolla toiseen samanlaiseen tietokoneeseen. Tämä toinen tietokone lähetti mittaustietokoneelle eri kokoisia paketteja siten, että pakettien kokojakauma vastasi tyypillisen verkkoliikenteen kokojakaumaa, ja mittaustietokone kaiutti paketit takaisin. Artikkeli 3 Artikkelissa esitellään sulautettuja järjestelmiä ja niiden tehonkulutusta simuloiva SimBed-ohjelma, jonka päällä voi ajaa reaaliaikaisia käyttöjärjestelmiä (RTOS:ia). Ohjelmalla tutkitaan kolmen eri RTOS:n suorituskykyä ja tehonkulutusta erilaisia sovelluksia ajettaessa. Suorituskykyä tutkittiin säätämällä RTOS ajamaan tehtäviä tietyin väliajoin, niin että jokainen tehtävä kirjoittaa I/O-porttiin kun se suoritetaan. Mitattujen suoritusaikojen välejä verrattiin

15 valittuun väliaikaan. Lisäksi tutkittiin järjestelmän responsiivisuutta eri kuormilla mittaamalla aika sisääntulosta keskeytyspalvelimen tuottamaan ulostuloon. Logiikka-analysaattoria olisi voitu käyttää suorituskyvyn mittaamiseen, jos RTOS:ia olisi ajettu mikrokontrollerilla. Silloin tarvitaan niin paljon muistia analysaattoriin, että siihen mahtuu usean millisekunnin aikaväli. Tästä tulosteesta ei voisi hakea tapahtumia käsin, vaan se pitäisi suodattaa ulkoisen ohjelman läpi. Tai vaihtoehtoisesti käyttää matalaa näytteenottotaajuutta ja niin pitkiä viestejä, että niiden "tracet" erottuvat tulosteesta. Tässä voisi olla vaikeaa erottaa eri taskien tuottamat viestit toisistaan. Tehonkulutusta analysaattorilla ei olisi pystynyt mittaamaan. Artikkeli 4 Artikkeli käsittelee aikansa mittapuulla nopean ja vähävirtaisen Rijndael- eli AES-salausprosessorin suunnitteluprosessia ja -periaatteita sekä testausjärjestelyä, jolla prosessorin toimintaa tutkittiin. Salausprosessoria testattiin koejärjestelyllä, jossa salausprosessorin sisääntuloväylään kytkettiin vektorigeneraattori ja ulostuloväylään logiikka-analysaattori. Testaukseen käytettiin yksinkertaisia data- ja avainkuvioita, joissa osa biteistä oli kytketty maahan. Salausprosessorin ulostuloja voitiin testaustilanteessa mitata salausprosessorin kellotaajuutta alhaisemmalla näytteenottotaajuudella, koska rajapinnat salausprosessorin sisään ja sieltä ulos oli toteutettu kaksisuuntaisella kättelyllä (two-way handshake). Logiikka-analysaattori käytti mittaukseen vektorigeneraattorin kelloa salausprosessorin toimiessa omalla, nopeammalla kellollaan. Tämä mittaustapa mahdollisti sen, että salausprosessorin testauksessa ja demonstroinnissa ei tarvittu kallista testauslaitteistoa, vaan testaus voitiin suorittaa tavallisilla kaupallisilla mittauslaitteilla. Artikkeli 5 Artikkeli esitelee uuden tekniikan digitaalisten järjestelmien debuggaukseen, laitteistodebuggerin. Siinä tallennetaan toistuvasti laitteen sisäisiä tiloja DUT-muistipuskuriin. Kun tilassa havaitaan (analysaattorin triggausehtojen malliin) virhe, voidaan ladata DUT:n sisältö tietokoneelle, alustaa porttitason simulaatio (esim. Modelsim) johonkin ennen virhettä tallennettuun tilaan, ja seurata simulaatiotyökalun sisällä, miten virheeseen päädytään. Logiikka-analysaattorilla voi seurata ainoastaan laitteen I/O-signaaleja, ei sisäisiä tiloja. Ainakin artikkelin kirjoituksen aikaan laitteistodebuggerilla oli useita rajoituksia : DUT-muisti on sidottu yhteen kelloalueeseen, I/O-signaaleja täytyy seurata jatkuvasti logiikka-analysaattorilla, breakpointit täytyy lisätä käsin debuggerin VHDL-koodiin, eikä DUT:na voi käyttää sirun sisään upotettua muistia. Näihin tosin luvattiin pikaisia parannuksia,

16 ja artikkeli on kahdeksan vuotta vanha.