FR2945396A1 - Procede et dispositif d'analyse de la propagation de transactions dans un reseau multi-protocoles d'un systeme sur puce - Google Patents

Abstract

L'invention concerne un procédé de suivi d'une transaction dans un réseau (SOC) comprenant au moins un noeud (ND1, ND2, ND3) et au moins deux liaisons de transmission de données connectées au noeud et gérées conformément à au moins un protocole de transmission de données, le procédé comprenant des étapes consistant à capter des transactions lors de leur transmission par des liaisons du réseau, convertir les transactions captées dans un même format, mémoriser des transactions converties, de manière à pouvoir identifier une liaison où a été captée chaque transaction mémorisée, et comparer une transaction convertie et à corréler avec des transactions mémorisées, la transaction à corréler étant corrélée avec une transaction mémorisée si la comparaison révèle une correspondance entre les transactions à corréler et mémorisée.

Description

i

PROCEDE ET DISPOSITIF D'ANALYSE DE LA PROPAGATION DE TRANSACTIONS DANS UN RESEAU MULTI-PROTOCOLES D'UN SYSTEME SUR PUCE

La présente invention concerne la propagation de données au sein d'un réseau de transmission de données. La présente invention s'applique en particulier aux systèmes sur puce SOC (System On Chip) comportant au moins un noeud, deux liaisons de données gérées conformément à au moins un protocole de transmission de données. Les systèmes sur puce SOC (System On Chip) tendent de plus en plus à regrouper dans un même circuit intégré des composants matériels tels que des coeurs de processeur hétérogènes, des circuits spécialisés, et des mémoires, ainsi qu'une architecture de communication complexe appelée io "réseau sur puce" NOC, reliant entre eux ces composants. Un réseau sur puce comporte couramment plusieurs liaisons de données point à point reliant les composants matériels du système sur puce. Les liaisons de données entre les composants matériels d'un système sur puce peuvent être réalisées à l'aide de bus conformes à plusieurs protocoles tels que STBus et 15 VSTNOC de la société STMicroelectronics, AXI et AHB de la société ARM, OCP de la société SONICS, DTL et MTL de la société NXP, et Danube de la société ARTERIS. Un tel réseau peut transporter des données de différentes natures en respectant différentes contraintes de transport. Ainsi, des données de type voix ou sons nécessitent une faible latence et une bande 20 passante relativement faible. Des données de type séquences vidéo nécessitent également une faible latence, mais aussi une bande passante élevée. En revanche, le transport de données quelconques ne nécessite pas une latence élevée, et une bande passante variable. Quel que soit le type de données, une certaine qualité de service doit être garantie. 25 En raison de la complexité grandissante des systèmes sur puce, il est souhaitable de mettre en oeuvre d'outils de conception, de modélisation et de simulation permettant de tester un système à différentes étapes de conception, ceci afin de pouvoir valider le système à chacune de ces étapes. Il est également souhaitable de pouvoir tester un système une fois qu'il est 30 implanté totalement ou partiellement dans un circuit intégré.

