Brevet FR3011108A1 — publié le 20150327

PROCEDE DE GESTION DE MEMOIRE EN SIMULATION HYBRIDE POUR SYSTEMES-SUR-PUCE Domaine technique de l'invention L'invention est relative à la validation de systèmes-sur-puce à l'aide de techniques d'analyse hybrides permettant de reproduire le comportement du système en utilisant conjointement plusieurs outils d'analyse différents. De telles techniques permettent, par exemple, de simuler certaines parties du système par du logiciel et d' émuler conjointement d'autres parties du système par du matériel. État de la technique L'ensemble de la partie numérique d'un système-sur-puce est en général défini dans un langage de description fonctionnelle de bas niveau, comme le Verilog ou le VHDL, langage que l'on désigne génériquement par RTL (de l'anglais « Register Transfer Level », ou niveau de transfert de registres). Les langages RTL sont précis au cycle d'horloge près (« cycle accurate » en anglais), c'est-à-dire qu'ils décrivent tous les événements qui se produisent à chaque cycle d'une horloge. Un fichier écrit dans un tel langage permet à des outils de synthèse de générer de manière automatisée les portes logiques et autres composants élémentaires nécessaires à réaliser les fonctions décrites. Un simulateur de ce niveau de description reproduit la fonctionnalité de manière logicielle, et s'avère bien trop lent lorsque le circuit est complexe. On lui préfère un émulateur, qui peut être programmé pour réaliser les fonctions logiques de manière matérielle. Cependant, l'horloge cadençant un émulateur étant notablement moins rapide que celle prévue pour cadencer le système-sur-puce, l'émulation trouve également ses limites lorsque le système-sur-puce devient très complexe. Dans ce cas on a recours à des techniques de simulation ou émulation hybride. Ces techniques consistent à partitionner un système en deux domaines de modélisation : un domaine de modélisation de bas niveau, du niveau d'un langage RTL, regroupe les circuits dont on veut analyser le comportement fin, au cycle près ; et un domaine de modélisation de haut niveau regroupe les circuits dont on veut utiliser les fonctions génériques, notamment les processeurs exécutant un programme. Le langage SystemC, tel que défini dans la norme IEEE 1666-2011, comporte une classe ou extension dénommée TLM (« Transaction Level Modeling ») pouvant servir dans le domaine de modélisation de haut niveau. Cette extension permet notamment de simuler rapidement la fonctionnalité d'un système processeur dans l'exécution d'un programme. Pour relier les deux domaines de modélisation, le domaine de haut niveau qu'on désignera par TLM, et le domaine de bas niveau qu'on désignera par RTL, on a développé une interface normalisée dénommée SCE-MI, décrite dans le manuel intitulé « Standard Co-Emulation Modeling Interface (SCE-MI) Reference Manual », publié sur Internet par le consortium Accellera Systems Initiative. La figure 1 est un schéma-bloc d'un exemple de système-sur-puce, ou SoC, partitionné pour mettre en oeuvre ces techniques. Le système comprend un processeur hôte d'usage général CPU, une mémoire partagée MEM, un dispositif périphérique IP, et une interface d'entrée/sortie IO. Tous ces éléments sont interconnectés par un bus B. Le processeur CPU, la mémoire MEM et l'interface IO se trouvent dans le domaine TLM, tandis que le dispositif périphérique IP se trouve dans le domaine RTL. Le bus B traverse les domaines par une interface SCE-MI, par exemple. Cette configuration permet d'analyser de manière fine le comportement du dispositif IP, par exemple un nouveau circuit qui n'a pas encore été réalisé sur silicium. Cette analyse peut être faite par émulation ou simulation de son comportement décrit en RTL. De manière générale, on place dans le domaine TLM des circuits dont la fiabilité a été vérifiée ou qui n'ont pas besoin d'une analyse fine. On y place en particulier, comme 20 cela est représenté, un système processeur d'usage général CPU, avec sa mémoire MEM et une interface permettant de fournir le programme au processeur. Dans une telle configuration, toute transaction sur le bus B, initiée par le processeur CPU ou le dispositif IP, est répercutée d'un domaine à l'autre par l'interface SCE-MI. Dans le monde de la simulation ou de l'émulation RTL, une transaction sur le bus est 25 plus lente, de plusieurs ordres de grandeur, par rapport à la transaction dans le circuit réel. Les accès à la mémoire MEM, occupant en pratique la majeure partie de la bande passante du bus, ralentiraient considérablement la simulation si chaque transaction était en effet simulée. Afin d'éviter un tel ralentissement, l'extension TLM prévoit une interface mémoire directe DMI, permettant de court-circuiter le bus pour les accès 30 mémoire effectués par le processeur CPU. Le gain en temps de simulation procuré par l'interface DMI est considérable, mais cela impose que la mémoire partagée soit placée dans le domaine TLM. Dans certaines situations, on souhaite placer la mémoire partagée dans le domaine RTL, par exemple pour analyser une nouvelle structure de mémoire, ou pour analyser des circuits qui ont une interaction poussée avec la mémoire, comme un circuit de gestion de la mémoire ou un circuit DMA. La figure 2 est un schéma-bloc illustrant un exemple de configuration où la mémoire 5 partagée est placée dans le domaine RTL, avec, par exemple, un circuit de gestion de la mémoire MCTRL, et un circuit DMA. Le dispositif périphérique (IP) peut comprendre un microcontrôleur UC conçu pour partager des données avec le processeur CPU par l'intermédiaire de la mémoire partagée MEM. Dans cette situation, l'interface DMI, propre au domaine TLM, n'est plus utilisable, et tous les accès du processeur CPU à la 10 mémoire passent par le bus B pour être pris en compte dans le domaine RTL. Cela peut ralentir la simulation d'un facteur 50 à 100. Résumé de l'invention On souhaiterait accélérer la simulation lorsque la mémoire partagée est placée dans le domaine RTL. 15 On tend à satisfaire ce besoin en prévoyant un procédé de simulation d'un circuit électronique numérique comprenant un processeur hôte, un dispositif périphérique, et une mémoire partagée entre le processeur hôte et le dispositif périphérique par un bus. Le procédé comprenant les étapes suivantes : partitionner le circuit en un domaine de modélisation de haut niveau comprenant des modèles fonctionnels et un domaine de 20 modélisation de bas niveau comprenant des modèles précis au cycle d'horloge près ; définir le processeur hôte dans le domaine de haut niveau ; définir la mémoire partagée et le dispositif périphérique dans le domaine de bas niveau ; définir une mémoire fantôme dans le domaine de haut niveau ; intercepter les accès du processeur hôte à la mémoire partagée, et rediriger les accès vers la mémoire fantôme, sans utiliser le bus, 25 par une interface mémoire directe (DMI) définie pour le domaine de modélisation de haut niveau ; et quand un accès à la mémoire partagée par le processeur hôte concerne des données partagées avec le dispositif périphérique, reproduire cet accès dans la mémoire partagée en utilisant le bus. Selon un mode de mise en oeuvre du procédé, un programme exécuté par le processeur 30 hôte comprend des instructions de gestion de mémoire cache ayant comme paramètres des emplacements mémoire. Le procédé comprend alors les étapes suivantes : définir la mémoire fantôme comme une mémoire cache pour le processeur hôte, de même taille au moins que la mémoire partagée ; et identifier les données partagées avec le dispositif périphérique à l'aide de l'emplacement mémoire fourni pour chaque instruction de gestion de mémoire cache. Selon un mode de mise en oeuvre du procédé, chaque instruction de gestion de mémoire cache est l'une parmi : - une instruction de nettoyage, conçue pour synchroniser la mémoire partagée avec la mémoire cache, - une instruction d'invalidation, conçue à l'origine pour marquer des données de la mémoire cache comme nécessitant un rafraîchissement depuis la mémoire partagée lors d'un accès subséquent, et - une instruction combinée de nettoyage et d'invalidation, conçue à l'origine pour synchroniser la mémoire partagée avec les données sales de la mémoire cache, puis invalider des données de la mémoire cache. Selon un mode de mise en oeuvre, le procédé comprend, pour traiter une instruction d'invalidation, l'étape consistant à rafraîchir la mémoire cache à partir de la mémoire 15 partagée dès le traitement de l'instruction d'invalidation. Selon un mode de mise en oeuvre, le procédé comprend, pour traiter une instruction combinée de nettoyage et d'invalidation, les étapes suivantes : définir une mémoire de traçage dans le domaine de modélisation de haut niveau, de même taille au moins que la mémoire partagée ; lors de l'exécution d'une instruction de nettoyage, dupliquer dans la 20 mémoire de traçage les données résultantes transférées de la mémoire cache vers la mémoire partagée ; lors de l'exécution d'une instruction d'invalidation, dupliquer dans la mémoire de traçage les données résultantes transférées de la mémoire partagée vers la mémoire cache ; et lors de l'exécution de l'instruction combinée de nettoyage et d'invalidation, comparer les données de la mémoire cache aux données correspondantes 25 de la mémoire de traçage. Pour les données inégales, les données de la mémoire cache sont transférées dans la mémoire partagée et dans la mémoire de traçage. Pour les données égales, les données de la mémoire partagée sont transférées dans la mémoire cache et dans la mémoire de traçage. Description sommaire des dessins 30 Des modes de réalisation seront exposés dans la description suivante, faite à titre non limitatif en relation avec les figures jointes parmi lesquelles : - la figure 1, précédemment décrite, représente un exemple de configuration de simulation hybride dans laquelle une mémoire partagée est placée dans un domaine de modélisation de haut niveau ; - la figure 2, précédemment décrite, représente un exemple de configuration de simulation hybride dans laquelle la mémoire partagée est placée dans un domaine de modélisation de bas niveau ; - la figure 3 représente un mode de réalisation de configuration de simulation hybride permettant de diminuer le temps de simulation lorsque la mémoire partagée est placée dans le domaine de modélisation de bas niveau ; et - les figures 4A à 4C symbolisent des étapes de procédé illustrant diverses possibilités d'utilisation de la configuration de la figure 3. Description d'un mode de réalisation préféré de l'invention Certains revendeurs de code RTL pour des processeurs à embarquer, comme la société ARM, proposent des modèles encapsulés au niveau TLM pour leurs processeurs, 15 permettant de simuler également la mémoire cache. Le fait de prévoir une mémoire cache dans le domaine TLM permet de réduire les accès mémoire par le bus B, ce qui tendrait à réduire le temps de simulation lorsque la mémoire partagée se trouve dans le domaine RTL (figure 2). Cependant, une mémoire cache n'offre pas un comportement prévisible, car son efficacité dépend des propriétés 20 du traitement effectué par le processeur, et elle n'est pas efficace lorsque le processeur traite des flots de données non-répétitives. Ainsi, on a constaté que le temps de simulation ne diminuait pas de manière significative dans la plupart des cas, et qu'il pouvait même augmenter dans certains cas, du fait que la simulation d'une mémoire cache est complexe. 25 En pratique, dans un système réel, la majeure partie de la bande passante du bus peut être occupée par le processeur CPU qui exécute un programme gourmand en ressources, comme une interface utilisateur graphique. Les données effectivement partagées entre le processeur CPU et le dispositif périphérique, ou microcontrôleur UC, peuvent ainsi représenter une partie infime de l'occupation du bus. On propose ci-après de tirer partie 30 de cette situation, pour ne faire apparaître sur le bus que les transactions concernant les données partagées. La figure 3 est un schéma-bloc d'une configuration de simulation hybride, du type de la figure 2, incorporant, dans le domaine TLM, une mémoire fantôme 10 gérée de manière particulière : de façon générale, toute transaction mémoire opérée par le processeur CPU, normalement destinée à la mémoire partagée MEM située dans le domaine RTL, est interceptée et redirigée vers la mémoire fantôme 10 en utilisant l'interface DMI. Cependant, quelques transactions marquées comme devant aller sans délai en mémoire partagée MEM, ou étant à destination d'un dispositif périphérique, comme le circuit DMA sont, effectivement placées sur le bus B, et donc prises en compte directement par leur destinataire (MEM ou DMA). Il en résulte que la mémoire partagée MEM ne contient finalement que les données partagées émises soit par le dispositif périphérique DMA, soit par les transactions placées sur le bus B Les autres données (ou instructions de programme) utilisées exclusivement dans le domaine TLM, notamment par le processeur CPU, ne sont contenues que dans la mémoire fantôme, où elles sont manipulées exclusivement par l'interface DMI. La mémoire fantôme 10 se comporte en fait comme une mémoire cache de taille illimitée, ou au moins de taille égale à celle de la mémoire partagée, qui serait configurée pour garder une vue locale de la mémoire partagée en RTL; c'est-à-dire qu'elle contient une copie locale des données lues ou écrites par le processeur dans la mémoire RTL non forcément cohérentes instantanément avec les données de celle-ci, car ne tenant pas compte des modifications effectuées par les modèles internes au domaine RTL. Dans chaque architecture de processeur sachant gérer une mémoire cache, il existe une manière d'identifier des données que le développeur ne souhaite pas mettre en cache. En marquant les données partagées de cette manière, la fonctionnalité souhaitée pourrait être obtenue, car les données partagées seraient toujours échangées par des transactions sur le bus B, et celles non-partagées par des transactions DMI.. Toutefois, cette solution nécessiterait une modification du programme exécuté par le processeur, ce qui n'est pas compatible avec la volonté de tester le système avec son programme original, dont le code source n'est pas forcément disponible. Afin d'utiliser le programme original, sans modification, on propose d'exploiter des instructions de gestion de mémoire cache, forcément présentes dans le programme original, puisque tout système à processeur complexe comprend aujourd'hui une mémoire cache. Ces instructions peuvent être : - Une instruction de « nettoyage », souvent désignée par « clean », servant à forcer la synchronisation de la mémoire partagée avec la mémoire cache. Cette instruction permet notamment de mettre à jour la mémoire partagée avec des données, dites « sales », qui viennent d'être écrites dans la mémoire cache et qui n'ont pas encore été écrites dans la mémoire partagée. Une telle instruction est utilisée, par exemple, lorsque le programme exécuté par le processeur a écrit des données partagées en mémoire et s'apprête à signaler leur disponibilité au dispositif périphérique. L'instruction « clean » permet ainsi de garantir que ces données sont à jour dans la mémoire partagée avant que le dispositif périphérique ne les lise. - Une instruction d'invalidation, souvent désignée par « invalidate », servant à marquer des données en cache comme invalides et à forcer le processeur à lire la mémoire partagée sans accéder à la mémoire cache lors de la prochaine lecture de ces données. A la suite de cette lecture, la mémoire cache se trouve mise à jour avec le contenu de la mémoire partagée. Une telle instruction est utilisée, par exemple, lorsque le dispositif périphérique a mis à disposition des données partagées dans la mémoire, et qu'il a signalé ce fait au processeur par une interruption. En effet, les données contenues dans la mémoire cache ne correspondent alors plus au contenu de la mémoire partagée - l'instruction d'invalidation permet d'assurer que le processeur aille lire les données les plus récentes dans la mémoire partagée. - Une instruction combinée de nettoyage et d'invalidation, souvent désignée par « clean and invalidate ». Cette instruction réalise les deux opérations précédentes de manière atomique. La fonction de nettoyage n'affecte cependant que les données marquées comme « sales » dans la mémoire cache. Une telle instruction est utilisée, par exemple, lorsque le processeur écrit et lit des données dans un même emplacement mémoire. Les données écrites peuvent être une commande pour le dispositif périphérique qui renvoie un résultat pour le processeur dans le même emplacement. Chacune des instructions de gestion de mémoire cache ci-dessus est exécutée avec un paramètre identifiant un emplacement mémoire. Selon les architectures de processeur, l'emplacement mémoire peut être une ligne de cache individuelle ou toutes les lignes de cache correspondant à une plage d'adresses. Chacune de ces instructions identifie ainsi un emplacement mémoire que l'on peut considérer comme correspondant à des données partagées. La mémoire fantôme 10 peut être conçue comme une mémoire cache qui répond à ces instructions de manière plus ou moins détournée, comme on le verra ci-après. Comme la mémoire fantôme 10 est au 5 moins de même taille que la mémoire partagée, on peut omettre dans son modèle les mécanismes à l'origine de la complexité d'une mémoire cache, comme les mécanismes d'indexation, d'éviction, et de gestion des drapeaux des lignes de cache - cela permet d'accélérer la simulation. Le modèle de la mémoire fantôme 10 n'est donc plus un modèle de mémoire cache classique - on continuera cependant à l'appeler « mémoire 10 cache » ci-après. La fonctionnalité souhaitée avec une instruction « clean » est celle offerte par une mémoire cache classique. Les instructions « invalidate » et « clean and invalidate » sont toutefois détournées. Pour gérer les instructions « clean » et « invalidate », on prévoit un module de gestion de cohérence CCTRL. Pour gérer l'instruction « clean and 15 invalidate », on prévoit en outre une mémoire de traçage TRK de même taille, au moins, que la mémoire partagée MEM. La mémoire 10 est utilisée par le processeur CPU par l'intermédiaire de l'interface DMI. Lorsque cela est requis, le module de gestion CCTRL assure les transferts entre la mémoire 10 et le bus B, et entre les mémoires 10 et TRK. 20 Les figures 4A à 4C illustrent l'utilisation de chacune des trois instructions de gestion de mémoire cache ci-dessus. La figure 4A illustre une manière de traiter l'instruction « clean » à l'aide d'un exemple. La mémoire cache 10 contient un certain nombre de données qui ont été écrites par le processeur, notamment des données « CPU DATA» exclusives au processeur, et des 25 données à l'emplacement d'adresse Al, destinées à être partagées avec le dispositif périphérique UC. L'instruction CLEAN(A1) est exécutée par le processeur pour préparer le partage de ces données avec le dispositif périphérique. Cette instruction est transmise au module de gestion CCTRL qui la traite en transférant le contenu de l'emplacement Al de la mémoire cache vers la mémoire partagée MEM par le bus B. 30 Le module CCTRL duplique également ce contenu dans la mémoire de traçage TRK, dont le rôle sera décrit ultérieurement. La lecture de la mémoire cache par le module CCTRL et la duplication dans la mémoire TRK n'ont pas besoin d'être faites selon une procédure de simulation normalisée - ces opérations peuvent être faites de manière logicielle interne qui ne ralentit pas la simulation. A la fin du traitement, la mémoire partagée MEM contient donc les mêmes données que la mémoire cache 10; un dispositif périphérique DMA peut donc utiliser ces données de manière fiable. On remarque que la mémoire partagée MEM peut contenir des données « UC DATA» qui ont été écrites par le microcontrôleur du dispositif périphérique en empruntant le bus B. Ces données, si elles sont exclusives au dispositif périphérique, ne seront jamais dupliquées dans la mémoire cache. Dans le système réel, comme cela est illustré en pointillés, elles partageraient la même mémoire avec les données « CPU DATA» et l'emplacement Al. De ce fait, les données « CPU DATA », « UC DATA» et Al utilisent des plages d'adresses disjointes, comme cela est illustré. La figure 4B illustre une manière de traiter l'instruction « invalidate » à l'aide d'un exemple. Le microcontrôleur UC du dispositif périphérique vient d'écrire des données à partager dans un emplacement d'adresse A2 de la mémoire MEM. Cette écriture a été faite par le bus B. Selon la conception du programme, le microcontrôleur peut émettre une interruption vers le processeur CPU pour signaler la disponibilité de ces données, ou bien le processeur se charge de scruter régulièrement un emplacement particulier pour y trouver les nouvelles données (en utilisant des transactions vers la mémoire partagée MEM. Le processeur prépare la lecture de l'emplacement A2 en exécutant l'instruction INVALIDATE(A2), destinée à l'origine à marquer les données correspondantes dans la mémoire cache comme « invalides ». Dans un système réel, lorsque le processeur lit l'emplacement A2, la mémoire cache émet un échec de lecture (« cache miss »), provoquant une lecture directe des données à partir de la mémoire partagée, et par la même occasion, un rafraîchissement des lignes de cache correspondantes. Dans le système simulé, pour éviter de mettre en oeuvre ce mécanisme complexe, le module CCTRL traite l'instruction en transférant immédiatement les données de l'emplacement A2 de la mémoire partagée MEM vers la mémoire cache par le bus B. L'emplacement A2 est par la même occasion dupliqué dans la mémoire de traçage TRK, dont le rôle sera décrit ultérieurement. A la fin du traitement, la mémoire cache 10 contient donc les mêmes données que la mémoire partagée MEM; le processeur CPU peut donc utiliser ces données de manière fiable avec des transactions « rapides » DMI. La figure 4C illustre une manière de traiter l'instruction « clean and invalidate » à l'aide d'un exemple. On considère que le processeur CPU et le dispositif périphérique DMA partagent un même emplacement d'adresse Al. Les contenus des différentes copies de l'emplacement Al sont illustrés côte à côte dans trois étapes successives. Lors d'une première étape, le processeur écrit des données CPU-D à l'emplacement Al. Ces données apparaissent d'abord dans la mémoire cache. Les emplacements Al dans la 5 mémoire partagée MEM et la mémoire TRK conservent leur contenu d'origine. Le processeur exécute une instruction CLEAN&INVALIDATE(A1). Dans un système réel, cette instruction vérifierait un drapeau associé aux données dans la mémoire cache et ne provoquerait une mise à jour de la mémoire partagée que si le drapeau indique que les données sont sales. Dans tous les cas, le système réel 10 indiquerait ensuite que les données sont invalides par un autre drapeau. Dans le système simulé, ces drapeaux ne sont pas mis en oeuvre - pour savoir si les données sont sales, on compare le contenu de l'emplacement Al de la mémoire cache au contenu du même emplacement dans la mémoire de traçage TRK. En effet, la fonction de la mémoire TRK, telle qu'elle a été définie jusqu'ici, est de contenir la trace 15 des dernières données partagées échangées par le bus B pour pouvoir effectuer cette comparaison, en fait une image des données partagées telles qu'elles seraient dans la mémoire partagée réelle. Dans cette première étape, les contenus de la mémoire cache et de la mémoire TRK sont différents. Cela provoque le transfert des données CPU-D de la mémoire cache vers la 20 mémoire partagée par le bus B, et vers la mémoire TRK, comme pour le traitement d'une simple instruction « clean » (figure 4A). La composante « invalidation » de l'instruction n'est pas mise en oeuvre. Les différentes mémoires contiennent alors les données CPU-D à l'emplacement Al, comme cela est illustré. Le processeur attend une réponse dans l'emplacement Al. Cette réponse peut être 25 indiquée par une interruption émise par le dispositif périphérique, ou bien le processeur scrute régulièrement un emplacement particulier pour savoir si le contenu de l'emplacement Al a été modifié. Avant de lire le contenu de l'emplacement Al, le processeur exécute une nouvelle instruction CLEAN&INVALIDATE(A1). Cette fois, les emplacements Al de la mémoire cache et de la mémoire de traçage contiennent la 30 même donnée CPU-D - la donnée en mémoire cache est considérée comme « propre » et n'est pas écrite dans la mémoire partagée. Au lieu de cela, on opère une invalidation de l'emplacement Al dans la mémoire cache, comme cela est fait pour une instruction « invalidate » seule (figure 4B) - le contenu de l'emplacement Al de la mémoire partagée est dupliqué dans la mémoire cache, par le bus B, et dans la mémoire de traçage TRK. Si le dispositif périphérique a au préalable modifié le contenu de cet emplacement, le contenu modifié UC-D se trouve ainsi dupliqué dans la mémoire cache et dans la mémoire de traçage. Le processeur peut alors poursuivre son traitement. De nombreuses variantes et modifications du procédé décrit ici apparaîtront à l'homme du métier. Le procédé a été décrit à titre d'exemple en relation avec des instructions de gestion de mémoire cache pouvant être spécifiques à certains processeurs. Les enseignements décrits sont toutefois applicables à toute instruction de gestion de mémoire cache ou autre permettant une discrimination entre des données exclusives et des données partagées. REVENDICATIONS1. Procédé de simulation d'un circuit électronique numérique comprenant un processeur hôte (CPU), un dispositif périphérique (UC), et une mémoire (MEM) partagée entre le processeur hôte et le dispositif périphérique par un bus (B), le procédé comprenant les étapes suivantes : - partitionner le circuit en un domaine de modélisation de haut niveau comprenant des modèles fonctionnels (TLM) et un domaine de modélisation de bas niveau comprenant des modèles précis au cycle d'horloge près (RTL) ; - définir le processeur hôte dans le domaine de haut niveau (TLM) ; - définir la mémoire partagée (MEM) et le dispositif périphérique (UC) dans le domaine de bas niveau (RTL) ; - définir une mémoire fantôme (10) dans le domaine de haut niveau (TLM) ; - intercepter les accès du processeur hôte à la mémoire partagée, et rediriger les accès vers la mémoire fantôme (10), sans utiliser le bus, par une interface mémoire directe (DMI) définie pour le domaine de modélisation de haut niveau ; et - quand un accès à la mémoire partagée (MEM) par le processeur hôte concerne des données partagées avec le dispositif périphérique, reproduire cet accès dans la mémoire partagée en utilisant le bus. 2. Procédé selon la revendication 1, dans lequel un programme exécuté par le processeur hôte comprend des instructions de gestion de mémoire cache ayant comme paramètres des emplacements mémoire, le procédé comprenant les étapes suivantes : - définir la mémoire fantôme (10) comme une mémoire cache pour le processeur hôte, de même taille au moins que la mémoire partagée (MEM) ; et - identifier les données partagées avec le dispositif périphérique à l'aide de l'emplacement mémoire fourni pour chaque instruction de gestion de mémoire cache. 3. Procédé selon la revendication 2, dans lequel chaque instruction de gestion de mémoire cache est l'une parmi :- une instruction de nettoyage, conçue pour synchroniser la mémoire partagée avec la mémoire cache, - une instruction d'invalidation, conçue à l'origine pour marquer des données de la mémoire cache comme nécessitant un rafraîchissement depuis la mémoire partagée lors d'un accès subséquent, et - une instruction combinée de nettoyage et d'invalidation, conçue à l'origine pour synchroniser la mémoire partagée avec les données sales de la mémoire cache, puis invalider des données de la mémoire cache. 4. Procédé selon la revendication 3, comprenant, pour traiter une instruction d'invalidation, l'étape suivante : - rafraîchir la mémoire cache à partir de la mémoire partagée dès le traitement de l'instruction d'invalidation. 5. Procédé selon la revendication 3, comprenant, pour traiter une instruction combinée de nettoyage et d'invalidation, les étapes suivantes : - définir une mémoire de traçage (TRK) dans le domaine de modélisation de haut niveau, de même taille au moins que la mémoire partagée (MEM) ; - lors de l'exécution d'une instruction de nettoyage, dupliquer dans la mémoire de traçage les données résultantes transférées de la mémoire cache (10) vers la mémoire partagée (MEM) ; - lors de l'exécution d'une instruction d'invalidation, dupliquer dans la mémoire de traçage (TRK) les données résultantes transférées de la mémoire partagée (MEM) vers la mémoire cache (10) ; et - lors de l'exécution de l'instruction combinée de nettoyage et d'invalidation : comparer les données de la mémoire cache (10) aux données correspondantes de la mémoire de traçage (TRK), pour les données inégales, transférer les données de la mémoire cache dans la mémoire partagée et dans la mémoire de traçage, et - pour les données égales, transférer les données de la mémoire partagée dans la mémoire cache et dans la mémoire de traçage.