Hallo, µc.net! Im Rahmen eines (privaten) Studienprojekts möchte ich ein NiosII System basteln, das Videos von einer SD-Card lädt, dekomprimiert und über A/V Schnittstellen ausgibt - also einen Embedded Videoplayer, entwickelt auf einem Altera/Terasic DE0 Board (Cyclone III). Da mir die Altera Toolchain (v.a. mit dem QSYS SOPC Builder) einige große Steine in den Weg legt, habe ich mich nun dazu entschieden, den Softcore manuell (in VHDL) zu instanzieren, gemeinsam mit meinen selbst geschriebenen Peripherals (LEDs, 7Segmente, SdCard Controller, Onchip-Speicher usw). Bevor ich den weiten Weg auf mich nehme, wären einige Details nützlich. Hat jemand damit schon Erfahrungen gemacht? Was mich aktuell beschäftigt: Am liebsten würde ich die NiosII Software Toolchain weiterverwenden, da sie für meine Ansprüche recht gut funktioniert. Mir ist klar, dass ich ohne den SOPC Builder ein eigenes BSP für das System erstellen muss. Aber ich könnte mir gut vorstellen, dass es mehr als nur den "nackten" Prozessor mit Programmspeicher benötigt, um ihn über die Toolchain programmieren zu können. Mir ist aufgefallen, dass die Portliste eines im SOPC Builder erstellten NiosII-Systems KEINE eigenen HDL-Ports für die Kommunikation mit dem Windows-Treiber hat. Ich konnte bereits herausfinden, dass das scheinbar über die "Programming Pins" passiert, mit denen der Interne Speicher "direkt" beschrieben werden kann. Gibt es hier jemanden, der damit bereits experimiert hat und mir auf die Sprünge helfen kann? Danke fürs Lesen ;) Liebe Grüße, Stefan
Du wollst mit dem NIOS2 ohne Qsys/SOPC-Builder arbeiten?! Vergiss das mal lieber ganz schnell wieder. Da steckt eine Menge mehr dahinter, als einfach nur ein VHDL-Modul zu instantiieren. Was hakt denn bei dir so, dass Qsys streikt? Ich hatte da noch nie Probleme mit. Gruß Marius
Danke erstmal für die schnelle Antwort! :) Nunja, die Liste ist lang... Leider schränkt einen Altera mit den IP-Modulen bekanntlich recht ein. Zum Einen stört mich das bei der Generierung des Systems. Während der Entwicklung meiner Custom Components in VHDL ändert sich natürlich ständig was am VHDL-Code. Also muss für jeden Simulationszyklus in der Entwicklungsphase folgendes abgearbeitet werden: 1. VHDL schreiben/ändern (bleibt mir natürlich sonst auch nicht aus :D) 2. Neu-Compilieren der Custom Component (geht nur im Custom Component Editor von QSYS!) 3. Neues Hinzufügen der Custom Component und Verbinden über die GUI 4. Generierung des Systems (dauert oft 1-2 Minuten, im Fehlerfall mehrmals nötig!) 5. Compilieren und Simulieren in ModelSim (das von QSYS erstellte .tcl-Script ist dabei auch fehlerhaft...) Und das für jede kleine Änderung! Meine Idee war ja eigentlich, dass ich nur noch die Schritte 1. und 5. machen muss, denn der SOPC Builder ist da ein gewaltiger Zeitfresser... Außerdem ist es bei mir später oft vorgekommen, dass ich den gesamten Quartus-Workspace bereinigen musste, damit nicht ständig irgendwelche dubiosen Compiler-Errors auftreten. Weiters: Die QSYS-GUI mit ihrer abstrakten Darstellung. Als Hardware-Entwickler möchte ich gerne etwas genauer reinschauen, vor allem, wenn ich ein Slave-Interface designen muss, das zum Softcore usw. kompatibel sein muss. Das wäre aber weiter nicht schlimm... Und dann waren da noch die Komplikationen von VHDL vs. NiosII... Bei manchen Konfigurationen können keine Testbench/Simulationsmodelle erstellt werden, weder Verilog noch VHDL. Was dann später noch dazukommt ist, dass das gesamte BSP für die Software neu generiert werden muss, wenn im QSYS was geändert wurde. Den NiosII habe ich übrigens gewählt, weil er der dynamischste und performanteste Softcore für meine Anwendung ist, den ich finden konnte. Gibts vielleicht noch andere (am besten Open-Source) Prozessoren, die da dran kommen könnten? Lg, Stefan
Meiner Meinung nach musst du nur in Qsys rein, wenn sich was grundlegendes in deinem IP-Core geändert hat. Solange sich das grundlegende Interface zum NIOS2 nicht ändert, brauchst du auch nix Neu-Kompilieren. Eine Alternative fürs Debugging wäre, dass du deine Komponente erstmal ohne NIOS simulierst. Einen Avalon-Master ist ja fürs Testbench recht schnell fertig gemacht. Gruß Marius
Hm ok, ich bin immer noch etwas von dem Flow verwirrt, und die Vorgehensweise sagt mir in der Grundkonzept-phase, in der noch viel am Gesamtsystem geschraubt wird, nicht so zu. Ich möchte es trotzdem hinkriegen, den Prozessor manuell zu integrieren, denn dann tue ich mir später bei etwaiger Fehleranalyse bestimmt leichter. Und mit einem Avalon-Master-Dummy ist das ganze meiner Meinung nach auch etwas schwammig, da der Prozessor dahinter doch noch einiges ausmacht, wenn man eine aufwendigere Kommunikation (zB. SD Card Controller) betrachtet. Außerdem möchte ich beim Simulieren jedes Custom Peripherals 100%ig sicher sein können, dass alles perfekt hinhaut, ansonsten wird die spätere Fehlersuche mit Sicherheit zur Hölle. Danke trotzdem! Ich werde Ergebnisse, sofern sie nicht allzu lange auf sich warten lassen, hier nachtragen... vielleicht kann jemand was draus machen :) Lg Stefan
Für doch den benötigten Teil des Busses über Conduits aus Qsys heraus. Verbinde dann Deine Komponente ausserhalb vom Qsys mit dem Bus.
Angehängte Dateien:
-
qsys_nios2.jpg
240 KB
Hallo Uff, Gute Idee! Ich hab mal nen Screenshot mit hochgeladen - meinst du das so in etwa? Ich hab noch keine Vorstellung davon, wie ich die Fehler wegbekomme um das System generieren zu können. Exportieren UND verbinden hab ich nicht hinbekommen... hast du das ganze schonmal gemacht? Lg Stefan
Angehängte Dateien:
-
2012-12-15_115208.png
9,7 KB -
2012-12-15_115451.png
34 KB
Eine kleine Komponente, die den Bus nach aussen führt in Qsys einbinden. Den Rest machste dann in Quartus.
Genial :) Das sieht recht vielversprechend aus, muss ich gleich ausprobieren... aber ich denke, so wirds hinhaun! Dankesehr :) Lg Stefan
Ich denke eher an eine kombinatorische Lösung bzw. reine "Verkabelung", dann krieg ich mit den Timings hoffentlich keine Probleme :D
Aber schwieriger zu konfigurieren ;) Und bei reinem Port-Mapping ohne Logik dürfen keine Verzögerungen anfallen, außer durch z.B. Bus-Komponenten, die durch QSYS generiert werden. Das wäre dann aber bei einem reinen QSYS-Design ebenso...
Also der Schuss ist ziemlich nach hinten losgegangen... leider passt das Verhalten in der Simulation überhaupt nicht mit dem Verhalten am Board zusammen. Der Prozessor scheint einiges anders zu machen, für mich ziemlich zufällig (bei jedem Reset durch Taster drücken laufen über den Datenbus "Random"-Werte, zumindest kann ich mir nichts davon erklären)... Werde jetzt den Plasma-Core ( http://opencores.org/project,plasma,overview ) testen, vielleicht auch den Leon3 ( http://www.gaisler.com/doc/leon3_product_sheet.pdf ) Projekt NiosII ist also gestorben :D Danke trotzdem für die Hilfe. LG, Stefan
Hallo, ich habe Deine Postings nur kurz überflogen, doch ich denke, Du hast einfach was durcheinander gebracht. Auf QSYS zu verzichten ist keine gute Idee! Und man muss nicht gleich alles neu generieren, wenn man eine kleine Änderung gemacht hat! Wenn erstmal AVALON-Interface steht und funktioniert ist es sehr einfach, die Komponenten zu erweitern und hinzuzufügen. Auch die Simulation ist straight-forward (mit dem NIOS+Speicher+Komponenten). Dein Vorhaben ist einfach zu groß. An Deiner Stelle würde ich erst mit NIOS anfangen und dann vielleicht eine LED blinken lassen (als eigene Komponente und die Ansteuerung aus dem NIOS heraus). Wenn Du das mal gemacht hast und es wirklich läuft und das auch in der Simulation rauskommt, kannst Du dann Dich weiter und weiter vortasten. Hier sind immer kompetente Leute unterwegs, sodaß Du immer Hilfe bekommst. Deine Frage muss nur wohlformuliert sein und kurz genug, dass man nicht den Hintergrund zu wissen braucht! :-) Kest
Kest schrieb: > Und man muss nicht gleich > alles neu generieren, wenn man eine kleine Änderung gemacht hat! Stuss. Natürlich muss man das System neu erzeugen, sobald eine Änderung im QSYS stattgefunden hat. Und natürlich kannst Du den Avalon-Bus nach aussen führen, wie mein Beispiel zeigt. Auch könntest Du mit so einem System booten, wenn der Resetvektor und Deine Adr-Dekodierung passt.
Uff schrieb: > Stuss. Natürlich muss man das System neu erzeugen, sobald eine Änderung > im QSYS stattgefunden hat. Und natürlich kannst Du den Avalon-Bus nach Ich meinte eine Änderung in einer VHDL-Datei. Wenn man da was ändert (auch wenn die Datei zu einer Komponente von QSYS gehört), muss man QSYS-System NICHT neu generieren. Ja, Avalon Bus kann man nach Außen führen, doch wieso? Dafür ist doch QSYS da, dass man grafisch alles verlinkt? Ich möchte mal denjenigen sehen, der ohne SOPC/QSYS Nios mit einem Speicher oder ähnoichen instantiiert... Na dann viel Spaß Kest
Kest schrieb: > Ich möchte mal denjenigen > sehen, der ohne SOPC/QSYS Nios mit einem Speicher oder ähnoichen > instantiiert... Na dann viel Spaß Dann haben wir uns falsch verstanden. Hier gebe ich Dir natürlich uneingeschränkt recht. Kest schrieb: > Ja, Avalon Bus kann man nach Außen führen, doch wieso? Im Zuge einer Entwicklung habe ich den Bus nach aussen geführt, um nicht bei jedem neuen Signal mit QSYS ein neues System zu generieren. Das passierte ausserhalb von QSYS im Adressdecoder. Ausserdem lassen sich so deutlich schneller Änderungen einpflegen, weil das QSYS-System in einer Design Partition Platz findet und nicht immer wieder neu mit Quartus kompiliert werden muss.
Klar muss bei reinen 'architecture'-Änderungen meiner Custom Components QSYS nicht neu generiert werden... aber bei Änderungen an QSYS Komponenten (Speichergröße->Adressbusverbreiterung, Interruptangelegenheiten, Adressvektoren, Nios2-Konfiguration, Cachegrößen, ....) schon, denn diese Einstellungen verändern den Sourcecode, der von QSYS generiert wird. Und für jede neue Altera-Komponente, die ich instanziere, gilt dasselbe. Da wird das ganze schon anstrengend... Wenn die ganze Prozedur wenigstens schnell gehen würde, das wär schon was. Aber das Generieren dauert mitunter schon Minuten, und ab und zu (fragt mich nicht in welchen Situationen genau) werden noch Sub-Entities vom Nios2 generiert mit postfix _001.v oder _002.sv o.Ä., welche mir in der Simulation dann wieder fehlen und ich händisch im tcl-File ergänzen muss (welches übrigens total unvollständig generiert wird, daher kann ich QSYS das Script nach der händischen Ergänzung nicht gleich wieder überschreiben lassen). -> zum Kotzen!
Hab das ganze übrigens experimentell mit dem Xilinx MicroBlaze Controller in der Xilinx Design Suite ausprobiert, da kommt beim "Core Generator" (ca. äquivalent zu QSYS) nach Wahl eine VHDL- oder Verilog-Datei raus, mit einer Schnittstelle, die im Groben so aussieht (einige individuelle Ports kommen dann je nach Anwendungsfall dazu/weg): entity microblaze_mcs_v1_0 is port ( Clk : in STD_LOGIC := 'X'; Reset : in STD_LOGIC := 'X'; IO_Ready : in STD_LOGIC := 'X'; UART_Rx : in STD_LOGIC := 'X'; IO_Addr_Strobe : out STD_LOGIC; IO_Read_Strobe : out STD_LOGIC; IO_Write_Strobe : out STD_LOGIC; UART_Tx : out STD_LOGIC; IO_Read_Data : in STD_LOGIC_VECTOR ( 31 downto 0 ); GPI1 : in STD_LOGIC_VECTOR ( 31 downto 0 ); IO_Address : out STD_LOGIC_VECTOR ( 31 downto 0 ); IO_Byte_Enable : out STD_LOGIC_VECTOR ( 3 downto 0 ); IO_Write_Data : out STD_LOGIC_VECTOR ( 31 downto 0 ); GPO1 : out STD_LOGIC_VECTOR ( 31 downto 0 ) ); end microblaze_mcs_v1_0; und der Core muss nur neu generiert werden, wenn ich direkt dran was ändern will (Anzahl GPIOs, UART-Baudrate, Debuggin Optionen, Allg. Prozessoreinstellungen,...), ganz logisch, bei den ganzen Einstellungen ist das nur sinnvoll. Fazit: Der riesengroße und wichtigste Unterschied ist, dass in der Xilinx-Umgebung eine "klassische" Instanzierung im HDL-Code vorgenommen werden kann und auch muss (also auch nicht anders wie im ASIC-Design)! Altera zwingt mich quasi dazu, ein misch-masch aus deren verschlüsselten IP-Cores (die's nur in Verilog gibt) und meinen VHDL-Units zu basteln. Und für die Simulation braucht man lediglich (vermute ich jetzt zumindest) die (fertige, 'unveränderliche') Xilinx/MicroBlaze-lib zu kompilieren, und nicht 20 weitere custom files wie solche, die mir QSYS generiert. In meinen Augen also Xilinx 1, Altera 0... Werd mir für mein Projekt also demnächst ein kleines Spartan-6-Devboard oder dergleichen zulegen.
Stefan E. schrieb: > In meinen Augen also Xilinx 1, Altera 0... > Werd mir für mein Projekt also demnächst ein kleines Spartan-6-Devboard > oder dergleichen zulegen. Das würde ich so nicht unterschreiben. Der Microblaze/MCS ist die Antwort von Xilinx auf den kleinen kostenlosen Altera-NIOS. Der Microblaze/MCS ist nur eine abgespeckte Variante vom vollkonfigurierbaren Microblaze aus dem EDK. Wenn Du Dir im Microblaze-EDK ein komplettes System zusammengeklickt hast, und dort nur eine winzige Änderung machst (z.B. einen Port umbenennen), dann darfst Du aber sowas von warten, bis jeder einzelne IP-Core neu generiert wird, das mir die Lust auf Microblaze vergangen ist. Duke
Duke Scarring schrieb: > Der Microblaze/MCS ist nur eine abgespeckte Variante vom > vollkonfigurierbaren Microblaze aus dem EDK. Das wusste ich nicht - damit muss ich mich noch genauer beschäftigen... aber bis jetzt finde ich den Designflow um einiges komfortabler. Duke Scarring schrieb: > Wenn Du Dir im Microblaze-EDK ein komplettes System zusammengeklickt > hast, und dort nur eine winzige Änderung machst (z.B. einen Port > umbenennen), dann darfst Du aber sowas von warten, bis jeder einzelne > IP-Core neu generiert wird Mit dem EDK ("Xilinx Platform Studio" ist da gemeint, glaube ich) hab' ich mich noch nicht recht auseinandergesetzt, weil ich dachte, aus dem Core Generator kommt bereits die vollwertige CPU raus. Bezüglich dem "lange warten": Das musste ich bei Altera auch. Ich hoffe, dass Xilinx nicht so viele Bugs und Einschränkungen bzgl. HDLs, Simulationsflow usw. hat, denn die sind weit anstrengender als die Zeit, die draufgeht.
Stefan E. schrieb: > Ich hoffe, > dass Xilinx nicht so viele Bugs und Einschränkungen bzgl. HDLs, > Simulationsflow usw. hat, denn die sind weit anstrengender als die Zeit, > die draufgeht. Da muß ich Dich enttäuschen. Auch Xilinx kocht nur mit Wasser. Aber die Hoffnung stirbt ja bekanntlich zuletzt :-) Duke
rd > > Mit dem EDK ("Xilinx Platform Studio" ist da gemeint, glaube ich) hab' > ich mich noch nicht recht auseinandergesetzt, weil ich dachte, aus dem > Core Generator kommt bereits die vollwertige CPU raus. Reicht dir eine CPU oder willst du noch weiter features haben?
Duke Scarring schrieb: > Stefan E. schrieb: >> Ich hoffe, >> dass Xilinx nicht so viele Bugs und Einschränkungen bzgl. HDLs, >> Simulationsflow usw. hat, denn die sind weit anstrengender als die Zeit, >> die draufgeht. > Da muß ich Dich enttäuschen. Auch Xilinx kocht nur mit Wasser. > Aber die Hoffnung stirbt ja bekanntlich zuletzt :-) Wir haben doch Weihnachten, da darf man auch bezüglich Xilinx-Software hoffen! Ist aber schon ein arg frommer Wunsch, im Hinblick auf weniger Bugs und Arbeit von Altera ausgerechnet auf Xilinx umsatteln zu wollen. Hehehe... Zu dem Thema gab es hier im Forum mal einen interessanten Beitrag, der einen Vergleich von Xilinx und Altera zu genau diesen Aspekten (Zeitaufwand, Fehler, Probleme) anstellte und zu einem vernichtenden Urteil kam. Meine persönliche Wertung aus nahezu 10 Jahren Projektarbeit mit beiden Herstellern, fällt auch für Altera aus.
Also Altera QSYS und Xilinx Platform Studio (EDK) fällt für mich gleich uninteressant aus. Werd mir also eine OpenCores-CPU in VHDL suchen, die meinen Vorstellungen am besten entspricht... da kann man ja zur Not auch umschreiben/erweitern/optimieren wies einem passt, ohne sich mit irgendeiner individuellen und schon gar nicht grafischen Toolchain wie XPS oder QSYS herumärgern zu müssen. René: Vermutlich wird ein Prozessorkern nicht reichen, weil ich dann den Datendurchsatz nicht hinbekomme (MPEG dekodieren ist nicht so unaufwendig...). Also brauche ich wahrscheinlich einen Kern fürs Dekodieren, und den anderen für die Ansteuerung der Peripherals (SD Card usw.), aber das muss ich mir noch genauer überlegen. Erstmal möchte ich, dass ein Kern (stabil) läuft.
http://www.youtube.com/watch?v=Bq2U_JO1kMc&list=TL_hdw7M_MdPQ Hier wird das zusammengebaut. Leider ist da auch händisches Kopieren angesgt. See how a Vivado HLS design can be saved as pcore IP and learn how this IP can be easily incorporated into an embedded system using Xilinx Platform Studio. In addition, this video shows how software drivers are created for the IP and how these can be used to speed the software development in SDK, allowing systems to be built quickly. For More Vivado Tutorials please visit: www.xilinx.com/training/vivado
> René: Vermutlich wird ein Prozessorkern nicht reichen, weil ich dann den > Datendurchsatz nicht hinbekomme (MPEG dekodieren ist nicht so > unaufwendig...). Also brauche ich wahrscheinlich einen Kern fürs > Dekodieren, und den anderen für die Ansteuerung der Peripherals (SD Card > usw.), > aber das muss ich mir noch genauer überlegen. Erstmal möchte ich, dass > ein Kern (stabil) läuft. Von der Dekodiererei sehe ich nicht da Problem. Die Rechenleistung vom Mais ist nicht zu verachten. Die MIPS waren in den 90er die Hochleistungsrechner. Leider sind sie nicht mehr so popolär. Es lassen sich auch Teile, wie der Huffman decoder ind die IDCT in Hardware (VHDL) umsetzen. Das habe ich für eine JPEG encoder bereits getan. Viel wichtiger ist bei solchen Datenströmen ein Plan zu haben, wie der Datenstrom läuft.
An den Threadstarter: Ich denke deine ursprüngliche Idee dein Vorhaben mit Altera und Nios2 zu erledigen war sehr gut. QSYS ist meiner Meinung nach ein sehr mächtiges Tool und nimmt einem echt verdammt viel Arbeit ab. Man muss halt nur den richtigen Dreh rausbekommen, wie man am besten damit umgeht. Ich habe z.B. hier ein Design mit Nios2, SDRAM, TCP, selbst geschriebenen Custom Instructions und 5 Custom Components (davon auch ein Design aus OpenCores mit nem Wishbone-Wrapper). Am besten ist schrittweise vorzugehen, also zuerst Prozessor, RAM und JTAG-UART instanzieren. Wenn man dann sicher ist, dass alles funktioniert kommt die nächste Peripherie dazu. Bei einer Änderung in den Custom Components braucht man nur QSYS neu zu generieren und es werden die geänderten Source-Files neu eingelesen. D.h. die Komponente und deren Verbindung brauchst du (sofern am Interface nichts geändert wurde) gar nicht anfassen. Im NiosII SBT brauchst du das BSP auch nicht neu zu erstellen, sondern es gibt einen Befehl (nios2-bsp-update-settings, wenn ich mich nicht irre), der aus der von QSYS erzeugten SOPCINFO Datei das BSP aktualisiert. Das lässt sich recht komfortabel mit einem Skript lösen. Eine gesamte Systemsimulation muss man meiner Meinung auch nicht machen. Wenn man die mitgelieferten Altera-Cores verwendet, gehe ich stark davon aus, dass die auch funktionieren. Ansonsten hat man zum Debuggen immer noch die Möglichkeit mit conduits die Signale zu exportieren (hab ich bei Avalon-Streaming Interface eingesetzt). In der Subscriber Edition gibts dann einen LogicAnalyser direkt am JTAG-UART Port, der funktioniert grandios! Speziell für deine Video-Anwendung sehe ich dann auch noch die Altera Embedded Video IP Suite. Vielleicht hast du Glück und es gibt Time-limited Versionen davon, somit kostet dich das Ganze keinen Cent zur Entwicklung! mfg Johnsn
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.