mikrocontroller.net

Forum: FPGA, VHDL & Co. RISC-V (FPGA)


Autor: Lars R. (lrs)
Datum:

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

Autor: Ale (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Picoriscv funktioniert siemlich gut. 4 oder 5 Takten pro Befehl. 
Ganz schön.

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab auch nur den PicoRV32 benutzt. Tat auf Anhieb (im Gegensatz zum 
Rest meines Monsters).

Autor: Til S. (Firma: SEGGER) (til_s)
Datum:

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

Daher sind wir ganz gut in dem Thema drin. Wer also Fragen hat, dem 
helfen wir gerne weiter.

Autor: Vancouver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
http://www.pulp-platform.org/ von der ETH Zürich.

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aber welche der freien Versionen hat auch eine Debug Schnittstelle wie 
das SiFive kit?

Autor: Mampf F. (mampf) Benutzerseite
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
abo-on

Autor: Michael F. (mifi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Til,

der J-Link unterstützt ja auch das RISC-V System und das Evalboard
mit dem E31. Gibt es hier eine Spezifikation die man umsetzen müßte
damit man den J-Link auch für andere RISC-V Projekte benutzen kann?

Gruß,
Michael

Autor: Til S. (Firma: SEGGER) (til_s)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, gibt es:
Zur Zeit wird die "RISC-V External Debug Support Version 0.13" 
unterstützt.
"RISC-V External Debug Support Version 0.11" is für Q1/2018 geplant.

Autor: Weltbester FPGA-Pongo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mampf F. schrieb:
> abo-on

+1

@Lars: Was möchtet ihr mit der RISC genau bauen?

Autor: Lars R. (lrs)
Datum:

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

Youtube-Video "7th RISC V Foundation Update And Workshop Introduction"

Autor: Martin S. (strubi)
Datum:

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

Autor: Andi (Gast)
Datum:

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

Autor: Michael F. (mifi)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Hallo Martin,

oder dieses Projekt in VHDL: https://github.com/f32c/f32c

Gruß,
Michael

Autor: Martin S. (strubi)
Datum:

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

Autor: S. R. (svenska)
Datum:

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

Autor: Michael F. (mifi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

habe ich jetzt etwas übersehen, oder kann es sein das nur die Umsetzung 
von dem "Potato Project" (https://github.com/skordal/potato) auch die 
CSR Register implementiert hat?

Mit kleineren Änderungen läuft diese Version jetzt auch auf einem Altera 
DE0-Nano.

Gruß,
Michael

Autor: Lars R. (lrs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael F. schrieb:
> habe ich jetzt etwas übersehen, oder kann es sein das nur die Umsetzung
> von dem "Potato Project" (https://github.com/skordal/potato) auch die
> CSR Register implementiert hat?

Mir war spontan aufgefallen, dass picorv32 die Interrupts nicht 
entsprechend Standard umsetzt. Unter anderem deshalb meine ursprüngliche 
Frage.

Autor: Michael F. (mifi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Lars,

hilf mir bitte mal auf die Sprünge, wie ist hier der Standard?

Gruß,
Michael

Autor: Lars R. (lrs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Ale (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der PicoRV32 läuft gut. Ich hab es auf einem DE10Lite Platine (Max10) 
portiert. Einem bootloader geschrieben. 5 Takten pro Befehl. Ganz schön.

Autor: Henning W. (henwo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guten Tag,

ich möchte als Einsteiger ein RISC 5 auf meinem Nexys4 DDR laufen 
lassen. Hat jemand dazu ein vernünftiges Tutorial beziehungsweise Tipps 
?

Danke im Voraus,

Henning

Autor: S. R. (svenska)
Datum:

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

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.