SDisk Emul project Final et pré-commandes - Page 24

EDIT : arf, tu as édité ton message pendant que je tapais le mien
Je regarde ce que tu as changé

Jeff_HxC2001 (./688) :
Parce que pas vraiment compatible : ça sort du cmos

La plage de sortie du CMOS est plus stricte que celle du TTL, donc normalement ça ne pose pas de problème

Jeff_HxC2001 (./688) :
et en plus c'est quasiment introuvable en open-collector (ou plutot open-drain...)

Je savais pas, j'ai regardé, effectivement c'est pas la joie :/
On trouve facilement en famille LVC par contre, et ça accepte un pull-up à 5 V en sortie.

Jeff_HxC2001 (./688) :
Ceci dis il faut tout de même adapter les signaux 5V en provenance des 74LS14 vers le FPGA. Le moyen le moins cher est la résistance de limitation.

Mouais
Ça revient à utiliser la diode de protection ESD interne du circuit comme clamp à Vcc + 0.5. Ça marche, mais c'est plutôt crade, et potentiellement risqué (que se passe-t-il si l'alimentation de la carte n'est pas connectée mais que le nappe floppy est branchée ?).

Sinon l'autre technique est de travailler en open collector 3.3V entre les 74LS14 & le fpga.

Mieux, mais les temps de montée vont être assez mauvais, vu qu'il n'y a qu'un pull-up qui drive la ligne dans ce cas. Celà dit, aux fréquences des signaux floppy, c'est peut-être pas un vrai problème.

Dernière technique: le buffer spécialisé.

C'est quand même le plus propre et le plus sûr
Un LVC conviendrait bien aussi.

Donc pour résumer, moi je préconiserais :
- 74LVC06 en sortie (ou 74LS06 si tu y tiens vraiment )
- 74LVC14 en entrée

Jeff_HxC2001 (./689) :
Et autre truc très important a ne pas oublier : il faut pouvoir driver 48mA

Arf, pas pensé à ça
Pour la famille LVC le max. c'est 24 mA. Ça marcherait en mettant 2 buffers en parallèle, mais bon, ça double le nombre de composants....

T'as gagné, je m'incline, le mieux c'est un 74LS06

(très intéressant le document sinon, je garde ça sous le coude si jamais je fais un truc sur disquettes un jour )

Zerosquare (./691) :

Jeff_HxC2001 (./688) :
Ceci dis il faut tout de même adapter les signaux 5V en provenance des 74LS14 vers le FPGA. Le moyen le moins cher est la résistance de limitation.

Mouais
Ça revient à utiliser la diode de protection ESD interne du circuit comme clamp à Vcc + 0.5. Ça marche, mais c'est plutôt crade, et potentiellement risqué (que se passe-t-il si l'alimentation de la carte n'est pas connectée mais que le nappe floppy est branchée ?).

Mais C'est une pratique assez courante. Regardes comment sont connectées les SDCard sur l'hxcfloppyemulator et le Sdiskemul ;-)

Le problème de l'alimentation coupée tu l'auras avec n'importe quel chip possedant des diodes de clamping: le circuit sera alimenté par les signaux (regardes comment se comporte un système avec un lecteur de disquette non alimenté ;-) ). C'est pour cela qu'il est preferable d'avoir un circuit d'alim 5V séparé de l'alim fpga 3.3V pour l'interface floppy: le fpga ne sera pas a priori impacté par ce phenomene. il faudra peut être protégé les signaux entre le driver et le fpga (la resistance en est une ;-) ) mais bon ça commence a faire beaucoup.

t'ain, mais comment vous faites pour être aussi balaise en électronique..moi je sais rien faire

ba je bricole et je travaille dans le domaine ;-).

Pareil

Jeff_HxC2001 (./693) :
Mais C'est une pratique assez courante. Regardes comment sont connectées les SDCard sur l'hxcfloppyemulator et le Sdiskemul ;-)

Je sais, je sais
Mais pour un truc aussi "sensible" qu'un FPGA, je trouve pas ça terrible, c'est tout

De toute façon, même en choisissant la "solution résistance", il te faudra un buffer à trigger de Schmitt avant. Donc je ne vois pas l'intérêt de mettre un 74LS14 + des résistances, alors que tu peux choisir un 74LVC14 qui est connectable directement sur les entrées du FPGA.

jul2149 (./694) :
t'ain, mais comment vous faites pour être aussi balaise en électronique..moi je sais rien faire

+1

Zerosquare (./696) :
Pareil

