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 !
Jelectronique.com
Bienvenue sur le Forum Jelectronique
Choix de matériel
Modérateur: Modérateur
11 messages • Page 1 sur 2 • 1, 2
de JP le 12 Mai 2005 6:11
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
-
JP - Administrateur
- Messages: 2325
- Inscription: 23 Sep 2003 18:14
- Localisation: Strasbourg
de Invité le 12 Mai 2005 9:06
Merci beaucoup pour tes conseils JP ! 
Je crois que je vais commencer par tester avec un CPLD d'Altéra !
Encore une petite question, des composants comme ca, tu en trouves dans des magasins d'électroniques ou il faut commander directement à Altéra ? (il font de la vente à l'unité ?)
Je crois que je vais commencer par tester avec un CPLD d'Altéra !
Encore une petite question, des composants comme ca, tu en trouves dans des magasins d'électroniques ou il faut commander directement à Altéra ? (il font de la vente à l'unité ?)
- Invité
de JP le 12 Mai 2005 11:59
Merci beaucoup pour tes conseils JP !
De rien
Encore une petite question, des composants comme ca, tu en trouves dans des magasins d'électroniques ou il faut commander directement à Altéra ?
Les cpld de la série max7000s (EPM7064SLC44, EPM0128SLC84 etc) tu peux les trouver chez Radiospares.
-
JP - Administrateur
- Messages: 2325
- Inscription: 23 Sep 2003 18:14
- Localisation: Strasbourg
de sab le 16 Mai 2005 8:41
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??
- sab
de JP le 16 Mai 2005 12:27
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.
Il y a des circuits intégrés faits pour ça, les UART.
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.
Car si je ne me trompe pas, il faut utiliser un registre à décalage,
Il y a des circuits intégrés faits pour ça, les UART.
a+
JP
-
JP - Administrateur
- Messages: 2325
- Inscription: 23 Sep 2003 18:14
- Localisation: Strasbourg
de sabord le 17 Mai 2005 8:31
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
- sabord
- PONCTUEL
- Messages: 18
- Inscription: 16 Mai 2005 8:02
de JP le 17 Mai 2005 8:40
par contre pour moi elle tient sur 16 bits
Donc il faudra que tu divises ton nombre en 2 et envoyer les 2 blocs en 2 trames de 8bits
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.
Pas sûr que la solution des registres à décalage soit la plus simple. Si tu as un cours dessus, pourquoi pas, ça marche aussi
a+
JP
-
JP - Administrateur
- Messages: 2325
- Inscription: 23 Sep 2003 18:14
- Localisation: Strasbourg
de sabord le 17 Mai 2005 10:01
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
- sabord
- PONCTUEL
- Messages: 18
- Inscription: 16 Mai 2005 8:02
de JP le 17 Mai 2005 16:39
vers un max232 pour effectuer une conversion de tension...si je me souviens bien.
Oui c'est bien ça.
Mais je ne sais plus à quel pin du max232 peut bien correspondre le signal busy??
Dans un max tu as 4 convertisseurs.
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.
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 générale ça se passe comme ça, mais c'est une question de convention :
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
-
JP - Administrateur
- Messages: 2325
- Inscription: 23 Sep 2003 18:14
- Localisation: Strasbourg
11 messages • Page 1 sur 2 • 1, 2
Retourner vers Electronique numérique et logique programmable
Qui est en ligne
Utilisateurs parcourant ce forum: Aucun utilisateur enregistré et 0 invités