Hallo, ich habe folgendes Problem und hoffe, dass jemand mir dabei helfen könnte.:) Ich habe einen VHDL Code, das Daten aus einem File liest (um es dann weiterzuverarbeiten). Die Simulation funktioniert auch ordentlich, allerdings habe ich schwierigkeiten den Code zu synthetisieren, damit ich es auf einem FPGA laden kann. Ich weiss, dass ich file operationen nicht synthetisieren kann, und ich sehe auch das Problem: solange ich auf meinem Rechner simuliere, kann der Simulator auf meinem Rechner auf die Datei zugreifen, auf dem FPGA geht dieser Vorgang natürlich nicht. Meine Frage: wie könnte ich erreichen, dass ich auf die Datei zugreifen kann, z.B. indem ich die Datei auf einem USB stick an den FPGA anschliesse? Was muss ich dann in diesem Fall in den VHDL code schreiben, damit es aus einer Datei lesen kann, was auf einem USB-Stick ist? MfG dagpe
Dag P. schrieb: > Meine Frage: wie könnte ich erreichen, dass ich auf die Datei zugreifen > kann, z.B. indem ich die Datei auf einem USB stick an den FPGA > anschliesse? So geht das nicht. > Was muss ich dann in diesem Fall in den VHDL code schreiben, damit es > aus einer Datei lesen kann, was auf einem USB-Stick ist? Wenn du "im echten Leben" auf einen USB-Stick zugreifen willst, dann mußt du 1. einen USB-Host implementieren, 2. einen USB-Stack für Massenspeicher implementieren, 3. das Filesystem implementieren, 4. Datei-IO-Operationen implementieren, und dann kannst du auf deine Daten zugreifen. Für die oben aufgeführten Aufgaben sieht ein (langsamer) Softcore angemessen aus... > Ich habe einen VHDL Code, das Daten aus einem File liest (um es dann > weiterzuverarbeiten). Was willst du damit im echten Leben machen? Wenn du dir schon so langsame Operationen wie "Dateizugriffe über USB" erlauben kannst, wofür dann danach eine schnelle Datenverarbeitung im FPGA?
Dag P. schrieb: > Meine Frage: wie könnte ich erreichen, dass ich auf die Datei zugreifen > kann, z.B. indem ich die Datei auf einem USB stick an den FPGA > anschliesse? Das einfachste dürfte sein die Daten in einem FPGA-internen RAM abzulegen. Wie groß sind denn Deine Daten? Und wie oft müssen die verändert werden? Duke
@ Lothar Miller, Duke Scarring danke für Ihre Antworten. Nun, mein Projekt sieht so aus: Ich habe einen synthetisierbaren VHDL Code vom Intel 8051 Microcontroller, den ich aber nur so (neu)programmieren kann, indem ich einen ROM definiere und da die auszuführenden Programzeilen in Maschinensprache reinschreibe. Dann muss ich synthetisieren und das Program läuft auf dem uC im FPGA. Ich möchte aber das ich das Ding auch nach der Synthese neuprogramieren kann, ohne es neu synthetiesieren zu müssen, und zwar in einer High-Level Programmiersprache, z.B. in C. Daher habe ich SDCC benutzt, um einen C Programm auf den 8051-er zu kompilieren. Das Resultat war ein .hex File. Ich habe ein VHDL-Modul geschrieben, das den Inhalt der .hex Datei in ein ROM kopiert - und zwar alle Bytes auf die richtige Adresse - das 8 bit breit ist, damit der uC den ROM richtig adressieren kann. Dies funktioniert im Simulator, leider kann ich es aber nicht synthetisieren, weil ja File operationen nicht synthetisierbar sind. Da ich den .hex file auf meinem Computer habe, muss ich die Datei irgendwie auf den FPGA bekommen, damit der implementierte uC aus der Datei lesen kann. Die Datei wird nur einmal am Anfang ausgelesen, es ist sozusagen ein "Boot-Prozess", das den uC am Anfang programmiert, was er zu tun haben wird. Ich hoffe, ich konnte mein Problem einigermassen verständlich schildern. Wenn Sie eine alternative Idee dazu hätten, wie der uC auf dem FPGA aus der .hex Datei lesen könnte, oder wie der uC überhaupt auf den Inhalt der Datei zugreifen könnte, wäre ich sehr Dankbar. :) Vielen Dank noch mal. MfG dagpe
Weiss nicht so genau, wie Deine Hardware aussieht, und wie flexibel Du bist sie zu verändern. Mit geringen Änderungen würde ich zwei mögliche Ansätze sehen: - UART / Seriele Schnittstelle. Statt eines ROM nimmst Du ein RAM auf dem FPGA und schreibst den Code vor dem Start runter und gibst das FPGA danach frei. HW-Aufwand und Aufwand für die UART im FPGA sind gering (und sicher existieren im Netz Quellen für beides) - Lokales Flash / EEPROM, zu programmieren z.B. über JTAG. Das FPGA holt sich dann den Programmcode bei jedem booten von dort. Hätte den Vorteil, dass Du nicht bei jedem Start neu schreiben musst, sondern nur Du wenn das Programm geändert hast...
Angehängte Dateien:
-
8051_in_FPGA.png
8,1 KB
@ Peter K. danke für Deine Tipps. Ich habe eine Skizze gezeichnet, wie ich mir das vorstelle. Ich möchte genau das machen, was Du bei den möglichen Ansätzen unter UART geschrieben hast. Mein VHDL-Modul, das auf Simulationsebene funktioniert, deklariert einen RAM (4KB), das (noch vor dem Start des Microcontrollers) mit dem Inhalt der .hex Datei "aufgefüllt" wird. Allerdings ist es nicht nur eine einfache Kopieraufgabe, denn mein RAM ist sequentiell, mit Adressen hintereinander von 0 bis 4095, wobei die Daten im file nicht sequentiell sind, ich muss die Daten aus der Datei (im Intel hex format) "herausfiltern", und zwar so, dass sie im RAM auf die richtige Adresse geschrieben werden. Wenn ich also, wie Du schreibst, einen UART im FPGA implementiere, dann kann ich zwar einzelne Daten von meinem Rechner auf den FPGA schicken, wenn ich es aber gut verstehe, dann werde ich trotzdem keinen Zugriff auf die ganze Datei haben, oder? Alles was ich bräuchte ist, dass der uC auf dem FPGA irgendwie auf den .hex File als ganzes Zugreifen kann, und es Charakter für Charakter auslesen kann, den Rest macht schon mein fertiges Modul. Deshalb dachte ich daran, dass ich einen USB IP implementiere, und die .hex Datei einfach auf ein USB-Stick kopiere, was ich dann an den FPGA anschliesse, damit der uC die Datei lesen kann. Allerdings weiss ich nicht was ich anstatt der Funktion des "read_file"-s (die ja nicht synthetisierbar ist) synthetisieren könnte, um das gleiche Ergebnis zu bekommen. Ich wusste auch nicht, dass das implementieren eines USB-s so kompliziert ist (oder zumindest sich kompliziert anhört:)) wie Lothar Miller es geschrieben hat. Danke nochmals. MfG dagpe
Dag P. schrieb: > Wenn ich also, wie Du schreibst, einen UART im FPGA implementiere, dann > > kann ich zwar einzelne Daten von meinem Rechner auf den FPGA schicken, > > wenn ich es aber gut verstehe, dann werde ich trotzdem keinen Zugriff > > auf die ganze Datei haben, oder? Die Idee wäre, dass Du über UART den ganzen RAM-Inhalt (Worte 0-4095) ins FPGA-RAM runter schickst und danach ebenfalls per UART (mit einem zu definierenden Kommando) das RAM dem internen 80C51 zur Verfügung stellst. Der 80C15 hat danach das RAM zur freien (Random Access ...) Verfügung. Du kannst das ganze System vorgängig simulieren, indem Du Dein File statt es direkt ins RAM zu laden via Testbench-UART-Modell und UART ins FPGA lädst. Für den 80C51 "hinter" dem RAM sollte nichts ändern, mal abgesehen davon, dass Du ihn erst loslassen darfst, wenn der Programm-Code im RAM ist. Einen ganzen USB-Link aufzubauen fände ich doch etwas viel Aufwand. Wenn Du losgelöst vom PC arbeiten musst (kein serielles Kabel), dann nimm halt ein kleines Flash/EEPROM und lade das FPGA-RAM von da. Hope this helps!
Das hex-File kannst du einfach mit hex2bin in ein sequenziell beschriebenes Bin-File umwandeln. Das kannst du dann hintereinander in den RAM schreiben. Im Normalfall schreibt man aber den BRAM über den Flash, in der Entwicklungsphase halt über JTAG mit dem Bit-File mit. Bei Xilinx gibts dazu entsprechende Tools, um BRAM Inhalt in den Bitstream einzubetten.
@ Peter K. Danke, ich muss es noch ein bisschen verdauen was Du geschrieben hast, es ist für mich nicht so trivial.:) @ Christian R Danke auch an Dich für Deine Antwort. Ich könnte also mit hex2bin einen sequentiellen bin File erzeugen. Ok, aber... Es kann sein das ich was falsch verstehe, aber wenn ich einen sequentiellen bin File erzeuge, habe ich immer noch das gleiche Problem, und zwar wie ich die Datei den uC im FPGA zugänglich mache, oder anders ausgedrückt, wie ich den Inhalt der Datei in einen RAM kopiere. MfG dagpe
Naja, da gibts mehrere Möglichkeiten. Wie schon geschrieben, zum Beispiel über UART, dazu musst du ein VHDL Modul schreiben, was auf UART Kommando hin den 8051 in den Reset schickt, und vom RAM abkoppelt. Dann beschreibst du den RAM und lässt nachher den 8051 wieder los laufen. Oder du nimmst einen DUAL Port RAM, der nur von UART beschrieben wird und nur vom 8051 gelesen wird. Dann hast du aus der Sicht des 8051 einen ROM. Im Normalfall wird aber wie ich schon schrieb, der RAM/ROM Inhalt für einen embedded Prozessor in den Bitstrom des FPGA integriert. Alle RAM Speicherzellen lassen sich mit dem Bitstrom beschreiben. Wenn du deine hex-Datei änderst, musst du nur das Bit-File neu erzeugen und per JTAG auf den FPGA bringen. Die gesamte Synthese, Mapping, Place&Route kannst du dann sparen, weil sich nur der RAM-Inhalt ändert. Lös dich von deinem File-IO Gedanken, das klappt auf dem FPGA nicht. Du hast da einen RAM oder ROM, den musst du mit den Daten aus dem Hex-File füllen.
@ Christian R. Naja, nach alledem was Ihr mir hier geschrieben habt, glaube ich auch, dass es mit diesem File IO nicht funktionieren wird und ich mich von diesen Gedanken lösen muss. Jedenfalls danke für Deine Hilfe, und danke natürlich auch an alle de mir hier geholfen haben... Mfg dagpe
Dag P. schrieb: > glaube ich auch, dass es mit diesem File IO nicht funktionieren wird Richtig, aber das ist keine Glaubenssache, sondern einfach eine Sache von Entwicklungssystem vs. FPGA-Board... File-IO ist nur für den Synthesizer und/oder den Simulator gedacht.
Christian R. schrieb: > Mal ganz unabhängig von den FileIO Sachen: Welches FPGA benutzt du denn > eigentlich? Die Sache ist die, dass ich aller Voraussicht nach in den nächsten Tagen einen Spartan-3 ausgeliehen bekomme. Ich war aber schon neugierig, ob ich meinen VHDL Code den ich geschrieben habe überhaupt synthetisieren kann, also habe ich Webpack von Xilinx runtergeladen. Und da fingen die Probleme an, denn ich habe mein Code in Modelsim geschrieben und auch Simuliert, hab mir aber noch keinen Kopf darüber gemacht wie ich es denn synthetisieren werde. Mein Ziel ist aber einen C-compiler zu den uC zu porten, damit ich den uC direkt in C programieren kann. Wie meine früheren Posts schon erahnen lassen, dachte ich, dass ich den hex File, der ja den auszuführenden kompilierten Programm beinhaltet, einfach in irgendeiner weise den uC zur verfügung stellen kann. Das hat bei der Simulation auch prima geklappt, da ich da ja die textio library von VHDL einfach benutzen konnte. Ich ahnte zwar schon, dass das wohl nicht eins-zu-eins zu synthetisieren sei, dachte aber dass es wohl irgendeine andere Möglichkeit geben wird, mit dem gleichen Ergebnis. War wohl bisschen Naiv, jetzt muss ich schauen wie ich eure Tipps in die Wirklichkeit umsetzen kann...:)
Naja, bei Xilinx können dir die meisten hier weiterhelfen. Du erstellst ein synthetisierbares Design mit deinem 8051 und einem ROM in der passenden Größe. Dann kannst du die Synthese durchlaufen lassen und am Ende fügst du den Compiler-Output in das Bit-File ein. Immer wenn du das 8051 Programm neu kompilierst musst du nur wieder das hex-File in ein BMM File umwandeln, und mit data2mem in das Bit-File schreiben. Geht aber nur für Spartan 3A, 3A DSP und 3AN. Schau mal hier: http://www.xilinx.com/support/documentation/sw_manuals/xilinx11/data2mem.pdf
Dag P. schrieb: > Und da fingen die Probleme an, denn ich habe mein Code in Modelsim > geschrieben und auch Simuliert... Oha, ein Theoretiker... ;-) Der synthesefähige Teil der VHDL Syntax ist (wenns hoch kommt) ca. 1%. Ich kann dir mal etwas ganz einfaches hinschreiben, dass super simuliert, aber (heutzutage) mitnichten synthetisiert werden kann:
1 | b <= a after 10 ns; |
Und wenn schon so unglaublich simple Konstrukte nicht in die Realität abgebildet werden können... :-o
Dag P. schrieb: > Ich ahnte zwar schon, dass das wohl nicht eins-zu-eins zu synthetisieren > sei, dachte aber dass es wohl irgendeine andere Möglichkeit geben wird, > mit dem gleichen Ergebnis. Geht aber fast ein-zu-eins (mit Neusynthese oder per JTAG). Schau mal hier: Beitrag "RAM Update für picoBlaze ohne Neusynthese" Ein VHDL-UART-Intel-Hex-Decoder-Core wäre auch 'ne feine Sache. Der könnte per :00000001FF dann den CPU-Reset auslösen. Duke
@ Christian R. Danke für den Link, ich werde es gleich lesen. @ Lothar Miller > Oha, ein Theoretiker... ;-) Naja, das ich jetzt ein bisschen in eine Sackgasse gekommen bin, ist das Ergebnis eines Prozesses, an dessen Anfang es hiess, ach schreib' ma einen VHDL Code, das dies und das macht, kein Problem wenn es nicht synthetisierbar ist. Ok, der Code ist fertig, die Simulation läuft, prima. Und dann: wenn wir schon so weit sind, wir könnten es doch auf einem FPGA implementieren, wär doch schön. Tja, und dann ist die synthetiesierbarkeit nicht mehr zweitrangig. Ich wusste zwar, dass Testbenches, und Verzögerungen wie
1 | b <= after 10 ns |
oder "wait for 10 ns" Statements nicht synthetisierbar sind, aber im Endeffekt hast Du Recht, ich habe zwar einiges über VHDL und FPGAs gelernt, aber in der Praxis leider zu wenig...:)
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.