La séparation entre la définition de l’interface et son comportement se fait en utilisant le concept d’interfaces de la programmation orientée objet.

• On définit dans l’interface la liste des méthodes (fonctions) que doit implémenter le canal
• On implémente dans le canal les méthodes de l’interface.

En C++, le concept d’interface utilise ce qu’on appelle des classes abstraites (virtuelles pures).

Exemple

Comment définir des interfaces en C++ ?

#include <iostream>
using namespace std;

class MyInterface {
public:
   // "=0" veut dire implémentation obligatoire
   virtual void hello()   = 0;
};

class SimpleImpl : virtual public MyInterface {
public:
   virtual void hello() override
   {
      cout << "Hi" << endl;
   }
};

class CplxImpl : virtual public MyInterface {
public:
   virtual void hello() override
   {
      cout <<  "Hi " << message << endl;
   }
   CplxImpl(string s): message(s) {}

private:
   const string message;
};

int main()
{
   // MyInterface   x; // ceci est une erreur car la classe est abstraite

   MyInterface * o[2];

   o[0] =  new SimpleImpl();
   o[1] =  new CplxImpl("folks");

   for (int i=0; i<2; i++)
      o[i]->hello();

   return 0;
}

Pour garder l’isolation entre les éléments d’une hiérarchie, les ports doivent permettre de rendre accessible les méthodes des interfaces dans un module.

Pour avoir un minimum d’interopérabilité, SystemC définit plusieurs types :

• sc_interface.
• sc_prim_channel
• sc_port

Ces deux interfaces sont définies comme des classes template, où le template T est le type des données transporté.

• sc_signal_in_if<T> : définit la méthode read() ainsi que les méthodes renvoyant les évènements.
• sc_signal_inout_if<T> : la complète en ajoutant entre autres la méthode write()

Des spécialisations de ces interfaces existent pour les types bool et sc_logic. Elles ajoutent ce qu’il faut pour les évènements sur front.

Ces ports spécialisés ajoutent des surcharges d’opérateurs pour permettre simplement d’écrire et de lire dans le signal. Aussi, on ne peut y connecter qu’un seul signal.

• T est le type transporté
• WRITER_POLICY détermine le comportement du sc_signal s’il est modifié par plusieurs processus. Par défaut, c’est interdit.

Travail à faire :

Écrire un exemple de code mettant en évidence la différence de comportement entre sc_signal et sc_buffer

L’interface sc_fifo_in_if<T> fournit :

• bool nb_read(&T) : lecture non bloquante qui renvoie true si elle réussit.
• void read(&T) et T read() : lecture bloquante (appelle wait() si la fifo est vide).
• int num_available() : qui renvoie le nombre d’éléments disponibles dans la fifo.
• sc_event& data_written_event() : renvoie une référence vers évènement notifié en cas d’écriture.

L’interface sc_fifo_out_if<T> fournit :

• bool nb_write(&T) : écriture non bloquante qui renvoie true si elle réussit.
• void write(&T) : écriture bloquante (appelle wait() si la fifo est pleine)
• int num_free() : renvoie le nombre d’éléments pouvant être écrits dans la fifo.
• sc_event & data_read_event() : une référence vers un évènement notifié en cas de lecture.

Attention comme les méthodes bloquantes de lecture et d’écriture font appel à wait() pour suspendre le processus qui les appelle, il faut donc prendre des précautions quand on les utilise dans des SC_METHOD.

Le constructeur d’une sc_fifo<T> prend en argument la taille de la fifo. La taille par défaut est de 16. De plus l’opérateur d’affectation a été surchargé pour appeler les méthodes bloquantes de lecture et d’écriture.

Exemple :

   // une fifo de 16 éléments
   sc_fifo<int> A;
   // une fifo de 32 éléments
   sc_fifo<int> B(32);

   // deux écritures bloquantes
   A.write(1);
   B = 1;

   // deux lectures bloquantes
   int x;
   x = A;
   x = B.read();

Exemple plus complet :

