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

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.

Je réitère donc mon offre : Si vous avez besoin d'une DC pour faire des tests, je peux vous en donner une dont le lecteur ne fonctionne pas trop bien.
Par ailleurs, j'avais déja lu auparavant l'ajout eventuel de la la DC pour l'émulateur. Je suis déja intervenu à deux ou trois reprise à ce sujet..
Vous pouvez me contacter plus facilement par mp sur le site www.amigaimpact.org si toutefois vous avez besoin d'une DC au même pseudo


Tiki

Je suis prenneur pour la DC pour pré étude!

Pour moi aussi le composant principal est le fpga et le pic est un peripherique

le petit détail qui a son importance: le fpga tourne 5 a 10 fois plus vite que le pic, toutes les fonctionnalités qui y sont implémentées tournent en parallèles.

donc le fpga peut très bien gérer l'affichage vga en mème temps que la simulation de floppy ou autre et la lecture de la sdcard etc


ok on va revoir le tout:

le pic sert en premier lieu a charger le soft du fpga, c'est sa fonction première : de lire le soft fpga sur la sdcard ou dans ses propres 512 ko de flash et de l'envoyer au fpga
l'interèt c'est de pouvoir modifié le soft fpga de le mettre sur la sdcard et ca se debrouille pas besoin de programmateur ou de jtag.
les maj et autre fonctionnalités peuvent etre faites après coup par l'utilisateur (comme sur le sdisk).

j'ai mis un pic32 car la differentces entre un 18f et un 32 est ridicule (3 ou 4euros) pourquoi s'en privé.

maintenant autant profité un peu du pic 32, certaines choses ne sont pas evidentes a faire avec un fpga.

la solution peut etre est de faire une ou 2 liaisons liaisons series synchrones (voir en 8bits) avec le fpga dans ce cas on ne partage pas le bus

et ca resouds nos problèmes de partage ou conflit.

