An update on lowRISC Alex Bradbury [email protected] @asbradbury @lowRISC ORConf 09/10/15 

One year on... 

Talk structure 1. What is lowRISC? 2. Recent developments 3. What's next? 

What is lowRISC ● A not-for-profit, open project ● An open source SoC that 'runs Linux well' ● A platform, on which others can base derivative designs ● Built using RISC-V (see Krste's talk!) ● Follows on from Raspberry Pi experience ● Technical focuses: flexibility and security 

The lowRISC approach ● Produce low-cost development boards – 'Raspberry Pi for grownups' ● Regular tape-outs. Not just a one-off effort ● Form collaborations. We can't do this alone ● Initial funding from private donor, recently from Google. Eventually self-sustaining ● Simple, permissive licensing ● How can we succeed where others have struggled? 

Motivation and philosophy ● A shared technology investment in an open SoC platform can boost innovation and productivity in the field ● Increase diversity and competition ● The best chance of replicating the success of Linux comes from outside the existing commercial players ● Allow groups (academic and industry) to focus on the 20% of the design that really matters 

We (all) will have been successful when ● Use of open source hardware designs is as common and accepted as for open source software ● A rich, international ecosystem ● Standard reference platforms for realistic SoCs, used by industry and academia. Complete SoC with all digital logic open ● There is a way for people to see their contributions in real hardware designs ● Non-aims: monoculture, eradication of all non-open IP from the face of the Earth 

The lowRISC platform Flexible minion core design ● Software-defined I/O interfaces ● Isolated execution ● Pre-processing I/O streams ● Low-power monitoring of I/O Tagged memory for security and other applications ● An end to control-flow hijacking attacks ● Flexible security policies ● Initial implementation released 

Developments: tagged memory Augment each 64-bit word with tag bits Augmented cache line is transparent to coherence control. Memory is partitioned into data and tag regions. Without an extra tag cache, memory traffic would be doubled (a data access and an extra tag access) Credit: Wei Song 

Developments: Summer of Code ● Google Summer of Code mentoring organisation ● Supported 6 projects + 2 local interns ● See talks from Hesham (seL4) and Sebastian (rump kernels and minion cores) and Sebastian (jor1k) ● Completed prototype LLVM pass for protecting control flow using tagged memory ● +more (see blog over next few weeks) 

Developments: collaborations+growth ● PULP (see talks later on in the day) ● Debug (see Stefan's talk tomorrow) ● Community input and contributions ● See phab.lowrisc.org and mailing list ● Growth of the core Cambridge-based team 

Developments: untethered SoC Credit: Wei Song 

Next milestones ● Complete untethering – Package up a release+instructions ● Integration of PULP-based minion cores ● Tag cache optimisations 

Towards the first test chip ● Aim to tape-out next year ● 2-4 cores, LPDDR2/3 memory interface, USB, Ethernet? ● 28nm/40nm ● The third party IP conundrum ● Interested in exploring open solutions for packaging, tools/flow, access to IP 

Discussion points ● Security features, beyond tagged memory ● Hypervisors and I/O abstraction ● Developing the community ● PULP integration and minion cores ● The first lowRISC tape-out ● Debug ● Software stack development ● Collaborations ● Conducting research in the open ● $YOUR_TOPIC_HERE 

Conclusion ● A final reflection: room for improvement? ● Thank you – Donors, contributors, collaborators, technical advisory board, supporters ● Questions? ● See also: lowrisc.org, our mailing list, phab.lowrisc.org ● Email: [email protected] ● Stickers!