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
slowing • Cores are free and customisable • Free from commercial influences and release cycles. Aim to maximise functionality (no product range) • Open source community
(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 • ...
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
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
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
◦ 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
• 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
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’
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
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
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
◦ 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