B-ASIC - Better ASIC Toolbox : En verktygslåda som förenklar design och optimering av ASIC

Linköpings universitet SE–581 83 Linköping

Linköpings universitet | Institutionen för datavetenskap

Kandidatrapport på grundnivå, 15hp | Datateknik

2020 | LIU-IDA/LITH-EX-G--2020/059--SE

B-ASIC - Better ASIC Toolbox

–

En verktygslåda som förenklar design och optimering av ASIC

B-ASIC - Better ASIC Toolbox

–

A toolbox that simplifies ASIC design and optimization

Angus Lothian

Arvid Westerlund

Adam Jakobsson

Felix Goding

Ivar Härnqvist

Jacob Wahlman

Kevin Scott

Rasmus Karlsson

Handledare : Lena Buffoni Examinator : Kristian Sandahl

Upphovsrätt

Detta dokument hålls tillgängligt på Internet - eller dess framtida ersättare - under 25 år från publice-ringsdatum under förutsättning att inga extraordinära omständigheter uppstår.

Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Över-föring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och till-gängligheten finns lösningar av teknisk och administrativ art.

Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet änd-ras eller presenteänd-ras i sådan form eller i sådant sammanhang som är kränkande för upphovsmannens litterära eller konstnärliga anseende eller egenart.

För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/.

Copyright

The publishers will keep this document online on the Internet - or its possible replacement - for a period of 25 years starting from the date of publication barring exceptional circumstances.

The online availability of the document implies permanent permission for anyone to read, to down-load, or to print out single copies for his/hers own use and to use it unchanged for non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional upon the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility. According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement.

For additional information about the Linköping University Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its www home page: http://www.ep.liu.se/. © Angus Lothian Arvid Westerlund Adam Jakobsson Felix Goding Ivar Härnqvist Jacob Wahlman Kevin Scott Rasmus Karlsson

Sammanfattning

Denna rapport behandlar ett arbete skriven av åtta studenter som läste kursen TDDD96 Kandidatprojekt i programvaruutveckling vid Linköpings universitet under vårterminen 2020. Projektets syfte var att utveckla en verktygslåda i Python och C++ för att konstruera signal-behandlade kretsar. Denna verktygslåda är tänkt att användas inom laborationer i kursen TSTE87 Applikationsspecfika integrerande kretsar vid Linköpings universitet och inom forsk-ning för utveckling av ASIC:s.

Projektet resulterade i produkten B-ASIC. B-ASIC är ett bibliotek för programmeringssprå-ket Python som är skrivet i Python med en underliggande modul i C++. B-ASIC används för design och optimering av ASIC:s. Produkten B-ASIC erbjuder ett grafiskt användar-gränssnitt där användaren kan interagera med biblioteket utan programmeringskunskaper inom Python.

I rapporten beskrivs hur projektarbetet har anpassats för att vara till värde för kunden och hur utvecklingsprocessen har påverkat resultatet av produkten. Projektmedlemmarna har dessutom genomfört egna undersökningar och dessa finns att läsa i slutet av rapporten.

Författarens tack

Projektgruppen vill ägna ett tack till kunden Oscar Gustafsson vid Institutionen för systemtek-nik på Linköpings universitet för sin delaktighet och rådgivning i projektet B-ASIC. Vidare vill även projektgruppen tacka examinatorn Kristian Sandahl och projektgruppens handle-dare Lena Buffoni som visat ett hängivet intresse för projektet och dess framgång i kursen TDDD96 Kandidatprojekt i programvaruutveckling vid Linköpings universitet.

Innehåll

3.2 Programmeringsspråk och programmeringsbibliotek . . . 10

3.3 Utvecklingsmetoder . . . 11

3.4 Utvecklingsverktyg . . . 13

3.5 Systemanatomi . . . 14

3.6 Samarbetsmiljöer . . . 15

4 Metod 17 4.1 Metodik för att fånga erfarenheter . . . 17

4.2 Metodik för att skapa värde för kunden . . . 17

4.3 Metodik för användning av systemanatomin . . . 18

4.4 Metodik för ökad ASIC-användning . . . 18

4.5 Utvecklingsmetodik . . . 19

5 Resultat 26 5.1 Systembeskrivning . . . 26

5.2 Jämförelse av B-ASIC med MATLAB-verktygslåda . . . 28

5.3 Testning av B-ASIC . . . 28

5.4 Processbeskrivning . . . 28

5.5 Resultat av B-ASIC:s värdeskapande . . . 29

5.6 Resultat av fångade erfarenheter . . . 31

5.7 Resultat av användning av systemanatomin . . . 33

5.9 Översikt över individuella bidrag . . . 36

6 Diskussion 39 6.1 Jämförelse av B-ASIC och MATLAB-verktygslådan . . . 39

6.2 Diskussion av testning . . . 40

6.3 Diskussion om fångade erfarenheter . . . 41

6.4 Diskussion om B-ASIC:s värdeskapande . . . 43

6.5 Diskussion om användning av systemanatomi . . . 47

6.6 Diskussion om ökad ASIC-användning . . . 47

6.7 Valda metoder . . . 49

6.8 Alternativa implementationssätt . . . 50

6.9 Diskussion om arbetet utifrån vidare sammanhang . . . 51

7 Slutsats 53 7.1 Hur kan systemet B-ASIC implementeras så att man skapar värde för kunden? 53 7.2 Vilka erfarenheter kan dokumenteras från programvaruprojektet B-ASIC som kan vara intressanta för framtida projekt? . . . 53

7.3 Vilket stöd kan man få genom att skapa och följa upp en systemanatomi? . . . 54

7.4 Vilka möjligheter för ökad ASIC-användning öppnar B-ASIC upp inom olika områden? . . . 54

A Hur påverkas ett projekt beroende på involveringen av kunden av Adam Jakobsson 55 A.1 Inledning . . . 55 A.2 Bakgrund . . . 56 A.3 Teori . . . 56 A.4 Metod . . . 57 A.5 Resultat . . . 58 A.6 Diskussion . . . 60 A.7 Slutsatser . . . 63

B Jämförelse av prestanda och parallellisering av vanliga operationer inom linjär algebra för NumPy och MATLAB av Angus Lothian 65 B.1 Inledning . . . 65 B.2 Bakgrund . . . 66 B.3 Teori . . . 66 B.4 Metod . . . 67 B.5 Resultat . . . 70 B.6 Diskussion . . . 74 B.7 Slutsatser . . . 75

C Tidsestimering, idag och i framtiden av Arvid Westerlund 77 C.1 Inledning . . . 77

C.2 Tidigare forskning i området . . . 78

C.3 Teori . . . 78

C.4 Metod . . . 81

C.5 Resultat . . . 82

C.6 Diskussion . . . 83

C.7 Slutsatser . . . 85

D Användning av GitFlow i mjukvaruutvecklingsprojekt av mindre skala av Felix Goding 86 D.1 Inledning . . . 86

D.2 Bakgrund . . . 87

D.4 Metod . . . 91

D.5 Resultat . . . 92

D.6 Diskussion . . . 94

D.7 Slutsatser . . . 96

E Dataorienterad design till icke-prestandakritiska projekt av Ivar Härnqvist 98 E.1 Introduktion . . . 98 E.2 Bakgrund . . . 99 E.3 Teori . . . 99 E.4 Metod . . . 100 E.5 Resultat . . . 101 E.6 Diskussion . . . 105 E.7 Slutsatser . . . 106

F Applicering av Scrum och Kanban-processer i små agila grupper av Jacob Wahlman108 F.1 Introduktion . . . 108 F.2 Bakgrund . . . 109 F.3 Teori . . . 109 F.4 Metod . . . 114 F.5 Resultat . . . 116 F.6 Diskussion . . . 125 F.7 Slutsatser . . . 132

G Testdriven utveckling i ett mindre mjukvaruprojekt av Kevin Scott 133 G.1 Introduktion . . . 133 G.2 Bakgrund . . . 134 G.3 Teori . . . 134 G.4 Metod . . . 135 G.5 Resultat . . . 136 G.6 Diskussion . . . 139 G.7 Slutsatser . . . 141

H Effekterna av att definiera kvalitetsprocesser i en liten mjukvaruprojektsgrupp av Rasmus Karlsson 142 H.1 Inledning . . . 142 H.2 Bakgrund . . . 143 H.3 Teori . . . 143 H.4 Metod . . . 144 H.5 Resultat . . . 145 H.6 Diskussion . . . 149 H.7 Slutsatser . . . 151 I Bilagor 152 I.1 GUI . . . 152 I.2 Systemanatomi . . . 155

I.3 Resultatet av enkätfrågorna för kundinvolvering . . . 156

Figurer

3.1 Exempel på hur en signalflödesgfraf kan se ut. Figur visar flödet från insignal x(n)

