Préambule

UNE RESSOURCE PLUS RÉCENTE EST DISPPONNIBLE ICI

Remarque préliminaire : ce cours de SystemC n'est pas un manuel complet de SystemC. C'est plutôt une introduction aux bases du langage. Nous y avons inclus ce qui nous semble important, en laissant de côté les aspects les plus complexes et pointus. Il part aussi du principe que vous avez suivi le cours sur les HDL en général, ainsi qu'au choix au moins un des deux cours sur Verilog ou VHDL.
 

License 

License d'utilisation de ce document : Licence de droits d'usage

Plan du cours

Ce cours est séparé en chapitres. Il est conseillé de les suivre dans l'ordre, même si ce n'est pas une nécessité absolue.

 

En pratique

Chaque chapitre est séparé en sous-parties. Vous pouvez naviguer dans les chapitres et sous-parties à l'aide du menu en haut de page.
Les icônes en bas de page vous permettent de passer au chapitre précédent ou suivant, ou de revenir à l'accueil du site sur les HDL.

Un enseignant se tient à votre disposition pendant les heures de cours, mais vous pouvez toujours nous contacter en mail.

Dernier détail, merci d'utiliser un navigateur acceptant les CCS et le javascript (firefox, mozilla, ...)

Bon courage ! 

Back to top

A propos de SystemC

SystemC est, comme Verilog et VHDL, un langage de description de matériel. C'est le fruit de contributions de plusieurs sociétés. En 1989, Synopsys met son outil commercial Scenic dans le domaine libre, et crée la version 0.9 de SystemC. Une première contribution de Frontier Design donne lieu à la version 1.0, et une autre de CoWare aboutit en 2000 à la version 1.1, première version officielle de SystemC. L'OSCI (Open SystemC Initiative) est alors crée, rassemblant une multitude de sociétés et laboratoires de recherche. Cette organisation a fusionné en 2011 avec Accellera, une association de normalisation de standards pour le design des systèmes électroniques. C'est maintenant Accellera Systems Initiative qui est en charge de diffuser, promouvoir et rédiger les spécifications de SystemC.

Les spécifications de SystemC ont été étendues en 2001 à la modélisation de systèmes abstraits (de très haut niveau, avant partitionnement matériel / logiciel), aboutissant à la version 2.0. En 2005, l'IEEE a approuvé une version de référence de SystemC, appelée IEEE1666-2005 et correspondant à la version 2.2.0 de SystemC.

En 2011 une révision du standard est approuvée, elle intègre entre autre la modélisation transactionnelle de TLM-2.0. Elle est appelée IEEE1666-2011 et est téléchargeable directement sur le site de l'IEEE.

Ce cours n'aborde pas en détail la modélisation transactionnelle.Les concepts abordés s'appliquent ainsi aux versions 2.2.0 et 2.3.0 de SystemC.

Bien que libre, la bibliothèque SystemC ne peut être téléchargée que depuis le site d'Accelera. Elle a été installée sur les machines du département COMELEC, dans le répertoire /comelec/softs/opt/systemc/systemc-2.3.0 et a été compilée pour les architectures x86 64bits sur Linux. Nous verrons plus loin comment l'utiliser.

Pour vous simplifier la vie, vous avez quand même accès au User Guide, et aux Functional Specifications for SystemC 2.0, mais en accès local seulement (depuis une machine du département).

Vous avez aussi une Quick Reference Card de la société Transfer, qui résume sur deux pages toutes les constructions de SystemC.

 

Back to top

Objectifs et utilité de SystemC

SystemC a pour objectif de modéliser des systèmes numériques matériels et logiciels à l'aide de C++. Il permet donc de modéliser non seulement des systèmes matériels, mais aussi des systèmes logiciels, mixtes ou non-partitionnés (où on ne sait pas encore ce qui sera fait en logiciel, et ce qui sera fait en matériel).

La modélisation d'un système complet passe par des niveaux comportementaux plus détaillés que ceux abordés précédemment.
La description de ces niveaux se fait à l'aide des termes suivants :

 

Le processus de modélisation d'un SoC se décompose alors ainsi :

 

Flot de développement habituel

Développement d'un système : raffinement des modèles matériels / logiciels

