Méthode de test et conception en vue du test pour les réseaux sur puce asynchrones :

© CEA 2008. Tous droits réservés. Toute reproduction totale ou partielle sur quelque support que ce soit ou utilisation du contenu de ce document est interdite sans l’autorisation écrite préalable du CEA

All rights reserved. Any reproduction in whole or in part on any medium or use of the information contained herein is prohibited without the prior written consent of CEA

1Xuan-Tu Tran : Soutenance de thèse12/02/2008

Méthode de test et conception en vue du testpour les réseaux sur puce asynchrones :

Application au réseau ANOC

Xuan-Tu TranLe 12 février 2008

M. Christian Landrault (CNRS, UMII, LIRMM)M. Habib Mehrez (UPMC, LIP6)Mme. Chantal Robach (INPG, LCIS)M. Jean Durupt, (CEA-LETI, MINATEC) M. Vincent Beroulle (INPG, LCIS)M. Yvain Thonnart (CEA-LETI, MINATEC)M. Bruno Rouzeyre (UMII, LIRMM)M. Mounir Benabdenbi (UPMC, LIP6)

Rapporteur :Rapporteur :

Directeur de thèse :Co-encadrant :Co-encadrant :Co-encadrant :Examinateur :Examinateur :




Introduction générale de la thèse

CONTEXTE

PROBLÈMES

CONTRIBUTIONS

SoC pour nouvelles applications multimédias, télécoms, etc.

(complexité croissante, besoins accrus de performance)

SoC pour nouvelles applications multimédias, télécoms, etc.

(complexité croissante, besoins accrus de performance)

Architectures NoC + GALS

(NoC asynchrones)

Architectures NoC + GALS

(NoC asynchrones)

Comment tester ces SoC

(complexité, les IP sont profondément

enfouies dans le système)

Comment tester ces SoC

(complexité, les IP sont profondément

enfouies dans le système)

Test des NoC (asynchrones)

(Manque d’outils CAO pour le

test des circuits asynchrones)

Test des NoC (asynchrones)

(Manque d’outils CAO pour le

test des circuits asynchrones)

Proposition d’une architecture

CVT pour les NoC asynchrones

(Conception, Implémentation,

Résultats, etc.)

Proposition d’une architecture

CVT pour les NoC asynchrones

(Conception, Implémentation,

Résultats, etc.)

Mise en œuvre de cette

architecture au réseau ANOC

(Génération des vecteurs de test,

validation, résultats, etc.)

Mise en œuvre de cette

architecture au réseau ANOC

(Génération des vecteurs de test,

validation, résultats, etc.)

Exploitations

supplémentaires

(Diagnostics, Vérification

sur silicium, Test des IP)

Exploitations

supplémentaires

(Diagnostics, Vérification

sur silicium, Test des IP)




Plan de la présentation

Contexte et Motivation Des systèmes sur puce (SoC) aux réseaux sur puce (NoC) Test des systèmes sur puce : synchrones et asynchrones

Proposition d’une architecture CVT pour les NoC asynchrones

Mise en œuvre de l’architecture développée au réseau ANOC

Utilisations alternatives de l’architecture CVT

Conclusions et perspectives




Interconnexions dans les systèmes sur puce (SoC)

Solutions d’interconnexion actuelles et leurs limitations

La limitation de débit, la consommation d’énergie, la synchronisation globale, etc.

goulot d’étranglement dans la conception des SoC.

• Point à point

• Bus partagé

• Bus hiérarchique

µP MEM I/O

IPIP IPIP IPIP

Local busLocal busLocal busLocal bus

Liens dédiés

Bus système Bus

périphérique

Passerelles




Réseau sur Puce : un nouveau paradigme

Introduction aux NoC

Caractéristiques Performance

Découpage communications/

traitements

Efficacité de la gestion d’énergie

Productivité (extensible,

réutilisable)

Synchronisation locale

IPIP

IPIPIPIP

IPIPIPIP

IPIP

RRRR

RRRR

Routeur

Unité de traitement

Lien réseau

RRRR IPIP

IPIPDifférentes horloges

=> GALS

(Globalement Asynchrone, Localement Synchrone)Réseaux sur puce

asynchrones




Logique asynchrone quasi insensible aux délais

Synchronisations locales par poignées de main

Encodage QDI 1 parmi n les données contiennent la requête Autant de signaux de requête