till utsignal y(n). . . 8

3.2 Exempel på hur en prioritetsgraf kan se ut. . . 9

3.3 Exempel på hur ett schema ser ut utgående från en signalflödesgraf. . . 10

4.1 Exempel av ett issue som använts i projektet. . . 22

4.2 Projektgruppens Kanban-bräde med de olika issue som behövs göras. De olika kolumnerna i bilden representerar de olika stadierna ett issue kan befinna sig i. . . 23

5.1 Ett additionsträd representerat i det grafiska gränssnittet. . . 27

5.2 Prototyp av det grafiska gränssnittet till B-ASIC. . . 30

B.1 Resultat från invertering av matris. . . 71

B.2 Resultat från beräkning av determinant till matris. . . 71

B.3 Resultat från beräkning av egenvärden och egenvektorer till matris. . . 72

B.4 Resultat från beräkning av kvadrat till matris. . . 72

B.5 Resultat från matrismultiplikation. . . 72

B.6 Resultat från matrisaddition. . . 73

B.7 Resultat från lösning av generellt linjärt ekvationssystem. . . 73

B.8 Resultat från lösning av homogent linjärt ekvationssystem. . . 73

B.9 Resultat från beräkning av minstakvadratlösning till överbestämt genrellt linjärt ekvationssystem. . . 74

D.1 En incheckningshistorik i form av en rak linje. Varje cirkel representerar en in-checkning. . . 89

D.2 En incheckningshistorik i form av en graf där nod E och F är incheckningar som tillhör en gren som skapats från mästergrenen i nod B. Nod D representerar sam-manfogningen mellan den skapade grenen och mästergrenen. . . 89

D.3 En incheckningshistorik i form av en graf där nod E och F är incheckningar som tillhör en gren som skapats från mästergrenen i nod B och sedan flyttats fram till att börja från nod D. . . 90

D.4 En bild över hur arbetsflödet GitFlow ser ut. Noderna representerar incheckningar hos de olika grenarna. Två pilar till samma nod representerar en sammanfogning mellan två grenar. . . 91

D.5 En bild över ett diagram som visar hur många utvecklare som använder sig av inchecknings omstrukturering (en. commit refactoring). Y-axeln beskriver antalet år utvecklarna har arbetat med utveckling och x-axeln beskriver hur stor andel som använder inchecknings omstrukturering [commitRefactoring]. . . . 94

G.1 Mätningar på antalet testfall och kodtäckning. . . 137

G.2 Arbetsflödet under iteration 2 och iteration 3. . . 137

G.3 Cirkeldiagram för andelen projektmedlemmar som har använt sig av testdriven utveckling i projektet. . . 138

G.4 Stapeldiagram för hur svårt det var att använda TDD i projektet. . . 138

G.5 Stapeldiagram för hur testdriven utveckling har påverkat kodkvalitet . . . 138

G.6 Stapeldiagram för hur testdriven utveckling har påverkat testkvalitet . . . 139

G.7 Cirkeldiagram för andelen projektmedlemmar som tyckte att det har tagit längre tid att bli klar med projektet. . . 139

H.1 En cirkelgraf med antalet procent som svarade Ja och Nej på fråga 2. . . 146

H.2 En cirkelgraf med antalet procent som svarade Ja och Nej på fråga 4. . . 147

H.3 Ett stapeldiagram över svaren på fråga 5. . . 147

H.4 Ett stapeldiagram över svaren på fråga 6. . . 147

H.5 Ett cirkeldiagram över svaren på fråga 7. . . 148

H.6 Ett stapeldiagram över svaren på fråga 8. . . 148

I.1 Första pappersprototypen av GUI:t som visades för kund. . . 153

I.2 Slutgiltig GUI-design som levererades till kund. . . 154

Tabeller

0.1 Tabell med termer och dess förklaring. . . 1

4.1 Dokument och dess respektive ansvarige. Beskrivningar av rollerna återges i Ka-pitel 4.5.8. . . 20

5.1 Tabell över resultaten från gruppens processmål, med möten, tidsestimeringar, faktiska tidsuppmätningar, skillnad i minuter och skillnad i procent i de olika ko-lumnerna. . . 29

5.2 Erfarenheter från februari månad. . . 32

5.3 Erfarenheter från mars månad . . . 32

5.4 Erfarenheter från april månad. . . 33

5.5 Kundintervju för ökad ASIC-användning med hjälp av B-ASIC . . . 36

6.1 Jämförelser mellan första och slutgiltiga GUI-prototypen . . . 44

6.2 Projektets restlista av krav som ej uppnåddes. . . 46

A.1 Svar på enkätfrågor 5-10. . . 60

A.2 Svar på enkätfrågor 5-10 i sin helhet. . . 60

A.3 Jämförelser mellan medelvärde på kriterierna. . . 62

B.1 Utförda prestandajämförelser av linjär-algebraoperationer samt deras korrespon-derande operationer i MATLAB och NumPy. Notera att förkortningen np repre-senterar numpy. . . 68

B.2 Hård- och mjukvara specifikationer för prestandajämförelserna. . . 70

C.1 Estimerad- och faktiskt tidsåtgång i timmar på ett antal issues från projektet B-ASIC. 83 E.1 Klasser i OOP-implementationen av simuleringssystemet . . . 103

E.2 Klasser i DOD-implementationen av simuleringssystemet . . . 103

E.3 Jämförelse av kodegenskaper mellan OOP- och DOD-implementationerna . . . 104

E.4 Jämförelse av exekveringstid mellan Python-, OOP- och DOD-implementationerna 104 E.5 Jämförelse av exekveringstid mellan Python-, OOP- och DOD-implementationerna med ett större antal iterationer . . . 104

F.1 Artefakter inom Scrum . . . 110

F.2 Roller inom Scrum . . . 111

F.3 Aktiviteter inom Scrum . . . 112

F.4 Enkät 1, Erfarenheter och förväntningar . . . 116

F.5 Enkät 2, Erfarenheter och åsikter om Sprint 1 . . . 117

F.6 Enkät 3, Erfarenheter och åsikter om Sprint 2 . . . 118

F.7 Sprint 1 mätvärden . . . 119

F.8 Sprint 1 medelvärden av mätvärden . . . 120

F.9 Sprint 2 mätvärden . . . 120

F.11 Enkät 4, Erfarenheter och förväntningar om Kanban-processen . . . 121

F.12 Enkät 5, Erfarenheter och åsikter om iteration 1 . . . 121

F.13 Enkät 6, Erfarenheter och åsikter om iteration 2 . . . 122

F.14 Iteration 1 mätvärden. . . 123

F.15 iteration 1 medelvärden av mätvärden . . . 124

F.16 Iteration 2 mätvärden . . . 124

F.17 Iteration 2 medelvärden av mätvärden . . . 124

H.1 Tabell över svaren på fråga 1. . . 145

H.2 Tabell över svaren på fråga 2. . . 146

Definitioner

Detta kapitel ämnar informera om definitioner och termer som används i denna rapport samt projektet B-ASIC.

Tabell 0.1: Tabell med termer och dess förklaring.

Term Definition

ASIC Applikationspecifik integrerad krets, (en. Application Specific In-tegrated Circuit). En krets som har ett enda ändamål.

Branch En gren (en. branch) som utvecklingen av en funktionalitet sker på.

C++ Statiskt typat programmeringsspråk. Daily-Scrum Daily-Scrum är ett dagligt Scrum-möte.

GUI Grafiskt användargränssnitt (en. Graphical User Interface). Issue Ett issue är ett objekt av arbete som ska genomföras i ett agilt

brä-de.

Issue-bräde Ett issue-bräde är en typ av bräde som beskriver det arbete och arbetsflöde som följs.

Kanban Kanban är ett agilt arbetssätt.

MATLAB Dynamiskt typat programmeringsspråk för matematiska och tek-niska beräkningar.

Minneselement Ett minneselement är en abstrakt minmal komponent som kan lagra ett variabelvärde.

Operation En operation är ett minimalt beräkningselement.

Operatoröverlagring Möjligheten att bestämma beteendet för operatorer, exempelvis för ’+’.

PG Prioritetsgraf (en. Precedence Graphs/Precedence Chart) är en graf som beskriver ordningen som operationer i en SFG utförs i. Processorelement Ett processorelement är en abstrakt minimal komponent som utför

en specifik beräkning på indata och ger utdata.

Product backlog Product backlog är den lista över funktionalitet som ska imple-menteras.

TABELLER

Tabell 0.1 – fortsättning från föregående sida

Term Definition

Python Dynamiskt typat programmeringsspråk.

Schema Ett schema kan genereras från en prioritetsgraf och beskriver då vilka operationer som utförs när för en ASIC.

Scrum Scrum är ett agilt arbetssätt.

