Re: Historische Breitbandaufzeichnungen von AM-Bändern (Projekt Cohiradia)
Ich habe die Synthese für die FPGA Familien verschiedener genannter Boards durchgeführt. Am unproblematischsten war das für die Intel/Altera-Seite, da die HDL-Dateien dafür direkte Anweisungen enthalten. Typische Vertreter bei Trenz/Elektorboards sind der Cyclone IV den ich auch habe, V und 10.
Nach der Synthese war der Bitstream bereit um auf den FPGA geladen zu werden.
Beim Versuch mit dem GoWin war die Sache nicht so einfach, aber mit Hilfe der KI dennoch leicht zu meistern. Ich will meine Fallstricke aufzeigen und wie die KI das erfolgreich für mich gelöst hat.
Das Problem, das Synthesetool Yosys für GoWin war noch auf Verilog-2005 eingestellt, die Erweiterung benutzt SystemVerilog, Yosys muss man dies über -sv mitteilen.
ERROR: no valid mapping found for memory duc_top.baseband_sharpener_inst.coeff_rom_5
Die Erklärung:
Die Ursache: Altera/Intel-spezifische Attribute auf einem Gowin FPGADer Fehler no valid mapping found for memory entsteht, weil der Code in der baseband_sharpener.v stark für Intel/Altera FPGAs optimiert wurde. Dort steht bei den Koeffizienten-ROMs (und auch bei den Ringpuffern) das Attribut (* ramstyle = "M9K" *).
Die Lösung: Attribute anpassen
Öffne die Datei baseband_sharpener.v und suche nach Zeile 60 (im Abschnitt 2. DISKRETE KOEFFIZIENTEN ROMs).
Ersetze diesen Block:
(* ramstyle = "M9K" *) reg signed [15:0] coeff_rom_0 [0:63]; (* ramstyle = "M9K" *) reg signed [15:0] coeff_rom_1 [0:63]; (* ramstyle = "M9K" *) reg signed [15:0] coeff_rom_2 [0:63]; (* ramstyle = "M9K" *) reg signed [15:0] coeff_rom_3 [0:63]; (* ramstyle = "M9K" *) reg signed [15:0] coeff_rom_4 [0:63]; (* ramstyle = "M9K" *) reg signed [15:0] coeff_rom_5 [0:63];
Durch diesen Block:
(* rom_style = "logic" *) reg signed [15:0] coeff_rom_0 [0:63]; (* rom_style = "logic" *) reg signed [15:0] coeff_rom_1 [0:63]; (* rom_style = "logic" *) reg signed [15:0] coeff_rom_2 [0:63]; (* rom_style = "logic" *) reg signed [15:0] coeff_rom_3 [0:63]; (* rom_style = "logic" *) reg signed [15:0] coeff_rom_4 [0:63]; (* rom_style = "logic" *) reg signed [15:0] coeff_rom_5 [0:63];
Damit sagst du Yosys explizit: "Vergiss die Block-RAMs, baue diese kleinen Konstanten-Tabellen einfach aus normalen Logik-Gattern zusammen."
Weiter oben in der Datei werden auch die echten Speicher (ram_i_a_0 etc.) mit (* ramstyle = "M9K" *) deklariert. Meistens ignoriert Yosys das bei echten RAMs (mit Schreib-Port) elegant und mappt sie automatisch auf die Gowin-eigenen "BSRAMs". Solltest du dort gleich den nächsten Fehler bekommen, ändere das M9K dort einfach in den Yosys-Standard (* ram_style = "block" *). also von
(* ramstyle = "M9K" *) reg signed [15:0] ram_i_a_0 [0:127]; // ... bis ... (* ramstyle = "M9K" *) reg signed [15:0] ram_q_b_5 [0:127];
nach
(* ram_style = "block" *) reg signed [15:0] ram_i_a_0 [0:127]; // ... bis ... (* ram_style = "block" *) reg signed [15:0] ram_q_b_5 [0:127];
Dadurch sagst du Yosys ganz generisch, dass es hier echtes Block-RAM verwenden soll, welches dann passend auf die Gowin-eigenen BSRAMs gemappt wird.
Proaktiver Fix: Weitere Altera-Attribute entfernen
Da wir gerade beim Beseitigen von Altera-Spezialitäten sind, ziehen wir direkt noch zwei weitere Dateien glatt, die dir andernfalls gleich im nächsten Build-Versuch um die Ohren fliegen:In shared_sine_rom.v: Hier steht für das physische ROM (* ramstyle = "M4K" *) reg signed [15:0] sine_quarter [0:1023];. Ändere das M4K (ein alter Altera-Speichertyp) in das allgemeine (* rom_style = "block" *) um.
In sync_fifo.v: Dort wird für den Speicher das Attribut (* ramstyle = "no_rw_check" *) verwendet. Dieses Attribut kannst du ersatzlos löschen, sodass dort einfach nur noch reg [DATA_WIDTH-1:0] ram [0:FIFO_DEPTH-1]; steht.
Speichere die Dateien ab und feure dein Synthesescript noch einmal ab.
!!!
Fotos, Grafiken nur über die
Upload-Option des Forums, KEINE FREMD-LINKS auf externe Fotos.
!!! Keine
Komplett-Schaltbilder, keine Fotos, keine Grafiken, auf denen
Urheberrechte Anderer (auch WEB-Seiten oder Foren) liegen! Solche Uploads werden wegen der Rechtslage kommentarlos gelöscht!
Keine Fotos, auf denen Personen erkennbar sind, ohne deren schriftliche Zustimmung.
Den Beitrag-Betreff bei Antworten auf Threads nicht verändern!
Re: Historische Breitbandaufzeichnungen von AM-Bändern (Projekt Cohiradia)
Auch die Synthese für GoWin FPGA lief dann erfolgreich ab.
Provisorisch verkabelt konnte ich runtergeladenen Mittelwellenaufzeichnungen bereits frei im Kurzwellenraum platzieren.
In der Software ist der I/Q Modus auszuwählen und der Parameter für die Shiftfrequenz anzupassen. Die Bits des DACs sind nicht mehr frei einstellbar. Der Bus vom Host zum FPGA läuft jetzt immer auf 16 Bit. Die Bitanzahl des DACs muss man jetzt im Topmodul der Erweiterung einstellen und dann die Synthese und Programmierung neu anstarten. Die DAC-Werte sind dann im FPGA und über cst, tcl Datei fest verdrahtet.
Grüße Roland
In Erweiterung des Versuchs, habe ich alle Tests auf dem Raspberry Pi 4 wiederholt. Dieser wurde direkt mit 1 Gbit an den Router angeschlossen und eine Netzwerkbelastung über alle Sendemodes in einer Tabelle eingetragen. Ich habe vermerkt welches System welchen Frequenzbereich erreichen kann. Der eindeutige Sieger ist hier der I/Q Modus, nur er bringt alle Freqzenzbereiche auf alle Grundsysteme und schont dabei das Hausnetzwerk.
Re: Historische Breitbandaufzeichnungen von AM-Bändern (Projekt Cohiradia)
WalterBar:Hallo Roland,
ob sich Cohiwizard und Cohiradiastreamer "beissen" kann ich nicht beurteilen, weil ich das Programm nicht programmiert habe.
Ich kann aber sagen, dass Hermann versuchen wird, Kernteile von Bernhards Codes in den COHIWizard einzubauen, da er die extrem effiziente liquiddsp Library nutzt. Das wird aber nicht vor Ende der HamRadio passieren, an der Cohiradia auf dem Stand der GFGF vertreten sein wird.
Gruss Walter
Hallo Walter,
es scheint sich in dieser Richtung etwas zu tun. Bei einem neuerlichen Download gibt es Anzeichen das Herr Scharfetter mit der Radiolab81 Entwicklergruppe eine Zusammenführung vorhaben. Im Code wird dies kommentiert und man erkennt Teile der liquiddsp darin. Die genauen Pläne kenne ich nicht. Ich meine das auch das neue I/Q Streaming nur noch eine Frage der Zeit sein wird.
Von Herrn Dünk erhielt ich eine Vorabversion zum Test, die im Grunde neben smisdr und parliosdr eine dritte SDR-Sendergruppe darstellt. Man verzichtet hier auf den Raspberry oder ESP32. Über ein Ethernetmodul, LAN8720 , DP83848, beziehungweise den Realtek der im Tang Primer 20k verbaut ist, wird der I/Q Datenstrom mit den eingebetteten Steuersignalen unmittelbar und ohne Umwege in das FPGA Modul gesendet. Herr Dünk berichtete das noch weitere FPGA Board mit fertiger Ethernethardware getest werden. Diese sollen im Handel für 100 Euro erhältlich sein. Zunächst ist Sendebetrieb mit GR oder CohiradiaStreamer möglich. Die Skalierung des DAC geht von 8 bis 14 Bit. Empfang wird es später geben wenn es eine Nachfrage für diese Funktion geben sollte.
Auf meiner Seite hat sich mittlereile das PMOD-Format für die Ausgabekarten etabliert. Meine einfachsten Testkarten mit 8 Bit habe ich mit Einzel-PMOD Buchse versehen, für größere DAC nehme ich einen zweiten PMOD Anschluss hinzu. Passende Dual-Kabelbäume sind günstig zu bekommen, da mit PMOD auch andere Zusatzboards verbaut werden. Nach meinen bisherigen Erfahrungen damit, sind diese Anschlüsse noch für 50 MegaSamples gut zu gebrauchen.
Re: Historische Breitbandaufzeichnungen von AM-Bändern (Projekt Cohiradia)
Hallo Roland,
seit der Abschaltung der BBC auf LW hatte ich keinen Kontakt zum Hermann mehr. Das ist aber ein gutes Zeichen. Ich bin mir sicher, dass er das Projekt, das er ja im Wesentlichen betreibt, weiter vorantreiben wird. Leider hat er Defizite in der C++ Programmierung, sodass es dauern wird und weitere Optimierungen braucht.
Ich kann da überhaupt nicht mitreden, weil ich der Generation "Lochkarten stanzen (Fortran 4, QBasic)" angehöre. Da staune ich immer wieder, was heute so geht.
Mein Anteil ist das Austesten in Windows 10/11 vor der Veröffentlichung. Soweit ich weiss hat man sich in Graz ganz auf Linux verlegt.
Re: Historische Breitbandaufzeichnungen von AM-Bändern (Projekt Cohiradia)
Vielen Dank Walter für diesen Zwischenbericht. Ich habe meinerseits nun auch die Variante mit Ethernet - FPGA direkt am Laufen und möchte selbst noch eine Änderung an einem bestehenden SDR vorschlagen, welches Herr Scharfetter bereits in seiner Software verwirklicht hat. Es handelt sich dabei um Adalm 2000, ein Labormessplatz mit Digial und Analog I/O.
Er testet es auf der Cohiradiawebseite und nennt ein paar Einschränkungen die das System hat, wenn es nicht modifiziert wird.
Wie beim fL2k muss die PC Seite die komplette Hochfrequenz aus den I/Q Dateien vorberechnen und diesen massiven Datenstrom über das Netzwerk senden. Das geht mit dem HDL-Modul was die radiolab81 Leute gebaut haben einfacher, dazu muss das ursprüngliche Design durch einen neuen Bitstrom umprogrammiert werden.
Von der Referenz-Architektur braucht man eigentlich nur:
PS7 (Takterzeugung, DDR, evtl. AXI I2C/SPI falls man den AD9963 noch über SPI konfiguriert) AXI_AD9963, aber nur die TX-Seite (RX/ADC-Pfad kannt man zum aktuellen Stand komplett rausnehmen)
Fliegen raus: AXI_ADC_TRIGGER, UTIL_VAR_FIFO/UTIL_EXTRACT, AXI_ADC_DECIMATE, AXI_LOGIC_ANALYZER, die komplette Scope-DMA-Kette und die zweite AWG-DMA (man braucht nur einen DMA-Pfad Richtung PL). AXI_DAC_INTERPOLATE ersetzt man direkt durch das angepasste Topmodul der DUC Gateware aus dem smiSDR Projekt.
ARM → AXI DMA (Port 1234) Das ist reine Linux-Seite: ein kleiner TCP-Server liest auf Port 1234, schreibt die eingehenden Bytes 1:1 (bestehendes In-Band-Protokoll bleibt unverändert) in einen per mmap gemappten, physisch zusammenhängenden DMA-Puffer und stößt die AXI-DMA-IP an. Danach erfolgt das Mapping auf smi_rx_16bit. Es wird mit einem Modul ein virtueller SMI Parallelbus mit In Band Decoder dargestellt. Dann kommt die DUC Chain aus dem smiSDR Projekt. Entweder erstellt man eine neue CLK Domain und macht ein letztes Upscaling auf den DAC oder man rechnet die DUC Chain nativ für die CLK Domain des Adalm 2000 aus. Die radiolab81 Leute haben dafür eine Software auf der Projektseite. Das komplette Neudesign welches der Bitstream beim Starten des Adalm 2000 anlegt, folgt diesem Pfad.
Die passenden Bausteine habe ich mit Claude ausformulieren lassen.
Das komplette Design lässt sich in Vivado synthetisieren und passt in den FPGA.
- der Adalm 2000 wird als Ethernetdevice erkannt und kann mit einer IP angesprochen werden (konnte er schon) - der Adalm 2000 empfängt jetzt nativ I/Q Daten mit 250 ks, 500ks , 1250 ksps wie smiSDR und parlioSDR - der Adalm 2000 kann intern Upscaling und Mischung machen bis auf 75 MHz, die PC Seite muss nur die I/Q Daten bereitstellen, vergleich Grundlast oben - der Adalm 2000 benutzt das Inband-Signaling und kann mit GNU Radio und den Encoderbaustein oder dem Cohiradiastreamer benutzt werden - keine Notwendigkeit ein FPGA Nachsatz und DAC Karten aufbauen zu müssen - für Zukunft hat er einen ADC bereits verbaut - mit 250 Euro teuer als alle anderen Alternativen, dafür fertig aufgebaut. Gut/Schlecht ?
Ich habe über Kleinanzeigen einen gebrauchten für 65 Euro erwerben können und hoffe er kommt bei mir heil an. Dann können Praxistests erfolgen.
Anmelden
