RISC-V (FPGA)

OP #5196429
Lesenswert?

Hallo,

arbeitet jemand mit einer RISC-V IP?

Mit welcher und warum?
https://github.com/skordal/potato
https://github.com/cliffordwolf/picorv32
https://github.com/SpinalHDL/VexRiscv
...

Nun hat man die Auswahl, nur was sollte man nehmen?

Zeichnet sich bereits eine Dominanz bei den IPs ab?
(Firma: SEGGER) #5242915
Lesenswert?

Wir benutzen den Kram von SiFive, die sind auch sehr stark in dem 
Bereich vertreten. Die IP nennt sich SiFive E31 RISC-V Core IP FPGA Eval 
Kit. Damit konnten wir relativ einfach das embOS auf RISC-V portieren: 
https://www.segger.com/products/rtos/embos/supported-cores-compiler/sifive/risc-v/embos-riscv-es/#tab-38577-1

Daher sind wir ganz gut in dem Thema drin. Wer also Fragen hat, dem 
helfen wir gerne weiter.
OP #5244483
Lesenswert?

Danke für die bisherigen Beiträge/Vorschläge.

Weltbester FPGA-Pongo schrieb im Beitrag #5244402:
> @Lars: Was möchtet ihr mit der RISC genau bauen?

Die Gedanken hinter meiner Eingangsfrage sind abstrakter. Erklärung:

Im Moment schreibe ich für Altera/Intel. Bzgl. eines 32-Bit Softcores 
hätte ich die Entscheidung: ZPU vs. NIOS II. Diesbezüglich ist meine 
Entscheidung NIOS II.

Hinsichtlich Risc-V vs. NIOS II fällt die Entscheidung nicht so 
eindeutig aus. Dh, sollte ich in Risc-V Aufwand investieren?

Viele Implementierungen sind nett, aber es reist mich noch nicht richtig 
mit, zB.: "INIT-code" beta, Architekturentscheidungen. Selbst habe ich 
mit meiner eigenen Architektur (für andere Zwecke) genug zu tun. Daher 
tue ich mich schwer, nun in eine RISC-V-Implementierung xy zu 
investieren, die eventuell 10 Monate später mangels allgemeinem 
Community-Interesse wieder untergeht.

Es ist eben sehr viel Bewegung in der Sache, was ja prinzipiell gut ist.

https://www.youtube.com/watch?v=Zo3ldgU3ytM
#5245659
Lesenswert?

Lars R. schrieb:
> investieren, die eventuell 10 Monate später mangels allgemeinem
> Community-Interesse wieder untergeht.

Auf die Community kann man eh kaum zählen, und darauf würde ich mich 
auch nicht verlassen.
Wenn du was hast, was im Läuftfürmich-Status ist, würde ich mir nur 
bedingt RISC-V antun. Ist auch nur 'yet another take' einer verbesserten 
MIPS-Arch. Zu den obigen Projekten kann ich nicht viel sagen, da für 
mich die Implementierung (VHDL) relevant ist, weniger kleinere 
Designschmankerl.
Gast #5245728
Lesenswert?

RISC-V hat schon einige Vorteile:
- skalierbar von einfachen 32bit bis 64bit Prozessoren mit allen Extras. 
Mit Option zu 128bit.
- Minimale Version ist kleiner als z.B Mico32, MIPS oder OpenRisc.
- Kann leicht mit eigenen Befehlen erweitert werden.
- Wird offiziell von GCC unterstützt, man hat also immer die neusten GCC 
Versionen verfügbar.
- LLVM Port gibt es nun auch.
- Viele Hochschulen und Firmen arbeiten an Tools und Chips.
- Die gleiche Architektur für alle FPGA Hersteller, bei Microsemi und 
Lattice sogar vom Hersteller selbst (wenn auch bei Lattice anscheinend 
noch? nicht OpenSource)
- Die ISA ist frei verwendbar, ohne drohende Lizenzprobleme oder Kosten.
- Viele freie OpenSource IPs, aber auch kommerzielle mit Support.
- Mehrere ASICs mit RISC-V sind angekündigt, oft mit mehreren Cores auf 
dem Chip, man kann also die Leistung später beliebig steigern.

Wenn's VHDL sein soll, dann schau dir mal den Orca von VectorBlox an. 
Die machen das kommerziell, aber der RISC-V Teil ist OpenSource und 
Hersteller übergreifend.
https://github.com/VectorBlox/orca
#5246502
Lesenswert?

Wie sieht's inzwischen bei RISC-V mit Regresstests/Testbench aus? Als 
ich das Dingen damals angeschaut habe (paar Jahre her) sah das noch mau 
aus..
Ebenso mit den Debug-Interfaces. Was zeichnet sich da so ab? Hat SiFive 
Standards genutzt/gesetzt?
Auch interessant: Compressed instruction sets. Beim MIPS (MIPS16 ASE) 
ein übler Hack, wie sieht's beim RISC-V damit unter Context-Switches 
aus?
#5247241
Lesenswert?

Martin S. schrieb:
> Wie sieht's inzwischen bei RISC-V mit Regresstests/Testbench aus?

Ich hatte mir vor längerer Zeit PicoRV32 angeschaut, und dessen 
Entwickler hat sein Steckenpferd eigentlich in der formalen Verifikation 
von Verilog.

Martin S. schrieb:
> Auch interessant: Compressed instruction sets.

Komprimierte und nicht-komprimierte Instruktionen können beliebig 
gemischt werden (müssen aber passend aligned sein) und jede komprimierte 
Instruktion expandiert zu einer exakt äquivalenten unkomprimierten 
Instruktion.
#5354050
Lesenswert?

Ich gehe davon aus, dass du "blinkende LEDs" und ein bisschen Basteln 
schon durch hast, sonst kannst du das gleich vergessen.

Nimm dir den PicoRV32 und schau dir dessen Interface an, außerdem die 
Dokumentation (die README-Datei). Dann brauchst du eine Form von RAM für 
den Core, aus dem er seinen Code ausführen kann (kannst du im Vivado mit 
einer Datei vorbelegen). Ein Block-RAM lässt sich relativ einfach 
anschließen.

Außerdem brauchst du eine Form von I/O, damit der Core mit der Umgebung 
kommunizieren kann. Im einfachsten Fall nimmst du Schalterstellung und 
LEDs und weist denen eine Adresse zu.

Wenn der PicoRV32 von dieser Adresse lesen will, gibst du die 
Schalterstellung zurück, wenn der PicoRV auf diese Adresse schreiben 
will, merkst du dir das für die LEDs, und andernfalls geht der Zugriff 
ins Block-RAM.

Bevor du es dann aufs Board legst, simulierst du das Ganze im Vivado 
durch.

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren