Jan Tångring: BARA ATT TACKA OCH TA EMOT Plötsligt dyker Berkeley-universitetet upp och hävdar att ingen existerande öppenkods-cpu kan konkurrera med deras RISC-V. Hur tas det emot av de entusiaster som ägnat åratal åt att finslipa sina öppna cpu-kärnor? Att plötsligt få höra att deras kärnor har grundläggande brister som det inte är någon mening med att försöka reparera? Att det smartaste är att börja om från noll? Jo, det verkar tas emot ganska bra, faktiskt. Visst – i sin iver att marknadsföra RISC-V går Berkeley möjligen lite väl hårt åt ideologiska föregångare som LM32, OpenRISC och Leon. Det är inget som grupperna kring dessa kärnor låter stå oemotsagt. De är trots allt mogna arkitekturer vid det här laget, med skarpa tillämpningar i allt från teveapparater och surfplattor till zigbee-asicar och till och med satelliter. Plus en rejäl skopa tillämpningar där deras existens är affärshemligheter. Det finns nog en liten impuls till Not-Invented-Here-syndrom hos båda parter. Men impulsen verkar försvinna ganska snabbt när dialogen öppnas. Det tycker jag är sympatiskt. Och symptomatiskt för rörelsen. Det känns som om man redan förväntar sig att RISC-V kommer att bli central inom öppen hårdvara, även om den har en bit kvar till de andras mognad. Det råkar faktiskt finnas en ypperlig nisch som RISC-V kan smita in i. Det har under några år talats om en uppdaterad OpenRISC-cpu. En icke-bakåtkompatibel uppdatering med arbetsnamnet OpenRisc 2000. Den har inte blivit så mycket mer än diskussioner. En ny arkitektur är ett massivt projekt och de flesta är redan fullt upptagna med förbättringar kring OpenRISC 1000. Men nu finns plötsligt RISC-V på banan, fix och färdig efter tre års utveckling. Designad med ungefär samma mål. Från designfiler upp till mjukvaruverktyg och snart till och med i skarp hårdvara. Och i öppen källkod. Det är svårt att tacka nej till ett sådant erbjudande. Och det blir svårt att motivera folk att engagera sig i OpenRISC 2000 när RISC-V redan finns. Berkeley har nyss börjat fiska efter samarbeten med de aktiva kring OpenRisc – man vill gärna se att så mycket som möjligt av det egna arbetet blir kompatibelt med det som redan finns. Intresset är ömsesidigt – gruppen kring OpenRisc vill kunna ta med sig så mycket av sin infrastruktur som möjligt om det skulle visa sig att fokus flyttas över till RISC-V. Visst kommer det först att göras utvärderingar, för nyheten är fortfarande helt färsk – de flesta experter jag tog kontakt med angående RISC-V inför denna artikel hade inte hört talas om den ännu. Men jag tycker det börjar lukta som att åtminstone gruppen kring OpenRisc kommer att omfamna RISC-V. På personplanet har korsbefruktningen redan börjat. En av OpenRisc-gruppens ansikten utåt, Julius Baxter, är rådgivare åt Cambridge-projektet LowRisc som tar fram fysiska RISC-V-processorer. Jag tror RISC-V-gruppens dragning på OpenRisc-konferensen i Tyskland kommer att avslutas med varma applåder.

När årets OpenRisc-konferens går av stapeln i München i oktober är det särskilt en av presentationerna som väntas få många nyfikna besökare – den om den öppna cpu-kärnan RISC-V.

Det finns redan flera öppenkods-cpu:er. Men enligt Berkeleyforskarna bakom den nya kärnan har de inte fått något större genomslag, vilket dessutom enligt Berkeley inte är inte så konstigt – de har varit experimentella, skapade för undervisning eller haft ett klent utvecklarstöd jämfört med de kommersiella kärnorna.

”Vi är däremot Berkely”, kan man kanske grovt förenkla argumentet.

– Vi bedriver många forskningsprojekt kring datorarkitektur här, från simulering till  FPGA-implementation och fysiskt kisel. Vi tillverkar nog fler mikroprocessorer än någon annan existerande forskargrupp, säger Krste Asanović, som tog initativet till RISC-V.

Och visst imponerar satsningen. I laget finns till exempel David Patterson som en gång myntade termen risc och tillsammans med John Hennessy är författare till den kanske mest använda läro­boken i datorarkitektur.

Institutionen säger sig inte bara redan uppammat ett starkt stöd utan också redan producerat en stor mängd kvalitets-IP kring kärnan.

Och via Berkeleys finansiering törs man lova ett långsiktigt engagemang i kärnans utveckling.

– Det är klart att vi är partiska, men för oss är det uppenbart att RISC-V är det tekniskt bästa och säkraste valet om man letar efter en gratis öppenkods-RISC, säger David Patterson.

– Från början hade vi bara tänkt använda den själva i universitetsvärlden. Men det var andra som kom till oss och tyckte att den var en trevlig öppenkods-risc.

Inom forskningsvärlden är fördelarna med öppenkodslicens uppenbara. Den tillåter dig att analysera och öppet diskutera säkerheten i en cpu, att undervisa om konstruktionen, och att vidareutveckla den. Dessutom, vidare upp i näringskedjan, att bygga effektiva verktyg och mjukvara, i sin tur också dessa eventuellt öppna. Allt dessutom utan kostnad, så att både stora små aktörer kan delta i ekosystemet.

– Varför vi väljer öppen källkod är ingen hemlighet – det är för att vi vill ha hjälp att ta fram verktyg som vi själva behöver i forskningen, säger Krste Asanović.

RISC-V tar rygg på OpenCores – den idag kanske största verksamheten kring öppenkods-hårdvara – och ser till att dess periferienheter kan utnyttjas i systemkretsar kring RISC-V.

