Modélisation SystemC d'un contrôleur mémoire durci

Modélisation SystemC d'un contrôleur mémoire durci
Jean BERTRAND - CNES
Vincent DELORD - CNES
15/10/2010

Modélisation et Raffinage d’un System on Chip
Non liée au cas d’étude ASM SWARM.
Volonté d’expérimenter en interne CNES les outils STM.
Déploiement de la plateforme SystemC / TLM + TAC.
Objectif de modéliser et raffiner un système simple mais
représentatif selon trois niveaux d’abstraction :
PV PV + T CABA
Workshop SoCKET – 14 et 15 octobre 2010
2

Workshop SoCKET – 14 et 15 octobre 2010
Expérimentation du flot SoCKET
#
!"# "
!
3

Modélisation et Raffinage d’un System on Chip
Système choisi : Carte CPU NG de la Plateforme Myriade.
Avantage : système existant et validé au niveau RTL.
Contrepartie : pas de vraie exploration d’architecture.
Workshop SoCKET – 14 et 15 octobre 2010
SDRAM RTAX2000 Flash
4

Au centre de la carte CPU NG : l’IP-TVM
Workshop SoCKET – 14 et 15 octobre 2010
5

Modèle fonctionnel simplifié de l’IP TVM
Workshop SoCKET – 14 et 15 octobre 2010
IP TVM
6

Caractéristiques du Contrôleur mémoire « durci »
Les calculateurs en environnement spatial sont fortement
contraints par les perturbations dues aux radiations (Upset,
Latch-up)
Le FPGA RTAX2000 est résistant aux radiations, mais pas les
SDRAM => Le contrôleur doit assurer la sûreté des données.
Accès séquentiel « normal » ou accès tripliqué-voté.
Correction des erreurs de type write-back.
Sélection de trois colonnes parmi quatre pour la passivation des
Latch-up.
Caractéristiques fonctionnelles :
Une interface de communication pour chaque Accesseur.
Ordonnancement des accès de type FIFO + ready/busy.
Workshop SoCKET – 14 et 15 octobre 2010
7

Modèle PV du contrôleur mémoire : une Classe C++
Attributs privés :
(SDRCONF, FIFO, Reg
client)
Attributs publics :
TAC target pour µP et OS-
LINK
TAC initiator pour SDRAM
Méthode privée :
Fonctionnalités du
contrôleur lancé dans un
SC_Thread indépendant.
Méthodes publiques :
implémentation des accès
sur les ports TAC (read,
write, synchro)
Workshop SoCKET – 14 et 15 octobre 2010
8

Simulation du modèle PV
Pour simuler le système au niveau PV, les autres composants
ont été modélisés également (initiateurs OS-link, Processeur,
TAC memory)
Création d’un « Top » selon le modèle STM (Classe « mère »
dont les attributs sont les composants du système)
Puis compilation et exécution du modèle PV de l’IP TVM.
Limitation : pas de modèle détaillé pour le Processeur.
Les simulations se sont limitées aux aspects fonctionnels
simples.
Étape suivante, introduction du temps :
Workshop SoCKET – 14 et 15 octobre 2010
PV + T
9

Ajout du temps dans le modèle PV
Le modèle PV permet les choix d’architecture mais ne révèle
pas les « goulots d’étranglements »
Typiquement, les méthodes read, write sur les mémoires
SDRAM doivent prendre en compte de la complexité des
accès à ce type de mémoires.
Ajout de temps d’exécutions
forfaitaires (directement dans
les méthodes dans notre cas).
Workshop SoCKET – 14 et 15 octobre 2010
10

Simulation du modèle PV+T
Le raffinage nécessite une étude approfondie de chaque
fonction pour en déduire un temps d’exécution précis.
Cependant, il n’est pas obligatoire de raffiner toutes les
fonctions du SoC pour le simuler.
Cela permet de valider les choix au niveau des composants
mémoires par exemple (remplacement des SDRAM par des
SRAM simplement en modifiant les temps d’accès !)
Les simulations révèlent non seulement les goulots
d’étranglements, mais également les asynchronismes.
Aucun bug révélé dans l’IP TVM…
Étape suivante, développement du modèle CABA :
Workshop SoCKET – 14 et 15 octobre 2010
11