SFG En signalflödesgraf (en. Signal Flow Graph) är en riktad graf med in och utdata som består av en eller flera operationer.

SoC Ett systemchip (en. System-on-a-Chip) är en ASIC som består av flera olika sorters processorer.

Sprint Sprint är tidsfixerat intervall i Scrum-processen.

Sprint-planning Sprint-planning är en aktivitet för planering av en Sprint i Scrum-processen.

Sprint-retrospective Sprint-retrospective är en aktivitet för erfarenheter av en Sprint i Scrum-processen.

Sprint-review Sprint-review är en aktivitet för utvärdering av en Sprint i Scrum-processen.

Systemanatomi Systemanatomi är en visuell beskrivning av ett systems funktio-naliteter och dess beroenden mellan varandra.

TDDD96 Kursen TDDD96 Kandidatprojekt i programvaruutveckling vid Linköpings universitet.

TSTE87 Kursen TSTE87 Applikationspecifika integrerade kretsar för digi-tal signalbehandling vid Linköpings universitet.

1

Inledning

B-ASIC är en verktygslåda som är ämnad att förenkla utvecklingen av applikationspecifika integrerade kretsar (ASIC). ASIC:s är ofta förekommande i till exempel datorer eller mobilte-lefoner för applikationer där prestandan är viktigare än möjligheten att ändra kretsens funk-tionalitet. Dessa ASIC:s kan vara mycket dyra att utveckla i liten skala och ett verktyg för simulering av dessa innan fysisk produktion kan bespara mycket tid och pengar för projekt som arbetar med ASIC:s. Projektet och denna rapport var en del av kursen TDDD96.

1.1

Motivering

Kursen TSTE87 använde sig för tillfället av en verktygslåda. MATLAB-verktygslådan hade begränsningar inom prestanda och användarbarhet. Exempel på be-gränsningar med MATLAB-verktygslådan var att den var långsam, saknade stöd för an-vändarvänliga funktioner som operatoröverlagring samt saknade ett grafiskt användargräns-snitt. En ny verktygslåda som var både enklare att använda och utföra funktioner med be-hövde utvecklas eftersom en sådan verktygslåda inte bara skulle underlätta för de som läser kursen, utan också för de som syftar på att använda den inom forskning. Denna verktygslåda behövde funktionalitet för att skapa, simulera och analysera kretsar, där operationerna kunde vara av en enkel typ till exempel addition, eller av en komplex typ, till exempel egenskriven Python-kod.

1.2

Syfte

Syftet med undersökningen var att besvara frågeställningarna i kapitel 1.3. För att besva-ra dessa utvecklade projektgruppen grunderna till en verktygslåda skriven i Python samt C++ vid namn B-ASIC och som kan användas för konstruktion av signalbehandlande kret-sar. Syftet var dessutom att B-ASIC skulle ersätta den nuvarande verktygslådan som använ-des inom laborationer i kursen TSTE87. B-ASIC skulle använ-dessutom vara snabbare och enklare att använda vilket skulle göra det enklare för de som läser kursen TSTE87 att genomföra

1.3. Frågeställningar

kursmoment. B-ASIC var vidare tänkt att kunna användas inom forskning och utveckling av ASIC-processorer. Syftet med projektet var dessutom att samla erfarenheter från utvecklings-arbetet.

1.3

Frågeställningar

1. Hur kan systemet B-ASIC implementeras så att man skapar värde för kunden?

2. Vilka erfarenheter kan dokumenteras från programvaruprojektet B-ASIC som kan vara intressanta för framtida projekt?

3. Vilket stöd kan man få genom att skapa och följa upp en systemanatomi?

4. Vilka möjligheter för ökad ASIC-användning öppnar B-ASIC upp inom utbildning och användning av ASIC:s?

1.4

Avgränsningar

Projektgruppen begränsar sig till att enbart använda programmeringsspråken Python samt C++. Projektgruppen begränsar sig till att enbart verifiera att produkten fungerar med ope-rativsystemet Ubuntu 18.04. Projektgruppen begränsar sig till att programmet ska levereras med en MIT-licens [1], därav användes enbart externa bibliotek som följer MIT-licensen eller kan användas under MIT-licensen.

2

Bakgrund

Avdelningen för datorteknik vid Institutionen för systemteknik (ISY) vid Linköpings univer-sitet bedriver forskning och undervisning inom digital hårdvara. Avdelningen tillhandahål-ler kursen TSTE87, där kursdeltagarna får lära sig om strukturen för en ASIC. Ett moment i denna kurs är en laboration där de får konstruera signalbehandlande kretsar. Kursledningen var i behov av ett program som enkelt kan automatisera konstruktionsflödet och represente-ra denna struktur tydligt för användaren. Konstruktionsflödet för en ASIC består av att man kopplar ihop ett antal operationer som var för sig utför någon grundläggande funktion till en signalflödesgraf som beskriver flödet från indata till utdata. Sedan kan signalflödesgrafen simuleras för att verifiera att den är korrekt, det vill säga ger den utdata som är förväntad. Därefter kan signalflödesgrafen analyseras genom att generera ett schema som beskriver vil-ka operationer som utförs när, samt extrahera använda minnes- och processorelement. Innan projektets början fanns det en egenutvecklad verktygslåda för MATLAB [2]. Det fanns dock begränsningar hos denna verktygslåda när mer komplicerade kretsar skulle konstrue-ras. Begränsningar beskrivs i Avsnitt 1.1.

Kunden önskade en nyutvecklad verktygslåda i Python med syfte att ersätta den nuvarande verktygslådan som användes i kursen. Kunden var dessutom öppen för att underliggande funktionaliteter kunde utvecklas i C++. Kunden önskade även att den nya verktygslådan B-ASIC skulle gå att använda inom forskning. B-B-ASIC skulle vara enkel att vidareutveckla och skulle vara kompatibel med den öppna källkodslicensen MIT [1].

Kunden vill inte använda produkter som Simulink [3] då de inte är anpassningsbara nog samt avsaknaden av möjligheten att interagera med produkten genom Python-kod. Kunden nämnde även att sådana verktyg är för automatiserade vilket medför att användaren inte kan påverka delar av konstruktionsflödet.

2.1. Projektgruppen

2.1

Projektgruppen

Projektet utfördes av åtta civilingenjörsstudenter från programmen datateknik och mjuk-varuteknik vid Linköpings universitet. Samtliga projektmedlemmar hade läst fem terminer inom deras respektive civilingenjörsprogram innan projektets början. Det fanns en varians i gruppmedlemmarnas programmeringsvana, men samtliga projektmedlemmar hade erfaren-het inom Python och C++. Ingen projektmedlem hade erfarenerfaren-het av bibliotek som PySide2 [4] och Pybind11 [5]. Samtliga projektmedlemmar var bekanta med signalteori, men inte ASIC:s.

3

Teori

Detta kapitel är ämnat att ge läsaren förståelse för de olika begrepp, termer och verktyg som förekommer i de olika delarna av rapporten.

3.1

Konstruktion av signalbehandlande kretsar

Nedan beskrivs de termer och verktyg som berör konstruktion av signalbehandlande kretsar.

3.1.1

ASIC-Verktygslåda

En ASIC-verktygslåda (hädanefter benämnd som verktygslåda) är en samling av verktyg för att konstruera en virtuell uppsättning av operationer och signaler. Dessa operationer tar in-data, manipulerar indatan och ger en form av utdata. En sådan verktygslåda kan därmed vara ett slags konstruktionsflöde för att konstruera dessa kretsar som sedan kan simuleras och analyseras därefter. För att konstruera kretsarna skapas signalflödesgrafer som represen-terar de beräkningar som behöver utföras och hur dessa är sammankopplade. Verktygslådan kan dessutom innefatta annan funktionalitet som generering av scheman och prioritetsgrafer från signalflödesgrafer.

3.1.2

ASIC

En ASIC är en integrerad krets som är skapad för en specifik applikation istället för att vara en generell processor som kan klara av olika uppgifter. En ASIC består av hårdvarukomponenter som utför grundläggande operationer som addition eller multiplikation, och ger utifrån en mängd indata en mängd utdata. [6]

3.1. Konstruktion av signalbehandlande kretsar

3.1.3

Operation

En operation är en minimal enhet som utför en funktion och genererar utdata baserat på indata. I en verktygslåda kan operationer vara grundläggande aritmetiska funktioner som addition, tidsfördröjning och multiplikation. Det finns dessutom möjlighet att definiera egna operationer (en. custom operation). Exempel på operationer som tidsfördröjning, multiplika-tion, addition och kvantifiering återges i Figur 3.1.

3.1.4

Signalflödesgraf

