Salut !
Je suis un étudiant en stage, et on me demande de faire une carte permettant de faire de l'acquisition de donnée sur un réseau rapide (12 MBps). Le but de la carte serait d'enregistrer toutes les données dans un buffer pendant quelques secondes, et ensuite d'envoyer celles ci à un PC par une interface quelconque (sûrement RS232)
Je n'ai jamais travaillé avec des FPGA ou CPLD, mais je trouve que ca pourrait être bien adapté, et ce serait une excellente occasion de commencer !
L'application devrait donc :
- Effectuer un traitement extêmement simple (remplir un buffer et le vider ensuite)
- Posséder une vitesse d'acquisition suffisante pour 12 MBps
- Posséder une RAM entre 4 et 8 Mbytes
Le problème est que n'ayant jamais programmé ce genre de composant, j'ai beaucoup de mal à juger lequel serait le plus adapté.
Est-ce que vous pourriez me conseiller un matériel qui pourrait fonctionner pour ce genre d'application ? CPLD ? FPGA ? Altera ? Xilinx ?
Je suis preneur de tout conseil !
Merci d'avance !
Choix de matériel
Modérateur : Modérateur
-
JP
- Administrateur
- Messages : 2323
- Inscription : 23 sept. 2003 18:14
- Localisation : Strasbourg
- Contact :
Salut Duc !
Vu que je débute je ne vais pas être d’une très grande aide.
Je peux juste te dire que les CPLD d'Altera peuvent aller jusqu'à 150Mhz.
Cette fréquence diminue en fonction des temps propagations donc du nombre de portes que tu utilises.
Les FPGA ne sont, apparemment, pas plus rapide il permette juste d'utiliser plus de portes. Au niveau des boîtiers les FPGA sont en CMS alors que les CPLD existent en PLCC, peut être plus simple pour débuter.
Altera ou Xilinx ? A première vue, je dirais que c’est la même chose. Les environnements de dev sont apparemment du même niveau, autant de choix, aussi disponible l’un que l’autre.
Tu peux déjà commencer par essayer un des deux environnements de développement, voir les deux, faire quelques simules avec des trames de 12MBps et voir ce que ça donne.
a+
JP
Vu que je débute je ne vais pas être d’une très grande aide.
Je peux juste te dire que les CPLD d'Altera peuvent aller jusqu'à 150Mhz.
Cette fréquence diminue en fonction des temps propagations donc du nombre de portes que tu utilises.
Les FPGA ne sont, apparemment, pas plus rapide il permette juste d'utiliser plus de portes. Au niveau des boîtiers les FPGA sont en CMS alors que les CPLD existent en PLCC, peut être plus simple pour débuter.
Altera ou Xilinx ? A première vue, je dirais que c’est la même chose. Les environnements de dev sont apparemment du même niveau, autant de choix, aussi disponible l’un que l’autre.
Tu peux déjà commencer par essayer un des deux environnements de développement, voir les deux, faire quelques simules avec des trames de 12MBps et voir ce que ça donne.
a+
JP
-
Invité
-
sab
c marrant, mais je suis en stage, et je vais aussi devoir faire quelque chose de similaire.Sauf que moi c des informations venant d'un codeur optique que je dois envoyer via port série.
et mon pb se situe ds l'utilisation d'un multiplieur:
qd il fonctionnera, j'obtiendrai une variable de type real:
et je ne sais pas comment envoyer ce type de variable sur port série.
Car si je ne me trompe pas, il faut utiliser un registre à décalage, et envoyer bit à bit, mais pour un type real? ct envoyer ça en bit à bit.
?
je veux dire, est-ce qu'un real, peut se lire bit à bit??
et mon pb se situe ds l'utilisation d'un multiplieur:
qd il fonctionnera, j'obtiendrai une variable de type real:
et je ne sais pas comment envoyer ce type de variable sur port série.
Car si je ne me trompe pas, il faut utiliser un registre à décalage, et envoyer bit à bit, mais pour un type real? ct envoyer ça en bit à bit.
?
je veux dire, est-ce qu'un real, peut se lire bit à bit??
-
JP
- Administrateur
- Messages : 2323
- Inscription : 23 sept. 2003 18:14
- Localisation : Strasbourg
- Contact :
Tu peux coder ton nombre en virgule fixe avec une convention que tu te fixes:
4 bits de partie entière et 4 bits de partie décimale
ex : 5.750 => 0101,1100
Ou alors en virgule flottante (IEEE 754) sur 32 bits
1 bit de signe, 8 bits d'exposant et 23 bits de mantisse
Donc la méthode à virgule flottante nécessitera 4 trames de 8 bits pour véhiculer 1 nombre alors que la méthode à virgule flottante qu'une.
A toi de voir si la précision est importante si la plage de variation de ton nombre est importante ou alors plus la vitesse de transmission.
a+
JP
4 bits de partie entière et 4 bits de partie décimale
ex : 5.750 => 0101,1100
Ou alors en virgule flottante (IEEE 754) sur 32 bits
1 bit de signe, 8 bits d'exposant et 23 bits de mantisse
Donc la méthode à virgule flottante nécessitera 4 trames de 8 bits pour véhiculer 1 nombre alors que la méthode à virgule flottante qu'une.
A toi de voir si la précision est importante si la plage de variation de ton nombre est importante ou alors plus la vitesse de transmission.
Il y a des circuits intégrés faits pour ça, les UART.Car si je ne me trompe pas, il faut utiliser un registre à décalage,
a+
JP
oui, la virgule fixe, walla ce que ct ma deuxième solution que j'ai trouvé...
par contre pour moi elle tient sur 16 bits, car ça va de 0 à 180...
mais bon c ça l'idée.
sinon g choisi le registre à décalge car je me suis rappelé avoir fait quelque chose de similaire en cours.
J'avais entendu parler des uart, mais je ne m'en suis jamais servi du moins je ne crois pas.
à prori ça devrait marcher. En tout cas ça compile. Je suis encore au stade où je découvre quartus 2 et g pas encore pigé toutes ses fonctionnalités...
En fait g pas encore choisi kel composant j'allais prendre...
je dois bosser à l'envers... lol
par contre pour moi elle tient sur 16 bits, car ça va de 0 à 180...
mais bon c ça l'idée.
sinon g choisi le registre à décalge car je me suis rappelé avoir fait quelque chose de similaire en cours.
J'avais entendu parler des uart, mais je ne m'en suis jamais servi du moins je ne crois pas.
à prori ça devrait marcher. En tout cas ça compile. Je suis encore au stade où je découvre quartus 2 et g pas encore pigé toutes ses fonctionnalités...
En fait g pas encore choisi kel composant j'allais prendre...
je dois bosser à l'envers... lol
-
JP
- Administrateur
- Messages : 2323
- Inscription : 23 sept. 2003 18:14
- Localisation : Strasbourg
- Contact :
Donc il faudra que tu divises ton nombre en 2 et envoyer les 2 blocs en 2 trames de 8bitspar contre pour moi elle tient sur 16 bits
Pas sûr que la solution des registres à décalage soit la plus simple. Si tu as un cours dessus, pourquoi pas, ça marche aussisinon g choisi le registre à décalge car je me suis rappelé avoir fait quelque chose de similaire en cours.
J'avais entendu parler des uart, mais je ne m'en suis jamais servi du moins je ne crois pas.
a+
JP
effectivement c par 2 trames que j'envoie.
Je viens de finir ma machine d'état pour l'envoie des trames via registre à décalage. En vhdl, je ne vois pas en quoi ça rend plus compliqué, car ça ne prend pas énormément de temps qd on a déjà fait ce genre de chose...enfin à kekchose près....et à condition que je me sois pas trompé car pas encore simulé...
là où je me pose une question, c que lorsqu'on avait fait ça, on envoyait, en plus de la trame(car cette fois là y'en avait qu'une) un signal busy.
la trame + le signal busy était envoyé vers un max232 pour effectuer une conversion de tension...si je me souviens bien.
Mais je ne sais plus à quel pin du max232 peut bien correspondre le signal busy??...d'ailleurs il n'ya pas de pin correspondant non plus sur un port série, à part peut-être celui nommé DCD: data carrier detect...???
en tout cas, un signal busy me parait utile, pour éviter les collisions...
walla ce que c'est de faire des TPs avec tout juste le minimum d'explications....on croit qu'on a compris paske le TP il marche, mais en fiat il manque des choses: ce que le prof à hommis de dire ....ou qu'on a pas bien écouté....
Paske mine de rien, y'a qd même 9 pins sur un port série:
CTS, et RTS ne devraient à priori pas être utiles pour mon application....
DSR: data set ready.....hum, jamais utilisé pas à partir du vhdl en tout cas...
DTR:data terminal ready.....hum, idem
DCD:??
TX: y'a besoin
Rx: aussi
GND: aussi
RI: ring indicator....hum inconnu au bataillon
lol
bon j'ai un puzzle à finir moi
Je viens de finir ma machine d'état pour l'envoie des trames via registre à décalage. En vhdl, je ne vois pas en quoi ça rend plus compliqué, car ça ne prend pas énormément de temps qd on a déjà fait ce genre de chose...enfin à kekchose près....et à condition que je me sois pas trompé car pas encore simulé...
là où je me pose une question, c que lorsqu'on avait fait ça, on envoyait, en plus de la trame(car cette fois là y'en avait qu'une) un signal busy.
la trame + le signal busy était envoyé vers un max232 pour effectuer une conversion de tension...si je me souviens bien.
Mais je ne sais plus à quel pin du max232 peut bien correspondre le signal busy??...d'ailleurs il n'ya pas de pin correspondant non plus sur un port série, à part peut-être celui nommé DCD: data carrier detect...???
en tout cas, un signal busy me parait utile, pour éviter les collisions...
walla ce que c'est de faire des TPs avec tout juste le minimum d'explications....on croit qu'on a compris paske le TP il marche, mais en fiat il manque des choses: ce que le prof à hommis de dire ....ou qu'on a pas bien écouté....
Paske mine de rien, y'a qd même 9 pins sur un port série:
CTS, et RTS ne devraient à priori pas être utiles pour mon application....
DSR: data set ready.....hum, jamais utilisé pas à partir du vhdl en tout cas...
DTR:data terminal ready.....hum, idem
DCD:??
TX: y'a besoin
Rx: aussi
GND: aussi
RI: ring indicator....hum inconnu au bataillon
lol
bon j'ai un puzzle à finir moi
-
JP
- Administrateur
- Messages : 2323
- Inscription : 23 sept. 2003 18:14
- Localisation : Strasbourg
- Contact :
Oui c'est bien ça.vers un max232 pour effectuer une conversion de tension...si je me souviens bien.
Dans un max tu as 4 convertisseurs.Mais je ne sais plus à quel pin du max232 peut bien correspondre le signal busy??
2 qui font la conversion TTL/CMOS->RS232 et 2 qui font la conversion RS232->TTL/CMOS après il ne te reste plus qu'à choisir un des convertisseurs en fonction de la direction de transmission que tu souhaites.
En générale ça se passe comme ça, mais c'est une question de convention :d'ailleurs il n'ya pas de pin correspondant non plus sur un port série, à part peut-être celui nommé DCD: data carrier detect...???
L'émetteur demande la prise de ligne DTR=0
Le récepteur dit ok : DSR=0
L'émetteur veut émettre : RTS=0
Le récepteur dit OK: CTS=0
L'émetteur envoie sa trame
Le récepteur dit bien reçu: DCD=0