Il problema del CDC (Clock Domain Crossing) negli FPGA

Durante il normale funzionamento di un FPGA (se si è fortunati, quando ancora il dispositivo è in fase di test e debug) può capitare talvolta di trovarsi davanti ad un errore transitorio e sporadico che non è stato possibile catturare in fase di simulazione RTL del codice, per quanto bene si possa essere riusciti a riprodurre nell’ambiente di simulazione gli stimoli che consentono di osservarlo on-board. Errori di questa natura sono di norma associati ad una violazione di timing che è possibile individuare tramite una Static Timing Analysis oppure, nel caso in cui il design includa più di un dominio di clock, ad un CDC (Clock Domain Crossing) eseguito in maniera non corretta. In questo articolo verrà introdotto il problema del CDC e sarà fornita una panoramica delle configurazioni circuitali (descritte in VHDL) che è possibile adottare per risolverlo in diversi scenari pratici particolarmente comuni.

INTRODUZIONE

Gli FPGA sono una tecnologia ad oggi estremamente diffusa per la realizzazione di reti digitali in diversi ambiti applicativi. In molti casi pratici di progettazione FPGA ci si ritrova nella necessità di scambiare informazioni con altri circuiti digitali che producono o consumano dati a frequenze di clock diverse tra loro: questo richiede naturalmente che il device sia partizionato in tante regioni (dette appunto domini di clock) quante sono le frequenze di clock da gestire. Finché si rimane all’interno di un singolo dominio di clock, i tool di STA (Static Timing Analysis) sono in grado di verificare che, nella rete implementata, ciascun trasferimento di dati tra un flip-flop e l’altro rispetti le regole fisiche definite dalle caratteristiche tecnologiche dei flip-flop stessi, in particolare i cosiddetti tempi di setup (tsu) e di hold (th).
Questa è una condizione di fondamentale importanza, legata alla possibilità che il dato all’ingresso di un flip-flop commuti in un istante di tempo troppo vicino al fronte di cattura del clock: se si verifica questo, il flip-flop di destinazione cade in una condizione che viene detta di metastabilità e che determina sulla sua uscita un valore incerto, non interpretabile né come 0 né come 1 perché compreso tra le soglie logiche che definiscono appunto i due stati. Il flip-flop si viene a trovare quindi in uno stato non stabile e la sua libera evoluzione determinerà, dopo un intervallo di tempo indefinito, il suo assestamento allo stato 0 o allo stato 1. Ma che succede durante questo intervallo di tempo? In base alla durata di quest’ultimo, potrebbe succedere che i flip-flop controllati da quello metastabile vedano al loro ingresso un valore indefinito nella finestra temporale individuata dai tempi di setup e hold intorno al fronte di cattura e, di conseguenza, che finiscano a loro volta in metastabilità. In breve, la metastabilità è un fenomeno che può generarsi in un circuito digitale in corrispondenza di un qualunque flip-flop di cui siano violati i parametri tsu e th e che può successivamente propagarsi sui flip-flop a valle causando un comportamento indefinito della rete. Naturalmente, le conseguenze di questo fault possono essere più o meno critiche a seconda della funzionalità impattata e più o meno drammatiche a seconda dell’ambito applicativo in cui il device è impiegato.

ATTRAVERSAMENTO DEI DOMINI DI CLOCK

Come già osservato, fino a che si rimane confinati all’interno di un singolo dominio di clock, la STA garantisce che qualunque violazione dei parametri tsu e th venga intercettata e segnalata al designer, che potrà quindi intervenire modificando il suo RTL o i vincoli di implementazione. D’altra parte, non è raro che il nostro design richieda di trasferire informazioni da un dominio di clock ad un altro, completamente asincrono rispetto al primo. In questi casi, la STA non è in grado di eseguire alcuna verifica sul rispetto dei parametri tsu e th, per il semplice motivo che non è possibile fare alcuna assunzione sulla posizione relativa tra il fronte di lancio del clock di sorgente e il fronte di cattura del clock di destinazione. Come si può allora essere sicuri che il flip-flop di destinazione non finisca in metastabilità? Per fare un po’ di filosofia, la risposta è che non si può essere assolutamente sicuri: come spesso capita in ingegneria, è necessario accettare una certa probabilità che un dato guasto si verifichi, normalmente espressa tramite il celebre MTBF (Mean Time Between Failure), probabilità che dovrà essere stimata e proporzionata in fase di design rispetto alle conseguenze che l’accadimento di quel guasto comporterebbe.
In termini pratici, si tratta innanzitutto di localizzare nell’RTL i punti in cui si verificano i CDC, quindi di adottare in corrispondenza di essi specifiche soluzioni circuitali (dette sincronizzatori) che garantiscano un certo grado di sicurezza rispetto alla metastabilità. Evidentemente, gli scenari potranno essere diversi a seconda delle caratteristiche del segnale che si desidera trasferire da un dominio di clock all’altro, nonché del rapporto tra le frequenze di clock dei domini di partenza e destinazione: diversi scenari richiederanno di conseguenza diverse strutture di sincronizzazione. Nei paragrafi successivi verranno quindi analizzati gli scenari più tipici di CDC e, per ciascuno di essi, verrà proposto un adeguato modello di sincronizzatore.

