'Eerste RISC-V-pc' bevat soc met vijf cores op mini-itx-bord

Chipbedrijf SiFive heeft de naar eigen zeggen 'eerste RISC-V-pc' aangekondigd. De HiFive Unmatched is een mini-itx-bord met pentacore-soc op basis van RISC-V, gericht op softwareontwikkeling.

De basis van het HiFive Unmatched-ontwikkelbord is de Freedom U740-soc met vier U74-cores en een S7-core. HiFive heeft bij deze soc al de vectorextensie-instructieset van RISC V geïmplementeerd, hoewel het nog om een draft gaat. RISC-V is een opensource-isa dat als doel heeft om cpu-ontwerpen vrijelijk onder een BSD-licentie beschikbaar te stellen. Het Unmatched-ontwikkelbord bevat verder 8GB DDR4, PCIe 3.0, gigabitethernet en USB 3.2 Gen 1. Het bord heeft een afmeting van 170x170mm.

Onder andere Western Digital en Samsung werken aan RISC-V-chips. Western Digital voor zijn opslagproducten, Samsung werkt samen met HiFive aan chips voor internet-of-things, automotive en 5G, maar HiFive wil RISC-V onder andere ook naar pc's of zelfs supercomputers brengen. Het bedrijf wil daarbij andere bedrijven helpen met ontwerpen en een ecosysteem ontwikkelen om de chipontwikkeling goedkoper, sneller en makkelijker te maken.

Reacties (74)

Waarom zit er geen los geheugenslot op? Zo ben je beperkt tot de vastgesoldeerde (ingebouwde?) 8GB. Op zich leuke ontwikkeling, ik zit niet per se vast aan x86. Al is het voor games wel makkelijk. Maar Linux draait hier ongetwijfeld prima op.

Ik denk dat het is om het bord klein en simpel te houden. Het bord is niet zo heel groot en daarnaast is RAM werkend krijgen en houden stiekem een kloteproces. Als je beperkt welke chips en timings je ondersteunt, maak je dat proces een stuk makkelijker voor jezelf.

Het apparaat is nou niet bepaald bedoeld om meteen te concurreren met een AMD Ryzen of een Intel i5. Ik denk dat ze eerst gewoon wat units de wereld in willen sturen waarmee ontwikkelaars aan de slag kunnen en waarmee ze dingen als Linuxsoftware stabiel kunnen krijgen zonder emulator, en later pas gaan kijken naar uitbreidbaarheid en andere features die je in een PC ziet.

Goed punt over de geheugencompatibiliteit!

En dat het niet direct concurrent voor high-end desktop CPUs is lijkt me evident. Maar voor iets als een browser-PC of HTPC zou het afhankelijk van de GPU best dienst kunnen doen.

heb jij bij een browser pc dan niet genoeg aan 8Gb ?

Hangt er vanaf van hoeveelt tabs je open hebt Maar meer geheugen is relevanter als je het als server zou willen inzetten.

Probeer eens 60 Firefox pagina's te openen haha

Maar Linux draait hier ongetwijfeld prima op.

Kaal Linux waarschijnlijk wel. Of je favoriete applicaties ook gecompileerd zijn voor RISC betwijfel ik, en ik weet niet of het in de praktijk eenvoudig is om bijvoorbeeld Firefox voor RISC te compileren. Een artikel uit 2019:

The main blockers in the RISC-V ecosystem from getting the remaining Debian packages built and allowing for a nice experience revolve primarily around Rust and LLVM support. Once the LLVM compiler stack has good support for RISC-V, that should unblock many other packages like Rust-dependent librsvg and Firefox, among others.

Nee, hoor. Debian ook al;

https://wiki.debian.org/RISC-V

Interessant. Verbruikt Risc net zoals MIPS niet veel minder stroom?

Je kan dus als ik het goed begrijp Risc v met de instructies op de Debian pagina laten emuleren in Qemu? En stuurt Risc met name fgpa's aan? Of begrijp ik dat verkeerd. (Waar draait Debian niet op?)

