Pine64 komt met Star64-singleboardcomputer die voor het eerst RISC-V-chip heeft

RISC-V is opzichzelf geen ontwerp, maar een ISA (instructie set architecture).

Bijvoorbeeld, ARM levert een redelijk compleet pakket met gegevens aan om een processor te bouwen. Zo zal de ISA voor een bepaalde generatie ARM cores vast liggen, maar zijn er ook verschillende core designs te licenseren die verschillende prestatieniveau’s halen. De bekende ontwerphuizen bouwen er peripherals en geheugenbussen omheen, en dan is de SOC klaar. Sommige fabrikanten (Apple met M1, maar ook anderen) passen cores nog verder aan naar eigen inzicht.

Bij RISC-V ligt dit allemaal veel losser. De instructieset heeft meerdere losse extensies, en je kan zelf kiezen wat je nodig hebt. Het minimum wat je nodig hebt is kunnen werken met 32-bit integers. In de instructieset is er zelfs ruimte in de opcodes gelaten dat je eigen instructies kan toevoegen. De implementatie van de processor, zoals de pipeline e.d. is ook niet vastgesteld en wordt tevens ook door de industrie/community geleverd.

In zekere aspecten heeft dit zeker voordelen. Als je een eigen ASIC of FPGA ontwerp bouwt, kan je er voor kiezen om een high-performance core design te maken/licenseren die superscalar (meerdere instructies tegelijk uitwerken), speculative execution, meerdere ALU’s enzovoort. Je gaat dan richting desktop PC levels performance.

Maar je kan ook optimaliseren voor size. In de open source community is er echter ook een zogenaamde “bit-serial” implementatie genaamd SERV. Deze CPU is enorm klein doordat het 1 bit van een 32-bit instructie per clock cycle verwerkt. Een instructie om 2 getallen bij elkaar op te tellen kost dus 32 cycles. Reguliere CPUs doen dat in 1 cycle, en CPUs met meerdere ALU’s kunnen nog hogere throughput halen.

Waarom zou je dat willen? Omdat het kan. De CPU is letterlijk paar honderd flipflops. Zodoende passen er 6000 SERV cores op 1 grote FPGA. De performance is wel om te huilen, omdat 1 CPU core dus eigenlijk 32 kloktikken per instructie nodig heeft.
Er is echter nog wel een legitieme gebruiksreden voor. Stel je maakt een ASIC die een klein processortje nodig heeft om even wat bits op de goede plek te zetten bij opstarten, en voor de rest niets doet. Dan kan je met een paar honderd flipflops dat al doen, en kan je zelfs de firmware later nog aanpassen.

Paar alinea’s terug zei ik “in zekere zin”, omdat ik nog niet helemaal overtuigd ben of dit ‘de’ aanpak is voor software developers. Voor hardware developers is RISC-V fantastisch omdat het nog niet uitgekneed is. Echter van verschillende microcontrollers die ik tot zover heb zien uitkomen met RISC-V hebben ze vaak ook eigen GCC compiler builds (nodig) juist omdat ze eigen instructies toevoegen aan de processor. Het is een klassieke eigenschap van OpenSource waarbij iemand die een stuk software wilt verbeteren, maar vervolgens de samenwerking of richting van het project niet bevalt en z’n eigen fork maakt. Zodoende heb je 2 software pakketten die hetzelfde doen. En is dit wenselijk voor een compiler die dezelfde architectuur zou moeten gebruiken? Of moeten we er mee leven dat je bepaalde ‘proprietary’ instructie set extensies enkel kan gebruiken als je de fabrikant z’n (mogelijk slecht onderhouden & sterk verouderde) compiler fork gebruikt?

Tevens hekel ik ook dat van veel chips niet duidelijk is welk performance niveau je kan verwachten. Een “RISC-V core” zegt mij niets hoe snel die kan zijn, zoals ik al net schets met een superscalar vs bit-serial implementatie.

[Reactie gewijzigd door Hans1990 op 30 juli 2022 12:48]