Institutionen för systemteknik

Designspec TSEA83

Allmänt

En designspes är ett dokument på några A4-sidor där ni berättar hur ni ska bygga er apparat.

Den ska innehålla detaljerade blockscheman. Börja gärna med att ta kontakt med handledaren och diskutera en tänkt lösning. Lämna därefter in en väl genomtänkt designspec i Lisam. När handledaren har godkänt den får ni tillgång till Nexys3-kort, övrigt material samt ett skåp att förvara sakerna i.

OBSERVERA. Det är inte tillåtet att använda någon annans figurer eller bilder utan tillstånd från bildägaren. Dvs, bäst är att rita sina egna figurer, vilket dessutom lämpar sig bäst då ni bygger en unik konstruktion.

Arbetsgång

Det i särklass bästa sättet är att först ta fram ett detaljerat blockschema över konstruktionen. Börja med att rita på papper. Behöver ni hjälp med att tänka eller fundera ut vad som är relevant och nödvändigt, ta kontakt med handledaren.

När blockschemat är klart så kan det dock behöva renritas, så att det blir läsbart.

Utgå sedan från blockschemat och skriv och förklara i designspecen hur ni tänkt att processorns olika delar ska fungera.

Förslag på designspec

• Försättsblad med projekttitel och medlemmarnas namn och email
• 1. Inledning. Kortfattad beskrivning av apparatens uppbyggnad
• 2. Analys av problemet
  Presentera hur ni tänkt. Vilken algoritm. ...
• 3. Förfinat blockschema med förklaringar. Här ska ni visa hur er apparat är uppbyggd. Lämpligt är att dela upp blockschemat i flera mindre blockscheman. Lämpliga komponenter i blockschemat är: multiplexer, komparator, adderare, räknare, register, sekvensnät, minne, ... .
• 4. Milstolpe Efter ungefär halva projektet kan vi ...

Tänkvärt

Processorn i konstruktionen behöver inte lösa alla uppgifter. Vissa saker lämpar sig betydligt bättre att bygga som separata tillståndsmaskiner och hårdvaruenheter som kör parallellt med processorn. Det kan t ex vara en UART som hanterar kommunikation med en annan dator, en I2C-modul som läser information ifrån en joystick, en VGA-motor som ständigt ritar upp en bild på en VGA-monitor, eller någon annan hårdvaruenhet som underlättar arbetet för processorn på nåt sätt. Processorns uppgift blir sedan att styra och skriva/läsa information från dessa enheter samt att göra det algoritmiska beräkningsarbetet. En lämplig utgångspunkt i designspecen är att göra just den här uppdelningen, dvs vilka uppgifter ska processorn lösa och vilka uppgifter ska övriga hårdvaruenheter lösa.

Sträva efter att göra en generell dator/processor-lösning. Det blir då oftast lättare att anpassa lösningen efter problem och nya situationer och idéer som uppstår under konstruktionsarbetets gång. Det kan förstås vara så att vissa saker lämpar sig bäst som speciallösningar, men det bör vara undantagsfall. Datorkonstruktion handlar mycket om att kompromissa, och att göra lämpliga avvägningar.

Checklista för designspec, dvs vad som lämpligen kan ingå

• Spelimplementation:
  • I stora drag, hur ska er hårdvara se ut och hur ska hårdvaran användas? Vad är de olika enheterna ansvariga för?
  • Vad finns det för spel-specifika klurigheter att ta hänsyn till i er implementation? Ger de några intressanta konsekvenser på hur hårdvaran måste byggas?
• CPU:
  • Vilken processormodell har ni tänkt bygga? (pipelinad/mikroprogrammerad/egen?)
  • Använder processorn delat eller kombinerat data/programminne?
  • Vad är ert instruktionsset? Hur ser instruktionsorden ut för t.ex. ALU-operationer, load/store-operationer osv? Hur många bitar krävs för en instruktion? (Beror ju så klart på hur många register er processor ska ha och hur många operationer som ska stödjas).
  • Vad ska vara er processors naturliga ordbredd? Ska processorn jobba med t.ex. 8, 16 eller 32-bitars tal eller något annat? Motivera gärna ert val.
  • Vilka adresseringsmoder ska stödjas?
  • Val av instruktionsset, ordbredd och adresseringsmoder är väldigt kopplat till vad er CPU ska göra för beräkningar. Finns det några applikationspecifika/spelspecifika features (t.ex. specialinstruktioner eller häftiga adresseringsmoder) som kan underlätta er spelprogrammering?
  • Hur ska processorn startas? Ska det finnas ett program laddat från start (enklast) eller ska processorn laddas med ett program, t.ex. från UART (klurigare)?
  • Endast projekt med UART: Hur ska eventuell UART kopplas in till processorn? Hur vet man när det har kommit ett UART-meddelande?
  • Vilka uppgifter ska CPUn utföra i er implementation? Kommer processorns prestanda räcka för dess tänkta uppgifter?