En signalflödesgraf är en riktad flödesgraf där noderna representerar variabler till ett system och bågar i grafen representerar kopplingen mellan dessa noder. En signalflödesgraf beskri-ver flödet och manipulationerna från indata till utdata [7]. I kursen TSTE87 definieras en signalflödesgraf som ett blockdiagram [8]. I projektet är noderna i signalflödesgrafen opera-tioner eller en annan signalflödesgraf. En signalflödesgraf kan på detta sätt beskriva kretsen i en ASIC på en högre nivå. I Figur 3.1 kan ett exempel på en signalflödesgraf från kursen TSTE87 [9] ses.

Figur 3.1: Exempel på hur en signalflödesgfraf kan se ut. Figur visar flödet från insignal x(n) till utsignal y(n).

3.1.5

Prioritetsgraf

En prioritetsgraf är en graf som beskriver ordningen och beroenden hos operationer [9]. En prioritetsgraf kan genereras från en signalflödesgraf, och kan därmed beskriva ordningen och beroendet av operationerna som görs i en ASIC. I Figur 3.2 kan ett exempel på en prioritets-graf från kursen TSTE87 [9] ses där den utgår från den signalflödesprioritets-graf som återges i Figur 3.1.

3.1. Konstruktion av signalbehandlande kretsar

Figur 3.2: Exempel på hur en prioritetsgraf kan se ut.

3.1.6

Schema

Ett schema beskriver när i tiden en mängd uppgifter ska exekveras relativt varandra, där en process innebär en godtyckligt stor beräkningsuppgift [10]. Ett schema kan genereras från en prioritetsgraf och beskriver vilka operationer som utförs när för en ASIC. I Figur 3.3 kan ett schema ses i Figur 3.3b som utgår från siganlflödesgrafen i Figur 3.3a. Exemplet är ett exempel från kursen TSTE87 [10].

3.2. Programmeringsspråk och programmeringsbibliotek

(a) Korresponderande signalflödesgraf till

schemat. (b) Exempel på hur ett schema kan se ut.

Figur 3.3: Exempel på hur ett schema ser ut utgående från en signalflödesgraf.

3.2

Programmeringsspråk och programmeringsbibliotek

Nedan beskrivs de programmeringsspråk och programmeringsbibliotek som har använts i utvecklingen av projektet.

3.2.1

C++

C++ är ett programmeringsspråk för allmän programmering som är baserat på språket C och tillåter relativt hårdvarunära programmering. Projektgruppen använde C++17 som specifi-ceras av standarden ISO/IEC 14882:2017 [11]. Vissa delar av produkten var beroende av mer resurskrävande algoritmer och därför var de delarna skrivna i C++.

3.2.2

CMake

CMake är ett system som hjälper till att konfigurera byggsystemet för att bygga C- och C++-projekt oavsett vilken hårdvara eller kompilatormiljö som används. CMake lämpar sig väl till projekt som ska kunna kompileras på flera olika datorarkitekturer och operativsystem [12]. Projektgruppen använde sig av CMake för att kompilera den kod som var skriven i C++ inom produkten.

3.2.3

Python

Python är ett dynamiskt typat objektorienterat programmeringsspråk [13]. Projektgruppen använde sig av Python 3 eftersom det var efterfrågat av kunden. Att Python är ett interpre-terat språk gör det möjligt för användaren att göra modifieringar i sin kod utan att behöva kompilera om den emellan.

3.3. Utvecklingsmetoder

3.2.4

pybind11

Biblioteket pybind11 gör det möjligt att skriva kod för Python i C++ och vice versa [5]. Pro-jektgruppen använde pybind11 då vissa delar av produkten var kodade i C++ och behövde därför kunna kommunicera med de delar som var kodade i Python.

3.2.5

NumPy

NumPy är ett Python-bibliotek som bland annat gör det enklare och mer effektivt att utföra avancerade beräkningar på vektorer av godtycklig dimension [14]. Projektgruppen använ-de NumPy för att beräkna väranvän-den från vektorer på olika dimensioner i produkten B-ASIC och för att förenkla kompatibiliteten med andra paket som använde sig av NumPy för att representera data.

3.2.6

Matplotlib

Matplotlib är ett Python-bibliotek för datavisualisering, till exempel grafritning [15]. Projekt-gruppen använde Matplotlib för att rita grafer och andra grafiska element som användaren skulle vilja se i produkten. Matplotlib användes som ett komplement till det grafiska gräns-snittet i produkten. Projektgruppen använde Matplotlib för att visualisera simuleringsresul-tat och scheman.

3.2.7

PySide2

PySide2 är en API skriven i Python för C++-biblioteket Qt. Qt används till att skapa grafiska användargränssnitt. PySide2 är ett projekt som gör det möjligt att använda Qt i Pythonkod [16]. Projektgruppen använde PySide2 för att bygga upp ett grafiskt användargränssnitt till systemet. Det grafiska användargränssnittet använde sig av det bibliotek som tillhandahålls av B-ASIC.

3.2.8

Graphviz

Graphviz är ett mjukvaruprogram som kan visualisera grafer [17]. Programmet visualiserar grafer på ett ordnat och strukturerat sätt. Programmet finns tillgängligt som ett Python-bibliotek. Projektgruppen använde Graphviz för att visualisera prioritetsgrafer.

3.3

Utvecklingsmetoder

Det är viktigt att utvecklingsprocessen är organiserad och välplanerad. Projektgruppen har därför använt sig av ramverk som beskriver hur det går att arbeta i en utvecklingsgrupp. Nedan beskrivs dessa ramverk.

3.3. Utvecklingsmetoder

3.3.1

Scrum

Scrum är ett ramverk som beskriver en agil arbetsprocess för utveckling av produkter. Scrum innehåller flera olika aktiviteter (en. events) som beskriver hur en projektgrupp kan arbe-ta. De olika aktiviteterna är: Sprint, planning, Daily-Scrum, review och Sprint-retrospective [18].

En Sprint är en fixerad tidsperiod, och denna tidsperiod kan pågå under exempelvis 2 veckor, där målet är att göra klart ett bestämt antal issue. Dessa issue hämtas ur en product backlog. En product backlog är en lista med alla möjliga issue som behöver implementeras och tas fram i början av varje projekt. Innan varje Sprint börjar genomförs en Sprint-planning där projekt-gruppen för diskussioner för vilka issue som behövs arbetas med och hur lång tid dessa bör ta att implementera. De issue som projektgruppen valt att arbeta med under Sprinten ingår i Sprint-backloggen som bestämmer vad projektgruppen ska utveckla under Sprinten. Sprin-ten avslutas sedan med en Sprint-review där projektgruppen går igenom ny funktionalitet av produkten. Efter Sprint-review genomförs en Sprint-retrospective där projektgruppen går igenom vad som gick bra och dåligt med Sprinten, med fokus på personliga erfarenheter från Sprinten. Ett dagligt Scrum-möte är en kort diskussion inom projektgruppen om vad alla ar-betat med, vad alla ska arbeta med under dagen samt om något hindrar en från att komma vidare i arbetet.

3.3.2

Kanban

Kanban är ett ramverk som beskriver en agil arbetsprocess för utveckling av produkter. De största skillnaderna mellan Scrum och Kanban är att Kanban inte arbetar i Sprints. Istället sker arbetet och leveranser kontinuerligt. De issue som ska arbetas med visualiseras på ett bräde. På detta bräde går det att se vilken prioritering olika issue har och vad som redan arbetas med [19]. Kanban är en populär arbetsmetodik som används mycket inom mjukva-ruutveckling. Vidare använde projektgruppen Kanban för att identifiera flaskhalsar i utveck-lingen.

3.3.3

Issue

I projektet använde projektgruppen sig av issue för att beskriva vad som behövde göras, vilket kunde ses som projektgruppens product backlog. Ett issue var en del av projektet som behövs arbetas med. Projektgruppen använde sig av issue till vad som behövde utvecklas och vilka dokument som behövde skrivas. Varje issue hade sedan en prioritering för att veta vilka som behövde arbetas med först [20]. Ett exempel på ett issue som projektgruppen tagit fram finns i Figur 4.1.

3.3.4

Git-arbetsflöde

Ett Git-arbetsflöde beskriver hur en branch ska användas och hur dessa ska genomföra en mer-ge senare. Projektgruppen använde sig av ett arbetsflöde som kallas för GitFlow. Detta inne-bar att det fanns en master branch och en develop branch. Idéen gick ut på att utveckling skedde på en develop branch och varje stabil version av programmet fanns på en master branch. Sedan skapades en branch från develop branch som kallades för feature branches. På dessa branch gjor-de utvecklare sina ändringar och när gjor-dessa var klara genomförgjor-des en merge till gjor-develop branch

3.4. Utvecklingsverktyg

