'Samsung ontwerpt risc-v-cpu voor internet-of-things'

Samsung zou begin dit jaar begonnen zijn met het ontwerp van zijn eigen cpu-core. Het Koreaanse bedrijf zou zich met de cpu op toepassingen voor internet of things richten en de chip zou op de risc-v-architectuur gebaseerd zijn.

De risc-v-rekenkern zou geïntegreerd worden in een 32 bits microcontroller en vanwege een beperkte omvang en laag verbruik geschikt zijn voor wearables. Volgens ETNews gaat het om een chip met 10.000 tot 20.000 transistors, vergelijkbaar met de Cortex-M0, die op de ARM-architectuur gebaseerd is.

Risc-v is een opensource isa die zijn oorsprong heeft bij de Computer Science Division van de University of California. Doel van het project, dat in 2010 in gang werd gezet, is om cpu-ontwerpen vrijelijk onder een bsd-licentie beschikbaar te stellen. Andere chipontwerpen die op de reduced instruction set computing-principes zijn gebaseerd, zoals arm en mips, worden tegen betaling onder een licentie verstrekt.

De eerste iot-producten met de Samsung-core zouden volgend jaar moeten verschijnen. Samsung ontwierp eerder de M1-core van de Exynos 8 Octa 8890, de soc van de Galaxy S7.

Reacties (56)

Dat is een behoorlijk kleine processor-core, zelfs voor RISC-begrippen.

- De grootste chip van dit moment telt een miljoen keer zoveel transistors (10 miljard: SPARC M7)
- De Intel 8086 uit 1978 had al 29.000 transistors
- Op een 14nm procédé past zo'n Cortex-M0-core in theorie op ca. 0,001 mm²

In de praktijk zullen ze wel groter worden 0,001 mm², maar dan nog blijven ze klein genoeg om vrijwel overal in te kunnen verwerken. Ze zouden in veel grotere versies ook van printbare flexibele materialen gemaakt kunnen worden.

Dat is een behoorlijk kleine processor-core, zelfs voor RISC-begrippen.

Ik betwijfel of dat getal wel klopt; zou er niet per ongeluk een nulletje zijn weggevallen?

Laten we uitgaan van 20.000 transistors. Je hebt er zes nodig voor elke bit SRAM. In een 32 bit CPU heb je dus al bijna 200 transistors nodig voor elk register en de architectuur heeft er 32. Dat is een totaal van ongeveer 6000; zo goed als een derde van de transistoren is dan al op, nog voordat we zelfs maar begonnen zijn aan de instruction decoder en de ALU. Voor het gemak ga ik er vanuit dat de optionele 32 floating point registers (en de floating point ALU) weggelaten zijn.

@Squee:
Ja, ik had het originele artikel er ook bij gepakt en toen ik daar hetzelfde zag staan begon ik flink te twijfelen of ik zelf niks over het hoofd zag; vandaar bovenstaande berekening. Jouw oplossing klinkt zeer aannemelijk, dat zou het best eens kunnen zijn, dankjewel!

[Reactie gewijzigd door robvanwijk op 25 november 2016 16:47]

Ik betwijfel of dat getal wel klopt; zou er niet per ongeluk een nulletje zijn weggevallen?

Al staat het zo te zien ook precies zo in het originele artikel, toch vermoed ik dat er inderdaad onderweg ergens wat spraakverwarring is ontstaan. Ik denk dat er oorspronkelijk over "10.000 a 20.000 gates" gesproken is, en dat iemand dat onderweg ergens geinterpreteerd heeft tot transistors, terwijl dit eerder een aanduiding is voor het aantal AND/NAND/OR/XOR etc gates die uit meerdere transistoren bestaan. Ik gok dat het werkelijke aantal transistoren dus een factor 4x a 6x hoger zal liggen.

Mooi overzichtje van aantal transistors per gate type:
https://en.wikipedia.org/...tor_count#Logic_functions

Er zijn wel plaatjes te vinden van RISC-processors waarop is te zien dat de registerfile iets van een kwart van het oppervlak van de processorcore beslaat. Ik vermoed dat de instructiedecoder en ALU minder efficiënt zijn te layouten dan een registerfile, dus dat die minder dan twee derde van het totaal aantal transistors bevatten lijkt me best aannemelijk.