• Grafik:
  • Vad är strategin för att rita grafik? (Blockschema!)
  • Upplösning och antal färger? Tiles/sprites?
  • Hur ska grafikenheten samarbeta med CPU-n? Behöver grafiken synkroniseras med CPU-n på något vis? (i vissa projekt kanske t.o.m. processorn själv ritar grafik beroende på implementation)
• I/O-enheter (t.ex. joystick, keyboard, knappar/7-segment på FPGA-kort, PS/2):
  • Vad behövs för hårdvara för att kommunicera med er I/O-enhet?
  • Hur ska er I/O-enhet kopplas in och användas av resten av systemet? Ni kan välja på att låta I/O-registren vara ett register i CPU-n eller en minnesscell.
• Minnesanvändning:
  • Vilka minnen finns i er design? Hur stora måste adressregistren (ADR, PC, XR, SP, ...) vara?
  • Hur stora behöver de olika minnena (minst) vara?
  • Vilka minnen behöver CPU-n läsa/skriva i?
  • Räcker minnet i FPGAn till för att implementera det ni tänkt er?
  (Minnesåtgång för t.ex. programminne kan vara svårt att veta. Gör en grov uppskattning.)
• Programmering:
  • Hur ska systemet programmeras? Vad behöver programmeras?
  • Behöver en assembler implementeras? (Ett tips från mig är att implementera en assembler för er CPU, eftersom det är rätt trist att skriva instruktioner i binärkod i längden... Det kan ni göra i ert favoritprogrammeringsspråk!)
• Timing:
  • Stora delar av tiden kommer erat program sannolikt bara att behöva vänta på att en viss tid har förflutit. Processorn klockas i 100 MHz och den kommer alltså att köra flera miljoner instruktioner per sekund. Så hur ska man göra för att få t ex ett grafisk objekt att förflytta sig med lämplig hastighet?
  • Funkar det att göra timing i samband med bilduppdatering? I så fall kanske Vsync kan användas på nåt sätt
  • Kan man ha en vänteloop i programmet? Hur många programcykler blir det?
  • Behöver man ha en separat räknare som håller reda på en viss tid?
• Boot-loader:
  • Mot slutet av projektet, när konstruktionen blir större, kommer det ta längre och längre tid att syntetisera. Samtidigt handlar det mesta arbetet då om att skriva programmet till datorn.
  • Dvs, varje liten programförändring kan då ta flera minuter att testa, om programkoden skrivs direkt i programminnet i VHDL-koden.
  • Det kan löna sig att bygga en boot-loader vars enda uppgift är att vänta på inkommande data/programkod från en UART, placera in det på rätt plats i minnet på den körande datorn och sedan starta programmet.
  • Dvs, det enda program som finns i datorn från början är boot-loader-programmet.
• Milstolpe:
  • Det står i de generella anvisningarna, men jag säger det igen: Glöm inte att specificera ett halvtidsmål, eftersom det ska examineras. T.ex. kan det vara att i simulering kunna visa upp en fungerande processor och ha ritat åtminstone någonting på en skärm. Ni bestämmer själva!
• Blockscheman:
  • Rita åtminstone ett översiktsschema, men i de flesta fall är det nog också motiverat med ett detaljschema över t.ex. er grafikenhet, eftersom denna kan innehålla en större mängd klurigt ihopkopplade komponenter. Schemana behöver inte vara supersnygga datorritade mästerverk (om ni inte vill). Även handritade inscanningar accepteras så länge de är läsbara. Undvik fotografier av ritat material, då det oftast blir snett, ofokuserat eller dåligt exponerat.