Forum: FPGA, VHDL & Co. RISC V Softcore Erfahrungen


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Newcomer of the year (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Fitzebutze (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Tim (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Vancouver (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Fulfisk (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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...

von Martin S. (strubi)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Christophz (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Christophz (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Strubi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Vancouver (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Christophz (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Christophz (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Martin S. (strubi)


Bewertung
0 lesenswert
nicht lesenswert
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
von Strubi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.