Introduction
Cette page aborde les entrées de données synchrones à la source (source-synchronous inputs) : cette technique signifie que les entrées de données sont synchronisées avec une horloge que le composant externe génère en parallèle de ces entrées.
Cette méthode est souvent utilisée tout simplement parce que c'est ainsi que fonctionne le composant externe. Une autre bonne raison est que la source des données est physiquement éloignée du FPGA. Il est également possible qu'un câble et un connecteur séparent le FPGA de l'autre partie. Par exemple, une caméra numérique qui envoie les données des pixels.
Une difficulté possible avec une horloge synchrone à la source (source synchronous clock) est qu'elle peut ne pas être active en permanence. Le signal d'horloge peut aussi être affecté par une connexion physique mal aboutée ou par un bruit excessif. Il est également possible que l'horloge n'ait pas une période stable, ou que la gigue (jitter) soit excessivement élevée. Cela arrive souvent lorsque la source des données (et donc aussi l'horloge) est un périphérique d'E/S d'un microprocesseur.
Notez qu'il existe une page séparée qui traite des relations entre l'horloge et les données en général.
Faire face à une horloge instable
La consigne la plus importante avec les entrées synchrones à la source est que l'horloge ne doit pas être connectée directement aux éléments logiques du FPGA. Il faut plutôt que l'horloge utilisée à l'intérieur du FPGA soit une horloge propre, générée par une PLL intégrée au FPGA.
Si une horloge externe est connectée directement à la logique du FPGA, des problèmes étranges peuvent survenir : une mauvaise horloge crée des comportements inattendus qui ne ressemblent pas à un problème d'horloge. Une gigue excessive et des parasites (glitches) peuvent violer les exigences temporelles qui garantissent le fonctionnement fiable de la conception. La conséquence est que pratiquement n'importe quoi peut arriver, y compris des situations impossibles selon le code Verilog. Il est donc facile de croire à tort que le problème est un bug dans la conception du FPGA.
Il est naturel de penser (à tort) qu'un problème d'horloge ne cause qu'une perte de cycles d'horloge et, par conséquent, que certains éléments de données manqueront. Lorsqu'une mauvaise horloge provoque d'autres problèmes, les tentatives de résolution se concentrent souvent sur les parties de la conception logique qui semblent les plus liées. Cela peut faire perdre beaucoup de temps.
La seule situation où une horloge externe peut être utilisée directement par le tissu logique est lorsqu'il est garanti que cette horloge est stable et propre. Si cette horloge n'est pas stable lorsque le FPGA commence à fonctionner, ce problème doit être traité : tant que l'horloge est instable, une remise à zéro doit être appliquée à la logique qui dépend de cette horloge.
Stratégies possibles
Il existe principalement quatre stratégies possibles pour se synchroniser avec l'horloge externe. Ces stratégies sont présentées ci-dessous, sans ordre particulier.
Stratégie n° 1 : échantillonnage du signal 01
Cette stratégie est la méthode la plus robuste pour les entrées synchrones à la source. Lorsque l'horloge externe se comporte mal, l'échantillonnage du signal 01 (01-signal sampling) présente un net avantage par rapport à toute autre méthode. Cependant, cette méthode n'est utile que lorsque la fréquence d'horloge de la source de données est relativement basse.
Cette méthode est présentée séparément sur une page dédiée.
Stratégie n° 2 : utilisation d'une PLL
Avec cette stratégie, l'horloge externe est connectée à l'entrée d'une PLL du FPGA. L'horloge de sortie de cette PLL est utilisée pour les éléments logiques. Un signal de remise à zéro est appliqué à ces éléments logiques lorsque la PLL n'est pas verrouillée. Cette solution garantit que les éléments logiques s'appuient sur une horloge stable : lorsque l'horloge de sortie de la PLL n'est pas stable, les éléments logiques sont désactivés par la remise à zéro.
La PLL facilite également l'atteinte des contraintes temporelles (timing constraints), par rapport à une connexion directe de l'horloge externe : la PLL compense le délai entre la broche d'horloge et l'horloge interne du FPGA.
Il faut cependant noter que les imperfections de l'horloge externe peuvent provoquer une gigue excessive à la sortie de la PLL. Le détecteur de verrouillage (lock detector) de la PLL peut continuer à indiquer que la PLL fonctionne correctement, même si l'horloge qu'elle produit est anormalement bruitée. Il n'existe pas de solution simple à cette situation. Une possibilité est de modifier les contraintes temporelles de la logique qui dépend de la sortie de la PLL. Par exemple, la gigue d'horloge indiquée dans les contraintes temporelles peut être augmentée jusqu'à une valeur que la PLL ne dépassera probablement pas (car un déverrouillage se produirait).
Cette stratégie présente une similitude avec l'horloge synchrone au système (system synchronous clock) : dans les deux cas, l'horloge externe est connectée à une PLL et la sortie de cette PLL est utilisée dans le FPGA. Les contraintes temporelles sont donc écrites de la même manière que pour une horloge synchrone au système.
Notez que la PLL aligne généralement son horloge de sortie sur l'horloge externe d'une manière optimale pour une horloge synchrone au système. L'alignement optimal pour une horloge synchrone à la source (source synchronous clock) peut être légèrement différent. Dans les deux cas, les horloges ne sont pas parfaitement alignées. Il existe plutôt une petite différence temporelle intentionnelle entre les fronts des horloges. Cette différence temporelle facilite le respect des exigences temporelles des registres d'E/S. Certaines PLL peuvent être configurées pour aligner les horloges de manière à offrir des performances optimales avec une horloge synchrone à la source.
Cette stratégie est la plus facile à mettre en œuvre par rapport aux autres stratégies énumérées ici. Elle convient à des fréquences d'horloge relativement élevées. Mais pour des fréquences proches du maximum que les E/S peuvent supporter, cette stratégie ne fonctionnera probablement pas.
Stratégie n° 3 : déphasage
Cette stratégie est généralement choisie lorsque le débit de données est proche du maximum que le FPGA peut prendre en charge.
Les méthodes habituelles pour garantir les exigences temporelles ne fonctionneront pas à de tels débits : il sera impossible de satisfaire les contraintes temporelles. Un échantillonnage fiable des signaux de données reste cependant possible.
Le problème des contraintes temporelles est de garantir les exigences temporelles par le calcul : un tel calcul inclut plusieurs paramètres incertains, par exemple les différences de fabrication du FPGA. Lorsque ces paramètres sont pris en compte, les calculs ne donnent pas une solution temporelle qui garantisse un échantillonnage fiable. Lorsque le débit de données est très élevé, il n'y a pas de marge temporelle à consacrer à ces incertitudes.
Mais pour un FPGA donné, ces paramètres sont constants. La solution consiste donc à rechercher le timing correct pendant que le FPGA fonctionne. Concrètement, cela signifie qu'une machine à états (state machine) à l'intérieur du FPGA ajuste le délai entre l'horloge de données et l'instant d'échantillonnage. On utilise ainsi un mécanisme adaptatif pour trouver le timing optimal, plutôt que de se fier à des calculs. Ce mécanisme est appelé déphasage (phase shifting).
Cette stratégie est souvent utilisée avec les signaux de données des mémoires DDR SDRAM. Dans cette application, l'objectif est toujours d'atteindre un débit de données aussi élevé que possible. Les capacités des ports d'E/S sont donc poussées à leur limite. Le déphasage est par conséquent le seul moyen de garantir un échantillonnage fiable des entrées de données : après l'initialisation de la mémoire DDR, une séquence spéciale de données est écrite dans la mémoire (les signaux de données vers la mémoire sont des sorties synchrones à la source, ce qui évite toute difficulté de timing). Le FPGA lit ensuite de façon répétée la même zone de la mémoire DDR. Une machine à états trouve le timing optimal en modifiant progressivement le délai d'échantillonnage. Les données d'entrée attendues sont connues, car il s'agit de la même séquence de données qui a été écrite précédemment. La machine à états peut donc facilement évaluer la fiabilité des données et trouver le délai optimal.
Une caractéristique intéressante de ce mécanisme est que l'horloge de données fournie par la puce DDR peut être ignorée : la mémoire DDR est synchronisée avec l'horloge que le FPGA génère. Cette horloge fait partie des sorties synchrones à la source que reçoit la mémoire DDR. Il est donc garanti que l'horloge de données des entrées synchrones à la source a exactement la même fréquence que l'horloge générée par le FPGA. Le mécanisme de déphasage peut donc s'appuyer sur l'horloge interne plutôt que sur l'horloge qui arrive avec les données. Peu importe qu'il existe un délai inconnu entre ces deux horloges : la machine à états trouve le timing optimal quel que soit ce délai.
En fait, c'est ainsi que ce mécanisme est généralement mis en œuvre pour les mémoires DDR : même si les mémoires DDR disposent d'une horloge synchrone à la source (appelée signal de strobage de données [data strobe]), la mise en œuvre habituelle du mécanisme de déphasage ignore ce signal. La raison est qu'il est plus important de garantir que les signaux de données arrivent de manière fiable que d'être aligné avec le signal de strobage.
L'utilisation du déphasage peut donc éliminer le besoin d'une horloge de données. On peut s'appuyer sur une horloge interne, à condition que sa fréquence soit garantie exactement égale au débit de données.
Avec cette stratégie, les contraintes temporelles ont le même objectif qu'avec des registres IOB ordinaires.
Stratégie n° 4 : utiliser l'horloge directement
Cette stratégie est apparemment la plus directe : l'horloge externe est connectée directement aux bascules du FPGA. Quelque chose comme ceci :
module top (
input data_clk,
input [7:0] data
);
reg [7:0] data_samp;
always @(posedge data_clk)
begin
data_samp <= data;
[ ... ]
end
Comme mentionné ci-dessus, cette stratégie n'est généralement pas une bonne idée. La raison principale est que si @data_clk présente un parasite (glitch), toute la logique qui dépend de cette horloge devient imprévisible.
Il peut être raisonnable d'utiliser ainsi une horloge externe s'il est garanti qu'elle est propre et stable. Mais même dans ce cas, il peut être difficile de satisfaire les exigences temporelles en raison du délai entre la broche d'horloge et les bascules. Certains FPGA disposent de ressources d'horloge spéciales destinées à réduire ce délai. Cela peut nécessiter d'utiliser une broche d'entrée d'horloge dédiée et de restreindre les ports d'E/S à des régions spécifiques du FPGA.
Lorsque l'horloge est utilisée directement, les contraintes temporelles s'écrivent de la même manière que pour une horloge synchrone au système.
L'alternative la plus directe à cette stratégie consiste à utiliser une PLL, comme suggéré plus haut. Si l'horloge de données n'est pas stable, l'échantillonnage du signal 01 doit être envisagé.
Résumé
Ce n'est pas un hasard si l'échantillonnage du signal 01 a été mentionné en premier sur cette page, et si cette stratégie est décrite sur une page séparée : c'est la méthode la plus recommandée lorsque le débit de données n'est pas supérieur à ce que cette méthode peut prendre en charge.
Si d'autres stratégies sont envisagées, il est important de prêter attention à la stabilité de l'horloge de données. Si une horloge s'écarte de son comportement autorisé (c'est-à-dire la période d'horloge et la gigue maximale), cela peut entraîner un dysfonctionnement permanent et irrécupérable de la logique concernée. Seule une remise à zéro peut ramener la logique à un fonctionnement normal.
L'utilisation d'une PLL pour générer une horloge fiable améliore considérablement la situation : la sortie de la PLL est fiable tant que son détecteur de verrouillage l'indique. Une remise à zéro doit sinon être appliquée à cette logique.