FR2870369A1 - Interface de bus virtuel et systeme et procede associes - Google Patents

Abstract

Mode de mise en oeuvre de système à titre d'exemple (400) comprenant un circuit logique de détection (440) facilitant l'identification du fait qu'une transaction point à point (430) est une transaction qui n'est pas mise en oeuvre par micro-architecture et un circuit logique de suivi (450) facilitant le suivi de la transaction et des paquets attenants par l'intermédiaire d'une interface de bus virtuel (410) et facilitant, de même, la production d'une donnée d'erreur associée à la transaction non-mise en oeuvre par micro-architecture.

Description

INTERFACE DE BUS VIRTUEL ET SYSTÈME ET PROCÉDÉ ASSOCIÉS

Des systèmes informatiques peuvent comprendre des composants informatiques qui sont connectés de façon fonctionnelle. Ces composants informatiques peuvent être connectés, de façon fonctionnelle, par exemple, à l'aide d'un bus et/ou par l'intermédiaire d'un(des) connecteur(s) en liaisons point à point (P2P). Des composants qui sont connectés, de façon fonctionnelle, à l'aide d'un bus sont, de façon usuelle, "à l'écoute" de sensiblement chaque demande placée sur le bus, "entendent" sensiblement chaque réponse sur le bus et essaient de communiquer sur le bus. Afin de faciliter l'écoute, l'audition, la communication et similaire, diverses techniques, synchronisations, protocoles et ainsi de suite de communication sur bus se sont développées. Ainsi, une transaction comme une lecture de données dans un système de modèle à bus peut comprendre la production et le contrôle de diverses phases (par exemple, l'arbitrage, les demandes, la surveillance de trafic, des données) et l'envoi/réception de divers signaux lors de ces phases.

Des composants informatiques qui sont connectés, de façon fonctionnelle, par des liaisons P2P fonctionnent de façon sensiblement différente de ceux connectés par un bus.

Des demandes et des réponses sont acheminées, de façon plus exclusive, entre des composants d'envoi et de réception.

Ainsi, une certaine partie des composants informatiques connectés, de façon fonctionnelle, peuvent rencontrer des paquets associés à une transaction. Des paquets peuvent être divisés en plus petites unités connues comme des "flits". Une transaction similaire à une lecture de données peut être effectuée en envoyant et en recevant des paquets et/ou des "flits" entre divers composants de source et de destination. Les actions effectuées pour envoyer, recevoir et/ou acheminer des paquets afin d'effectuer une transaction P2P peuvent être différentes de celles engagées pour effectuer une transaction correspondante de modèle à bus.

Dans des environnements comme la vérification de processeur et le multitraitement hybride, certains composants peuvent être connectés par un bus comme un bus frontal (FSB) et d'autres composants peuvent être connectés par des liaisons P2P. Des composants connectés par FSB effectuent certaines actions de certaines façons. Par exemple, des messages prévus pour un composant peuvent être diffusés sur le FSB, visualisés par tous les composants connectés de façon fonctionnelle au FSB et traités par des composants cibles. Des composants connectés par liaison P2P effectuent certaines actions selon certaines autres façons.

Par exemple, des paquets peuvent être transmis entre des composants spécifiques avec un "agent de la circulation" à barres croisées responsable de la direction des paquets/"flits". Comme, à la fois, des connexions FSB et des connexions P2P présentent des forces et des faiblesses, il n'est pas surprenant que certains systèmes informatiques soient connectés en FSB alors que d'autres sont configurés en P2P. Dans certains exemples, un système multiprocesseur ou un autre grand système peut même comprendre des composants qui sont connectés à l'aide de chacun des procédés.

Ces dernières années, des outils ont été développés pour concevoir, analyser, tester et ainsi de suite des systèmes utilisant un FSB. D'autres outils ont été développés pour concevoir, analyser, tester et ainsi de suite des systèmes utilisant des liaisons P2P. Comme les deux systèmes sont fondamentalement différents, un outil connu comme une interface de bus virtuel (VBI) développée pour faciliter la corrélation et/ou la comparaison des résultats à partir des différents outils. Une VBI facilite la production de transactions du type à bus à partir de transactions P2P. Cela peut faciliter, à son tour, une communication entre des systèmes utilisant un modèle à bus et des systèmes utilisant un modèle à liaison P2P. Mais, comme décrit ci-dessus, la structure de conception et logique des transactions P2P diffère fondamentalement de celle des transactions à bus.

Une VBI peut être utilisée lors d'une conception de processeur afin de faciliter la corrélation et/ou la vérification des actions d'outil de simulation. Un premier outil de conception de processeur comme un outil de simulation de langage de transfert de registre à modèle par bus peut être disponible. Un second outil de conception de processeur comme un simulateur de modèle à liaison P2P de langage de plus haut niveau peut être, de même, disponible.

Une VBI peut faciliter la comparaison des sorties des deux outils de conception de processeur. Par exemple, des transactions à partir de l'outil de modèle à liaison P2P peuvent être utilisées comme des entrées sur une VBI qui produiront des transactions correspondantes de modèle à bus. Ainsi, des transactions survenant dans l'outil de modèle P2P peuvent être comparées à des transactions survenant dans l'outil de modèle à bus, procurant une plus grande sécurité dans les résultats de simulation.

Les dessins annexés qui sont incorporés et font partie de la description illustrent divers systèmes, procédés et ainsi de suite à titre d'exemples illustrant divers modes de mise en oeuvre des aspects de l'invention.

On remarquera que les délimitations illustrées d'élément (par exemple, des pavés, des groupes de pavés ou d'autres formes) sur les figures représentent un exemple des délimitations. L'homme du métier remarquera qu'un élément peut être conçu sous la forme de plusieurs éléments ou que plusieurs éléments peuvent être conçus sous la forme d'un seul. Un élément illustré comme un composant interne d'un autre élément peut être mis en oeuvre sous la forme d'un composant externe et vice versa. De plus, des éléments peuvent ne pas être tracés à l'échelle.

Sur les dessins: la Figure 1 illustre une configuration à titre 5 d'exemple de modèle à bus de composants informatiques; la Figure 2 illustre une configuration à titre d'exemple de modèle P2P de composants informatiques; la Figure 3 illustre un environnement à titre d'exemple dans lequel une interface de bus virtuel peut manier des transactions mises en oeuvre de façon non-microarchitecturale; la Figure 4 illustre un système à titre d'exemple pour manier des transactions mises en oeuvre de façon nonmicro-architecturale; la Figure 5 illustre un trajet de message à titre d'exemple associé à une VBI; la Figure 6 illustre une VBI à titre d'exemple configurée pour manier des transactions mises en oeuvre de façon non-micro-architecturale; la Figure 7 illustre un procédé à titre d'exemple pour le maniement de transactions mises en oeuvre de façon nonmicro-architecturale; la Figure 8 illustre un environnement informatique à titre d'exemple dans lequel des systèmes et des procédés à titre d'exemples, illustrés dans notre cas, peuvent fonctionner; et la Figure 9 illustre une interface de programmation d'application à titre d'exemple (API).

