Jean BERTRAND - CNESVincent DELORD - CNES

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

15/10/2010

Workshop SoCKET – 14 et 15 octobre 2010 2

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 3

Expérimentation du flot SoCKET

���������� ��

���������������

��������� ��������

� ���������������������

���������

�������������

��������������

������

���������������

���������

�����������������

��������������

����������

�����������������

� �����������

� �����������

�����

�����

��������

��������

������������������������

������ �������� ���� �!�������

���

��� �����������

�������

�!"#������

�������"���������

#�� ����������������������� ����

Workshop SoCKET – 14 et 15 octobre 2010 4

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.

SDRAM RTAX2000 Flash

Workshop SoCKET – 14 et 15 octobre 2010 5

Au centre de la carte CPU NG : l’IP-TVM

Workshop SoCKET – 14 et 15 octobre 2010 6

Modèle fonctionnel simplifié de l’IP TVM

IP TVM

Workshop SoCKET – 14 et 15 octobre 2010 7

Caractéristiques du Contrôleur mémoire « durci »

�Les calculateurs en environnement spatial sont fort ement contraints par les perturbations dues aux radiation s (Upset, Latch-up)�Le FPGA RTAX2000 est résistant aux radiations, mais pas les

SDRAM => Le contrôleur doit assurer la sûreté des do nné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 pa ssivation des

Latch-up.

�Caractéristiques fonctionnelles :�Une interface de communication pour chaque Accesseu r.�Ordonnancement des accès de type FIFO + ready/busy.

Workshop SoCKET – 14 et 15 octobre 2010 8

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-LINKTAC 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 9

Simulation du modèle PV

�Pour simuler le système au niveau PV, les autres co mposants ont été modélisés également (initiateurs OS-link, Pr ocesseur, TAC memory)�Création d’un « Top » selon le modèle STM (Classe « mèr e »

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 Processe ur.�Les simulations se sont limitées aux aspects foncti onnels

simples.

�Étape suivante, introduction du temps :

PV + T

Workshop SoCKET – 14 et 15 octobre 2010 10

Ajout du temps dans le modèle PV

�Le modèle PV permet les choix d’architecture mais n e révèle pas les « goulots d’étranglements »�Typiquement, les méthodes read, write sur les mémoi res

SDRAM doivent prendre en compte de la complexité de s 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 11

Simulation du modèle PV+T

�Le raffinage nécessite une étude approfondie de cha que fonction pour en déduire un temps d’exécution préci s. Cependant, il n’est pas obligatoire de raffiner tou tes les fonctions du SoC pour le simuler.�Cela permet de valider les choix au niveau des comp osants

mémoires par exemple (remplacement des SDRAM par de s 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 12

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 :

� Il doit pourtant rester totalement « rétro-compatibl e ».

tac_target_port<int ,int > toSDRAM1 ;

//Signal permettant de diff érencier les écritures des lecturessc_out< bool> RW;//Signaux de contrôle propres aux SDRAMs (rafra îchissement …) sc_out< bool> RAS;sc_out< bool> CAS;//Signal permettant d ’activer la SDRAMsc_out< bool> CS;//Bus d ’adressesc_out< int> addr;//Bus de donn éessc_inout< int> data;

Workshop SoCKET – 14 et 15 octobre 2010 13

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âc e à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 d irectement à 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 abstracti ons.

Workshop SoCKET – 14 et 15 octobre 2010 14

Simulation hétérogène PV(+T) avec CABA

� Il n’est pas possible de relier directement deux mo dèles de composants de niveaux différents.� Il faut donc insérer un « traducteur » (appelé Transact eur)

entre un composant CABA et un composant PV(+T).

Workshop SoCKET – 14 et 15 octobre 2010 15

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 !

VHDL CABA

entity exemple isport (entree : in std_logic;sortie : out std_logic);

end entity;architecture test of exemple is

signal bus : unsigned(31 downto 0);begin

#codeend test;

class exemple : public sc_module {public :

sc_in<bool> entree;sc_out<bool> sortie;void méthode();

private :sc_signal<int> bus;

};void exemple::méthode(){ /*code*/

}

Workshop SoCKET – 14 et 15 octobre 2010 16

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écial isés par domaines.�Sachant d’autre part que, même lorsque la représent ativité 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 s ont révélées en simulation rétro-annoté, il faudra reto ucher le VHDL et propager la modification dans le modèle CAB A… à la main !

Le risque de divergence est alors très fort.

Workshop SoCKET – 14 et 15 octobre 2010 17

Conclusions

�Le raffinement de modèle PV vers PV+T permet de dimensionner rapidement son système et de valider l es choix d’architectures.�Le modèle CABA peut également s’obtenir par raffina ge,

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’inve stissement 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 bes oin de qualification des modèles en vue de simulations con jointes.

�Considérant les objectifs « projets scientifiques» du CNES, l’usage de ce niveau d’abstraction ne se justifie p as.

Workshop SoCKET – 14 et 15 octobre 2010 18

Questions ?