un protocole avec le fpga (serie ou autre) est a mettre au point ( j'ai deja fait pour la coupe m6) (euh j'ai aussi fait le bus partagé avec memoire double port cypress et ring buffer derriere c'est plus galère...)

qu'en pensez vous ?

je modifierais le schéma en conséquence...



ps: pour les fautes d'orthographes ma secrétaire est en grève...)

ps2: Zerosquare j'en ai aussi une bonne je fais une photo et post.....

Il faut juste faire attention que le pic aie accès à la sdcard quand le fpga n'est pas programmé. Sinon ça va avoir du mal à démarrer
Effectivement le pic n'a peut être pas besoin d'accès directs à autre chose et le fpga peut tout gérer en interne pour le reste...

Ok pour reduire la largeur du bus pic-fpga mais attention : il faut garder un lien offrant des perfs environ equivalent a la liaison usb (~1Mo) du pic.
Si le problème est potentiellement résolu entre le pic& le fpga, l'est il entre la ram et le bus externe ?

Autre point : Il faut une frequence minimum pour le fpga pour demarrer les pll du fpga (~18Mhz je crois, plus sur...). Ce point est il ok ?

je réserve un des 2 liens spi du pic pour la liason vers le fpga, d'après la doc de microchip il fonctionne jusqu'a 25Mb/s, au dela microchip reste évasif (theorique = 40 Mb/s)

mais 25Mb/s devrait largement nous suffire. je vais rajouter quelque i/o entre le fpga et le pic pour le future mais ca va quand mème nous liberer pas mal de pinoches.

pour le bus externe je vais intercaler de 74lvc 245 si ca te convient Jeff ?

tu as pu remarquer que je n'ai pas mis les oscillateurs sur le schéma, c'est un point a éclaircir >> j'ai plusieurs questions et options:

j'ai des oscillateurs 40mhz (5 volts) sous le coude >> en sortie oscillations 2.5 v crètes , cela peut_il convenir pour le fpga ?
pour le pic je vais faire des essais pour voir....

d'après les doc altera une seul clock peut étre distribuée sur tous les secteurs du fpga (cyclone 3 only) et servir a en générer d'autre horloge dailleur, (la dessus j'ai besoin de vos avis)

une autre solution, il me reste une centaine de quartz 20 mhz low profile (je dis bien quartz) peut ont les utiliser sur le fpga ? (entrées differentiell clock)

je vais reprendre le schéma donc les remarques , modifs et corrections qui vous semble nécéssaires sont les biens venues.

je réserve un des 2 liens spi du pic pour la liason vers le fpga, d'après la doc de microchip il fonctionne jusqu'a 25Mb/s, au dela microchip reste évasif (theorique = 40 Mb/s)

Ok pour les lignes SPI entre le FPGA et le PIC (une liaison devrait suffire d'ailleurs)

pour le bus externe je vais intercaler de 74lvc 245 si ca te convient Jeff ?

dans l'absolu c ok pour les 74lvc245. ceci dit je n'ai pas étudié le port externe (bus de combien de bits ? signaux de contrôles, etc)

j'ai des oscillateurs 40mhz (5 volts) sous le coude >> en sortie oscillations 2.5 v crètes , cela peut_il convenir pour le fpga ?

Pour l'oscillateur a 5V, je le sens pas trop : le fpga risque de voir une horloge avec un rapport cyclique != de 50% -> Problèmes de PLL en vues !
De plus il ne faut pas dépasser les 3.3V sur Cyclone III!. En effet je crois que la tension io idéal pour ce FPGA est de 2.5V, il est juste tolérant pour le 3.3V.
Tu peux pas faire dériver une horloge du PIC ?

>d'après les doc altera une seul clock peut étre distribuée sur tous les secteurs du fpga (cyclone 3 only) et servir a en générer d'autre horloge dailleur, (la dessus j'ai besoin de vos avis)

oui ça c ok, c une nouveauté du Cyclone III.

une autre solution, il me reste une centaine de quartz 20 mhz low profile (je dis bien quartz) peut ont les utiliser sur le fpga ? (entrées differentiell clock)

Alors là je dirais non (j'ai jamais vu faire ça), mais quelques recherches à ce nouveau la pourraient clarifier la chose. En tout cas ce n'est pas par l'entrée différentiel (il faut un inverseur avec un facteur d'amplification >=1 pour que l'oscillation puisse démarrer).

ok je vois pour un oscillateur:

soit on derive le clock out du pic (oscillateur en 3.3v en clock in du pic) soit on mets un 2eme oscillateur en 2.5v ?

les pll du cyclone demarrent à partir de 5 mhz, la clock ideal pour le pic est 8 mhz (lui aussi est equipé d'un pll avec coef x).

Ok pour la dérivation de l'horloge du pic.
Pour l'oscillateur il faut qu'il soit en accord avec l'alimentation io associée (donc 3.3V)

oui en effet j'ai fait un rapide tour d'horizon sur ce qui ce faisait en oscillateur.

en 2.5v je n'en ai pas trouvé...

donc oscillateur 8 mhz en 3.3v.

je vais verifier dans les datasheets si cette fréquence de départ permet d'exploiter le fpga au max (~402.5mhz pour cyclone III C8)

donc soit sortie du pic en clock-out ou direct sortie de l'oscillateur (horloge commune avec le pic)

si je me rappel bien le clock-out est dephasé par rapport au clock-in (pic), ca présente peut etre un intérèt... ?

pour le bus externe pour l'instant j'ai mis le bus dtata en 16 bits plus 36 bits au travers les 4 74lvc245 avec 8 bits suplementaire de gestion de ces derniers (cs/inout)
je finis de corriger le shéma coté liaison pic et après on verra plus en détails le bus externe.

sundance (./731) :
je vais vérifier dans les datasheets si cette fréquence de départ permet d'exploiter le fpga au max (~402.5mhz pour cyclone III C8)

de toute façon t'arriveras jamais à l'utiliser à cette fréquence
(rien que l'utilisation d'un bloque de ram ferra chuter la fréquence max à 238MHz)

si je me rappel bien le clock-out est déphase par rapport au clock-in (pic), ca présente peut être un intérêt... ?

Les plls du fpga permettent de régler la phase de chacune de leur sorties

[edit]
D'ailleurs je pense à ça, il y aura suffisamment de place dans le pic pour stocker le programme du fpga + le siens ?

ok donc en gros 238 mhz ,ok pour la phase, le plus sage est peut etre de ce mettre en sortie de l'oscillateur car les sorties du pic ......

en effet le soft du fpga ne tiendra peut etre pas dans le pic, c'est pour ca qu'il doit avoir absolument accès a la sdcard.

de cette facon le pic pourra ce mettre a jour et charger le fpga (passive serial).

a oui au fait, faut aussi penser au comportement de la carte tant que le FPGA n'est pas programmé : les cyclones mettent toutes les IO en tristate tant qu'il n'est pas en mode user (programme chargé et opérationnel).

Concernant la SDcard ça c'est déjà réfléchi, on a eu quelques échanges de mail a ce sujet.

Et effectivement il faudra penser a mettre les bonne pull-up/down sur les contrôles des buffer.

le schéma à jour (mais pas fini!)


Fichier joint : ultimate.pdf

wow O_o

j'ai hate de voir tout ça routé...

M'en parle pas ;-). D'ailleurs il faudra peut être réattribuer les io du fpga pour se faciliter la vie.

ok pour les reattributions des i/o, dis moi ce que tu préferres Jeff , que je modifie le schéma.
(les sources du schéma sont sur le server /download)

en ce moment je regarde les alimentations (regulateur etc)

on commence a en voir la fin (du schéma)

pour le routage les idées d'implantes sont les bienvenues.....

Salut sundance, seras-tu de l'AC 2009 ?

euh c'est quand l'ac 2009 ?

topics/118377-date-ac-2009

arg loupé pour moi je ne serais pas présent a l'ac2009...

sundance (./739) :
ok pour les reattributions des i/o, dis moi ce que tu préferres Jeff , que je modifie le schéma.
(les sources du schéma sont sur le server /download)

en ce moment je regarde les alimentations (regulateur etc)

on commence a en voir la fin (du schéma)

pour le routage les idées d'implantes sont les bienvenues.....

Non en fait l'idée c'est que si lors du routage tu vois que les pistes se croisent trop, tu démêles le truc coté schéma. C'est au moment du routage que cela se fait.

oui en effet c'est que j'ai l'habitude de faire.

les bonnes nouvelles : je termine la partie alimentation, j'ai lancé les commandes de composants ca arrive dans les prochaines semaines...

pour les alims donc on part d'un bloc alim 12v 1.6A

puis regulateur a découpage 5v 3A (lm2596s)

sur ce 5v 2 départs 1er 2.5 v 150ma pour les pll (mic 5255 2.5 ca devrait suffire)

2eme 3.3v 1.5A (LM1086IT un peu de marge en courant)


et enfin a partir du 3.3 v le 1.2v 1.5A (ncp565 un peu large je pense)

reste quelques pinoches a relier sur le pic aussi.

Bon, bad news de mon coté : La Dreamcast qu'on m'a fait parvenir par la poste s'est volatilisée en chemin (Considérée comme livrée par la poste, avec une fausse "signature").

Jeff_HxC2001 (./746) :
Bon, bad news de mon coté : La Dreamcast qu'on m'a fait parvenir par la poste s'est volatilisée en chemin (Considérée comme livrée par la poste, avec une fausse "signature").

Si tu es en bon terme avec tes voisins, tu peux leurs demander si ils ne l'ont pas reçu à ta place.
Si tu reçois parfois du courrier adressé à une autre personne, il est possible que lui reçoive parfois du courrier qui t'était adressé.

Sinon, lance une enquête à la poste.
Soit le colis a été envoyés en colissimo (simple) (remise sans signature) et tu peux être remboursé de 23 euros par kilo
Soit le colis a été envoyée en colissimo recommandé (remise contre signature), et ça semble être le cas si tu parles de "fausse signature" et là, il y aura enquête et si fausse signature avérée, alors tu seras remboursé en fonction du taux de recommandation (R1:50€ / R2:200€ / R3:400€ / R4:600€ / R5:800€)

Surtout ne lache pas l'affaire.
Mais autant te prévenir de suite, ça peut prendre 6 mois à 1 an...

sundance (./745) :
les bonnes nouvelles : je termine la partie alimentation, j'ai lancé les commandes de composants ca arrive dans les prochaines semaines...

Pour les fpga tu te fournis où et à quel prix (si c'est pas indiscret) ?

Concernant la DreamCast, j'ai lancé l'enquète lundi. Je ne savais pas que cela pouvais prendre aussi longtemps ( 6 mois à 1 an ).
Mais ce qui me dégoute le plus, c'est de ne plus avoir de DC à fournir. Vivement que la saison des brocantes recommence.


Tiki