De eerste RISC-V cpu's zijn met Field Programmable Gate Arays (FPGA) gemaakt omdat dit bij enkele stuks een betrekkelijk goedkope oplossing is (alleen de FPGA programmeercode is nodig en kan , waar nodig, eenvoudig gecorrigeerd worden). Voor massa productie kan je goedkoper het normale chip bakproces volgen. dat laatste heef SiFive dus gedaan en ook de bijbehorende aanstuur chips + printboard samengesteld tot een werkbaar geheel.

De instructieset bepaalt niet hoeveel stroom er verbruikt wordt.

Nee, dat is al lang niet meer zo. Het hebben van een superscalar architectuur en caches zijn de hoofd stroom vreters. De instruction decoders zijn relatief veel minder belangrijk geworden in het power verhaal.

Ik ken deze specifieke hardware niet. Is dit significant anders dan ARM? Ik heb wel op wat ARM-SOC based bordjes Linux gedraaid inclusief GUI, en ik dacht ook Firedox. Dat was al een paar jaar geleden. Niet heel snel maar wel werkbaar.

Als thuisserver ook mogelijk interessant.

ARM is een ander ISA, hoewel ARM ook een "RISC architectuur" (net als een hele rits andere CPUs en tov. van x86 dat CISC is, maar tegenwoordig stiekem gewoon RISC met een vertaal stap - microcode) is zijn ARM en RISC-V compleet andere architecturen en een binary voor de ene zal niet op de andere draaien net als dat iets dat voor x86 is gecompileerd niet op ARM kan draaien.

Wat dit platform in mijn ogen enorm interessant maakt is dat de hardware in grote mate Open Source is wat betekent dat software ondersteuning in theorie veel beter en langduriger kan zijn dan bij de gemiddelde ARM SoC waar de binary blob drivers meestal maar voor een klein aantal kernels worden uitgebracht en Open Source ondersteuning bijna niet te vinden is.

Als je die blops nog zelf moet ontwikkelen ben je een hele tijd verder dan die ARM gebruiker. De kracht van die blops is dat elke hardware bouwer dat pakt wat voor zijn toepassing nodig is en dan met vliegende start kan ontwikkelen op punten die specifiek zijn voor de toepassing ipv low level taken wiel elke keer opnieuw uit te vinden. Je levert dan wel in maar kan schelen in 2 á 3jaar time to market of 4 á 7 jaar. En open source afhankelijk hoeveel vrijetijd de vrijwilligers hebben en wie de leiding neemt gaat het eigen ding volgen.
Alles heeft zijn pro's en con's . Als toepassing hebt in bepaald niche markt en 10mil aan de ontwikkeling in 4 jaar iets moet opleveren of 25mil om 7 jaar iets op te leveren houd in dat met kleiner team met deels kant klate modules hardware en software tot product moet komen. Afhankelijk of die toepassing , standaard oplossingen aan de eisen voldoen.

Die blops worden nu ook ontwikkelt door de fabrikant van de chip en dan heb je beperkte tijd ondersteuning en heb je 0 invloed/inzicht op de kwaliteit/veiligheid en is de fabrikant "klaar" dan kun je naar verdere ondersteuning fluiten.

Het mooie aan de RISC-V omgeving is dat er allerlei uitbreidingen en toevoegingen worden ontwikkelt door een veelvoud aan partijen en veel van die ontwikkelingen gebeuren ook weer Open Source dus kun je voort boorduren op het werk van anderen.

Op dit moment moet er nog veel worden ontwikkelt maar er is ook al enorm veel klaar sinds de eerste aankondigingen een paar jaar geleden (PCIe interface bvb) en hoe verder het platform zich ontwikkelt hoe lager de "vooraf" kosten zullen zijn (zeker in vergelijking tot andere chips).

Is dit significant anders dan ARM?

