Hallo,
ich würde gerne mal eine kleine Umfrage starten, ob von euch schon
jemand (viele, alle?) Qsys im Einsatz hat.
Ich habe es bisher jedenfalls (v11.1) nicht geschafft, in akzeptabler
Zeit ein ganz simples Qsys-System mit Nios, interem RAM und JTAG selbst
zu bauen.
Da hab ich doch einfach mal ein altes System konvertiert. Nur scheint es
da so zu sein, dass Qsys nicht automatisch eine Datei anlegt, in der die
ganzen Sourcen gesammelt werden. SOPC Builder packt das einfach in ein
.qip file und gut is.
Die BSP IDE kenn nicht mal nen Crosscompiler für Nios auf meinem System,
muss ich dem das von Hand beibringen?
Entweder mache ich da grundlegend was falsch oder Qsys ist schlicht
nicht fertig?? Wie sind denn eure Erfahrungen?
Ich beschäftige mich nur hobbymässig mit Quartus,
um auch bei anderen Anbietern auf dem Laufenden zu
bleiben, bin also kein Quartus-Profi.
Mit 12.0 habe ich die Gelegenheit genutzt, mich
in QSys einzuarbeiten (grobe Kenntnisse in SOPC
machen den Einstieg sehr einfach). Nach ca. einer
Woche (6* 2-3Stunden) kriegt man schon einfache
NiosII-Systeme hin, DDR und andere IPs sind auch
kein Problem (geht sogar einfacher als bei Xilinx,
gutes Board vorausgesetzt).
Was ich bei Altera gegenüber Xilinx vermisse sind
kurzgehaltene Tutorials für einen Schnelleinstieg
(in QSys bzw. EDK, VHDL-Kenntnisse vorausgesetzt).
Bei Xilinx liest man ein solches an einem Abend
durch und kriegt auch schon ein einfachstes Beispiel
hin. Bei Altera schaffe ich das nicht.
Hallo Michael,
schönes Tutorial! Immerhin habe ich jetzt schon ein leicht abgewandeltes
Qsys-System nach deinem Tutorial aufgebaut, das sogar fehlerfrei
compiliert.
Gleich mal ne Frage: Braucht man bei Qsys keinen JTAG-UART, um Daten per
printf auf die Konsole schicken zu können? Ich kann mich vage daran
erinnern, dass es jetzt ein supertolles neues Konzept gibt; für den
Anfang würde mir aber eine simple Konsole wie in der NIOS IDE reichen.
Leider bietet mein SBT die Option "File > New > Nios II Board Support
Package" gar nicht erst an. Jetzt installier ich halt den ganzen Krempel
mal neu und hoffe, dass ich morgen die vermisste Option habe :-)
Hallo Sigi,
ich schreibe mir eigentlich recht gute SOPC Builder Kenntnisse zu.
Vielleicht macht es das ganze dann wieder etwas komplizierter? Deine
Einschätzung hat mich jedenfalls bestärkt, mich endlich mal hinzusetzen
und Qsys zu lernen. Führt ja eh kein Weg dran vorbei.
Aus dem Xilinx-Tools bin ich schon seit Jahren raus, allerdings fällt
mir auch auf, dass Xilinx deutlich mehr und auch bessere Whitepapers zu
ihren FPGAs hat (die teilweise auch auf Altera übertragbar sind).
Vielen Dank schonmal euch beiden von (einem hier anonymen, aber trotzdem
freundlichen) ich ;-)
Na toll, jetzt habe ich alles neu installiert, und die SBT lassen sich
immer noch nicht korrekt benutzen. Es sieht wohl so aus dass die
Nios-Perspektive in Eclipse bei mir komplett fehlt. Daher hat mir wohl
auch immer der letzte und entscheidende Schritt gefehlt, um Qsys
vernünftig benutzen zu können. Mal sehen was Altera dazu sagt.
@ich:
Für einfachste Beispiele verzichte ich ausser
beim Debuggen komplett auf SBT, setze stattdessen
alles per Hand zusammen => kaum Treiberoverhead,
Programm+Data passen komplett in eine handvoll
BlockRAMs.
Das ZIP-File soll nur als Beispiel dienen. Es
enthält alle notwendigen Scripts zum Starten und
Runterladen. Das SOF-File fehlt, die Scripts
mussen evtl. an deine Dir-Struct angepasst werden.
Schau's dir einfach mal an.
Hallo "ich",
ich habe den JTAG-UART in dem Beispiel nicht benutzt, da meine HW
einen richtigen UART hatte. Ein Beispiel mit JTAG-UART gibt es
beim dem SOPC Tutorial hier:
http://www.emb4fun.de/fpga/niosii1/index.html
Viele Grüße,
Michael
Hallo nochmal,
dank Michaels Tutorial (und zahlreichen Neuinstallationen von Quartus)
habe ich jetzt tatsächlich ein laufendes System hingekriegt. Vielen
Dank!
Jetzt habe ich aber doch noch eine kleine Unstimmigkeit die ich gerne
sauber hinkriegen würde:
Mein Qsys hat ein Modul (clk_0) das u.A. für den Reset zuständig ist.
Das habe ich über den Conduit "reset" exportiert, siehe Bild.
In der Instantierung heisst dann das entsprechende Signal reset_reset_n:
Gesagt, getan, also habe ich mal einen negativen reset angeschlossen.
Dabei stellte sich raus, dass das Signal zwar reset_n heisst, das System
aber einen positiven Reset erwartet.
Mag jetzt kleinlich klingen, aber mit solch unsauberen
I/O-beschreibungen schiesse ich mich irgenwann selber ins Knie. Michaels
Beispiel zeigt genau das gleiche Verhalten.
Hat da jemand ne vernünftige Lösung dafür?
Hallo "ich",
>Michaels Beispiel zeigt genau das gleiche Verhalten.
Das mag ich jetzt nicht glauben, da ich das "locked" Signal
der PLL als Reset für die CPU verwende. Schau hier bitte noch mal
genauer in mein Beispiel:
http://www.emb4fun.de/download/fpga/nutos/de0_nano_fpga_100_final_20120815.zip
Wenn hier ein positives Signal ein Reset auslösen würde, dann
würde meine CPU überhaupt nicht laufen wenn die PLL im Lock Zustand ist.
Viele Grüße,
Michael
Sorry, da hab ich wohl falsch hingeschaut.
Fakt ist jedoch, in mein System kommt ein negativer Reset rein. Das habe
ich gerade nochmal mit Signaltap verifiziert (reset_n). Diesen muss ich
dann invertiert an reset_reset_n der CPU anschliessen, damit sie läuft.
1
...
2
.reset_reset_n(!reset_n),
3
...
Ich schliesse hier also einen positiven Reset an das als negativ
bezeichnete Signal an. Nur wenn ich das so mache, läuft das System.
Besteht da überhaupt eine Möglichkeit, auf die gesamten exportierten
Namen einfluss zu nehmen?
Hallo "ich",
wo kommt denn der delay_reset_block_b0 her?
Aber egal, kannst Du evt. mal die PLL so umbauen das
sie auch ein locked Signal ausgibt, und dann diese
Signal als Reset benutzen? Soll nur mal ein Test sein.
Ich habe gerade mal in den delay_reset_block geschaut.
Darf man so etwas:
always @(posedge clock_in or negedge reset_n)
überhaupt machen? Auf eine positive und negative Flanke
abfragen? Ich dachte das FPGAs nur positive Flanke können?
Wie gesagt versuche es mal mit dem locked Signal um den
Fehler einzukreisen. Denn ich glaube immer noch das auch
Deine CPU bei einem negativen Signal im Reset bleibt.
Viele Grüße,
Michael
Das FF arbeitet ja auf der positiven Flanke des clocks und der
asynchrone Reset wird so formuliert, hier eben ein negativer reset. Das
klappt schon, soll mal nicht das Problem sein :-)
Meine CPU bleibt mit einem negativen Signal im Reset. Daher muss ich den
negativen Reset erst invertieren und dann dem Signal "reset_reset_n"
zuweisen, damit das System läuft. Mein eigentliches Problem ist, dass
das Signal von Qsys falsch benannt wird und ich keine Möglichkeit finde,
das richtig zu nennen. Das ist jetzt nicht extrem schlimm, aber ich seh
mich halt schon in zukunft 3 tage dransitzen und fluchen warum nix geht,
weil ich nen falschen Reset angeschlossen habe. Dafür sitz ich jetzt
schon fast 3 Tage dran :-)
Gruss,
ich ;-)
Hallo "ich",
jetzt versteh ich Dich nicht mehr. Oben schreibst Du noch:
>Gesagt, getan, also habe ich mal einen negativen reset angeschlossen.>Dabei stellte sich raus, dass das Signal zwar reset_n heisst, das System>aber einen positiven Reset erwartet.
Und jetzt hast Du geschrieben:
>Meine CPU bleibt mit einem negativen Signal im Reset.
Das wäre ja auch richtig, da am Toplevel der CPU (cpu u0) das Signal
wie folgt heißt: reset_reset_n
???
Viele Grüße,
Michael
Da schreib ich doch zwei mal das gleiche?
Das signal heisst reset_n, und wenn ich einen negativen Reset
anschliesse gehts nicht. Nur wenn ich an reset_n einen positiven Reset
anschliesse, dann gehts.
Hallo "ich",
>Da schreib ich doch zwei mal das gleiche?
Nein, Du schreibst beim zweiten mal:
"Meine CPU bleibt mit einem negativen Signal im Reset."
Für ein Signal mit dem Namen "reset_n" ist das doch OK, oder?
Gruß,
Michael
Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.
Wichtige Regeln - erst lesen, dann posten!
Groß- und Kleinschreibung verwenden
Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang