Hardware/Software Codesign with SystemC (HM-ES-th1 en HM-ES-pr1).

Deze pagina is bestemd voor studenten van de Haagse Hogeschool - Academie voor Technology, Innovation & Society Delft groep ECNES = minor Embedded Systems.

Inleiding.

Het vak "Hardware/Software Codesign with SystemC" richt zich vooral op de eerste stappen in het ESL ontwerpproces: het modeleren van het systeem op systeemniveau met behulp van de modelleringstaal SystemC, het uitvoeren van een "design space exploration" waarin de verschillende implementatiemogelijkheden worden verkend en met elkaar worden vergeleken en de software en hardware taken worden gedefinieerd. Bij dit vak wordt ook een voorbeeld van een hardware design flow gegeven. In het practicum "Hardware/Software Codesign with SystemC" leer je in de eerste opdracht werken met SystemC en ga je in de tweede opdracht een beeldbewerkings-applicatie die geschreven is in C++ optimaliseren voor het DE2-70 ontwikkelbord. Dit kan gedaan worden door de software te optimaliseren maar ook door bepaalde delen van de software in hardware te implementeren.

Theorie HM-ES-th1.

Beschikbaar matriaal:

Goed inleidend artikel over SystemC.
Handleiding voor het installeren en gebruiken van SystemC.
SystemC refence card. met dank aan de firma Transfer.
De SystemC standaard wordt onderhouden door de Open SystemC Initiative (OSCI).
Ik maak gebruik van het boek: "System C: From the Ground Up". Als je met google zoekt zul je zien dat dit een populair SystemC boek is.
Sheets van mijn collega van de TUDelft Alexander de Graaf .

Inhoud en sheets per les. De sheets kunnen na afloop van een les nog worden bijgewerkt.

Les 1 :
Overzicht van de minor Embedded Systems en een oproep om je C++ kennis (indien nodig) op te halen. Zie Programmeren en Software Engineering 3

Les 2:
In deze les heb ik uitgelegd hoe je in SystemC systemen op verschillende abstractieniveau's kan beschrijven. Een systeembeschrijving bestaat uit een beschrijving van de functionaliteit (het gedrag) en van de vorm (structuur) van het systeem. In SystemC wordt het gedrag beschreven met behulp van de jullie bekende C++ constructies: beslissing, herhaling, functie, class enz. Voor het beschrijven van de structuur van een systeem maakt SystemC gebruik van modules. Een systeem bestaat in een SystemC model altijd, op elk abstractieniveau, uit modules. Een module beschrijft een subsysteem en kan dus zelf ook weer bestaan uit modules. Een module kan via poorten communiceren met de wereld buiten de module. Poorten kunnen met elkaar verbonden worden met behulp van channels. In de onderstaande tabel heb ik voor verschillende abstractieniveaus aangegeven wat de modules en channels op dit abstactieniveau modelleren. Modules worden in SystemC op elk abstractieniveau geïmplementeerd met behulp van de SystemC library class sc_module. Channels worden in SystemC geïmplementeerd met verschillende classes uit de SystemC library afhankelijk van het abstactieniveau.

Abstractieniveau	modules modelleren:	channels modelleren:	SystemC class(es) voor channel(s)
Gate Level (poort niveau). Dit is het laagste abstractieniveau dat in SystemC beschreven kan worden. Het wordt gebruikt voor het modelleren van hardware.	Het systeem bestaat op dit abstractieniveau uit logische poorten (and, or, inverter, enz).	Elektrische verbinding (metaalspoortje of draadje)	`sc_signal<sc_logic>` `sc_signal<bool>` `sc_buffer<sc_logic> sc_buffer<bool>`
Register Transfer Level (RTL). Dit abstactieniveau wordt vaak gebruikt voor het modelleren van hardware maar kan ook gebruikt worden om software op een heel laag abstractieniveau (assembler) te beschrijven.	Het systeem bestaat op dit abstractieniveau uit registers, optellers, vermenigvuldigers, schuifregisters, tellers, multiplexers enz.	Elektrische verbinding of groepjes van deze verbindingen (bussen).	`sc_signal<...>` `sc_buffer<...>`
Behavioural Level. Dit is een abstractieniveau boven RTL waarin de nadruk ligt op het beschrijven van het gedrag (en niet op het beschrijven van de structuur). Dit kan zowel gebruikt worden voor het modelleren van hardware als voor het modelleren van software.	Het systeem bestaat op dit abstractieniveau uit modules boven het RTL niveau. De onderliggende structuur van deze modules wordt niet gemodelleerd.	Op dit niveau kunnen allerlei soorten channels gebruikt worden. De SystemC library bevat een aantal zogenoemde primitive channels maar het is ook mogelijk om zelf andere soorten primitieve channels of om zelf zogenoemde hierarchical channels te implementeren.	`sc_signal<...> sc_buffer<...> sc_mutex sc_semaphore sc_fifo<...>`
Transaction Level Modelling. Op dit abstractieniveau wordt de architectuur van de hardware beschreven.	Het systeem bestaat op dit abstractieniveau uit processing elements, geheugens en I/O devices die via één of meerdere bussen met elkaar zijn verbonden. De informatieoverdracht over deze bussen wordt beschreven met behulp van transacties.	SystemC heeft een speciale uitbreidings library voor het modelleren van dit soort modellen: SystemC TLM-2.0.1	-
Function Level: Asynchronous Message Passing. Op dit abstratieniveau wordt het systeem beschreven als een verzameling processen die met elkaar communiceren via ongelimiteerde FIFO's. Dit kan zowel gebruikt worden voor het modelleren van hardware als voor het modelleren van software.	Het systeem bestaat op dit abstractieniveau uit processen. Deze kunnen later in software worden geïmplementeerd als processen/threads/tasks in een operating systeem of als processoren/processing elements in hardware.	FIFO's. Dezen kunnen later in software geïmplementeerd worden als pipes/message channels/TCP verbindingen enz of in hardware als hardware FIFO's.	`sc_fifo<...>`
Function Level: Algorithm Description. Dit is het hoogste abstractieniveau waarin alleen de functionaliteit van de hard- en/of software wordt beschreven.	Op dit abstractieniveau bestaat het hele systeem uit één module.	Er zijn op dit abstractieniveau geen channels	-

Het gedrag van een module wordt beschreven in SystemC processen. Deze processen moeten bij de simulatiekern van SystemC geregistreerd worden (call backs). Bij deze registratie moeten ook de events worden opgegeven waarop het proces moet reageren. Deze events zijn afkomstig van de channels waarmee de poorten van de modules verbonden zijn.
Sheet 1 t/m 5 van de TUDelft. In de traditionele manier van het ontwikkelen van embedded systems werd eerst de hardware ontworpen en pas daarna de software. De toenemende complexiteit van embedded systems heeft ertoe geleid dat deze manier van werken niet langer mogelijk is. Het ontwikkelen van een RTL beschrijving van de hardware neemt te veel tijd in beslag en het simuleren van een RTL beschrijving van het systeem (om de software te testen voordat de hardware beschikbaar is) is veel te langszaam. Daarom willen we het systeem op een hoger abstrcatie niveau beschrijven. SystemC is een modelleringstaal die dit mogelijk maakt.

Les 3:
Sheet 6 t/m 15 en 18 t/m 20 van de TUDelft. Hierin wordt uitgelegd hoe je een module in SystemC definieert en gebruikt.
Sheet 13 bevat een klein foutje. De macro SC_MODULE(transmitter) expandeert niet in
class transmitter: public sc_module
maar in:
struct transmitter: public sc_module
In C++ is een struct bijna exact gelijk aan een class. Het enige verschil is dat de members in een class per default private en de members in een struct per default public zijn.
Les 4:
Sheet 21 t/m 35. Vervolg van de uitleg over de SystemC module. Bespreken van de SystemC datatypes.
Sheet 25 bevat een klein foutje.
cout.write(tempC | tempE);
moet zijn:
Cout.write(tempC | tempE);
De memberfunctie add mag niet door gebruikers van de class Adder aangeroepen worden maar wordt door de SystemC simulatiekern aangeroepen. Het is dus beter om de memberfunctie add private te declareren zodat het onmogelijk is om deze memberfunctie, per ongeluk, aan te roepen.
Sheet 26 bevat een klein foutje.
tempE = Cin.read() & tempD.read();
moet zijn:
tempE = Cin.read() & tempD;
Sheet 28 geeft een top-level module die geen enkele uitvoer produceert. Om de werking te kunnen controlleren is het nodig om de signalen te tracen. Zie hier.
Dat zelfde geldt voor sheet 32. Zie hier.
Sheet 33 gebruikt het type sc_int maar dat geeft "verrassende" resultaten. Je kunt beter sc_uint gebruiken. De extra u zorgt ervoor dat de getallen unsigned zijn. Zie hier.
De SystemC processen die in deze sheets gebruikt worden om het gedrag van de modules te beschrijven zijn SC_METHOD en SC_THREAD. Deze worden later (hoofdstuk 4 van de sheets) nog uitgebreid behandeld. Voor nu is het voldoende om te weten dat een als SC_MODULE geregistreerde memberfunctie telkens opnieuw, door de SystemC simulatiekern, wordt aangeroepen als een event optreedt dat in de bijbehorende sensitivity list is gespecificeerd. Het uitvoeren van deze memberfunctie kan niet onderbroken worden door de SystemC simulatiekern. Een als SC_THREAD geregistreerde memberfunctie daarintegen wordt slechts één maal, door de SystemC simulatiekern, aangeroepen. In deze memberfunctie is het mogelijk om de uitvoering tijdelijk te onderbreken (suspend) door de simulatiekern aan te roepen via de wait functie. Er bestaan diverse overloaded versies van deze functie waarmee je op verschillende soorten events kunt wachten. De memberfunctie die wait heeft aangeroepen wordt weer vervolgd (resume) als het event, waarop gewacht wordt, is opgetreden. In de voorbeelden wordt dit gebruikt om een bepaalde tijd te wachten.
Sheet 35 behandeld enkele SystemC datatypes. SystemC heeft ook support voor zogenaamde fixed-point datatypes. In de les heb ik het belang en de principes van fixed-point getallen en berekeningen uitgelegd. We gaan dit bij de practicumopdrachten gebruiken. In het SystemC boek worden de fixed-point datatypes behandeld in paragraaf 4.5. Je kunt ook deze presentatie bekijken: http://homes.esat.kuleuven.be/~yvanderp/HJ81/part3/fixed_point.ppt
Les 5:
Sheet 36 t/m 53, 16, 17, 54 t/m 66. Processen en Events.
Het voorbeeld op pagina 49 geeft bij het uitvoeren de volgende foutmelding:
```
Error: (E115) sc_signal<T> cannot have more than one driver:
	signal `RippleCounter2Bits.signal_3' (sc_signal)
	first driver `RippleCounter2Bits.DFF1.port_2' (sc_out)
	second driver `RippleCounter2Bits.port_1' (sc_out)
	In file: c:\systemc-2.2.0\src\sysc\communication\sc_signal.cpp:137
