FR2919401A1 - Procede de test des chemins de donnees dans un circuit electronique - Google Patents

Procede de test des chemins de donnees dans un circuit electronique Download PDF

Info

Publication number
FR2919401A1
FR2919401A1 FR0705381A FR0705381A FR2919401A1 FR 2919401 A1 FR2919401 A1 FR 2919401A1 FR 0705381 A FR0705381 A FR 0705381A FR 0705381 A FR0705381 A FR 0705381A FR 2919401 A1 FR2919401 A1 FR 2919401A1
Authority
FR
France
Prior art keywords
transfer
block
group
blocks
test method
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
FR0705381A
Other languages
English (en)
Other versions
FR2919401B1 (fr
Inventor
Patrick Dervin
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Thales SA
Original Assignee
Thales SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Thales SA filed Critical Thales SA
Priority to FR0705381A priority Critical patent/FR2919401B1/fr
Priority to US12/173,278 priority patent/US7913129B2/en
Publication of FR2919401A1 publication Critical patent/FR2919401A1/fr
Application granted granted Critical
Publication of FR2919401B1 publication Critical patent/FR2919401B1/fr
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • GPHYSICS
    • G11INFORMATION STORAGE
    • G11CSTATIC STORES
    • G11C29/00Checking stores for correct operation ; Subsequent repair; Testing stores during standby or offline operation
    • G11C29/04Detection or location of defective memory elements, e.g. cell constructio details, timing of test signals
    • G11C29/08Functional testing, e.g. testing during refresh, power-on self testing [POST] or distributed testing
    • G11C29/12Built-in arrangements for testing, e.g. built-in self testing [BIST] or interconnection details
    • G11C29/18Address generation devices; Devices for accessing memories, e.g. details of addressing circuits
    • G11C29/26Accessing multiple arrays
    • GPHYSICS
    • G11INFORMATION STORAGE
    • G11CSTATIC STORES
    • G11C29/00Checking stores for correct operation ; Subsequent repair; Testing stores during standby or offline operation
    • G11C29/02Detection or location of defective auxiliary circuits, e.g. defective refresh counters
    • GPHYSICS
    • G11INFORMATION STORAGE
    • G11CSTATIC STORES
    • G11C29/00Checking stores for correct operation ; Subsequent repair; Testing stores during standby or offline operation
    • G11C29/04Detection or location of defective memory elements, e.g. cell constructio details, timing of test signals
    • G11C29/08Functional testing, e.g. testing during refresh, power-on self testing [POST] or distributed testing
    • G11C29/12Built-in arrangements for testing, e.g. built-in self testing [BIST] or interconnection details
    • G11C29/38Response verification devices
    • G11C29/40Response verification devices using compression techniques
    • G11C2029/4002Comparison of products, i.e. test results of chips or with golden chip

Landscapes

  • Techniques For Improving Reliability Of Storages (AREA)

Abstract

Un procédé de test d'un circuit électronique complexe, comprenant une pluralité d'opérateurs de transferts DMA_0, DMA_1, UDMA, Routines logicielles exécutées par le processeur, et une pluralité de ressources mémoire (M1, M2, M3, M4) formant un espace mémoire partagé 1 sur lequel peuvent travailleur les différents opérateurs, comprend une initialisation de chaque adresse de l'espace mémoire partagé par une donnée qui est une fonction bijective de cette adresse, un partitionnement de cet espace mémoire partagé 1 en une pluralité de blocs 0, B1, B2, B3, B4, les blocs étant regroupés en au moins un groupe G0, ne comportant que des blocs de même taille, et une exécution d'une série de transferts S(T), chaque transfert étant réalisé par un opérateur, pour transférer le contenu d'un bloc source d'un groupe, dans un bloc destination du même groupe. Les transferts au sein de chaque groupe sont suivis par une table de mouvement TAB(G0) correspondante, qui à l'initialisation, associe un index initial à chaque bloc, et à chaque transfert écrit comme nouvel index courant du bloc de destination de ce transfert, l'index du bloc source. Cet index identifie de façon bijective les données contenues dans le bloc correspondant.

Description

PROCEDE DE TEST DES CHEMINS DE DONNEES DANS UN CIRCUIT ELECTRONIQUE
La présente invention concerne un procédé de test d'un circuit électronique, dans lequel des ressources mémoire peuvent être accédées de façon concurrente par différents opérateurs de transferts de données. Les circuits électroniques sont de plus en plus complexes, utilisant des processeurs puissants, et mettant en oeuvre des mécanismes perfectionnés de gestion et contrôle des données notamment (parallélisme, pipeline,...), permettant des puissances de calcul toujours plus élevées. Leurs architectures sont complexes, avec une pluralité de bus : un bus local auquel sont directement connectés le ou les processeurs et leurs mémoires principales, et dans certains cas à des contrôleurs de mémoire cache ; et un ou des bus d'extension qui permettent d'ajouter des fonctionnalités d'entrée et/ou de sortie, notamment des cartes mémoires supplémentaires, des fonctionnalités graphiques, des liaisons série, des réseaux locaux ... Le bus local est alors connecté aux contrôleurs des différents bus d'extension.
Différents standards de bus sont utilisés, correspondant généralement à des fonctions spécifiques. On peut notamment citer parmi les standards bien connus, les bus d'extension PCI (parallèle) ou PCI Express (série), et USB, dont des connecteurs correspondants sont couramment prévus sur les cartes mères des circuits électroniques, pour y connecter des cartes spécialisées ou des cartes mémoire supplémentaires. Ces architectures comprennent ainsi différentes ressources mémoire accessibles aux différents opérateurs par des interfaces de données appropriées. Ces ressources mémoire forment ainsi un espace mémoire partagé qui regroupe typiquement : des zones de mémoires sur le bus local ou hôte, et sur les bus d'extension, accessibles par l'interface ou le contrôleur correspondant. Les mémoires de cet espace de mémoire partagée seront par exemple des mémoires vives de type SDRAM ou de tout autre type (ZBT "Zero Bus Turnaround", DDR "Double Data Rate", QDR "Quadruple Data Rate", ...) situées sur le bus local ou déportées via un bus PCI, ou des mémoires programmables de type flash EPROM par exemple (bus USB), ou autres... , et sont accessibles en lecture et/ou en écriture. Quant aux différents opérateurs de transferts de données, ils peuvent être synchrones ou asynchrones. Ils possèdent des ressources mémoire de travail propres (registres, mémoire tampon), pour stocker temporairement les données échangées, des informations de commande qui définissent le mode de fonctionnement de l'interface (par exemple, sens du transfert : entrée/sortie, mode de transfert : interruption/scrutation), et des informations d'état, typiquement inscrites dans des registres d'état, qui informent notamment si des erreurs de transmission se sont produites, et qui sont consultées par le processeur. Les opérateurs peuvent accéder aux différentes zones de mémoire communes ou partagées du circuit électronique. Ces opérateurs peuvent être des routines logicielles exécutées par le processeur ou des services de transfert de blocs de données en mémoire ou vers des réseaux de communication, des automates programmables de transfert de blocs de données par accès direct mémoire DMA (Direct Memory Access), des contrôleurs de liens de communication, tels que des contrôleurs de liaison série ou parallèle (UART), des contrôleurs réseaux ...la liste ne se prétend pas exhaustive. Dans ces circuits électroniques complexes, les accès suivent des chemins de données comprenant les différentes interfaces de données, ou contrôleurs, par lesquels les opérateurs peuvent accéder en lecture et/ou en écriture à une zone mémoire donnée. Les différents opérateurs peuvent agir de manière concurrente, nécessitant des arbitrages sur les demandes d'accès, qui peuvent être de différents types. Notamment les demandes peuvent se faire selon un mode de transfert en scrutation ou en interruption ; et les structures des données peuvent varier selon les interfaces : octet (8 bits), mot (16 bits), ou autres formats (24, 32 bits..). Avec l'augmentation de la complexité de ces circuits électroniques, les besoins en vérification du fonctionnement de ces circuits se sont également accrus, et la difficulté de réaliser cette vérification d'une façon satisfaisante aussi.
Ces vérifications sont notamment très importantes s'agissant de circuits associés à des fonctions de sécurité, tels que des circuits embarqués dans les aéronefs : il est nécessaire de pouvoir certifier leur bon fonctionnement. Or les processus asynchrones et concurrents qui se déroulent dans ces circuits entraînent nombre de situations critiques nécessitant des arbitrages. Il faut pouvoir être certain que ces situations et leurs arbitrages ne conduisent à aucun dysfonctionnement du circuit électronique, en aucunes circonstances. En d'autres termes, il faut pouvoir vérifier que dans toutes les situations possibles, le fonctionnement est correct.
Selon une approche classique, le test de vérification d'un circuit électronique devrait consister à reproduire toutes les situations de fonctionnement possibles, et à vérifier que pour chacune de ces situations, ce qui se déroule est bien ce qui est attendu pour la situation considérée. Un tel test suit une approche raisonnée systématique à base de tests unitaires.
Une telle approche rencontre ses limites dans les circuits électroniques complexes, du fait de la multiplicité des situations à envisager et de la difficulté à les envisager toutes, notamment : multiplicité des ressources, des chemins de données, des opérateurs ; comportements concurrents des différents opérateurs dans l'accès aux ressources mémoire, qui impliquent des arbitrages ; pluralités d'horloges asynchrones en coexistence sur le même circuit. Cette dernière particularité est très pénalisante pour l'approche raisonnée systématique à base de test unitaire car : la complexité combinatoire résultant des relations de phase entre les horloges asynchrones est liée à un phénomène physique continu et non plus discret ce qui implique une quantité non dénombrable de situations différentes, - la phase respective des horloges asynchrones n'est généralement pas contrôlable.
Dans le même temps, la vérification du bon fonctionnement des circuits électroniques définis pour réaliser des fonctions critiques est encore compliquée par l'utilisation de composants dits COTS, par opposition à des composants conçus spécifiquement pour l'application, nécessairement plus chers. L'utilisation de composants COTS permet de répondre à la demande pressante du marché de réduire les coûts. En contrepartie, elle impose que les vérifications effectuées soient particulièrement efficaces à tester le comportement de ces composants dans des situations critiques, pour palier au manque de données de conception complètes sur ces composants COTS.
Enfin le recours à des outillages de test externes pour vérifier les données émises sur les liens de communication externes (liaisons série, réseaux...) est une solution complexe à mettre en oeuvre notamment pour les aspects de synchronisation. Un objet de l'invention est ainsi de proposer une démarche innovante de vérification des chemins de données, et facile de mise en oeuvre, qui permette de certifier avec un fort niveau de confiance l'absence de défauts conceptuels dans un circuit électronique, plus particulièrement dans les circuits électroniques complexes. Dans l'invention, on montre que la vérification du bon fonctionnement opérationnel d'un circuit électronique peut être assurée par la vérification du bon déroulement des échanges de données en toute situation. Dans l'invention, la vérification du bon déroulement des échanges de données en toute situation repose sur une utilisation d'invariants associés à l'espace de mémoire partagée : taille de blocs de données et contenu initial de blocs de données, et sur des opérations de transferts de ces blocs de données sur les opérateurs de transfert de données, définies de façon aléatoire ou pseudo-aléatoire, qui permettent de vérifier facilement et dans tout le domaine d'application, ou d'usage, des opérateurs, que les échanges de données par ces opérateurs sur les ressources mémoire partagées se font correctement. L'invention concerne donc un procédé de test d'un circuit électronique comportant une pluralité d'opérateurs de transferts de données opérant sur des ressources mémoire définissant un espace mémoire partagé, caractérisé en ce qu'il comprend : - une phase d'initialisation dudit espace mémoire, dans laquelle chaque adresse de l'espace mémoire partagé est initialisée avec une donnée qui est unique dans ledit espace mémoire, - une phase de définition d'un scénario de test comprenant un partitionnement de tout ou partie dudit espace mémoire en une pluralité de blocs de mémoire disjoints, organisés en groupes de blocs, au moins un groupe, tel que ^ un bloc appartient à un seul groupe; et ^ les blocs d'un groupe ont tous la même taille; et au moins une phase d'exécution d'un scénario de test comprenant au moins une opération de transfert de données, chaque transfert de données étant un transfert défini sur un opérateur de transfert donné et sur un groupe de blocs donné, pour écrire le contenu d'un bloc source, dans un bloc destination du même groupe; une phase de vérification, pour vérifier que le contenu de l'espace mémoire partagé correspond au dit scénario exécuté. Avec un scénario de test exécuté selon le procédé de test de l'invention, les patterns se déplacent au sein d'un groupe, de bloc en bloc. Si l'exécution des transferts demandés se déroule correctement, les patterns seront déplacés sans déformation dans le groupe, et le contenu mémoire dans les autres zones de l'espace mémoire non concernées par ces transferts ne seront pas affectés. La phase de vérification vérifie ainsi le contenu l'espace mémoire partagé dans les zones mémoire sur lesquelles des opérations de transfert sont exécutées et dans les autres zones mémoires, normalement non concernées. Avantageusement, chaque donnée d'initialisation est une fonction bijective de cette adresse, en sorte qu'après initialisation le contenu mémoire à chaque adresse non affectée par des transferts de données est facilement connu ou déterminable à partir de l'adresse. Avantageusement, la phase de partitionnement comprend en outre une indexation des blocs par un index initial identifiant de façon bijective, un pattern unique égal à l'ensemble des données d'initialisation du bloc correspondant, et une initialisation d'une table de mouvement pour chaque groupe, ladite table comprenant pour chaque bloc, un index courant initialisé avec ledit index initial. L'association d'un index initial à chaque bloc dans un groupe, index qui est une fonction bijective du pattern initial de ce bloc, facilite la vérification du contenu de chaque bloc du groupe en relation avec la table de mouvement associée : chaque nouveau transfert effectué sur le groupe y est inscrit, par écriture de l'index courant du bloc source, comme index courant du bloc de destination, en sorte que pour chaque bloc, son contenu physique après la réalisation d'une série d'opérations de transfert est connu ou déterminable, à partir de l'index courant correspondant.
Selon un aspect de l'invention, la table de mouvement d'un groupe a une taille finie quel que soit le nombre de transferts effectués dans le bloc : l'état courant (index courant) de chacun des blocs du groupe est mémorisé, sans mémoire des transferts exécutés précédents. Chaque opération de transfert est définie de façon aléatoire ou quasi aléatoire, par un choix aléatoire ou quasi-aléatoire de l'un au moins des paramètres suivants : un opérateur de transfert, un mode de transfert, un groupe, un bloc source sur ce groupe, un bloc destination sur ce groupe. Ces choix peuvent être contraints par un domaine d'usage associé à chaque opérateur.
D'autres avantages et caractéristiques de l'invention sont détaillés dans la description suivante en référence aux dessins illustrés d'un mode de réalisation de l'invention, donné à titre d'exemple non limitatif. Dans ces dessins : la figure 1 illustre schématiquement un exemple de circuit électronique à opérateurs de transfert opérant sur un espace mémoire partagé; la figure 2 illustre les différentes ressources mémoire de cet espace mémoire partagé; la figure 3 illustre un exemple de partitionnement d'un tel espace mémoire selon l'invention; la figure 4 illustre une table de mouvement associée; la figure 5 illustre un scénario de test de ce circuit électronique basé sur un mécanisme de déplacement de blocs utilisé dans l'invention ; la figure 6 est un organigramme général d'un procédé de test selon l'invention; la figure 7 illustre une table de suivi de l'utilisation des blocs.
L'invention est décrite en relation avec un mode de réalisation 30 appliqué à un exemple d'architecture d'un circuit électronique comprenant un espace mémoire partagé, accessible à différents opérateurs de transferts de données prévus dans le circuit. L'invention ne concerne pas en soi une architecture de circuit électronique. Ces architectures peuvent être très variées selon les 35 applications concernées, et les processeurs et bus utilisés. L'invention 20 25 concerne un procédé de vérification exhaustif des chemins de données dans une architecture de circuit électronique. Nombre de variantes d'architecture de bus, d'opérateurs, existent, en fonction des applications, qui ne peuvent pas être toutes énumérées ici,.... mais auxquelles l'invention peut s'appliquer. La figure 1 illustre à titre d'exemple, une architecture de calculateur de l'état de l'art avec un espace mémoire partagé 1 auquel le procédé de test de l'invention peut avantageusement s'appliquer. L'architecture est organisée autour d'un bus interne ou hôte HB, et différents bus d'extension, suivant des standards bien connus. Dans l'exemple : un premier bus d'extension EB, par exemple un bus de type USB (Universal Serial Bus), sur lequel est connecté une mémoire M2 de type flash EPROM, accessible en lecture/écriture, de 8 Megaoctets dans l'exemple ; et un premier et un deuxième bus d'extension de type PCI (Peripheral Component Interconnect), noté PCI_O et PCI_1. Sur chacun de ces bus d'extension PCI_0, respectivement PCI_1, est connectée une carte mémoire d'extension, M3, respectivement M4, chacune de 8 Megaoctets dans l'exemple. Sur le bus interne HB, on trouve une carte unité centrale CPU, dans l'exemple une unité centrale à mémoires caches de données et instructions séparées (cache de niveau 1); une carte mémoire programme ROM associée ; une carte mémoire vive M1 de type SDRAM (Synchronous Dynamic Ram), de 126 Megaoctets dans l'exemple, et des opérateurs de transferts, autres que le processeur CPU. Dans l'exemple, on a ainsi regroupés dans un bridge (ou pont) deux contrôleurs d'accès direct DMA 0 et DMA 1 permettant de séquencer notamment des transferts entre les mémoires situées de part et d'autre du bridge, un contrôleur d'accès direct mémoire UDMA dont un port est connecté en entrée à un contrôleur USART (Universal Synchronous Transmitter) d'une liaison série LS, et un autre port est connecté à la sortie de ce contrôleur. Comme illustré sous forme de tableau sur la figure 2, l'espace mémoire partagé 1 est formé de zones de mémoires des cartes mémoires mi à M4, définies chacune par leurs adresses de début et de fin. En pratique tout l'espace mémoire de chaque carte n'est pas en ressource partagée. En effet, dans chaque carte mémoire, une petite zone mémoire, typiquement 4 Koctets, est réservée au processeur local de la carte mémoire. Dans l'exemple, la zone [0020_0000 û 06EF_FFFF] de la mémoire M1 est accessible en lecture/écriture en ressource partagée ; la zone [8001_0000 û 807F_FFFF] de la rnémoire M2 et la zone [9001_0000 û 907F FFFF] de la mémoire M3 sont chacune accessibles en lecture/écriture en ressource partagée sur leur bus d'extension respectif, PCI_0 pour M2 et PCI_1 pour M3 ; la zone [9001_0000 û 907F_FFFF] de la mémoire M4 accessible en lecture/écriture en ressource partagée sur le bus d'extension EB. Dans l'architecture illustrée, on a ainsi : - quatre interfaces de données, à savoir la mémoire SDRAM, en lecture/écriture, et les trois bus d'extension : le bus d'extension, en lecture de la mémoire flash M4, et les deux bus d'extension PCI_0 et PCI_1 de lecture/écriture respectivement de la mémoire M2 et de la mémoire M3; et trois opérateurs de transferts matériels: les opérateurs d'accès direct mémoire DMA 0, DMA_1, UDMA , et un ensemble non borné d'opérateurs de transferts logiciels implémentés comme des routines séquentiellement lancées et exécutées par le processeur de la CPU.
Le procédé de test de l'invention comprend une phase d'initialisation de l'espace mémoire partagé par des données, chaque donnée écrite à une position de l'espace mémoire étant unique dans l'espace mémoire. Avantageusement, cette donnée est définie par une fonction bijective de l'adresse de cette position mémoire. Puis une phase de partitionnement de l'espace mémoire partagé est activée, dans laquelle des blocs de différentes tailles sont définis dans cet espace, blocs que l'on répartit dans des groupes, au moins un groupe, avec les règles suivantes : un groupe ne comporte que des blocs de taille identique ; et un bloc appartient à un seul groupe. Une phase de définition et d'exécution d'un scénario est réalisée, pour exécuter au moins une opération de transfert de données sur l'espace mémoire partagé, chaque transfert étant défini sur un groupe et un opérateur, pour faire lire le contenu d'un bloc de ce groupe et l'écrire dans un bloc du même groupe, par cet opérateur.
Le partitionnement des blocs est paramétrable. Il est défini pour au moins scénario. Pour permettre des déplacements des patterns sans déformation, indépendamment les uns des autres, le partitionnement est réalisé de 5 manière à ce que. les blocs soient tous disjoints : il n'y a pas de chevauchement de blocs. Selon le partitionnement réalisé, les blocs définis dans une phase de découpage peuvent ne pas recouvrir tout l'espace mémoire partagé. Le découpage est réalisé pour permettre le test des différentes 10 fonctionnalités des opérateurs. Notamment, comme illustré sur la figure 3 : un groupe pourra contenir des blocs de même taille mais d'alignements différents : par exemple des blocs auront une adresse de début modulo 8, d'autres blocs pourront avoir une adresse de début modulo 3. Ceci permet de tester la capacité 15 d'un ou des opérateurs à réaliser des transferts de blocs d'alignement variés ; la taille associée à un groupe est choisie pour permettre de tester des transferts de blocs de données autour des tailles limites. Par exemple, si comme paramètre de transfert d'un 20 opérateur, on a une taille maximum de blocs de 256 octets, on peut prévoir un groupe où la taille des blocs est de 255 octets, un autre ou ce sera 256, un autre ou ce sera 257. Ceci permet de tester les situations limites du domaine d'usage de cet opérateur. 25 Dans un procédé de test selon l'invention, on a vu que l'espace mémoire partagé est initialisé avec une donnée unique par position mémoire. Ainsi, chaque bloc est initialisé avec un contenu ou pattern unique égal à l'ensemble des données d'initialisation contenues dans ce bloc. 30 Chaque transfert opère sur un seul groupe, pour copier le contenu d'un bloc dans un autre bloc du même groupe. Les blocs étant disjoints, ils sont véritablement les objets élémentaires transférés. Le contenu de chaque bloc étant unique, dans le cas où l'on met en oeuvre des transferts avec conservation de l'ordre des octets, et que le circuit électronique fonctionne 35 correctement, le pattern à l'Intérieur des blocs se déplace, sans se déformer, au cours des transferts. A chaque transfert effectué, une information correspondante peut être inscrite dans une table de mouvement en sorte qu'après une série de transferts, le pattern qui devrait être contenu dans chaque bloc du groupe est connu ou déterminable, et peut être comparé au pattern effectivement trouvé dans chacun des blocs. S'il y a une quelconque différence, c'est que le fonctionnement n'est pas correct. Selon une mise en oeuvre avantageuse de l'invention, on prévoit : d'associer à chacun des blocs d'un groupe, un index initial permettant d'identifier de façon bijective, ce pattern unique. Cet index initial est unique : unique dans l'espace partagé 1 ou unique dans son groupe, chaque groupe étant identifié de manière unique dans l'espace partagé. d'associer à chaque groupe une table de mouvement, contenant pour chaque bloc, un index courant. Au départ, les index courants sont les index initiaux des blocs. Ensuite, chaque transfert d'un bloc d'un groupe dans un bloc de ce groupe, provoque une écriture de l'index du bloc source comme index courant du bloc destination. Ceci permet une phase de vérification efficace des contenus des blocs des différents groupes, par lecture pour chaque bloc de l'index courant, qui identifie de façon unique le pattern que devrait contenir le bloc à ce moment.
En illustration de ceci, considérons un groupe GO de cinq blocs BO à B4. On indexe les blocs : à chaque bloc correspond un index n du bloc n=0 à 4 dans l'exemple. Chaque bloc Bn contient après initialisation de l'espace mémoire partagé, un pattern unique pn : p0 à p4, pour BO à B4 dans l'exemple. Les patterns sont le contenu physique des blocs : c'est à dire que le pattern d'un bloc comprend toutes les valeurs de tous les octets ou mots ou double mots (selon la structure mémoire) de ce bloc. Après initialisation, le pattern de chaque bloc est ainsi une fonction bijective de l'index du bloc qu'il initialise. L'index 0 identifie de façon unique le pattern p0 par exemple, plus généralement l'index n identifie de façon unique le pattern pn.
Selon l'invention, on peut ainsi identifier le contenu physique pn des blocs par son contenu logique n. Dans une table de mouvement, chaque transfert d'un bloc source, dans un bloc de destination, peut être inscrit de façon simple, par la fonction de transfert correspondante, en écrivant dans la table le nouveau contenu logique du bloc d'arrivée, c'est à dire l'index du bloc source. Ce contenu logique définit de façon certaine le contenu physique que devrait avoir le bloc destination à l'issue de ce transfert. A la suite d'une série de transferts, le dernier contenu logique de chaque bloc permet d'identifier de façon certaine le contenu physique qu'il devrait avoir. Illustrons ceci par un exemple pratique, en relation avec la figure 4 : On prend un groupe GO qui comprend cinq blocs BO à B4 d'index respectif 0 à 4. Chaque index 0, 1, 2, 3, 4 identifie de façon unique (relation bijective) un pattern correspondant p0, p1, p2, p3, p4. Supposons que le scénario de test S(T) comprend la série d'opérations de transferts suivantes, sur le groupe GO : ~o transfert du contenu du bloc B1 dans BO par l'opérateur DMA_O; transfert du contenu du bloc B3 dans B2 par l'opérateur UDMA; transfert du contenu du bloc B4 dans BO par l'opérateur DMA 0; transfert du contenu du bloc B2 dans B4 par l'opérateur DMA O. On note à cette occasion que les transferts d'une série peuvent 15 selon les cas, être réalisés simultanément ou en séquence. Suivant les principes énoncés plus haut, une table de mouvement correspondante TAB(GO) est construite, illustrée sur la figure 4, qui est mise à jour par chacun des opérateurs responsable des transferts effectués. Après le dernier transfert, on peut lire dans la table de mouvement, que : 20 le contenu logique de BO est l'index 4; le contenu logique de B1 est l'index 1; le contenu logique de B2 est l'index 3; le contenu logique de B3 est l'index 3; le contenu logique de B4 est l'index 3. 25 Comme on peut le voir sur la figure 4, à chaque stade, l'état courant de la table de mouvement comprend deux index identiques pour deux blocs différents, le bloc source et le bloc destination, correspondant à l'index du bloc source du transfert effectué. 30 Ainsi, une phase vérification à la suite de ces trois transferts devra vérifier que les contenus physiques des blocs correspondent aux contenus logiques indiqués dans la table de mouvement, c'est à dire ici que le contenu physique de BO est bien le pattern p4 ; celui de B1, p1; celui de B2, p3; celui de B3, p3 ; et celui de B4, p3.
Dans cet exemple, on peut remarquer que les patterns p0 et p2 ont irrémédiablement disparus du groupe. En pratique, il est utile d'établir des règles de transfert dans un groupe, par lesquelles on limite l'appauvrissement des patterns.
Ceci peut être avantageusement obtenu en mettant en oeuvre un mécanisme de type jeu de taquin sur chaque groupe, mécanisme par lequel un unique pattern est sacrifié qui est celui du bloc qui sera le bloc de destination du premier transfert effectué, les déplacements devant satisfaire la règle suivante : le bloc source de chaque transfert devient le bloc destination du transfert suivant. Par ce mécanisme, on contraint l'espace des possibilités des transferts, mais en contrepartie, on peut réaliser un très grand nombre de transferts de blocs sur un groupe de taille finie. L'appauvrissement des patterns du groupe est limité au pattern d'un seul bloc.
Ce mécanisme suppose qu'un transfert ne soit exécuté qu'une fois le transfert précédent soit réalisé. Ceci peut être contrôlé au moyen d'un mécanisme simple qui consiste à ajouter un indicateur d'état réservé ou non d'un bloc, comme il sera détaillé plus loin. Une illustration de ce mécanisme de définition des transferts est donnée sur la figure 5, qui donne l'état d'une table de mouvement associé au groupe GO comprenant cinq blocs BO, B1, B2, B3, B4, chacun indexé par un index correspondant égal respectivement à 0, 1, 2, 3 et 4. Dans l'exemple qui est illustré, le bloc de destination du premier transfert exécuté est B1 : le contenu initial p1 de ce bloc va être sacrifié. 25 Tous les déplacements sont régis par la règle précitée R1. TO (B3--B1) Tl (BOù>B3) T2(B2ù>BO) T3(B1ù>B2) A la fin l'état courant des index pour les blocs BO, B1, B2, B3 et B4 sont respectivement 2, 3, 3, 0, 4. Comme on peut le voir, un seul pattern est sacrifié : le pattern p1 30 du bloc B1 de destination du premier transfert. Les transferts ayant comme particularité que leur bloc de destination est le bloc source du transfert précédent, le bloc "sacrifié" (gris foncé sur la figure 5) se déplace dans le sens inverse des transferts effectués. Comme illustré sur les figures 4 et 5, le contenu de la mémoire 35 peut être vérifié facilement après une séquence quelconque de transferts selon un procédé de test suivant l'invention, grâce au suivi continu des mouvements des patterns par la table de mouvement associée au groupe : il suffit de vérifier que le contenu physique d'un bloc est bien cohérent avec le contenu logique indiqué dans la table de mouvements. Ainsi, la phase de vérification du contenu des blocs n'a besoin que de la table de mouvement, qui est mise à jour automatiquement par les fonctions de transfert des opérateurs, au fur et à mesure de leur réalisation, et de la relation bijective entre chaque index et le pattern associé. Cette relation peut être accessible par exemple par une table donnant pour chaque bloc, l'index initial. Les adresses de début et de fin de chaque bloc peuvent être lues dans une table de partitionnement. Comme la donnée d'initialisation est unique pour chaque adresse, et avantageusement une fonction bijective de cette adresse, on peut connaître ou déterminer cette donnée en chaque position du bloc. Cette phase de vérification est doncavantageusement simple à mettre en oeuvre. Son écriture ne dépend pas en soi des transferts qui sont effectués ni des opérateurs qui réalisent ces transferts. Elle est écrite une fois pour toutes et est opérationnelle pour vérifier n'importe quelle séquence de transferts. En particulier, elle reste valable même pour des séquences de transfert définies aléatoirement (en prenant garde au fonctionnement concurrent des opérateurs de transfert). En pratique, l'algorithme de test avec ses différentes tables de partitionnement, d'index initiaux, de mouvement et autres nécessitées par le procédé de test sont exécutées en mémoire de travail du processeur : SDRAM ou avantageusement en mémoire cache.
De façon plus générale, un procédé selon l'invention peut comprendre plusieurs phases en séquence, avec des possibilités de rebouclage en certains points de la séquence, comme illustré de manière schématique sur l'organigramme de la figure 6. Cet organigramme indique des phases clefs du procédé de test 30 qui sont les suivantes : • "I": phase d'initialisation de l'espace mémoire partagé 1 avec des données telle qu'à chaque adresse de l'espace mémoire, la donnée est une fonction bijective de cette adresse; • "P": phase de partitionnement de l'espace mémoire, pour définir les groupes, les blocs des groupes, et initialiser la table de mouvement de chaque groupe. • "T": phase de définition et exécution d'un scénario de transfert 5 • "V": phase de vérification que le contenu de l'espace mémoire correspond au scénario exécuté. Cette phase de vérification "V" comprend principalement : • la lecture des différents registres d'état des opérateurs de transfert sollicités par le test, pour vérifier l'absence de signalisation d'erreurs; 10 • la vérification que dans les zones de mémoire de l'espace mémoire hors des groupes de blocs sur lesquels le scénario s'exécute, les données n'ont pas changé. • la vérification des contenus physiques des blocs dans les groupes. Cette vérification utilise avantageusement les tables de mouvement 15 précédemment décrites.
Cet organigramme indique aussi une phase "G" d'initialisation des opérateurs de transfert, préalable à la phase de partitionnement "P", pour initialiser les paramètres de transfert des opérateurs tels que notamment : 20 mode de transfert, taille des grains (blocs) du transfert, détection d'erreur, l'activation ou non d'un mécanisme de correction d'erreur, la création ou non d'erreurs corrigibles par le dit mécanisme, des temps de réponse de composants électroniques (paramètre "latency timer" du composant PCI , et paramètre "CAS latency" d'une SDRAM, ...). 25 Cette phase du test a son importance pour couvrir le domaine d'usage des opérateurs. En effet les choix aléatoires ou quasi-aléatoires opérés dans la phase de partitionnement de l'espace mémoire partagé et de définition des opérations de transferts du ou des scénarios, peuvent être contraints pour couvrir au mieux le domaine d'usage des opérateurs, qui est 30 en partie défini par les paramètres de transferts de ces opérateurs. Le procédé permet ainsi avantageusement l'exécution de trois boucles de test dont les entrées dans l'organigramme sont notées "T", "P" et "G", permettant de tester l'ensemble des domaines d'usage des différents opérateurs de transfert sur l'ensemble de l'espace mémoire partagé.
La première boucle "T", la plus interne, permet d'exécuter plusieurs séries d'opérations de transfert, avec une étape de vérification (V) entre deux séries. Ce peuvent être des opérations prédéfinies, ou aléatoires ou quasi-aléatoires. L'aspect aléatoire peut concerner : le groupe et/où les blocs sur lequel s'opèrent le transfert, et/ou l'opérateur qui doit réaliser le transfert. La boucle médiane "P" permet de modifier des paramètres du scénario découlant du partitionnement de l'espace mémoire partagé, _ définition du nombre de groupes, de leurs tailles ; définition des blocs : nombre de blocs par groupe, alignements des blocs dans chaque groupe_, avant de relancer un ou plusieurs scénarios d'une ou plusieurs opérations de transfert. La boucle la plus externe "G" permet de changer des paramètres de fonctionnement des opérateurs : taille maximum des blocs par opération, mode de transfert (interruption ou scrutation), correction d'erreur .... On notera que le terme "boucle" est à prendre au sens large dans le contexte de l'invention, signifiant tout retour en arrière dans les étapes de l'organigramme. La répétition d'une boucle n'est pas nécessairement une répétition d'une même séquence d'opérations (boucles "for", qui s'écrivent pour n= 1 à N, exécuter les opérations qui suivent ), mais plus généralement d'un même type d'opérations. Deux passages dans la même boucle peuvent ainsi être identiques (boucle for) ou différents, selon l'écriture du scénario. Notamment, dans le cas de transferts de type aléatoires, deux passages dans une boucle s'écriront en séquence, par exemple comme suit : Pour i = 1 à k, (T) transfert aléatoire transfert aléatoire (V) Vérification (R) retour à (T) Toutes lies boucles se terminent par une étape de vérification, chaque boucle correspondant à un scénario de test. On notera qu'une phase de vérification associée à un scénario ne peut être démarrée qu'après la fin de tous les transferts de ce scénario. La définition du test doit en pratique tenir compte des domaines d'usage des différents opérateurs. Par exemple, les tailles de blocs sont définies dans un ou plusieurs partitionnement (répétition de la boucle "P") pour couvrir les différents modes de transfert des opérateurs. Si un opérateur est défini pour transférer des données par blocs de 128 bits, des blocs et leur(s) groupe(s) seront définis avec cette taille, et des tailles un peu inférieures (126 bits par exemple) ou un peu supérieures (129 bits par exemple), pour tester les opérateurs en limite de leurs domaines d'usage. De même, au sein d'un groupe, on prévoit avantageusement des alignements d'adresse différents, qui permettent de tester les opérateurs dans toutes les situations qui en découlent.
Par ailleurs, certains opérateurs étant concurrents, par exemple les automates programmables d'accès direct mémoire (DMA 0 et DMA 1) et le processeur CPU dans l'exemple de la figure 1, l'écriture ou la gestion de l'exécution d'un scénario doit permettre : d'empêcher que plusieurs opérateurs de transfert accèdent en même 15 temps au même bloc de données. de vérifier que l'exécution d'un transfert par un opérateur ne débute qu'après qu'un premier transfert soit terminé, lorsque par exemple le bloc source du second transfert est le bloc destination ou résultat du premier transfert, comme dans le mécanisme précédemment décrit en relation 20 avec la figure 5. Ceci peut se faire en prévoyant une table de suivi de l'utilisation des blocs, comprenant une information R d'état réservé ou non associée à chaque bloc. Cette information logique R peut ainsi être à l'état 0, ou à l'état 1, signifiant respectivement, dans un exemple de convention, état libre, ou 25 occupé. Une telle table de suivi TAB_R est illustrée en exemple sur la figure 7. Cette table est consultée par les opérateurs de transfert avant d'effectuer un transfert. Cette table de suivi peut aussi être avantageusement utilisée en scrutation pour activer la phase de vérification à la suite d'un scénario S(T), 30 pour qu'elle ne débute que lorsque tous les blocs sont à l'état non réservé. Un transfert ne peut débuter que si au moins le bloc destination est à l'état non réservé, pas nécessairement le bloc source (on peut généralement faire plusieurs accès en lecture simultanément). Dans le cas où le transfert dépend de l'exécution d'un transfert 35 précédent comme indiqué plus haut, il faudra que le bloc source et le bloc destination concernés par une opération de transfert, soient tous les deux à l'état non réservé (R=O). Ceci sera par exemple le cas si le scénario met en oeuvre un scénario de transferts définis selon le mécanisme de type jeu de taquin décrit précédemment en relation avec la figure 5.
En ce qui concerne les opérateurs de transferts eux même, outre les précautions à prendre pour les opérations concurrentes à réaliser, d'autres précautions peuvent être prises en pratique. Notamment, s'agissant d'un contrôleur UART de liaison série LS associé à un automate de transfert direct mémoire UDMA (figure 1), il serait trop complexe de mettre en oeuvre un outillage externe pour vérifier des données émises par le contrôleur UART ou pour envoyer des données sur ce contrôleur, principalement à cause des problèmes de synchronisation. On prévoit en pratique d'utiliser cet automate avec le contrôleur UART, rebouclé sur lui-même, l'entrée de la liaison série du contrôleur étant rebouclée sur la sortie de cette liaison (liaison cc sur la figure 1). L'automate UDMA est alors initialisé pour opérer à la fois en transmission sur un port associé à la ligne de transmission de la liaison série et en réception sur un autre port associé à la ligne de réception de la liaison série, avec la même longueur : Ainsi utilisé, l'UDMA est équivalent à un DMA SDRAM / SDRAM.
Ce mode de d'utilisation du contrôleur de liaison série a pour effet une petite restriction de couverture du domaine d'usage du contrôleur. Néanmoins, la transmission fonctionne seule pendant un court instant au début, avant que l'automate reçoivent ses premières données via l'entrée de la liaison série. De même, à la fin, l'émission fonctionne seule pendant que le contrôleur en transmission vide sa mémoire tampon après que l'automate ait terminé son opération. Enfin, on prévoira avantageusement une étape de vérification de l'absence de biais dans la distribution statistique des événements accumulés dans des histogrammes lors de l'exécution du procédé de test. Pour cela on prévoit la création d'histogrammes d'évènements correspondants aux opérations de transfert (transferts effectués et paramètres de transfert associés) réalisées lors de l'exécution du test. Pour cette opération on identifiera en pratique les caractéristiques importantes des opérateurs dont on tracera des histogrammes, typiquement en notant la liste des opérateurs, les tirages des paramètres effectués, et en échantillonnant l'état courant des opérateurs. On obtient ainsi des marqueurs statistiques dont on peut vérifier qu'ils se comportent comme attendu, permettant de vérifier que les différents tirages aléatoires ont permis de parcourir le domaine qui devait être parcouru, sans biais. Notamment, on peut détecter un mauvais parallélisme d'opérateurs. Un procédé de test selon l'invention permet par la vérification des chemins de données du circuit électronique sur sensiblement tous les ~o domaines d'usage des opérateurs et en conditions limites, de certifier le bon fonctionnement opérationnel d'un circuit électronique complexe.

Claims (17)

REVENDICATIONS
1. Procédé de test d'un circuit électronique comportant une pluralité d'opérateurs de transferts de données opérant sur des ressources mémoire définissant un espace mémoire partagé (1), caractérisé en ce qu'il comprend une phase d'initialisation (I) dudit espace mémoire, dans laquelle chaque adresse de l'espace mémoire partagé est initialisée avec une donnée qui est unique dans ledit espace mémoire, une phase de définition (P) d'un scénario de test comprenant un partitionnement de tout ou partie dudit espace mémoire en une pluralité de blocs (BO, B1, B2) de mémoire disjoints, organisés en groupes de blocs (GO, G1), au moins un groupe, tel que ^ un bloc appartient à un seul groupe; et ^ les blocs d'un groupe ont tous la même taille; et au moins - une phase d'exécution (T) d'un scénario de test S(T) comprenant au moins une opération de transfert de données, chaque transfert de données étant un transfert défini sur un opérateur de transfert donné et sur un groupe de blocs donné, pour écrire le contenu d'un bloc source, dans un bloc destination du même groupe; une phase de vérification (V), pour vérifier que le contenu de l'espace mémoire partagé correspond au dit scénario exécuté.
2. Procédé de test selon la revendication 1, caractérisé en ce que chaque donnée d'initialisation est une fonction bijective de cette adresse.
3. Procédé de test selon la revendication 1 ou 2, caractérisé en ce que la phase de partitionnement comprend une indexation des blocs par un index initial (n) identifiant de façon bijective, un pattern unique (pn) égal à l'ensemble des données d'initialisation d'un bloc correspondant (Bn), et une initialisation d'une table de mouvement associée à chaque bloc, comprenant pour chaque bloc, un index courant initialisé avec ledit index initial, en ce que dans la phase d'exécution (T) d'un scénario, chaque transfert de donnée entraîne une écriture de l'index courant dudit bloc source comme indexcourant dudit bloc destination dans une table de mouvement associé au dit groupe.
4. Procédé de test selon la revendication 3, caractérisé en ce que ladite 5 table de mouvement associée à chaque bloc à une taille finie.
5. Procédé de test selon l'une des revendications 1 à 4, caractérisé en ce qu'il comprend en outre une phase d'initialisation (G) des opérateurs de transfert, préalable à la dite phase de partionnement, pour initialiser des 10 paramètres de transfert de chaque opérateur.
6. Procédé de test selon l'une des revendications 1 à 5, caractérisé en ce que chaque phase de vérification (V) comprend une vérification que le contenu des blocs de chaque groupe correspond aux opérations de 15 transferts dudit scénario S(T) exécuté.
7. Procédé de test selon la revendication 1 à 6, caractérisé en ce que chaque phase de vérification comprend une vérification que le contenu de zones de l'espace rnémoire partagé hors de tout groupe, correspond aux 20 données écrites dans ladite phase d'initialisation (I).
8. Procédé de test selon la revendication 1, dans lequel chaque opération de transfert est définie de façon aléatoire ou quasi aléatoire, par un choix aléatoire ou quasi-aléatoire de l'un au moins des paramètres suivants : un 25 opérateur de transfert, un mode de transfert, un groupe, un bloc source sur ce groupe, un bloc destination sur ce groupe;
9. Procédé de test selon la revendication 8, caractérisé en ce que ledit choix aléatoire ou quasi-aléatoire est contraint par un domaine d'usage associé à 30 chaque opérateur.
10. Procédé de test selon la revendication 8 ou 9, caractérisé en ce que le choix aléatoire ou quasi-aléatoire est contraint par une règle de déplacement des blocs dans un groupe, selon laquelle le bloc source de chaque transfert 35 devient le bloc destination du transfert suivant.
11. Procédé de test selon la revendication 1, caractérisé en ce que la phase de partitionnement (P) comprend une définition de groupes de différentes tailles, et de blocs avec des alignements différents au sein d'un même groupe.
12. Procédé de test selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comprend une première boucle de test (T) pour exécuter une pluralité de scénarios les uns après les autres, comprenant au moins une phase de vérification (V) à la fin de chaque scénario. 10
13. Procédé de test selon la revendication 11, caractérisé en ce qu'il comprend une deuxième boucle de test (P) pour modifier le partitionnement entre deux scénarios. 15
14. Procédé de test selon la revendication 12 ou 13, caractérisé en ce qu'il comprend une troisième boucle de test (G) pour modifier les paramètres de transfert et/ou le partitionnement entre deux séries de transferts.
15. Procédé de test selon l'une quelconque des revendications précédentes, 20 caractérisé en ce qu'il comprend la mise à jour d'une table d'occupation des blocs de l'espace mémoire partagé (TAB_R) indiquant pour chaque bloc, si il est réservé par une opération de transfert ou non, ladite table étant consultée par les opérateurs de transfert avant d'effectuer un transfert. 25
16. Procédé de test selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comprend la création d'histogrammes d'évènements correspondant aux opérations de transfert, et une étape de vérification de l'absence de biais dans la distribution statistique des événements accumulés dans lesdits histogrammes lors de l'exécution du procédé de test. 30
17. Système de certification d'un circuit électronique, caractérisé en ce qu'il met en oeuvre un procédé selon l'une quelconque des revendications précédentes. 35
FR0705381A 2007-07-24 2007-07-24 Procede de test des chemins de donnees dans un circuit electronique Expired - Fee Related FR2919401B1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
FR0705381A FR2919401B1 (fr) 2007-07-24 2007-07-24 Procede de test des chemins de donnees dans un circuit electronique
US12/173,278 US7913129B2 (en) 2007-07-24 2008-07-15 Method of testing data paths in an electronic circuit

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR0705381A FR2919401B1 (fr) 2007-07-24 2007-07-24 Procede de test des chemins de donnees dans un circuit electronique

Publications (2)

Publication Number Publication Date
FR2919401A1 true FR2919401A1 (fr) 2009-01-30
FR2919401B1 FR2919401B1 (fr) 2016-01-15

Family

ID=39153958

Family Applications (1)

Application Number Title Priority Date Filing Date
FR0705381A Expired - Fee Related FR2919401B1 (fr) 2007-07-24 2007-07-24 Procede de test des chemins de donnees dans un circuit electronique

Country Status (2)

Country Link
US (1) US7913129B2 (fr)
FR (1) FR2919401B1 (fr)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2946815B1 (fr) * 2009-06-12 2011-06-17 Thales Sa Procede d'acquisition d'une pluralite de signaux logiques, avec confirmation de validite d'etat
CN103389920B (zh) * 2012-05-09 2016-06-15 深圳市腾讯计算机系统有限公司 一种磁盘坏块的自检测方法和装置

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1988009554A1 (fr) * 1987-05-29 1988-12-01 Siemens Aktiengesellschaft Procede et agencement de controle automatique de memoires vives organisees par mots
JPH01251400A (ja) * 1988-03-30 1989-10-06 Toshiba Corp Ramのチェック方法
EP0919917A2 (fr) * 1997-11-07 1999-06-02 Alcatel Procédé de test de la mémoire tampon d'un system micro-processeur
US7167405B1 (en) * 2005-09-19 2007-01-23 Lattice Semiconductor Corporation Data transfer verification systems and methods

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2029986B (en) * 1978-09-13 1983-02-02 Hitachi Ltd Sequence control system
US4825360A (en) * 1986-07-30 1989-04-25 Symbolics, Inc. System and method for parallel processing with mostly functional languages
US6381682B2 (en) * 1998-06-10 2002-04-30 Compaq Information Technologies Group, L.P. Method and apparatus for dynamically sharing memory in a multiprocessor system
US6665777B2 (en) * 2000-07-26 2003-12-16 Tns Holdings, Inc. Method, apparatus, network, and kit for multiple block sequential memory management

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1988009554A1 (fr) * 1987-05-29 1988-12-01 Siemens Aktiengesellschaft Procede et agencement de controle automatique de memoires vives organisees par mots
JPH01251400A (ja) * 1988-03-30 1989-10-06 Toshiba Corp Ramのチェック方法
EP0919917A2 (fr) * 1997-11-07 1999-06-02 Alcatel Procédé de test de la mémoire tampon d'un system micro-processeur
US7167405B1 (en) * 2005-09-19 2007-01-23 Lattice Semiconductor Corporation Data transfer verification systems and methods

Also Published As

Publication number Publication date
FR2919401B1 (fr) 2016-01-15
US7913129B2 (en) 2011-03-22
US20090027981A1 (en) 2009-01-29

Similar Documents

Publication Publication Date Title
CN111213340B (zh) 选择用于密码功能的证明委托并使其安全
TWI344087B (en) Serial ata port addressing
US8478982B2 (en) Media access control security management in physical layer
US9921914B2 (en) Redundant array of independent disks (RAID) write hole solutions
US8135869B2 (en) Task scheduling to devices with same connection address
CN109992285B (zh) 区块链代码块独立升级方法、装置及电子设备
EP1617335A1 (fr) Procédé de programmation d'un contrôleur de DMA dans un système sur puce et système sur puce associé
WO2011070262A1 (fr) Controleur d'acces dircet a une memoire pour le transfert direct de donnees entre memoires de plusieurs dispositifs peripheriques
US8626965B2 (en) Using a DMA engine to automatically validate DMA data paths
CN111459948B (zh) 一种基于中心化块链式账本的交易完整性验证方法
CN116243959A (zh) 大规模对象版本控制和一致性的实现方式
FR3003054A1 (fr) Procede et dispositif de filtrage de transactions pour systeme sur puce
CN112291321B (zh) 业务处理方法、装置及系统
TW201106150A (en) Memory testing with snoop capabilities in a data processing system
EP2507712B1 (fr) Systeme autorisant des transferts directs de donnees entre des memoires de plusieurs elements de ce systeme
FR2919401A1 (fr) Procede de test des chemins de donnees dans un circuit electronique
JP7189952B2 (ja) エラー・ハンドリングのための方法、コンピュータ・プログラム、データ処理システム、およびエラー・ハンドリング・コンポーネント
CN114443516A (zh) 接口电路、包括接口电路的处理器以及处理包的方法
CN114550773A (zh) 存储器控制器、存储系统和数据处理方法
Spæren Performance analysis and improvements for Apache Beam
US11263164B1 (en) Multiple field programmable gate array (FPGA) based multi-legged order transaction processing system and method thereof
EP3531419A1 (fr) Procédé de gestion du routage de transactions entre des équipements sources, au moins un équipement cible, par exemple une mémoire multiports, et système sur puce correspondant
EP2652624B1 (fr) Procede, programme d'ordinateur et dispositif de gestion d'acces memoire dans une architecture multiprocesseurs de type numa
EP2717163B1 (fr) Procédé et dispositif de sauvegarde d'un état d'un circuit sous test émulé dans un émulateur et de son environnement de test logiciel, et procédé et dispositif de restauration correspondants
US20230028407A1 (en) In-band modification of event notification preferences for server events

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 9

PLFP Fee payment

Year of fee payment: 10

PLFP Fee payment

Year of fee payment: 11

PLFP Fee payment

Year of fee payment: 12

PLFP Fee payment

Year of fee payment: 14

PLFP Fee payment

Year of fee payment: 15

PLFP Fee payment

Year of fee payment: 16

ST Notification of lapse

Effective date: 20240305