Certains systèmes et procédés à titre d'exemples décrits, dans notre cas, concernent une VBI produisant des transactions du type à bus à partir de transactions P2P en maniant des transactions mises en oeuvre de façon nonmicro-architecturale. Un processeur peut essayer de communiquer avec d'autres processeurs, mémoires et ainsi de suite par l'intermédiaire d'une liaison P2P. Un moteur de protocole de noyau (CPE) peut servir d'interface entre le processeur et la liaison P2P. Des décisions de microarchitecture concernant le processeur et/ou le système associé au processeur peuvent créer une situation dans laquelle certaines des transactions P2P possibles pouvant être maniées par une liaison P2P ne doivent pas être émises par le CPE et ainsi, ne doivent pas exister sur la liaison P2P. Si ces types de transactions sont émis par le CPE, une VBI reconfigurée interceptant des transactions initialement prévues pour une liaison P2P peut alors manier ces transactions mises en oeuvre de façon non-microarchitecturale. De plus, des transactions comprenant des transactions non-mises en oeuvre peuvent survenir sur la VBI à partir d'autres positions comme d'autres agents sur un réseau P2P, d'autres noyaux RTL, d'autres dispositifs RTL, un agent simulé et ainsi de suite. Des transactions mises en oeuvre de façon non-micro-architecturale seront référencées par la suite comme des "transactions non-mises en oeuvre".

Dans un système conçu pour communiquer par l'intermédiaire d'un protocole de point à point dans lequel une VBI traite les transactions de protocole de point à point et/ou des paquets en transactions de modèle à bus, il peut survenir des discordances entre les types de transactions et/ou de paquets que peut manier la VBI, les types de transactions et/ou de paquets que la VBI est prévue de manier, les types de transactions et/ou de paquets que le système est configuré pour produire et les types de transactions et/ou de paquets que produit, en réalité, le système. Par exemple, une spécification de protocole P2P peut lister vingt types de transactions tandis qu'un système développé peut ne mettre en oeuvre que douze des vingt types de transactions. Ainsi, une VBI usuelle peut être configurée pour ne traiter que les douze types mis en oeuvre. Si une VBI usuelle traitant des transactions P2P dans des transactions du type à bus rencontre un des huit types de transactions ne sont pas mis en oeuvre, elle peut entrer dans un état d'erreur ou ne pas traiter correctement la transaction.

Ainsi, des systèmes et des procédés décrits, dans notre cas, à titre d'exemple facilitent la reconfiguration et/ou la charge avec une VBI pour traiter des transactions non-mises en oeuvre comme des erreurs. Des erreurs peuvent survenir pour diverses raisons. Par exemple, une transaction peut être injectée dans un processus de test afin de voir comment un processeur, une CPE ou une liaison P2P réagit, un ingénieur peut faire une erreur mentale et programmer un processeur pour produire une transaction qu'il est incapable physiquement de produire, des bits peuvent être endommagés et ainsi, un 0 peut être changé en un 1, provoquant une modification du type de transaction, par exemple d'un OxAl (mis en oeuvre) en OxAO (non-mis en oeuvre) et similaire. Tandis que trois cas sont décrits, on remarquera que d'autres cas peuvent conduire à des transactions non-mises en oeuvre et recues par une VBI. Des systèmes et des procédés à titre d'exemples facilitent une identification par une VBI d'une transaction non-mise en oeuvre, établissant des critères d'achèvement pour celle-ci, la traitant et la suivant par l'intermédiaire de la VBI puis lorsque les critères d'achèvement sont satisfaits, effectuant des actions comme un rapport d'erreur et la libération d'un identificateur de transaction pour une réutilisation.

Ce qui suit comprend des définitions de termes sélectionnés utilisés dans notre cas. Les définitions comprennent divers exemples entrant dans le cadre d'un terme. Les exemples ne sont pas prévus pour être limitatifs. A la fois, des formes au singulier et au pluriel peuvent entrer dans les définitions.

Comme utilisé dans ce dépôt, le terme "composant informatique" se réfère à une entité d'ordinateur, soit un matériel, soit un microprogramme, soit un logiciel ou une combinaison de ceux-ci. Des composants informatiques peuvent comprendre par exemple un processus tournant sur un processeur, un processeur, un objet, un exécutable, une unité d'exécution, un programme, un ordinateur et ainsi de suite. Des composants informatiques peuvent être localisés sur un ordinateur et/ou répartis entre deux ou plusieurs ordinateurs.

Un "support lisible par ordinateur", tel qu'utilisé dans notre cas, se réfère à un support participant à la fourniture directe ou indirecte de signaux, d'instructions et/ou de données à un composant informatique. Un support lisible par ordinateur peut prendre diverses formes comme des supports non volatiles, des supports volatiles, des supports de transmission et similaires. Des supports non volatiles peuvent comprendre, par exemple, des disques optiques ou magnétiques. Des supports volatiles peuvent comprendre par exemple des disques optiques ou magnétiques, une mémoire dynamique et ainsi de suite. Des supports de transmission peuvent comprendre, par exemple, des câbles coaxiaux, des fils de cuivre et des câbles à fibre optique.

Des supports de transmission peuvent prendre, de même, la forme d'un rayonnement électromagnétique comme celui généré lors de communications de données par ondes radio et par infrarouge ou peuvent prendre la forme d'un ou plusieurs groupes de signaux. Des formes usuelles d'un support lisible par ordinateur comprennent des disquettes souples, des disques durs, des bandes magnétiques, des cédéroms, des RAMs, des ROMs, des EPROMs, d'autres composants ou cartes de mémoire, des barrettes de mémoire, des ondes/impulsions de porteuse et d'autres supports à partir desquels un ordinateur, un processeur ou un autre dispositif electronique peut effectuer une lecture. Des signaux utilisés pour propager des instructions ou un autre logiciel sur un réseau comme Internet peuvent etre considérés comme un "support lisible par ordinateur".

Un "stockage de données", tel qu'utilisé dans notre cas, se réfère à une entité physique et/ou logique pouvant stocker des données. Un stockage de données peut être, par exemple, une base de données, un tableau, un fichier, une liste, une file d'attente, un segment de mémoire, une mémoire, un registre et ainsi de suite. Un stockage de données peut se trouver dans une entité logique et/ou physique et/ou peut être réparti entre deux ou plusieurs entités logiques et/ou physiques.

Un "circuit logique", tel qu'utilisé dans notre cas, comprend sans y être limité un matériel, un microprogramme, un logiciel et/ou leurs combinaisons effectuant une(des) fonction(s) ou une(des) action(s) et/ou provoquant une fonction ou une action d'un autre circuit logique, procédé et/ou système. Par exemple, un circuit logique peut comprendre un microprocesseur commandé par logiciel, un circuit logique discret comme un circuit intégré d'application spécifique (ASIC), un dispositif logique programmé, un dispositif de mémoire contenant des instructions et ainsi de suite. Un circuit logique peut comprendre une ou plusieurs portes, des combinaisons de portes ou d'autres composants de circuit. Un circuit logique peut être, de même, entièrement mis en oeuvre sous forme logicielle. Lorsque plusieurs circuits logiques sont décrits, il peut être possible d'incorporer les multiples circuits logiques en un circuit logique physique. De même, lorsqu'un seul circuit logique est décrit, il peut être possible de répartir ce seul circuit logique entre plusieurs circuits logiques physiques.