[21]. Projektgruppen valde detta arbetsflöde eftersom det gör det enkelt att utveckla och in-troducera funktionaliteter en efter en, samt att hålla stabila versioner av koden isolerade från potentiellt instabila utvecklingsversioner.

3.3.5

Planning poker

Planning poker är ett verktyg som används under Sprint-planning för att tidsestimera issue i ens product backlog. Verktyget går ut på att en person i projektgruppen läser upp och för-klarar en issue och sen gör varje person i projektgruppen en egen tidsestimering genom att välja ett kort som representerar hur mycket tid som behöver spenderas på en issue. På korten som varje person kan välja mellan finns det siffror, till exempel 3 eller 15, och det är upp till projektgruppen att bestämma vad dessa siffror betyder [22]. Projektgruppen använde sig av Planning Poker för att sammanställa och diskutera medlemmarnas olika tidsestimeringar för ett visst issue, och sedan komma fram till en lämplig estimering i slutändan.

3.3.6

Testdriven utveckling

Testdriven utveckling är en utvecklingsmetodik där ingen implementation sker innan tester skapats. För en vidare förklaring av testdriven utveckling se Avsnitt G.3.1.

3.4

Utvecklingsverktyg

För att alla i projektgruppen skulle kunna arbeta parallellt med utvecklingen av programmet använde projektgruppen sig av olika utvecklingsverktyg. Med utvecklingsverktyg menas de verktyg som underlättade utvecklingen av programmet. De verktyg projektgruppen använde sig av beskrivs nedan.

3.4.1

Git

Git är ett versionshanteringsprogram som gör det möjligt för utvecklare att dela sin kod mel-lan varandra på ett smidigt sätt. Versionshantering innebär att det finns en historik över alla filer som tillhör systemet. Detta gör det möjligt att gå tillbaka till en tidigare version av sitt program om något går fel. Git möjliggör för flera utvecklare att arbeta samtidigt eftersom skillnader mellan kod kan ses över tid och ger möjligheten att kunna se vilka ändringar som har genomförts [23]. Git användes av projektgruppen som ett versionshanteringssystem som möjliggjorde arbete på distans för alla gruppmedlemmar. Det valdes för att alla gruppmed-lemmar var bekanta med detta versionshanteringssystem.

3.4.2

GitLab

GitLab är ett webb-GUI för Git där en utvecklare har en överblick över alla dess arkiv (en. repositories) och kan ändra i dessa både lokalt och via GitLab [24]. Projektgruppen använde GitLab som tjänst för att den erbjöd många användbara funktioner som issue och merge request där utvecklare kunde diskutera implementeringsfrågor, Continuous Integration, Scrum- och Kanban-bräden och privata arkiv som bara gruppmedlemmarna och behöriga personer kom åt där medlemmarna lagrade all kod.

3.5. Systemanatomi

3.4.3

Branch och merge

Under utveckling med hjälp av Git används vanligtvis branch för att inte förstöra utveckling-en på master branch. Master branch är dutveckling-en branch där huvuddelutveckling-en av kodutveckling-en befinner sig och om en ny branch skapas från den kopieras versionen på master branch till en nyskapad branch. Sedan kan utvecklaren utföra ändringar i koden utan att ändra på koden som befinner sig på master branch. När utvecklaren är klar med ändringar av koden kan den genomföra en mer-ge från sin branch med master branch [25]. Detta kan dessutom göras via GitLabs mermer-ge request. Med en merge request kan en utvecklare meddela andra utvecklare på samma projekt om att de vill genomföra en merge med sina ändringar med en branch. Då kan dessa utvecklare granska ens kod och lämna kommentarer för att slutligen godkännas eller nekas [26]. Projektgruppen använde sig av merge request för att det skulle bli enklare att hitta fel, avvikelser från satta standarder och förbättringsmöjligheter som utvecklaren av koden inte hade upptäckt. Att få in flera olika perspektiv i kodskrivandet hjälpte projektgruppen att hålla hög kvalitet och gav de andra gruppmedlemmarna en chans att lära sig vad andra medlemmar i projektgruppen hade skrivit och utvecklat på.

3.4.4

GitLab Continuous Integration

GitLab Continuous Integration (CI) är till för att integrera ens kod med befintlig kod i ett arkiv. För varje push som sker till en branch där CI är aktiverad körs fördefinierade tester som kon-trollerar att koden som genomgått en push är godkänd innan den genomför en merge till en branch [27]. All kod som inte klarar av testerna nekas till att genomföra en merge till den ge-mensamma branch för utveckling och utvecklaren bör därmed se över vad den behöver ändra för att klara av testerna. Projektgruppen valde att använda CI för att kontinuerligt kunna kon-trollera ifall det är något som inte fungerade med systemet och för att alltid ha en fungerande version på master branch.

3.4.5

GitLab issue-bräden

Under projektet använde projektgruppen sig av GitLabs integrerade bräden. Ett issue-bräde är till för att hålla koll på alla issue i projektet och organisera dessa efter behov. GitLabs issue-bräden kan användas som ett traditionellt Kanban-bräde eller ett anpassat bräde för Scrum. I brädena går det enkelt att se vilka som planerar att arbeta med vilka issue och när de bör vara klara [28]. Projektgruppen använde sig av denna funktionalitet för att få en överblick över vad som höll på att utvecklas på produkten och för att delegera arbetsuppgifter.

3.4.6

Pytest

För att koden ska hålla en bra kvalitet och uppnå projektets standarder var det viktigt att kunna testa koden. För att kunna göra detta används testramverket Pytest som är till för att automatisera testning av Python-kod [29].

3.5

Systemanatomi

En systemanatomi är en riktad graf utan cykler som visar funktionsmöjligheter i ett system i ett användarperspektiv. Grafen brukar oftast bestå av olika lager där det yttersta lagret är

3.6. Samarbetsmiljöer

de funktioner en användare kan ta del av och det innersta lagret är det fundamentala som behövs för att systemet ska fungera, till exempel en strömförsörjningskälla. En systemana-tomi används främst som en grund för att alla som berörs av systemet ska förstå systemets upplägg och interna beroenden [30]. Projektgruppen använde systemanatomin för att kun-na ta fram en implementationsordning som inte bröt mot några beroenden. De beroenden som systemanatomin syftade på att klarlägga var komponenter av programmet B-ASIC som krävde en tidigare komponents funktionalitet. Exempel på sådana beroenden i programmet B-ASIC var PGs beroende av en SFG, vilket vi kan se i Figur I.3.

3.6

Samarbetsmiljöer

Under projektet använde projektgruppen olika program för att planera och samla relevant information på ett organiserat vis. Dessa olika program beskrivs nedan.

3.6.1

Google Kalender

Google Kalender är ett kalenderprogram som används till att schemalägga aktiviteter och få påminnelser angående kommande planer. Det går dessutom att dela kalendern med andra, vilket gör programmet bra för grupper [31]. Projektgruppen använde sig av Google Kalender för att schemalägga möten och arbetstillfällen samt för påminnelser och viktiga deadlines.

3.6.2

Slack

Slack är en samarbetsyta som är skapad för projektgrupper. I Slack kan en grupp skapa en egen yta där projektgruppen kan kommunicera via kanaler där det går att kan skicka med-delanden och dela bilder. Projektgruppen använde sig av ett Google Kalender-plugin för att få påminnelser i Slack angående inplanerade aktiviteter [32]. Projektgruppen använde sig av Slack som huvudtjänsten för kommunikation, diskussion och viktiga påminnelser.

3.6.3

Google Drive

Google Drive är en molnlagringstjänst där det går att lagra filer i molnet. Projektgruppen an-vände sig av Drive genom att skapa en grupp för att dela filer i. Projektgruppen kunde sedan organisera dessa filer med hjälp av en mappstruktur [33]. Google Drive användes av grupp-medlemmarna för att spara mötesprotokoll, bilder, diagram, enkäter och andra nödvändiga filer som användes av projektmedlemmarna.

3.6.4

Overleaf

Overleaf är en webbtjänst som gör det möjligt att redigera och kompilera dokument i språ-ket LaTeX. Overleaf låter flera användare redigera samma dokument samtidigt och erbjuder dessutom granskningsfinesser [34]. Projektgruppen använde Overleaf till att skriva doku-ment som skulle lämnas in i projektkursen.

3.6. Samarbetsmiljöer

3.6.5

Zoom

Zoom är en molnbaserad videokommunikationsplattform som gör det möjligt att kommuni-cera via både text och video. Zoom har en funktion för att skapa mötesrum där flera personer kan kommunicera med varandra under exempelvis möten eller konferenser [35]. I detta pro-jekt användes Zoom för att hålla möten på distans när alla medlemmar arbetade hemifrån.

4

Metod

4.1

Metodik för att fånga erfarenheter