que de valeurs possibles

La porte de Muller implémenteun rendez-vous sur ses entrées

CLogiq

ueDirect

e

Logique

Directe

Logique

Retour

Logique

Retour

CLogiq

ueDirect

e

Logique

Directe

Logique

Retour

Logique

Retour

CLogiq

ueDirect

e

Logique

Directe

Logique

Retour

Logique

Retour

requête

acquittement

requête

acquittement

ProcessusA

ProcessusB

ack

111

Z-101

Z-110

000

ZBA

valeur 2valeur 1valeur 0




ANOC : un réseau sur puce asynchrone (1/3)

Caractéristiques du réseau ANOC

Commutation de paquets

Implémentation en logique asynchrone

quasi-insensible aux délais (QDI)

2 canaux virtuels

SAS : Interface synchrone/asynchrone

NI : Interface réseau

Application au circuit FAUST (2005)

(Flexible Architecture of Unified System for Telecom)

Pour les applications télécoms 4G

ANOC 20 routeurs (topologie : maillage 2D)

23 unités de traitement (IP)

Surface totale : ~ 80mm2 (STM 130nm)

NI

SAS

NI

SAS NI

SAS

NI

SAS

NI

SAS

NI

SAS NI

SAS NI

SAS

NI

SAS

IP IP IP

IP IP IP

IP IP IP

R R R

R R R

R R R





Mécanismes de communication

Format de flits

Message

Paquet(s) (taille variable)

Flit(s) (taille fixée à 34 bits)

BoP EoP Type de flit

1 0 Flit d’en tête

0 0 Flit de donnée

0 1 Flit de fin

1 1 Paquet 1-flit

BoP EoP Payload Path–to-Target

33 32 31 18 17 0

BoP EoP Payload

33 32 31 0

Flit d’en tête

Flit de données ou flit de fin





Routeur du réseau 5 ports d’entrée, 5 ports de sortie, 2 canaux virtuels

Send0/1

Data

Accept0/1

Unité d’entrée

ControlControl

Dem

uxD

emux

VC0

VC1

HPUHPU

Unité de sortie

VC0

VC1

Mux

Mux

ControlControl(HPU : Header Parsing Unit)

ANOCrouter

NORD

EST

RES

SUD

OUEST




Exigences et défis

Qualité de service(latences, fiabilité)

Programmation(ordre de données,

flot de contrôle)Surcoût d’implémentation

(routeur, interface réseau)

Test & Debug(réseau de communication,

unités de traitement)





Contexte et Motivation Des systèmes sur puce (SoC) aux réseaux sur puce (NoC) Test des systèmes sur puce : synchrones et asynchrones








Méthode de test générale pour les SoC

Architecture générale

Générateur des vecteurs

de test (GVT) ; analyseur

des réponses (AR)

Mécanisme d’accès de

test (TAM)

Wrapper de test

IEEE Std. 1500 (2005)

IPSousTest

IPIP

CPUCPU

I/OInterface

I/OInterface

ROMROM

UDLUDL

IPIP

IPIP

Wrapper

SRAMSRAM

TAM TAM TAMTAM

IPIP

GVTGVTARAR




Test des circuits asynchrones

Ad hoc Ajouter des points de contrôle

et d’observation

Utilisation des chaînes de scan Supprimer les fils de rétroactions, Introduire les vecteurs de test, et observer les réponses

Deux approches principales

Chaînes de scan avec une

horloge dédiée [Berk02A, Efth05T]

Chaînes de scan auto-séquencées

[Ronc94P, Petl95S, Khoc95A, Garc98S]

circuit combinatoirecircuit combinatoire

x

op

Point d’observation

x

cp Test

Point de contrôle

DQ0

1

in

scan-inscan-out

TestTst-clk

out

un exemple d’utilisation scan-latch




Test des architectures NoC

Test du réseau (routeurs et liens)

Faible contrôlabilité et observabilité Surtout pour les routeurs éloignés

des entrées/sorties primaires

Réseau en logiques asynchrones

Architecture des routeurs régulière À exploiter

Test des unités de traitement et leurs interfaces réseaux Utilisation des techniques classiques: IEEE 1500, chaîne de scan, etc. Réseau peut être utilisé comme un TAM

Bande passante élevée

Aucun coût supplémentaire pour le TAM

