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

Deze pagina is bestemd voor studenten van de Haagse Hogeschool - Faculteit Technologie, Innovatie & Samenleving groep E-EMSYS = minor Embedded Systems.

Let op! Deze pagina bevat mogelijk verouderde informatie, kijk op Blackboard voor de meest recente informatie!

Inhoud

Studiemateriaal	Sheets	Practicumopdrachten: 0 1 2

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 materiaal:

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 Accellera. De standaard IEEE 1666-2011 kun je gratis downloaden van de IEEE website: http://standards.ieee.org/getieee/1666/download/1666-2011.pdf. Een lokale kopie kun je hier vinden: 1666-2011.pdf .
Er is ook een uitbreiding van SystemC zodat ook analoge systeemonderdelen in een SystemC model kunnen worden. Deze uitbreiding heet SystemC-AMS, zie: http://www.systemc-ams.org/. De voorzitter van de SystemC-AMS Working Group is een Nederlander (Martin Barnasconi). Deze uitbreidingen zijn nog niet opgenomen in de nieuwe SystemC standaard IEEE 1666-2011 en worden in dit vak niet besproken.
Ik maak gebruik van het boek: "System C: From the Ground Up".
Webinar: The Keys to SystemC & TLM-2.0: How to be Successful Dit webinar geeft je in 1 uur een goede inleiding in SystemC en TLM.
Webinar Overview: SystemC has become well-established as the language of choice for system modeling and virtual platform creation and integration, and is now being applied successfully for high level synthesis. SystemC models also frequently appear as reference models in the hardware verification flow. This session is aimed at hands-on hardware or software engineers who might know Verilog or C but have no previous experience of SystemC. It will explain what you need to know to be successful with SystemC by exploring some fundamental questions including: What is SystemC and how is it used? What does modern SystemC code look like? What use cases best fit SystemC? What is TLM? Where can I learn more?
Sheets van mijn collega van de TUDelft Alexander de Graaf . Versie 9 mei 2014.

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 Object Georiënteerd Programmeren in C++.