Den metodik projektgruppen använde för att fånga erfarenheter var att efter månaderna februari, mars och april antecknade respektive medlem i projektgruppen sina erfarenheter angående utvecklingsiterationen. Projektgruppen diskuterade och dokumenterade de erfa-renheter som återgetts. Erfaerfa-renheterna sammanställdes och användes som underlag till att presentera resultatet av projektgruppens erfarenheter.

4.2

Metodik för att skapa värde för kunden

Metodiken för hur projektgruppen skapat värde för kunden involverade bland annat att pro-jektgruppen genomförde regelbundna möten med kunden för att få återkoppling angående systemet. Mötena genomfördes varannan vecka. Kunden hade även tillgång till projektets GitLab för att kontinuerligt granska och testa produkten B-ASIC för möjligheten att ge åter-koppling.

Mötena innehöll en demonstration av den existerande prototypen av produkten samt potenti-ella frågor projektgruppen hade angående implementationen. Om det inte fanns en prototyp, visades den existerande funktionaliteten hos B-ASIC. Kunden gavs möjligheten att återge si-na synpunkter på systemet till projektgruppen.

Det genomfördes även användartester med kunden för att verifiera användarbarhet och funktionalitet. Användartesterna genomfördes i slutet av varje iteration. Återkopplingar do-kumenterades för att kunna användas som underlag vid presentation av resultatet för hur projektgruppen skapar värde för kunden. Mötena och användartesterna hanterades av pro-jektgruppens analysansvariga.

4.3. Metodik för användning av systemanatomin

En annan metodik som projektgruppen använde för att skapa värde var en prototyp för GUI:t som projektgruppen skapade. Projektgruppen tog först fram ett utkast av prototypen och den redovisas i Figur 5.2. Prototypen presenterades sedan för kunden för återkoppling. Återkopp-lingen gav upphov till revideringar i prototypen och ett nytt utkast skapades. Till sist skapa-des en datorprototyp som presenteraskapa-des för kunden för återkoppling. Projektgruppen tog sedan fram en slutgiltig prototyp som verifierades av kunden. Prototyperna och designbe-sluten dokumenterades under utvecklingen. Dokumentationen och prototyperna användes som underlag för att besvara Frågeställning 1.

En tredje metodik för att skapa värde för kunden var att projektgruppen bedrev en kontinu-erlig diskussion om kravspecifikationen. Ett första utkast av kravspecifikationen togs fram och visades för kunden. Kravspecifikationen skapade diskussion mellan kunden och pro-jektgruppen om förbättringar och förtydligande av de krav som specificerats i kravspecifika-tionen. Revideringar av kravspecifikationen gjordes efter diskussionen och den reviderade kravspecifikationen presenterades för kunden.

4.3

Metodik för användning av systemanatomin

Metodiken om hur systemanatomin användes för projektgruppen var att projektgruppen sammankopplade systemanatomin med relevanta krav i kravspecifikationen. I systemana-tomin kopplades varje systemkomponent till ett motsvarande krav från kravspecifikatio-nen. Det visualiserades med att krav-numret finns i systemkomponenten under namnet för systemkomponenten. Projektgruppen kunde sedan markera de systemkomponenter som ge-nomförts och till följd kunde projektgruppen få en överblick över vilka krav som avklarats. Ett annat användningsområde där projektgruppen använde sig av systemanatomin var pla-nering av utvecklingen. Varje systemkomponent hade en iteration tilldelad till sig som be-skrevs i respektive systemkomponent. Iterationsindelningen medförde att projektgruppen fick en överblick över vad som ska implementeras i vilken iteration och för att identifiera potentiella risker, exempelvis arbetsmängden för respektive iteration.

4.4

Metodik för ökad ASIC-användning

Metodiken för ökad ASIC-användning utreddes av projektgruppen med en litteraturstudie. Litteraturstudien undersökte vad ASIC används till och varför samt hur B-ASIC kunde an-vändas inom dessa områden. Fokusområdet för litteraturstudien var på undervisning av om-råden relaterade till ASIC-användning. Vidare undersöktes även hur B-ASIC som program kunde underlätta i syftet att undervisa för design och konstruktion av en ASIC i utbildningar på avancerad nivå.

En annan metodik projektgruppen använde för att besvara frågeställningen var att intervjua kunden. Kunden är en examinator för kursen TSTE87. Intervjun syftade på att undersöka kundens uppfattning om för vilka områden som ASIC används i nuläget, vad ASIC kan an-vändas i framtiden och vilka problem det finns med ASIC. Till sist syftade intervjun även på att undersöka för vilka produkter för konstruktion och design av en ASIC, samt hur produk-ten B-ASIC kan användas inom respektive område. Kundens svar på intervjun kunde sedan sammanställas och presenteras som resultat.

4.5. Utvecklingsmetodik

4.4.1

Litteraturstudie

Syftet med litteraturstudien av användningsområdet för en ASIC var att identifiera nuvaran-de användningsområnuvaran-den för en ASIC, verktyg för utbildning inom konstruktion och nuvaran-design av en ASIC och även att för vilka metoder som program som B-ASIC kan underlätta i utbild-ning på avancerad nivå, exempelvis vidare studier angående konstruktion och design av en ASIC vid ett universitet.

Den litteratur som studien syftade att studera var Considerations of Teaching Digital ASIC De-sign [36] av Puhm A., Rössler P. Vidare utvärderades B-ASIC utifrån de kriterium som Puhm et al. lyfter i sin artikel för undervisning av digital ASIC design.

Utöver undervisning sökte även litteraturstudien att undersöka andra områden som en ASIC kan användas i och har använts i, detta då undersökningen sökte att besvara om B-ASIC kan vara ett lämpligt verktyg i den fortsatta utvecklingen av ASIC inom området.

4.4.2

Intervju

För att vidare undersöka B-ASIC och dess relevans för utbildning och användning genom-fördes en intervju med den kund som produkten B-ASIC är skapad för. Intervjun syftade på att undersöka vilka användningsområden som kunden ser för design av en ASIC genom di-gitala verktyg, vilken framtid B-ASIC innefattar i området för digital design av en ASIC samt vilka problem som digital design av en ASIC har.

Syftet med intervjun var att undersöka hur relevant en produkt som B-ASIC är och i vilken mån en sådan produkt kan användas i syftet att utbilda och använda produkten inom rele-vanta områden.

Intervjun genomfördes enbart på kunden för projektet B-ASIC. Intervjun genomfördes på distans genom ett formulär med frågor som kunden svarar på. Frågorna var av kvalitativ grad, det vill säga av undersökande karaktär, då svaren som söktes av kunden var åsikter och tankar kring området för konstruktion, design och användning av en ASIC. Frågorna var därmed konstruerade i syfte att uppmana till utvecklade svar med egna teorier och åsikter om respektive område. Frågor och svar sammanställs i Tabell 5.5.

4.5

Utvecklingsmetodik

Utvecklingsmetodiken genom projektets gång beskrivs nedan.

4.5.1

Dokument

Dokumentskrivningen genomfördes genom att respektive medlem i projektgruppen hade ansvar för att skriva de dokument som var anknutna till dess projektspecifika roll. De med-lemmar som inte hade något dokument anknutet till sin roll, hjälpte till att skriva på de andra medlemmarnas dokument. Fördelningen av dokument återges i Tabell 4.1. När ett dokument var färdigt granskades dokumentet av en annan medlem och eventuella åtgärder genom-fördes av dokumentets ansvarige. De olika dokumenten var levande under utvecklingen av produkten, i den mån att de uppdaterades vid behov.

4.5. Utvecklingsmetodik

Tabell 4.1: Dokument och dess respektive ansvarige. Beskrivningar av rollerna återges i Kapi-tel 4.5.8. Dokument Ansvarig Projektplan Utvecklingsansvarig Kravspecifikation Analysansvarig Kvalitetsplan Kvalitetssamordnare Testplan Testansvarig Testrapport Testansvarig Arkitekturbeskrivning Arkitekt

De olika dokumenten togs fram för att hjälpa projektgruppen att dokumentera arbetspro-cessen, kraven för produkten, projektgruppens kvalitetsprocess, projektgruppens process för tester och verifiering av krav samt produkten B-ASIC:s arkitektur.

4.5.1.1 Projektplan

En projektplan togs fram för att beskriva arbetsprocessen som projektgruppen arbetade efter. Projektets rollbeskrivningar återges i projektplanen tillsammans med milstolpar, tidsbegräns-ningar och risker. Projektplanen var ämnad att hjälpa projektgruppen att planera för vad som ska skulle genomföras under respektive iteration.

4.5.1.2 Kravspecifikation

En kravspecifikation togs fram för att definiera kraven för produkten. Respektive krav be-stämdes av kunden tillsammans med projektets analysansvarige. Kraven sammanställdes i en kravspecifikation där kraven ordnades efter en prioritetsordning. Kravspecifikationen fungerade som en specifikation av vad produkten ska innehålla och hur den skulle se ut, och fungerade därmed som en form av checklista som beskriver det projektet var tänkt att implementera.

4.5.1.3 Kvalitetsplan

En kvalitetsplan togs fram för att säkerställa att kvaliteten på produkten når upp till de för-väntningarna kunden önskar och för att projektgruppen skulle ha en kännedom över önskad kvalitet. Kvalitetsplanen tog bland annat upp vilka metoder projektgruppen använde för att mäta kvalitet. Kvalitetsplanen skulle hjälpa projektgruppen att upprätthålla en god kvalitet med hjälp av olika metriker vid till exempel kodgranskning och dokumentgranskning. Kva-litetsplanen tog dessutom upp hur länkning mellan krav, tester och de issue som skulle hjälpa projektgruppen att få en kännedom om vilka krav som har uppfyllts eller inte.

4.5.1.4 Testplan

En testplan togs fram för att kunna testa produktens funktionalitet. Testplanen definierade hur projektgruppen testar ett issue samt hur systemtesterna genomfördes. Testplanen var äm-nad att hjälpa projektgruppen att skriva tester genom att beskriva hur funktionalitet skulle testas samt tillvägagångssättet för att skapa tester.

4.5. Utvecklingsmetodik

4.5.1.5 Testrapporten

Testrapporten togs fram i syfte att sammanställa resultaten från testningen efter varje itera-tion av utveckling.

4.5.1.6 Arkitekturbeskrivning

En arkitekturbeskrivning togs fram för att beskriva hur systemets arkitektur är uppbyggd. Arkitekturbeskrivningen beskrev olika designbeslut för hur koden skulle struktureras. Vida-re beskVida-rev den även systemets UML-klassdiagram, systemanatomi och arkitektuella ram-verk. Arkitekturbeskrivningen ämnade att hjälpa projektgruppen att implementera funk-tionalitet hos produkten. Klassdiagrammet beskrev vilka klasser som skulle implementeras samt dess attributer och metoder. Systemanatomin beskrev vidare vilka beroenden mellan de abstrakta funktionerna som projektgruppen måste ta hänsyn till vid implementation.

4.5.2

Arbetsmetod

Projektgruppen arbetade i tre iterationer. Under den första iterationen var fokuset att im-plementera de grundläggande funktionaliteterna av biblioteket med underliggande struktur samt att parallellt implementera GUI:ts grundläggande funktionalitet. I iteration två var fo-kuset att koppla samman GUI:t med den underliggande strukturen och fortsätta utveckla funktionalitet till biblioteket. I iteration tre var fokuset att fortsatt utveckla funktioner vid behov samt förbättra existerande funktionalitet.

Den arbetsprocess som projektgruppen arbetade enligt i iteration ett var Scrum-processen. Den metodik som kännetecknar Scrum var att projektgruppen arbetade under Sprints. En Sprint genomfördes under två veckor. Innan Sprintens start genomförde projektgruppen en Sprint-planning. Den innehöll de issue som projektgruppen tänkt implementera under Sprin-ten. Flera issue lades till på ett Scrum-bräde och tilldelades gruppmedlemmar. Under itera-tionen hade projektgruppen möte på måndagar, onsdagar och fredagar där de besvarade på frågorna:

• Vad har jag gjort sedan föregående Scrum-möte som hjälpte projektgruppen att nå vårt Sprint-mål?

• Vad ska jag göra idag och till nästa möte för att projektgruppen ska nå sitt Sprint-mål? • Vet du om några problem som förhindrar att projektgruppen inte når sitt Sprint-mål?

Vid slutet av en Sprint genomförde projektgruppen en review samt en Sprint-retrospective. I Sprint-retrospective diskuterade projektgruppen positiva och negativa erfa-renheter som påträffats under Sprinten. I Sprint-review gick projektgruppen igenom projekt-gruppens product backlog och diskuterade om ett issue skulle fortsätta arbetas på i en senare Sprint eller inte.

4.5. Utvecklingsmetodik

Varje issue under projektet beskrevs som enligt Figur 4.1. Varje issue innehöll följande infor-mation:

• En beskrivning som beskriver vad som ska implementeras och hur det ska fungera. • En lista av länkade krav.

• Potentiella problem med ett issue.

• En lista över andra issue som måste implementeras innan ett specifikt issue.

• En numrerad lista över krav som beskriver exakt hur det som ska implementeras ska fungera.

• En kommentar med övrig info som kan vara användbar för utvecklaren.

• Ifall ett issue togs fram under iteration två eller tre inkluderar den även en lista över användarberättelser (eng. user-story).

Figur 4.1: Exempel av ett issue som använts i projektet.

Under iteration två och tre skedde utvecklingen enligt Kanban-principen och inga Sprints genomfördes. Ett kontinuerligt arbete på ett prioriterat issue användes istället. Under iteration två använde projektgruppen sig av statusmöten för att stämma av utvecklingens status och se över risker för att identifiera problem som kunde uppstå under iteration två och tre. Iteration två introducerade även testdriven utveckling för all utveckling av funktionalitet.

Figur 4.2 visar hur projektgruppens Kanban-bräde som användes under utvecklingen såg ut. En vidare beskrivning av Kanban-brädet finns i avsnitt F.3.1.3.

4.5. Utvecklingsmetodik

Figur 4.2: Projektgruppens Kanban-bräde med de olika issue som behövs göras. De olika kolumnerna i bilden representerar de olika stadierna ett issue kan befinna sig i.

4.5.3

Versionshantering

Koden som projektgruppen skriver versionshanterades med Git. Metodiken med versions-hanteringen var enligt git-arbetsflödet som beskrivs i 3.3.4.

4.5.4

Kodstilguide

Koden som projektgruppen producerade under projektet följer den kodstilsguide som be-stämts innan dess att utveckling påbörjats. Denna guide involverade diverse definitioner för att minska på stilskillnader i kodbasen.

4.5.5

Kodgranskning

Kodgranskningen genomfördes genom att all kod som var ämnad att genomföra en merge till master branch granskades av minst två projektmedlemmar innan merge. Projektmedlemmar som granskade koden följde följande granskningslista:

• Att koden inte ger några felmeddelanden. Detta verifieras för att se till att koden kan köras.

• Att koden inte ger några varningsmeddelanden. Detta verifieras för att se till att koden inte har några kvalitetsbrister som kan automatiskt detekteras.

• Att alla funktioner som behöver det har en funktionskommentar som beskriver even-tuella parametrar, hur den behandlar parametrarna och vad den returnerar. Detta veri-fieras för att se till att koden är väldokumenterad.

• Att koden är läsbar. Detta innebär att det inte ska vara några tvivel om vad som står i koden och att den följer projektgruppens interna regler kring skrivandet av kod. Detta verifieras för att se till att koden ska vara enkel att vidareutveckla.

4.5. Utvecklingsmetodik

• Att varje modul har en kommentar som beskriver dess syfte. Detta verifieras för att se till att koden är väldokumenterad.

• Att varje kodrad inte innehåller fler än 121 tecken. Detta verifieras för att se till att koden är läsbar.

• Att effektiva och passande datastrukturer och algoritmer har använts. Detta verifieras för att se till att koden har god prestanda.

• Att koden är testad och att testerna verifierar rätt funktionalitet. Detta verifieras för att se till att koden ska hålla en så hög standard som möjligt.

Kodgranskningen var ämnad att hjälpa projektgruppen att upprätthålla en hög kodstandard. Att utföra kodgranskningar ökade även förståelsen för kodbasen för de projektmedlemmar som granskade implementationen.

4.5.6

Utvecklingsverktyg

Det utvecklingsverktyg som projektgruppen använde sig av var GitLab. GitLab användes som versionshanteringsverktyg samt i syfte att representera utvecklingsflödet för projektet. Flera issue representerades i ett Scrum/Kanban-bräde i GitLab. Projektmedlemmar kunde sedan välja ett issue och skapa en egen branch. Denna branch användes sedan för all utveckling av den implementationen, detta bidrog att risken för diverse problem med versionshantering minskade.

4.5.7

Testning

Projektgruppen använde sig av testramverket Pytest för att testa implementationen.

För varje issue ansvarade utvecklaren för att skriva tester som grundligt testade teten hos implementationen. Testerna var implementerade på ett sådant sätt att funktionali-teten verifierades och att olika typer av indata gav korrekt resultat.

Testerna implementerades i en specifik testmapp i biblioteket B-ASIC.

Testerna för det grafiska gränssnittet genomfördes manuellt då projektgruppen ansåg att test-ning med testramverk ämnade för grafiska gränssnitt var utanför projektets omfatttest-ning. De manuella testerna beskrev ett scenario som testaren sedan genomförde för att verifiera funk-tionaliteten hos det grafiska gränssnittet.