Généralement le développement d'un système complexe tel qu'un système sur puce commence par une étape de définition de spécifications écrites en langage informel. Vient ensuite une étape de définition ou de sélection d'algorithmes permettant de répondre aux spécifications. Les algorithmes peuvent être définis à l'aide d'un langage de haut niveau tel que Matlab ou C++. La définition des algorithmes permet de passer à une étape de définition de modèles d'un premier niveau d'abstraction appelé "niveau transactionnel" TLM (Transaction Level Model) décrivant une architecture et donc spécifiant une répartition entre matériel et logiciel (définition des io composants matériels et des logiciels exécutés par les composants matériels). Le niveau transactionnel peut regrouper des modèles fonctionnels PV (Programmer View) et des modèles temporisés PVT (Programmer View + Timing). Un modèle fonctionnel permet par exemple de simuler un logiciel embarqué dans un composant matériel du système. Dans 15 un modèle fonctionnel, les transferts de données entre les composants matériels peuvent être simulés par un canal de communication unique idéal, c'est-à-dire non limité en débit. Les modèles temporisés permettent d'évaluer de manière précoce un choix d'architecture et de répartition de traitements entre matériels et logiciels. Afin de préciser des contraintes temporelles que 20 devront respecter les composants matériels du système, la taille des mots et le débit des canaux de communication sont fixés. Un modèle du niveau transactionnel peut être défini à l'aide d'un langage de modélisation de systèmes matériels tel que SystemC, permettant de représenter des composants matériels par des modules qui sont reliés entre eux par des 25 ports connectés à des canaux de communication. Les comportements des composants matériels et des logiciels sont décrits par des processus exécutant du code dans un langage de programmation tel que C++. Tous les composants matériels et logiciels d'un système peuvent ainsi être modélisés à l'aide de SystemC, quels que soient leur nature et leur niveau 30 d'abstraction. L'étape de développement suivante consiste à ajouter la notion d'horloge pour créer un modèle à la précision du cycle BCA (Bus Cycle Accurate) précisant le comportement du système à chaque cycle d'une horloge cadençant le système. Vient ensuite l'étape de définition du niveau transfert de registre RTL (Register Transfer Level) qui permet ensuite 35 une synthèse rapide et efficace d'un circuit intégré. Le niveau RTL définit la valeur de chaque bit à chaque coup d'horloge à l'aide d'un langage tel que VHDL ou Verilog. Le niveau RTL permet ensuite de définir des réseaux de portes logiques qui peuvent être traités par des outils de placement et de routage pour obtenir une structure à deux dimensions qui sert de base à la réalisation de masques de fabrication du circuit intégré. Il s'avère que les performances d'un réseau et notamment un réseau sur puce ont un impact significatif sur les performances du système intégrant le réseau. Il est donc souhaitable de pouvoir analyser le trafic du réseau, caractériser son utilisation, et en particulier suivre la propagation des io données dans le réseau. Il est souhaitable qu'une telle analyse soit réalisée suffisamment tôt durant la conception et le développement d'un système sur puce, ceci afin d'éviter d'avoir à remettre en cause des choix de conception effectués lors d'étapes précédentes de développement du système. Les niveaux d'abstraction TLM, BCA et RTL permettent une étude is approfondie des performances d'une architecture de système bien avant la mise en oeuvre du système et son implantation dans un circuit intégré. Le suivi de la propagation des données dans un système est généralement effectué à l'aide de sondes connectées à différentes liaisons du système, l'ensemble des composants du système n'étant pas nécessairement 20 modélisés dans un même niveau d'abstraction. Toutefois, les outils existants d'analyse ou de surveillance de réseau ne sont généralement compatibles qu'avec un seul protocole de réseau. Dans le cas d'un réseau complexe comportant des liaisons respectant des protocoles de transmission différents, il peut être difficile de corréler entre 25 eux des données ou des signaux prélevés par différentes sondes sur un chemin entre un composant initiateur et un composant cible. Il peut être également difficile de corréler un message de requête avec un message de réponse au message de requête. Par ailleurs, les données d'un message transmis dans le réseau peuvent être à certains moments réparties dans 30 plusieurs liaisons du réseau. II est alors difficile de suivre les données transmises et de déterminer qu'une donnée détectée par une sonde se retrouve à un autre moment avec d'autres données dans un même message. Il est donc souhaitable de pouvoir suivre la propagation de données 35 transmises dans un réseau multi-protocole et notamment un réseau sur puce multi-protocole, quelle que soit la complexité du réseau, et que les données transmises restent ensemble dans un message, ou soient à un autre instant, réparties dans plusieurs autres messages transmis par plusieurs liaisons différentes du réseau.

Un mode de réalisation concerne un procédé de suivi d'une transaction dans un réseau comprenant au moins un noeud et au moins deux liaisons de transmission de données connectées au noeud et gérées conformément à au moins un protocole de transmission de données. Selon un mode de réalisation, le procédé comprend des étapes consistant à : io capter des transactions lors de leur transmission par des liaisons du réseau, convertir les transactions captées dans un même format, mémoriser des transactions converties, de manière à pouvoir identifier une liaison où a été captée chaque transaction mémorisée, et comparer une transaction convertie et à corréler avec des transactions mémorisées, la transaction à 15 corréler étant corrélée avec une transaction mémorisée si la comparaison révèle une correspondance entre les transactions à corréler et mémorisée. Selon un mode de réalisation, le procédé comprend une étape de recherche parmi les transactions mémorisées de transactions captées de liaisons adjacentes à une liaison où a été captée la transaction à corréler, 20 l'étape de comparaison de la transaction à corréler étant limitée aux transactions trouvées. Selon un mode de réalisation, la comparaison de deux transactions comprend l'exécution sur des données des deux transactions d'un algorithme de comparaison sélectionné en fonction d'un type des liaisons où 25 ont été captées les deux transactions. Selon un mode de réalisation, les algorithmes de comparaison comprennent un algorithme qui fournit un résultat de corrélation positif lorsque le contenu des deux transactions est identique, et des algorithmes qui fournissent un résultat de corrélation positif lorsque le contenu de l'une 30 des deux transactions se trouve dans l'autre transaction. Selon un mode de réalisation, chaque transaction convertie est mémorisée dans une pile de stockage temporaire sélectionnée en fonction de la liaison où a été captée la transaction, une pile étant attribuée à chaque liaison où une transaction peut être captée.

Selon un mode de réalisation, le procédé comprend une étape de retrait d'une transaction mémorisée de la pile où elle est mémorisée lorsqu'elle a été entièrement corrélée avec une ou plusieurs autres transactions.

