synchronisation du processus sur FPGA

Je suis nouveau dans les fpgas, et il y a certaines subtilités de synchronisation que je ne suis pas sûr de comprendre: si tous mes processus synchrones sont déclenchés sur le même front, cela signifie que mes entrées sont `` capturées '' sur un front montant, et mon les sorties changent sur .. le même bord? le prochain front montant?

si j'ai deux modules, où la sortie de l'un coule dans les entrées du suivant, il pourrait se produire la situation où les entrées de mon module (les sorties d'un module précédent) changent en même temps qu'elles sont capturées.

Le marqueur à 205ns montre de quoi je parle, op et data_write étant mes entrées. Tout semble "fonctionner correctement" dans ce cas de test, mais dans la simulation, il n'est pas clair exactement ce qui est capturé quand. Le data_write = "0001 ..." est-il capturé à 205ns ou (205ns + 1 cycle d'horloge)? Existe-t-il un moyen d'obtenir des formes d'onde plus détaillées dans ISim qui montrent les temps de configuration et de maintien?

Merci.

Il y a toujours un certain retard de propagation à travers la bascule. Il est souvent appelé délai "d'horloge à Q".

Cela signifie que vos entrées sont capturées sur le bord et que vos sorties changent sur le même bord, mais quelques nanosecondes plus tard. Ce délai de quelques nanosecondes est suffisant (si vos bascules sont conçues avec un "temps de maintien nul" comme dans la plupart des FPGA) pour que les changements n'affectent aucune bascule en aval jusqu'au prochain front d'horloge.

Dans la simulation fonctionnelle ou RTL (qui est probablement ce que vous faites pour générer votre résultat), le retard ne sera pas simulé comme des nanosecondes durables. En VHDL, ce sera un cycle delta unique de l'horloge du simulateur, ce qui n'est techniquement pas du tout du temps. Cela rend impossible de voir le retard dans la sortie du simulateur. Néanmoins, pour les bascules simulées comme idéales, il suffit que les changements de sortie n'affectent pas les bascules en aval.

Si vous effectuez une simulation post-lieu et itinéraire, elle devrait pouvoir inclure les retards appropriés afin que vous puissiez voir clairement ces effets, au prix d'un effort de simulation accru.

Au front d'horloge souhaité (montant ou descendant), l'entrée à D apparaît à la sortie Q. Cela prend un temps limité (retard d'horloge à Q) et en supposant qu'il n'y a pas de violation de synchronisation, D ne passera que par un FF à la fois (c'est-à-dire s'il y a une autre entrée FF connectée à Q, la seconde FF passera la valeur FF1 Q avant de changer.

Pour inclure des timings dans votre simulation, vous devez synthétiser et placer et acheminer votre conception, puis exécuter une simulation de lieu et d'itinéraire. Cela aura tous les délais de combinaison, d'horloge à Q, etc. inclus. La simulation HDL n'a aucun de ces timings, elle n'est donc utile que pour tester le fonctionnement de base, pas les limites de timing. Vous obtiendrez également un rapport de synchronisation, qui vous indiquera les limites de vitesse d'un domaine d'horloge particulier, vous indiquera s'il y a des violations de synchronisation et vous montrera le temps de synchronisation pour différents chemins. Vous pouvez utiliser ces informations pour déterminer où des modifications doivent être effectuées, ou des règles ajoutées pour indiquer au logiciel que la violation n'est pas un problème (par exemple pour des choses comme les chemins multi-cycles ou les chemins croisés)

Ceci est censé être un ajout aux réponses précédentes, dont je crois que vous avez compris l'idée.

Ces questions peuvent en effet être un peu délicates au début lors de la conception de simulations RTL car il est difficile de voir quelle est la cause et quel est l'effet dans les simulations idéales / fonctionnelles / RTL (= pas de délais de propagation).

Avec le bon simulateur, les retards delta peuvent en fait être visualisés. ISim ne le fait pas, mais dans ei ModelSim, vous pouvez activer l' expansion delta autour des bords de l'horloge. Vous trouverez ci-dessous un exemple de capture d'écran d'une adresse IP tierce buggy que j'ai résolue.

cest le signal d'horloge, et +1etc. sont les cycles delta, visualisés comme le temps.

Si une conception est simulée là où la simulation et la conception sont vraiment idéales et synchrones , sans aucun retard simulé, vous pouvez, en principe, voir tous les changements de signal sur un flanc d'horloge spécifique comme se produisant légèrement après ce flanc d'horloge. Par conséquent, dans votre exemple, à 205 ns, data_write= 0000...est ce qui est capturé. Un autre logique dans la première unité est en train de changer le signal data_writede 0001...sur le même flanc, et en ce que le signal apparaît sur data_writeun peu après le flanc d'horloge. Ce "légèrement après" serait un ou plusieurs deltas de simulation dans une simulation idéale (votre exemple) (non visible dans ISim, mais par exemple dans ModelSim avec expansion delta), ou quelques ps / n plus tard dans le monde réel.

Sur une note latérale: Une chose importante avec la conception RTL est de s'assurer que les entrées sont toujours échantillonnées sur le flanc de l'horloge - même un cycle delta plus tard est trop tard. L'entrée peut ne pas être valide un delta plus tard. Ou en d'autres termes: "ne jouez pas avec le chemin de l'horloge".