Speksit tiskiin

Kuten tuossa vaatimuspuolella jo todettiin, on tarkoitus koota 68000 sirun ympärillä toimiva sulautettu systeemi. Tarvitaan siis itse CPU, muistia, näyttö ja sekalaisia I/O laitteita kuten näppis ja tietenkin muistikortinlukija. Normaalistihan firmis on joko flash-sirulla tai ROM-muistissa. Nyt kuitenkin valitaan lähestymistapa jossa se ladataan muistikortilta jotta testaaminen on helpompaa softan osalta. Ja niin, erilaisia nappuloita ja valoja on kiva debuggausvaiheessa myös olla. Koska devaaminen tapahtuu valmiilla devilaudalla, ei näistä vaatimuksista tässä kohtaa tarvitse välittää.

Koska houkutus on koota koko systeemi osapuilleen valmiiksi ja aloittaa sitten testaaminen, otetaankin vähän happea ja rakennellaan palanen kerrallaan. Prosessorin osalta mennään siitä mistä aita on matalin, eli otetaan pakasta valmis toteutus. 68000 ei nykystandardeilla ole kovinkaan monimutkainen prossu. Sellaisen tekeminen tyhjistä kuitenkin on melkoinen operaatio ja valmiita laadukkaita toteutuksia löytyy. Siksi onkin syytä poimia näistä yksi.

Käytännön vaihtoehdot avoimen koodin toteutuksista ovat seuraavat:

• ao68000
• TG68k
• WF68000

Kaikissa on omat vahvuutensa, mutta mahdollisimman suuren alkuperäistä rautaa noudattelevan ratkaisun hengessä valitsin WF68000:n. Tämä siksi, että se on syklin tarkkuudella alkuperäistä vastaava toteutus. Lisäksi signalointi noudattelee 100% oikeaa rautaa, joten periaatteessa softaprosessori olisi korvattavissa aidolla jos näin haluttaisiin jostakin syystä. Tietysti yksi valintakriteeri on se, että käytän samaa toteutusta yhdessä toisessa projektissa joten ei kannata keksiä pyörää uudelleen projektien välillä.

Lue lisää: 68000 softacoret

Seuraava isompi palikka on luonnollisesti muisti. Kehityslauta tarjoaa käytettäväksi joko staattista RAM-muistia tai SDRAM-muistia. Koska kiikarissa on oikean piirilevyn suunnittelu ja tekeminen, kannattaa nykyään kylmästi valita SDRAM. Se on kustannustehokkaampi suhteessa saatavaan kapasiteettiin ja tarjoaa myös hyvin virtapihejä vaihtoehtoja. Miinuspuolella SDRAM vaatii hieman monimutkaisemman kontrollerin toteuttamisen ja vaikeuttaa ihan synkronoinnin vuoksi toteutustyötä. Teoreettinen kolmas mahdollisuus olisi käyttää itse FPGA:n sisäisiä muistiblokkeja. Ne eivät kuitenkaan tarjoa riittävää kapasiteettia tähän projektiin, joten asian voi unohtaa. Niiden hyödyntämistä kannattaa kuitenkin harkita osana suunnittelua, sillä niillä voidaan toteuttaa lokaaleja muistielementtejä itse designissa, mm. cacheja ja rekistereitä (joista myöhemmin lisää).

Lue lisää: SRAM ja SDRAM muistien erot

Näytön integrointi järjestelmään vaatii tietenkin jonkun fyysisen näytön sekä logiikan sen ohjaamiseen. Koska kehitystyö tapahtuu valmiilla laudalla, käytetään tähän VGA-liitäntää, joten VGA-kontrollerin toteuttaminen on pakollista. Lopulliseen designiin tulee eri tyyppinen näyttö, mutta tässä kohtaa tehty työ ei sinänsä mene hukkaan. Suurin ero tulee lopulta signaloinnissa ja VGA:n vaatiman framebufferin voi suoraan hyödyntää.

Lue lisää: mikäs on se VGA ja framebuffer?

Sitten tullaankin mielenkiintoiseen kohtaan: systeemin herättely henkiin vaatii jonkin mekanismin, sillä bitit eivät kulje pyhällä hengellä. 68000:n koodi pitää ladata jostain, mutta sitä ei tietenkään voi ladata ellei joku sitä lataa. Usein tässä kohtaa järjestelmään ilmestyy mikrokontrolleri joka hoitaa systeemin pystyyn potkimisen. Tämä on perusteltua varsinkin silloin jos koko FPGA:n ohjelmointi tehdään esim. muistikortilta.

FPGA vaatii ohjelmoinnin aina kun virrat lyödään päälle. Sen voi tehdä joko mikrokontrolleri, CPLD¹ tai sitten asiaan tarkoitettu serial flash -muisti² FPGA:n JTAG-pinneillä³.

Nyt kuitenkin teemme niin, että FPGA sisältää ohjelmoituna bootstrap-koodin joka osaa ladata muistiin 68000:n koodin. Tarkoittaa siis että FPGA sisältää minimisetin 68000-koodia joka lataa loput. TAI toteutan FPGA:lle mikrokontrollerin joka hoitaa saman asian. Joka tapauksessa tämä johtaa siihen, että erillinen kontrolliblokki järjestelmään on pakko tehdä. Päätämme tämän varsinaisen toteutustavan myöhemmin. Tässäkin kannattaa pitää mielessä se, että vastaavalle tulee todennäköisesti tarvetta muissakin projekteissa. Siksi siihen kannattaa panostaa.

Kokeneempi harrastaja kokoaa tarvittavista komponenteista omat kirjastot. Tässä projektissa mennään quick & dirty hengessä.

Tässäpä karkeasti edessä olevat haasteet. Siirrymmekin siis suoraan muistikontrollerin kimppuun. Odotettavissa onkin rattoisia hetkiä datasheetin parissa. Elikkäs jatkamme tänne.

---