Je constate qu'avec l'arrivée du RGH2, tous nos problèmes de stabilité du RGH reviennent au galop.
Pour le RGH2 (donc que pour les PHAT) nous devons câbler nos CPLD à la sauce RGH1 version SLIM mais chose bizarre
nous utilisons pas les mêmes composants externes (condo/résistance) lors du câblage.
Je suis pas un expert en électronique mais il y a surement une raison, la CM des PHAT ne doit pas utiliser les mêmes valeurs de tension que celle des SLIM
sinon je ne comprendrais pas le coup de la résitance de 10 ohms qui n'existe pas sur le montage SLIM RGH1.
=> SI vous connaissez les valeurs des tension/courant des signaux qui sont utilises par le HACK je suis preneur ...
Pour revenir au hack RGH1 il y a un truc que je n'ai pas bien compris.
- Pour SLIM on relie VCCIO1 sur VCCINT le tout relié au 1,8V qui provient du régulateur (LDO) de 1,8V/150ma interne au CPLD (vu sur 2 versions de CoolRunner non TX)
- Pour PHAT on doit utiliser une tension pour VCCIO1 < VCCINT pour que le FPGA arrive a bien décoder les infos (1 logique) qui arrive sur OUT_POST1.
-> Certains utilise le 1,8V qui provient de la CM en directe pour VCCIO1
-> Certains utilise le 3.3V du CPLD - la tension de 3 diodes pour obtenir un 3,3V-3x0,7V=1,2V
-> Certains utilise le 1.8V de VCCINT - la tension d'une diode soit 1,8V-0,7V=1,1V
(note: La tension d'une diode peut varier de 0,6V a 0,7V donc ça peut varier de quelques 0,1V)
Pourquoi car un niveau logique '1' vu sur POST_OUT doit être environs égale à 70% de VCCINT (si je confond pas avec VCCIO1) soit 70% de 1,8V = 1,26V (donc une tension >= 1,26V sera vu comme un '1' logique)
Peut etre qu'un meilleur seuil serait de 80% ?
Corrigez moi si je me trompe
De plus le signal CPU_RST que l'on va envoyer depuis le CPLD doit être de 1,1V pour être compatible avec le niveau logique des tensions des signaux de la CM.
=> Donc il faut bien régler ce fameux VCCIO1
Je n'ai pas regardé le code VHDL du FPGA mais il doit surement y avoir des résistances internes pour faire chuter cette tension de sortie au niveau de l'IO)
1ere question:
Pourquoi doit on faire cette modif sur PHAT et pas sur SLIM (pour RGH v1.1) ?
=> car les tensions de la carte SLIM sont plus élevés ?
2eme question:
En modifiant nos CPLD RGH1 pour faire du RGH2 on câble bien le montage SLIM (utilisation de SDA & SCL mais plus de CPU_PLL_BYPASS) mais ne doit pas conserver le mechanisme de VCCIO1 < VCCINT sur nos CPLD aussi pour le RGH2 ?
=> Je pense que OUI c'est pourquoi nous avons pas beaucoup de retour positif ...
car ce fameux VCCIO1 est surement mal réglé !
Certains vendeur de CPLD préconise de régler VCCIO1 à 1,65V pour avoir une temps de boot de 5s sur RGH2
=> La réponse est peut être déjà donnée ?
note: 1,65V donne un seuil d'environs 92%
Plus le seuil est haut plus on va filtrer les parasites sur POST_OUT1 mais si le signal est trop faible on va rien voir non plus !
Sur RGH2, la résistance de 10 ohms pour moi ne sert qu'a limiter la sortie du courant sortant de l'IO pour protéger la CM qui doit avoir un courant plus faible (supposition).
Donc avec ou sans cette résistance ça ne doit pas changer la donne,
de plus cette valeur doit être propre à la CoolRunner de TX (propre a leur régulateur de 1,8v)
donc pas forcement bonne pour toutes les autres cartes à voir ....
Chez moi j'ai mesuré ces valeurs pour une RGH v1.1 sur PHAT de type falcon qui boot en 5s
avec VCCIO1=1,8V provenant de la CM (je ne suis plus sur de la valeur: entre [1,78-1,81]V)
et son cable d'alimentation toujours branché:
POST_OUT1:
Power OFF = 0V
Power ON = 1,14V
Au moment du Glitch = 0,9V (ca doit descendre plus bas mais au multimetre ca a tendance a moyenner la valeur)
Xell qui s'affiche = 1,14V
STBY_CLK = clock 48Mhz = tension de 1,75V tout le temps
CPU_RST:
Power OFF = 0V
Power ON = 1,15V
Glitch = mesure impossible a faire avec le multimetre mais ca doit surement tendre vers 0V
Xell qui s'affiche = 1,15V
d’après mes lectures CPU_RST doit être de 1,1V donc ma valeur semble cohérente ...
Merci pour vos lumières et si vous avez d'autres valeurs de tension je suis preneur...
Modifié par xvassor, 31 mai 2012 - 10:40.