L'un des inconvénients majeurs des flots habituels vient de la multitude des langages mis en oeuvre :

 

Toutes ces transcriptions manuelles introduisent des erreurs. L'objectif principal de SystemC est de maintenir un seul et même langage d'un bout à l'autre du flot de conception.

 

SystemC étant une extension du C++ (donc du C), un seul et même langage est utilisé de la première étape du flot de conception jusqu'à l'étape TLM (BCA) ou CABA, que ce soit pour la partie logicielle que pour la partie matérielle. Arrivé au stade BCA, ou à un niveau suffisamment bas et raffiné, on peut :

A chaque étape, le même environnement de test (écrit en SystemC) peut être utilisé, garantissant la fonctionnalité du système (matériel + logiciel). Si on arrive à l'utilisation de Verilog ou VHDL, un cosimulateur se charge de simuler les deux langages en même temps.

 

Flot de developppement SC

Flot de conception SystemC

 

Back to top

Organisation de SystemC

SystemC est une extension du langage C++, plus précisément une bibliothèque de classes C++ contenant des modèles de matériel, ainsi que toutes les briques de base pour modéliser un système matériel qui n'aurait pas été inclus dans la bibliothèque de base.

Cette bibliothèque C++ comprend aussi en standard un moteur de simulation événementiel rapide, permettant de se passer d'un simulateur externe. D'autres simulateurs existent, plus ou moins performants, comme le simulateur SystemCass du LIP6 permettant, dans certaines conditions, de multiplier les vitesses de simulation par 20.

La figure ci-dessous résume l'architecture de la bibliothèque.
Les types de données usuels C++ ont été enrichis par des types de données adaptées à la modélisation de matériel (logique multivaluée, décimaux virgule fixe, ...).
Les autres éléments se répartissent en deux ensembles,


Certains des éléments de communication, les canaux, qui sont fréquemment utilisés, font partie de SystemC. On les appelle les canaux atomiques ou primaires (car ce sont des briques de base), et regroupent les signaux, les fifos, ...

Certains de ces types de données servent à représenter du matériel (modules, ports, signaux, fifo), d'autres à représenter du logiciel (sémaphores, mutex), et certains sont suffisamment abstraits pour pouvoir représenter les deux (canaux, événements, interfaces, ...).

 

 

Organisation de SystemC

Organisation de SystemC

 

Un modèle écrit en SystemC est donc un programme C++ utilisant les classes de la bibliothèque SystemC. Il doit donc être compilé.
A l'école, vous travaillerez sur des PC Linux avec la suite de compilation C/C++ GNU (gcc/g++).  

Le processus de développement est le même que pour tout programme C/C++ :

 

Back to top

Structure d'un modèle System

Les différents composants structurels de SystemC seront étudiés en détail plus tard. Mais voici d'ores et déjà un aperçu rapide de la façon dont est construit un modèle SystemC d'un système numérique.

Hiérarchie

Comme en Verilog ou VHDL, un système est une hiérarchie d'objets. Généralement de sont des modules imbriqués et/ou des processus. Les modules communiquent entre eux par des canaux.
Le plus haut de la hiérarchie d'un système complet (module à tester + testbench) n'est pas un module top (comme on en a l'habitude en Verilog/VHDL), mais la fonction SystemC sc_main (l'équivalent du main des programmes en C).

Modules

Un module en SystemC est composé d'autres modules, de canaux de communication entre ces modules (signaux, ou canaux plus abstraits), et éventuellement de processus.

Ports : port

Un module possède un ou plusieurs ports. Les ports sont juste des points d'entrée ou de sortie, qui ne font rien de particulier.
Par contre, les ports doivent déclarer les fonctions qui seront utilisées pour communiquer à travers eux. Exemples :

La déclaration des fonctions qu'il va utiliser est appelée interface.

Interfaces : interface

Une interface est une déclaration des fonctions (ou "méthodes", pour prendre la terminologie C++) qui pourront être utilisées à travers les ports d'un module. Une interface ne contient pas de code, c'est seulement une déclaration de fonctions.
Les interfaces permettent au compilateur de détecter très tôt le branchement d'un port à un canal qui ne lui est pas adapté.

Canaux : canaux

