Ich habe schon mehrere Softcores für FPGA's aus opencores.com versucht in eine Anlogic FPGA zu integrieren. Dabei stieß ich immer wieder auf Probleme. Ich muss gleich dazu sagen - Ich nutze kein LINUX sondern WINDOWS. Das größte Problem - welches ich im Moment sehe - ist die der Generierung des µC Programms für den Softcore und die Frage - wie bringe ich dies in den FPGA? Mal angenommen man reseviert oder sieht RAM/ROM dafür vor. Dann kann man den ja bei der Erstellung des SoftcoreFPGA.bit Files ja schon als Initialfile in den RAM/ROM integrieren/laden. Wenn man jetzt z.B. das AtmelStudio zur Generierung verwendet erzeugt mir dieses doch ein Hex-File im Motorola Format. Dieses müsste jetzt entsprechend in ein RAM/ROM Initial-File für den FPGA (Format hier xxx.mif) gewandelt werden. Und wenn ich es schaffe, dieses File in den RAM/ROM zu bringen, sollte doch der Softcore laufen, oder? Hab ich dies bis hierhin richtig verstanden? PS: Gerade versuche ich diesen Softcore für eine Anlogic EG4S20 FPGA zu integrieren/anzupassen.(Bin noch am Anfang) https://opencores.org/projects/softavrcore
Hmm, mit dem Kompeiler kein Binfile erzeugen koennen, aber an FPGA rumspielen wollen. Du bist ja ein Fokel Altera kann auch Hexfiles lesen!
Angehängte Dateien:
Altera? >Anlogic EG4S20 FPGA https://www.mikrocontroller.net/attachment/520610/EG4S20_integrated_SDRAM.pdf Chinesisch, die englische Website ist noch im Aufbau https://www.crunchbase.com/organization/anlogic
:
Bearbeitet durch User
Christoph db1uq K. schrieb: > Altera? *.mif ist ursprünglich ein Alteraformat, es steht also zu vermuten das du mit altera/intel tools hex zu mif konvertieren kannst. O.ä. https://www.intel.com/content/www/us/en/programmable/quartushelp/13.0/mergedProjects/reference/glossary/def_mif.htm Und wenn nicht eigentlich ne gute Idee mit python oder tcl anzufangen und sich selbst einen konverter zu schreiben. https://pypi.org/project/mif/
qwerty schrieb: > Hmm,... Naja, mir kommt da der kleine Häwelmann in den Sinn, oder wie kann man mit dem eigenen Himmelbettchen zum Mond fliegen. W.S.
HomukoVodeFa schrieb: > *.mif ist ursprünglich ein Alteraformat, es steht also zu vermuten das > du mit altera/intel tools hex zu mif konvertieren kannst. O.ä. Einen Konverter hab ich schon geschrieben. Mich interessiert erstmal ob ich das Prinzip dahinter richtig verstanden habe bevor ich anfange den nächsten Core auf einen EG4S20 FPGA abzuändern und dann alles synthetisieren kann und doch kein Programm in den FPGA bekomme.
:
Bearbeitet durch User
> Mich interessiert erstmal ob > ich das Prinzip dahinter richtig versanden habe bevor ich anfange den > nächsten Core auf einen EG4S20 FPGA abzuändern und dann alles > synthetisieren kann und kein Programm in den FPGA bekomme. Naja wenn die eine Art das programm reinzubekommen, nicht funktionniert, versucht man halt ne andere, bspw. über inferiertes ROM/RAM mit Constants: https://www.mikrocontroller.net/articles/Retrocomputing_auf_FPGA#.22Vor.22-laden_und_Starten_eines_Programmes Neben der vollen Synthese mit der 'Firmware' als VHDL-konstante, gibt es je nach toolchain noch andere Möglichkeiten, bspw. überschreiben der entsprechenden Abschnitte im config-bitstream. Was deine toolchain kann, wirste aber wegen dem Exotenstatus wohl selbst austesten müssen. Bei überfliegen der dynasty-manual habe ich jetztz nichts gefunden. Du kannst ja auch mal den Autor bei OpenCores kontaktieren, vielleicht hat der ja Tipps für den Chinesen-Brösel.
qwerty schrieb: > Hmm, mit dem Kompeiler kein Binfile erzeugen koennen, > aber an FPGA rumspielen wollen. Danke für den Hinweis 'qwerty'. Darüber hab ich noch garnicht nachgedacht, ob das der avrasm2 assembler auch gleich macht. Und zumindest kann ich da 'generisch', 'Intel-Hex' oder 'Motorola-Format' auswählen und damit lässt sich jetzt noch einfacher ein 'xxx.mif' ROM-Init-File erstellen. Danke qwerty HomukoVodeFa schrieb: > Naja wenn die eine Art das programm reinzubekommen, nicht funktionniert, > versucht man halt ne andere, bspw. über inferiertes ROM/RAM mit > Constants: Das werde ich mir ansehen - danke. HomukoVodeFa schrieb: > Neben der vollen Synthese mit der 'Firmware' als VHDL-konstante, gibt es > je nach toolchain noch andere Möglichkeiten, bspw. überschreiben der > entsprechenden Abschnitte im config-bitstream. Was deine toolchain kann, > wirste aber wegen dem Exotenstatus wohl selbst austesten müssen. Kann es - Der FPGA Downloader kann das wohl. Hab ich zumindest so schon erlesen können. Aber das werde ich dann erst später in Angriff nehmen. Erstmal muss wenigstens das 'Hello world" mit dem Softcore realisiert werden.
> das Prinzip dahinter richtig verstanden habe Das geht ganz einfach: Eine > volle Synthese mit der 'Firmware' als VHDL-konstante erzeugt z.B. bei den Alteratools ein MIF-File. Das kann mann dann ja kontrollieren. Aber was die Fuelle der Moeglichkeiten an Endianess, Stuffing etc. angeht, macht das ganze schon fehlertraechtig. Und mit chinesischen Exoten wird es wohl nicht leichter.
Wie sieht die Toolchain für das chinesische FPGA aus, vom Hersteller scheint ja nicht viel zu kommen? Gibt es das zu dem Eval-Board? https://www.cnx-software.com/2018/09/04/licheetang-anlogic-eg4s20-fpga-board-targets-risc-v-development/ https://www.seeedstudio.com/Sipeed-TANG-PriMER-FPGA-Development-Board-p-2881.html Eine IDE: "Integrate, download, debug features with TD IDE" Und weiter unten im Abschnitt "LEARN AND DOCUMENTS" anscheinend Links zum Hersteller als Textfile. Sehr umständlich. Auch Tipps zur Linux-Installation.
Christoph db1uq K. schrieb: > Wie sieht die Toolchain für das chinesische FPGA aus, vom Hersteller > scheint ja nicht viel zu kommen? Gibt es das zu dem Eval-Board? Ich arbeite mit WINDOWS. Die Toolchain Tang Dynastie TD4.xx oder TD5.xx zum FPGA läuft unter WINDOWS und LINUX. Genau dieses EVAL Board benutze ich. Und soweit funktioniert auch alles. Die Dokumentation auf englisch zum FPGA und der Software ist da, allerdings mühsam zusammengestellt. Ich habe 64x9k und 16x32k Block RAM und 19600 LUT zur Verfühgung. Einen LCD Controller àla SSD1351 für einen 8bit AVR (6800-series Interface) hab ich schon erfolgreich in den FPGA gebaut und eingepflanzt. Dazu habe ich auch den embedded SDRAM genutzt. Dabei ist dann auch dieses von dir angegebene Dokument zum SDRAM entstanden. Nun möcht ich halt gerne mal einen AVR Core in den FPGA bringen und damit ein wenig rumspielen. Dieser E203 RISC-V Core läuft zwar auf dem FPGA und man kann den auch per Arduino verwenden, aber der ist so dermaßen abgespeckt, dass da nur ein IO Port und JTAG zum Programmieren funktioniert und sonst nichts.
"Be ready to learn Mandarin or use Google translate (seedstudio-Link ganz unten) Das FPGA enthält also keinen nichtflüchtigen Speicher, nur SRAM und SDRAM. Ein 8 MBit Flash für das FPGA und ein JTAG Anschluss vermutlich um das zu füllen. Der USB-Anschluss scheint nur für die Versorgung zu sein, wie wird JTAG mit dem PC verbunden? Erweiterung des Flash über SD-Karte. Irgendein Bootloader dürfte nach dem Einschalten das Flash in das FPGA kopieren, dann muss der Softcore irgendwie starten. Der AVR-Softcore wird schon in den 8 MBit stehen, aber sein Programm müsste der Bootloader noch aus der SD-Karte nachladen, bevor der AVR startet?
Angehängte Dateien:
-
Schematic.png
200 KB
Christoph db1uq K. schrieb: > Das FPGA enthält also keinen nichtflüchtigen Speicher, nur SRAM und > SDRAM. Ja, genau. Christoph db1uq K. schrieb: > Ein 8 MBit Flash für das FPGA und ein JTAG Anschluss vermutlich > um das zu füllen. Ja und Nein. Genau genommen sind es 2 Flash Speicher. Wenn ich es richtig verstanden habe, 2x8Mbit XT25F08B NOR Flash. Christoph db1uq K. schrieb: > Der USB-Anschluss scheint nur für die Versorgung zu > sein, wie wird JTAG mit dem PC verbunden? Nein. Der FPGA wird über den USB -> GD32 µC -> JTAG -> FPGA (siehe oben Bild) aus der Toolchain mit einem Downloader beschrieben. Dabei kann man wählen wohin das bin-File gehen soll. In den RAM oder in den externen Flash. Es gibt noch sehr viel mehr Möglichkeiten. Aber dazu habe ich mich noch nicht eingelesen. Also der µC (GD32...) stellt hier die JTAG Brücke zum programmieren und debuggen bereit. Das JTAG Interface welches ich im Bezug auf den E203 Risc-V Core erwähnt hatte ist in der dem Soft-Core enthalten und extra heraus geführt. Darüber wird bei dem Risc-V der Programmcode geladen und der Core debuggt. Christoph db1uq K. schrieb: > Erweiterung des Flash über > SD-Karte Dies wäre dann auch noch eine Möglichkeit.
> Ich habe schon mehrere Softcores für FPGA's aus opencores.com versucht in eine Anlogic FPGA zu integrieren. Dabei stieß ich immer wieder auf Probleme. Wie wärs damit: https://github.com/stnolting/neorv32 Ist ein [Zitat] "platformunabhängiger RISC-V Mikrocontroller". Die eigentliche Anwendungssoftware kann man entweder per Bootloader und UART/SPI, per vor-initialisiertem Blockram oder sogar per JTAG über openOCD/gdb einspielen.
Ich wollte erst einmal beim 8-Bitter bleiben. Aber den NEORV32 hatte ich mir auch schon angeschaut. Der ist auch super kommentiert. Nur mit der Erzeugung von Programm Code hab ich noch nicht ganz durchgesehen.
> Nur mit der Erzeugung von Programm Code hab ich noch nicht ganz durchgesehen. Gebaute Toolchains zum NEORV32 gibt es hier: https://github.com/stnolting/riscv-gcc-prebuilt Einfach runterladen, entpacken, zu PATH hinzufügen und das wars. Ich nutze auch Windows und benutze das Linux Subsystem von Windows. Funktionert bisher ohne Probleme damit. Einfach "make" tippen und die ganzen Skripte bauen aus dem C-Programm eine Executable.
Ggf. 'ne Art Net-Urloader wie anno dunnemals drumherum bauen. Damals baute man Logikschaltungen die zu beginn von einer Betriebssystemdiskette die Firmware direkt in den RAM schrieben und anschliessend die CPU an den Bus schalteten. Hier könnte man im FPGA-code einen Mux und einen AUART beschreiben. Zu beginn ist der Programmspeicher über den MUX mit nen UART verbunden der über 3-2 Pins mit einem ÜC verbunden ist der per serielle Konsole das Atmel-Programm rüberpustet. Anschliessend schaltet derMuxer den Arbeitsspeicher an den atmel core und startet den Core (lokaler Reset release). Diese Methode funktioniert unabhängig von der restlichen Hardware auf dem Board, man braucht lediglich ein serielles USB-Kabel wie dieses: https://www.amazon.de/PL2303-USB-Kabel-Header-Pinbelegung-ttl-232r-3-V3-Stecker/dp/B075GH9H3P Dein Board sollte 3V3 IO-s unterstützen?! Was ähnliches würde für das erwähnte Z1013 Nachbau auch gemacht: https://github.com/abnoname/redz0mb1e-de1 https://www.robotrontechnik.de/html/forum/thwb/showtopic.php?threadid=9276 (Post 243 vom 05.01.2015)
8 Bitter auf FPGA...naja. AVR benötigt wohl ähnlich viele Resourcen wie ein 8051 Core, und damit immer noch mehr als ein schmaler RISC-V. Der NEORV32 ist mir etwas zu überdosiert und die Pipeline-Architektur etwas eigenwillig. Aber einen Prozessor in pur VHDL hochzuziehen ist mutig, deswegen: Well done. Man sollte sich beim FPGA halt genau fragen, was der Zweck des Prozessors sein soll (komplette Simulierbarkeit oder reiner Konfigurationsprozessor oder auf Coprocessing optimiert, usw.). Es gibt komplette Build-Systeme, die wie Linux die Konfiguration erledigen, ROM Tabellen für VHDL/Verilog generieren, usw. - das läuft als Docker-VM auch unter Windows oder im Browser, usw. Man kann sich das auch mit msys2 oder cygwin alles selbst herbasteln, aber verzettelt sich u.U. sinnlos.
Fitzebutze schrieb: > 8 Bitter auf FPGA...naja. AVR benötigt wohl ähnlich viele Resourcen wie > ein 8051 Core, und damit immer noch mehr als ein schmaler RISC-V. Der > NEORV32 ist mir etwas zu überdosiert und die Pipeline-Architektur etwas > eigenwillig. Ich würde sogar RISC-V eher vorschlagen ... picorv32 oder vexriscv. Hab mit letzterem schon relativ viel gemacht in Cyclone 10, Spartan 7 und ICE40. Hat tadellos funktioniert :)
Mampf F. schrieb: > Ich würde sogar RISC-V eher vorschlagen ... picorv32 oder vexriscv. Ja, der NeoRV32 interessiert mich schon. Kurzes Update: Ich versuche jetzt doch gerade einen mega32U4 zu implementieren/anzupassen. Die Synthese ging ohne Fehler und jetzt sogar ohne Warnungen durch. Eine LED hab ich zum leuchten bekommen. Aber irgendwas haut noch nicht mit dem RCALL + RET hin. IN/OUT sowie DEC, LDI, BRNE, RJMP funktionieren schonmal. Die Interrupt Vectortabelle ist benötigt nur ein Wort anstatt wie beim orginal 2. Ich habe jetzt ja auch nur 4k ROM als Programmspeicher vorgesehen. Ich versuche nun dem rcall/ret auf die Schliche zu kommen. PS: Der "rcall" scheint zu funktionieren. Denn das Unterprogramm wird angesprungen. Scheinbar wird die Rücksprungadresse nicht richtig abgelegt oder zurück geholt.
> und jetzt sogar ohne Warnungen durch
Das glaubst du doch selber nicht.
Angehängte Dateien:
&&& schrieb: >> und jetzt sogar ohne Warnungen durch > > Das glaubst du doch selber nicht. Da hast du Recht - ich wollt es auch selber nicht glauben. Aber ja! Es ist ohne zu meckern durch gegangen. Ich hänge mal das komplette Projekt - so wie der Stand bis jetzt ist - mit an. Außerdem hab ich mal die ROM-read-Adresse (PC) ab RESET mit Core Takt mit einem Analyzer aufgezeichnet. Und dazu das Mini Programm mit ROM-Adressen. Es soll eine der 3 RGB LED blinken. Dazu das Unterprogramm mit den delay-countern.
Hier hatte ich den Neo-RiscV ausprobiert: Beitrag "RISC V minmal CPU" Das lies sich relative gut umsetzen.
Super toll chris_. Das werde ich mir auf alle Fälle auch noch genauer anschauen. Aber erstmal möchte ich den mega32u4 komplett zum laufen bringen. Es hapert immer noch am RET / RETI Der Timer0 Overflow Interrupt funktioniert sogar bis zum RETI.. Irgendwas läuft wahrscheinlich beim STACK schief. Vielleicht liegt es am REGISTERD/NON REGISTERD Ich bleib dran
> in eine Anlogic FPGA zu integrieren. Dabei stieß ich immer wieder auf > Probleme. Verstehe ich garnicht. Ich hab einfach nur die Doku gelesen. :-) Die Oberflaeche liesst mif files ein. Die sehen im Prinzip so aus: -- Olafs MIF Generator V1.0 DEPTH = 4096; -- Anzahl der Datenwoerter WIDTH = 8; -- Breite eines Datenworts in Bit ADDRESS_RADIX = HEX; -- The radix for address values DATA_RADIX = HEX; -- The radix for data values -- -- CONTENT -- Ab hier folgen die Daten BEGIN 0000 : 00; 0001 : 00; 0002 : ff; [..] Wie die siehst, ich hab mir selber einen kleinen Konverter geschrieben der bin-files in mif umwandelt. Dann laesst du dir von der Entwicklungsumgebung etwas blockram generieren und dort kannst du das mif File einlesen: .INIT_FILE("rom.mif"), Ich hab das hier problemlos mit einer 6502 laufen.... Olaf
> Verstehe ich garnicht.
Du hantierst auch nur mit Trivialitaeten.
Spannend wird es z.B. bei Fixpointzahlen im Q27 Format.
&&& schrieb: >> Verstehe ich garnicht. > > Du hantierst auch nur mit Trivialitaeten. > Spannend wird es z.B. bei Fixpointzahlen im Q27 Format. MIF kann Float-Werte selbstständig in ein Fixpunkt-Format umrechnen?
Olaf schrieb: > Wie die siehst, ich hab mir selber einen kleinen Konverter geschrieben > der bin-files in mif umwandelt. Das hab ich auch schon längst erledigt ;) Am .mif oder .dat File liegt es schon lange nicht mehr. Olaf schrieb: > Ich hab das hier problemlos mit einer 6502 laufen.... Olaf, könntest du bitte mehr darüber schreiben oder vielleicht mal ein .bin zum testen geben? Gerne auch per PN. Ich weiß, dass du auch dieses Sipeed Tang Primer Board hast. :) 6502 hört sich so nach C64 an?
Ich verwende ein simples tcl-Skript, um .bin-Dateien in .vhdl umzuwandeln. Das hat den Vorteil, dass man damit unabhängig von der Synthese (und .mif) wird und den Code auch (z.B. mit ghdl) simulieren kann.
1 | package require cmdline |
2 | |
3 | post_message "embed_m68k.tcl" |
4 | |
5 | exec /bin/bash -c "(cd m68k; make)" |
6 | set binfile m68k/simple.bin |
7 | set fp [open $binfile r] |
8 | fconfigure $fp -translation binary |
9 | set bindata [read $fp] |
10 | close $fp |
11 | |
12 | set filename simple.vhd |
13 | |
14 | set date [clock format [clock seconds] -format { %a, %Y-%m-%d, %H:%M }]
|
15 | set file [open $filename w] |
16 | set script [info script] |
17 | |
18 | puts $file "library ieee;" |
19 | puts $file "use ieee.std_logic_1164.all;" |
20 | puts $file "" |
21 | puts $file " -- VHDL representation of $binfile" |
22 | puts $file " -- generated by $script on $date" |
23 | puts $file " -- m68k executable as preloaded RAM contents" |
24 | puts $file "" |
25 | puts $file "package m68k_binary is" |
26 | puts $file " subtype ubyte is std_logic_vector(7 downto 0);" |
27 | puts $file " type ubyte_array is array (natural range <>) of ubyte;" |
28 | puts $file "" |
29 | puts $file " constant m68k_binary : ubyte_array :=" |
30 | puts $file " ("
|
31 | puts -nonewline $file " " |
32 | set len [string length $bindata] |
33 | for {set i 0} {$i < $len} {incr i} {
|
34 | set char [string index $bindata $i] |
35 | binary scan $char H2 byte |
36 | puts -nonewline $file "x\"" |
37 | puts -nonewline $file $byte |
38 | puts -nonewline $file "\"" |
39 | if { ! ([expr $i + 1] == $len) } {
|
40 | puts -nonewline $file ", " |
41 | } |
42 | if { [expr ($i + 1) % 8] == 0 } {
|
43 | puts $file "" |
44 | puts -nonewline $file " " |
45 | } |
46 | } |
47 | puts $file "" |
48 | puts $file " );" |
49 | puts $file "end package m68k_binary;" |
50 | close $file |
> Olaf, könntest du bitte mehr darüber schreiben oder vielleicht mal ein > .bin zum testen geben? Was soll ich dazu schreiben? Ich hab einfach das hier synthetisiert: https://github.com/Arlet/verilog-6502 http://ladybug.xs4all.nl/arlet/fpga/6502/ > 6502 hört sich so nach C64 an? 6502 hoert sich nach 6502 an. 7805 hoert sich ja auch nicht nach C64 an auch wenn man vermuten darf das einer drin war. :-) Der 6502 ist halt eine sehr einfach CPU die den Vorteil hat nur sehr wenige Resourcen zu verbrauchen. Wenn ich mich richtig entsinne laeuft sie im Anylogic maximal mit 90Mhz takt, ich lasse sie aber in der Regel deutlich langsamer laufen. Olaf
Markus F. schrieb: > Ich verwende ein simples tcl-Skript, um .bin-Dateien in .vhdl > umzuwandeln. Toll, was für .bin Dateien meinst du denn damit und wozu in VHDL wandeln? Ich verstehe gerade den Sinn nicht. Oder wird in VHDL der RAM anders initalisiert? Hört sich ja so an, als könne man den nicht über ein Daten-File initialisieren. Ich allerdings benötige nunmal ein .mif oder .dat File mit Daten (so wie Olaf schon im letzten Beitrag gezeigt hat) um diese zum Initialisieren in den RAM zu bringen. Ich verwende 'eh Verilog. Will jetzt keinen Streit vom Zaun brechen - dafür gibt es hier schon diverse andere Beiträge - aber ich persönlich finde Verilog übersichtlicher und besser. Olaf schrieb: > 6502 hoert sich nach 6502 an. 7805 hoert sich ja auch nicht nach C64 > an auch wenn man vermuten darf das einer drin war. :-) Mir wär so als hätte ich neulich etwas darüber gelesen. Nun ja, auf jedenfall ist es auch eine CPU/ZPU. Der mega32u4 Core läuft inzwischen. Es lag am STACK Pointer. Diesen musste ich wie bei der älteren Generation der AVR's erst initialisieren. Also auf das Ende des RAM zeigen lassen. Macht ja auch Sinn in einem konfigurierbaren Core mit konfigurierbarem RAM das auch dem USER zu überlassen. Obwohl es wohl auch bei einem RESET vom Core übernommen werden könnte. Jetzt probiere ich gerade ein paar AVR Instructions auf aus. Dabei fällt mir auf, dass diese nicht allzu stabil laufen. Soll heißen: Ich vermute mal, dass durch Unterbrechung eines Interrupts irgendwelche Daten verloren gehen. Denn meine LED blinkt ab und zu mit einem extra kurzem Intervall. SBIW funktionierte erstmal gar nicht. Der "BRNE" Befehl verweigerte seinen Dienst so dass ich auf getrenntes SUB/SBC umsteigen musste. Nun gehe ich der SBIW Befehlsumsetzung nach, ob ich dabei einen Fehler entdecken kann. Eventuell liegt es hieran:
1 | `INSTRUCTION_SBIW: |
2 | begin
|
3 | R = {1'b0, rd} - {inst[7:6], inst[3:0]}; |
4 | sreg_out[`XMEGA_FLAG_C] = R[15] & ~rd[15]; |
5 | sreg_out[`XMEGA_FLAG_V] = ~R[15] & rd[15]; |
6 | sreg_out[`XMEGA_FLAG_N] = R[15]; |
7 | sreg_out[`XMEGA_FLAG_S] = sreg_out[`XMEGA_FLAG_N] ^ sreg_out[`XMEGA_FLAG_V]; |
8 | sreg_out[`XMEGA_FLAG_Z] = RD_16_IS_ZERO; |
9 | end
|
R und rd sind 16bit Register. Hier wird aber dem 16Bit R <= ( 1Bit + 16Bit 'rd') zugeordnet. Ein Bit von rd fällt dadurch weg. Ich weiß gerade nur nicht welches. Entweder das *rd[15]* oder das *rd[0]*. Aber egal welches, ich denke mal für die Rechenoperation ist es nicht gut. Was meint ihr?
Steffen H. schrieb: > Toll, was für .bin Dateien meinst du denn damit und wozu in VHDL > wandeln? Ich verstehe gerade den Sinn nicht. Oder wird in VHDL der RAM > anders initalisiert? Hört sich ja so an, als könne man den nicht über > ein Daten-File initialisieren. Gleiche Problematik wie bei dir: Binärcode in den Softcore-RAM oder -ROM laden. .mif-Dateien sind plattformspezifisch. VHDL nicht. Das Script verwende ich für die Simulation mit ghdl (das kann mit .mif nichts anfangen) identisch zur Synthese.
Angehängte Dateien:
-
GTK_SBIW.PNG
41 KB
Steffen H. schrieb: > Eventuell liegt es hieran:`INSTRUCTION_SBIW: > begin > R = {1'b0, rd} - {inst[7:6], inst[3:0]}; > sreg_out[`XMEGA_FLAG_C] = R[15] & ~rd[15]; > sreg_out[`XMEGA_FLAG_V] = ~R[15] & rd[15]; > sreg_out[`XMEGA_FLAG_N] = R[15]; > sreg_out[`XMEGA_FLAG_S] = sreg_out[`XMEGA_FLAG_N] ^ > sreg_out[`XMEGA_FLAG_V]; > sreg_out[`XMEGA_FLAG_Z] = RD_16_IS_ZERO; > end Also daran scheint es nicht zu liegen. Hab es gerade getestet - siehe Bild. Das funktioniert alles. Warum der BRNE Befehl bei SREG_Z = 1 nicht reagiert ist mir weiterhin ein Rätzel.
Steffen H. schrieb: > Warum der BRNE Befehl bei SREG_Z = 1 nicht > reagiert ist mir weiterhin ein Rätzel. Ich frage mal ganz unbedarft: "Was erwartest Du?" BRNE heisst doch "branch if Not Equal", also bei Ungleichheit. Und ungleichheit wird doch im Unterschied zu Gleichheit (wie bei BREQ "branch if equal" erforderlich ) mit Zeroflag = '0' angezeigt. Dann ist doch ganz verständlich, daß BRNE bei gesetztem Zero-Flag (Gleichheit anzeigend) nicht reagiert?!
https://www.eejournal.com/article/fpgas-made-in-china/ Ein Artikel zu FPGAs aus China, verglichen mit den "big guys" in USA. Anlogic steht auch in der noch kurzen Liste. "their data sheets are largely written in Mandarin"
Christoph db1uq K. schrieb: > https://www.eejournal.com/article/fpgas-made-in-china/ > Ein Artikel zu FPGAs aus China, verglichen mit den "big guys" in USA. Interessante Übersicht, auch wenn die Basis keine Labortests sind sondern google ("... With a bit of Google elbow grease ..") Und zu dem Nachteil der unverständlichen Dokumentation und tool-sprache kommt die im Vergleich zu heutigen Baureihen wie Xilinx series seven und Zybo SoC eher geringe Leistungsfähigkeit: Zitat: "If you look at the FPGAs in the above table, you might conclude that they offer little serious competition to the more advanced FPGA offerings from Intel, Lattice, Microchip, or Xilinx" Diese China-FPGA's entsprechen dem hiesigen Stand vor 20 Jahren, also Spartan-3/6 -> Zitat: "The FPGAs from these companies are mostly “pure” in the Tim Davis sense: they look like they could have been developed in the 1990s. They’re largely arrays of programmable logic, based mostly on 4- and 5-input LUTs, and most offer only parallel I/O pins with adjustable voltage levels (with a few exceptions)." Damit ist IMHO immer noch ein älteres und damit sehr preiswertes Evalboard mit Xilinx oder Altera mit englischsprachige Dokumentation und oft auch deutschsprachigen Anleitungen aus dem Hochschul/Maker-Unfeld die mit Abstand bessere Wahl in Sachen Einsteiger-Hardware.
Ich will jetzt keinen Streit vom Zaun brechen, aber ich fand halt den integrierten SDRAM, die DSP's und ausrechend LUT's sowie die standardisierte 40pol LCD Schnittstelle mit LED Backlight Stromsenke und Touchcontroller und den Preis dazu sehr überzeugend, um mir dieses Board zu zulegen. Trotzdem passen diese beiden Beiträge wohl besser in diesen Tread hier: Beitrag "Sipeed Lichee Tang FPGA mit RISC-V Core aus China unter 20€"
Fpgakuechle K. schrieb: > Diese China-FPGA's entsprechen dem hiesigen Stand vor 20 Jahren, also > Spartan-3/6 -> > Nur, dass sie etwas stromsparender sind. > > Damit ist IMHO immer noch ein älteres und damit sehr preiswertes > Evalboard mit Xilinx oder Altera mit englischsprachige Dokumentation und > oft auch deutschsprachigen Anleitungen aus dem Hochschul/Maker-Unfeld > die mit Abstand bessere Wahl in Sachen Einsteiger-Hardware. Das sehe ich nicht so. Bin eher ein Freund von 'keep it simple' (and focused), wenn die Toolchain eines noch so primitiven FPGA schon ein bisschen konsistenter und standardkonformer läuft als die Sachen von A/X/L (mag auch yosys sein), kann man sich u.U. besser auf das Kerngeschäft konzentrieren. Da hält auch ein Mandarin-Datenblatt nicht weiter vom Reverse-Engineering ab (und dabei lernt man am meisten). Finde es gut, dass Leute auch solche Exoten unter die Lupe nehmen. Denn Xilinx und Altera decken eine gewisse Nische kaum noch ab.
> Ich will jetzt keinen Streit vom Zaun brechen, aber ich fand halt den > integrierten SDRAM, die DSP's und ausrechend LUT's sowie die > standardisierte 40pol LCD Schnittstelle mit LED Backlight Stromsenke und Der Author hat ja auch eine Menge unterschlagen. Zum einen das was du da angefuehrt hast und dann auch dem im FPGA integrierten ADC. Interessant in dem Zusammenhang finde ich eher was anderes. Auf der einen Seite wuerde man meinen das kleine FPGA heute eher seltener gebraucht werden als frueher weil wir jetzt im Zeitalter von 600Mhz Mikrocontroller leben. Auf der anderen Seite gruenden sich gerade in China fuenf(!) neue Firmen die kleine FPGAs bauen? Was passiert da das komplett an uns vorbei geht? Olaf
Fitzebutze schrieb: > Fpgakuechle K. schrieb: >> Diese China-FPGA's entsprechen dem hiesigen Stand vor 20 Jahren, also >> Spartan-3/6 -> >> > > Nur, dass sie etwas stromsparender sind. Das weiss man nicht, weil das meines Wissens bisher kein Labor nachgemessen hat (Angaben oben sind google). Ferner sind SRAM-basierte FPGA ohnehin der falsche Ansatz, wenn es ums Stromsparen geht.
Fpgakuechle K. schrieb: > Ich frage mal ganz unbedarft: "Was erwartest Du?" > BRNE heisst doch "branch if Not Equal" Na dass bei der Subtraktion mit SBIW bei Result = 0 auch das Z-Flag gesetzt wird, damit BRNE entsprechend reagieren kann. Vielleicht hatte ich mich diesbezüglich nicht so verständlich ausgedrückt. Aber wie der Befehl BRNE funktioniert weiß ich schon ;) Ich habe den Bug übrigens fixen können. Es lag an dem Registerfile. SBIW (ein Word Befehl) arbeitet nun korrekt. Nun macht der Interrupt Controller Probleme. Das heißt, wenn ein Interrupt auftritt wird der Registerinhalt des in der normalen Routine (während des Interrupts) zu bearbetenden Registers nach dem Interrupt nicht wieder hergestellt. Der PC der normalen Routine wird korrekt auf den Stack gespeichert und auch von da wieder abgeholt. Es wird also nach dem Interrupt auch an der rausgesprungenen Stelle das Programms an der korrekter Stelle wieder fortgesetzt.
Olaf schrieb: >> Ich will jetzt keinen Streit vom Zaun brechen, aber ich fand halt den >> integrierten SDRAM, die DSP's und ausrechend LUT's sowie die >> standardisierte 40pol LCD Schnittstelle mit LED Backlight Stromsenke und > > Der Author hat ja auch eine Menge unterschlagen. Zum einen das was du da > angefuehrt hast und dann auch dem im FPGA integrierten ADC. Der wie der XADC in Xilinx und der ADC in Max10 wegen schlappen 1MSps nur zu Board Spannungs Monitoring taugt, aber nicht für DSP. > Auf der anderen Seite gruenden sich gerade in China fuenf(!) neue Firmen > die kleine FPGAs bauen? Was passiert da das komplett an uns vorbei geht? Ist halt wieder ein Sack Reis der China umkippt. Steffen H. schrieb: > Trotzdem passen diese beiden Beiträge wohl besser in diesen > Tread hier: > Beitrag "Sipeed Lichee Tang FPGA mit RISC-V Core aus China unter 20€" Sehe ich genauso, daher hier: Over und out für die China-Blabla
> Der wie der XADC in Xilinx und der ADC in Max10 wegen schlappen 1MSps > nur zu Board Spannungs Monitoring taugt, aber nicht für DSP. Gibt es denn ueberhaubt irgendeinen FPGA der sagen wir mal 50 bis 100Ms mit einem internen ADC kann? Soweit ist weiss liegen die alle unter 1MSp oder gleich im Gsample-Bereich. Olaf
Fpgakuechle K. schrieb: > Das weiss man nicht, weil das meines Wissens bisher kein Labor > nachgemessen hat (Angaben oben sind google). Ferner sind SRAM-basierte > FPGA ohnehin der falsche Ansatz, wenn es ums Stromsparen geht. Ich weiss es. Man sehe sich mal die gut reverse-engineerten ICE40 an. In die Richtung geht es auch bei den meisten chinesischen Entwicklungen, die mir untergekommen sind. Mehr sage ich dazu nicht. Olaf schrieb: > Was passiert da das komplett an uns vorbei geht? Naja. Das Knowhow hätten wir hier in Europa auch, aber die US-dominierte Altherren-Lobby scheint im Torpedieren von Innovationen recht erfolgreich, so dass man sich hier auch in den akademischen Gefilden wenig traut, mal etwas anderes zu probieren (Es gibt ein paar wenige Ausnahmen). So kommt die kritische Masse an Innovationsballung und entsprechender Szene hierzulande halt nicht zusammen (gegenüber Shenzhen).
> Naja. Das Knowhow hätten wir hier in Europa auch, aber die US-dominierte > Altherren-Lobby scheint im Torpedieren von Innovationen recht Es ist nicht das Knowhow was mich erstaunt. Es wundert mich das es da ploetzlich einen Markt fuer solche Devices gibt. Es nehmen doch nicht fuenf Leute ploetzlich Kohle in die Hand um dafuer eine Firma aufzumachen wenn nicht vorher klar ist das man das was verkaufen kann. Olaf
Irgendwo stand im Zusammenhang mit einem Anlogic-FPGA ein Name eines chinesischen Messgeräteherstellers, ich meine Siglent. Dort finde ich aber eher "Xilinx".
Ich habe den Fehler gefunden. Grob gesagt wusste ich schon, dass irgendwas mit dem RAM, Stackpointer + call oder reti nicht stimmten konnte. Das hat jetzt tatsächlich 2 Tage debugging gedauert um herauszufinden, daß es nur am falsch benutzem WE write enable des Block RAM lag.. Echt schei.. wenn eine ausführliche Dokumentation und Timings zu den Blockram fehlt. Naja, nun funzt es jedenfalls. Also im Moment läuft der Mega32 core/alu mit einem Hardcoded RTC, der aller 1ms einen Timer0 OVF Interrupt generiert und der PortB. Wobei beim PortB PB0..PB2 wiederum auch hart als Ausgang intern auf die RGB Led verschaltet wurde. Ich würde jetzt gerne nach und nach mehr io-module zuschalten. Und da bin ich über den Bus-Demux gestolpert. Den versteh ich irgendwie nicht.
Gibt es sowas wie einen asynchronen demux? Also ohne select? Hier mal das Beispiel aus dem Mega Softcore:
1 | `timescale 1ns / 1ps module io_bus_dmux # ( parameter BITS_PER_BUS = 8, parameter NR_OF_BUSSES_IN = 1 )( input [(NR_OF_BUSSES_IN * BITS_PER_BUS) - 1 : 0]bus_in, output reg[BITS_PER_BUS - 1:0]bus_out );reg [NR_OF_BUSSES_IN - 1 : 0]tmp_busses_bits;integer cnt_add_busses;integer cnt_add_bits; always @ * begin for(cnt_add_bits = 0; cnt_add_bits < BITS_PER_BUS; cnt_add_bits = cnt_add_bits + 1) begin: DMUX_IO_DATA_BITS for(cnt_add_busses = 0; cnt_add_busses < NR_OF_BUSSES_IN; cnt_add_busses = cnt_add_busses + 1) begin: DMUX_IO_DATA_BUSES tmp_busses_bits[cnt_add_busses] = bus_in[(cnt_add_busses * BITS_PER_BUS) + cnt_add_bits]; end bus_out[cnt_add_bits] = |tmp_busses_bits; end endendmodule |
Kann dazu irgendwer was sagen? Werden die alle nur parallel da dran gehangen und die NR_OF_BUSSES erhöht? Über Google habe ich zu asynchron Mux/Demux nichts finden können?! Wie werden eigentlich die ganzen Module (Usart, Timer, PIOs, SPI,.. ) an den Datenbus gehangen?
Ich steig durch dein Code-Snippet nicht wirklich durch gerade.. Aber Multiplexer sind ja generell erstmal nur eine kombinatorische Schaltung (wenn kein Register dahinter hängt)?! Von anderen Soft-Cores/SoCs kenne ich das so, dass die ganzen IO-Units nur eine Ausgabe !=0 machen wenn sie per Adresse selektiert sind. Die ganzen Ausgänge jeder einzelnen Unit werden dann verodert und das Ergebnis geht dann als Lese-Daten-Bus zur CPU zurück.
Olaf schrieb: >> Der wie der XADC in Xilinx und der ADC in Max10 wegen schlappen > 1MSps >> nur zu Board Spannungs Monitoring taugt, aber nicht für DSP. > > Gibt es denn ueberhaubt irgendeinen FPGA der sagen wir mal 50 bis 100Ms > mit einem internen ADC kann? Soweit ist weiss liegen die alle unter 1MSp > oder gleich im Gsample-Bereich. > > Olaf Jep, die RFSoCs von Xilinx koennen das: https://www.xilinx.com/products/silicon-devices/soc/rfsoc.html Gehen bis maximal 10 GSPS bei 6 GHz Bandbreite.
> Jep, die RFSoCs von Xilinx koennen das:
Ja ich weiss. Aber die sind ja dann wieder das andere extrem.
Nicht das ich jetzt geschaut haette, aber vermutlich faellt man
dann beim Preis in Ohnmacht.
Aber eine gesunde Mittelklasse, sagen wir mal so um 100Ms scheint
es nicht zu geben.
Olaf
Olaf schrieb: > Aber eine gesunde Mittelklasse, sagen wir mal so um 100Ms scheint > es nicht zu geben. So, wie ich das verstanden habe, gibt es optimierte Fertigungsprozesse für ADC (analog), FPGA (digital) und Speicher, die zueinander 'inkompatibel' sind. Bei den RFSoc wird intern "silicon interposer technology" verwendet, um die Einzeldies zu verbinden. Duke
Duke Scarring schrieb: > So, wie ich das verstanden habe, gibt es optimierte Fertigungsprozesse > für ADC (analog), FPGA (digital) und Speicher, die zueinander > 'inkompatibel' sind. 'Inkompatibel' gerade nicht, aber eben nicht auf einen Die/Wafer gleichzeitig anwendbar, jedenfalls nicht kostenoptimiert. Die unterscheiden sich eben schon mal in der Anzahl der metal layer (Verdrahtungsebenen) da braucht Logik mehr als Speicher. Und bei Analog wird viel mit Messung, abgleich gearbeitet, während es bei digital egal ob ein paar mV mehr oder weniger solange die Schaltschwelle passt. Und Kosten heisst hauptsächlich yield, und wenn man Speicher mit 95% Ausbeute bauen jann, analog aber nur mit 50%, dann sackt die Ausbeute für ne Analog-Soc Kombi auf unter 50% und macht so die Logik teurer.
lexi schrieb: > Die ganzen Ausgänge jeder einzelnen Unit werden dann verodert und das > Ergebnis geht dann als Lese-Daten-Bus zur CPU zurück. Das würde ja zu dem hier passen:
1 | bus_out [cnt_add_bits] = | tmp_busses_bits; |
Medium "ADC/DACs" kann man doch per Adapter-Board anschließen. Oder man macht sich selber eine Platine. Was bringt es diese in den FPGA zu packen? Die Vielfalt der Bauteile ist ziemlich hoch (Conversion time, Sample Rate, bits, ENOB, Spannungsbereich, ..). Die FPGA-Nachfrage wird dann vermutlich zu gering sein im Einzelnen.
< Was bringt es diese in den FPGA zu packen? So manchen schmerzt es ja schon, die wirklich wenigen Pins eines seriellen Configflashs extern anzuschliessen. Wenn man die "verbratene" Flaeche dafuer im Floorplaner ansieht, und einem vielleicht ein paar LEs/Multiplizierer fehlen. Der grosse Renner ist der LPC4370 mit seinen 80 MSPS/12 bit auf dem Markt ja auch nich geworden. Kein FGPA aber ein 3 Core ARM. Mit den mickrigen 1 MSPS kann man nun eigentlich gar nichts anfangen.
... schrieb: > Mit den mickrigen 1 MSPS kann man nun eigentlich gar nichts > anfangen. Ich denke mal, dass die On-Chip-Temperaturmessung und die optionale Lüftersteuerung wohl die Hauptanwendung dafür ist. Irgendein Power-Level dazu messen, ist dann Bonus der mit abfällt.
Tim schrieb: > ... schrieb: >> Mit den mickrigen 1 MSPS kann man nun eigentlich gar nichts >> anfangen. > > Ich denke mal, dass die On-Chip-Temperaturmessung und die optionale > Lüftersteuerung wohl die Hauptanwendung dafür ist. naja, in CNC bereich gibt es etlich langsame AD-Wandler (Kraftmessung per DMS bspw). Aber da nimmt man eher einen µC statt einen FPGA zur Auswertung. In der normalen (nicht-bildgebenden) Medizintechnik muss auch nicht sonderlich schnell sein, beispiel EKG: https://www.nutsvolts.com/magazine/article/February2017_Build-ECG-EKG-Unit
> Das würde ja zu dem hier passen: >> bus_out [cnt_add_bits] = | tmp_busses_bits; Ja, das sieht tatsächlich so aus - wobei mein Verilog doch etwas eingerostet ist...
Das war es tatsächlich. Mal als kurzes Update, ich hänge jetzt gerade am TWI fest. Diesen versuche ich jetzt gerade zu implementieren. Denn dieser funktionierte im Repositorie nicht. Also PortB bis PortF, inclusive tongeln über set PIN sowie der Uart funktionieren schon.
:
Bearbeitet durch User
Welche Repository nutzt du denn genau?
> Denn dieser funktionierte im Repositorie nicht.
Hast du kein "stabiles" Release runtergeladen oder ist der Core noch im
Alpha-Stadium?
lexi schrieb: > Hast du kein "stabiles" Release runtergeladen oder ist der Core noch im > Alpha-Stadium? Angeblich "Beta" Hierbei handelt es sich um den ArduFPGA. Zu finden in Opencores: https://opencores.org/projects/ardufpga_ice40up5k GitHub: https://github.com/dev-board-tech/hdl-core-common Beispiel: https://github.com/dev-board-tech/hdl-core-mega-xmega Einfach mal nach Arduboy oder ArduFPGA suchen. Das Projekt ist ziemlich frisch. Das Projekt dazu ist faszinierend. Aber der I2c / TWI wurde in keinem einzigen Beispiel oder Projekt eingebunden. Ich habe den Autor schon daraufhin kontaktiert. Ich versuche ja nur den ATmega32U4 in eine Anlogic Egle4 FPGA zu portieren.
Steffen H. schrieb: > Ich versuche ja nur den ATmega32U4 in eine Anlogic Egle4 FPGA zu > portieren. Was ist eigentlich der Sinn der Übung? Lernen? Spielen? oder doch ein praktischer Einsatzzweck?
Per schrieb: > Was ist eigentlich der Sinn der Übung? Lernen? Spielen? Sicherlich soll das Lernen und Verstehen im Vordergrund stehen. Und eventuell braucht man mal eine kleine CPU im FPGA die eine bestimmte Aufgabe lösen kann. Dann geht es allerdings nichtmehr so um eine Nachbildung eines bestimmten Prozessors. Ich habe den ATmega nur deshalb gewählt, da ich das Programm dafür einfach wie gewohnt mit dem Atmel Studio erstellen kann. Möglicherweise kann ich den core dann als Fontgenerator in meinem LCD Controller einsetzen.
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.