Dette semesteret har vært interessant for gruppa vår. I høst har vi måtte sette oss ned for å redefinere hva planen vår er. Det skjedde etter at vi gikk delvis inn i flere dead ends, og brukte godt over halve semesteret på å komme ingen vei. Nå tror vi at vi har løsningen.

I bunn og grunn handler prosjektet om å produsere en prosessor på et kretskort, som kan brukes for å formidle til andre hvordan en datamaskin fungerer. Vi hadde som mål å basere oss på og bygge opp "vår egen" versjon av MOS 6502-prosessoren. Planen var å være så nærme sannheten og det originale designet som mulig. Det viste seg å være mye mer komplekst enn antatt. (Hvem hadde trodd‽)

Derfor endrer vi nå kurs og baserer oss på hva prosessoren gjør, ikke nødvendigvis hvordan den gjør det. Dette er et såkalt instruksjonssettarkitektur, eller ISA. Denne er veldig godt kjent, og vi har en god forståelse av hva som må gjøres.

Figur: Alle mulige instruksjoner i 6502-ISAen. Gule celler er dokumenterte instruksjoner, grå er ulovlige instruksjoner. Mer om det litt lenger ned i artikkelen. (kilde)

Kontrollogikk

Prosessorer er laget som en sammensetning av mindre komponenter (feks. regneenheter og registre). For at disse enhetene skal kunne gjøre jobbe sin og samarbeide må det være en del av prosessoren som har kontroll over hva som skjer og hva som skal skje videre. Dette er kontrollogikken. Nøyaktig hva kontrollogikken gjør og hvordan den fungerer varierer fra prosessor til prosessor.

 I 6502 sitt tilfelle kan det sies at “predecode register”, “predecode logic”, “instruction register”, “timing generation logic”, “decode rom”, “interrupt and reset control”, “processor status register” og “random control logic” komponentene som sammen fungerer som kontroll-logikken. Denne delen tar opp nesten halve blokkdiagrammet, noe som kan vise til hvor kompleks denne delen av prosessoren er. Mesteparten av kompleksiteten ligger i komponentet “random control logic”. Som navnet tilsier er dette en “tilsynelatende tilfeldig” logisk krets som tar inn input fra flere ulike komponenter, inkludert signaler utenfra prosessoren, og gjør “ett eller annet” for å produsere rundt 60 såkalte kontrollsignaler. Disse kontrollsignalene er hva som styrer resten av prosessoren, og er dermed rimelig viktige for at prosessoren skal kjøre riktig. 

Grunnen til at logikken er “tilsynelatende tilfeldig” er usikkert, men er trolig fordi flere av kontrollsignalene ikke påvirker utførelsen av en enhver instruksjon (feks. det skader ikke å regne ut a + b hvis resultatet ikke lagres eller påvirker prosessorens status). Denne toleransen for “feil” kan ha gjort det lettere og billigere å lage kontrollogikken (siden signaler som ikke skader ikke trengs å “skrus av”), men det gjør det samtidig vanskeligere å finne ut av hva som skjer under utførelsen av en instruksjon.

For å lage kontrollogikken kreves det informasjon om hvordan de ulike komponentene i kontrollogikken fungerer. Tre av komponentene er register, men ulike kontrollinjer for å styre hvordan registeret skal ta imot og gi fra seg data. Dette er kjente komponenter. Videre er “predecode logic”, “timing generation logic”, “interupt and reset controll” og “decode rom” komponentene godt dekket av informasjonen tilgjengelig på visual6502 og breaknes. Det som da gjenstår er “random control logic”, som ikke er godt dekket av noen kilder vis har funnet.

Breaknes er et prosjekt som tar for seg å dekonstruere spillkonsollen NES og simulere hver eneste del av den. NES konsollen bruker en 6502 som hovedprosessor, en del av breaknes prosjektet har dermed gått ut på å dekonstruere alle deler av en 6502. Dette inkluderer “random control logic” komponentet. Virkemåten av dette komponentet er delt som en wiki artikkel med en tilhørende verilog fil (språk for å beskrive virkemåten av maskinvare). Siden denne implementasjonen er fritt tilgjengelig og “random control logic” komponentet er så komplekst,  tenkte vi det lureste ville være å bruke denne implementasjonen. 

Siden vi har tilgang på en transistor-nivå simulasjon av prosessoren, tenkte vi det ville vært kjekt å teste denne implementasjonen mot simulasjonen. Dette førte til veldig mye trøbbel, siden et fåtall av signalene i simulasjonen er navngitt, og de som er navngitt har ikke nødvendigvis liknende navn til de korresponderende signalene i breaknes implementasjonen. Det gikk dermed flere arbeidstimer til å følge signaler fra transistor til transistor for å finne alle de manglende signalene, og verifisere de andre. Etter utallige forsøk har vi ennå ikke fått samme resultat av simulasjonen og breaknes sin implementasjon. I tillegg er det flere linjer som blir “flyetende” (signaler som ikke logisk 0 eller 1, men noe annet) i simulasjonen av breaknes sin verilog med grunntilstanden hentet fra transistor-nivå simulasjonen. Siden så mye tid har gått til å teste breaknes implementasjonen, uten noe resultat, har vi bestemt oss for å forkaste ideen om å bruke denne implementasjonen. 

Istedenfor å replikere “random control logic” har vi nå bestemt oss for å implementerer noe som fungerer liknende, men ikke eksakt likt. Dette kan virke som en merkelig avgjørelse, men det reduserer arbeidet som kreves drastisk. Grunnen til dette er at såkalte “illegal opcodes” (instruksjoner som ikke har en spesifisert virkemåte) er produkt av snarveier tatt i “random control logic”. Illegal opcodes kan gjøre alt fra å stoppe prosessoren (KIL) til å produsere et resultat som kan påvirkes utallige faktorer som produsent, temperatur, hvor mange ganger noen har nyset i det siste døgnet og muligens utenomjordiske vesener (XAA). Ved å kun finne kontrollsignalene som kreves for å implementere de spesifiserte instruksjonene vil kompleksiteten som introduseres av å simulere disse uspesifiserte instruksjonene fjernes.

Denne avgjørelsen ble tatt etter oppfordring av postdoktor Odd Rune Strømmen Lykkebø (TDT4160 Datamaskiner og digitalteknikk <3) som tydeligvis har gjort denne jobben selv og var villig til å dele arbeidet. Siden hovedfokuset med prosjektet er å vise hvordan en prosessor er laget og implementere en 6502 på kretskort, har gruppen valgt å heller sette seg inn i hvordan Lykkebø sin løsning av problemet fungerer, enn å bruke enda mer tid på å prøve å løse det selv.

Og snipp snapp snute, så var artikkelen ferdig.

Til neste gang, Prosjekt: Makroprosessor over og ut. (Artikkel skrevet av Simon Doksrød og Ola Horg Jacobsen)