Ja, het is significant anders. RISC is een instructieset, x86 is een instructieset en ARM is een instructieset (technische gezien zijn het alle drie verzamelingen, er zijn veel dialecten van in ieder geval ARM en x86, bijvoorbeeld ARMv7 of x86-64). Dus software die werkt op x86 werkt per definitie niet op ARM, en software die is geschreven/gecompileerd voor ARM zal niet werken op RISC. Het is echter goed denkbaar dat dezelfde source code voor alle drie deze architecturen gecompileerd kan worden en dus zal werken.

RISC en CISC zijn CPU architecturen.
ARM en RISC-V zijn RISC.
x86 is CISC (en vanbinnen volgens mij steeds meer RISC).

De -V is belangrijk bij RISC-V.

Ik begrijp natuurlijk dat dezelfde binaries niet uitwisselbaar zijn. Het punt is dat RISC een typering van een instructieset is. ARM is ook een RISC. x86 is een CISC (die ondertussen dacht ik onder de motorkap ook naar een RISC instructieset vertaald wordt). RISC-V is een RISC.

Maar ik ben tot nu toe weinig / geen platformen tegengekomen waarvoor GCC niet beschikbaar is. Vandaar mijn vraag - zijn er zaken die het significant moeilijker om iets naar RISC-V te porten? Dan moet je dus al code hebben met in-line assembly, of beperkingen in de ondersteuning van features door GCC en dergelijke.

ARM is ook een RISC

Klopt, dus mijn vereenvoudiging was te eenvoudig. RISC-V is een instructieset gebasseerd op de RISC-filosofie en ARM is dat wellicht ook. Dus je kan gelijk hebben dat de verschillen tussen RISC-V en ARM kleiner zijn dan tussen x86 en ARM; maar zeker weten doe ik dat niet en ik weet ook niet of je er iets aan hebt.

Het is niet alleen dat RISC-V is gebaseerd op de RISC filosofie, maar het is ook de vijfde generatie van Berkeley RISC, waar David Patterson oorspronkelijk aan werkte en nu bij RISC-V nog steeds doet samen met sommige van zijn voormalige studenten, die inmiddels zelf professor zijn en ook weer hun studenten bij het project hebben betrokken. Bovendien staat de V in RISC-V ook voor vectorinstructies.

Ik heb dit jaar mezelf de basis van ARM en POWER eigen gemaakt en daarnaast ook het RISC-V boek gelezen, maar nog niet de tijd gehad om daarmee aan de slag te gaan. Met QEMU kun je uitstekend een RISC-V machine emuleren die bijvoorbeeld Fedora, Debian of OpenSUSE draait. Niet alle software zal daarbij beschikbaar zijn, maar volgens mij kon ik zelfs een XFCE desktop draaien in de geëmuleerde machine. Daarnaast heb ik het de afgelopen jaren al een paar keer zien draaien op echte hardware.

Maar ik ben tot nu toe weinig / geen platformen tegengekomen waarvoor GCC niet beschikbaar is.

Dat is te simpel gedacht: De hele omgeving waarin een programma moet werken, inclusief alle bibliotheken, moeten beschikbaar zijn. Je komt daarbij vanzelf bibliotheken tegen met low-level hardware-afhankelijkheden, zoals bijvoorbeeld een OpenGL-implementatie. Dat soort dingen zul je allemaal moeten porten voordat je je eigen code door GCC heen kunt halen.

[Reactie gewijzigd door dmantione op 30 oktober 2020 14:25]

Volgens mij is er geen inherent probleem met de tooling waarom porten moeilijker zou zijn, maar het is gewoon gigantisch veel werk. Naast alle in-line assembly heeft tegenwoordig iedere programmeertaal blijkbaar een JIT compiler nodig (Java, Javascript (browser/NodeJS), .NET, Python...) die in staat is native code te genereren. Die vertaalslag moet in staat zijn effectieve machinecode te genereren.

