Simulazione Nios II

[fabiolino88]

Salve a tutti!
Sono nuovo del blog e spero che mi possiate aiutare con un problema che ho sulla simulazione del Nios II.
Sto svolgendo un lavoro e finora avevo utilizzato l'ambiente di sviluppo della Xilinx (facendo diverse cose con Microblaze, periferiche custom, bus FSL e GPIO e simulando il tutto sia lanciando Isim da ISE sia da EDK) e, ora, ho riscontrato alcuni problemi nella simulazione del Nios II con Modelsim. Vorrei sapere come simulare un sistema che comprende sia il Nios II sia alcune periferiche custom che ho creato io in VHDL nell'ambiente Quartus II (per il momento sono riuscito a simulare il Nios II da solo lanciando Modelsim da Eclipse).

[deluca]

Modelsim... non è che hai molte scelte.

Esistono altre vie, ma molto + complesse e costose.

Modelsim mi sembra nel tuo caso la via + appropriata.

[fabiolino88]

Ciao,
forse mi sono espresso male, come simulatore sto utilizzando Modelsim! Volevo sapere se è possibile simulare un intero sistema (che comprende anche il Nios II) lanciando Modelsim separatamente e non avviandolo da Eclipse. Ho creato un sistema con Nios II e periferiche custom in Quartus II ma, poi, quando lancio Modelsim separatamente e creo un progetto caricando i files VHDL del sistema e del test-bench (che ho scritto io) non ottengo risultati (la simulazione si avvia ma l'uscita del PIO mi rimane indefinita). Io credo che il software applicativo che ho scritto in C++ con Eclipse non venga caricato in memoria. Come posso far "capire" a Modelsim che il programma (il file .elf o .hex) che ho scritto deve andare nella memoria RAM del processore?

[legacy]

Per un sistema molto piu' semplice mi sono scritto io un tool in C che converte un file hex contenente il firmware del SoftCore (macinino ad 8 bit) in una mappa di memoria verilog, in questo modo viene descritto il contenuto della ram e al reset il softCore e' felice e saluta in seriale con "hAllo".

Ma tra parentesi, sui sistemi Xilinx come fai ? Io avevo lo stesso problema ed ho risolto allo stesso modo, generando un file verilog o vhdl che descrive il contenuto della ram a partire da un file hex sputato fuori dall'asm. Ho usato picoBlaze, dovevo quasi per forza giocare con l'asm, i compilatori C per quella architettura arrancano.

Per la Xilinx sia se lanci Isim da EDK sia da Project Navigator (una volta creato il tuo sistema programmabile con Microblaze in EDK e il suo sw applicativo con SDK), l'ambiente di sviluppo ti permette di caricarti il file .elf risultato della compilazione che va a costituire il contenuto della memoria BRAM. Fatto ciò, lanci Isim e simuli come un qualsiasi circuito digitale (naturalmente Microblaze eseguirà il programma che gli hai messo in memoria!).

Mai usato EDK, ho sempre costruito io le BRAM contents. Se parti da un elf e' peggio, hai le sections ed i symbols da gestire, secondo me ti conviene chiedere alla toolchain di sfornare un hex per poi convertirlo in bin ad esempio con un tool hex-to-bin tool (formato intel), infine farti un programmino o uno script (p.e. python) per riversare il bin nel BRAM stuffing code.

[Leonardo]

Ciao,

Spero che hai già risolto, se comunque dovesse ancora servire e per memoria futura ecco un interessante AN che sembra indirizzare il tuo problema: http://www.altera.com/support/examples/nios2/exm-simulating-niosii.html

[legacy]

tra parentesi e' sempre un piace notare che uno chiede, l'altro risponde, e poi non si sa mai come va a finire

cosa non mi piace di Altera ? E' un mondo chiuso, fatto dei loro tools, delle loro cose, un po' come Xilinx, e ognuno dice la sua, quindi alla fine un AN come quello e' spendibile solo su Altera, vai altrove ? Ti si ripresenta il problema, quello che avevo scritto qui sopra e' un pelo + universale.

[Leonardo]

Purtroppo devo constatare che è un comportamento diffuso (perlomeno in passato) da parte di chi pone i quesiti. A chi risponde piace sapere come va a finire..

Forse con gli hard-core ARM la situazione migliorerà un pochino.. rendendo più semplice (ma non indolore) il passaggio da un produttore all'altro, avendo una minimo comune denominatore più ampio. Non ho però elementi a sufficienza per confermare questa ipotesi.

In alternativa non rimane che scriversi qualcosa di fatto in casa come ha fatto il gruppo di Giovanni col SuperAVRcore

[legacy]

secondo me bastano dei tools ed un minimo di malizia, io p.e. mi sono fatto tutta la toolchain ed i tools del caso, come dicevo nel post qui sopra, funziona tutto pero' se c'e' una cosa che mi irrita e' che nello scenario comune tutti quanti re-inventano la ruota: Altera a suo modo, Xilinx a suo modo, gli hobbisti a loro modo, e gli accademici a loro modo. Io mi ci metto a piene mani nel mezzo, ovvero anche io, a modo mio, that's my way, ed e' proprio questo che non va bene: basterebbe mettersi tutti quanti d'accordo per non dover ogni santa volta impiegare mesi del proprio tempo a riscrivere l'ennesimo tool.

that's life