Delta Island

Je sais pas faire

OK, ce n'est pas grave .

Les CPLD Microchip se programment en CUPL. En gros, ce sont des équations logiques et des descriptions d'automates à états finis. Les outils sont horribles mais pas difficiles à prendre en main, je les utilise régulièrement pour programmer mes GAL. Pour du CPLD, c'est peut-être un poil trop limité. Et après, pour transférer la configuration dans le CPLD, il faut des outils potentiellement pas donnés, et qui ne tournent pas sur toutes les machines.

Les CPLD Intel/Altera se programment avec les outils de la suite Quartus Prime (Intel) dont il existe une versio gratuite. C'est beaucoup plus complexe, mais c'est maintenu. Là, il faut clairement s'accrocher pour la prise en main.
Par contre, on entre dans le monde réel: ça se programme en VHDL ou en Verilog (les 2 sont équivalents). Idem, c'est de la description de comportement dans un langage adapté. Quartus permet ensuite de câbler le programme sur un modèle de CPLD (ou de FPGA, pareil) en voisissant quelle "variable" est raccordée à quelle broche du CPLD.
Les outils viennent avec un outil gratuit de simulation (ModelSim), au moins jusqu'à la version 20.x (?), qui permet de simuler des entrées et d'observer les sorties en retour. Je m'en suis servi pour programmer des tests automatiques qui cassent la simulation si les résultats attendus ne sont pas conformes aux attentes. C'est pratique.
Et là, pour injecter la configuration dans le CPLD, il faut aussi un périphérique spécifique (un USB Blaster) dont il existe des clones (j'en ai un, 10€).

J'ai pratiqué Quartus sans être allé au bout de mes projets, et j'ai une carte de dev avec un CPLD dessus (10€ ) qui permet de s'amuser et vérifier qu'on ne fait pas n'importe quoi. J'ai appris le VHDL pour l'occasion, et je suis moins à l'aise avec le Verilog.

Cela dit, j'ai regardé le "code" du NEO-C1, et ce n'est pas la mer à boire. La puce est plutôt simple, donc le code aussi. Il reste quand même quelques commentaires dans le code qui suggèrent que tout n'est pas câblé à 100%, ce qui ne pose pas de problème pour de l'émulation, mais qui pourrait le devenir pour du matériel réel.

Bref, je partirais bien sur de l'Intel, mais il faut que je bosse un peu pour le mettre à niveau!

Ce pourrait faire une vidéo intéressante sur la génèse de la puce si on arrive à quelque chose!

Pour ma part, CPLD/FPGA Altera OK -> USB Blaster Clone sous Quartus prime
Xilinx OK aussi

J'ai fait pas mal de projet sous CPLD/FPGA (VHDL-Vertilog + Super fonction), mais le plus interessant (qui n'est pas de moi) )-> Sega Gamer Cartridge de pastek

Petit projet qui commence a dater :
viewtopic.php?p=1613#p1613

Sympa, ça!
Eh ben partir sur de l'Altera ne semble pas une mauvaise idée, du coup! A tout hasard, tu as jeté un oeil au code du projet Mister?
je ne vois définitivement pas ça comme un gros projet. Il faut surtout qu'on trouve un moyen efficace de rattacher ce CPLD à l'empreinte du NEO-B1 sur le PCB!

Alors ce ne sera pas un problème.
Je termine le design du flex asap

Pour m'auto-répondre, j'ai l'impression qu'on peut utiliser un "stiffener", pour rigidifier certaines parties (les connecteurs, typiquement), et qu'on pourrait s'en servir pour rigidifier le dos du PCB à l'emplacement du CPLD.

Un retour d'expérience sur le soudage sur PCB flex? Ca se fait bien? (ça se fait, tout court?)

J’ai trop patientes AES qui attendent des organes en Neo-C1
Je pourrais procéder aux tests de montage et d’essais

Idem pour mon cimetière de mvs !

Bouz a écrit : mer. 7 févr. 2024 22:12 Pour m'auto-répondre, j'ai l'impression qu'on peut utiliser un "stiffener", pour rigidifier certaines parties (les connecteurs, typiquement), et qu'on pourrait s'en servir pour rigidifier le dos du PCB à l'emplacement du CPLD.

Un retour d'expérience sur le soudage sur PCB flex? Ca se fait bien? (ça se fait, tout court?)

Sur un flex ça se soude très bien

Schéma interne
https://github.com/furrtek/SiliconRE/bl ... matics.pdf

Définition logique verilog
https://github.com/MiSTer-devel/NeoGeo_ ... ter/rtl/io

Ah ben super, les 2 sources se complètent .
Le neo_c1.v donne la logique, avec 2 collentaires qui indiqueraient qu'il n'est pas complet.
Le schéma devrait boucher les trous.
J'essaie de regarder ça cette semaine.

Quand j’ai vu le post comme quoi furtek parlait qu’il n’y avait pas assez de place pour la puce de remplacement
j’ai pensé direct au système flex pour une déportation de la puce !
cela me paraissait logique mais je n’ai pas osé vous en faire part…
comme vous avez eu la même idée que moi ce n’était pas si bête finalement
J’avais pensé à deux solutions pour la nappe dont une comme Bouz en deux parties

J’ai pris l’image de Xrider pour l’exemple mais les flex sont à souder sur la carte mère de la Neo bien sûr

Première idée qui demande un arrangement des pistes tout autour :



À voir si avec toutes les pistes la nappe ne sera pas trop large l’avantage c’est que le connecteur de 100 Ali express peut être posé sur le pcd qui reçoit la puce.

Deuxième idée celle qui rejoint celle de Bouz 2 flex pour 2 connecteurs :



Un flex en L (rouge) pour l’extérieur et un flex en L (bleu) pour l’intérieur
ce qui permet de superposer les nappes pour une connexion une derrière l’autre sur le pcb qui reçoit la puce.

Je partage avec vous les idées que j’ai eu ces derniers jours si cela peut vous aider
Pour la deuxième photo j’ai schématiser au max car le dessin sur pc ce n’est pas mon truc.