SINCRONIZZAZIONE DI UN SEGNALE STATICO

Lo scenario più semplice è sicuramente quello che prevede il trasferimento da un dominio di clock all’altro di un segnale scalare statico. In questo caso, indipendentemente dai rapporti tra le frequenze di clock, il sincronizzatore, rappresentato in Figura 1, può essere semplice come una cascata di due o più flip-flop.

library ieee;
use ieee.std_logic_1164.all;

entity static_scalar_synchr is
generic (
  FF_NUM   : integer range 2 to 16 := 2);
port (
  cdc_src     : in std_logic;
  a_rst_dst   : in std_logic;
  clk_dst     : in std_logic;
  cdc_dst     : out std_logic);
end entity;

architecture beh of static_scalar_synchr is

  signal resync_ffs   : std_logic_vector(FF_NUM-1 downto 0);

begin

  process(a_rst_dst, clk_dst)
  begin
    if (a_rst_dst = '1') then
      resync_ffs <= (others => '0');
    elsif rising_edge(clk_dst) then
      resync_ffs(0) <= cdc_src;
      resync_ffs(FF_NUM-1 downto 1) <= resync_ffs(FF_NUM-2 downto 0);
    end if;
  end process;

  cdc_dst <= resync_ffs(FF_NUM-1);

end architecture;
Sincronizzatore per un segnale scalare statico, basato su una semplice cascata di due flip-flop.

Figura 1: Sincronizzatore per un segnale scalare statico.

L’idea di base è che un’eventuale metastabilità che si verifichi sul primo flip-flop verrà con ogni probabilità “risolta” dal secondo: poiché tra i due flip-flop non è presente alcuna logica combinatoria, il primo flip-flop ha a disposizione quasi un intero periodo del clock di destinazione per evolvere verso uno dei due stati stabili, prima che il secondo flip-flop ne legga l’uscita (per essere più precisi, il tempo a disposizione è lo slack di setup del path tra i due flip-flop: la determinazione dello slack richiede tuttavia concetti di STA che esulano dallo scopo di questo articolo). Come per qualunque modello di sincronizzatore, anche per questo sarebbe possibile calcolare MTBF, che in generale risulta funzione dei parametri tecnologici dei flip-flop come anche delle frequenze di clock in gioco; è inoltre possibile mostrare come la probabilità che l’uscita di questo sincronizzatore vada in metastabilità abbia una dipendenza esponenziale decrescente dal numero di flip-flop impiegati. In termini estremamente pratici, questo vuol dire che, in presenza di condizioni più critiche relativamente ai parametri tecnologici e/o alle frequenze di clock in gioco, è possibile ottenere comunque un MTBF sufficientemente alto aumentando il numero di flip-flop in cascata. Per questo motivo, nel VHDL di esempio che descrive il sincronizzatore, il parametro relativo agli stadi di ricampionamento è stato posto come generico. Nei modelli di sincronizzatore che seguono si potrebbe applicare la stessa identica [...]

ATTENZIONE: quello che hai appena letto è solo un estratto, l'Articolo Tecnico completo è composto da ben 3860 parole ed è riservato agli ABBONATI. Con l'Abbonamento avrai anche accesso a tutti gli altri Articoli Tecnici che potrai leggere in formato PDF per un anno. ABBONATI ORA, è semplice e sicuro.

Scarica subito una copia gratis

4 Commenti

  1. Avatar photo Maurizio 17 Maggio 2016
  2. Avatar photo Lorenzo Columbo 18 Maggio 2016
  3. Avatar photo Lorenzo Columbo 23 Maggio 2016

Scrivi un commento

Seguici anche sul tuo Social Network preferito!

Send this to a friend