Hallo Leute, gibt es hier Erfahrungen mit RISC V Softcores? Wie kann man die verschiedenen Implementierungen mit einander vergleichen? Habt ihr schon welche in der Firma im Einsatz?
Newcomer of the year schrieb: > gibt es hier Erfahrungen mit RISC V Softcores? Ich habe mal mit dem PicoRV32 gespielt. Der läuft einfach, ist formal verifiziert und ist gut dokumentiert. Ließ sich gut integrieren. Newcomer of the year schrieb: > Wie kann man die verschiedenen Implementierungen > mit einander vergleichen? Indem du erstmal die gewünschte Metrik spezifizierst und dann danach vergleichst. Gibt ja ganz unterschiedliche Anforderungen an so eine CPU. Was interessiert dich denn?
Siehe auch: Beitrag "RISC-V (FPGA)" Bei den meisten Implementierungen siehts mit vernünfigen Debug-Schnittstellen (ICE) etwas mau aus. Wenn du aber nur einfache Hardware und keine komplexen Systeme dranflanschst, kann man ohne leben. Auch habe ich noch keine kompakte Variante gefunden, die die komprimierten Instruktionen unterstützt, damit ins FPGA etwas mehr Code reinpasst.
Fitzebutze schrieb: > Auch habe ich noch keine kompakte Variante gefunden, die die > komprimierten Instruktionen unterstützt, damit ins FPGA etwas > mehr Code reinpasst. Der PicoRV32 kann die, wenn man das einschaltet.
Fitzebutze schrieb: > Bei den meisten Implementierungen siehts mit vernünfigen > Debug-Schnittstellen (ICE) etwas mau aus. Habe ich auch so erfahren. Die Flows sind noch sehr frickelig. Testfähigkeit ist bei großen Sachen nicht zu vernachlässigen.
Wir arbeiten gerade an einem ASIC-Design, das auf der PULP-Architektur von der Uni Bologna/ETH Zürich aufbaut. Die Entwicklung (auch der Software) läuft auf einer FPGA-Implementierung. Wir haben PULP u.a. deswegen ausgewählt, weil die Architektur nach unserem Eindruck den höchsten Entwicklungsstand aller offenen RV-Implementierungen hat und schon in einigen ASIC-Projekten verwendet wird (z.B. GAP8 von Greenwaves). Es gibt ein SDK und eine Debug-Bridge für handelsübliche JTAG-Debugger (z.B. Olimex ARM-OCD). PULP ist unter aktiver Entwicklung, da arbeiten eine Menge Leute dran. Allerdings muss man sagen, dass PULP eher für ASIC gedacht ist, FPGA gehört nicht zu deren Zielarchitekturen. Was aber nicht heißt, dass es auf FPGA nicht läuft, es gibt auch eine Zynq-basierte Demo. Nach ein paar Anpassungen konnten wir es auf Virtex-FPGA implementieren (incl. FPU). Wenn Dich nur der nackte Core ohne das SoC-Gedöns interessiert und du den Rest selbst machen willst, dürfte die Anpassung ziemlich einfach gehen.
Weiß jemand von offenen Designs die inzwischen auch ein vernünftiges Debug- Interface für FPGAs bieten? Grundsätzlich existiert ja so etwas für den lm32 von Latticesemi. Müsste doch auch für eine RiscV gehen, oder bin ich da fehl gewickelt...
Moin, es gibt eine Debugger-Spec, die allerdings eine erhebliche Komplexitaet gegenueber der einfachen In Circuit Emulation aufweist. Meines Wissens ist ICE nicht ganz detailliert fuer den Risc-V definiert (warum, entzieht sich meiner Kenntnis, vermutlich weil jeder Chip-Hersteller sowieso seine eigene Suppe kochen will) Das naechste Problem ist, dass die JTAG-Interfaces (Primitiven heissen bei jedem FPGA-Hersteller anders) sich teils per FPGA-Familie sogar voneinander unterscheiden und da ein gehoeriger Wildwuchs herrscht. Man koennte natuerlich explizit auf einen user-definierte JTAG-TAP (test access port) gehen. Thema war schon einige Male auf dem Tisch, eine Loesung fuer Spartan3 und aufwaerts und Lattice ECPx/MachXO-Serien haette ich, aber (noch) nicht als OpenSource. Die basiert auch auf ICE und setzt den RiscV-Standard nicht um.
Guckt mal hier: https://workshop.fomu.im/ Fomu ist ein super kleines FPGA board das fast im USB Port verschwindet. Es ist so etwas wie die Zusammenfassung aller Open Source FPGA Entwicklungen der letzten >10 Jahre. - IP Cores werden mit dem Python basierten MiGen beschrieben. - SoC wird mit dem Python basierten LiteX zusammengesetzt (Whishbone als on-chip Bus) - Synthese mit Yosis, P&R mit NextPNR - RiscV Entwicklung läuft mit Mainline GCC - RiscV Debugging läuft über eine USB Whishbone Bridge an die dann GDB angestöpselt wird - Build Automatisierung mit Make
Entwickeln ohne Debugger (Emulator): RiscV Softwareentwicklung lässt sich zum Teil auch per Qemu bewerkstelligen, solange natürlich keine(oder einfach abstrahierbare) Interaktion mit externer Hardware/Systemen nötig ist. An der FOSDEM 2019 hat mir ein QEMU Entwickler (Arbeitet jetzt für einen der grossen FPGA Hersteller) erzählt, dass Verilator in der Lage ist, aus Verilog Code System C Modelle zu generieren. Damit hätten sie eine Demo zusammengebaut um in QEMU auch projektspezifische Hardware zu emulieren.
Christophz schrieb: > An der FOSDEM 2019 hat mir ein QEMU Entwickler (Arbeitet jetzt für einen > der grossen FPGA Hersteller) erzählt, dass Verilator in der Lage ist, > aus Verilog Code System C Modelle zu generieren. Damit hätten sie eine > Demo zusammengebaut um in QEMU auch projektspezifische Hardware zu > emulieren. Das geht ansich schon laengstens per Co-Simulation, allerdings kenne ich nur die VHDL-Seite. GHDL gibt mir hier ein Executable aus, was mit qemu, Python, oder sonst irgend einem Datenlieferanten uebers Netzwerk spricht. qemu adressiert z.b. ueber einen virtuellen Bus die Peripherie. Die Frage ist immer, wie schnell sowas laufen muss. Da koennte SystemC allenfalls einen Vorteil besitzen, aber wenn alles zyklengenau ist/sein muss schenkt sich vermutlich nichts. Ghdl ist soweit flott genug, dass man den gesamten RISC-V inklusiv Peripherie (virtueller UART, Ethernet, usw.) in die Loop stecken kann. Der regtest dafuer dauert halt ein paar Stunden.
Christophz schrieb: > dass Verilator in der Lage ist, > aus Verilog Code System C Modelle zu generieren. Damit hätten sie eine > Demo zusammengebaut um in QEMU auch projektspezifische Hardware zu > emulieren. Das ist ja ne coole Sache! Hast du weitere Infos dazu? Ich arbeite ziemlich intensiv mit Verilator, und eine Anbindung an QEmu um RV-Software im selben Modell zu emulieren wäre ja wie Ostern ind Weihnachten auf einmal. Im Moment simulieren wir ein RTL-Modell vom RV mit, aber das ist ein ziemlicher Overhead.
Ich denke, dass es diese Demo ist, von der er erzählt hatte: https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842109/QEMU+SystemC+and+TLM+CoSimulation
Strubi schrieb: > Das geht ansich schon laengstens per Co-Simulation, allerdings kenne ich > nur die VHDL-Seite. GHDL gibt mir hier ein Executable aus, was mit qemu, > Python, oder sonst irgend einem Datenlieferanten uebers Netzwerk > spricht. qemu adressiert z.b. ueber einen virtuellen Bus die Peripherie. @Strubi: Hast du hierzu weitere Informationen oder sogar ein Tutorial? Alles was ich gefunden hatte waren ältere Diskussionen mit toten Links auf deinen alten Blog (tech.section5.ch/...). Ist diese Methode mit Mainline Qemu/GHDL möglich?
Hi Christoph,
Mit GHDL mainline, ja. Du brauchst nur die ghdlex-Erweiterung, die gegen
das ausgegebene Simulations-Executable ('ortho'-Variante, nicht 'mcode')
gelinkt werden muss:
https://github.com/hackfin/ghdlex
Die stellt den virtuellen Bus per TCP/UDP Socket zur Verfuegung. Auf
Client-Seite (qemu) braucht man einen entsprechenden Bus-Wrapper, der
Zugriffe auf den entsprechenden Adressbereich mit der Simulation
kommuniziert. Das ist leider nicht in 'mainline'.
Tutorials in dem Sinne gibt's nicht, aber einen Docker-Container, der
zumindest fuer einen neo430 automatisch den ganzen Kram baut.
Sonst findest du hier noch etwas Info:
https://section5.ch/?s=virtual+chip
Der virtuelle neo430 laeuft im Prinzip auch online in einem
Docker-Playground. Nur die Traces kann man da nicht anschauen.
Das ganze noch fuer den RISC-V zu machen ist dann was fuer die kalten
Wintertage..
:
Bearbeitet durch User
Moin, fuer die kalten Wintertage hat's nicht mehr gereicht - der Vollstaendigkeit halber: Meinen RISC-V-Prototypen habe ich mal als VHDL-Ausgabe eingecheckt zwecks kontinuierlicher Verifikation gegen die aktuelle Quasi-Metrik der riscv/riscv-tests. Ich weiss noch nicht, ob das dann als 'compliant' gilt, soll mal nur als Beispiel dienen. Weiteres siehe https://github.com/hackfin/MaSoCist. Im Prinzip wird dabei ein 'make all test' aufgerufen, was so mehr oder weniger alles automatisch zieht und baut. Schliesslich wird aus $MASOCIST/test/virtual_riscv die Simulation gestartet und das Pythonscript (emulation.py) durchgefahren. Im groben bedient das den gesamten Setup mit virtuellem RAM, Emulation per Test Access Port, usw, d.h. auf das quasi virtualisierte SoC-Board wird ein riscv-test runtergeladen, und an den Breakpoints die korrekte Funktion ueberprueft. Da das ganze recht komplex geworden ist, gilt: Use the docker container, read the source, Luke :-) Ahja, und so zum Spass: man kann per 'make run-pyrv32' auch die Simulation mit einem virtuellen Terminal laufen lassen und mit der einfachen bare-metal shell (die wirklich zyklengenau auf dem Soft-Core mitsimuliert wird) quatschen, z.B. virtuelles SPI-Flash (von der FMF.org) ansteuern. So laesst sich also eine komplette Hardware und Software in die CI packen.
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.