Une "connexion fonctionnelle" ou une connexion selon laquelle des entités sont "connectées de façon fonctionnelle" ou "peuvent être connectées de façon fonctionnelle" est une connexion dans laquelle des signaux, des communications physiques et/ou des communications logiques peuvent être envoyés et/ou reçus. De façon usuelle, une connexion fonctionnelle comprend une interface physique, une interface électrique et/ou une interface de données mais une connexion fonctionnelle peut comprendre différentes combinaisons de ces ou d'autres types de connexions suffisantes pour permettre une commande de fonctionnement. Par exemple, deux entités peuvent être connectées, de façon fonctionnelle, en étant capables de communiquer des signaux l'une vers l'autre directement ou par l'intermédiaire d'un ou plusieurs composants informatiques intermédiaires, circuits logiques et ainsi de suite. Des canaux de communication logiques et/ou physiques peuvent être utilisés pour créer une connexion fonctionnelle.

Un "signal", tel qu'utilisé dans notre cas, comprend sans y être limité un ou des signaux électriques ou optiques, un ou des signaux analogiques ou numériques, des données, une ou des instructions d'ordinateur ou de processeur, un ou des messages, un bit ou une suite binaire ou d'autres moyens pouvant être reçus, transmis et/ou détectés.

Un "logiciel", tel qu'utilisé dans notre cas, se réfère à des instructions d'ordinateur ou de processeur pouvant être lues, interprétées, compilées et/ou exécutées pour amener un ordinateur, un processeur ou un autre dispositif électronique à effectuer une(des) action(s) et/ou à se comporter d'une façon désirée. Les instructions peuvent être mises en oeuvre sous diverses formes comme des sous programmes, des algorithmes, des modules, des procédés, des unités d'exécution et/ou des programmes comprenant des applications ou des instructions séparées à partir de librairies de liaison dynamique. Le logiciel peut être mis en oeuvre sous diverses formes exécutables et/ou chargeables comprenant sans y être limitées un programme autonome, un appel de fonction (en local et/ou à distance), un servlet Java, une mini- application, des instructions stockées dans une mémoire, une partie d'un système d'exploitation ou d'autres types d'instructions exécutables. Un logiciel peut être situé dans un circuit logique et/ou réparti entre deux ou plusieurs circuits logiques en communication, en coopération et/ou en traitement en parallèle et peut ainsi être chargé et/ou exécuté en série, en parallèle, en parallèle dense et d'autres façons.

Un logiciel adapté pour la mise en oeuvre des divers composants des systèmes et des procédés à titre d'exemples décrits, dans notre cas, comprennent des langages et des outils de programmation comme le Java, le Pascal, le C#, le C++, le C, le CGI; le Perl, le SQL, les APis, les SDKs, un assembleur, un microprogramme, un microcode et ainsi de suite. Un logiciel, que ce soit un système complet ou un composant d'un système, peut être mis en oeuvre sous la forme d'un article de fabrication et peut être maintenu ou prévu comme partie d'un support lisible par ordinateur, comme défini précédemment. Un logiciel peut être transmis sous la forme de signaux sur un réseau ou un autre support de communication. Ainsi, dans un exemple, un support lisible par ordinateur prend la forme de signaux représentant un logiciel qui est téléchargé d'un serveur Web vers un utilisateur. Selon un autre exemple, le support lisible par ordinateur prend la forme d'un logiciel tel que conservé par le serveur Web.

Certaines parties de la description détaillée suivante sont présentées en termes d'algorithmes et de représentations symboliques des opérations sur des bits de données dans une mémoire. Ces descriptions d'algorithmes et ces représentations symboliques sont les moyens utilisés par l'homme du métier pour transmettre la substance de leurs travaux. Un algorithme est, dans notre cas et en général, conçu sous la forme d'une séquence d'opérations produisant un résultat tangible, concret dans le monde réel. Les opérations peuvent comprendre des manipulations physiques d'éléments physiques. Les quantités physiques peuvent prendre la forme de signaux électriques ou magnétiques pouvant être stockés, transférés, combinés, comparés et dans les autres cas, manipulés dans un circuit logique, une mémoire d'ordinateur et similaires.

Il s'est avéré pratique à certains moments, principalement pour des raisons d'usage commun, de faire référence à ces signaux comme des bits, des valeurs, des éléments, des symboles, des caractères, des termes, des nombres ou similaires. Il doit cependant venir à l'esprit que ces termes et des termes similaires doivent être associés aux quantités physiques adaptées et sont simplement des étiquettes pratiques appliquées à ces quantités. On remarque que dans la description, des termes comme un traitement, un calcul, une estimation, une détermination, un affichage ou similaires se réfèrent à des actions et à des processi d'un composant d'ordinateur, d'un circuit logique, d'un processeur ou d'un dispositif électronique similaire manipulant et transformant des données représentées sous la forme de quantités physiques (électroniques).

La Figure 1 illustre une configuration de modèle de bus 100 à titre d'exemple de composants d'ordinateur. Un bus 110 comme un bus frontal peut connecter des composants comme les composants 120, 130, 140 et 150. Les composants peuvent être, par exemple, des processeurs dans un système multiprocesseur, des mémoires, des mémoires caches et ainsi de suite. Tandis que quatre composants sont illustrés, on devra remarquer qu'un plus grand et/ou plus petit nombre de composants peuvent être connectés. Une transaction sur le bus 110 peut comprendre, par exemple, deux parties fondamentales comme une partie de demande et une partie de réponse. La partie de demande peut émettre une demande devant être satisfaite et la partie de réponse peut achever ou reporter la transaction. Ainsi, une transaction peut être considérée comme un ensemble d'activités de bus concernant une seule opération de bus comme une lecture ou une écriture. Une transaction peut passer plusieurs phases comme une phase d'arbitrage, une phase de requête, une phase d'erreur, une phase de surveillance de trafic, une phase de réponse, une phase de données et ainsi de suite. Une communication entre un premier composant (par exemple, 120) et un second composant (par exemple, 130) sera percue par sensiblement tous les composants (par exemple, 120, 130, 140, 150) connectés, de façon fonctionnelle, par le bus 110.

La Figure 2 illustre une configuration de modèle P2P à titre d'exemple de composants d'ordinateur. Un commutateur 210 comme un commutateur à barres croisées peut connecter des composants comme les composants 220, 230, 240 et 250. Encore une fois, tandis que quatre composants sont illustrés, on devra remarquer qu'un ou des commutateurs peuvent connecter un nombre plus grand et/ou plus petit de composants dans un système à liaison P2P. Des demandes à partir d'un premier composant (par exemple, 220) peuvent être acheminées par l'intermédiaire du commutateur 210 pour arriver sur un second composant (par exemple, 230). Des composants différents des premier et second composants, comme les composants 240 et 250, peuvent ne pas être au courant du fait que la communication entre les premier et second composants a eu lieu. Comme décrit ci dessus, des transactions sont fondamentalement différentes selon le modèle à bus et le modèle point à point. Par exemple, tandis que des transactions dans le modèle point à point comprennent des ensembles de paquets, des transactions dans un modèle à bus ne présentent pas de paquets.