Die eerste is dan weer niet helemaal correct, er zijn chips die ruim meer dan 10 miljard transistors hebben. Volgens wikipedia gaat het dan wel om een GPU en FPGA's.

Die eerste is dan weer niet helemaal correct, er zijn chips die ruim meer dan 10 miljard transistors hebben. Volgens wikipedia gaat het dan wel om een GPU en FPGA's.

Dat lijkt me wel als we het hier over processoren (dus alleen CPUs ) hebben, want jij hebt het over compleet andere chips. De tabel op Wikipedia loopt al een beetje achter zo te zien, maar ik vermoed dat de huidige top drie iets zal zijn als:
- 7.2 miljard transistors voor de 22-core Broadwell Xeon
- 8+ miljard voor Xeon Phi Knights Landing
- 10 miljard voor SPARC M7

Als van die top drie alleen de Xeon Phi ontbreekt valt het ook wel redelijk mee met hoe erg die tabel achterloopt. De andere twee staan er wel in.

De MCU's met Cortex-M0 kernen die wij gebruiken worden op 90nm gemaakt, sinds kort worden dergelijke producten ook op 40nm gemaakt.

De ARM2 uit 1983 had ongeveer evenveel transistoren als de 8086 en presteerde beter dan de 80286. RISC-architecturen hebben over het algemeen minder transistoren nodig om tot dezelfde prestatie te komen vergeleken met CISC-architecturen.

Men voegde extra instructies toe om het makkelijker te maken voor ontwikkelaars om dingen voor elkaar te krijgen. Veel werd toen nog met assembler gedaan.

Tegenwoordig gaat alles in in C / C++ of nog hogere ontwikkeltalen. Dan maken die instructies niet meer uit, het werkt wordt door de compiler gedaan. De executables van RISC CPU's zijn dan meestal ook groter. Maar geheugen is tegenwoordig dirt-cheap en opslag al helemaal.

[Reactie gewijzigd door ArtGod op 25 november 2016 15:09]

Aangezien moderne CISC architecturen intern alles vertalen naar RISC achtige instructies zal het verschil waarschijnlijk tegenwoordig wat kleiner zijn dan in de begintijd die jij aan haalt. Waar je wel een groot verschil zal zien tussen RISC en CISC tegenwoordig is in de Instruction Fetch en Decode stappen van de processor. De Decode stap is waar de CISC processor zijn instructies opsplitst in RISC achtige micro-ops (zoals alle x86 sinds Pentrium Pro), dus alles wat daar achter zit kan min of meer vergelijkbaar zijn.

Waar het verschil in zit is dat Fetch en Decode veel complexer zijn voor een CISC architectuur zoals x86 omdat ze om moeten kunnen gaan met een variabele instructie lengte (van 1 tot wel 15 bytes!). Op een RISC processor zoals SPARC, MIPS of ARM (de 16-bit Thumb instructie extensie even buiten beschouwing latende) zijn alle instructies 4 bytes en dus even lang. Dit is veel simpeler voor de Fetch logica omdat ze altijd blokken in veelvoud van 4 bytes kunnen binnen halen en dan gegarandeerd een heel aantral instructies heeft opgehaald uit het geheugen. Op x86 kan je dit niet voorspellen, omdat je pas in Decode weet hoe lang en hoe veel het er waren. Dit geeft dan weer extra complexiteit voor het voorspellen van branches, enzovoorts enzovoorts.

En tot slot, als je in een CISC instructie set veel meer (type) instructies moet ondersteunen zal je Decode logica natuurlijk ook veel complexer zijn dan in een RISC

De meeste processor cores zijn niet veel groter, ze passen meestal in de hoekje van een moderne chip. De complete CPUs hebben ook zaken als cache, MMU, DAC, ADC, en een verzameling I/Os zoals HDMI, UART, SPI etc. aan boord, dat zijn veel grotere blokken.

[Reactie gewijzigd door springtouwtje op 25 november 2016 10:48]

Bij grotere aantallen transistoren is 99% waarschijnlijk cache geheugen.

IoT wordt echter nooit op 14nm gemaakt (voorlopig): Veel te duur voor een chip waarbij iedere cent telt, en de transistors lekken te veel als ze "uit" staan. Wat ik begrijp is dat transistors die uit staan meer lekken naarmate ze kleiner zijn. Verder is het lastig analoge circuits die je vaak nodig hebt bij sensoren, te koppelen aan zulke kleine logica. 180nm t/m 40nm, op reeds afgeschreven apparatuur dus, schijnt ideaal te zijn voor IoT.

Voor wie wat meer wil weten over RISC-V staat er op Wikipedia een uitgebreid artikel. Een interessante processorarchitectuur. De bekende C compiler GCC ondersteunt dit al en ook LLVM heeft ondersteuning voor deze architectuur.

Behalve Samsung is er volgens Wikipedia ook een reeks andere bedrijven die processors willen maken gebaseerd op RISC-V, onder andere Google, HP en Nvidia.

Hopelijk leidt dit tot efficiënte en zuinige apparaten.

[Reactie gewijzigd door jj71 op 24 november 2016 19:49]

hp is naar mijn weten in de geschiedenis een grote speler geweest op risk processoren

Nope, niet RISC maar EPIC architectuur. (AXP processor was van DEC).

HP is waar een van de grotere RISC architecturen, PA-RISC, vandaan komt. @itcouldbeanyone heeft dus gewoon gelijk.

EPIC gebruikt ook RISC instructie sets maar gaat toch iets verder door in een hyperscalar architectuur onder programma controle zaken parallel te verwerken. HPPA is overgegaan naar Itanium.

Jadus? Het ging er om dat HP groot was op de RISC markt met PA-RISC, waar jij "Nope" op antwoordde.

Het bestaan van Itanium staat los van de post van @itcouldbeanyone

hppa is een stap verder dan risk pur sang. HPPA had de mogelijkheid om conditioneel instructie uit te voeren iets wat ook EPIC genoemd wordt. En de HPPA processor is opgegaan/hernoemd in Itanium.
Er zijn veel meer processoren met een RISC instructie set, een vroeg voorbeeld is bv. PDP-11. of EM-1 (virtuele machine).

Wat is de kans dat Intel dit later gebruikt? Het zou echt fantastisch zijn als processoren een open standaard voor een instructie set gebruiken zodat de scheiding tussen mobile en desktop veel minder word.

De kans dat Intel zijn x86 instructieset en architectuur vervangt door RISC-V is vrijwel nul, want Intel heeft daar weinig zakelijk belang bij, en bovendien is x86 zo wijdverspreid dat het heel moeilijk zal zijn om dat door iets anders te vervangen. Dan moeten alle operating systems en alle andere software daarvoor worden aangepast.

Andere operating systemen hoeven mogelijk niet zoveel te worden aagepast.
Het belangrijste is in eerste instantie de compiler, die is er.
Een een OS als BSD of Linux draait al op zoveel systemen dat het model van deze processor met minimale aanpassingen er wel bij kan.

Inderdaad voor PC's. Voor IoT, MCU's en embedded is alle software ARM gebaseerd, dus in die markt zou het met Risc V ook overnieuw moeten.

Ik ben ook blij dat open-source hardware steeds meer ingeburgerd raakt want qua security is dat de zwakke schakel. Idem firmware in USB controllers, grafische kaarten, network controllers etc.

Met 20.000 transistors ga je echt niet kunnen computeren zoals iedereen gewend is. Dit wordt geen ARM-killer. Dit zal altijd een stuk elektronica blijven dat zich in een niche van de embedded markt zal begeven.

Met die 20.000 transistors zit RISC-V in de performance range van de ARM M0 mcu's. Er zijn ook multicore 1GHz+ RISC-V varianten die in principe kunnen concurreren met de grote ARM SoC's, zoals lowRISC.

Het grote voordeel van ARM is de wijdverbreidheid maar je betaalt wel per cpu of per licentie, RISC-V zet daar een licentievrije architectuur tegenover. Samsung, die vele miljoenen devices per jaar verkoopt kan potentieel veel geld overhouden door die licentiekosten

Ik heb wel nergens beweert dat RISC geen valable ISA kan zijn. Dat is nonsens. Wat ik gezegd heb is dat deze chip geen ARM-killer kan worden. RISC heeft op zich net zoals MIPS genoeg in huis om een ARM te kunnen zijn.