Selon un mode de réalisation, une transaction convertie comprend des données de début et de fin de transaction, des données de contenu de transaction, une information indiquant si la transaction est de type requête ou réponse, un identifiant de transaction, et si la transaction est du type réponse, un identifiant d'une transaction de type requête correspondant à la lo transaction de type réponse. Selon un mode de réalisation, seules les transactions de type requête sont mémorisées en vue d'une comparaison avec une autre transaction. Selon un mode de réalisation, le procédé comprend des étapes de corrélation d'une transaction de type réponse avec une transaction de type 15 requête mémorisée, et de suppression de la transaction de type requête mémorisée seulement si la transaction de type requête ne peut pas être propagée dans d'autres liaisons et si la liaison où a été captée la transaction de type requête ne peut pas transmettre une transaction de type réponse correspondant à la transaction de type requête avant que la requête soit 20 exécutée par le système. Un mode de réalisation concerne un dispositif de suivi d'une transaction dans un réseau comprenant au moins un noeud et au moins deux liaisons de transmission de données connectées au noeud et gérées conformément à au moins un protocole de transmission de données, le 25 dispositif comprenant des sondes connectées aux liaisons de transmission de données pour capter des transactions transmises par les liaisons. Selon un mode de réalisation, le dispositif est configuré pour mettre en oeuvre le procédé tel que défini précédemment. Selon un mode de réalisation, les sondes sont associées à un module 30 de conversion des transactions dans un même format. Selon un mode de réalisation, le dispositif comprend un ensemble de piles mémoire comportant une pile mémoire par sonde. Selon un mode de réalisation, le dispositif comprend au moins un module de sortie configurés pour recevoir des couples de transactions 35 corrélées et pour traiter ces informations afin d'effectuer une analyse de la propagation des transactions dans le réseau, et/ou enregistrer ces informations et/ou les afficher sur un écran de visualisation, et/ou pour déterminer des latences de transmission, et/ou élaborer des statistiques de transmission ou de charge du réseau, et/ou réaliser des traitements définis par l'utilisateur. Un mode de réalisation concerne un programme enregistré sur un support lisible et exécutable par un ordinateur, configuré pour mettre en oeuvre le procédé tel que défini précédemment, lorsqu'il est exécuté par un ordinateur.

Des exemples de réalisation de l'invention seront décrits dans ce qui suit, à titre non limitatif en relation avec les figures jointes parmi lesquelles : - la figure 1 représente schématiquement un système sur puce comportant un réseau sur puce multi-protocoles, et un dispositif de suivi de la propagation de transactions dans le réseau sur puce, - la figure 2 représente schématiquement un dispositif de suivi de la propagation de transactions, selon un mode de réalisation, - la figure 3 est une vue schématique d'un module de suivi de propagation de transactions du dispositif représenté sur la figure 2, - la figure 4 est une vue schématique d'un module de corrélation de transactions du module représenté sur la figure 3, - la figure 5 est une vue schématique d'un module de recherche de transactions du module représenté sur la figure 4, - la figure 6 représente un organigramme d'une séquence d'étapes 25 exécutées par le module de recherche de transaction, - la figure 7 représente une partie d'un système comportant deux liaisons auxquelles sont connectées des sondes, des signaux de transaction captés par les sondes, et l'état de piles de stockage temporaire de transactions, - la figure 8 représente une partie d'un système comportant plusieurs liaisons 30 auxquelles sont connectées des sondes, des signaux de transaction captés par les sondes, et l'état de piles de stockage temporaire de transactions. La figure 1 représente un système sur puce SOC comprenant des sondes PB connectées à un dispositif de suivi de la propagation de transactions TTS, selon un mode de réalisation. Le système SOC est dans 35 un état de conception comportant plusieurs parties définies à des niveaux d'abstraction différents. Par exemple, le système SOC comprend une première partie P1 au niveau d'abstraction à la précision du cycle d'horloge BCA et une seconde partie P2 au niveau d'abstraction transactionnel TLM. Le système SOC comprend des initiateurs de transactions MP1, SPC1, SPC2, SPC3, des cibles de transactions MM1, MM2, MM3, un réseau d'interconnexion INTC entre les initiateurs et les cibles, et des passerelles PSI, PS2, PS3 entre les initiateurs MP1, SPC2 et SPC3 et le réseau INTC. Le réseau INTC comprend des noeuds ND1, ND2, ND3. Le noeud ND1 est relié au noeud ND3 par l'intermédiaire d'une passerelle de bus BP1. Le io noeud ND2 est relié au noeud ND3 par l'intermédiaire d'une passerelle de bus BP2. L'initiateur MP1 est relié au noeud ND1 par l'intermédiaire de la passerelle PSI. L'initiateur SPC1 est connecté au noeud ND1. Les initiateurs SPC2 et SPC3 sont reliés au noeud ND2 par l'intermédiaire de passerelles PS2 et PS3. Le noeud ND3 est connecté aux cibles de transaction MM1, 15 MM2 et MM3. Chacune des liaisons entre les composants du système est placée sous surveillance d'une sonde PB qui écoute les signaux transmis par la liaison, les convertit dans un format défini par un protocole de transmission, et les transmet au dispositif US. L'initiateur MP1 est par exemple un coeur de microprocesseur simulé ou réel. Les initiateurs SPC1, 20 SPC2 et SPC3 sont par exemple des composants de traitement spécialisés, réels ou modélisés à des niveaux d'abstraction pouvant être différents. Ainsi l'initiateur SPC1 est par exemple un générateur de trafic qui génère un flux de transactions. Les initiateurs SPC2 et SPC3 sont par exemple modélisés par des modèles transactionnels respectivement de type PV et PVT. Les 25 cibles de transaction MM1, MM2 et MM3 sont par exemple des mémoires de différents modèles, réelles ou simulées. Les passerelles de bus BPI, BP2 sont par exemple des mémoires tampon. Dans la description qui suit, le terme "transaction" désigne un message de requête ou de réponse transmis entre deux composants d'un 30 système. La figure 2 représente le dispositif de suivi de la propagation de transactions US, selon un mode de réalisation. Le dispositif TTS comprend un module de suivi de transaction TPPM connecté d'un côté aux sondes PB, et de l'autre à des modules de sortie OUTM. Le module TPPM reçoit des 35 données de transaction transmises par les sondes PB. Le module TPPM dispose d'un accès à une base de données d'algorithmes ALDB et à des informations MINF relatives à la topologie du réseau du système SOC. La base de données ALDB contient des algorithmes exécutables sur les données d'un couple de transactions transmises dans le réseau du système s SOC pour déterminer si les deux transactions sont ou non corrélées. Les informations MINF définissent toutes les liaisons du réseau, c'est-à-dire notamment à quels composants du système elles sont connectées. Le module TPPM est configuré pour permettre de déterminer le chemin suivi par une transaction dans le réseau du système SOC en corrélant entre elles io par couple des transactions détectées par des sondes PB adjacentes dans le réseau. Dans ce qui suit, deux sondes ou deux liaisons sont considérées adjacentes dans le réseau lorsqu'il existe un chemin dans le réseau reliant ces deux sondes ou ces liaisons, ne comportant pas d'autre sonde entre celles-ci ou d'autre liaison où une transaction peu être captée. 15 Les sondes PB comprennent un module d'adaptation de transaction TAD pour convertir chaque transaction détectée dans un format unique quel que soit la liaison de transmission de données à laquelle la sonde est connectée et le protocole de transmission associé. Dans certains cas, notamment lorsque la sonde à été conçue par un tiers, le module TAD peut 20 être externe à la sonde. Le module TAD est alors adapté au format des données de sortie de la sonde. Les sondes PB comprennent également une machine à états finis FSM pour constituer des transactions à partir de signaux reçus. Le module TAD est configuré pour fournir chaque transaction captée 25 par la sonde PB sous la forme d'un ensemble de données comprenant un événement de début de requête ou de réponse, un contenu de requête ou de réponse, et un événement de fin de requête ou de réponse. Les événements de début et de fin de requête ou de réponse comprennent un identifiant de sonde PB, une date de détection de l'événement par la sonde 30 et un identifiant de transaction. L'événement de fin de réponse comprend également un identifiant de la transaction de requête correspondante. Un contenu de requête ou de réponse comprend un identifiant de sonde associé aux données de contenu de la requête ou de la réponse. Les données de contenu comprennent une taille globale en nombre de blocs de données 35 transférées, une longueur de données à transférer spécifiant la taille d'un bloc de données, et une adresse de destination des données transférées. Les données de contenu peuvent également comprendre des paramètres optionnels, notamment pour pouvoir prendre en compte des spécificités imposées par certains protocoles.

