bertocar ha scritto:Se e' il fw per un FPGA (che comunque va sintentizzato) lo si carica per test via jtag (circa 1 secondo).
quando si parla di fw (firmware) ci si riferisce solitamente a cio' che bootstrappa una CPU, nel caso cio' che bootstrappa il softcore 68K in fpga.
la fpga bootstrappa "bitstream", o da cavetto jtag o da sua boot rom seriale dedicata, volendo anche per altre vie (che dipendono da come configuri il bootstrap da fpga, da quale sorgente e in che modo, era il discorso dei jumper che ti facevo pagine fa) ma non e' il caso parlarne
il punto e' che seduti al PC al bitstream si arriva dopo 10 minuti di macchinata
se il fw e' inglobato nel bitstream (che descrive anche una rom), per ogni modifica i tempi sono questi, non si scappa.
bertocar ha scritto:Se invece e' un fw di servizio con del codice eseguibile
facciamola + semplice: da dove fa fetch al primo colpo di clock il softcore 68k ?
il tuo progetto e' un SoC "quasi" come il mio (il mio e' moooooolto + piccolo e semplice), nel mio caso in fpga ho sintetizzato
- cpu
- ram
- rom
- uart
- altro
si chiama SoC perche' e' un System on Chip, a rigore un SoC deve prendere dall'esterno solo il clock e non deve aver bisogno d'altro avendo tutte le risorse necessarie in fpga, altrimenti che SoC sarebbe ?
e infatti la mia schiscetta cpu ad 8 bit si faceva rispettare facendo bootstrap da rom sintetizzata in fpga (usando 2Kbyte di risorse bram) ed istanziata con il fw di sviluppo, cosa figherrima ma che significa anche che, essendo una definizione di portmap, il contenuto di quella rom e' definito da un file verilog, quindi significa che per cambiare 1 bit di quella rom io debba necessariamente ricompilare tutto il progetto e ricaricare tutto su fpga: il cavetto jtag ci mette 1 secondo a caricarlo in fpga, ma io al pc ci metto 10 minuti ad arrivare a quel bitstream
siccome mi ero rotto abbastanza le scatole, ho rotto un pezzo di definizione di SoC ed alla faccia di avere tutto on chip ho messo uno zoccolo esterno, cosi' ora la rom in fpga e' istanziata solo con un jump to 0xE000 a cui e' mappata rom esterna su zoccolo su cui sviluppo in scioltezza con eprom emulator alla velocita' della luce ed e' goduria operativa.
perche', esemplificando giusto per insaporire la questione
operativamente prima: io mi siedevo al pc, compilavo il fw scritto 60% in C e 40% in asm, linkavo tutto assieme, ottenevo il binario, trasformavo il binario in s19, invocavo l'istanziatore, questo trasformava s19 in istanza bram per b16 reversed bit (perche' cosi' vuole Xilinx per le bram della famiglia spartan 3), otteneva un file verilog che descriveva la rom istanziata con il mio firmware, e ... lanciavo ISE v10.1 per far sintetizzare un nuovo bitstream da caricare in fpga ... 10 minuti topo lo potevo finalmente caricare per saggiare le modifiche al fw
operativamente ora: io mi siedo al pc, compilo il fw, linko tutto assieme, ottengo il binario, apro la porta udp/ip verso l'eprom emulator, invio il file binario, e tempo meno di 1 secondo ho quell'immagine nella rom del target
una altra via che ho sperimentato era usare la seriale, avevo messo un monitor nella rom interna alla fpga, questo faceva bootstrap e si metteva in ascolto sulla acia0, io compilavo e tutto, alla fine mandavo il file s19 via seriale ... bello, semplice e pulito, ma l'immagine veniva copiata in area rom (la rom e' descritta come una ram) a partire da 0xf000, alla fine lo eseguivo con un jump to 0xf020, abbastanza comodo e tutto, ma l'accrocchio se la viaggiava @ 119200 bps contro 10Mbit/sec della ethernet dell'eprom emulator.
tu parli di usb ? per me e' fumoso, non mi e' chiaro il giro che fa il bootstrap della tua scheda, sopratutto le sdcard, cioe' MMC/SD, non sono SPI ? Che ruolo gioca esattamente la usb ? Chi gestisce fisicamente la usb ?
In ogni caso senza sapere nulla penso che nel mio piccolo non mi converrebbe mettermi a sviluppare qualcosa per usb perche' rispetto alla seriale beh ... se la complessita' della seriale gestita in polling e' ridicola ... la usb costa un usb/stack con accrocchi vari a seguire.