Patterns de test doivent être encapsulés en paquets

R R R

R R R

R R R

IP IP IP

IP IP IP

IP IP IP





Contexte et Motivation

Proposition d’une architecture CVT pour les NoC asynchrones Méthode de test pour les NoC asynchrones Conception et réalisation Implémentation et résultats







Méthode de test pour les NoC asynchrones

Test structurel

Test de production

Technique habituelle Nombreux outils

disponibles

Coût important de test CVT coûteuse en

surface Absence d’outils CAO Back-end difficile

Test fonctionnel

Vérification et/ou test de

production Demande une

connaissance de la fonctionnalité du circuit sous test

Fonctionnalité simple Structure d’interconnexion Vecteurs de test facile à

générer

Faible contrôlabilité,

observabilité Test fonctionnel avec wrappers

Util

isat

ion

clas

siqu

e po

ur c

ircui

ts s

ynch

rone

sA

pplic

atio

n au

xN

oC a

sync

hron

es

[Efth05T, Ronc94P, Petl95S,Garc98S]




Proposition d’une architecture CVT asynchrone

NI

SAS

NI

SASNI

SAS

NI

SAS

NI

SAS

NI

SAS

cfg-in

cfg-out

gac-out

gac-in

GAC unit

Test Wrapper (TW)

Configuration chainWCM

IP-TW

IP IP IP

IP IP IP

R R R

R R R

GAC : Générateur-Analyseur-Contrôleur

WCM : Wrapper Control Module

IP-TW: IP Test Wrapper

SAS : Interface Synchrone/Asynchrone

NI : Interface réseau

R : Routeur






Proposition d’une architecture CVT pour les NoC asynchrones Méthode de test pour les NoC asynchrones Conception et réalisation Implémentation et résultats







Architecture du wrapper de test

5 cellules ITC pour les entrées (ITC : Input Test Cell)

5 cellules OTC pour les sorties(OTC : Output Test

Cell)

Un contrôleur local WCM (WCM : Wrapper

Control Module)

Fonction « bypass »

WCM

OTC-3

ITC-3

ITC-1

OTC-1

ITC-0 OTC-0

ITC-4

OTC-4

OTC-2 ITC-2

Wrapper de test

RouteurANOC

OUEST

RES

EST

SUD

NORD

cfg-in

cfg-out

2

2

34

Bypass

Bypass




Micro architecture de la cellule de test

2 multiplexeurs

2 blocs de séparation

sans contrôle La donnée est présentée

aux deux sorties

Elle n’est utilisée que par

le récepteur qui en a

besoin

S2noc-in

noc-out

cell-in

cell-out

ctrl-mux

ctrl-mode

0

1

10

S1

MODE

MUX

LO CAL

A

B34

34

34

34

(micro-architecture d’une cellule de test)




Micro architecture de la cellule avec « bypass »

Implémentation de la cellule avec la fonction « bypass »

Ajout d’un port de sortie pour les cellules d’entrée

Ajout d’un port d’entrée pour les cellules de sortie

(cellule de test d’entrée - ITC) (cellule de test de sortie - OTC)

S2noc-innoc-out

cell-in

cell-out

ctrl-muxctrl-mode

10

S1

MODE

MUX

LO CAL

bp-out

S2noc-in

noc-out

cell-in

cell-out

ctrl-muxctrl-mode

10

S1

MODE

MUX

LO CAL

bp-in




Construction de la chaîne de configuration

Chaîne de configuration

Check ID Check ID Check ID

ID ok ID ok ID ok

Génération des signaux de contrôle

Générationdes signauxde contrôle

Générationdes signauxde contrôle

GACunit

GACunit

WCM

Cellulesde test

Cellulesde test

Cellulesde test

Cellulesde test

Cellulesde test

Cellulesde test

Décodage TCF

DécodageTCF

DécodageTCF

2 bits

Wrapper 0 Wrapper 1 Wrapper N

WCM WCM




Micro architecture du module WCM

Format d’une configuration de test

Frame ShifterFrame Shifter

EoF Detector

EoF Detector

ID Verifier

ID Verifier

Control GeneratorControl Generator

2 bits 2 bitscfg-in cfg-out

ctrl-mode[i] &

with i = 0..4

ctrl-mux[i]

EoF ID ok

