Bonjour tout le monde,
J'ai écrit un code vhdl qui est censé faire quelques trucs.. A la simulation, tout se passe très bien et comme je le veux mais une fois implémenté dans mon FPGA, c'est un peu n'importe quoi.. Je ne vais pas rentrer dans les détails mais je me demandais s'il était possible de visualiser les signaux dans le top (comme sur modelsim en fait) non pas en simulation mais en test réel ?
Merci pour vos réponses
(Je précise que je suis sur quartus.)
Vous pouvez mettre en miroir le signal en une pin de sortie du dispositif, alors alimenter une LED
Bonsoir
Oui c'est possible avec Quartus, voir dans "tools" "signal tap",le mode d'emploi est trop compliqué pour être détaillé ici, voir dans le Help.
Ceci dit un truc qui fonctionne avec modelsim et pas "in vivo" c'est généralement la signature de métastabilité : signaux asynchrones rentrés sans précautions dans une machine séquentielle.
JR
Dernière modification par jiherve ; 08/08/2015 à 21h07.
l'électronique c'est pas du vaudou!
Merci pour vos réponses andré et hervé.. J'avais pensé aux leds effectivement, mais avec une interface ethernet qui tourne au Gb/s, ça va trop vite et quand bien même, il n'y en a pas assez sur la carte d'éval pour voir tous les signaux dont j'ai besoin..
Tout ce qui est asynchrone c'est le reset, le reste est cadencé sur des clocks, mais en parlant de stabilité, ça me fait penser à un truc : d'un quartz à 50MHz, je passe au double avec une pll, et j'ai pas fait de fichier de contraintes (j'en ai jamais fait d'ailleurs), peut-être que mon firmware a du mal à tourner à cause de ça, j'vais essayer de me tourner vers les contrainte alors mais avant tout, je vais regarder l'outil signal tap, ça peut être intéressant, merci de l'astuce. Je ferais un autre post quand j'aurais testé tout ça.
NON !Envoyé par Alekos
Je ferais un autre post quand j'aurais testé tout ça.
Tu restes sur cette discussion .
J'aime pas le Grec
Oula, on se calme daudet, restons zen, c'était bien sûr évident que quand je parle d'autre post, je voulais dire de message dans cette même discussion..
Bonsoir,
A ces fréquences il faut OBLIGATOIREMENT faire un fichier de contrainte et donc utiliser TimeQuest, je te préviens ce n'est pas évident et même souvent contre intuitif, j'ai passé des jours à contraindre correctement une interface DDR2 made in moi même.
Mais si tu as utilisé la fonction fournie par Altera alors il existe un utilitaire qui le fera pour toi, c'est un script TCL: "Tools"=> "TclScript".
Si bien sur tu l'as chargé.
Contrairement à ce que beaucoup croient le VHDL ce n'est pas du soft il faut une très grande maitrise de l’électronique digitale et analogique pour l'utiliser.
Pour finir j’espère que tu disposes d'outils, oscilloscopes d'enfer, analyseur logique de course, car il faudra un jour ou l'autre s'en servir;Le ticket d'entrée est aux alentours de 100k€ pour chacun.
JR
l'électronique c'est pas du vaudou!
Votre design travaille avec combien de fréquences différentes ?
@+
Not only is it not right, it's not even wrong!
Bonsoir,
C'est en effet une bonne question car même avec une PLL un changement de domaine d'horloge doit être traité comme le cas asynchrone.
JR
l'électronique c'est pas du vaudou!
Je commence de plus en plus à être convaincu que c'est un problème de timing.. J'ai un fichier .sdc déjà codé MAIS il ne correspond qu'à une partie de mon firmware, j'ai rajouté pas mal de choses, et j'ai donc utiliser des PLL pour cadencer ces blocs, alors je me demandais si le fichier de contrainte ne sert qu'aux clocks externes (ce qui a été déjà fait en fait) ou bien s'il faut contraindre TOUTES les horloges, même internes, sortant de PLLs?..
Bonjour,
oui il faut tout contraindre, avec les plus il y a une directive adaptée:dérive clock qui étendra au horloges issues des pll les contraintes imposées aux horloges externes.
mais comme indiqué dans mon précédent message il faut faire très attention aux signaux logiques échangés entre domaines d'horloges différents.
on ne doit en aucun cas considérer que ces horloges bien que synchrones si issues de la même PLL soient en phase, les fronts ne coïncident pas et le déphasage induira des aléas dans la logique . Le double échantillonnage est obligatoire pour palier ce risque.
JR
l'électronique c'est pas du vaudou!
Est-ce qu'à la place, il n'y aurait pas moyen de resynchroniser les horloges? En vhdl, qu'est-ce que ça donnerait?
Bonsoir,
Il faut d'abord être sur d'avoir réellement besoin de plusieurs horloges, et qu'une solution utilisant une horloge unique et des signaux de validation qui en seraient dérivés ne serait pas possible.
Si plusieurs horloges sont nécessaires alors il faut soigneusement étudier la façon dont on échange les signaux, pour un bus il est par exemple impératif de générer un signal annexe re synchronisé dans le domaine de destination qui servira à valider tout le bus. Ne pas perdre de vue que la resynchronisation individuelle de plusieurs signaux fera disparaître les relations de phases qui les caractérisaient.
C'est un très vaste sujet qui dépasse ce qui peut être traité sur un forum.
JR
l'électronique c'est pas du vaudou!
Aux fréquences plus élevées il n'y est pas une solution adéquate pour générer des signaux d'horloge dans le code que les bus de signaux ne sont pas optimisés pour ça, et que les fabricants d'outils de logiciels ont déjà les moyens de le faire, que, même en utilisant les bus internes des puces spécialement préparé pour faire face à des signaux d'horloge.
