{{{
#!html
<h1>TP7 : Modélisation TLM-DT </h1>
}}}
[[PageOutline]]

= 1 Objectifs =

Le principal objectif de la modélisation TLM-DT (Transaction Level Modeling with Distributed Time)
est d'accélérer la vitesse de simulation du
prototype virtuel, au prix d'une légère perte de précision temporelle. Cette accélération est 
particulièrement utile dans le cas d'architectures multi-processeurs comportant un
grand nombre de processeurs, puisque le temps de simulation augmente proportionnellement au nombre de processeurs.

Le but de ce TP est donc de modéliser, et de simuler en TLM-DT l'architecture quadri-processeurs du TP4.

= 2 Top-Cell TLM-DT =

Comme les communications entre composants en TLM-DT utilisent des appels de fonctions et non des 
signaux, l'écriture de la top-cell décrivant l'architecture matérielle est simplifiée, puisqu'il n'y a pas besoin de 
déclarer les signaux.

Les prototypes des constructeurs TLM-DT des composants matériels ressemblent beaucoup aux prototypes des constructeurs CABA.
La principale différence est que le composant d'interconnexion '''!VciVgmn''' n'utilise pas le paramètre template '''vci_param'''. 

En principes les noms des ports sont identiques pour les modèles CABA et TLM-DT (même si le
mécanisme de communication est très différent. Prenez le temps de consulter la documentation 
des composants [https://www.soclib.fr/trac/dev/wiki/Component/ ici]).

La modélisation TLM-DT correspondant à une représentation plus abstraite de l'architecture, on n'a pas besoin
de décrire précisément les largeurs des différentes nappes de fils de l'interface VCI. On se contente de préciser le type C++ utilisé pour véhiculer les adresses et les données :

{{{
     typedef VciParams<uint32_t, uint32_t> vci_param;
}}}

C'est la description de la connectique qui est la plus profondément modifiée :
La modélisation TLM-DT ne permet que des connexions point à point entre deux ports de deux composants
matériels : Pour connecter le port '''px''' du composant '''A''' au port '''py''' du composant '''B''' , on ne fait plus référence à un signal intermédiaire, et on écrit directement :
{{{
     (A.px)(B.py);
}}}
ou de façon équivalente :
{{{
     (B.py)(A.px);
}}}

Si un composant C possède un vecteur de ports indexés, chaque élément pz[i] est en fait un pointeur sur un port, et il faut écrire :
{{{
     (A.px)(*C.pz[i]);
}}}

 * Les signaux CK et RESETN des modèles CABA sont des signaux multi-points, mais ces deux signaux ne sont plus représentés explicitement dans la modélisation TLM-DT. 
 * Les signaux VCI sont des connexions point-à-points, qui s'expriment donc très simplement en TLM-DT.
 * Les signaux correspondant à des lignes d'interruption sont également des signaux point-à-point. 

Tous les ports d'un module doivent être explicitement connectés. 

En CABA, les entrées inutilisées d'un composant sont généralement connectées à un même signal possédant la valeur constante ''false''. 
Dans l'architecture quadri-processeurs qui nous intéresse, ceci concerne par exemple les ports IRQ[1] à IRQ[5] des
processeurs MIPS, qui ne sont pas utilisés. Ceci concerne également les ports IRQ_IN[3:1] du composant ICU puisque
les 4 composants IOC, TTY, TIMER et DMA utilisent au total 13 lignes d'interruptions: 
  
 * IRQ_IN[0]      : IOC
 * IRQ_IN[3:1]   : Inutilisés
 * IRQ_IN[7:4]   : DMA[3:0]
 * IRQ_IN[11:8] : TIM[3:0]
 * IRQ_IN[15:12] : TYY[3:0]

Puisqu'en TLM-DT, il n'y a pas de signaux, et que les connexions multi-points sont interdites, on utilise des pseudo-composants matériels '''!VciBlackhole''' possédant le nombre de ports nécessaires pour connecter les ports inutilisés.

Pour ce qui concerne les 3 ports inutilisés du composant ICU IRQ_IN[3:1], on instancie donc un composant de type '''!VciBlackhole''' , nommé '''fake_irq_in''', possédant 3 ports de sortie '''p_socket[k]''':

{{{
     VciBlackhole<tlm::tlm_initiator_socket<> >*  fake_irq_in;
     fake_irq_in = new VciBlackhole<tlm::tlm_initiator_socket<> >("fake_irq_in", 3);
}}}

Pour ce qui concerne Les 5 ports inutilisés IRQ_IN[5:1] de chacun des 4 processeurs, on instancie, pour chaque processeur P[i], un composant de type '''!VciBlackhole''', nommé '''fake_irq_out[i]''', possédant 5 ports de sortie p_socket[k]'':

{{{
     VciBlackhole<tlm::tlm_initiator_socket<> >*  fake_irq_out[4];
     fake_irq_out[0] = new VciBlackhole<tlm::tlm_initiator_socket<> >("fake_irq_out_0", 5);         
     fake_irq_out[1] = new VciBlackhole<tlm::tlm_initiator_socket<> >("fake_irq_out_1", 5);     
     fake_irq_out[2] = new VciBlackhole<tlm::tlm_initiator_socket<> >("fake_irq_out_2", 5);         
     fake_irq_out[3] = new VciBlackhole<tlm::tlm_initiator_socket<> >("fake_irq_out_3", 5);     
}}}

On connecte ensuite ces ports '''p_socket[k]''' de ces pseudo-composants aux ports inutilisés  des processeurs ou de l'ICU.

Il ne faut pas oublier d'inclure le fichier '''vci_blackhole.h''' dans la top-cell, et de compléter le fichier de description de la top-cell en conséquence.

Enfin le lancement de la simulation dans la top-cell se réduit à la ligne suivante :
{{{
     sc_start();
}}}

= 3 Travail à réaliser =

Créez un répertoire TP7 pour ce TP, et placez-vous dans ce répertoire.

En prenant comme point de départ les fichiers décrivant la top-cell de l'architecture quadri-clusters du TP4, écrivez les fichier '''tp7_tlmdt_top.cpp''', et '''tp7_tlmdt_top.desc'''.  Vous trouverez ci-dessous le fichier '''tp7_tlmdt_top.desc''': 

{{{
# -*- python -*-

todo = Platform('tlmdt', 'tp7_tlmdt_top.cpp',
        uses = [
                Uses('tlmdt:vci_xcache_wrapper', iss_t = 'common:gdb_iss', gdb_iss_t = 'common:mips32el'),
                Uses('tlmdt:vci_local_crossbar'),
                Uses('tlmdt:vci_icu'),
                Uses('tlmdt:vci_timer'),
                Uses('tlmdt:vci_ram'),
                Uses('tlmdt:vci_multi_tty'),
                Uses('tlmdt:vci_vgmn'),
                Uses('tlmdt:vci_block_device'),
                Uses('tlmdt:vci_framebuffer'),
                Uses('tlmdt:vci_blackhole'),
                Uses('common:elf_file_loader'),
                Uses('common:mapping_table'),
                ],
        addr_t = 'uint32_t',
        data_t = 'uint32_t',
)
}}}

Vous pouvez re-utiliser sans modifications les fichiers définissant le code binaire du logiciel embarqué du TP5.
Recopiez donc dans le répertoire TP7, les deux répertoires contenant les deux applications exécutables sur l'architecture
quadri-clusters '''soft_hello''' et '''soft_transpose'''. 

== 3.1 Validation de l'architecture matérielle ==

Générez le simulateur TLM-DT de l'architecture quadriclusters en utilisant soclib-cc.

'''Question''' : Validez ce prototype virtuel en exécutant l'application ''hello world''.

== 3.2 Application Transpose ==

La modélisation TLM-DT permet de réduire les temps de simulation, au prix d'une légère perte de précision temporelle.
Comparez les temps de simulation du modèle CABA et du modèle TLM-DT en exécutant successivemenr l'application logicielle ''transpose'' sur le prototype virtuel CABA et sur le prototype virtuel TLM-DT.

'''Question''' : Quel est le rapport des temps de simulation CABA et TLMDT , temps de simulation mesurés en secondes pour afficher 5 images) ?
 
'''Question''' : Quelle est la perte de précision ? On relèvera précisément les dates de début de chargement, fin de chargement, début de transposition, fin de transposition, début d'affichage, fin d'affichage, pour calculer les durées de chacune  des trois phases, pour chacune des 5 images (15 durées à mesurer en CABA, et autant en TLM-DT).  On calculera les 15 erreurs relatives de TLM-DT par rapport à CABA, en divisant l'erreur absolue (nombre de cycles) par la durée de la phase correspondante (nombre de cycles). On en tirera une evaluation de l'erreur relative moyenne en pourcentage.
 
= 4 Compte-rendu =

Il ne vous est pas demandé de compte-rendu pour ce TP, mais on vous demandera une démonstration de votre simulateur au début du TP de la semaine suivante...