lowRISC: The path to an open source SoC Alex Bradbury [email protected] @asbradbury @lowRISC FOSDEM 31/01/15 

Beginnings and motivation ● Aim to produce volume silicon for a complete open source SoC. Run Linux ‘well’ ● Started Summer 2014 as a non-profit project based at University of Cambridge Computer Laboratory ● Previous experience with Raspberry Pi ● Why? ○ Teaching and research ○ Demand from industry ○ Startups and innovation 

The opportunity ● Clean slate design ● Technology scaling is slowing ● Cores are free and customisable ● Free from commercial influences and release cycles. Aim to maximise functionality (no product range) ● Open source community 

RISC-V ● An open instruction set architecture, originally from UC Berkeley ● 32-bit, 64-bit, 128-bit(!) variants ● Explicitly designed for extension ● Base integer ISA has ~40 instructions ● Ports (so far) for GCC, LLVM, Linux, Coreboot, ... ● Berkeley ‘Rocket’ core - silicon proven (28nm+45nm) ● See http://riscv.org 

What’s involved in producing a chip? ● Licensing of tools+IP (peripherals, PDK, PHYs) ● Design logic in HDL of choice (Verilog, VHDL, Chisel, ...) ● Synthesise, simulate, test, iterate ● Physical design (place and route, clock tree synthesis, physical verification) ● Integration of third-party IP ● Design of IC package ● Test chip via multi-project wafer service ● Volume production ● ... 

● Arduino (circuit board design) and Reprap (mechanical design) have great success. Where’s the open silicon? ● Challenges: ○ High fixed costs ○ Long development cycles ○ Verification - you can’t patch hardware ○ Finding talent These challenges highlight the potential upside of an open, known-good SoC design. It’s called hardware because it’s hard 

● Simple reusable components rather than single- purpose solutions ● Build on Berkeley’s Rocket RISC-V core ● Expose interesting new features ● Develop out in the open as much as possible ● Multiple volume silicon runs ● Initial volume target: a low cost development board. ‘Raspberry Pi for grownups’ Approach 

System diagram for test chip 

● Associate tags (metadata) with each memory location ● Initial motivation is prevention of control-flow hijacking attacks (still a major attack surface) ○ Provide protection for code pointers. i.e. set tag bit => read-only ● Low overhead implementation. Tag bits copied to L1/L2 and on-chip tag cache ● Exploring 2-bit tags (~3% storage overhead) Tagged memory 

Supporting tagged memory 

● Infinite memory watchpoints ● Better version of traditional canaries ● Garbage collection ● Accelerate debug/performance tools (e.g. Google *Sanitizer) ● Per-word lock bits or full/empty bits for synchronisation ● Mark valid targets of indirect branches Tagged memory - beyond security 

System diagram for test chip 

● Motivation ○ Soft peripherals ○ I/O preprocessing/filtering ○ Offload fine-grain tasks e.g. security policies, debug, performance monitoring ○ Secure, isolated execution ○ Virtualized devices ● Everything old is new again ○ CDC6600, TI PRUs, Ubicom IP3000, XMOS, NXP LPC4370, Motorola (e)TPU, Parallax Propeller Minion cores 

● Predictable timing ● Local scratchpad memory ● I/O ‘shim’ ○ Logic to aid shift in/out, parallel load, buffer data, provide clocks, assign pins to minions ● Low-latency path between main cores and minions ○ May carry cache misses, branch mispredictions Minion cores - architecture 

● Tagged memory, but also hopes for… ● Secure boot ● Crypto accelerators ● Encrypted off-chip memory ● Isolated execution ● Virtualisation ● … Provide well documented, auditable (open source!) primitives to empower users to protect their privacy. Security features 

● The Cathedral and the Bazaar - want to be a truly open project ● Case 1: Source is open, but development happens behind closed doors ● Case 2: Development happens in the open, but nobody else chooses to take part ● Case 3: Open source and open development, with a community of external contributors Project directions: ‘open to the core’ 

● Make it easier for people to contribute ● “I’m experienced at writing software - can I start writing hardware too?” ● Opportunity to go far beyond what you get in the datasheets and manuals of current commercial offerings ● Formal specification Project directions: documentation 

● Computer architecture: a science of tradeoffs ● Move towards larger scale benchmarks ● Evaluate options with openly shared experiments, which can be revisited as the tradeoffs change ● Develop into a powerful tool for computer architecture research ● Hardware/software co-design Project directions: data-driven development 

● “Software is eating the world” ● No such thing as a pure hardware project, and lowRISC never intended to be ● Masses of interesting software work ● Harness new hardware features ● lowRISC-specific and more general RISC-V work ● Upstreaming and working with existing projects Project directions: software 

● Q1 2015 - Tagged memory (FPGA) ● Q2 2015 - Minion cores (FPGA) ● End 2015 - Dual-core test chip with integrated memory PHY, minions, 28nm or 40nm ● First volume run 2016/2017 Roadmap 

● See www.lowrisc.org for ○ Announcement + development discussion lists ○ Memo with many more details on tagged memory and minions ○ More as the project develops ● irc.oftc.net #lowRISC ● Thinking about performance counters, debug, interrupt controllers, ... ● Keen to receive feedback, explore collaborations etc. [email protected] @asbradbury @lowRISC Get involved