Modélisation “Cycle Accurate Bit Accurate”
Le modèle CABA est très différent du PV+T.
Le temps forfaitaire est remplacé par une horloge.
Il nécessite une réécriture complète des interfaces et de la
structure interne des composants. Par exemple, pour
l’interface SDRAM :
tac_target_port toSDRAM1 ;
//Signal permettant de différencier les écritures des lectures
sc_out RW;
//Signaux de contrôle propres aux SDRAMs (rafraîchissement …)
sc_out RAS;
sc_out CAS;
//Signal permettant d’activer la SDRAM
sc_out CS;
//Bus d’adresse
sc_out addr;
//Bus de données
sc_inout data;
Il doit pourtant rester totalement « rétro-compatible ».
Workshop SoCKET – 14 et 15 octobre 2010
12

Raffinement du modèle PV+T en modèle CABA
Les méthodes et types de données des modèles PV et de
CABA sont compatibles au sein d’un même module grâce à
une méthode interne. Les données peuvent transiter :
D’un port sc_in vers un port de type tac_initiator_port.
D’un port tac_target_port vers un sc_out.
Ceci permet de dériver (=raffiner) le modèle CABA directement
à partir du modèle PV+T.
Chaque sous-fonction est raffinée individuellement et peut être
re-simulée avec le modèle PV+T déjà validé, assurant ainsi la
cohérence avec les modèles de plus fortes abstractions.
Workshop SoCKET – 14 et 15 octobre 2010
13

Simulation hétérogène PV(+T) avec CABA
Il n’est pas possible de relier directement deux modèles de
composants de niveaux différents.
Il faut donc insérer un « traducteur » (appelé Transacteur)
entre un composant CABA et un composant PV(+T).
Workshop SoCKET – 14 et 15 octobre 2010
14

Modèle CABA : utile ou pas ?
L’effort de raffinement PV+T vers CABA est du même ordre
que celui de codage du VHDL !
Workshop SoCKET – 14 et 15 octobre 2010
VHDL CABA
entity exemple is
port (
entree : in std_logic;
sortie : out std_logic);
end entity;
architecture test of exemple is
signal bus : unsigned(31
downto 0);
begin
#code
end test;
class exemple : public sc_module
{
public :
sc_in entree;
sc_out sortie;
void méthode();
private :
sc_signal bus;
};
void exemple::méthode(){ /*code*/
}
15

Modèle CABA : utile ou pas ?
Un tel effort de développement serait valable s’il existait des
outils universels de transformation CABA vers VHDL. Or
aujourd’hui les outils existants sont assez spécialisés par
domaines.
Sachant d’autre part que, même lorsque la représentativité visà-vis
du matériel est théoriquement parfaite, tout ne se
débugge pas au niveau CABA :
Si par exemple des erreurs de type métastabilités sont
révélées en simulation rétro-annoté, il faudra retoucher le
VHDL et propager la modification dans le modèle CABA… à la
main !
Le risque de divergence est alors très fort.
Workshop SoCKET – 14 et 15 octobre 2010
16

Workshop SoCKET – 14 et 15 octobre 2010
Conclusions
Le raffinement de modèle PV vers PV+T permet de
dimensionner rapidement son système et de valider les choix
d’architectures.
Le modèle CABA peut également s’obtenir par raffinage,
néanmoins l’absence de passerelle universelle vers VHDL
induit un fort risque de divergence.
La simulation SystemC CABA reste plus rapide que le niveau
RTL et plus précise que le PV(+T). Cependant l’investissement
conséquent lié à ce développement ne se justifie que dans le
cas d’un re-use très large (et encore…) ou d’un besoin de
qualification des modèles en vue de simulations conjointes.
Considérant les objectifs « projets scientifiques» du CNES,
l’usage de ce niveau d’abstraction ne se justifie pas.
17

Workshop SoCKET – 14 et 15 octobre 2010
Questions ?
18