```
Dit klopt ook want de uitgang bit1 van de RippleCounter2Bits en de uitgang Q van de subcomponent dff1 zijn met elkaar verbonden via het signaal Q1_bit1. Twee uitgangen met elkaar verbinden leidt tot kortsluitingen en is om die reden verboden. De uitgang Q van de subcomponent dff1 kan wel rechtstreeks worden verbonden met de uitgang bit1 van de "omhullende" module RippleCounter2Bits.
dff1.Q(bit1); // in plaats van bit1(Q1_bit1); en verwijder Q1_bit1.
Maar nu komt een ander probleem aan het licht. De uitgang Q van subcomponent dff0 moet verbonden worden met uitgang bit0 van de omhullende module en óók met de clk ingang van de subcomponent dff0 (via signaal Q0_clk1). Maar dat werkt niet want de uitgang Q mag maar 1 keer gebonden worden. Dit kun je oplossen door de clk ingang van de subcomponent dff0 rechtstreeks te binden met de uitgang bit0 van de omhullende module. Het signaal Q0_clk1 is dan overbodig.
Nu gaat het bijna goed! Alleen reageert de teller nog niet goed bij de eerste opgaande flank van bit0. Dit komt omdat de Q_bar uitgang van dff1 dan nog gelijk is aan de Q uitgang van dff1. Een situatie die, nadat het process van dff1 éénmaal uitgevoerd is als de enable hoog is, nooit kan optreden omdat Q_bar dan altijd het inverse is van Q. Dit laatste probleem kan opgelost worden door een reset signaal toe te voegen. De gecorrigeerde code kun je hier vinden.
Het voorbeeld op pagina 52 geeft een compilatiefout omdat het haakje sluiten van de buitenste if ontbreekt. Over dit model valt het een en ander op te merken:
- In dit model telt de counter op. Dit is niet consequent met het vorige voorbeeld (RippleCounter2Bits) waarbij de counter aftelt.
- In dit model wordt alleen gereageerd op een reset signaal bij een positieve flank op de clock als de counter enabled is. Het is gebruikelijker om een reset signaal asynchroon te maken (onafhankelijk van de clock) en onafhankelijk van het enable signaal.
- Het gebruik van #define om de waarde van N te definiëren tijdens compile time is niet handig! Probeer maar eens twee counters van het type counterNbit te gebruiken met 2 verschillende waarden van N. Het is beter om counterNbit als template class te definiëren zodat we telkens als we een object van het type counterNbit aanmaken de gewenste waarde van N als template parameter kunnen meegeven. De aangepaste code kun je hier vinden.
Sheet 53 laat zien hoe je een module kunt maken die configureerbaar is tijdens run time via de constructor. Je kunt in dit geval de macro SC_CTOR niet gebruiken maar je moet gebruik maken van de macro SC_HAS_PROCESS. Bedenk dat je een module configureerbaar kunt maken tijdens compile time door er een template class van te maken. Zie sheet 16 en 17 voor uitleg over de SC_HAS_PROCESS macro.
Sheet 53 bevat een klein foutje:
sc_in<bool> reset. enable;
De . moet natuurlijk een , zijn.
sc_in<bool> reset, enable;
Sheet 53 bevat ook een logische fout. De waarde van de member variabele count wordt nooit naar de output poort geschreven! Voor de wait() moet de volgende regel worden toegevoegd:
out.write(count);
Ook is het logischer om het unsigned type sc_uint<8> in plaats van het signed type sc_int<8>. De membervariabele dir kan beter in de initializatielijst geïnitialiseerd worden. Tot slot vind ik de naam dir niet zo duidelijk, count_down is beter.
Sheet 55 bevat een klein foutje. De laatste notify sheduled een event na 20 femptoseconden (en niet na 1 zoals in het commentaar staat). Deze zelfde fout staat ook op pagina 78 van het SystemC boek.
Sheet 60 maakt gebruik van sensitive_pos. Dit is deprecated in de SystemC standaard. De standaard zegt: "Classes sc_sensitive_pos and sc_sensitive_neg and the corresponding data members sensitive_pos and sensitive_neg of class sc_module are deprecated, use the event finders pos and neg instead". Dus:
sensitive_pos << clock;
kan beter vervangen worden door:
sensitive << clock.pos();
Op sheet 64 staat een fout.
e_filled.notify(SC_ZERO_TIME);
moet zijn:
e_tank_filled.notify(SC_ZERO_TIME);
De complete code van dit voorbeeld kun je hier vinden.
Les 6:
Sheet 67 t/m 81, 84, 85, 92 t/m 95, 96 t/m 119. Channels en Ports.
Sheet 96 t/m 117 behandelen dezelfde onderwerpen (channels en ports) als sheet 71 t/m 91.
Les 7 en Les 8 :
In deze lessen wordt aan de hand van een voorbeeld besproken hoe een functional level SystemC model verfijnt kan worden in een RTL SystemC model.
Zie ook: http://www.cs.ucr.edu/~vahid/courses/122a_f99/ch4.pdf.
Meer informatie over Euclid's Algorithm: http://en.wikipedia.org/wiki/Euclidean_algorithm.
Een snellere methode kun je hier vinden: http://en.wikipedia.org/wiki/Binary_GCD_algorithm. Oefening: Herhaal les 7 en 8 voor dit algoritme.
Les 9 :
In deze les wordt de Preformance Counter besproken die je ook in het practicum moet gebruiken voor het timen van je programma. Vervolgens zullen we de C2H tool van Altera gebruiken om een software functie (gcd) automatisch om te zetten naar hardware.
Documentatie van de preformance counter: http://www.altera.com/literature/hb/nios2/qts_qii55001.pdf.
C2H User Guide: http://www.altera.com/literature/ug/ug_nios2_c2h_compiler.pdf.
White paper: Automated Generation of Hardware Accelerators With Direct Memory Access From ANSI/ISO Standard C Functions: http://www.altera.com/literature/wp/wp-aghrdwr.pdf.
Les 10 :
In deze les zullen we kort kijken naar een research tool genaamd SPACE waarmee we SystemC code kunnen draaien op een Embedded Systeem met behulp van een Real-Time Operating Systeem (bijvoorbeeld MicroC/OS-II). Deze les is gebaseerd op het artikel:
http://cadal.cse.nsysu.edu.tw/seminar/seminar_file/2006/060911_tcyeh_paper.pdf
...

SystemC voorbeelden:
Nog doen...

Practicum HM-ES-pr1.

Opdrachten:

De inleidende practicum voor de minor Embedded Systems kun je hier vinden: pract1.htm.
Het practicum Hardware/Software Codesign with SystemC bestaat uit 2 practicumopdrachten:
- Opdracht 1: Introductie in SystemC en het modelleren en verfijnen van een eenvoudig beeldbewerking algoritme.
- Opdracht 2: Het implementeren van de bij opdracht 1 gemodeleerde beeldbewerking algoritme op het DE2-70 ontwikkelbord.

Resultaten practicum: res_HM-ES-pr1.pdf.

Resultaten theorie: res_HM-ES-sc1.pdf.
Resultaten theorie herkansing: res_HM-ES-sc1_herk.pdf.