Des transactions peuvent être également injectées dans le module TPPM par un module de simulation de composant TRNP qui simule un composant du système SOC. A cet effet, le module TRNP est configuré pour transmettre au module TPPM des transactions provenant par exemple d'une base de transactions TRDB à des instants prédéfinis. io Les modules de sortie OUTM sont configurés pour recevoir des couples de transactions corrélées et leurs contenus respectifs, et pour traiter ces informations afin d'effectuer une analyse de la propagation des transactions dans le réseau, ou simplement enregistrer ces informations ou les afficher sur un écran de visualisation. Les modules OUTM peuvent ainsi is être configurés pour déterminer des latences de transmission, élaborer des statistiques de transmission ou de charge du réseau, ou réaliser d'autres traitements définis par l'utilisateur. La figure 3 représente un mode de réalisation du module de suivi de transaction TPPM. Le module TPPM comprend un module d'enregistrement 20 de transaction TREG, un ensemble de piles de stockage temporaire de transaction TRST, un module de corrélation de transactions TPLK, un module d'enregistrement de sonde PREG, et un module de traitement de données de configuration CPAR. Le module TPPM comprend également une base de données SARC contenant des données de description de 25 l'architecture du système SOC, ainsi qu'une base de données DARC qui contient notamment des spécifications de liaisons par défaut entre deux composants du système SOC, et en particulier entre deux sondes PB adjacentes. Les données de la base SARC indiquent notamment un algorithme de corrélation de transaction pour chaque couple de sondes 30 adjacentes du système SOC, cet algorithme étant défini dans la base ALDB. Lorsqu'une sonde n'est pas activée notamment pour des raisons de performance, un lien est créé dans la base de données SARC entre deux sondes actives adjacentes de la sonde non activée pour conserver les liaisons du réseau. 2945396 io

