Qu'est-ce que Protocole de poignée de main (handshake) ?

Méthode qui transfère des données de façon fiable par l'échange d'une requête (req) de l'émetteur et d'un acquittement (ack) du récepteur. Entre domaines d'horloge, seuls req et ack sont synchronisés pendant que les données sont maintenues stables, ce qui est sûr mais demande plusieurs cycles ou plus par transfert.

Nom japonais: ハンドシェイク

« Protocole de poignée de main (handshake) » apparaît dans 5 questions d'entraînement réparties sur 1 thèmes, dont Analyse temporelle et CDC.

Domaine: Analyse temporelle et CDC

S'entraîner : questions sur Protocole de poignée de main (handshake)

Dans un handshake à 4 phases utilisant req et ack, quel est l'ordre correct des signaux pour transmettre une donnée ?

  1. AMettre req à 1 tout en commençant à modifier la donnée → le récepteur met ack à 1 → req et ack repassent à 0 simultanément
  2. BLe récepteur met d'abord ack à 1 → l'émetteur stabilise la donnée et met req à 1 → le récepteur capture la donnée → req et ack repassent à 0 simultanément
  3. CStabiliser la donnée et mettre req à 1 → le récepteur capture la donnée et met ack à 1 → req repasse à 0 → ack repasse à 0
Afficher la réponse et l'explication

Réponse : C. Stabiliser la donnée et mettre req à 1 → le récepteur capture la donnée et met ack à 1 → req repasse à 0 → ack repasse à 0

Dans un handshake à 4 phases, req et ack montent puis descendent une fois chacun, et un transfert s'achève en 4 transitions au total. L'émetteur stabilise la donnée puis lève req ; le récepteur, voyant req synchronisé, capture la donnée et lève ack. L'émetteur, voyant ack synchronisé, abaisse req, et le récepteur, voyant req redescendre, abaisse ack. req et ack étant des signaux de 1 bit, ils se transmettent en toute sécurité par des synchroniseurs à 2 étages. Si l'on lève req pendant que la donnée change, le récepteur risque de capturer une valeur en cours de changement.

Quel est l'inconvénient correct du transfert de données entre domaines d'horloge par handshake ?

  1. ALa synchronisation de req et ack faisant un aller-retour, chaque transfert prend de nombreux cycles, ce qui ne convient pas aux transferts continus et volumineux
  2. BLorsqu'on transmet une donnée multibit, les décalages de synchronisation entre bits corrompent la donnée
  3. CIl n'est utilisable que si les horloges de l'émetteur et du récepteur ont la même fréquence
Afficher la réponse et l'explication

Réponse : A. La synchronisation de req et ack faisant un aller-retour, chaque transfert prend de nombreux cycles, ce qui ne convient pas aux transferts continus et volumineux

Dans un handshake à 4 phases, req met 2 cycles de synchronisation pour atteindre le récepteur et ack 2 cycles pour revenir à l'émetteur, et leurs retours à 0 prennent autant ; un transfert nécessite donc au moins 8 cycles au total sur les deux domaines. Il convient donc aux données transmises occasionnellement, comme les valeurs de registres de contrôle. La donnée restant stable pendant tout le transfert, aucune erreur due au décalage entre bits ne se produit, et le rapport des fréquences est indifférent. Pour faire circuler des données quasiment à chaque cycle, on utilise une FIFO asynchrone.

« Protocole de poignée de main (handshake) » dans les explications

Questions mentionnant « Protocole de poignée de main (handshake) » (5)

  1. Dans un handshake à 4 phases utilisant req et ack, quel est l'ordre correct des signaux pour transmettre une donnée ?
  2. Quel est l'inconvénient correct du transfert de données entre domaines d'horloge par handshake ?
  3. Chaque bit d'une donnée de 4 bits a été transmis vers un autre domaine d'horloge via son propre synchroniseur à 2 étages. Lorsque la donnée passe de 0111 à 1000, quel problème peut survenir ?
  4. Une impulsion qui vaut 1 pendant un seul cycle (2 ns) dans un domaine d'horloge à 500 MHz a été transmise à un domaine à 100 MHz via un synchroniseur à 2 étages. Quel problème peut survenir ?
  5. Quelle contrainte s'applique correctement lorsqu'on transmet des impulsions d'un domaine d'horloge rapide vers un domaine d'horloge lent par synchronisation par toggle ?

Termes associés

FIFO asynchrone Domaine d'horloge Via Synchroniseur Métastabilité Code de Gray Chemin critique Chemin multicycle CRPR (suppression du pessimisme de reconvergence d'horloge) Faux chemin (false path)

Retour au glossaire