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
● 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
● 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
● 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
asb
hagevvashi
john_smith
line_developers
whywaita
non97
pf_businessdivision
salaboy
lmt_swallow
nishiuma
yamahiro
culvert
yoshiiryo1
denniskardys
keathley
danielanewman
revolveconf
edds
mongodb
iamctodd
trishagee
jasonvnalue
malarkey
kevinliebholz
samlambert