Ready/valid et tampon élastique d'une place

Le transfert a lieu si valid et ready valent 1 au même front

L'émetteur affirme valid quand il présente une donnée utilisable ; le récepteur affirme ready quand il peut la recevoir. La décision se prend en échantillonnant les deux au front d'horloge.

Pendant valid=1,ready=0, l'émetteur doit conserver valid et la donnée. Attendre ready avant même d'affirmer valid peut provoquer un interblocage selon les règles du partenaire. Tous les signaux sont ici dans le même domaine : ready/valid^{iHandshake Contrat validant le transfert lorsque valid de l'émetteur et ready du récepteur valent 1 au même front. Il définit aussi la conservation des données en attente.} ne résout pas un CDC.

Transmettre une seule fois la donnée en attente

Les colonnes représentent les cycles d'échantillonnage 0–5, avec valeurs juste avant le front montant^{iFront montant Instant où l'horloge passe de 0 à 1, distinct du niveau désignant tout l'intervalle CLK=1. En savoir plus}. A attend aux cycles 1 et 2, valid=1,ready=0 : données et valid restent constants. A est accepté au front 3, B au front 4. Le schéma illustre le contrat, pas les délais setup^{iSetup Durée minimale de stabilité de la donnée avant le front de capture. En cas de violation, le résultat mémorisé n'est pas garanti. En savoir plus}/hold.

Un valid haut plusieurs cycles ne signifie pas un seul transfert. Chaque front où ready est aussi haut constitue un transfert distinct.

Construire un tampon d'une place

Il reste de la place si le tampon est vide ou si son contenu actuel peut sortir sur ce front.

module elastic_buffer (
    input  logic       clk,
    input  logic       rst,
    input  logic       in_valid,
    output logic       in_ready,
    input  logic [7:0] in_data,
    output logic       out_valid,
    input  logic       out_ready,
    output logic [7:0] out_data
);
    assign in_ready = !out_valid || out_ready;

    always_ff @(posedge clk) begin
        if (rst) begin
            out_valid <= 1'b0;
        end else if (in_ready) begin
            out_valid <= in_valid;
            if (in_valid) out_data <= in_data;
        end
    end
endmodule

Depuis l'état vide, accepter l'entrée met à jour out_valid et out_data après le front. Sans bypass combinatoire, cette nouvelle donnée ne compte pas comme transférée en sortie au même front. Ne comptez aucun transfert pendant reset. Avec out_valid=0, out_data n'a pas de signification : il n'est donc pas indispensable de réinitialiser^{iReset Commande ramenant l'état à la valeur initiale spécifiée. Son caractère synchrone/asynchrone et sa priorité sur les autres commandes doivent être définis. En savoir plus} le registre^{iRegistre Circuit stockant plusieurs bits d'état. Les registres synchrones du cours capturent leur entrée définie sur un front d'horloge. En savoir plus} de données lui-même.

Remplacer même un tampon plein

La dernière ligne permet un élément par cycle après remplissage. La latence ne divise pas automatiquement le débit^{iDébit Nombre d'opérations acceptées ou terminées par unité de temps. Un pipeline peut l'augmenter sans réduire la latence d'une opération individuelle. En savoir plus} par deux.

Un modèle vérifiant l'ordre

Utilisez une queue de longueur maximale 1. Décidez sortie et acceptation à partir des anciennes valeurs au front ; comparez d'abord la sortie au premier élément, puis ajoutez l'entrée. Dequeue et enqueue pouvant coïncider, définissez bien leur ordre.

Cet invariant s'applique à un intervalle de comptage recommencé au reset. Vérifiez aussi stabilité pendant stall, ordre et absence de doublons. Le compte seul ne prouve pas les valeurs.

Une longue chaîne combinatoire de ready allonge le chemin temporel inverse. Vérifiez aussi l'absence de boucle combinatoire entre tampons.

Pour aller plus loin : AMD UG934 — READY/VALID Handshake