Jeff_HxC2001 (./693) :
Mais C'est une pratique assez courante. Regardes comment sont connectées les SDCard sur l'hxcfloppyemulator et le Sdiskemul ;-)

Je sais, je sais
Mais pour un truc aussi "sensible" qu'un FPGA, je trouve pas ça terrible, c'est tout

De toute façon, même en choisissant la "solution résistance", il te faudra un buffer à trigger de Schmitt avant. Donc je ne vois pas l'intérêt de mettre un 74LS14 + des résistances, alors que tu peux choisir un 74LVC14 qui est connectable directement sur les entrées du FPGA.

Je n'ai pas dis le contraire: L'adaptation est obligatoire avec les HCT (5V) mais pas avec les LVC (3.3V).
Mais il faut vérifier que les seuils de commutations sont compatibles entre la version 5V & 3.3V, ce qui n'est pas forcement gagné.

tiens pour vous faire rigoler va y'avoir des SDXC

ok Jeff je corrige ces erreurs.....

squalyl : tu parles de la prochaine génération de cartes SD ? (cf ./644 et ./677)

Jeff : d'après les datasheets TI :
74LS14 : seuil "bas" entre 0.6 V et 1.1 V, seuil "haut" entre 1.5 V et 2 V (hystérésis min : 0.4 V)
74LVC14A : seuil "bas" entre 0.6 V et 1.5 V, seuil "haut" entre 0.9 V et 2 V (hystérésis mini : 0.3 V)

Reste à voir si c'est un problème ou pas. Les extrêmes sont les mêmes, donc la seule différence devrait être un très léger décalage de l'instant de basculement. Par contre l'immunité au bruit sera un peu moins bonne à cause de l'hystérésis plus faible.

Le schéma :

Fichier joint : ultimate.pdf


en cours de réalisation.....

les remarques sont les biens venues.

petites precisions:

la sdcard est cablée pour pouvoir fonctionné en spi et 4bits.

en bas 1 er pavé = sdram
du 2 au 5eme = sram



les 2 ports floppy:

