---
# System prepended metadata

title: TP SystemC

---

# 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. 


![](https://i.imgur.com/4xHQtGi.png)
*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 

![](https://i.imgur.com/fYhekOg.png)

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
- ...

![](https://i.imgur.com/iktmyIK.png)


### 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. 

![](https://i.imgur.com/TNSp5Yh.png)
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. 











