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?
Ich hab auch nur den PicoRV32 benutzt. Tat auf Anhieb (im Gegensatz zum Rest meines Monsters).
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.
Aber welche der freien Versionen hat auch eine Debug Schnittstelle wie das SiFive kit?
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
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.
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
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.
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
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?
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.
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
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.
Hallo Lars, hilf mir bitte mal auf die Sprünge, wie ist hier der Standard? Gruß, Michael
picorv32 readme: https://github.com/cliffordwolf/picorv32#custom-instructions-for-irq-handling RISC-V ISA Volume I und Volume II: https://riscv.org/specifications/
Der PicoRV32 läuft gut. Ich hab es auf einem DE10Lite Platine (Max10) portiert. Einem bootloader geschrieben. 5 Takten pro Befehl. Ganz schön.
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
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.
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.