Het grote voordeel van ARM is de wijdverbreidheid maar je betaalt wel per cpu of per licentie, RISC-V zet daar een licentievrije architectuur tegenover. Samsung, die vele miljoenen devices per jaar verkoopt kan potentieel veel geld overhouden door die licentiekosten

Dat is een interessante stelling, ik kan me goed voorstellen dat dat een van de voornaamste beweegredenen van Samsung zou kunnen zijn hiervoor. Maar wat ik me wel af vraag, is hoe ze zullen om gaan met IP en patenten. RISC-V is leuk, maar kan je het wel "veilig" implementeren zonder te veel patenten te schenden van andere partijen? Als jij een ARM licentie afneemt dan wordt je neem ik aan ook door ARM z'n patenten portfolio beschermd. Als je zelf een open standaard als RISC-V gaat implementeren heb je dat natuurlijk niet. Al zal Samsung zelf ook wel een flinke sloot aan patenten bezitten om zichzelf mee te kunnen verdedigen.

Risc V is met name een 'broncode' voor een instructieset, een abstract idee dus. Je zou het kunnen kopen in 'boekvorm'. Er is geen fysieke belichaming van dat abstracte idee. Dus in de VS en Europa is het dan voor zover ik begrijp niet patenteerbaar dus, er geldt alleen copyright op.

Samsung is na IBM de no. 2 patent aanvrager van de wereld, daar wil je inderdaad geen patent oorlog mee. Zelfs Apple is daar behoorlijk hard in gefaald. Dus patenten lijken me geen hindernis voor Samsung om met Risc V te werken.

Overigens, theoretisch zou ARM vziw micro architecturen kunnen maken die op de Risc V instructie set werken en licenties daarop kunnen verkopen aan bijv. Samsung, of hulp kunnen verkopen aan Samsung bij het ontwerpen. Is immers BSD gelicenseerd. Zo kunnen ze proberen toch relevant te blijven als Risc V het ooit van ARM wint, zoals de Linux kernel (qua aantal apparaten) van de Windows kernel won.

Op een IoT-ding kun je sowieso (nog) niet computeren zoals op een laptop/desktop. Ooit al eens een Arduino in handen gehad? Dat soort power moet je aan denken, genoeg om bij te houden wat je meterstand is, en dat door te seinen naar elders. Niet genoeg om zelf te denken.

Nou een arduino draait anders ook Doom

Niet de AVR-gebaseerde arduino's (uno/duemilenova) die iedereen kent hoor. Die hebben daar echt de power niet voor.

Ja en nee. De ARM2 uit 1983 had 30.000 transistoren en presteerde beter dan een 286.

Ervan uitgaande dat deze RISC-processor vergelijkbaar efficient is en in een kleiner procedé wordt gemaakt en hoger geklokt kan worden, zou hij zomaar vergelijkbaar kunnen zijn met een pentium. Geen marktconforme desktopprestaties maar ook weer niet heel ver weg van 'kunnen computeren zoals iedereen gewend is'.

Geen marktconforme desktopprestaties maar ook weer niet heel ver weg van 'kunnen computeren zoals iedereen gewend is'.
Klopt, lowRISC mikt bijvoorbeeld op 'Raspberry Pi for grownups'.

Je kan hem eenvoudig sneller maken door cache geheugen op de chip toe te voegen. Los daarvan heb je voor IoT niet zoveel processor capaciteit nodig. Prijs is veel belangrijker.

is het zo dat deze microprocessor dan ook gelijk wifi functionaliteiten bevat? of is het meer dat er een zuinigere microprocessor op de markt komt?

Wat is er beter ten opzichte van een microcontroller van Atmel?

Een processor heeft in principe geen periferie aan boord. Een SoC kan wifi aan boord hebben, een microcontroller heeft meestal een flinke bult GPIO aan boord.

Een RISC-V processor zal ook gewoon als microcontroller of SoC worden gemaakt met alle pheripherals aan boord, zoals timers, UARTS, netwerk, hardware encryption etc.

Welke microcontroller van Atmel bedoel je? Hun 8-bit, 16-bit, 32-bit of 32-bit ARM architectuur? Ten opzichte van de eerste 3 is het vooral een (veel) nieuwer/cleaner ontwerp met (veel) hogere rekenkracht. Ten opzichte van alle 4 de architecturen is de 32-bit RISC-V een licentievrije open source architectuur. Omdat RISC-V een nieuwe architectuur is en de ontwerpers goed gekeken hebben naar wat werkt bij andere architecturen heeft het een 'optimale' instructieset gekregen.