Testerna publicerades tillsammans med implementationen och genomgick kodgranskning för att verifiera att testerna var korrekt genomförda.

Vidare använde sig projektgruppen av acceptanstester för att verifiera funktionaliteten hos B-ASIC tillsammans med kunden.

4.5. Utvecklingsmetodik

4.5.8

Grupproller

Rollerna och dess ansvarsområden var fördelade över alla projektmedlemmar. De roller som projektgruppen utformades av är följande:

• Teamledare: Angus Lothian Teamledarens ansvar var att leda projektgruppens arbete genom att tillhandahålla information och vägleda vid beslut. Vidare hade teamledaren även ansvar att vägleda möten och andra sammankomster som projektgruppen tar del av under projektets gång.

• Analysansvarig: Adam Jakobsson Analysansvariges ansvar var att tillhandahålla kon-takten med beställaren, och vidare hade den analysansvariga medlemmen ansvar för kravspecifikationen och dess framställning. Frågor till beställaren gick via den här med-lemmen.

• Arkitekt: Ivar Härnqvist Arkitektens ansvar var att bestämma den övergripande systemdesignen med ett arkitekturdokument. Vidare behövde även arkitekten föreslå tekniker som borde användas i projektet.

• Konfigurationsansvarig: Felix Goding Konfigurationsansvariges ansvar var att tillhan-dahålla och underhålla de systemen projektgruppen använde under utvecklingsfasen av projektet. Exempelvis versionshanteringssystemet.

• Kvalitetssamordnare: Rasmus Karlsson Kvalitetssamordnarens ansvar var att se till att kvaliteten hos projektet efterlevs, detta genom att definiera en kvalitetsplan.

• Testledare: Kevin Scott Testledarens ansvar var att bestämma hur produkten skulle tes-tas sådant att kvaliteten hos produkten garanterades. Testledaren garanterade detta ge-nom att organisera bland annat acceptanstester med flera. Testledaren ansvarade även för att testrapporten och testplanen planerades och genomfördes.

• Utvecklingsledare: Jacob Wahlman Utvecklingsledarens ansvar var att bestämma vil-ken utvecklingsmiljö projektet skulle använda sig av och design av miljön. Vidare hade även utvecklingsledaren ansvar att se till att alla medlemmar på ett enkelt vis kunde arbeta med att utveckla produkten, bland annat via processer som Scrum och Kanban-bräden.

• Dokumentansvarig: Arvid Westerlund Dokumentansvariges ansvar var att se till att all dokumentation som producerades under projektets gång var väl genomförd och struk-turerad. Dokumentansvarige tog fram mallar för dokument samt en logotyp för projek-tet. Dokumentansvarige hade även ansvar för att leveranser av dokument skedde.

5

Resultat

Detta kapitel tar upp de resultat projektgruppen kom fram till.

5.1

Systembeskrivning

Detta avsnitt beskriver hur systemet för produkten B-ASIC är uppbyggt på en hög abstrak-tionsnivå.

5.1.1

Översikt över systemet

Produkten B-ASIC är ett system som består av två större komponenter, ett bibliotek med den faktiska implementationen av produkten samt ett grafiskt gränssnitt som använder sig av biblioteket till sin funktionalitet.

5.1.1.1 Bibliotek

Biblioteket är implementerat i Python med garanterat stöd för version 3.6 eller högre. Biblio-teket har dessutom en mindre del implementerat i C++ för funktionalitet som ställer krav på prestanda. Vidare använder sig biblioteket av moduler som NumPy för diverse beräkningar vid simulering av bland annat signalflödesgrafer och pybind11 för koppling mellan Python och C++.

Biblioteket som utvecklats används för att representera operationer, operationsträd, signal-flödesgrafer, prioritetsgrafer och scheman. Dessa strukturer är konstruerade baserat på en existerande struktur; för att skapa ett operationsträd kopplas en eller flera operationer till varandra, för att skapa en signalflödesgraf används ett operationsträd, för att generera en prioritetsgraf krävs en signalflödesgraf och slutligen för ett schema krävs en prioritetsgraf. Genom denna typ av implementation på strukturerna bibehåller vi existerande funktionalitet

5.1. Systembeskrivning

och krav på strukturer genom arv, vilket gör att det är mycket enkelt att vidare implementera en ny struktur som är baserad på samma eller liknande funktionalitet.

Biblioteket är utvecklat på sådant sätt att dokumentation och tydlighet har varit ett fokusom-råde för att möjliggöra enkel vidareutveckling av produkten.

Biblioteket går att använda separat från det grafiska gränssnittet genom att använda en god-tycklig Python-interpretator med stöd för version 3.6 eller högre genom att importera biblio-teket som en modul.

5.1.1.2 Grafiskt gränssnitt

Det grafiska gränssnittet är implementerat i Python med garanterat stöd för version 3.6 eller högre och själva gränssnittet är implementerat med modulen PySide2 som är en Python-baserad variant av det grafiska utvecklingsverktyget Qt. Vidare använder sig gränssnittet av modulen Matplotlib för att återge resultat från exempelvis simuleringar.

Det grafiska gränssnittet som utvecklats används för att implementera en grafisk representa-tion av funkrepresenta-tionaliteten i biblioteket. Det grafiska gränssnittet kan exempelvis användas för att skapa operationer, operationsträd och signalflödesgrafer och även representera dessa gra-fiskt. Ett additionsträd går att se i Figur 5.1. Vidare går det även att simulera dessa grafer för att få en viss utdata givet en indata till exempelvis signalflödesgrafer. Simuleringen kan även återges i form av en graf med hjälp av modulen Matplotlib i Python.

Det grafiska gränssnittet levereras tillsammans med biblioteket och ska gå att använda givet att installationskraven är uppfyllda.

5.2. Jämförelse av B-ASIC med MATLAB-verktygslåda

5.1.2

Vad kunden har för värde av B-ASIC

Det värde kunden har av B-ASIC är att kunden kan använda B-ASIC som program till labo-rationer i kursen TSTE87 som kunden är examinator i. B-ASIC kan dessutom att användas till att bedriva forskning för att skapa och optimera ASIC:s.

5.1.3

Utvärdering av B-ASIC

I utvärderingen av produkten B-ASIC är andelen uppfyllda krav från kravspecifikationen 72 %. Att andelen avklarade krav är låg beror på att 25 % av kraven är schema-krav som var under implementation och inte hann göras klart i tid till projekts slut. Trots den låga andelen krav är kunden nöjd med B-ASIC och ser fram emot att vidareutveckla B-ASIC.

5.2

Jämförelse av B-ASIC med MATLAB-verktygslåda

Verktygslådorna tillhandahåller ett sätt att behandla signalflödesgrafer genom ett kodgräns-snitt. Det som utmärker B-ASIC är att programmet utnyttjar objektorienterad programmering för att representera de olika komponenter för signalflödesgrafen. Eftersom MATLAB-språket representerar variabler som matriser behövde användaren för MATLAB-verktygslådan re-presentera signalflödesgrafen som en matris vilket betydde att användaren hade mindre kontroll över konstruktionsflödet. B-ASIC har dessutom stöd för att dynamiskt lägga till eg-na operationer i sigeg-nalflödesgrafen. Operationer som utgör sigeg-nalflödesgrafen kan samman-kopplas genom Pythons operatoröverlagring.

B-ASIC är 96 % snabbare än MATLAB-verktygslådan för konstruktion av en enkel signalflö-desgraf. B-ASIC har testats mot MATLAB-verktygslådan för tre olika exempel som kunden har bidragit med. Dessa exempel är tagna från laboration 1 och 3 i kursen TSTE87.

5.3

Testning av B-ASIC

Testning av B-ASIC har främst skett genom att skriva automatiserade tester. Varje issue som projektgruppen jobbade med har genomgått enhetstestning av utvecklaren som skrev tillhö-rande kod. Det skrevs totalt 160 tester för B-ASIC som gav en täckning på 88 % av koden för Python-biblioteket.

Manuella tester har förekommit inom gruppen vid testning av GUI:t eftersom det ansågs vara smidigare. Ett acceptanstest har också utförts av kunden för att verifiera att kraven på produkten har uppnåtts. De krav som som inte blev avklarade återfinns i tabellen 6.2.

5.4

Processbeskrivning

Gruppen hade som processmål att effektivisera gruppens interna veckomöten. Detta gjordes genom att estimera hur mycket tid som behövde läggas på varje inplanerad punkt på möte-sagendan innan mötet började. Efter att gruppen blev klar med en punkt på agendan anteck-nades det hur lång tid det faktiskt tog att gå igenom punkten. Resultatet sammanställdes i en tabell som visas i Tabell 5.1 nedan.