– Dessutom har vi byggt en stor mängd kärnor i våra egna projekt. De står sig mycket bra i jämförelse med de flesta öppenkodskärnor, och är dessutom beprövade i kisel. Vi kommer snart att släppa dem som öppen källkod, säger David Patterson.

Det är också möjligt att integrera RISC-V med kommersiella IP-kärnor från exempelvis Arm, Synopsys och Cadence via bussen AMBA och på så sätt få tag på bra kärnor för exempelvis PCIe, USB och SRIO.

Vad gäller mjukvaruverktyg stöds hela GNU-Linuxfamiljen: Binutils, GCC, GDB, Newlib, glibc, LLVM och Qemu.

Det är först nu RISC-V börjar göra väsen av sig – arkitekturen fick exempelvis sin Wikipediaartikel först den 25 augusti i år. Men koden har redan förfinats och optimerats under tre år. Den första Isa-manualen till RISC-V publicerades redan år 2011.

Åtta tapeouts i 45 och 28 nm har hittills gjorts på RISC-V-versioner med vektoracceleratorer. I 45 nm har man lyckats köra cpu:n i 1,65 GHz och vektoracceleratorn i 1,35 GHz. I 28 nm har man kommit upp i 1 GHz och använt drivspänning ner till 0,48 V.

Också alternativa implementationer av RISC-V har påbörjats. Först att planera volymtillverkning – av 64-bitarsversionen Rocket – är Cambridge-universitetet. Projektet heter Lowrisc och i projektet hittar man en av grundarna till Raspberry Pi.

Lowrisc planerar för tillverkning i 40 och 28 nm och hoppas på klockfrekvenser upp till 1,0 respektive 1,5 GHz och en prisnivå på tio dollar.

Amerikanska EDA-företaget Bluespec implementerar just nu RISC-V i sina syntesverktyg.

Indiska universitetet IIT-Madras utvecklar en bred familj om sex processorer på RISC-V, från styrkretsar till superdatorer.

– Det demonstrerar en del av RISC-filosofin som är att en och samma Isa ska kunna användas i alla typer av enheter. Om man bara konstruerar noggrant så blir kostnaden inte så hög för de små systemen, säger Krste Asanović.

Institutionen hade först tänkt använda arkitekturen IBM Power, men bytte till RISC-V för ett år sedan.

Berkeleys eget fokus är asic­implementationer,  men det finns också ett externt projekt som utvecklar en LUT-minimerad implementation av RISC-V för FPGA-användning.

BEHÖVS VERKLIGEN ÄNNU EN ÖPPENKÄRNA? Elektroniktidningen bad några experter  att ta en titt på RISC-V.  Alla applåderade initiativet, men ställde också kritiska frågor. FPGA-utvecklare: Det finns redan flera öppenkodsrisc-kärnor därute – som Leon, LM32 och Openrisc – varför inte förbättra dem istället? –  Det skulle kanske varit en möjlighet. Men de har alla allvarliga brister i sin arkitektur. Dessutom har jag svårt att tro att vi skulle kunna ansluta oss till en öppen organisation och övertala de aktiva att ändra instruktionsuppsättningen radikalt genom att hävda att vi tycker att den är bristfällig, säger David Patterson. – Vår förhoppning är snarare att några av dem kommer att omfamna oss. Och vi försöker aktivt få det att hända. –  Många projekt med öppna kärnor har varit fixerade vid att utveckla en specifik enkel kärna och konstruerat en Isa runt den, kommenterar Krste Asanović. – Istället för den approachen – som är från typ 40–50-talet – så följer vi den snäppet modernare approach som började användas för IBM360 i mitten av 60-talet – vi konstruerar en Isa som är skalbar över en bred uppsättning implementationer. CPU-konstruktör: För att vara intressant kommersiellt krävs support från de verktyg som utvecklarna är vana vid. – Vi har GNU-verktygen. Dem är kommersiella kunder vana vid, säger David Patterson. Asicutvecklare: Det finns redan gratiskärnor från FPGA-tillverkarna. – Vi brukade själva använda Mic­roblaze, men var inte nöjda. Vårt verktygsstöd är minst lika bra, säger David Patterson. – Om det enda du vill göra är att sätta en liten styrkrets på en FPGA – då kan det fungera bra med tillverkarnas egna kärnor. Men utanför det begränsade tillämpningsområdet är deras verktygsstöd dåligt, säger Krste Asanović. Asicutvecklare: Ni använder ett eget hårdvaruspråk, Chisel, som inte har så många användare. –  Chisel växer i popularitet efter­som det är mycket mer produktivt än Verilog och System Verilog, och eftersom folk gillar det – även en del som inte är intresserade av RISC-V. Det går dessutom att inkludera Verilogmoduler i Chisel, säger David Patterson. – Det finns dessutom RISC-V-kärnor i andra projekt som byggs i Verilog, VHDL eller Bluespec, säger Krste Asanović. FPGA-utvecklare: Var är källkoden? Forskare brukar producera oanvändbar källkod. –  Det är i och för sig svårt att uttala sig om kvaliteten innan du sett den. En av orsakerna till att vi inte släppt den ännu är att vi håller på att städa upp i koden, säger David Patterson. – Städningen handlar om att ta bort NDA-känsligt material, flytta runt saker, ordna så att den fungerar out of the box och se till att den har rätt licenser, säger Yunsup Lee, en av en av författarna till den första RISC-V-manualen som släpptes 2011. –  För övrigt gör språket Chisel att koden blir kortare, tydligare och lättare att modifiera och underhålla än de andra hårdvaruspråken, möjligen med undantag av Bluespec, säger Krste Asanović. FPGA-utvecklare: Var är prestandasiffrorna? – Vi jobbar på dem, säger David Patterson.