Als je ontwikkeld in een taal als C, C++ dan is het inderdaad prima mogelijk om voor meerdere processortypes te ontwikkelen, maar veel (zo niet alles) hangt af van de standaardisering en beschikbaarheid van bibliotheken (libraries). Standaarden als POSIX, SYSV etc dateren al uit de vorige eeuw, en zijn nodig om code te schrijven die op UNIX/Linux (en later ook Windows) op een varieteit aan hardware kan draaien. Bijv. de volgende OS/processor combinaties: HPUX+Itanium, Solaris/SUN_SPARC, AIX/PowerPC, Windows/x86. Ik denk dat RISC-V wel parallellen heeft met IBM zijn PowerPC processor.

Op deze manier is ook Linux voor een hele rij processor architecturen beschikbaar (grote delen van Linux zijn in de taal C geschreven).

Debian, Fedora, OpenSUSE en een aantal andere distros hebben images voor RISC-V. Rond de release van Debian 10 werd gezegd dat 80% van de software in de Debian repositories draait onder RISC-V. Dit zal over het afgelopen jaar nog wel verder verbeterd zijn. In de Debian repos is een package van Firefox voor riscv64 beschikbaar.

[Reactie gewijzigd door Omega op 30 oktober 2020 15:43]

Qemu heeft al jaren risk-V aan boord. Dus emulator en software ervoor was er al.

De vraag is niet of RISC-V op Linux draai maar andersom

Je kan dus NU al testen ....: (Kernel sources:), hardware niet vereist...
Voor werkelijk hardware zijn mogelijk nog wel (extra) drivers nodig....

$ ls -l /usr/src/linux/arch/riscv
total 48
-rw-r--r-- 1 root root 67 Nov 25 2019 Kbuild
-rw-r--r-- 1 root root 7532 Oct 20 13:21 Kconfig
-rw-r--r-- 1 root root 0 Nov 25 2019 Kconfig.debug
-rw-r--r-- 1 root root 302 Nov 25 2019 Kconfig.socs
-rw-r--r-- 1 root root 2592 Nov 25 2019 Makefile
drwxr-xr-x 3 root root 4096 Oct 20 13:22 boot
drwxr-xr-x 2 root root 4096 Oct 20 13:22 configs
drwxr-xr-x 4 root root 4096 Oct 20 13:22 include
drwxr-xr-x 3 root root 4096 Oct 20 13:22 kernel
drwxr-xr-x 2 root root 4096 Oct 20 13:22 lib
drwxr-xr-x 2 root root 4096 Oct 20 13:22 mm
drwxr-xr-x 2 root root 4096 Oct 20 13:22 net

[Reactie gewijzigd door tweaknico op 31 oktober 2020 15:58]

Bedoel je dat dit de allereerste RISC-V chip is en voor dit bord alleen met emulators getest kon worden?

Er zijn nog niet veel SOC's gebouwd. Voor zover mij bekend is dit de eerste die algemeen beschikbaar komt.
Voorheen alleen emulators en in FPGA uitgevoerde exemplaren.
BTW.. Qemu is er ook voor BSD en Windows.. Dus je kan ook Risk-V op Windows draaien, het omgekeerde Windows op Risk-V is vooralsnog veel lastiger
(Risk-v met Qemu die X-86 emuleert en dan windows in de Emulator.)

[Reactie gewijzigd door tweaknico op 31 oktober 2020 16:41]

LLVM is sinds september 2019 officeel beschikbaar voor RISC-V:
https://hub.packtpub.com/...sm-goto-clang-9-and-more/

En als je zelf RISC-V CPU's gaat ontwerpen zijn er tools die het LLVM-backend etc mee genereren:
https://riscv.org/wp-cont...VM-Support-For-RISC-V.pdf
(slide 7)

En anders draai je er toch gewoon één of andere x86 emulator op

Er zijn wel ARM en PowerPC compatibility layers/emulatie programma's zoals Box86 en QEMU. Maar ik heb geen idee of deze tools specifiek voor ARM en PowerPC zijn en of ze kunnen worden gebouwd voor RISC-V.