celui du haut a gauche = external , pour piloter un lecteur de disquette réél (re-écriture d'images protégées)

celui du bas a gauche = port d'emulation d'un floppy.

La SDXC:
http://www.clubic.com/actualite-249814-carte-memoire-sdxc-extended-capacity.html

Beurk, ils ont choisi l'exFAT

(enfin, c'est moins pire que le NTFS à gérer normalement, mais pour le moment le standard est fermé)

Un espoir ?:
"The faster bus speeds in the SDXC specification also will benefit SDHC, Embedded SD and SDIO specifications."
http://www.sdcard.org/developers/tech/sdxc/

Mouais... c'est assez flou comme déclaration, faut attendre de voir.

Questions / Réponses / conseils rapides (d'autres suivront)

-> Il me semble qu'il manque quelques pull-up sur le connecteur jtag
-> a quoi servent les résistances R13-R29 du bus de donné entre le fpga et les ram?
-> remarque : sur cyclone III : VCC_PLL = 2.5V , VCC_INT = 1.2V et VCC_IO = 3.3V dans notre cas.
http://www.altera.com/literature/dp/cyclone3/PCG-01003.pdf
-> je pense que tu le sais déjà, mais il manque les capa de découplage ;-).
Il faudra être vigilent avec les alims des pll.
-> sur les connecteurs d'extension a quoi servent les 74ls06 ?
-> pourquoi avoir mis des resistances en series entre la sd & le fpga ?
-> il faut prévoir des protections ESD sur la sortie VGA.

Jeff_HxC2001 (./708) :
-> remarque : sur cyclone III : VCC_PLL = 2.5V , VCC_INT = 1.2V et VCC_IO = 3.3V dans notre cas.
http://www.altera.com/literature/dp/cyclone3/PCG-01003.pdf

plus précisément : VCC_PLLA = VCCA = 2.5V et VCC_PLLD = VCORE = 1.2V comme ce que sundance a fait
et comme tu le fais remarquer, il faut être vigilant sur les alims des pll.

SCPCD (./709) :

Jeff_HxC2001 (./708) :
-> remarque : sur cyclone III : VCC_PLL = 2.5V , VCC_INT = 1.2V et VCC_IO = 3.3V dans notre cas.
http://www.altera.com/literature/dp/cyclone3/PCG-01003.pdf

plus précisément : VCC_PLLA = VCCA = 2.5V et VCC_PLLD = VCORE = 1.2V comme ce que sundance a fait
et comme tu le fais remarquer, il faut être vigilant sur les alims des pll.

Dans ce cas c'est bon ;-).

Par contre je vois un pb dans le design : Le bus de data est partagé entre les SRAM, le FPGA, et le PIC. A mon avis ce n'est pas une bonne idée surtout pour garantir les accès du PIC dans le FPGA : Il risque d'avoir un conflit d'accès et pour pouvoir faire fonctionner ça il va falloir mettre en place un système de contrôle/partage de bus relativement lourd (genre le pic demande le bus au fpga, le fpga acquitte, le pic fait son accès). Ce cas de figure (l'accès concurrent) risque de se produire régulièrement, notamment pendant l'emulation floppy : le fpga va chercher les data des tracks en sram, et le pic envoi les prochaines data/tracks ou ce que vous voulez en sram.

Moi j'aurais plutôt vu le fpga au centre du truc pour tous ce qui concerne les transfers entre les différents bus a savoir le bus pic, le bus sram et le bus externe. La ram interne du fpga permettent de mettre en place de méthode de transfert assez avancée pour obtenir les meilleurs perf possible : FIFO, ring buffer , etc.
Exemple le fpga occupe la sram pour une tache X (exemple :lecture au fil de l'eau les data d'une piste de la disquette, ou d'un CD ;-) ), et le pic veux faire des accès dans cette même sram pour préparer une tache Y: pas de pb, lorsque le pic écrit les valeurs, le fpga les stocke temporairement pour pouvoir les transférer a son rythme tout en garantissant le traitement de la tache X, et sans mettre le pic en attente.

Ceci dit cela demande plus de gpio sur le fpga et vu qu'il est déjà bien occupé...

Je sais pas si j'ai bien compris le truc mais si tu as une autre idée de la stratégie d'accès bus je veux bien un petit cours ;-)

Jeff, je m'étais fait grosso modo les mêmes réflexions.

Pour le port PS/2, il faut des résistances de pull-up à 5 volts sur les 2 lignes, et de quoi faire la conversion de tension. Y'a un petit montage astucieux pour faire ça dans une doc Xilinx :

(bon pour les selfs et les condensateurs, je trouve qu'ils chipotent un peu, mais bon ^^)

Ou alors on peut aussi le faire façon Jeff et se contenter de résistances

Ou alors on peut aussi le faire façon Jeff et se contenter de résistances

lol non ce n'est pas ma méthode mais une méthode bien sale pour adapter des niveaux ;-). Si un bas prix est un objectif primordial, dans ce cas elle peux être envisagée. Pour le reste un buffer est toujours plus sage ;-) .

Jeff_HxC2001 (./710) :
Moi j'aurais plutôt vu le fpga au centre du truc pour tous ce qui concerne les transfers entre les différents bus a savoir le bus pic, le bus sram et le bus externe. La ram interne du fpga permettent de mettre en place de méthode de transfert assez avancée pour obtenir les meilleurs perf possible : FIFO, ring buffer , etc.
Exemple le fpga occupe la sram pour une tache X (exemple :lecture au fil de l'eau les data d'une piste de la disquette, ou d'un CD ;-) ), et le pic veux faire des accès dans cette même sram pour préparer une tache Y: pas de pb, lorsque le pic écrit les valeurs, le fpga les stocke temporairement pour pouvoir les transférer a son rythme tout en garantissant le traitement de la tache X, et sans mettre le pic en attente.

le problème est surtout sur le partage des accès en lecture de la ram, principalement de la sdram.
il faudra obligatoirement un moyen pour prévenir le pic que les datas ne sont pas prête car si le fpga fait un burst en sdram et que le pic lui demande de lire une data dans une page non ouverte ou si il y a un refresh en cours, plus les délais de propagation entre la synchro des signaux, les traitements, etc, ça peut prendre du temps, même avec de la sdram avec une clock assez élevé.

Le partage des accès ça devient vite tordu

SCPCD (./713) :

Jeff_HxC2001 (./710) :
Moi j'aurais plutôt vu le fpga au centre du truc pour tous ce qui concerne les transfers entre les différents bus a savoir le bus pic, le bus sram et le bus externe. La ram interne du fpga permettent de mettre en place de méthode de transfert assez avancée pour obtenir les meilleurs perf possible : FIFO, ring buffer , etc.
Exemple le fpga occupe la sram pour une tache X (exemple :lecture au fil de l'eau les data d'une piste de la disquette, ou d'un CD ;-) ), et le pic veux faire des accès dans cette même sram pour préparer une tache Y: pas de pb, lorsque le pic écrit les valeurs, le fpga les stocke temporairement pour pouvoir les transférer a son rythme tout en garantissant le traitement de la tache X, et sans mettre le pic en attente.

le problème est surtout sur le partage des accès en lecture de la ram, principalement de la sdram.
il faudra obligatoirement un moyen pour prévenir le pic que les datas ne sont pas prête car si le fpga fait un burst en sdram et que le pic lui demande de lire une data dans une page non ouverte ou si il y a un refresh en cours, plus les délais de propagation entre la synchro des signaux, les traitements, etc, ça peut prendre du temps, même avec de la sdram avec une clock assez élevé.

Le partage des accès ça devient vite tordu

Oui c'est ce que je voulais signaler.
Pour la sdram le fpga contiendra a priori un contrôleur sdram rudimentaire : a savoir qu'il saura lire/écrire une "page" (genre de 1Ko) entière en burst dans le fpga, puis le pic pourra aller piocher dans le fpga. Une ligne d'IT est (doit) prévue pour indiquer la fin du transfert.
Le but étant de pouvoir avoir une quantité de ram beaucoup importante par rapport a la sram.

je rajoute les pull-ups sur les borches de prg et jtag et corrige les appellations des alimenattions.

je n'est pas mis les capa (0.1µ) pour ne pas alourdir le schéma.

pour la partie alimentation ca viendra aussi plut tard.


pour le port ps2 le + simple est prendre la solution xilinx.... (je réfléchis la dessus on pourrais aussi le connecter sur le pic 5v tolerant)


oui en effet le partage de bus, n'est pas simple a gérer.

sachant que le problème est le nombre de broches du fpga.

donc plusieurs solution:


solution 1 les bus séparés (la meilleur)

avoir une bus sur la sdram/sram + un bus pour le pic + 2 port floppy + un bus externe

le fpga pioche dans la sdram/sram quand le pic fait une requete il l'a traite dès qu'il le peut (int4 du pic est prevue pour lui indiquer la disponibilté ou la fin du transfert)

le revers c'est qu'il faut un nombre important de broches/pins si vous avez des propositions pour optimiser leur nombre...

le multiplexage en est une ....


solution 2 le bus partagé


le fpga gère les sdram/sram il est donc prioritaire, si le pic veut faire un accès il doit faire un bus request et attendre une IT (bus_ack), genre bus 68000

la difficulté vient que seul le bus de data est partagé,

en effet la, ca devient complexe car le pic va mettre sur le bus de data l'adresse de la page memoire voulue (via ses signaux de controle ALE) cette adresse de départ doit etre stockée dans un compteur puis tranférée sur le bus d'adresse des memoires du fpga,

avant chaque transfert le pic controle le signal busy en provenance du fpga.(et attends si il le faut)

enfin a chaque clock founit par le pic au fpga(encore un signal de controle), ce dernier incrémente sont compteur et transfert la valeur obtenue sur le bus d'adresse des mémoires. si le fpga a besoin du bus il monte le signal busy.

quand le pic a fini il relache le bus_request

ouf !


a oui le pic n'accéderas pas a la sdram est est trop rapide pour lui.....

en plus avec 2 mo de sram (au mini je pense que ce seras plutot 4mo).... ya de quoi faire

c'est vrai cette méthode est lourde....

si avez une idée une idée Jeff ,SPCD, Zerosquare et ceux qui regardent et ne post jamais (c'est de l'humour)



bon on enfonce le clou

il faut surtout penser que ce seras plutot le contraire, le fpga soustraiteras certaines taches complexe au pic:

le fpga veut la liste des fichiers sur la sdcard histoire de l'afficher sur le port vga, il demande au pic de lui macher le travail, le pic lui demande de stocker le dir en question en sram, le pic transforme en quelque de + comprhensible pour faire de la video par le fpga.

le fpga veut lire une entrée analogique du pic, lire les pors usb / joysticks / pwm / entrées et sorties (open collector en 5v) / LCD 2x16 / etc

dans ces cas il faudrais plutot penser le pic comme un periphique vue dans l'espace memoire adressable par le fpga.

a ne pas oublié aussi le pic a 32 ko de ram interne et 512 ko de flash

ouf ! ouf!

mais je suis et reste ouvert a toute proposition.

Bonjour,

Je continue à suivre ce topic, même si je ne comprends rien 95% du temps. Puisque je vous ai suggeré l'idée de l'ajout de la dreamcast, je peux vous en donner une dont le lecteur et plus ou moins en loose si vous voulez faire des tests. Et tant pis si à la suite de ces tests la DC decede.
Sinon, et je suis peut-etre hors sujet, le minimig ( une petite machine compatible Amiga dont le lecteur de D7 est remplacé par un lecteur SD ) supporte les HDF ( hard file drive ) ce qui permet de booter sur le workbench et d'utiliser la capacité de la SD comme un disque dur ( si j'ai bien compris ). Est-ce que cela est aussi possible avec l'emulateur que vous préparez ?

Merci

Tiki

Pour le partage de bus fpga/pic, je me demande si la question a vraiement lieu d'être...

Le FPGA a de la ram interne dans laquelle il peut stocker pas mal de trucs (framebuffer pour la sortie vga par exemple ?). Si on conçoit le truc proprement, le fpga ne fera des accès à la ram externe que si le pic le lui demande (du genre, "va chercher la liste des directory à l'adresse x"). On peut imaginer que le fpga ne prend jamais arbitrairement le contrôle du bus mais attend que le pic lui demande de faire quelque chose.
ça suppose que le pic se met en veille quand le fpga fait des accès intensifs à la ram (genre, dump d'une disquette), mais dans ces cas là on peut peut être utiliser la sdram à laquelle le pic n'accède jamais de toutes façons.

En conclusion, on peut voir le fpga comme un périphérique externe (et pas comme un second cpu). Avec à la limite des accès DMA qui peuvent bloquer le PIC dans certains cas si c'est nécessaire.

PulkoMandy (./717) :
Pour le partage de bus fpga/pic, je me demande si la question a vraiement lieu d'être...

Le FPGA a de la ram interne dans laquelle il peut stocker pas mal de trucs (framebuffer pour la sortie vga par exemple ?). Si on conçoit le truc proprement, le fpga ne fera des accès à la ram externe que si le pic le lui demande (du genre, "va chercher la liste des directory à l'adresse x"). On peut imaginer que le fpga ne prend jamais arbitrairement le contrôle du bus mais attend que le pic lui demande de faire quelque chose.
ça suppose que le pic se met en veille quand le fpga fait des accès intensifs à la ram (genre, dump d'une disquette), mais dans ces cas là on peut peut être utiliser la sdram à laquelle le pic n'accède jamais de toutes façons.

En conclusion, on peut voir le fpga comme un périphérique externe (et pas comme un second cpu). Avec à la limite des accès DMA qui peuvent bloquer le PIC dans certains cas si c'est nécessaire.

euh le FPGA n'a que quelques Ko en interne (~64Ko) , donc l'accès RAM externe est capital. Si c'est pour se retrouver aussi limiter qu'avec un PIC18 , autant le supprimer (ou supprimer la ram externe). Suivant l'encoding, 64Ko ça suffit a peine pour stocker une track floppy.

Tu parles du FPGA comme d'un périph & de framebuffer et bien regardes comment fonctionne une carte vidéo :
1) Soit le chip video accède a directement a sa RAM (bus non partagé, l'idéal)
2) Soit le chip video et le CPU partage la même RAM (comme sur ST et quelques PC pas cher), avec une priorité d'accès donné au chip vidéo (et non pas au CPU !).
Problème pour nous dans ce cas : pas de signaux dispo pour bloquer les accès PIC de façon transparente.

Note : Pour moi le composant principal c'est le FPGA et pas le PIC !

Tiki (./716) :
Bonjour,

Je continue à suivre ce topic, même si je ne comprends rien 95% du temps. Puisque je vous ai suggeré l'idée de l'ajout de la dreamcast, je peux vous en donner une dont le lecteur et plus ou moins en loose si vous voulez faire des tests. Et tant pis si à la suite de ces tests la DC decede.
Sinon, et je suis peut-etre hors sujet, le minimig ( une petite machine compatible Amiga dont le lecteur de D7 est remplacé par un lecteur SD ) supporte les HDF ( hard file drive ) ce qui permet de booter sur le workbench et d'utiliser la capacité de la SD comme un disque dur ( si j'ai bien compris ). Est-ce que cela est aussi possible avec l'emulateur que vous préparez ?

Merci

Tiki

Le sujet a déjà été invoqué, mais le support DC semble effectivement possible. il s'agit a priori d'emuler une interface IDE/ATAPI. Cela se fera a priori plus tard.

Pour l'émulation HDD sur amiga, c'est possible si celui ci possède un bus HDD de base. Sur amiga 500 il n'y en a pas il me semble (sur 600 & 1200 c'est de l'IDE encore une fois. ;-) )

En attendant, il reste un truc qui n'est pas possible avec les émulateurs de floppy...