Le module PREG est configuré pour recevoir, par exemple durant une phase d'initialisation du dispositif US, des requêtes d'inscription de sondes PB contenant chacune un identifiant de sonde et un identifiant de liaison à laquelle la sonde est connectée. A la réception d'une requête d'inscription, le 5 module PREG crée une pile P1-Pn dans l'ensemble TRST pour la sonde à inscrire et demande au module CPAR d'enregistrer dans la base SARC de description de l'architecture du système SOC, l'identifiant de la sonde en relation avec l'identifiant de la liaison. Le module TREG reçoit des données de transaction TINF provenant lo des sondes PB. Si la transaction TINF est du type requête, le module TREG recherche dans l'ensemble TRST une pile P1-Pn attribuée à la sonde ayant transmis les données de transaction reçues. Si une pile a été attribuée à la sonde, le module TRST transfère les données de transaction au module TPLK et les enregistre dans la pile P1-Pn attribuée à la sonde ayant is transmis les données de transaction reçues. Les transactions de type réponse ne sont pas mémorisées dans une pile P1-Pn. Le module TPLK est configuré pour corréler chaque transaction à traiter, transmise par le module TREG avec une ou plusieurs transactions dites "parentes" préalablement mémorisées dans l'une des piles de 20 l'ensemble TRST. A cet effet, le module TPLK recherche dans l'ensemble TRST les transactions parentes pour chaque transaction reçue, à l'aide des données d'architecture du système SARC et de la base de données d'algorithmes de corrélation ALDB. Si une transaction parente est trouvée, le module TPLK la retire de la pile P1-Pn où elle a été trouvée, et transmet la 25 transaction reçue et la transaction parente trouvée aux modules de sortie OUTM. La figure 4 représente un mode de réalisation du module TPLK. Le module TPLK comprend un module de détermination LMD de sondes adjacentes à la sonde ayant émis la transaction TINF à traiter, un module de 30 recherche PTRS de transactions potentiellement parentes dans l'ensemble de piles TRST, et un module de sélection TRL de transactions parentes parmi les transactions potentiellement parentes. Le module LMD reçoit un identifiant de sonde PBN et recherche dans la base SARC toutes les sondes adjacentes à la sonde correspondant à 35 l'identifiant reçu PBN, c'est-à-dire des sondes reliées à cette dernière par un Il

chemin dans le système SOC ne comportant pas d'autres sondes. Le module PTRS reçoit les données de transaction TINF à traiter et des identifiants de sondes adjacentes APB fournis par le module LMD et lit dans la pile P1-Pn de chaque sonde adjacente trouvée la dernière transaction stockée dans la pile. Les transactions lues dans les piles P1-Pn sont comparées avec la transaction à traiter TINF pour détecter des corrélations. Si aucune corrélation n'a été trouvée, le module PTRS lit dans la pile P1-Pn de chaque sonde adjacente trouvée la transaction suivant la dernière transaction lue dans la pile, et ainsi de suite jusqu'à ce qu'une corrélation to soit détectée avec une transaction lue ou que toutes les transactions de la pile aient été lues. Les transactions lues et corrélées à la transaction à traiter TINF sont considérées comme des transactions parentes de celle-ci et sont fournies au module TRL. Normalement (sauf en cas de corrélation partielle), une et une seule transaction parente doit être trouvée pour chaque is transaction TINF reçue du module TREG. Si plusieurs transactions parentes sont extraites de l'ensemble TRST, le module TRL en sélectionne une qu'il fournit aux modules de sortie OUTM avec la transaction traitée TINF. La figure 5 représente un mode de réalisation du module PTRS. Le module PTRS comprend un module d'extraction de transactions TREX, un 20 module de recherche d'algorithme SALD, un module d'exécution d'algorithme ALEX, et un module de sélection de transaction TRT. Le module TREX reçoit un identifiant de chaque sonde adjacente APB de la sonde PBN ayant transmis la transaction à traiter TINF. Le module TREX exécute des étapes Si à S6 d'une séquence d'étapes représentée sur la 25 figure 6. A l'étape S1, le module TREX détermine tout d'abord, à partir des données de la transaction TINF, si la transaction est de type réponse. Si la transaction TINF est de type réponse, le module TREX détermine à l'étape S2 si la liaison à laquelle est connectée la sonde PB ayant transmis la transaction TINF est du type "Write Posting", c'est-à-dire si la liaison peut 30 transmettre une réponse à une requête avant que la requête soit propagée dans le réseau. Le module TREX peut à cet effet accéder à la base de données SARC. Si cette liaison n'est pas du type "Write Posting", le module TREX exécute les étapes S3 et S4 où il recherche la transaction de type requête correspondant à la transaction TINF dans la pile P1-Pn de la sonde 35 ayant transmis la transaction TINF, (étape S3). Si la transaction de type requête est trouvée dans la pile (étape S4), elle est retirée de la pile (étape S5). La transaction TINF est ensuite transmise aux modules de sortie OUTM sans être traitée, car il n'est pas nécessaire de corréler une transaction de type réponse avec une autre transaction puisqu'elle contient un identifiant de la requête correspondante. Si la transaction TINF est de type requête, le module TREX lit les données de transaction dans chaque pile P1-Pn correspondant aux identifiants de sonde reçus APB (étape S6). Chaque transaction extraite qui est ainsi potentiellement parente de la transaction TINF est fournie au lo module SALD. Le module SALD recherche dans la base ALDB un algorithme de corrélation de transaction en fonction des types de transaction et des types de liaisons auxquelles sont connectées la sonde adjacente APB ayant transmis la requête potentiellement parente et la sonde ayant transmis la transaction traitée TINF. Le module ALEX exécute l'algorithme sélectionné 15 sur les données de transaction TINF de la transaction traitée TINF et les données de la transaction potentiellement parente. Le module ALEX fournit ainsi au module TRT un résultat d'exécution d'un algorithme sur un couple de transactions. En parallèle, le module TRT reçoit les données de transaction de la transaction parente PTR sur laquelle l'algorithme a été 20 exécuté. Si le résultat de l'exécution de l'algorithme est positif, la transaction potentiellement parente est une transaction parente PTR et le module TRT fournit les données de la transaction parente PTR. Le module TREX retire alors la transaction parente PTR de la pile P1-Pn où elle a été lue. Un algorithme de corrélation de transaction consiste par exemple à 25 comparer deux à deux chaque bloc de donnée des deux transactions et à fournir un résultat de corrélation positif si tous les blocs des deux transactions sont strictement identiques. Un autre algorithme de corrélation peut consister à déterminer si la transaction TINF correspond à une partie de la transaction potentiellement parente. Si tel est le cas, les deux transactions 30 sont considérées comme corrélées et seule la partie de la transaction parente correspondant à la transaction TINF est retirée de la pile P1-Pn par le module TREX, ou est marquée comme corrélée. Un autre algorithme de corrélation peut consister à déterminer si la transaction potentiellement parente correspond à une partie de la transaction 35 traitée TINF. Dans ce cas, seule la partie de la transaction traitée correspondant à la transaction parente est considérée comme corrélée, et le module SALD doit effectuer une autre tentative de corrélation de la transaction traitée avec une autre transaction potentiellement parente, jusqu'à ce que tout le contenu de la transaction traitée ait été corrélé avec une transaction parente. Dans ce cas, le module TRL fournit autant de couples de la transaction traitée associée à une transaction parente qu'il y a de transactions parentes trouvées. La figure 7 représente une partie d'un système sur puce comportant trois composants Cl, C2, C3, une liaison entre les composants Cl et C2 et une liaison entre les composants C2 et C3. Chacune des deux liaisons est connectée à une sonde PB1, PB2, les sondes étant connectées au dispositif de suivi de la propagation de transaction US. La figure 7 représente également des chronogrammes de signaux de transaction captés par les sondes PB1, PB2, ainsi que le contenu de piles P1, P2 de l'ensemble TRST attribuées aux sondes PB1 et PB2, à des instants successifs t1, t2, t3 et t4. Le composant Cl émet une transaction de type requête d'écriture REQ1 au composant C2. A la réception de la transaction REQ1, le composant C2 transmet en réponse au composant Cl une transaction de type réponse REP1 et propage la transaction REQ1 vers le composant C3 sous la forme d'une nouvelle transaction de type requête d'écriture REQ2 reprenant le contenu de la requête REQ1. A la suite de la réception de la transaction REQ2, le composant C3 exécute la requête et transmet en réponse au composant C2 une transaction de type réponse REP2. La sonde PB1 capte successivement les transactions REQ1 et REP1 aux instants tl et t2, et la sonde PB2 capte successivement les transactions REQ2 et REP2 aux instants t3 et t4. Normalement la réponse REP1 devrait être émise par le composant C2 seulement après avoir reçu la réponse REP2, puisque la réponse REP1 devrait contenir les informations de la réponse REP2 pour pouvoir informer le composant Cl sur le réel succès ou échec de l'exécution de la requête REQ1. Pour des raisons de rapidité d'exécution, certains systèmes adoptent le fonctionnement représenté sur la figure 7 consistant pour le composant intermédiaire, ici C2 à répondre au composant émetteur de la requête, ici Cl, dès qu'il reçoit la requête. Il en résulte une violation du principe de causalité. Ainsi, les flèches épaisses en trait continu sur la figure 7 représentent des liens de causalité entre transactions, tandis que la flèche épaisse en trait discontinu représente un lien de causalité violé. Pour pouvoir prendre en compte cette violation du principe de causalité, la liaison entre les composants Cl et C2 est configurée du type "Write Posting" dans la base SARC, tandis que la liaison entre les composants C2 et C3 ne l'est pas. II en résulte que lorsque le dispositif TTS traite la transaction REP1, il ne retire pas la transaction REQ1 de la pile P1 de la sonde PB1, conformément à la séquence représentée sur la figure 6. De cette manière, lorsque le dispositif traite la transaction REQ2, celle-ci peut être corrélée par le dispositif US avec la transaction REQ1. La transaction REQ1 est ainsi retirée de la pile P1 seulement après réception par la sonde PB2 de la requête REQ2 qui est insérée dans la pile P2. Lorsque le dispositif traite la transaction REP2, celle-ci est corrélée avec la transaction REQ2 grâce au fait qu'une transaction de réponse inclut un identifiant de la transaction de requête correspondante. La transaction REQ2 est alors retirée de la pile P2. Il est à noter que si la transaction REQ2 est captée par la sonde PB2 avant que la sonde REP1 soit captée par la sonde PB1, la transaction REQ2 aura déjà été corrélée avec la transaction REQ1 et donc la transaction REQ1 ne sera plus dans une pile lorsque la transaction REP1 sera traitée.