Les canaux sont les moyens de communication entre les modules. Ils peuvent être basique et concrets (signaux), ou plus évolués / plus abstraits (fifo, réseau ethernet, ...). Ils peuvent aussi contenir d'autres canaux, voire même des modules si ce sont des canaux de très haut niveau.

Les canaux contiennent (entre autres) l'implémentation du code C++ déclaré dans les interfaces. On dit qu'ils implémentent une interface.

On branche un canal à un module par l'intermédiaire d'un port, ce port devant déclarer l'interface implémentée par le canal. L'intérieur du module peut alors accéder au canal en appelant les fonctions déclarées dans l'interface. De façon imagée, les ports publient une offre d'embauche (l'interface) et les canaux aptes à y répondre font le boulot. L'interface est donc ce qui lie les ports et les canaux en décrivant comment l'information transite par les ports. Ce qui est symbolisé dans le schéma ci-dessous par l'image port-interface (qui combine port et interface). Tout ce dont a besoin un module pour pouvoir utiliser un port est de connaître l'interface qu'il publie. Autrement dit, on peut modifier à loisir le contenu d'un canal, le raffiner progressivement, sans avoir à toucher quoi que ce soit d'autre. Il suffit que son interface reste la même.

Processus : processus

Les processus en SystemC sont similaire à ceux de Verilog et VHDL. Il décrivent une fonctionnalité, un comportement. Un processus ne doit pas être appelé directement; c'est le moteur de simulation SystemC qui se charge de l'appeler (le déclencher) sur certains événement particuliers : ceux qui sont dans sa liste des sensibilité.

Les processus peuvent éventuellement communiquer directement avec les canaux. Ils n'ont pas besoin de port pour cela, ils appellent directement les méthodes du canal.

 

En résumé, l'architecture d'un module en SystemC ressemble à ceci :

Orga structurelle de SC

Organisation structurelle en SystemC

Exercice 

Si les modules sont des réservoirs d'eau, les ports sont des robinets. Que sont alors les canaux et les interfaces ?

Back to top

Remarques importantes

FAQ C++

Même si SystemC n'utilise pas toutes les possibilités du C++, il est parfois nécessaire de comprendre certaines constructions inhabituelles pour les programmeurs C.
Pour cela, les FAQ C++ sont des ressources très importantes, et tout particulièrement la C++ FAQ Lite. Si votre programme ne compile pas, si vous ne comprenez pas les messages du compilateur ou de l'éditeur de lien, la solution s'y trouve probablement.

 

Structure de code

Les habitués du C ont l'habitude de placer les déclarations dans un fichier .h et l'implémentation dans un fichier .c. Pour le C++, la situation est parfois plus compliquée, notamment à cause des templates.

Certains placent tout leur code directement dans les déclarations de classe, dans les .h. Ce n'est pas bon (voir la FAQ pour savoir pourquoi).
Il est préférable de garder déclarations et implémentations dans des fichiers séparés (.h et .cpp).
Cela pose néanmoins un problème avec les template. Pour plus d'informations, voir les URL suivantes :

 

Personnellement, je recommande, en attendant une version de g++ qui supporte la recompilation des template, d'adopter la troisième solution de la FAQ, c'est-à-dire :

 

Back to top

Changelog

03/03/05 06/06/05
18/06/05
10/03/08
23/02/12
12/03/13

 

 

Back to top

En résumé

SystemC est une bibliothèque C++, qui fournit des classes C++ adaptées à la modélisation de matériel ainsi qu'un moteur de simulation événementiel rapide, le tout sous licence libre !

Il permet de garder un même langage d'un bout à l'autre du flot de conception, excepté peut-être à la toute fin (mais on a alors des moyens de s'assurer de la cohérence des modèles).

Un modèle SystemC est écrit en C++, c'est généralement un module.

Les modules sont les briques structurelles de base. Ils instancient d'autres modules, ainsi que des canaux et des processus. Ils communiquent avec l'extérieur par des ports. La communication proprement dite se fait au travers de canaux reliés au port.

Pour qu'un canal soit relié à un port, les deux doivent avoir la même interface (déclaration de fonctions). L'implémentation de ces fonctions est faite dans le canal.

 

Back to top