EoF ID [2:0] MOTC-Res ITC-Res OTC-Nord ITC-Nord

24 0






Proposition d’une architecture CVT pour les NoC asynchrones Méthode de test pour les NoC asynchrones Conception et Réalisation Implémentation et résultats







Implémentation et résultats (1/2)

Technologie 65nm de STM avec la bibliothèque TAL065nm du

laboratoire TIMA

Coût en surface

32,7% d’un routeur testable

3 5% de la surface totale d’un SoC

Bande passante Débit max : 20M-vecteurs/s

Débit normal : 10M-vecteurs/s

Latence ajoutée

Latence de communication en mode normal augmentée de 0,17ns par cellule

Débit maintenu

Débit de communication en mode

normal maintenu à 500Mflits/s

routeur197.578µm2

67,30%

5 OTC42.800µm2

14,58%

WCM10.400µm2

3,54%

5 ITC42.800µm2

14,58%




Implémentation et résultats (2/2)

Intégration dans le circuit ALPIN

(Asynchronous Low Power Innovative NoC)

Objectif: valider différentes techniques autour du réseau ANOC

Disponible 02/2008

La fonctionnalité du routeur

avec le wrapper a été observée

TRXOFDMFHT1

FHT2

MEM

NoCPerf

80c51

DC-DC

3440 µm

3480 µm

NoCIF







Mise en œuvre de l’architecture développée au réseau ANOC Génération des vecteurs de test Application des vecteurs de test Résultats du test






Génération des vecteurs de test (1/3)

Structure de liens du réseau

un lien du réseau

1 canal « Send »

17 canaux « 1-of-4 »

2 canaux « Accept »

valeur 0

acquittementvaleur 1

valeurs de 0 à 3

acquittement

requête

acquittement

Data (tous les 17 digits « 1-of-4 ») Send

« 0.0.0………………………………0 » « 0 »

« 1.1.1………………………………1 » « 1 »

« 2.2.2………………………………2 » « 0 »

« 3.3.3………………………………3 » « 1 »

Total :

4 vecteurs





Pour le routeur du réseau La partie « data »

Vecteurs de test pour un triplet « entrée/sortie/canal virtuel »

Unité d’entrée

ControlControl

VC0

VC1

HPUHPU

Unité de sortie

VC0

VC1

ControlControl

path–to-target

1 0 contrôles infos de routage

0 0 champ de données

Flit d’en-tête

Flits de données

dir-1

BoP EoP

dir-0

0 1 champ de données

Flit de fin du paquet

Data Send

BoP/EoP 15 digits « 1-of-4 » Direction canal

« 2 » « 0.0.0……………………………0 » « dir. » « vc. »

« 0 » « 0.0.0……………………………0 » « 0 » « vc. »

« 0 » « 1.1.1……………………………1 » « 1 » « vc. »

« 0 » « 2.2.2……………………………2 » « 2 » « vc. »

« 1 » « 3.3.3……………………………3 » « 3 » « vc. »

Total :

200 vecteurs





Pour le routeur du réseau La partie « contrôle »

Vecteurs de test pour un triplet « entrée/sortie/canal virtuel »

Unité d’entrée

ControlControl

VC0

VC1

HPUHPU

Unité de sortie

VC0

VC1

ControlControl

path–to-target

1 1 contrôles infos de routage

Paquet d’un flit

dir-1

BoP EoP

dir-0

Data Send

BoP/EoP 15 digits « 1-of-4 » Direction canal

« 3 » « 1.1.1……………………………1 » « dir. » « vc. »

« 3 » « 2.2.2……………………………2 » « dir. » « vc. »

« 3 » « 3.3.3……………………………3 » « dir. » « vc. »

Total :

120 vecteurs













Application des vecteurs de test (1/2)

Test des routeurs

Un exemple :

Routeur ID = WCM

OTC-3

ITC-3

ITC-1

OTC-1

ITC-0 OTC-0

ITC-4

OTC-4

OTC-2 ITC-2

RouteurANOC

OUEST

RES

EST

SUD

NORD

cfg-in

cfg-out

2

2

34

Entrée

Sortie

Chemin de routagesous test

Wrapper N°2

EoF ID RS – RE OS – OE SS – SE ES – EE NS – NE M

3 – – – – – 1

Configuration de test

00 00 00 00 01 02 12 01 02 12002

002




