Hallo, dies ist mein erster Beitrag hier, ich lese hier aber schon einige Zeit immer mal wieder mit und habe schon eine Menge an guten Tips hier gefunden. Bevor ich mein Problem schildere möchte ich kurz erzählen wo ich fachlich aktuell stehe: Ich bin gerade am Ende des 5. Semesters im E-Technik Bachelorstudium. An meiner FH hat man sich entschieden, Vorlesungsübergreifend auf Altera FPGAs und VHDL zu setzen. Gelernt habe ich dabei in letzter Zeit folgendes: - Umgang mit Quartus 15 - Basics in VHDL - Implementierung von Alteras NIOSII Außerdem bin ich Vetraut mit allgemeinen Prozessor-Architektur Konzepten und habe etwas Erfahrung im arbeiten mit Texas Instruments Mikroprozessor-Entwicklungsboards. Diese habe ich Anfangs mit Energia programmiert, bin inzwischen auf den Code Composer umgestiegen. Ich habe aktuell Zugriff auf 2 FPGA Entwicklungsboards mit Cyclone 5 FPGAs. Nun stolperte ich vor kurzem über den openMSP430 Softcore und war begeistert von der Idee, schon entwickelten Code und eine bekannte Toolchain zusammen mit diesem Softcore nutzen zu können. Nach dem Lesen der Dokumentation, stellte ich mir das so vor, dass ich einen passend parametrisierten openMSP430 inkl. Multiplizierer, Timer und GPIO, ohne Speicher in eine Einzige VHDL Komponente wrappen könnte, die mir nach Außen hin Interfaces für die Clock, den Speicher, die GPIOs und den Peripheral Bus bietet. Dort möchte ich mir dann selbst Speicher aus dem MegaWizzard anbinden, mir Gedanken mache wie ich diese mit kompiliertem Code fülle und dann halt schauen was ich so drumherum für Anwendungen basteln kann. Als zweiten Schritt könnte ich mir vorstellen, den Versuch zu wagen, die Struktur im Inneren nachzuvollziehen und einzelne Funktionsblöcke in VHDL selbst zu neu schreiben. Bis hier hin alles schöne Ideen. Nur leider beherrsche ich kein Verilog. Nach dem betrachten des Verilog Codes, bin ich etwas desillusioniert, da ich die Struktur des Projektes einfach nicht durchblicke. Ich hatte mir nach dem Lesen der Doku in etwa solch eine Struktur vorgestellt und mir auch gedacht, diese ohne Verilog kenntnisse grob im Code nachvollziehen zu können: openMSP430 openMSP430_defines Frontend ... Execution Unit ALU Register File ... Serial Debug Interface UART ... Memory Backbone ... Watchdog ... usw. Kurz gefasst, ich hatte gehofft in openMSP430_defines.v den Prozessor laut Doku parametrisieren zu können und dann in meine VHDL oder auch Blockschaltbild Top Level Entity einfach den openMSP340.v einbinden zu können. Ich war davon Ausgegangen, dass die jeweils übergeordnete Ebene die darunter liegenden Verilog Komponenten einbindet. Mein "Problem" dabei ist: in openMSP430.v sind zwar eine Menge an Ports angegeben, aber es ist - für mich mit Null Verilog Kentnissen - nirgendwo zu erkennen, dass abgesehen von der openMSP430_defines.v irgendeine der Funktionseinheiten innerhalb des Prozessors eingebunden wird. Für mich sieht das wie eine leere Hülle ohne Innenleben aus. Und das bringt mich an den Punkt zu fragen: Sind das Unklarheiten, die mir jemand in ein bis zwei Sätzen beantworten kann, so dass ich mit einigen wenigen Hinweisen ein frisches Quartus Projekt mit einer funktionierenden grundsätzlich Prozessorstruktur anlegen kann und mich dann erst mal um das programmieren und erstellen von Peripherie kümmern kann? Oder sollte ich mich richtig intensiv in Verilog eingearbeitet habe, bevor ich den Core überhaupt nur benutzen kann? Ich hoffe natürlich auf ersteres und evtl. Tips, die mir auf die Sprünge helfen, aber wenn ihr zum Schluss kommt, dass das ne Hausnummer zu groß ist, freue ich mich auch das über ehrliche Antworten. Grüße Janos
Verlinke am besten mal den Code, damit man mal einen Blick darauf werfen kann. Für einen Anfänger in VHDL mit wenig praktischer Erfahrung in der Informatik ist es - denke ich, empfehlenswert ein Buch über Verilog zu lesen und durch zu arbeiten bevor er sich an Projekte macht. Mit VHDL hast Du jetzt ja schon mal eine Idee, worum es geht. Das hilft. Wenn auch nur relativ, da Du bisher ja auch wenig mit VHDL gemacht hast; resp. gemacht haben kannst. Mein Eindruck ist, dass es einige starke Ähnlichkeiten gibt (was ja ganz natürlich ist) aber auch einige wichtige Ausdrucksweisen in Verilog die dem VHDL-Kenner nur wenig bis gar nichts sagen. Da muss man einfach durch. Bisher habe ich Verilog-Code mit einiger VHDL-Erfahrung zumindest soweit verstehen können, dass ich grob wusste, was los ist und erkennen konnte was mir gar nichts bedeutet hat und das habe ich dann nachgeschlagen. So wird das bei Dir auch laufen. Viel Erfolg.
Janos B. schrieb: > Und das bringt mich an den Punkt zu fragen: Sind das Unklarheiten, die > mir jemand in ein bis zwei Sätzen beantworten kann, so dass ich mit > einigen wenigen Hinweisen ein frisches Quartus Projekt mit einer > funktionierenden grundsätzlich Prozessorstruktur anlegen kann und mich > dann erst mal um das programmieren und erstellen von Peripherie kümmern > kann? Oder sollte ich mich richtig intensiv in Verilog eingearbeitet > habe, bevor ich den Core überhaupt nur benutzen kann? Wenn's VHDL sein soll, hätte ich noch diesen (etwas anderen) Vorschlag: http://www.gaisler.com/index.php/downloads/leongrlib Ein Sparc V8 Prozessor in VHDL. Ich habe bislang nur sehr oberflächlich reingeschaut, aber was ich gesehen habe, hat mir gefallen.
Bevor sich hier jetzt jeder meldet, er kenne auch einen Softcore für FPGA, hier eine Übersicht, die auch ergänzt werden darf... https://www.mikrocontroller.net/articles/FPGA_Soft_Core Und um auf die Frage des TO einzugehen. Inzwischen dürften alle aktuellen Toolchains mixed-language-support haben. D.h. Du kannst die Verilog-Komponente als Black-Box betrachten und im VHDL einbinden. Wie das konkret geht findest Du in der Dokumentation zu Quartus. Duke
Auf opencores gibt es auch eine Implementierung der MSP430-ISA in VHDL: http://opencores.org/project,neo430
Janos B. schrieb: > irgendeine der Funktionseinheiten innerhalb des Prozessors eingebunden > wird Wie stellst du dir denn das Einbinden vor? In der openmsp430.v wird doch zum Beispiel omsp_clock_module, omsp_frontend usw. eingebunden. Du musst nur nicht, wie in VHDL, die Komponentendeklaration extra nochmal hinschreiben. Grundsätzlich musst du, falls du den Prozessor nur benutzen willst, nicht unbedingt Verilog beherrschen. Allerdings ist es manchmal ganz sinnvoll, gerade wenn man bei der Inbetriebnahme mal etwas tiefer schauen will, wo es evtl. klemmt. Die grundsätzlichen Syntaxunterschiede sind auch schnell erfasst, wenn man schon VHDL kennt. Wie schon gesagt könntest du ja ansonsten für den Anfang mit einer etwas einfacheren VHDL-CPU anfangen Duke Scarring schrieb: > Bevor sich hier jetzt jeder meldet, er kenne auch einen Softcore z.B. der ZPU.
Ich hatte vor einiger Zeit mal mit openMSP430 rumgespielt und diesen dazu in VHDL eingebunden. Kannst du unter https://github.com/speters/openmspde0 finden. Das "Projekt" hatte ich mal angefangen, bevor ich auf den Trichter kam, dass das A und O bei HDL die Testbenches sind. Blinkyblinkyhelloworld auf 'nem FPGA-Board sind zwar fein und motivierend, aber letztendlich muss man ganz klein anfangen, sonst wird das nix.
:
Bearbeitet durch User
Danke für die Antworten bis hier! Klaus schrieb: > Verlinke am besten mal den Code, damit man mal einen Blick darauf werfen > kann. Ich habe den Code hier her: https://gitlab.informatik.uni-bremen.de/goekce/omsp430/tree/bc991b821f2a45f51fdf9d876db0c304bfdd3091 Duke Scarring schrieb: > Du kannst die > Verilog-Komponente als Black-Box betrachten und im VHDL einbinden. Wie > das konkret geht findest Du in der Dokumentation zu Quartus. Dass das funktioniert wusste ich. Und ehrlich gesagt hatte ich es mir auch so vorgestellt, dass ich quasi die Blackbox benutzen kann. Aber die Realität scheint dann ja doch etwas komplexer :/ VHDL hotline schrieb im Beitrag #4449555: > Wie stellst du dir denn das Einbinden vor? In der openmsp430.v wird doch > zum Beispiel omsp_clock_module, omsp_frontend usw. eingebunden. Du musst > nur nicht, wie in VHDL, die Komponentendeklaration extra nochmal > hinschreiben. Das habe ich inzwischen dann auch herausgefunden, ich hatte im Code genau nach dieser aus VDHL bekannten Komponentendeklaration gesucht und sie nicht gefunden. Nach einigen Stunden durchwühlen des Codes bin ich aber wohl so ganz grob durchgestiegen. Mein Stand derzeit ist: Ich habe den Softcore im Projekt eingebunden und Memory angebunden. Es kompiliert bis zum Ende durch, schmeißt aber einen Haufen an Warnings heraus, die ich aktuell nachzuvollziehen versuche. Ich habe in der openMSP430_defines.v PMEM_AWIDTH auf 16 und DMEM_AWIDTH auf 12 gesetzt um so 128kB Programmspeicher und 8kB RAM zu bekommen, was dem MSP430F5529 entspricht. Entsprechende RAM Bausteine mit 16Bit Wortbreite aus dem MegaWizzard habe ich angebunden und den PMEM Baustein ein .hex File zum initialisieren gegeben, welches mir Energia für den MSP430F5529 kompiliert hatte (eine simple blinkende LED). Den entsprechenden GPIO habe ich auch im Design mit einer LED des BEMICRO CV Boards, mit dem ich gerade arbeite verbunden Bisher passiert noch nichts. Was mich irritiert: Das .hex File scheint nicht richtig in den Speicher zu passen. Ich bekomme die Warnings: Warning (113007): Byte addressed memory initialization file "Blink.cpp.hex" was read in the word-addressed format Warning (113015): Width of data items in "Blink.cpp.hex" is greater than the memory width. Wrapping data items to subsequent addresses. Found 76 warnings, reporting 10 Warning (113009): Data at line (1) of memory initialization file "Blink.cpp.hex" is too wide to fit in one memory word. Wrapping data to subsequent addresses. ... Critical Warning (127005): Memory depth (65536) in the design file differs from memory depth (65528) in the Memory Initialization File "/media/janos/JANOS64/openMSP430/Software/Blink.cpp.hex" -- setting initial value for remaining addresses to 0 Grundsätzlich sollte es doch funktionieren, das Programm Memory auf diese Weise schon mit einem Programm zu füllen, oder ist das ein Denkfehler? Ansonsten wäre es nun, wie schon von euch bemerkt, an diesem Punkt sicher gut etwas tiefer in Verilog zu stecken um den Grund für weitere Warnings nachzuvollziehen und diese bewerten zu können. Ich schau mal wie weit ich in den nächsten paar Tagen noch komme. Falls es nicht erfolgreich ist, werde ich mir noch einmal einen anderen, VHDL basierten Prozessor anschauen, ich bin mir in der Tat bewusst, dass es da noch so einige gibt. Auch der von Stephan N. verlinkte MSP430 in VHDL wäre da natürlich interessant. Ich halte euch auf dem laufenden und freue mich über Hinweise!
Sönke P. schrieb: > Ich hatte vor einiger Zeit mal mit openMSP430 rumgespielt und diesen > dazu in VHDL eingebunden. > Kannst du unter https://github.com/speters/openmspde0 finden. > > Das "Projekt" hatte ich mal angefangen, bevor ich auf den Trichter kam, > dass das A und O bei HDL die Testbenches sind. > Blinkyblinkyhelloworld auf 'nem FPGA-Board sind zwar fein und > motivierend, aber letztendlich muss man ganz klein anfangen, sonst wird > das nix. Oh, die Antwort hatte ich eben übersehen. Sehr cool, ich schau da mal rein. Wie weit ist dein Design denn funktionsfähig? Das mit den Testbenches ist in der Tat auch etwas, dass ich zwar von der Theorie verstehe, in der Praxis hier aber auch noch nie benutzt habe und recht komplex finde. Ich habe mir bisher immer das Design zusammengebaut, direkt auf der Hardware laufen lassen und im Zweifel den Signal Tap Analyzer genommen um Fehlfunktionen nachvollziehen zu können. Aber falls ich einen funktionierenden Softcore habe/finde, wäre das Thema Testbench ja erst einmal nicht so extrem wichtig für den Einstieg für mich, oder?
Janos B. schrieb: > Oh, die Antwort hatte ich eben übersehen. Sehr cool, ich schau da mal > rein. Wie weit ist dein Design denn funktionsfähig? Da ist ja nicht viel von mir dran, nur die Top-Entity und die herstellerspezifischen Memory-Blocks/Block-RAMs. Ein wenig Verilog benötigt man für die Konfiguration des Cores, da openMSP430 den Präprpozessor/Makros nutzt, anstatt - wie bei VHDL - spracheigene Konstrukte zu verwenden. Das oben verlinkte funktionierte insoweit, als dass der Testcode mit dem GPIO-Pingewackel (memledtest) läuft und auch die serielle Anbindung an den Debugger per openmsp430-minidebug klappt.
Okay, die Konfiguration geschieht dann ja in der openMSP_defines.v und parallel in der config.vhd richtig? Ich denke damit komme ich grundsätzlich klar. Ich habe die Pfadangaben in openMSP430.v gegen Pfade zu meinem lokal gespeicherten Projektordner getauscht. Das gab eine Stange an Errors bzgl. fehlenden Defines für omsp_clock_module.v. Ich habe dann festgestellt, dass in deiner openMSP430_defines.v unter "// Basic clock module: BCSCTL1 Control Register" vier Zeilen fehlten gegenüber der Version, die im Hauptprojekt enthalten war. Nach einem kopieren dieser Werte aus der anderen Datei hat er nun Fehlerfrei kompiliert. Hast du eine Ahnung wie das sein kann? Nun werde ich mal das ganze auf mein Board umbasteln und bin gespannt wie weit ich komme...
Ach ja noch etwas: Sönke P. schrieb: > Das oben verlinkte funktionierte insoweit, als dass der Testcode mit dem > GPIO-Pingewackel (memledtest) läuft Ich sehe, dass diese Datei mit dem Pfad msp430_software/memledtest.mif auch für das pmem0 als Initialisierungsfile angegeben ist. Nur leider befindet sie sich nicht (mehr) in dem von dir verlinkten GitHub Verzeichnis. Wo finde ich die?
Das memledtest Testprogramm ist i.w. in openMSP430 unter ./fpga/altera_de1_board/software/memledtest zu finden.
So, gerade habe ich mal Zeit gefunden mich wieder dran zu setzen. Hab den Memtest gefunden, bzw. gesehen dass in dem Ordner lediglich die Quellen dafür liegen. Warum liegt da nicht schon die fertig kompilierte Datei? Wie dem auch sei, ich habe mir einen USB-UART Adapter besorgt und konnte gerade den Softcore darüber mit dem mini debugger Tool ansprechen. Das ist schon mal ein großartiger Startpunkt und zeigt dass schon mal überhaupt irgendetwas funktioniert. Ich werde weiter über den Fortschritt berichten... :)
Guten Tag zusammen. Wie schon im vorherigen Post berichtet steht die grundsätzliche Kommunikation über die UART Debug Schnittstelle. Ich habe nun die Speicherkonfiguration an den MSP430G2553 angepasst (16kB Flash, 512B RAM) und möchte ein dafür mit Energia kompiliertes, simples Blink-Programm hochladen mit dem opemsp430-loader, ein Command line Tool, welches halt nichts weiter machen sollte, als ein in .hex-Format vorliegendes Programm in den openMSP430 zu laden. Leider bekomme ich folgende Meldung:
1 | .../tools/bin$ tclsh openmsp430-loader.tcl -device /dev/ttyUSB1 /tmp/build4194166154426707548.tmp/Blink.cpp.hex |
2 | |
3 | Connecting with the openMSP430 (/dev/ttyUSB1, 115200 bps)... done |
4 | Connected: target device has 16384B Program Memory and 512B Data Memory |
5 | |
6 | Load Program Memory... done |
7 | Verify Program Memory... ERROR |
Er scheint also das Programm in den Speicher zu laden und vergleicht danach ob das, was er aus dem Speicher dann wieder ausließt mit dem übereinstimmt, was hochgeladen wurde und stellt dabei einen Fehler fest? Wo könnte da mein Fehler liegen? Habe ich die Speicher aus dem MegaWizzard falsch parametrisiert? Oder hat jemand eine andere Idee, wo ich nach einer Lösung suchen könnte? Ich freue mich über Ideen und Tips!
Fehler gefunden. So etwas blödes ist mir selten passiert, ich habe direkt an zwei Stellen im Code dmem und pmem verdreht gehabt, so dass er keine Compilerwarnung rausgegeben hat, aber offensichtlich die ganze Zeit das Programm in den Arbeitsspeicher geladen hat. Und nun läuft es, ich kann den Softcore via Energia programmieren. Jetzt versuche ich als nächstes die Energia IDE zu modifizieren, dass er denn openMSP430 Uploader nutzt, statt den originalen und dann hätte ich einen FPGA-Softcore im Quasi-Arduino Style zusammengeschustert ;)
Hi Janos, I just stumbled upon this thread too late, as I see that you solved all your issues. Really good job :-) Oliv' PS: sorry, my written german is just not that good :-P
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.