La figure 8 représente une partie d'un système sur puce comportant quatre composants C4, C5, C6, C7, et un noeud de réseau ND4 auquel les quatre composants sont connectés, chacune des liaisons entre un composant C4-C7 et le noeud du réseau ND4 étant connectée à une sonde PB4, PB5, PB6, PB7. Les sondes PB4-PB7 sont considérées adjacentes dans la base SARC étant donné qu'aucune autre sonde n'est disposée entre elles. La figure 8 illustre une corrélation entre une première transaction et plusieurs transactions ultérieures dont les contenus sont à corréler avec une partie du contenu de la première transaction. A cet effet, la figure 8 représente également des chronogrammes de signaux de transaction captés par les sondes PB4-PB7, ainsi que le contenu de piles P4, P5, P6, P7 de l'ensemble TRST attribuées aux sondes PB4-PB7, à des instants successifs t5, t6, t7 et t8. Par souci de clarté de la figure, seules les piles P4-P7 dont le contenu est modifié sont présentées à chacun de ces instants. A l'instant t5, la sonde PB4 capte sur la liaison entre le composant C4 35 et le noeud ND4 une transaction comportant trois blocs de données B1, B2, B3 de tailles quelconques. La transaction B1-B3 est insérée dans la pile P4 de la sonde PB4. A l'instant t6, la sonde PB6 entre le composant C6 et le noeud ND4 capte une transaction contenant le bloc B3 qui est insérée dans la pile P6 de la sonde PB6. Le traitement de la transaction contenant le bloc B3 par le dispositif TTS aboutit à la corrélation de celle-ci avec le bloc B3 de la transaction B1-B3 mémorisée dans la pile P4. Par conséquent, seul le bloc B3 est retiré de la pile P4. A l'instant t7, la sonde PB5 entre le composant C5 et le noeud ND4 capte une transaction contenant le bloc B1 qui est insérée dans la pile P5 de la sonde PB5. La transaction contenant le io bloc B1 est ensuite corrélée par le dispositif US avec le bloc B1 de la transaction B1-B3 mémorisée dans la pile P4. Le bloc B1 est donc retiré de la pile P4. A l'instant t8, la sonde PB7 entre le composant C7 et le noeud ND4 capte une transaction contenant le bloc B2, qui est insérée dans la pile P7 de la sonde PB7. La transaction contenant le bloc B2 est ensuite corrélée 15 par le dispositif TTS avec le bloc B2 de la transaction B1-B3 mémorisée dans la pile P4. Le bloc B2 est donc finalement retiré de la pile P4. La corrélation partielle d'une transaction avec une partie d'une autre transaction stockée dans une pile de l'ensemble TRST est configurée grâce à un algorithme prévu dans la base ALDB et attribué aux liaisons auxquelles sont 20 connectées les sondes PB1-PB4. II est à noter qu'au lieu de retirer un bloc corrélé d'une transaction dans une pile, une marque de corrélation peut être mémorisée dans la pile en correspondance avec chaque bloc de la transaction. A chaque corrélation d'un bloc la marque correspondant au bloc est mise à jour dans la pile et 25 lorsque tous les blocs de la transaction sont marqués corrélé, la transaction est retirée de la pile. Le dispositif US peut être réalisé sous la forme d'un logiciel exécuté par un ordinateur simulant ou connecté au système SOC à tester, ou bien simulant une partie du système et connecté à d'autres parties du système.

30 II apparaîtra clairement à l'homme de l'art que la présente invention est susceptible de diverses variantes de réalisation et diverses applications. En particulier, l'invention n'est pas limitée aux systèmes sur puce, mais peut être appliquée à tout système comportant un réseau de transmission de données. Par ailleurs, il n'est pas nécessaire de mémoriser les transactions 35 dans des piles attribuées chacune à une liaison du système à tester. II suffit en effet de mémoriser chaque transaction à corréler, de manière à pouvoir déterminer sur quelle liaison une transaction mémorisée a été captée, par exemple en association avec un identifiant de liaison ou de sonde. Il n'est pas non plus nécessaire, bien que cela puisse être moins performant, de limiter la recherche des transactions parentes aux transactions captées dans les liaisons adjacentes à la liaison où a été captée la transaction à corréler. Dans certains systèmes simples, un seul algorithme de comparaison de transactions peut être suffisant. Il n'est donc pas nécessaire de prévoir une étape de sélection d'un tel algorithme pour détecter une corrélation lo entre deux transactions. La présente invention n'est pas non plus limitée à un format particulier de transmission aux modules de sortie OUTM des informations relatives aux corrélations détectées. Ainsi un lien de corrélation entre deux transactions peut être transmis aux modules OUTM en fournissant successivement toutes 1s les informations relatives à une transaction et à la transaction parente, comme décrit précédemment, ou bien en fournissant simplement les données relatives à une transaction et un identifiant de la transaction parente, laquelle a été préalablement transmise aux modules de sortie. Il peut également être prévu de mémoriser toutes les transactions captées 20 dans une mémoire accessible aux modules de sortie, et de ne transmettre aux modules de sortie que des couples d'identifiants de transactions corrélées entre elles. Par ailleurs, la présente invention n'est pas limitée aux algorithmes de comparaison de transaction précédemment décrits. En effet, il peut être 25 prévu d'autres algorithmes de comparaison de transaction, notamment des algorithmes adaptés au contenu de transactions particulières. La présente invention n'est pas non plus limitée à un format de transaction particulier, la structure de ce format résultant d'un choix arbitraire. 30