Application des vecteurs de test (2/2)

Test des liens du réseau

2 wrappers sont utilisés

2 configurations de test

2 liens sont testés à la fois

Routeur

Routeur

lienssous test

1er wrapper

2ièmewrapper

en mode traverséeEst Sud

en mode demi-tour

Entrée

Sortie




Algorithme de test pour le réseau entier

Stratégie de test globale

Les routeurs déjà testés sont mis en mode bypass

links-under-test

current-routerH-next router

V-nextrouter

12345

109876

1115

2016

chaîne de config et de bypass

cfg-in

cfg-out

Testeur













Résultats du test (1/3)

Temps d’application du test

Vitesse de test : 10M-vecteurs/s

Pour les tailles considérées, le temps d’application du test est inférieur à 1ms (inférieur au temps d’application du test d’une IP)

Taille du

Réseau sous test

Temps d’application de test (µs)

les routeurs les liens le réseau entier

1 x 1 32

3 x 3 288,40 5,20 293,20

3 x 4 384,55 7,35 391,35

4 x 4 512,75 10,35 522,35

5 x 4 640,95 13,35 653,35





Couverture de fautes (le test du réseau)

Fautes non-détectées

Les fautes se localisent avant les entrées d’un très petit nombre de

portes de Muller asymétriques

Circuit sous test Unité d’entrée Unité de sortie Routeur entier

SSAF sur les entrées

et les sorties

9194/9194

(100%)

14110/14142

(99,77%)

116520/116680

(99,86%)

+A

BZ

• Ne considère pas le niveau 0 sur l’entrée B

• Impossible de vérifier le collage à 1 sur B,

la transition sur Z peut arriver trop tôt





Couverture de fautes (le test de l’architecture CVT)

Fautes non-détectées Les fautes se localisent sur les signaux concernant la vérification de

l’identifiant (ID) du wrapper de test et sur les signaux ctrl-mode des

cellules de test (avant les entrées des portes de Muller asymétriques)

Circuit sous test Cellule de test WCM Wrapper entier

SSAF sur les

entrées et sorties

3380/3382

(99,94%)

3400/3472

(97,93%)

37200/37292

(99,75%)








Utilisations alternatives de l’architecture CVT Diagnostic Vérification du réseau sur silicium Test des unités de traitement





Diagnostic

(in

terc

onne

xion

s) (

inte

rcon

nexi

ons)

Input stage 4

IN_4 OUT_4

Output stage 4

CtrlCtrl CtrlCtrl

~ 100 portes logiques~ 600 portes logiques~ 40 portes logiques

Input stage 0 Output stage 0




Vérification du réseau sur silicium (1/2)

Transmissions concurrentes

Ouest

Nord

Est

WCM

Res

Sud

P1 – VC0

P2 – VC0

Ouest

Nord

Est

WCM

Res

Sud

P1 – VC0

P2 – VC1





Influence des paquets successifs

Nord

WCM

Res

Sud

Ouest

Nord

WCM

Res

Sud

Est

TW2TW1

P1P2

R1 R2




Test des unités de traitement (IP)

Architecture CVT est utilisée comme un TAM

Un algorithme de test a été proposé

NIIP

Contrôleur

Contrôleur IP-T

W

WCM

SASSAS

Interface réseau (NI)

Wrapper de routeur en mode traversée

Wrapper de routeur en mode bypass

WCM

IP sous test

TESTEUR













Conclusions

Une méthode de test pour les réseaux sur puce asynchrones Modélisation, validation de la méthode Publications : IEEE-DDECS 2006, IEEE-ETS 2006

Réalisation et implémentation d’une architecture CVT Réalisation, implémentation, optimisation, et intégration au circuit

ALPIN, évaluation des résultats de cette implémentation (coût en surface, latence ajoutée, bande passante, etc.)

Publications : IEEE-ETS 2007, ACM/IEEE-NOCS 2007

Application la méthode proposée au réseau ANOC ATPG, Algorithme de test, évaluation des résultats du test (couverture

de fautes, temps d’application du test, etc.) Publications : ACM/IEEE-NOCS 2008

Exploitation de l’architecture CVT développée pour plusieurs

utilisations alternatives




Perspectives

Valider l’implémentation physique de l’architecture CVT sur le

circuit ALPIN

Optimiser le temps d’application du test pour les IP en

