# TP SystemC

## Exercice 1

Le but du code est de faire la somme des carrés de deux nombres donnés.

Projet composé de :
- un module "adder"
- un module " multiplier"
- un module "stim" => sensible sur front montant de la clock : deux boucles for pour incrémenter a et b
- un module "mon" => monitor, sensiblie sur front descendant de la clock : pour print les résultats
- un module "dut" : permet de faire la somme de deux carrées
- un fichier "testbench"

### Modification du code pour faire le carré d'une somme

- fichier "sosum.h"

## Exercice 2

L'objectif est de réaliser un compteur 8bits avec un reset synchrone.

En entrée on aura :
- un signal de reset (sc_bool)
- un signal de clock (sc_clk)

En sortie:
- la valeur du compteur

### Création d'un fichier trace et visualisation avec gtkwave

Dans notre test_bench, on met en place une clock de période 10 ns. Un reset est appliqué au bout de la 260 itération du compteur.

*Figure 1: chronogramme du compteur*

On peut voir le bon fonctionnement du compteur qui change de valeur sur front montant de l'horloge. Celui-ci compte bien sur 8bits (de 0 à 255). Lorsque le reset est appliqué, le compteur repasse bien à 0.

## Exercice 3

Le but de l'exercice est de créer addeur qui retourne la somme de 4 valeurs de 8bits. Les valeurs d'entrées sont présentes dans un fifo.

### Fifo object issues
Afin de relier un fifo à un module en tant qu'entrée de ce module, il faut utiliser l'objet `sc_fifo_in<>` dans le module correspondant.
Afin de relier une fifo en tant que sortie d'un module, il faut utiliser l'objet `sc_fifo_out` dans le module écrivant dans la fifo.

La déclaration de l'objet `sc_fifo` sera réalisé dans le main et sera connecté simplement aux entrées sorties des différents blocs.

### Data length
Somme de 4 valeurs uint8.
4*255 = 1020. Valeure maximale. Il faut donc 10bits pour coder la sortie de la somme.
### testbench

Ici nous faisons le choix de considérer le compteur réalisé à l'exo 2 en tant que générateur de données 8bits.

### Results


Les résultats sont cohérents. La somme est réalisé toutes les 4 valeurs générés :

- Somme de 1,2,3,4 =10
- - Somme de 5,6,7,8 =26
- ...


### Latency
Ajout d'une latency de 20ns. Pour cela, on ajoute un wait de 20ns lors de l'attribution du buffer `buff` de somme dans la sortie `out`. Ou alors, ajouter un wait de 5ns à chaque fois qu'on somme la nouvelle valeur présente dans la fifo dans le buffer.

La latence influe uniquement sur le premier calcul de somme. En effet, lors du premier, on attend les 4 valeurs qui mettent 10ns à se présenter dans la fifo. Ensuite, 20ns supplémentaire sont attendues avant d'obtenir le résultat de la somme. Cependant, pendant ces 20ns, le générateur a ajouté 2 valeurs dans la fifo. Lors de la reprise de lecture de celle-ci par le calculateur de somme, celui-ci n'a pas besoin d'attendre 20 ns pour deux valeurs mais uniquement 20ns pour obtenir les 4 valeurs. Ensuite de nouveau 20ns sont attendues avant d'obtenir le résultat de la somme.

## Exercice 4 : Writting processor

### Goals

Simuler un processeur écrivant de la donnée en mémoire.
La mémoire est slave et le processeur est master.

### Memory

La mémoire est une classe qui hérite de la classe mem_if qui elle même hérite de sc_interface. La classe mem_if est un classe abstraite pure, on doit redéfinire toutes les fonctions dans la classe Memory.

### CPU

Le CPU est connecté à un objet de type mem_if. L'objectif est que le CPU s'adapte à n'importe quelle type de mémoire grâce à cette classe.
Dans sa fonction act(), le CPU va dans un premier temps instancier une addresse aléatoire comprise dans l'intervalle de mémoire disponible ([0;MEMORY_SIZE]) qui va nous servir pour effectuer des lectures/écriture.

# Exercice 5

L'objectif de cet exercice est de modéliser le management d'une station service. Elle est composé de deux clients et d'un vendeur. Quand le reservoir d'un client est vide, celui-ci demande à être rempli par le vendeur.
Le vendeur ne peut remplir le réservoir d'un client seulement si il n'est pas déjà occupé à remplir le réservoir d'un autre client.

Chaque client est représenté par un process :
`customer1_thread` et `customer2_thread`

Le vendeur est représenté par une méthode :
`attendant_method`

Afin de simuler correctement le fonctionnement de la station service, des events et des flags supplémentaires ont été ajoutés :
1. ` e_filling` : un event qui indique au client que le vendeur est en train de remplir le réservoir d'un client. Il a été ajouté car il n'est pas possible de réaliser de wait() dans une méthode. L'attente du remplissage d'un reservoir est donc réalisée dans les threads de chaque client.
2. `isFilling1,isFilling2` : flags indiquant l'état courant des clients, à savoir si leur réservoir sont en train d'être rempli ou non. Cela permet au vendeur de savoir quel client lui fait une requête et aussi de prioriser les clients.