1. Introduction aux bases du langage SystemC
Module Co-Design - II3
Élaboré par:
Saber FERJANI
École Nationale des Sciences Informatiques
18 Octobre 2012
Saber F. (ENSI)
SystemC
18 Octobre 2012
1 / 42
2. Objectif
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.
Saber F. (ENSI)
SystemC
18 Octobre 2012
2 / 42
5. Terminologie
UTF (UnTimed Functional) : s'applique à l'interface et à la fonctionnalité
d'un modèle. Le modèle comporte seulement un ordre éventuel dans
l'exécution des événements. Chaque événement s'exécute en un temps nul.
TF (Timed Functional) : s'applique à l'interface et à la fonctionnalité d'un
modèle. Le modèle comporte des notion de durée.
BCA (Bus Cycle Accurate) : s'applique à l'interface d'un modèle. Il signie
que la modélisation des transactions sur l'interface sont correctes au cycle
près.
CABA (cycle accurate / bit accurate) : s'applique à l'interface d'un modèle
et à la fonctionnalité d'un modèle. Il signie que la modélisation des
transactions sur l'interface est BCA, et porte aussi sur les signaux de
l'interface. La modélisation est précise au bit près.
RTL (Register Transfert Level) : s'applique à l'interface et à la fonctionnalité
d'un modèle matériel. Tout est modélisé.
Saber F. (ENSI)
SystemC
18 Octobre 2012
5 / 42
7. Inconvénients de la méthode classique
L'un des inconvénients majeurs des ots habituels vient de la multitude des
langages mis en ÷uvre :
Saber F. (ENSI)
SystemC
18 Octobre 2012
7 / 42
8. Inconvénients de la méthode classique
L'un des inconvénients majeurs des ots habituels vient de la multitude des
langages mis en ÷uvre :
le partitionnement matériel / logiciel est eectué, le plus souvent en C /
C++ (ou dans un langage spécialisé)
Saber F. (ENSI)
SystemC
18 Octobre 2012
7 / 42
9. Inconvénients de la méthode classique
L'un des inconvénients majeurs des ots habituels vient de la multitude des
langages mis en ÷uvre :
le partitionnement matériel / logiciel est eectué, le plus souvent en C /
C++ (ou dans un langage spécialisé)
un modèle matériel transactionnel (TF) est alors produit, qui sert de modèle
de référence. C'est un exécutable modélisant le comportement du système
matériel. Il est écrit le plus souvent en C / C++ ou dans un langage
propriétaire.
Saber F. (ENSI)
SystemC
18 Octobre 2012
7 / 42
10. Inconvénients de la méthode classique
L'un des inconvénients majeurs des ots habituels vient de la multitude des
langages mis en ÷uvre :
le partitionnement matériel / logiciel est eectué, le plus souvent en C /
C++ (ou dans un langage spécialisé)
un modèle matériel transactionnel (TF) est alors produit, qui sert de modèle
de référence. C'est un exécutable modélisant le comportement du système
matériel. Il est écrit le plus souvent en C / C++ ou dans un langage
propriétaire.
ce modèle est alors manuellement transcrit dans un langage de description
matériel, puis rané jusqu'à la synthèse.
Saber F. (ENSI)
SystemC
18 Octobre 2012
7 / 42
11. Inconvénients de la méthode classique
L'un des inconvénients majeurs des ots habituels vient de la multitude des
langages mis en ÷uvre :
le partitionnement matériel / logiciel est eectué, le plus souvent en C /
C++ (ou dans un langage spécialisé)
un modèle matériel transactionnel (TF) est alors produit, qui sert de modèle
de référence. C'est un exécutable modélisant le comportement du système
matériel. Il est écrit le plus souvent en C / C++ ou dans un langage
propriétaire.
ce modèle est alors manuellement transcrit dans un langage de description
matériel, puis rané jusqu'à la synthèse.
une fois le module matériel arrivé au stade CABA, un autre modèle C / C++
de référence est produit (manuellement) incorporant les éventuelles
modications qui ont eu lieu tout au long du cycle de développement.
Saber F. (ENSI)
SystemC
18 Octobre 2012
7 / 42
12. Inconvénients de la méthode classique
L'un des inconvénients majeurs des ots habituels vient de la multitude des
langages mis en ÷uvre :
le partitionnement matériel / logiciel est eectué, le plus souvent en C /
C++ (ou dans un langage spécialisé)
un modèle matériel transactionnel (TF) est alors produit, qui sert de modèle
de référence. C'est un exécutable modélisant le comportement du système
matériel. Il est écrit le plus souvent en C / C++ ou dans un langage
propriétaire.
ce modèle est alors manuellement transcrit dans un langage de description
matériel, puis rané jusqu'à la synthèse.
une fois le module matériel arrivé au stade CABA, un autre modèle C / C++
de référence est produit (manuellement) incorporant les éventuelles
modications qui ont eu lieu tout au long du cycle de développement.
à chaque étape, les environnements de test doivent eux aussi être transcodés.
Saber F. (ENSI)
SystemC
18 Octobre 2012
7 / 42
13. Inconvénients de la méthode classique
L'un des inconvénients majeurs des ots habituels vient de la multitude des
langages mis en ÷uvre :
le partitionnement matériel / logiciel est eectué, le plus souvent en C /
C++ (ou dans un langage spécialisé)
un modèle matériel transactionnel (TF) est alors produit, qui sert de modèle
de référence. C'est un exécutable modélisant le comportement du système
matériel. Il est écrit le plus souvent en C / C++ ou dans un langage
propriétaire.
ce modèle est alors manuellement transcrit dans un langage de description
matériel, puis rané jusqu'à la synthèse.
une fois le module matériel arrivé au stade CABA, un autre modèle C / C++
de référence est produit (manuellement) incorporant les éventuelles
modications qui ont eu lieu tout au long du cycle de développement.
à chaque étape, les environnements de test doivent eux aussi être transcodés.
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 ot de
conception.
Saber F. (ENSI)
SystemC
18 Octobre 2012
7 / 42
14. Limite de la simulation
Saber F. (ENSI)
SystemC
18 Octobre 2012
8 / 42
15. Flot de conception SystemC
Saber F. (ENSI)
SystemC
18 Octobre 2012
9 / 42
16. Objectif
Permet la co-conception logiciel/Matériel
Avantages
Pas de transcriptions manuelles.
Saber F. (ENSI)
SystemC
18 Octobre 2012
10 / 42
17. Objectif
Permet la co-conception logiciel/Matériel
Avantages
Pas de transcriptions manuelles.
Plus proche du matériel par rapport à C/C++, et plus abstrait que
Verilog/Vhdl
Saber F. (ENSI)
SystemC
18 Octobre 2012
10 / 42
18. Objectif
Permet la co-conception logiciel/Matériel
Avantages
Pas de transcriptions manuelles.
Plus proche du matériel par rapport à C/C++, et plus abstrait que
Verilog/Vhdl
Open-source
Saber F. (ENSI)
SystemC
18 Octobre 2012
10 / 42
19. Objectif
Permet la co-conception logiciel/Matériel
Avantages
Pas de transcriptions manuelles.
Plus proche du matériel par rapport à C/C++, et plus abstrait que
Verilog/Vhdl
Open-source
Plusieurs niveaux d'abstraction de la conception système jusqu'à la synthèse
RTL
Saber F. (ENSI)
SystemC
18 Octobre 2012
10 / 42
20. Objectif
Permet la co-conception logiciel/Matériel
Avantages
Pas de transcriptions manuelles.
Plus proche du matériel par rapport à C/C++, et plus abstrait que
Verilog/Vhdl
Open-source
Plusieurs niveaux d'abstraction de la conception système jusqu'à la synthèse
RTL
Types de données enrichis par des types de données adaptées à la
modélisation de matériel (logique multivaluée, décimaux virgule xe, ...).
Saber F. (ENSI)
SystemC
18 Octobre 2012
10 / 42
21. Objectif
Permet la co-conception logiciel/Matériel
Avantages
Pas de transcriptions manuelles.
Plus proche du matériel par rapport à C/C++, et plus abstrait que
Verilog/Vhdl
Open-source
Plusieurs niveaux d'abstraction de la conception système jusqu'à la synthèse
RTL
Types de données enrichis par des types de données adaptées à la
modélisation de matériel (logique multivaluée, décimaux virgule xe, ...).
Moteur de simulation adapté : PowerSim, SystemCass du LIP6
Saber F. (ENSI)
SystemC
18 Octobre 2012
10 / 42
23. Historique
Version 0.9 par Synopsys en 1989
Version 1.0 par Frontier Design
Saber F. (ENSI)
SystemC
18 Octobre 2012
11 / 42
24. Historique
Version 0.9 par Synopsys en 1989
Version 1.0 par Frontier Design
Version 1.1 par CoWare en 2001
Saber F. (ENSI)
SystemC
18 Octobre 2012
11 / 42
25. Historique
Version 0.9 par Synopsys en 1989
Version 1.0 par Frontier Design
Version 1.1 par CoWare en 2001
Création de L'OSCI (Open SystemC Initiative) en 2001
Saber F. (ENSI)
SystemC
18 Octobre 2012
11 / 42
26. Historique
Version 0.9 par Synopsys en 1989
Version 1.0 par Frontier Design
Version 1.1 par CoWare en 2001
Création de L'OSCI (Open SystemC Initiative) en 2001
Version 2.0 par L'OSCI
Saber F. (ENSI)
SystemC
18 Octobre 2012
11 / 42
27. Historique
Version 0.9 par Synopsys en 1989
Version 1.0 par Frontier Design
Version 1.1 par CoWare en 2001
Création de L'OSCI (Open SystemC Initiative) en 2001
Version 2.0 par L'OSCI
Version 2.2 approuvée par IEEE appelée IEEE1666-2005 en 2005.
Saber F. (ENSI)
SystemC
18 Octobre 2012
11 / 42
28. Historique
Version 0.9 par Synopsys en 1989
Version 1.0 par Frontier Design
Version 1.1 par CoWare en 2001
Création de L'OSCI (Open SystemC Initiative) en 2001
Version 2.0 par L'OSCI
Version 2.2 approuvée par IEEE appelée IEEE1666-2005 en 2005.
En juin 2011 une alliance entre Accellera et l'OSCI est annoncée
Saber F. (ENSI)
SystemC
18 Octobre 2012
11 / 42
37. Design Entity : SC_MODULE
Classe dans C++
Syntaxe
SC_MODULE(module_name)
{
// Ports declaration
// Signals declaration
// Module constructor : SC_CTOR
// Process constructors and sensitivity list
// SC_METHOD
// Sub-Modules creation and port mappings
// Signals initialization
// Process denition
};
Saber F. (ENSI)
SystemC
18 Octobre 2012
16 / 42
38. Design Entity : SC_MODULE
Classe dans C++
Bloc élémentaire de la conception
Syntaxe
SC_MODULE(module_name)
{
// Ports declaration
// Signals declaration
// Module constructor : SC_CTOR
// Process constructors and sensitivity list
// SC_METHOD
// Sub-Modules creation and port mappings
// Signals initialization
// Process denition
};
Saber F. (ENSI)
SystemC
18 Octobre 2012
16 / 42
39. Design Entity : SC_MODULE
Classe dans C++
Bloc élémentaire de la conception
Approche diviser pour régner
Syntaxe
SC_MODULE(module_name)
{
// Ports declaration
// Signals declaration
// Module constructor : SC_CTOR
// Process constructors and sensitivity list
// SC_METHOD
// Sub-Modules creation and port mappings
// Signals initialization
// Process denition
};
Saber F. (ENSI)
SystemC
18 Octobre 2012
16 / 42
40. Design Entity : SC_MODULE
Classe dans C++
Bloc élémentaire de la conception
Approche diviser pour régner
Équivalent à Entity dans Vhdl
Syntaxe
SC_MODULE(module_name)
{
// Ports declaration
// Signals declaration
// Module constructor : SC_CTOR
// Process constructors and sensitivity list
// SC_METHOD
// Sub-Modules creation and port mappings
// Signals initialization
// Process denition
};
Saber F. (ENSI)
SystemC
18 Octobre 2012
16 / 42
41. Ports
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.
Syntaxe
SC_MODULE(module_name)
{
sc_indata_type in1, in2;
sc_outdata_type out1, out2;
sc_inoutdata_type inout1, inout2;
//...
};
Saber F. (ENSI)
SystemC
18 Octobre 2012
17 / 42
42. Interfaces
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é.
Saber F. (ENSI)
SystemC
18 Octobre 2012
18 / 42
43. Canaux
Les canaux sont les moyens de communication entre les modules. Ils peuvent être
basique et concrets (signaux), ou plus évolués / plus abstraits (fo, 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.
Saber F. (ENSI)
SystemC
18 Octobre 2012
19 / 42
44. 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é.
Saber F. (ENSI)
SystemC
18 Octobre 2012
20 / 42
45. Les types de données
III- Les types de données
Saber F. (ENSI)
SystemC
18 Octobre 2012
21 / 42
46. Les éléments de base de SystemC (signaux, ports, ...) sont des classes génériques,
des templates au sens C++. Selon les objets qu'ils représentent, on doit les
spécialiser pour un type particulier, préciser leur nombre de bits, leur nature
(entier ou ottant), ...
Principaux types :
les types bits
Saber F. (ENSI)
SystemC
18 Octobre 2012
22 / 42
47. Les éléments de base de SystemC (signaux, ports, ...) sont des classes génériques,
des templates au sens C++. Selon les objets qu'ils représentent, on doit les
spécialiser pour un type particulier, préciser leur nombre de bits, leur nature
(entier ou ottant), ...
Principaux types :
les types bits
les vecteurs de bits
Saber F. (ENSI)
SystemC
18 Octobre 2012
22 / 42
48. Les éléments de base de SystemC (signaux, ports, ...) sont des classes génériques,
des templates au sens C++. Selon les objets qu'ils représentent, on doit les
spécialiser pour un type particulier, préciser leur nombre de bits, leur nature
(entier ou ottant), ...
Principaux types :
les types bits
les vecteurs de bits
les types entiers
Saber F. (ENSI)
SystemC
18 Octobre 2012
22 / 42
49. Les éléments de base de SystemC (signaux, ports, ...) sont des classes génériques,
des templates au sens C++. Selon les objets qu'ils représentent, on doit les
spécialiser pour un type particulier, préciser leur nombre de bits, leur nature
(entier ou ottant), ...
Principaux types :
les types bits
les vecteurs de bits
les types entiers
les nombres en virgule xe
Saber F. (ENSI)
SystemC
18 Octobre 2012
22 / 42
50. Les éléments de base de SystemC (signaux, ports, ...) sont des classes génériques,
des templates au sens C++. Selon les objets qu'ils représentent, on doit les
spécialiser pour un type particulier, préciser leur nombre de bits, leur nature
(entier ou ottant), ...
Principaux types :
les types bits
les vecteurs de bits
les types entiers
les nombres en virgule xe
les types temporels
Saber F. (ENSI)
SystemC
18 Octobre 2012
22 / 42
51. Les types bits
SystemC propose deux types de bit : sc_bit et sc_logic :
sc_bit
Ce type est obsolète (depuis La version 2.2). On utilisera plutôt le type bool.
Ce type est destiné à représenter un bit ne pouvant prendre que deux valeurs, '0'
(false) et '1' (true).
sc_logic
Ce type est une extension de sc_bit à la logique 4-valuée. Il représente un bit
pouvant prendre les valeurs '0', '1', 'Z' et 'X'. Par défaut, un object sc_logic non
initialisé vaut 'X'.
Saber F. (ENSI)
SystemC
18 Octobre 2012
23 / 42
52. Les types entiers
SystemC propose une extension du type int (généralement sur 32 bits), signés et
non-signés, allant de 1 bit à autant qu'on veut : sc_int, sc_uint, sc_bigint,
sc_biguint.
Exemple
sc_int12 val1, val2; // entiers signés sur 12 bits
sc_int64 res; // entier signé sur 64 bits
sc_uint10 val3; // entier non signé sur 10 bits
sc_int3 val4; // entier signé sur 3 bits
Saber F. (ENSI)
SystemC
18 Octobre 2012
24 / 42
53. Les vecteurs de bits
Les types vecteurs de bits ne doivent pas être confondus avec les types entiers.
Ce sont des tableaux de bits, pas des nombres. Ils sont optimisés pour les
manipulations de bits, et ne disposent pas d'opérations arithmétiques.
sc_bvn : Vecteur de bits 2-valués.
sc_lvn : Vecteur de bits 4-valués.
Exemple
sc_bv8 x;
sc_bit y;
x = 01000111;
y = x[6]; // y vaut '1'
Saber F. (ENSI)
SystemC
18 Octobre 2012
25 / 42
54. Les nombres en virgule xe
Les système numériques travaillant sur des nombres décimaux qui peuvent être
représentés en virgule xe.
SystemC propose quatre types pour représenter ces nombres en virgule xe, avec
diérents modèles de quantication et de dépassement.
signés non-signés
paramètres déterminés à la compilation sc_xed sc_uxed
paramètres dynamiques
sc_x sc_ux
Saber F. (ENSI)
SystemC
18 Octobre 2012
26 / 42
55. Le temps
En SystemC 2.x, comme en Verilog et VHDL, le modèle sous-jacent pour le temps
est de type entier non signé sur 64 bits. La résolution par défaut est 1ps.
Une valeur temporelle est de type sc_time, et demande deux arguments lors de sa
création :
un argument de type double spéciant la valeur,
Exemple
sc_time t1( 20, SC_NS );
Saber F. (ENSI)
SystemC
18 Octobre 2012
27 / 42
56. Le temps
En SystemC 2.x, comme en Verilog et VHDL, le modèle sous-jacent pour le temps
est de type entier non signé sur 64 bits. La résolution par défaut est 1ps.
Une valeur temporelle est de type sc_time, et demande deux arguments lors de sa
création :
un argument de type double spéciant la valeur,
un argument de type énuméré sc_time_unit en spéciant l'unité.
Exemple
sc_time t1( 20, SC_NS );
Saber F. (ENSI)
SystemC
18 Octobre 2012
27 / 42
58. Une fois les éléments structurels de SystemC dénis, nous allons maintenant
présenter les diérents éléments fonctionnels de SystemC, autrement dit comment
représenter la fonctionnalité d'un module autrement que par un assemblage de
sous-boîtes.
Événements : SC_EVENT
Saber F. (ENSI)
SystemC
18 Octobre 2012
29 / 42
59. Une fois les éléments structurels de SystemC dénis, nous allons maintenant
présenter les diérents éléments fonctionnels de SystemC, autrement dit comment
représenter la fonctionnalité d'un module autrement que par un assemblage de
sous-boîtes.
Événements : SC_EVENT
Processus : SC_METHOD, SC_THREAD, SC_CTHREAD
Saber F. (ENSI)
SystemC
18 Octobre 2012
29 / 42
60. Événements
Dénition
Les événements sont les objets sur lesquels se base toute la synchronisation des
processus. Ils déterminent quand est-ce qu'un processus doit être déclenché ou
réveillé.
Il peuvent représenter des événements concrets (changement d'état d'un signal),
ou abstraits.
Classe et méthodes
Les événements sont des instances de la classe sc_event. On les créé rarement
soi-même, sauf quand on crée un nouveau type de canal, ou qu'on veut rendre un
processus sensible à autre chose qu'un signal.
On récupère l'événement associé à un canal par une des méthodes suivante :
pour un signal : value_changed_event(), posedge_event(), negedge_event()
Saber F. (ENSI)
SystemC
18 Octobre 2012
30 / 42
61. Événements
Dénition
Les événements sont les objets sur lesquels se base toute la synchronisation des
processus. Ils déterminent quand est-ce qu'un processus doit être déclenché ou
réveillé.
Il peuvent représenter des événements concrets (changement d'état d'un signal),
ou abstraits.
Classe et méthodes
Les événements sont des instances de la classe sc_event. On les créé rarement
soi-même, sauf quand on crée un nouveau type de canal, ou qu'on veut rendre un
processus sensible à autre chose qu'un signal.
On récupère l'événement associé à un canal par une des méthodes suivante :
pour un signal : value_changed_event(), posedge_event(), negedge_event()
pour les fo : data_written_event(), data_read_event()
Saber F. (ENSI)
SystemC
18 Octobre 2012
30 / 42
62. Processus
Dénition
Les processus de SystemC se comportent comme les processus de VHDL. Ils
décrivent la fonctionnalité d'un module.
Les processus utilisent les événements et les canaux pour communiquer entre eux.
(Il est possible de faire communiquer des processus par des variables, mais c'est
fortement déconseillé.)
Types de processus
Il existe deux types de processus en SystemC : SC_METHOD et SC_THREAD.
(SC_CTHREAD, est une spécialisation des SC_THREAD.)
Étapes d'instanciation :
déclaration du processus
Saber F. (ENSI)
SystemC
18 Octobre 2012
31 / 42
63. Processus
Dénition
Les processus de SystemC se comportent comme les processus de VHDL. Ils
décrivent la fonctionnalité d'un module.
Les processus utilisent les événements et les canaux pour communiquer entre eux.
(Il est possible de faire communiquer des processus par des variables, mais c'est
fortement déconseillé.)
Types de processus
Il existe deux types de processus en SystemC : SC_METHOD et SC_THREAD.
(SC_CTHREAD, est une spécialisation des SC_THREAD.)
Étapes d'instanciation :
déclaration du processus
enregistrement
Saber F. (ENSI)
SystemC
18 Octobre 2012
31 / 42
64. Processus
Dénition
Les processus de SystemC se comportent comme les processus de VHDL. Ils
décrivent la fonctionnalité d'un module.
Les processus utilisent les événements et les canaux pour communiquer entre eux.
(Il est possible de faire communiquer des processus par des variables, mais c'est
fortement déconseillé.)
Types de processus
Il existe deux types de processus en SystemC : SC_METHOD et SC_THREAD.
(SC_CTHREAD, est une spécialisation des SC_THREAD.)
Étapes d'instanciation :
déclaration du processus
enregistrement
déclaration de la liste de sensibilité par défaut
Saber F. (ENSI)
SystemC
18 Octobre 2012
31 / 42
65. Processus
Dénition
Les processus de SystemC se comportent comme les processus de VHDL. Ils
décrivent la fonctionnalité d'un module.
Les processus utilisent les événements et les canaux pour communiquer entre eux.
(Il est possible de faire communiquer des processus par des variables, mais c'est
fortement déconseillé.)
Types de processus
Il existe deux types de processus en SystemC : SC_METHOD et SC_THREAD.
(SC_CTHREAD, est une spécialisation des SC_THREAD.)
Étapes d'instanciation :
déclaration du processus
enregistrement
déclaration de la liste de sensibilité par défaut
implémentation
Saber F. (ENSI)
SystemC
18 Octobre 2012
31 / 42
66. SC_METHOD - SC_THREAD - SC_CTHREAD
Dénition
Les SC_METHOD sont, du point de vue du scheduler, des fonctions normales. Ils
sont appelés par le scheduler à chaque notication d'événement de leur liste de
sensibilité. Ils s'exécutent en entier, dans le contexte du scheduler, puis exécutent
un return(), qui redonne la main au scheduler.
Quand utiliser un SC_METHOD
Pour modéliser des processus qui s'exécutent d'un trait, avec un comportement
globalement constant à chaque appel. Par exemple une bascule D, un compteur, ...
Par opposition, une machine à état passe successivement par des états diérents,
et son comportement change à chaque état. Elle ne se prête donc pas bien aux
SC_METHOD, à moins de la décrire de façon académique (registre d'état, et un
processus combinatoire à part).
Saber F. (ENSI)
SystemC
18 Octobre 2012
32 / 42
67. SC_CTHREAD -
SC_THREAD - SC_CTHREAD
Dénition
Les SC_THREAD sont des threads indépendant du scheduler. Ils sont lancés une
seule fois, au début de la simulation, et plus jamais après. Ce sont des boucles
innies, qui peuvent et doivent être mises en veille à intervalle réguliers. Le temps
peut alors s'écouler. Les SC_THREAD sont réveillés par leur liste de sensibilité.
Diérence avec les SC_METHOD
un SC_METHOD est lancé à chaque fois que sa liste de sensibilité le
demande, et ne se suspend pas (sinon le scheduler bloque).
un SC_THREAD est lancé une seule fois, c'est un thread (au sens Unix du
terme) indépendant. Sa liste de sensibilité sert à le sortir de veille. Il peut
bloquer (veille, boucle innie, ...), ça ne gêne pas le simulateur.
Saber F. (ENSI)
SystemC
18 Octobre 2012
33 / 42
68. SC_CTHREAD - SC_THREAD -
SC_CTHREAD
Dénition
Les SC_CTHREAD sont des cas particuliers des SC_THREAD. Leur nom signie
Clocked THREAD : threads synchrones. Ils sont utilisés pour modéliser des thread
sensibles uniquement à un front d'horloge.
Fonctionnement
Comme les SC_THREAD, les SC_CTHREAD sont des threads Unix
indépendants du simulateur. Une fois qu'ils ont exécuté un return(), ils sont morts
et ne sont plus jamais exécutés.
Saber F. (ENSI)
SystemC
18 Octobre 2012
34 / 42
69. Processus Événements
V- Exemples Introductifs
Saber F. (ENSI)
SystemC
18 Octobre 2012
35 / 42
75. Conclusion Générale
La bibliothèque SystemC permet d'accélérer la réalisation des systèmes,
Il permet d'unier le langage des diérents étapes du ot de conception,
Saber F. (ENSI)
SystemC
18 Octobre 2012
40 / 42
76. Conclusion Générale
La bibliothèque SystemC permet d'accélérer la réalisation des systèmes,
Il permet d'unier le langage des diérents étapes du ot de conception,
L'automatisation de la traduction permet de minimiser la probabilité d'erreur,
Saber F. (ENSI)
SystemC
18 Octobre 2012
40 / 42
77. Conclusion Générale
La bibliothèque SystemC permet d'accélérer la réalisation des systèmes,
Il permet d'unier le langage des diérents étapes du ot de conception,
L'automatisation de la traduction permet de minimiser la probabilité d'erreur,
Bien que SystemC ne remplace pas les langages de description matériel, son
utilisation s'impose de plus en plus.
Saber F. (ENSI)
SystemC
18 Octobre 2012
40 / 42
78. Merci pour votre attention !
Saber F. (ENSI)
SystemC
18 Octobre 2012
41 / 42