La Figure 3 illustre une partie 300 d'un système dans laquelle un processeur 310 utilise un moteur de protocole de noyau 320 comme interface avec d'autres composants d'ordinateur et ainsi de suite. Dans un exemple, le moteur de protocole de noyau 320 peut être une liaison point à point 330. Dans un autre exemple, le moteur de protocole de noyau 320 peut être une liaison vers un VBI 340 qui est, à son tour, une liaison du type à bus 350. Sur la base des décisions de micro- architecture concernant le processeur 310, certaines transactions faisant partie d'un protocole mis en oeuvre par la liaison point à point 330 ne doivent pas être présentées au moteur de protocole de noyau 320 par le processeur 310. Ainsi, le moteur de protocole de noyau 320 ne doit pas présenter de telles transactions à l'interface de bus virtuel 340 ou à la liaison point à point 330. Tandis que la liaison point à point 330 peut manier la transaction non attendue car la transaction fait partie du protocole mis en oeuvre par la liaison point à point 330, une interface de bus virtuel 340 usuelle peut ne pas avoir une telle réussite.

Une interface de bus virtuel 340 usuelle peut être configurée pour seulement des transactions de processus que le processeur 310 doit produire sur la base des décisions de micro-architecture. Ainsi, des systèmes et des procédés à titre d'exemples décrits, dans notre cas, concernent l'interaction et/ou la reconfiguration de l'interface de bus virtuel 340 pour manier des transactions mises en oeuvre sans micro-architecture. De plus, l'interface de bus virtuel 340 peut rencontrer des transactions destinées au processeur 310 ou au CPE 320 comprenant des transactions non-mises en oeuvre pouvant arriver à partir d'autres positions comme d'autres agents sur un réseau P2P, d'autres noyaux RTL, d'autres dispositifs RTL, un agent simulé et ainsi de suite.

La Figure 4 illustre un système à titre d'exemple 400 facilitant une VBI 410 maniant des transactions mises en oeuvre de façon non-microarchitecturale. Le système 400 peut être configuré pour interagir avec une VBI 410 qui est configurée pour produire une transaction de type à bus 420 à partir d'une transaction P2P 430. Le système 400 peut comprendre un circuit logique de détection 440 qui est configuré pour déterminer si la transaction P2P est une transaction non-mise en oeuvre. Par exemple, les transactions P2P qui ne doivent pas être émises par un moteur de protocole de noyau et qui sont recues sous la forme de transactions non- mises en oeuvre dans le système 400 et/ou l'interface de bus virtuel 410 peuvent être identifiées puis suivies jusqu'à la fin dans le système 400. Une transaction P2P et/ou un paquet associé à celle-ci peut être identifiée comme étant une transaction non-mise en oeuvre en examinant, par exemple, un type de transaction, un type de paquet, un identificateur de transaction et similaires. Le type de transaction et/ou le type de paquet peut être comparé, par exemple, à une liste de transactions mises en oeuvre, une table de transactions mises en oeuvre et ainsi de suite pour déterminer si un processeur, un système et/ou un CPE doit émettre ce type de transaction et/ou de paquet. L'identificateur de transaction peut être comparé, par exemple, à une liste, une table et similaires d'identificateurs de transaction associés à des transactions identifiées précédemment comme étant des transactions non-mises en oeuvre. Le suivi jusqu'à la fin peut comprendre, par exemple, le contrôle de l'interface de bus virtuel 410 lors de sa réception et de l'assemblage des paquets associés à une transaction.

Un circuit logique de suivi 450 peut coder des critères de fin pour des transactions non-mises en oeuvre similaires à la façon dont des critères de fin sont codés pour des transactions mises en oeuvre. Le suivi de la transaction jusqu'à la fin facilite des actions comme la réutilisation d'identificateurs de transaction et ainsi, la réduction de la VBI 410 et/ou l'amorçage d'une consommation de ressource d'agent, réalisant une machine d'état associée à une VBI 410 plus complète et plus efficace et ainsi de suite. De même, un suivi de la transaction jusqu'à la fin favorise la prévention d'une entrée dans un état inconnu d'un circuit logique de suivi de transaction de VBI pouvant conduire à la consommation de ressources de VBI 410 (par exemple un temps, des cycles de processeur, une mémoire) pour revenir de l'état inconnu.

Dans un exemple, lorsqu'une transactions non-mises en oeuvre est reconnue, le circuit logique de suivi 450 peut marquer la transaction comme étant non-mise en oeuvre et par conséquent, sur la base du marquage, commander la VBI 410 pour ne pas produire de transaction de modèle de bus ni permettre la réutilisation d'un identificateur de transaction alloué à la transaction non-mise en oeuvre jusqu'à ce que la transaction non-mise en oeuvre soit suivie jusqu'à la fin. Dans un autre exemple, le circuit logique de suivi 450 peut mettre à jour une structure de données ou stocker une valeur dans un stockage de données pour indiquer que la transaction non-mise en oeuvre doit être suivie. Des paquets suivants associés à la transaction non-mise en oeuvre peuvent remplir desconditions sémantiques résiduelles pour une transaction puis peut provoquer le passage logique de la transaction non-mise en oeuvre par l'intermédiaire du circuit logique de suivi de transaction de VBI 410 et/ou le circuit logique de suivi 450. Ce suivi facilite le traitement correct par la VBI 410 des paquets reçus ensuite qui concernent la transaction non-mise en oeuvre ainsi que d'autres paquets non liés à la transaction non-mise en oeuvre. Cela peut faciliter à son tour la réutilisation d'identificateurs de transaction et un traitement plus efficace de VBI 410.

Des transaction non-mise en oeuvre qui sont suivies peuvent être rapportées comme des erreurs, par exemple, en produisant des messages d'erreur, en manipulant des valeurs stockées dans une mémoire d'ordinateur, en générant un signal d'erreur et similaires. Ainsi, le système 400 peut comprendre, de même, un circuit logique d'erreur 460 facilitant la production de signaux d'erreur, de données d'erreur et/ou de messages associés à la transaction d'erreur. Dans un exemple, les signaux, les données et/ou les messages d'erreur peuvent être rapportés directement à partir du circuit logique d'erreur vers un fichier, un moniteur, un système et ainsi de suite tandis que dans un autre exemple, ils peuvent être rapportés par l'intermédiaire de l'interface de bus virtuel 410.

La Figure 5 illustre le passage d'un message à titre d'exemple associé à une VBI 510 qui est configurée pour manier des transactions mises en oeuvre de façon non-microarchitecturale. La VBI 510 peut être configurée pour suivre, par exemple, des transaction non-mise en oeuvre, des transactions P2P qu'un utilisateur spécifie comme des transactions d'erreur et ainsi de suite.