Een microcontroller is een cpu met daaraan toegevoegd een combinatie van peripherals (functieblokken) zoals general purpose I/O, analoge signaal acquisitie, seriele interfaces (serial, spi, i2c, lin, ir, can), (real time) clocks, capacative touch, timers, flash/eeprom/fram en ram geheugen, accelerators als AES-256/CRC, usb en wifi.

Elke microcontroller heeft weer een andere subset van dergelijke peripherals maar aangezien dit om een hele kleine microcontroller gaat verwacht ik niet dat usb en wifi van de partij zijn.

Samsung is voor mij niet de meest voor de hand liggende partij om dit te doen. Ik dacht dat hun SoCs achter een NDA zaten, dus een open source SoC lijkt me niks voor Samsumg.

Omdat je denkt dat ze ook iets anders doen, is dit niks voor ze? Ik zou graag de feiten en de redenatie nader toegelicht zien.

Als je feiten kloppen hoeft de redenatie dat ook nog niet te doen trouwens; een openbron processorkern is niet persé besmettelijk voor het ontwerp erom heen. Dat hangt maar net van het licentiemodel af.

Waarom niet? Een cent per verkochte SoC besparen aan licentieafdrachten aan ARM levert een groot bedrijf als Samsung veel geld op.

Ik vraag me af of dit op den duur gaat leiden tot een vergelijkbare beweging als met open source software; speciale toepassingen blijven dan op basis van licenties, maar generieke toepassingen kan je als vrije bouwstenen verkrijgen. Stel dat ARM hun basiscores vrij beschikbaar stellen, maar extra functies als SIMD instructies, SE's en GPU's nog steeds onder licentie houden, dan kunnen ze hun marktaandeel vergroten maar toch competitief blijven en geld verdienen aan hun IP.

Het is natuurlijk nog niet zo dat RISC-V een alternatief is voor ARM of x86, maar dat hoeft niet altijd zo te blijven. Stel dat er genoeg mensen en kennis achter gaat zitten, dan kan een open model op den duur voor veel toepassingen beter presteren dan de gesloten varianten. Wat je dan wel hebt is dat specifieke implementaties nog steeds moeilijk te gebruiken blijven. Als Quamcomm (of hoe ze tegenwoordig ook heten) een RISC-V ISA in een SoC gebruiken maar dezelfde gesloten en geheime opzet als met ARM houden, dan hebben 'we' als community er nog steeds weinig aan.

Dit gebeurt al, er is de open-source hardware IP website OpenCores.
Je vind er tientallen (deels geverifieerde) CPU cores

[Reactie gewijzigd door springtouwtje op 25 november 2016 10:44]

Ik vraag mij af of dit een reactie is op de overnamen van ARM door Softbank. Ik heb al langer betoogd dat de onafhankelijkheid van ARM de reden voor hun succes was. Nu dat niet meer geld zie ik het ARM eco-systeem langzaam uiteen vallen.

Ik hoopte ook dat open-source ontwerpen zoals RISC-V geproduceerd gaan worden en mijn gebeden zijn beantwoord.

RISC... Ik kan mij nog herinneren dat we dat gingen proberen te bouwen in Minecraft met een 16 bit CPU Gouden tijden, erg leuk om deze term naar boven zient e komen. RISC-V is overigens wel iets anders, maar toch leuk om te zien ^^

Dit is inderdaad ook min of meer op minecraft schaal te maken met uitzondering van het grote geheugen. Het is echt te zien dat hier de afweging wordt genomen tussen de complexiteit en aantal transistoren tegenover de snelheidswinst dat je ervoor terugkrijgt. Dit doet me erg denken aan de MIPS architectuur. Ik denk niet dat het er veel van zou afwijken.

Het begint met nieuwe ARM cpu's ,en voor je het weet hebben we nog een desktop-CPU fabrikant(of GPU for that matter). Zou wel leuk zijn om meer concurrentie te hebben in de CPU/GPU markt.

Tot het lezen van dit artikel dacht ik dat het over 'Rich Instruction Set Computing' ging