Als RISC-V een beetje aanslaat in de Linux community zullen we wel projecten die i386 en AMD64 emulatie op riscv64/riscv128 als doel hebben zien verschijnen.

Ik twijfel of dat Linux 'prima' zal lopen, aangezien het over development-hardware gaat, maar het zal wel zeker een van de beste opties zijn.

Het zal wel draaien, gezien deze hardware geen enorme ladingen aan binary blobs nodig heeft om überhaupt te werken zoals de meeste ARM apparaten.

Bij mijn weten heb je helemaal geen blobs nodig om Linux op ARM te draaien, alleen maar om de randapparatuur te gebruiken.

Klop maar zonder blobs moet je wel zeer zorgvuldig kiezen uit de randapparatuur die je gaat toepassen.
(kijk eens naar het het librem-5 ontwikkel proces.).

Erg benieuwd naar RISC-V de aankomende tijd.

Is er een prijs(~range) bekend van dit bord?

Op hun website in hun laatste blogpost staat "Priced at $665USD (suggested retail price)"

Thanks! Raar dat ze het niet bij de Pre-order knop zetten.

USD 665 volgens The Register, waarschijnlijk komt daar nog BTW bij.

De marketing afdeling heeft het waarschijnlijk een dollar lager geprijsd

665 USD.

Nu er een kans is dat nVidia ARM in handen krijgt is RISC-V steeds interessanter en belangrijker.
Het is namelijk nog maar de vraag hoe open en toegankelijk ARM blijft als nVidia er mee aan de haal gaat

Zou voor (Open)SPARC ook nog ruimte zijn? Volgens mij zou de boel vrij eenvoudig te gebruiken moeten zijn, maar het lijkt er op dat alleen Fujitsu nog echt wat ontwikkelt (met de SPARC M12-2 als recentste voorbeeld)

Zo op het oog na wat zoeken lijkt risc-v gewoon de modernste, en daarmee wellicht beste open keuze te zijn.

[Reactie gewijzigd door begintmeta op 30 oktober 2020 19:09]

Voor zover ik weet heeft Oracle het meeste van de Sun-erfenis in het vuilnisvat geworpen.

Vorig jaar is Solaris weer eruit gehaald, omdat de overname van RedHat mislukte. IBM was Oracle daar te vlug af.

[Reactie gewijzigd door tweaknico op 30 oktober 2020 23:08]

Wat zijn eigenlijk de belangrijkste unique selling points van RISC-V?

Het is open source, de VS kan het dus niet gebruiken als wapen in hun economische/protectionistische oorlogen.
Als NVIDIA ARM overneemt, heeft de VS het quasi monopolie op CPU's, en kan het de ganse wereld chanteren en naar hun hand zetten door te dreigen met een exportverbod.

Grootste sellingpoint is dat de architectuur onder BSD licentie valt, dus kan iedereen mee "aan de slag"

Open Hardware

Alles wat open en vrij is kan voor felle concurrentie zorgen in de markt: je kan als klein bedrijf gelijk verder meelopen met de rest. Het drukt ook de kosten.

Je kan zo een configuratie via SiFive bestellen die aan je business-eisen voldoet. Zoiets als “doe mij dit en dat dat wel en dat niet”, en ze bakken het voor je.

Nou is dit natuurlijk nog verre van wat het in de toekomst kan gaan worden, maar er wordt aan gewerkt.

Deze RISC standaard, is dat nu hetzelfde als wat IBM in hun Power machines (ook wel bekent als AS400, iSeries, P-series, mid-frames, en andere namen uit het verleden) hebben zitten?

RISC is een CPU architectuur en geen standaard instructieset.
RISC PowePC instructies zijn anders dan de RISC ARM instructies of de RISC-V.

Vergelijk het met bijvoorbeeld een 'toontaal'. Je gebruikt hetzelfde principe, maar je verstaat elkaar niet.