Claims (14)

1. REVENDICATIONS1. Procédé de suivi d'une transaction dans un réseau comprenant au moins un noeud (ND1, ND2, ND3) et au moins deux liaisons de transmission de données connectées au noeud et gérées conformément à au moins un protocole de transmission de données, caractérisé en ce qu'il comprend des étapes consistant à : capter des transactions lors de leur transmission par des liaisons du réseau, convertir les transactions captées dans un même format, mémoriser des transactions converties, de manière à pouvoir io identifier une liaison où a été captée chaque transaction mémorisée, et comparer une transaction convertie et à corréler avec des transactions mémorisées, la transaction à corréler étant corrélée avec une transaction mémorisée si la comparaison révèle une correspondance entre les transactions à corréler et mémorisée. 15
2. 2. Procédé selon la revendication 1, comprenant une étape de recherche parmi les transactions mémorisées de transactions captées de liaisons adjacentes à une liaison où a été captée la transaction à corréler, l'étape de comparaison de la transaction à corréler étant limitée aux 20 transactions trouvées.
3. 3. Procédé selon la revendication 1 ou 2, dans lequel la comparaison de deux transactions comprend l'exécution sur des données des deux transactions d'un algorithme de comparaison sélectionné en fonction d'un 25 type des liaisons où ont été captées les deux transactions.
4. 4. Procédé selon la revendication 3, dans lequel les algorithmes de comparaison comprennent un algorithme qui fournit un résultat de corrélation positif lorsque le contenu des deux transactions est identique, et 30 des algorithmes qui fournissent un résultat de corrélation positif lorsque le contenu de l'une des deux transactions se trouve dans l'autre transaction. 17
5. 5. Procédé selon l'une des revendications 1 à 4, dans lequel chaque transaction convertie est mémorisée dans une pile de stockage temporaire (P1-Pn) sélectionnée en fonction de la liaison où a été captée la transaction, une pile étant attribuée à chaque liaison où une transaction peut être captée.
6. 6. Procédé selon la revendication 5, comprenant une étape de retrait d'une transaction mémorisée de la pile (P1-Pn) où elle est mémorisée lorsqu'elle a été entièrement corrélée avec une ou plusieurs autres transactions. i0
7. 7. Procédé selon l'une des revendications 1 à 6, dans lequel une transaction convertie comprend des données de début et de fin de transaction, des données de contenu de transaction, une information indiquant si la transaction est de type requête ou réponse, un identifiant de 15 transaction, et si la transaction est du type réponse, un identifiant d'une transaction de type requête correspondant à la transaction de type réponse.
8. 8. Procédé selon la revendication 7, dans lequel seules les transactions de type requête sont mémorisées en vue d'une comparaison 20 avec une autre transaction.
9. 9. Procédé selon l'une des revendications 7 et 8, comprenant des étapes de corrélation d'une transaction de type réponse avec une transaction de type requête mémorisée, et de suppression de la transaction 25 de type requête mémorisée seulement si la transaction de type requête ne peut pas être propagée dans d'autres liaisons et si la liaison où a été captée la transaction de type requête ne peut pas transmettre une transaction de type réponse correspondant à la transaction de type requête avant que la requête soit exécutée par le système. 30
10. 10. Dispositif de suivi d'une transaction dans un réseau comprenant au moins un noeud (ND1, ND2, ND3) et au moins deux liaisons de transmission de données connectées au noeud et gérées conformément à au moins un protocole de transmission de données, le dispositif comprenant5 des sondes (PB) connectées aux liaisons de transmission de données pour capter des transactions transmises par les liaisons, caractérisé en ce qu'il est configuré pour mettre en oeuvre le procédé selon l'une des revendications 1 à 9.
11. 11. Dispositif selon la revendication 10, dans lequel les sondes (PB) sont associées à un module de conversion des transactions dans un même format. 10
12. 12. Dispositif selon la revendication 10 ou 11, comprenant un ensemble de piles mémoire (TRST) comportant une pile mémoire par sonde (PB).
13. 13. Dispositif selon l'une des revendications 10 à 12, comprenant au 15 moins un module de sortie (OUTM) configurés pour recevoir des couples de transactions corrélées (TINF, PTR) et pour traiter ces informations afin d'effectuer une analyse de la propagation des transactions dans le réseau, et/ou enregistrer ces informations et/ou les afficher sur un écran de visualisation, et/ou pour déterminer des latences de transmission, et/ou 20 élaborer des statistiques de transmission ou de charge du réseau, et/ou réaliser des traitements définis par l'utilisateur.
14. 14. Programme enregistré sur un support lisible et exécutable par un ordinateur, 25 caractérisé en ce qu'il est configuré pour mettre en oeuvre le procédé selon l'une des revendications 1 à 9, lorsqu'il est exécuté par un ordinateur.5