Les 2:
In deze les leg ik uit hoe je in SystemC systemen op verschillende abstractieniveau's kunt beschrijven. Een systeembeschrijving bestaat uit een beschrijving van de functionaliteit (het gedrag) en van de structuur (hierarchy) 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 hierarchy 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.	In de SystemC standaard is een speciaal deel opgenomen voor het modelleren van dit soort modellen: SystemC TLM2	`simple_initiator_socket<...> simple_target_socket<...> ...`
Functional 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<...>`
Functional 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 10 van de TUDelft. In de traditionele manier van het ontwikkelen van embedded systems werd eerst de hardware ontworpen.
Sheet 11 t/m 21 van de TUDelft slaan we over omdat ik ervan uitga dat jullie C++ kennis voldoende is. Zie anders Object Georiënteerd Programmeren in C++.
Sheet 11 t/m 21 bevatten bovendien enkele foutjes:
Sheet 12: #include <assert.h> moet zijn #include <cassert>.
Sheet 14: De constructor en destructor kunnen netter worden gecodeerd:

Image(): width(0), height(0), data(nullptr) { /* use initialisation list */
}
~Image() {
    delete[] data; /* it is safe to call delete[] on a null pointer */
}

Sheet 16: De constructor kan netter worden gecodeerd:

Image(int w, int h): width(w), height(h), data(new Vec3f[w*h]) {
}

Sheet 16: Image myImage = Image(10, 10); moet zijn Image myImage(10, 10);.
Sheet 17: Het prototype van de copy constructor is niet Image(Image *img) maar Image(const Image& img). Alle pijlen (->) moeten punten (.) zijn. Ook kan het netter door de initialisatielijst van de constructor te gebruiken:

Image(const Image& img): width(img.width), height(img.height), data(new Vec3f[img.width * img.height]) {
    for (int i = 0; i < width * height; ++i)
        data[i] = new data[i];
}

Sheet 17: "usually" moet zijn "sometimes". Zie paragraaf 5.7 van het dictaat: Objectgeoriënteerd Programmeren in C++: Dictaat_OGPiCpp.pdf.
Sheet 20: De default constructor van de basisklasse wordt automatisch aangeroepen in de constructor van een afgeleide klasse. De constructor van Sphere kan dus netter als volgt worden gecodeerd:

Sphere::Sphere() : radius(1.0) {
}

Les 3 :
In het verleden (<2013) gebruikte ik de sheets van de TUDelft om uit te leggen hoe je SystemC kan gebuiken om hardware op RTL- of poortniveau te beschrijven. Ik denk dat het goed is om dat aan de hand van een aantal voorbeelden te doen. In de laatste versies (>=2013) van de sheets van de TUDelft is echter voor een heel abstracte aanpak gekozen. Zie Sheet 22 t/m 41 van de TUDelft. In de (abstracte) voorbeeldcode is er ook voor gekozen om veel "onderdelen" dynamsich aan te maken wat in mijn ogen nodeloos complex is. Ook het "simple example" op sheet 32 t/m 41 is volgens mij verre van simpel. Om deze reden heb ik besloten om een eigen presentatie te maken gebaseerd op de oude presentatie van de TUDelft.
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 van de TUDelft) 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 (resumed) als het event, waarop gewacht wordt, is opgetreden. In de voorbeelden wordt dit gebruikt om een bepaalde tijd te wachten.

SystemC voorbeelden:
- Model van een 1-bit (full)adder inclusief testbench. versie 1.
- Model van een 1-bit (full)adder inclusief testbench. versie 2: zonder (overbodige) lokale variabelen in de SC_METHOD(add).
- Model van een 1-bit (full)adder inclusief testbench. versie 3: met gebruik van impliciete type conversies en operator overloading in SC_METHOD(add). Ik raad het gebruik van deze stijl af omdat het naar mijn idee het verschil tussen variabelen en in- of uitgangen maskeerd.
Les 4 :
Vervolg SystemC modules en hierarchie en bespreken van de SystemC datatypes.
Sheet 66 t/m 70 van de TUDelft behandelen de belangrijkste SystemC datatypes. Meer informatie over het sc_logic datatype kun je hier vinden: http://www.asic-world.com/systemc/data_types2.html. Daar kun je ook vinden hoe de logische operatoren (and, or en not) voor dit datatype gedefinieerd zijn.
In de les heb ik het belang en de principes van fixed-point getallen en berekeningen uitgelegd. We gaan dit bij de practicumopdrachten gebruiken. Algemene informatie over fixed point getallen kun je hier vainden: http://en.wikipedia.org/wiki/Fixed-point_arithmetic . In het SystemC boek worden de fixed-point datatypes behandeld in paragraaf 4.5. Je kunt ook deze presentatie van Yves Vanderperren bekijken: fixed_point.pdf . In de SystemC standaard worden de fixed-point datatypes behandeld in paragraaf 7.10.
SystemC voorbeelden:
- Structural model van een 2-bit (full)adder.
- Behavioral model van een 2-bit (full)adder.
Les 5:
Sheet 42 t/m 65. Processen, Events en Tijd.
Sheet 50 gebruikt een deprecated (lees: oude) manier om de sensitivity van een proces op te geven. De SystemC standaard zegt: "operator() of class sc_sensitive is deprecated. Use operator<< instead". De regel sensitive(fillup_request); moet dus vervangen worden door sensitive << fillup_request;
Sheet 52 bevat twee kleine foutjes: "Calculated" moet zijn "Calculated " en mytime moet zijn my_time. Het doel van de voorbeeldcode is mij niet duidelijk.
Sheet 57 staat achter het prototype van wait "triggers an event". Dat moet natuurlijk zijn: "waits for an event". Het voorbeeld is erg vreemd. Er staat // assume previous slide maar op de sheet ervoor komt helemaal geen my_event voor.
Les 6:
Sheet 71 t/m 91. Interfaces, Channels en Ports. Dit wordt in een zodanig tempo behandeld dat het wel nodig zal zijn om een en ander zelf thuis in het boek nog eens op te zoeken en te bestuderen!
SystemC voorbeelden:
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://ens.ewi.tudelft.nl/Education/courses/et4054/ch4.pdf.
Meer informatie over Euclid's Algorithm: http://en.wikipedia.org/wiki/Euclidean_algorithm.
Normaal maak ik geen gebruik van het whiteboard. In les 8 gebruik ik maar liefst 2 borden! Zie: bord_rechts.jpg en bord_links.jpg.
Een snellere methode kun je hier vinden: http://en.wikipedia.org/wiki/Binary_GCD_algorithm. Oefening: Herhaal les 7 en 8 voor dit algoritme.
SystemC voorbeelden:
Les 9 :
In deze les wordt de SystemC synthesizer Fossy kort besproken. Een synthetiseerbaar cycle accurate model van een special function processor die de gcd van 2 getallen kan uitrekenen kun je hier vinden: input.cpp. Voor de liefhebbers: De door Fossy geproduceerde VHDL code die dit model implementeerd is: gcd.vhdl deze code maakt gebruikt van deze library: osss_pkg.vhdl.
In deze les wordt ook de Preformance Counter besproken die je 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 wordt de standaard SystemC channel sc_fifo besproken. Een sc_fifo kan gebruikt worden om modules met elkaar te laten communiceren. Dit kan dan later als een hardware fifo of als een software fifo worden geïmplementeerd. We kunnen een sc_fifo ook gebruiken om threads met elkaar te laten communiceren. Dit kan dan later als software geïmplementeerd worden (b.v. als een message queue in een POSIX compatible Real-Time OS of als een Queue in FreeRTOS). Tot slot wordt in deze les uitgelegd hoe je zelf een channel kunt definiëren en gebruiken. Om zelf een channel te definieren moet je:
- een read interface en een write interface definiëren. Een zelfgedefinieerde interface moet virtual overerven van de base class sc_interface. Zie de SystemC standaard pagina 117 en 118:
  An interface proper is an abstract class derived from class sc_interface but not derived from class sc_object. An interface proper contains a set of pure virtual functions that shall be defined in one or more channels derived from that interface proper. An interface proper shall obey the following rules:
  a) It shall be publicly derived directly or indirectly from class sc_interface
  b) If directly derived from class sc_interface, it shall use the virtual specifier
  In de les zal ik kort uitleggen wat het verschil is tussen "gewoon" overerven en virtual overerven. Meer info kun je hier vinden: http://en.wikipedia.org/wiki/Virtual_inheritance . Nog meer details vind je hier: http://www.parashift.com/c++-faq-lite/multiple-inheritance.html.
- een module afleiden van sc_channel. Deze module moet de interfaces implementeren. De typenaam sc_channel is slechts een andere naam voor het type sc_module. Het type sc_channel is in de SystemC library als volgt gedefinieerd: typedef sc_module sc_channel;
De zelfgedefinieerde channel kan via zijn read interface en zijn write interface worden gebruikt.
- In een module kun je via een port van het type sc_port<read interface> de functies die gedefinieerd zijn in de read interface en geïmplementeerd zijn in de channel aanroepen. Bijvoorbeeld out->read(c). Let op: out.read(c) is niet correct (de class sc_port heeft helemaal geen read functie) en geeft een compilatiefout. De operator-> is overloaded in de class sc_port<read interface> en geeft een pointer terug naar de read interface van de channel waar de port mee verbonden is.
- In een module kun je via een port van het type sc_port<write interface> de functies die gedefinieerd zijn in de write interface en geïmplementeerd zijn in de channel aanroepen. Bijvoorbeeld out->write(c). Let op: out.write(c) is niet correct (de class sc_port heeft helemaal geen write functie) en geeft een compilatiefout. De operator-> is overloaded in de class sc_port<write interface> en geeft een pointer terug naar de write interface van de channel waar de port mee verbonden is.
SystemC voorbeelden:
- Voorbeeld van een untimed model waarin een producer en een consumer module met elkaar communiceren (en synchroniseren) via een sc_fifo. In dit voorbeeld is geen timing gebruikt. De fifo wordt dus steeds helemaal volgeschreven en daarna helemaal leeggelezen. Zie fifo_output.png.
- Voorbeeld van een timed model waarin een producer en een consumer module met elkaar communiceren (en synchroniseren) via een sc_fifo. In dit voorbeeld is wel timing gebruikt. De producer is net een beetje sneller dan de consumer. De fifo loopt dus langzaam vol. Zie fifo_tim_output.png.
- Voorbeeld van een timed model waarin een producer en een consumer SC_THREAD (binnen dezelfde module) met elkaar communiceren (en synchroniseren) via een sc_fifo. In dit voorbeeld is timing gebruikt. De producer is net een beetje sneller dan de consumer. De fifo loopt dus langzaam vol. Zie fifo_tim_proc_output.png.
- Voorbeeld van een timed model waarin een producer en een consumer module met elkaar communiceren (en synchroniseren) via een zelfgemaakte class fifo. In dit voorbeeld is timing gebruikt. De producer is net een beetje sneller dan de consumer. De fifo loopt dus langzaam vol. Zie my_fifo_tim_output.png.
- Uitwerking huiswerk. Probeer eerst zelf het huiswerk te maken! Implementatie van een channel genaamd pq die zich net zo gedraagt als een sc_fifo maar waarbij bij een read het grootste element (dat zich in de queue bevindt) wordt teruggegeven. Voorbeeld van een timed model waarin een producer en een consumer module met elkaar communiceren (en synchroniseren) via de zelfgemaakte class pq. De producer is net een beetje sneller dan de consumer. De fifo loopt dus langzaam vol. Zie pq_output.png.

Les 11 en 12 :
In deze lessen wordt een introductie gegeven van Transaction Level Modeling (TLM) 2.0. Dit is een uitbreiding van SystemC die bedoeld is om modellen sneller te maken en interoperabiliteit te verkrijgen/verhogen. De link hierboven verwijst naar een door mij aangepaste (uitgeklede) presentatie. De originele presentatie kun je hier vinden.
Alle details kun je vinden in hoofdstuk 9 t/m 16 van de SystemC standaard (IEEE 1666-2011): 1666-2011.pdf .
Deze pagina is zeker het bekijken waard: http://www.doulos.com/knowhow/systemc/tlm2/. De op deze pagina gegeven tutorial (waarvoor je jezelf moet registreren) kun je ook hier downloaden (zonder jezelf te registreren):
Les 13 en 14: Gastcollege. Dit jaar is er geen gastcollege over SystemC maar wel een gastcollege van Verum over model driven software development en Formele Verificatie. Bij de toets HM-ES-th1 kunnnen vragen over dit gastcollege worden gesteld.

Extra SystemC voorbeelden:
- Behavioral model van een N-bit counter. Timing diagram: N-bit-counter_output.png.
- Structural model van een N-bit counter. De structuur van een synchrone N bit counter opgebouwd met D flip-flops is erg regelmatig. Zie: http://teahlab.com/4-bit_counter_modulo-16_D_flipflop/. Het timing diagram is gelijk aan het bovenstaande timing diagram.
- Voorbeeld van het gebruik van sc_mutex. De uitvoer zonder en met mutex: systemc/progs/mutex_zonder_output.png en systemc/progs/mutex_met_output.png.
Toets van 18 januari 2011: toets.pdf .
Toets van 5 februari 2013: toets.pdf .
Geen uitwerkingen.

Practicum HM-ES-pr1

Opdrachten:

De inleidende practicum voor de minor Embedded Systems kun je hier vinden: pract0.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.