OBSERVERA!! Dessa sidor är numera utdaterade. Kursens websidor finns i Lisam.
Institutionen för systemteknik
Göm meny

Examination TSEA83


Redovisningsschema och anmälan till redovisningstider görs i Excel-dokumentet Anmälan_Redovisning i Lisam.


Ni behöver bara närvara vid ert eget tillfälle. Varje grupp får 12-15 minuter för sin presentation och 5-6 minuter för sin demonstration av projektet.

OBS, att vi kräver PowerPoint (eller något liknande), för själva presentationen.

Den tekniska rapporten (gärna i PDF-format) ska tillsammans med källkoden finnas incheckad i master-branch i Gitlab, när projektet är färdigt. Skicka en notis till handlederen när det är gjort. Vederbörande läser, kommenterar och godkänner rapporten.

Läs mer om Presentation, Demonstration, Teknisk dokumentation, Återlämning längre ner på sidan.


Presentation

Normalt redovisar 4-5 grupper per tillfälle. Gruppen ska vara närvarande vid ett tillfälle.

Uppdraget är att ni ska presentera er tekniska lösning och er produkt på ett bra sätt. Framhåll gärna datorns roll i det hela, hur den hanterar in- och ut-data och vilket syfte den har i konstruktionen. Tänk er att de som lyssnar är tekniska experter, med samma kunskap som ni. Dessa experter överväger att för sitt företags räkning köpa er konstruktion förmodligen för att bygga in den i en större produkt. De är alltså ganska intresserade av hur apparaten egentligen fungerar och kan tänkas ställa intrikata frågor!


Demonstration

Gör en kort demonstration av er konstruktion för samma tekniska experter. Ni kan låtsas att de har kravspecifikationen i händerna och att de inte vill köpa grisen i säcken!


Teknisk rapport

Allmänt

Den tekniska rapporten ska vända sig till personer med ungefär samma grundkunskaper som ni själva har. När ni skriver texten, så tänk på läsbarheten. Det finns alltså en läsare till er rapport. Ni ska alltså på ett pedagogiskt sätt förklara för läsaren hur grunkan funkar. Det gäller alltså att inte tappa bort läsaren. Speciellt viktigt är detta i inledningen på nya avsnitt. Omfattningen av rapporten behöver vara sådan att man med den som underlag i princip skulle kunna bygga upp projektet på nytt. Ca 12-17 sidor kan kanske vara en lämplig mängd sidor.

Den tekniska rapporten ska innehålla en beskrivning av hur produkten är konstruerad och hur man använder den. Underlag för detta hittar ni till stor del i er designskiss.

Tillståndsdiagram och blockschemor, som har förklaringsvärde, placeras med fördel i den löpande texten. Tänk på att figurer och tabeller ska numreras och refereras.

Eventuella kretsschemor, komponentförteckningar och övrigt referensmaterial placeras i bilagor.

Källkoden, däremot, placeras i projektets Gitlab-konto i master-branch.

Vi vill att den tekniska dokumentationen ska bestå av en enda sammanhållen pdf-fil.

Förslag på innehållsförteckning:

  • 1. Inledning
    Bakgrund, syfte, källor
  • 2. Apparaten
    Börja gärna med en bild på bygget och redgör för hur apparaten används. Detta blir en kombinerad presentation av konstruktionen och användarhandledning.
  • 3. Teori
    Här kan ett videoprojekt beskriva videoformatet, ett MIDI-projekt redogöra för MIDI-standarden, förekommer någon beräkningsalgoritm t ex kortaste-väg-sökning eller en fraktalalgoritm och hur fungerar då dessa, dvs den teoretiska bakgrunden till olika tekniska lösningar i projektet. Måhända finns dock inget som tarvar en teoretisk utläggning.
  • 4. Hårdvaran
    Börja med ett översiktligt blockschema, gå vidare till mera detaljerade blockschemor. Vill man rita figurer och blockschemor på datorn så är Inkscape ett bra alternativ. Handritade figurer och blockschemor är acceptabelt, bara de är snygga och väl läsbara, MEN dessa ska då vara inscannade, dvs avfotograferade figurer och blockschemor är INTE godtagbart.
    Beskriv sedan hur de olika blocken fungerar. Tänk på läsbarheten och växla mellan figurer och text. Den här typen av text är ganska "grafisk", då nästan varje mening syftar in i en figur. Var därför noga med att text och figurer stämmer överens.
  • 5. Slutsatser
    Vad gick bra? Vilka problem förekom? Vad kunde göras bättre? Vad har vi lärt oss?
  • 6. Referenser
  • Appendix. VHDL-kod
    Inte själva VHDL-koden utan en förklaring av den. Det är ju inte säkert att VHDL-kodens processer och andra delar tydligt matchar dom blockchemor som ritats i hardvaruavsnittet. Då kan det vara lämpligt att förklara vad koden gör. Om VHDL-koden är väl strukturerad med bra kommentarer så räcker det gott att bara inkludera den i en tar-fil, enligt instruktioner ovan.
  • Appendix. Övriga listor / bilagor
    T ex kopplingsschemor och dylikt i förekommande fall. Maskinkod och dokumentation av denna. Lista över instruktioner, vad de betyder och vilka argument de tar.

Tänk på att tyngdpunkten i rapporten bör ligga på avsnittet med hårdvaran.

Tänk på att alla i gruppen ska ha granskat den version som lämnas in. Lämna inte inte en ofullständig eller slarvigt skriven version. Det leder bara till fler kompletteringar, och tar längre tid.


Återlämning

FPGA-kortet och andra komponenter ska återlämnas till handledaren. Återlämningen ska göras så snart som möjligt efter demonstrationstillfället.

Godkännande

För att bli godkänd i kursen krävs:
  • Väl utfört konstruktionsarbete
  • Föredrag
  • Demonstration av fungerande apparat
  • Godkänd dokumentation: Kravspecifikation, designskiss och teknisk rapport.
  • Återlämning av utkvitterad materiel. Återlämnas till handledaren.


Informationsansvarig: Anders Nilsson
Senast uppdaterad: 2022-05-05