#include <systemc.h>
SC_MODULE(A) {
   sc_fifo_out<int> out;
   void loop() {
      int i = 0;
      for(;;){
         // write est obligatoire
         out.write(i);
         i++;
         wait(33, SC_NS);
      }
   }
   SC_CTOR(A) { SC_THREAD(loop); }
};
SC_MODULE(B) {
   sc_fifo_in<int> in;
   void loop() {
      wait(300, SC_NS);
      for(;;){
         // in.read() appelle in->read()
         cout << "Lecture 1 : " << in->read() << "@ " << sc_time_stamp() << endl;
         cout << "Lecture 2 : " << in.read()  << "@ " << sc_time_stamp() << endl;
         wait(55, SC_NS);
      }
   }
   SC_CTOR(B) { SC_THREAD(loop); }
};

int sc_main(int, char **) {
   // une fifo de 10 entiers
   sc_fifo<int> fifo(10);

   A a("modA");
   a.out(fifo);

   B b("modB");
   b.in(fifo);

   sc_start(300,SC_NS);
   cout 
      << "contenu de la fifo @" << sc_time_stamp() << endl
      << fifo << endl;

   sc_start(1,SC_US);
   cout 
      << "contenu de la fifo @" << sc_time_stamp() << endl
      << fifo << endl;

   return 0;
}

Travail à faire :

Écrire le code de deux modules s’échangeant des Pixels à travers une fifo. Les modules devront fonctionner à des cadences différentes tout en étant synchrones à une horloge clk générée au niveau supérieur. Par exemple :

• Producteur : envoie, une à une, 100 données en attendant un cycle entre chaque envoi puis s’arrête pendant un nombre aléatoire de cycles compris entre 0 et 32.
• Consommateur : lit une donnée puis attend 2 cycles si la somme des composantes du pixel lu est paire ou 3 cycles elle est impaire.
• Observez le comportement pour différentes profondeurs de fifo.

Faites deux implémentations du producteur, l’une utilisant des SC_THREAD ou SC_CTHREAD et l’autre utilisant des SC_METHOD.

Le sc_mutex fournit les méthodes :

• int lock() : pour verrouiller le mutex. S’il est déjà verrouillé, on est mis en attente (wait() est appelée). Cette méthode renvoie toujours 0.
• int trylock() : pour essayer de verrouiller le mutex. Cette méthode renvoie 0 en cas de succès, -1 sinon.
• int unlock() : pour libérer le mutex. Cette méthode renvoie 0 en cas de succès, -1 sinon (i.e. le mutex n’est pas verrouillé ou il appartient à un autre thread).

Le sc_semaphore prend en argument de constructeur le nombre de sémaphores qu’on peut prendre. Si ce nombre est égal à un, son comportement est équivalent à un sc_mutex.

Le sc_semaphore fournit les méthodes :

• int wait() : si le nombre de sémaphores restants est supérieur à 0, le décrémenter et retourner, sinon, le processus est suspendu (wait()) Cette méthode renvoie toujours 0.
• int trywait() : si le nombre de sémaphores restants est supérieur à 0, le décrémenter et retourner 0, sinon, retourne -1.
• int post() : incrémente le nombre de sémaphores. Cette méthode renvoie toujours 0.
• int get_value() : renvoie le nombre de sémaphores disponibles.

Attention

Il n’y a pas de ports dédiés à ces deux types de canaux. Si vous voulez utiliser ces canaux entre deux modules, il faudra passer par un sc_port générique exposant l’interface de ces deux type de canaux (respectivement sc_mutex_if et sc_semaphore_if).

Travail à faire :

Écrire le code d’un module dans lequel deux SC_THREAD concurrents s’exécutent à tour de rôle en utilisant un sc_mutex.

Un sc_mutex suffirait-il si on avait trois processus ?

Travail à faire :

En utilisant la classe sc_channel écrire le code d’un générateur d’horloge. Ce canal contiendra un sc_signal qui pourra être connecté à l’entrée d’un module de test à travers un sc_export.