Une première transaction Tl comprenant un ensemble de paquets Pl 522, P2 523, P3 524, P4 525 et P5 526 peut être présentée à la VBI 510. La nomenclature Px se réfère à un paquet P avec un identificateur x facilitant l'identification d'un type de paquet. Par exemple, un paquet Pl peut indiquer que le paquet est un paquet d'en-tête pour une transaction de lecture. De la même façon, un paquet P7 peut indiquer que le paquet est un paquet d'en- tête pour une demande d'acheminement P2P. L'ensemble des paquets dans la transaction Tl peut décrire une transaction P2P valide mise en oeuvre et peut conduire ainsi à la production par la VBI 510 d'une première transaction de bus frontal FSB1 Tl. Une seconde transaction T2 comprenant un ensemble de paquets peut être présentée de façon similaire à la VBI 510. La transaction T2 peut être une transaction qui n'est pas supposée être présentée à la VBI 510. Par exemple, dans un environnement de développement, un processeur prototype peut ne pas avoir mis en oeuvre la fonctionnalité qui produirait les paquets en T2. Par exemple, des transactions commençant avec un paquet P7 peuvent être identifiables comme des transaction non-mise en oeuvre. Cependant, la VBI 510 peut être configurée pour faire plus qu'une simple ignorance de ces transaction nonmise en oeuvre. Plutôt que d'ignorer simplement le paquet P7 532, la VBI 510 peut engager des actions comme le marquage de la transaction T2 comme une transaction non-mise en oeuvre, la mise à jour d'un stockage ou d'une structure de données pour indiquer que la transaction T2 est une transaction non-mise en oeuvre et ainsi de suite. Après avoir engagé la(les) action(s) pour faciliter l'identification du fait que les paquets P3 534 et P5 536 appartiennent à la transaction T2 qui est une transaction non-mise en oeuvre, la VBI 510 peut poursuivre le traitement de la transaction T2 jusqu'à la fin en recevant et en traitant les paquets P3 534 et P5 536. Ainsi, plutôt que de recevoir le paquet P3 534 et le voir apparaître comme n'appartenant pas à une transaction en cours, ce qui pourrait déclencher le traitement d'une nouvelle transaction, la VBI 510 pourra traiter, de façon correcte, la transaction T2 et la prise en compte des paquets P3 534 et P5 536.

Le suivi et le traitement des transactions d'erreur jusqu'à la fin permet d'éviter un problème pouvant survenir par exemple si la transaction T2 n'a pas été correctement maniée (par exemple, le paquet P7 532 est simplement mis de coté) puis les paquets P3 534 et P5 536 arrivés. Comme on peut le voir par le traitement de la transaction T3 par la VBI 510 dans une transaction de bus FSB2 T3 548, les paquets P3 544 et P5 546 forment une transaction P2P valide. Si le paquet P7 532 était simplement mis de coté et si les paquets P3 534 et P5 536 arrivent ensuite et ne sont pas maniés comme faisant partie de la transaction T2, une transaction "additionnelle" pourrait alors produite par la VBI 510.

La Figure 6 illustre une VBI 600 qui est configurée pour manier des transactions mises en oeuvre de façon non- micro-architecturale. La VBI 600 peut produire une transaction de type à bus 610 à partir d'une transaction P2P 620. Ainsi, la VBI 600 peut comprendre un circuit logique de transaction P2P 630 configuré pour traiter un paquet associé à la transaction P2P 620. Le paquet peut comprendre un identificateur facilitant la détermination du fait que le paquet fait partie d'une transaction non-mise en oeuvre ou non. Ainsi, la VBI 600 peut comprendre un circuit logique de détection 640 configuré pour détecter le fait qu'un paquet associé à la transaction P2P 620 identifie la transaction comme une transaction non-mise en oeuvre. Une transaction P2P et/ou un paquet associé peut être identifiée comme étant une transaction non-mise en oeuvre, par exemple, en examinant un type de transaction, un type de paquet, un identificateur de transaction et similaires. Le type de transaction et/ou le type de paquet peut être comparé, par exemple, à une liste de transactions mises en oeuvre, une table de transactions mises en oeuvre et ainsi de suite pour déterminer si un processeur, un système et/ou un CPE doit émettre ce type de transaction et/ou de paquet ou non. L'identificateur de transaction peut être comparé, par exemple, à une liste, une table et ainsi de suite d'identificateurs de transaction associés à des transactions identifiées précédemment comme étant des transaction non-mise en oeuvre.

La VBI 600 peut comprendre, de même, un circuit logique de transaction de type à bus 670 qui est configuré pour produire, de façon sélective, la transaction de type à bus 610 à partir de la transaction P2P 620 lorsque la transaction P2P 620 est un type de transaction mise en oeuvre. Pour faciliter le maniement correcte des paquets associés à une transaction non-mise en oeuvre, la VBI 600 peut comprendre un circuit logique de suivi 650 qui est configuré pour suivre la transaction non-mise en oeuvre et ses paquets/"flits" pendant leur réception par le circuit logique de transaction P2P 630. La VBI 600 peut comprendre un circuit logique d'erreur 660 qui est configuré pour faciliter la production sélective de données et/ou de messages d'erreur concernant une transaction non-mise en oeuvre.

Le circuit logique de transaction P2P 630 et le circuit logique d'erreur 660 peuvent coordonner leurs activités concernant le suivi, le maniement et le rapport de transaction non-mise en oeuvre à l'aide de divers procédés. Par exemple, lors de la détection du fait que la transaction P2P 620 est une transaction non-mise en oeuvre, le circuit logique de transaction P2P 630 peut engager des actions comme le stockage d'une valeur identifiant, de façon unique, la transaction non-mise en oeuvre dans une structure de données associée à la VBI 600, le stockage d'une valeur identifiant de façon unique la transaction non-mise en oeuvre dans un stockage de données associé à la VBI 600 et/ou le marquage de la transaction comme une transaction "d'erreur". Alors, le circuit logique d'erreur 660 peut commander la production de données et/ou de messages d'erreur sur la base de la(des) valeur(s) et/ou le marquage.

Le circuit logique de suivi 650 peut examiner un identificateur réutilisable de transaction fourni par un agent d'amorçage pour faciliter le suivi d'une transaction pendant son traitement par la VBI 600. L'identificateur réutilisable de transaction peut faciliter la liaison des paquets avec des transactions associées. Dans un exemple, un identificateur de transaction peut être stocké dans chaque paquet traité par la VBI 600. Cependant, il peut y avoir un ensemble fini d'identificateurs de transaction disponibles. Par exemple, un champ de quatre bits peut être alloué au stockage d'un identificateur de transaction et ainsi, seulement seize identificateurs de transaction peuvent être disponibles. Avec seulement seize identificateurs de transaction disponibles, un agent d'amorçage peut avoir besoin de réutiliser, de façon efficace, des identificateurs de transaction.

Le maniement efficace d'actions comme l'identification de la fin d'une transaction et l'identification de la réception de paquets associés à une nouvelle transaction peut aider à la réutilisation de l'identificateur de transaction et ainsi, de la VBI 600 et/ou la justesse et l'efficacité d'agent d'amorçage. En maniant des transaction non-mise en oeuvre, les cas où un identificateur de transaction peut ne pas être réutilisé peuvent être évités. Par exemple, un premier paquet peut être reçu par la VBI 600. La VBI 600 peut déterminer le fait que le paquet est le premier paquet d'une nouvelle transaction. Cependant, si le paquet est un paquet qu'un CPE ne doit pas avoir émis ou le paquet est associé à une transaction non-mise en oeuvre de façon usuelle, des paquets suivants et arrivants peuvent ne pas être maniés correctement et la transaction peut ne pas se terminer. De plus, un circuit logique de machine d'état dans la VBI 600 peut ne pas manier correctement les paquets et/ou la transaction. Par conséquent, l'identificateur réutilisable de transaction qui a été alloué à la transaction peut ne pas être disponible, de façon usuelle, pour une réutilisation par l'agent d'amorçage plus longtemps que dans le cas du traitement de la transaction par une VBI reconfigurée pouvant manier des transaction non-mise en oeuvre.

