lowRISC: The path to an open source SoC

Transcript

1. 1.

   lowRISC: The path to an open source SoC Alex Bradbury

   asb@lowrisc.org @asbradbury @lowRISC FOSDEM 31/01/15
2. 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. 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. 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. 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. 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. 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. 8.

   System diagram for test chip

9. 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. 10.

    Supporting tagged memory

11. 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. 12.

    System diagram for test chip

13. 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. 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. 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. 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. 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. 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. 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. 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. 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