Beim Durchstöbern des Verkaufs-Themen-Bereiches kam mir gerade folgende
Idee:
Beitrag "Re: [V] Xilinx Artix-7 A200T AC701 FPGA Eval Kit"
Gibt es eine tool chain, welche eine hardware-Co-Simulation von
Verilog-HDL-Programmen direkt auf einer fpga-Plattform ermöglicht?
Soweit ich es kenne, geht das nur mit kommerziellen tools der
Hersteller?
Ich würde gerne vorhandene und neu zu bauende Verilog-Beschreibungen in
Echtzeit / möglichst schnell simulieren. Wenn machbar auch C-Programme
übersetzen lassen.
Joe F. schrieb:> Warum lässt du nicht einfach den Code auf dem FPGA ausführen?
Weil z.B. Modelle der Umgebung einer Schaltung und die auftretenden
Szenarien nicht herstellbar sind oder sich nicht ausführen / erzeugen
lassen, weil damit etwas kaputt gehen, oder GEfahr erzeugt werden kann.
Darüber hinaus gelten alle anderen Gründe, warum überhaupt simuliert
wird.
Man sollte auch nicht immer die intention infragestellen. Das, was ich
ohne Simulation machen kann, mache ich ohne.
Und das, was ohne HW-Beschleunigung machbar ist, mache ich natürlich. Es
ist aber eine Zeit- und Kostenfrage, ob ich 2min oder 20min warten muss,
bis ein Ergebnis kommt.
Gewisse Entwicklungen sind dann nicht machbar oder führen zu Kosten, die
das Produkt für Viele unerschwinglich machen.
Somit ist open source Simulation ohne extreme Kosten eine nachfragbare
Sache, finde ich.
Tobias N. schrieb:> hardware-Co-Simulation
Davon habe ich noch nichts gehört, und ich denke ich kenne zumindest das
Xilinx-Portfolio. D.h. Xilinx bietet sowas nicht an.
Ich kenne eine "Co-Simulation". Der Begriff kommt aus der HLS-Schiene
und bedeutet nichts anderes als eine Simulation der erzeugten Logik auf
dem PC (Modelsim/Questsim,XSim, etc).
Eine "hardware-Co-Simulation", die direkt auf einem FPGA läuft, ist mir
nicht bekannt.
daniel__m schrieb:> Eine "hardware-Co-Simulation", die direkt auf einem FPGA läuft, ist mir> nicht bekannt.
Ich meine das, was MATLAB darunter versteht, nämlich einen Algorithmus
nicht nur in MATLAB, als auf der CPU in C zu simulieren, sondern
parallel auch das bitgenaue Modell in integer. Und das eben a) in
hardware, um es zu beschleunigen und b) auch Software in C oder nicht
nur Verilog.
Möglicherweise ist der Begriff nicht gut gewählt.
@Tobias: Formuliere doch mal praezise aus, was du genau brauchst.
Es gibt einiges an OpenSource-Ansaetzen, aber du hast trotzdem die
Aufgabe, die Simulation mit Hilfe der Tools selber zu stricken.
Die mir bekannte Methode der Co-Sim mit Matlab reicht, das Modell gegen
die Implementierung zu verifizieren. Das ist aber a priori eine pure
SW-Simulation. Wenn du was wie Simulink brauchst, um richtig SW mit HW
'in the loop' zu simulieren, gibt's nix kostenloses.
Wenn MyHDL nicht gerade in einem katastrophalen Zustand waere, haette
ich das noch empfehlen koennen. Python ist fuer viele OpenSourceler 'das
bessere Matlab'. Damit mache ich auch (per netzwerkfaehige FPGA-nodes)
meine verteilte Co-Simulation/Implementierung von DSP-Pipelines.
daniel__m schrieb:> Davon habe ich noch nichts gehört, und ich denke ich kenne zumindest das> Xilinx-Portfolio. D.h. Xilinx bietet sowas nicht an.
Gab es mit ISM:
UG817
"ISim Hardware Co-Simulation Tutorial:
Accelerating Floating Point FFT Simulation"
Keine Ahnung, ob es das im Vivado auch noch gibt und ob bzw. welche
Lizenz dafür nötig ist.
Tobias N. schrieb:> Soweit ich es kenne, geht das nur mit kommerziellen tools der> Hersteller?
Sowas hab ich mir schon 'zu Fuß' gebaut:
- Puffer für Eingangswerte
- Puffer für Ergebnisse
- FSM um das DUT zu triggern
Und dann das Ganze vom PC aus über die serielle Schnittstelle gesteuert.
Je nach Datenaufkommen würde ich aber heute eine schnellere
Schnittstelle empfehlen.
Duke
Tobias N. schrieb:> Ich würde gerne vorhandene und neu zu bauende Verilog-Beschreibungen in> Echtzeit / möglichst schnell simulieren. Wenn machbar auch C-Programme> übersetzen lassen.
Nach dem was ich hier gelesen habe, klingt das für mich mehr nach dem
Wunsch "Verification in Hardware" zu machen als das, was unter
co-simulation (z. B. mit Renode, Verilator, Python/MyHDL oder Simulink)
verstanden wird.
Um beliebige HDL-Blöcke in Hardware zu verifizieren kann man z. B.
Testbenches schreiben die synthetisierbar sind. Dann lässt sich das
ganze (Testbench + Design) im Simulator simulieren und läuft auch mit
realer Geschwindigkeit im FPGA (an dem Punkt nenne ich das nicht mehr
Simulation).
Die synthetisierbare Testbench kann dann nette komplexere features haben
wie Kommunikation mit einem Entwicklungs PC etc. (Simulink nennt das
dann FPGA-in-the-loop
https://ch.mathworks.com/help/hdlverifier/fpga-in-the-loop.html?s_tid=srchtitle).
Mir ist bis jetzt kein Open Source Framework bekannt, dass diesen
Prozess direkt adressiert.
Open Source IP Blöcke wie z. B. eine USB Whishbone Bridge könnten aber
schon alles sein was du brauchst (Dein zu verifizierender Block braucht
dann natürlich ein Whishbone Interface oder einen Wrapper).
https://workshop.fomu.im/en/latest/
Am "höheren" Ende gäbe es sonst noch das:
https://www.missinglinkelectronics.com/images/files/papers/EW2016-Session18-MLE-PCIeOverIP_r09.pdf
Das ist zwar kaum OpenSource, aber das Konzept demonstriert, wie leicht
sich dann die Cores zwischen Sim und Syn austauschen lassen.
Auf die Weise kann man auch ein zunächst co-simuliertes System (z.B.
qemu und ghdl) in die Hardware migrieren. qemu steuert also einen aufs
Netzwerk exportierten "Virtuellen Bus" an, erst die Simulation, dann die
Hardware, und schliesslich packt man alles auf den SoC. Mit renode geht
das vielleicht noch eleganter/homogener.
Martin S. schrieb:> Wenn MyHDL nicht gerade in einem katastrophalen Zustand waere, haette> ich das noch empfehlen koennen.
Inwiefern ist MyHDL "gerade" in einem katastrophalen Zustand?
In Kuerze:
Insbesondere die VHDL-Konversion ist in einem inkonsistenten Zustand und
Fixes werden seit Jahren vernachlaessigt. Heisst, die aktiven Entwickler
arbeiten mit ihren eigenen Forks, die Fuehrung scheint sich ausgeklinkt
zu haben. Darum: Fuer (Python-)Anfaenger unter argem Vorbehalt.