considérant comme contrainte le coût de la surface

additionnelle de l’architecture Configurer parallèlement les wrappers de test

Ajouter des bypass reconfigurables

Implémenter l’unité GAC sur silicium afin de réaliser un NoC

auto-testable Une étape très importante pour le transfert industriel

BIST (Built-In Self-Test) du réseau asynchrone




Merci de votre attention !




Back up… slides

Back up !!!




Format d’une configuration de test (TCF)

EoF ID [2:0] EMS MMCS EME MCE EMS MCS EME MCE

24Cellules OTC – ITC (Res)

0Cellules OTC – ITC (Nord)Ouest – Sud – Est

EoF Valeur spéciale indiquant la fin d’une configuration

ID[2:0] Identifiant du wrapper de test

EMS[i] Activer le signal ‘ctrl-mode’ pour la cellule OTC i

MCS[i] Définir la valeur du signal ‘ctrl-mux’ pour la cellule OTC i

EME[i] Activer le signal ‘ctrl-mode’ pour la cellule ITC i

MCE[i] Définir la valeur du signal ‘ctrl-mux’ pour la cellule ITC i

M Mode du wrapper de test affecté par la configuration




Stockage de données dans le wrapper

Stockage de données entre des cellules de test Une donnée peut être stockée entre deux cellules

S2

noc-in

noc-out

cell-incell-out

01

1

0

S1

MODE

MUX

LOCALS2

noc-in

noc-out

cell-incell-out

01

1

0

S1

MODE

MUX

LOCAL

S2

noc-in

noc-out

cell-incell-out

01

1

0

S1

MODE

MUX

LOCAL

canal contient une donnée

canal contient un code vide




Co-simulation

Gén

érateur d

e Vecte

urs d

e Test (G

VT

)

An

alyseu

r de R

épo

ns

es (AR

)

Contrôleur Principal (CP)

Routeur +Wrapper de test

(VHDL ou Netlist model)

Enveloppe SystemC

sc-fifo links

QDI links

sc-fifo links

QDI links

Cfg-out Cfg-in

Send

Data

Accept0/1

Send

Data

Accept0/1

QDI links QDI links

Interfaces: SystemC QDI

Interfaces: SystemC QDI

Ou modèle SystemC




Circuit ALPIN

Intégration dans le circuit ALPIN (Asynchronous Low Power Innovative NoC)

NoC PORT

SAS

NI

80C51ID=4

LCG

SAS

NI

80C51ID=4

LCG

NI

80C51ID=4

LCG

NI

80C51ID=4

LCG

SAS

NI

MEMID=5

LCG

SAS

NI

MEMID=5

LCG

NI

MEMID=5

LCG

NI

MEMID=5

LCG

SAS

NI

NoC PerfID=3

LCG

SAS

NI

NoC PerfID=3

LCG

NI

NoC PerfID=3

LCG

NI

NoC PerfID=3

LCG

SAS

NI

TRXOFDMID=0

LCG

SAS

NI

TRXOFDMID=0

LCG

NI

TRXOFDMID=0

LCG

NI

TRXOFDMID=0

LCG

SAS

NI

FHT1ID=1

LCG

SAS

NI

FHT1ID=1

LCG

NI

FHT1ID=1

LCG

NI

FHT1ID=1

LCG

SAS

NI

FHT2ID=2

LCG

SAS

NI

FHT2ID=2

LCG

NI

FHT2ID=2

LCG

NI

FHT2ID=2

LCG

NOCIF

DC-DC Converter

POW

ER C

ON

TRO

L

POW

ER C

ON

TRO

L

POW

ER C

ON

TRO

L

Cut

_of

fre

set_

nD

CD

Cct

rl

Asynchronous Node

Asynchronous Node with test Serial link 8051 output port

Clk output

Vcore

Vdcdc

Node test configuration

TW_ID = 0TW_ID = 1TW_ID = 2

node 0_0 node 0_1 node 0_2







Influence des paquets successifs

TW1 en mode normal TW2 n’est pas configuré jusqu’au moment où les paquets sont prêts à l’entrée Ouest de TW2

Nord

WCM

Res

Sud

Ouest

Nord

WCM

Res

Sud

Est

TW2TW1

P1P2

R1 R2

Documents

Méthode de test et conception en vue du test pour les réseaux sur puce asynchrones :