RISC is een ontwerpfilosofie.

Er waren al FPGA -- http://risk-v.com/
Meer info: https://en.wikipedia.org/wiki/RISC-V

Thanks, duidelijk!

Waarom willen ze een risc-V cpu ontwikkelen?

SiFive is opgericht door mensen die aan de Berkeley universiteit aan de ontwikkeling van RISC-V hebben gewerkt en daarna het idee opgevat hebben om RISC-V technologie commercieel beschikbaar te maken. Het hele bedrijf draait om RISC-V, dus het is zinnig dat ze ook doen aan ontwikkeling van RISC-V cores en de hardware eromheen.

Die is al ontwikkeld, op basis van software emulatie (QEMU) en in FPGA;s.., dit zijn de eerste echte silicium implementaties.

Hier zou ik graag mee willen experimenteren. Je kan er in principe een desktop-achtige opstelling mee maken, maar ik zie veel meer in een zuinig gateway/buffer systeem. Kleine form factor, goede interfaces en als het eenmaal een tijdje in productie is hopelijk ook een schappelijke prijs. Dat is bij nieuwe chips altijd even lastig om dat er gigantisch in geïnvesteerd moet worden voor dat het product levensvatbaar is voor een bedrijf, maar na de eerste development bordjes zou dit misschien de eerste stap richting massa kunnen zijn.

Het gebrek aan verbruik en flops doet mij wel denken dat het eigenlijk nog niets is om naar huis te schrijven, hoeft ook niet voor een dev bord/platform maar het is wel tekenend.

Hun vorige chip deed iets van 60 watt als ik het mij goed herinner. (kan geen bron vinden met watt en/of TDP)

Een reden om dit bedrijf in de gaten te houden is omdat Chris Lattner (http://nondot.org/sabre/) in januari van dit jaar aan de slag is gegaan als Lead Product and Engineering bij SiFive. Hij is onder andere oprichter van de LLVM Compiler Infrastructure, de Swift programming language en de MLIR Compiler Infrastructure. Hoewel succes van een product of bedrijf natuurlijk niet afhangt van 1 engineer heeft Chris wel zodanige reputatie om zijn werk in de gaten te houden.

Ik vraag me nu net af wat gaat AMD hier mee doen?

Ze hebben net een divisie fpga's overgenomen. Ze maken Al x86. En Lisa Cu stond aan de wieg o.a. van de PowerPC die in de PS3 zat.

X86 ik in combinatie met RISC-V en fpga's? Ze wilden toen een hybride met Arm maken maar dat is gestaakt.

Toch wel bijzonder om te zien dat ze deze oude techniek toch nog een duw in de rug proberen te geven.
Ik had zelf het idee dat je met ARM, FPGA, x86 en GPU achtige CPU's toch voldoende keuze heb voor het uitvoeren van je code.

RISC is weliswaar oud, maar RISC-V is nieuw.

Er is de afgelopen 2 jaar een flinke groei in implementaties, het lijkt erop alsof cloudboeren en vendors de aanstormende dood van x86 aan voelen komen. In deze architectuur zit niet heel veel rek meer. Of ARM of Risk-V gaat toch vrij groot worden in de cloud komende jaren.
Coreteks had hier ook een mooie analyse over.

Het lijstje met implementaties zitten best toffe projecten tussen zoals een 2,5gHz 16 core risk-v processor van Alibaba. Zie: https://en.wikipedia.org/wiki/RISC-V#Implementations

Intel Core.... heeft een probleem. die heten Meltdown en Spectre. Alle werkende maatregelen tegen spectre en meltdown zorgen ervoor dat Intel Core absoluut niet meer competitief is.

Dus? Dat ligt niet aan x86 maar aan Intel. Je kunt prima x86 van AMD pakken (ja, de 64bit versie maar dat wou ik nou eigenlijk net niet allemaal los gaan opnoemen)

Die heeft iets minder problemen, maar is niet geheel ongehavend.