Des procédés à titre d'exemples peuvent être mieux compris en référence à l'organigramme de la Figure 7. Pour des buts de simplicité d'explication, la méthode à titre d'exemple est décrite sous la forme d'une série d'actions et on considérera que la méthode n'est pas limitée par l'ordre des actions, certaines pouvant survenir dans des ordres différents et/ou en même temps que d'autres. De plus, seulement une partie des actions illustrées peuvent être requises pour une mise en oeuvre d'une méthode à titre d'exemple. De plus, des méthodes additionnelles et/ou en option peuvent utiliser des actions additionnelles non illustrées.

Dans l'organigramme, des pavés représentent des actions pouvant être mises en oeuvre avec un circuit logique. Un organigramme n'illustre pas de syntaxe pour un quelconque langage particulier de programmation, méthode ou style (par exemple, de procédure, orienté objet). Au contraire, un organigramme illustre une information fonctionnelle que l'homme du métier peut utiliser pour développer un circuit logique effectuant le traitement illustré. On remarquera que dans certains exemples, des éléments de programme comme des variables temporaires, des boucles de sous programme et ainsi de suite ne sont pas illustrés. On remarquera que les actions peuvent être mises en oeuvre à l'aide de diverses approches de programmation comme un langage machine, une procédure, des techniques orientées objet et/ou d'intelligence artificielle.

La Figure 7 illustre un procédé à titre d'exemple 700 facilitant le maniement par une VBI de transactions mises en oeuvre de façon non-microarchitecturale. Le procédé 700 peut comprendre en 710 la détection d'un événement de fin associé à une transaction P2P et/ou un paquet reçu dans une VBI. Comme décrit ci-dessus, les transactions peuvent arriver sur la VBI à partir de position comme un moteur de protocole de noyau, des agents sur un réseau P2P, des noyaux RTL, des dispositifs RTL, un agent simulé et ainsi de suite. Une fois la détection de l'événement de fin, le procédé 700 peut déterminer en 720 le fait que la transaction P2P recue est une transaction mise en oeuvre ou non. Si la détermination en 720 est non, le procédé 700 peut comprendre alors en 730 le suivi sélectif de la transaction jusqu'à la fin. Pour faciliter le suivi d'une transaction qui n'est pas mise en oeuvre, le procédé 700 peut engager des actions comme la manipulation d'une position en mémoire pour identifier la transaction P2P pour la VBI comme une transaction non-mise en oeuvre, le marquage de la transaction P2P pour l'identifier comme une transaction non-mise en oeuvre, l'allocation d'un identificateur de transaction pour la transaction non-mise en oeuvre et ainsi de suite. Ainsi, une transaction passe par une VBI, divers circuits logiques de la VBI peuvent pouvoir référencer la position de mémoire manipulée et/ou le marquage de transaction pour déterminer la façon de manier la transaction d'erreur. De même, l'identificateur de transaction peut faciliter l'avancement logique d'une transaction non-mise en oeuvre par l'intermédiaire d'une machine d'état VBI.

Le procédé 700 peut comprendre, de même, en 740 la production sélective de données d'erreur associées au traitement de la transaction non-mise en oeuvre. En 750, on détermine s'il existe une autre transaction et/ou paquet à traiter. Si la détermination est non, le traitement peut alors se terminer; dans les autres cas, le traitement peut revenir en 710.

Tandis que la Figure 7 illustre diverses actions survenant en série, on remarquera que diverses actions illustrées sur la Figure 7 peuvent avoir lieu sensiblement en parallèle. A titre d'illustration, un premier processus pourrait détecter un événement terminé, un second processus pourrait déterminer si une transaction est une transaction mise en oeuvre et un troisième processus pourrait faciliter la production de données et/ou de messages d'erreur associés à la transaction suivie, par exemple, en manipulant une mémoire, en marquant des transactions et ainsi de suite. Tandis que trois processi sont décrits, on remarquera qu'un nombre plus grand et/ou plus petit de processi pourraient être utilisés et que des processi légers, des processi réguliers, des unités d'exécution et d'autres approches pourraient être utilisés.

Dans un exemple, des méthodes sont mises en oeuvre sous la forme d'instructions exécutables par processeur et/ou d'opérations stockées sur un support informatique. Ainsi, dans un exemple, un support informatique peut stocker des instructions exécutables par processeur pouvant servir à appliquer un procédé incluant la détection d'un événement de fin associé à une transaction point à point recue dans une interface de bus virtuel et la détermination du fait que la transaction point à point est une transaction mise en oeuvre. La détermination du fait que la transaction point à point est une transaction mise en oeuvre peut comprendre la comparaison d'un identificateur de transaction avec un ensemble d'identificateurs de transaction identifiés précédemment comme étant associés à des types de transaction non-mise en oeuvre. Le procédé peut comprendre, de même, le suivi sélectif de la transaction point à point par l'intermédiaire de l'interface de bus virtuel en établissant un ensemble de critères de fin de phase sémantique incluant un critère ultime de fin et le contrôle de la progression de la transaction point à point par l'intermédiaire de l'ensemble de critères de fin de phase sémantique vers le critère ultime de fin. Le procédé peut comprendre, de même, la production sélective de signaux d'erreur, de codes d'erreur, de message d'erreur et ainsi de suite associés au traitement d'une transaction non-mise en oeuvre.

Tandis que le procédé ci dessus est décrit comme étant stocké sur un support informatique, on remarquera que d'autres procédés à titre d'exemples décrits, dans notre cas, peuvent être stockés, de même, sur un support informatique.

La Figure 8 illustre un ordinateur 800 comprenant un processeur 802, une mémoire 804 et des connecteurs d'entrée/sortie 810 connectés, de façon fonctionnelle, par un bus 808. Dans un exemple, l'ordinateur 800 peut comprendre une VBI 830 configurée pour faciliter la conversion de transactions P2P en transactions du type de bus. La VBI 830 peut être reconfigurée selon les systèmes et procédés décrits dans notre cas pour faciliter le maniement de transactions mises en oeuvre de façon nonmicro-architecturale. Qu'elle soit mise en oeuvre sous la forme d'un matériel, d'un microprogramme, d'un logiciel et/ou de leurs combinaisons, la VBI 830 peut fournir des moyens pour déterminer si un paquet associé à une transaction point à point recue par une interface de bus virtuel identifie la transaction point à point comme une transaction non-mise en oeuvre, des moyens pour identifier un paquet associé à une transaction non-mise en oeuvre vers l'interface de bus virtuel pour faciliter le traitement d'un paquet reçu ensuite associé à la transaction non-mise en oeuvre et des moyens pour suivre la transaction non-mise en oeuvre pendant son traitement par l'interface de bus virtuel.

Le processeur 802 peut faire partie de divers processeurs incluant des architectures à double microprocesseur ou d'autres architectures multiprocesseurs. La mémoire 804 peut comprendre une mémoire volatile ou non. La mémoire non volatile peut comprendre sans y être limitée une ROM, une PROM, une EPROM, une EEPROM et similaires. La mémoire volatile peut comprendre, par exemple, une RAM, une RAM synchrone (SRAM), une RAM dynamique (DRAM), une DRAM synchrone (SDRAM), une SDRAM à double cadence de données (DDR SDRAM) et une RAM à bus direct (DDRAM).

Un disque 806 peut être connecté, de façon fonctionnelle, à l'ordinateur 800 par l'intermédiaire, par exemple, d'une interface d'entrée/sortie 818 (par exemple, une carte, un dispositif) et un connecteurs d'entrée/sortie 810. Le disque 806 peut comprendre sans y être limité des dispositifs comme un lecteur de disque magnétique, un lecteur de disque à semiconducteur, un lecteur de disquette souple, un lecteur de bande, un lecteur Zip, une carte de mémoire Flash et/ou une barrette de mémoire. De plus, le disque 806 peut comprendre des lecteurs optiques, comme un lecteur de cédérom, un lecteur de CD enregistrable (lecteur de CD-R), un lecteur de CD réenregistrable (lecteur de CD-RW) et/ou un lecteur de ROM numérique vidéo (DVD ROM). La mémoire 804 peut stocker, par exemple, des processi 814 et/ou des données 816. Le disque 806 et/ou la mémoire 804 peut stocker un système d'exploitation commandant et allouant des ressources de l'ordinateur 800.

Le bus 808 peut être une architecture unique d'interconnexion de bus interne et/ou d'autres architectures de bus ou de maillage. Tandis qu'un seul bus est illustré, on remarquera que l'ordinateur 800 peut communiquer avec divers dispositifs, circuits logiques et périphériques utilisant d'autres bus qui ne sont pas illustrés (par exemple, PCIE, SATA, Infiniband, 1394, USB, Ethernet). Le bus 808 peut être de divers types comprenant sans y être limité un bus de mémoire ou un contrôleur de mémoire, un bus périphérique ou un bus externe, un commutateur à barres croisées et/ou un bus local. Le bus local peut être de divers types comprenant sans y être limité un bus d'architecture standard de l'industrie (ISA), un bus d'architecture à microcanal (MSA), un bus ISA étendu (EISA), un bus d'interconnexion de périphérique (PCI), un bus série universel (USE) et un bus d'interface de système de petit ordinateur (SCSI).

L'ordinateur 800 peut coopérer avec des dispositifs d'entrée/sortie par l'intermédiaire de interfaces d'entrée/sortie 818 et des connecteurs d'entrée/sortie 810. Les dispositifs d'entrée/sortie peuvent comprendre sans y être limités un clavier, un microphone, un dispositif de pointage et de sélection, des cartes vidéo, des affichages, un disque 806, des dispositifs de réseau 820 et similaires.

Les connecteurs d'entrée/sortie 810 peuvent comprendre, sans y être limités, des connecteurs série, des connecteurs parallèle et des connecteurs USB.

L'ordinateur 800 peut fonctionner dans un environnement de réseau et peut ainsi être connecté à des dispositifs de réseau 820 par l'intermédiaire des interfaces d'entrée/sortie 818 et/ou les connecteurs d'entrée/sortie 810. Par l'intermédiaire des dispositifs de réseau 820, l'ordinateur 800 peut interagir avec un réseau. Par l'intermédiaire du réseau, l'ordinateur 800 peut être connecté de façon logique avec des ordinateurs à distance. Les réseaux avec lesquels l'ordinateur 800 peut interagir comprennent sans y être limités un réseau local (LAN), un réseau étendu (WAN) et d'autres réseaux. Les dispositifs de réseau 820 peuvent se connecter aux technologies LAN comprenant sans y être limités une interface de données réparties à fibre (FDDI), une interface de données réparties à câble (CDDI), un Ethernet (IEEE 802.3), un réseau en anneau à jeton (IEEE 802.5), une communication sans fil d'ordinateur (IEEE 802.11), Bluetooth (IEEE 802.15.1) et similaires. De même, les dispositifs de réseau 820 peuvent se connecter aux technologies WAN comprenant sans y être limités des liaisons point à point, des réseaux à commutation de circuit comme des réseaux numériques à intégration de services (ISDN), des réseaux à commutation par paquets et des lignes numériques de souscripteur (DSL).

En référence, à présent, à la Figure 9, une interface de programmation d'application (API) 900 est illustrée assurant un accès à une VBI 910. La API 900 peut être utilisée, par exemple, par un programmeur 920 et/ou un processus 930 pour avoir accès au traitement effectué par la VBI 910. Par exemple, un programmeur 920 peut écrire un programme d'accès à la VBI 910 (par exemple, appelle son fonctionnement, contrôle son fonctionnement, commande son fonctionnement), l'écriture du programme étant facilitée par la présence de la API 900. Plutôt que de devoir comprendre la structure interne de la VBI 910, le programmeur 920 doit seulement apprendre l'interface avec la VBI 910. Cela facilite l'incorporation de la fonctionnalité de la VBI 910 tout en exposant sa fonctionnalité.

De la même façon, la API 900 peut être utilisée pour fournir des valeurs de données à la VBI 910 et/ou pour extraire des valeurs de données de la VBI 910. Par exemple, un processus 930 recevant des transactions P2P peut fournir une transaction P2P avec le système 910 par l'intermédiaire de la API 900 en utilisant un appel prévu dans la API 900.

Ainsi, dans un exemple de la API 900, un ensemble d'interfaces de programmation d'application peuvent être stockées sur un support informatique. Les interfaces peuvent être utilisées par un programmeur 920, un composant d'ordinateur, un circuit logique, un processus 930 et ainsi de suite pour avoir accès à la VBI 910. Les interfaces peuvent comprendre, sans y être limitées, une première interface 940 communiquant une transaction P2P (par exemple un ensemble de paquets, un ensemble de "nits"), une seconde interface 950 communiquant une donnée de suivi (par exemple, de marquage, un drapeau, un sémaphore) facilitant le suivi d'une transaction non-mise en oeuvre et une troisième interface 960 communiquant une donnée d'erreur facilitant la production d'un message d'erreur, d'une entrée de journal d'erreur, de données de commande de suivi de transaction VBI et similaires concernant la transaction non-mise en oeuvre.

Tandis que des systèmes, des procédés et ainsi de suite, à titre d'exemples, ont été illustrés et décrits de façon très détaillée par description d'exemples, il n'est pas dans l'intention des déposants de restreindre ou de limiter la portée des revendications annexées à de tels détails. Bien entendu, il n'est pas possible de décrire chaque combinaison concevable de composants ou de méthodes à des fins de description des systèmes, des procédés et ainsi de suite décrits dans notre cas. Des avantages et des modifications additionnels seront évidents pour l'homme du métier. Par conséquent, l'invention n'est pas limitée aux détails spécifiques, au dispositif représentatif et aux exemples illustratifs illustrés et décrits. Ce dépôt est prévu pour englober des variantes, des modifications et des variations entrant dans le cadre des revendications annexées et ainsi, le cadre de l'invention doit être déterminé par les revendications annexées et leurs équivalents.

Dans la mesure où le terme "comprend" ou "comprenant" est utilisé dans la description détaillée ou les revendications, il est prévu d'inclure d'une façon similaire le terme "comprenant" en tant que terme interprété lors d'une utilisation comme mot de transition dans une revendication. De plus, dans la mesure où le terme "ou" est utilisé dans la description détaillée ou les revendications (par exemple, A ou B), il est prévu de signifier "A ou B ou les deux". Lorsque les déposants prévoient d'indiquer "seulement A ou B et non pas les deux", le terme "seulement A ou B et non pas les deux" sera alors employé (voir Bryan A. Garner dans "A Dictionnary of Modern Legal Usage 624 (2d Ed. 1995)).

Claims (9)

REVENDICATIONS

1. Système (400) configuré pour interagir avec une interface de bus virtuel (410) produisant des transactions du type à bus (420) à partir de transactions point à point (430), le système (400) étant caractérisé en ce qu'il comprend: - un circuit logique de détection (440) configuré pour détecter le fait qu'une transaction point à point (430) fournie à l'interface de bus virtuel (410) est une transaction non-mise en oeuvre pour laquelle aucune transaction du type à bus (420) doit être produite et pour laquelle un signal d'erreur doit être généré ; - un circuit logique de suivi (450) connecté, de façon fonctionnelle, au circuit logique de détection (440), le circuit logique de suivi (450) étant configuré pour faciliter le suivi de la transaction point à point (430) pendant son traitement par l'intermédiaire d'une ou plusieurs phases sémantiques par l'interface de bus virtuel (410) et pour commander l'interface de bus virtuel (410) afin de ne pas produire de transaction du type à bus (420) associée à la transaction non-mise en oeuvre; et - un circuit logique d'erreur (460) connecté, de façon fonctionnelle, au circuit logique de suivi (450), le circuit logique d'erreur (460) étant configuré pour produire un signal d'erreur associé à une ou plusieurs parmi la transaction non-mise en oeuvre détectée par le circuit logique de détection (440) et la transaction non-mise en oeuvre suivie jusqu'à la fin par le circuit logique de suivi (450).

2. Système (400) selon la revendication 1, caractérisé en ce que le circuit logique de détection (440) est configuré pour détecter le fait qu'une transaction point à point (430) fournie à l'interface de bus virtuel (410) est une transaction non-mise en oeuvre par examen d'un identificateur de type de paquet dans un paquet d'en-tête associé à la transaction point à point (430).

3. Système (400) selon la revendication 1, caractérisé en ce que le circuit logique d'erreur (460) est configuré pour produire, en réponse au circuit logique de détection (440) détectant la transaction non-mise en oeuvre, un signal d'erreur en appliquant une ou plusieurs, en mettant à jour une ou plusieurs parmi une valeur dans une structure de données associée au suivi de la transaction point à point (430) et une valeur dans un stockage de données associé au suivi de la transaction point à point (430), et le marquage de la transaction point à point (430) à l'aide d'un label d'erreur.

4. Système d'interface de bus virtuel (600) configuré pour produire, de façon sélective, une transaction du type à bus (610) à partir d'une transaction du type point à point (620), caractérisé en ce qu'il comprend: - un circuit logique de transaction point à point (630) configuré pour recevoir un paquet associé à une transaction point à point (620) ; - un circuit logique de détection (640) configuré pour déterminer si le paquet est associé à une transaction 25 non-mise en oeuvre; - un circuit logique de transaction du type à bus (670) configuré pour produire, de façon sélective, une transaction du type à bus (610) à partir de la transaction point à point (620) recue par le circuit logique de transaction point à point (630) ; - un circuit logique de suivi (650) configuré pour suivre une transaction non-mise en oeuvre pendant son traitement par le circuit logique de transaction du type à bus (670) ; et - un circuit logique d'erreur (670) connecté, de façon fonctionnelle, au circuit logique de suivi (650) et au circuit logique de détection (640), le circuit logique d'erreur (660) étant configuré pour produire un signal d'erreur lié à la transaction non-mise en oeuvre sur la base au moins en partie de la détermination effectuée par le circuit logique de détection (640) et le suivi effectué par le circuit logique de suivi (650), le circuit logique d'erreur (660) commandant, de façon sélective, le circuit logique de transaction du type à bus (670) pour ne pas produire de transaction du type à bus (610) à partir de la transaction point à point (620).

5. Système (600) selon la revendication 4, caractérisé en ce que le circuit logique de suivi (650) est configuré pour examiner un identificateur de transaction réutilisable fourni par un agent de démarrage, l'identificateur de transaction réutilisable facilitant l'identification unique d'une transaction non-mise en oeuvre et le circuit logique de suivi (650) commandant de façon sélective le circuit logique de transaction du type à bus (670) pour libérer l'identificateur de transaction lors du traitement de la transaction non-mise en oeuvre jusqu'à la fin.

6. Procédé (700), caractérisé en ce qu'il comprend: - la détection (710) d'un événement de fin associé à une transaction point à point recue dans une interface de 30 bus virtuel; - la détermination (720) du fait que la transaction point à point est une transaction mise en oeuvre ou non; - le suivi sélectif (730) de la transaction point à point par l'intermédiaire de l'interface de bus virtuel sous la forme d'une transaction non-mise en oeuvre; et - la production sélective (740) d'une donnée d'erreur 5 associée à une transaction non-mise en oeuvre suivie.

7. Procédé (700) selon la revendication 6, caractérisé en ce qu'il comprend une ou plusieurs étapes parmi la manipulation d'une position de mémoire pour identifier la transaction point à point sur l'interface de bus virtuel comme une transaction non-mise en oeuvre et le marquage de la transaction point à point pour identifier la transaction point à point sur l'interface de bus virtuel comme une transaction non-mise en oeuvre.

8. Procédé (700) selon la revendication 6, caractérisé en ce que la détermination (720) du fait que la transaction point à point est une transaction mise en oeuvre comprend la comparaison d'un identificateur de transaction associé à la transaction point à point avec un ensemble d'identificateurs de transaction précédemment identifiés comme étant associés aux types de transaction non-mise en oeuvre.

9. Procédé (700) selon la revendication 6, caractérisé en ce que le suivi sélectif (730) de la transaction point à point par l'intermédiaire de l'interface de bus virtuel comme une transaction non-mise en oeuvre comprend l'établissement d'un ensemble de critères sémantiques de fin de phase comprenant un critère ultime de fin et le contrôle de la progression de la transaction point à point dans l'ensemble de critères sémantiques de fin de phase jusqu'au critère ultime de fin et en ce que la production sélective d'une donnée d'erreur associée à une transaction suivie non-mise en oeuvre comprend la production d'un ou plusieurs parmi un signal d'erreur, un code d'erreur ou un message d'erreur.