Design-Praxis RISC-V

Von den Grundlagen bis zum Prototyp

10. März 2019, 19:51 Uhr | Dr. Constantin Tomaras, Ressortredakteur für Systemdesign, DESIGN&ELEKTRONIK

Fortsetzung des Artikels von Teil 4

II. Design und Verifikation nach DVCon Europe

Nur anhand der Definition der semantischen Ebene mit den beiden Spezifikationen [1, 2], ist es schwierig abzuschätzen, wie ein Szenario für eine Erweiterung aussieht und welchen Implementierungsaufwand es nach sich ziehen kann.

Prinzipiell könnte ein Halbleiterhersteller diese Erweiterung sogar auf die Anwenderebene herunter bringen, in dem freie Maschinenbefehlssätze der Standard-Erweiterungen, eine programmierbare Logik ansprechen, die beliebige asm-Befehle tragen kann. Bis so ein Produkt am Markt auftaucht,
werden Entwickler ihre proprietäre RISC-V-Erweiterung auf der Ebene des Chipdesigns einführen müssen. Das DVCon-Tutorial [3] zeigt dazu zwei Entwurfsflüsse: die Integration der Erweiterung in einen Simulator und eine Implementierung über der VHDL-definierten physikalischen Ebene.

Die Simulation basiert auf der Imperas-Plattform, die ein virtuelles Modell für den RV32IM angeschlossen an einen Speicher hat. Der Simulator selbst wird auf Terminalebene im jeweiligen Betriebssystem angesprochen. Als Beispiel wird die Samba20-Verschlüsselung als eigener Befehl implementiert. Diese besteht aus vier logischen Rotationen, die jeweils elementare Operationen wie XOR und ROL aufrufen. Mit einer API können diese Operationen in einen Ausführungsblock zusammengefasst, das timing ergänzt und dem neuen asm- und Maschinenbefehl zugeordnet werden. Ob die phy diese elementaren Operation auch wirklich clustern kann, steht auf einem ganz anderen Blatt: idealerweise gibt es etwas im Steuerwerk, das die elementaren Operationen mit einem Befehl abarbeitet, oder das Ergebnis wird von einer unterschiedlichen physikalischen Implementierung erarbeitet.

Matchmaker+ Anbieter zum Thema

zu Matchmaker+

Bild 2 zeigt einen möglichen Entwicklungsfluss, für die Erweiterung der virtuellen Plattform um einen neuen Befehlssatz. Die angestrebte Anwendung sollte zunächst als c-Programm auf der virtuellen Plattform ausgeführt werden. Aus Anwendungssicht ist nämlich nicht klar, ob eine Hardware funktional geeignet ist.

Die Simulation sollte dabei Befehlsakkurat sein, damit die Anwendung über eine debug/trace-Schnittstelle relastisch analysiert werden kann. Standardmetriken sind Performanz in Rechenzyklen und das timing. Im Samba20-Beispiel ist die rekursive c-Definition der vier logischen Rotationen aus einem Funktionsarchetyp heraus, dabei rechen-ineffizient.

Im nächsten Schritt muss der angestrebte Befehlssatz charakterisiert, und zu der virtuellen Plattform in Verhalten und timing ergänzt werden. Im Beispiel ist es effizienter, die vier logischen Rotationen direkt als Assemblerbefehle anzulegen. Mit der Äquivalenz von Befehl und Operation, können mehrere Operationen mit der API im Modell gekapselt und einem einzigen erweiterten Maschinenbefehl zugeordnet werden.

Der erweiterte Befehlssatz muss erneut durch befehlsakkurate Simulation in der Anwendung verifiziert und analysiert werden. Wird ein Bug erkannt, muss der Befehlssatz oder seine virtuelle Implementierung angepasst werden.

Funktioniert der neue Befehl in der Anwendung, so kann das RISC-V-Modell optimiert und seine Performanz als Referenz für eine VHDL-Verifikation dienen. Besonders für den Nachweis der RISC-V-compliance sind automatisierte Tests mit pseudo-zufälligem Code vorteilhaft.