lowRISC: The path to an open source SoC

My slides from my FOSDEM talk on lowRISC

https://fosdem.org/2015/schedule/event/lowrisc/
https://fosdem.org/2015/interviews/2015-alex-bradbury/

Transcript

1. lowRISC: The path to an open source SoC Alex Bradbury asb@lowrisc.org @asbradbury @lowRISC FOSDEM 31/01/15
2. 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
3. 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
4. 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
5. 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 • ...
6. • 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
7. • 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
8. System diagram for test chip
9. • 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
10. Supporting tagged memory
11. • 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
12. System diagram for test chip
13. • 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
14. • 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
15. • 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
16. • 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’
17. • 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
18. • 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
19. • “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
20. • 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
21. • 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. asb@lowrisc.org @asbradbury @lowRISC Get involved