Tutorial	  Introduc.on	  Krste	  Asanović	  krste@eecs.berkeley.edu	  http://www.riscv.org	  RISC-­‐V	  Tutorial,	  HPCA,	  SFO	  Marriot	  February	  8,	  2015	  ISAs	  don’t	  ma-er	  Most	  of	  the	  performance	  and	  energy	  running	  soLware	  on	  a	  computer	  is	  due	  to:	  § Algorithms	  § Applica.on	  code	  § Compiler	  § OS/Run.mes	  § ISA	  (Instruc.on	  Set	  Architecture)	  § Microarchitecture	  (core	  +	  memory	  hierarchy)	  § Circuit	  design	  § Physical	  design	  § Fabrica.on	  process	  In	  a	  system,	  there’s	  also	  displays,	  radios,	  DC/DC	  convertors,	  sensors,	  actuators,	  …	  2

ISAs	  do	  ma-er	  § Most	  important	  interface	  in	  computer	  system	  § Large	  cost	  to	  port	  and	  tune	  all	  ISA‑dependent	  parts	  of	  a	  modern	  soLware	  stack	  § Large	  cost	  to	  recompile/port/QA	  all	  supposedly	  ISA‑independent	  parts	  of	  stack	  § Proprietary	  closed-­‐source,	  don’t	  have	  code	  § Bit	  rot,	  lose	  ability	  to	  compile	  own	  source	  code	  § Lost	  your	  own	  source	  code	  § Most	  of	  the	  cost	  of	  developing	  a	  new	  chip	  is	  developing	  soLware	  for	  it	  § Most	  big	  new	  chips	  have	  several	  ISAs…	  	  3So…	  If	  choice	  of	  ISA	  doesn’t	  have	  much	  impact	  on	  system	  energy/performance,	  and	  it	  costs	  a	  lot	  to	  use	  diﬀerent	  ones,	  	  why	  isn’t	  there	  just	  one	  industry-­‐standard	  ISA?	  	  	  	  	  	  
4ISAs	  Should	  Be	  Free	  and	  Open	  While	  ISAs	  may	  be	  proprietary	  for	  historical	  or	  business	  reasons,	  there	  is	  no	  good	  technical	  reason	  for	  the	  lack	  of	  free,	  open	  ISAs:	  	  § It’s	  not	  an	  error	  of	  omission.	  
§ Nor	  is	  it	  because	  the	  companies	  do	  most	  of	  the	  soLware	  development.	  
§ Neither	  do	  companies	  exclusively	  have	  the	  experience	  needed	  to	  design	  a	  competent	  ISA.	  
§ Nor	  are	  the	  most	  popular	  ISAs	  wonderful	  ISAs.	  
§ Neither	  can	  only	  companies	  verify	  ISA	  compa.bility.	  
§ Finally,	  proprietary	  ISAs	  are	  not	  guaranteed	  to	  last.	  Beneﬁts	  from	  Viable	  Freely	  Open	  ISA	  § Greater	  innova+on	  via	  free-­‐market	  compe++on	  from	  many	  core	  designers,	  closed-­‐source	  and	  open-­‐source.	  
§ Shared	  open	  core	  designs,	  shorter	  .me	  to	  market,	  lower	  cost	  from	  reuse,	  fewer	  errors	  given	  more	  eyeballs,	  transparency	  makes	  it	  diﬃcult	  for	  government	  agencies	  to	  add	  secret	  trap	  doors.	  	  § Processors	  becoming	  aﬀordable	  for	  more	  devices,	  which	  would	  help	  expand	  the	  Internet	  of	  Things	  (IoTs),	  which	  could	  cost	  as	  lible	  as	  $1.	  	  § So;ware	  stacks	  survive	  for	  long	  +me	  upgrade	  soLware	  on	  systems	  embedded	  in	  concrete	  50	  years	  ago	  § Make	  architecture	  research	  and	  educa+on	  more	  real	  with	  fully	  open	  hardware	  and	  soLware	  stacks	  What	  Style	  of	  ISA?	  
§ If	  ISA	  doesn’t	  maber,	  then	  pick	  an	  easy-­‐to-­‐implement,	  eﬃcient	  ISA	  § Seymour	  Cray’s	  50-­‐year-­‐old	  load-­‐store	  design,	  reﬁned	  by	  RISC	  research	  30+	  years	  ago,	  s.ll	  a	  good	  choice	  7

ISA	  innovaAon	  over	  last	  30	  years?	  
§ Load-­‐store	  ISAs	  predate	  Moore’s	  Law	  § Very	  lible	  (nothing?)	  stuck	  for	  general-­‐purpose	  code,	  failures:	  - CISC	  (microcode	  worse	  than	  instruc.on	  cache	  in	  VLSI)	  - Stack	  machines	  (compiler	  can	  target	  registers)	  - VLIW	  (dynamic	  predictors	  beat	  sta.c	  scheduling)	  § Industry	  has	  reconverged	  on	  simpler	  RISC	  ideas:	  - ARM	  v8,	  MIPS	  r6,	  both	  similar	  ideas	  to	  RISC-­‐V	  § Specialized	  Accelerators?	  Only	  way	  to	  improve	  performance	  un.l	  post-­‐CMOS	  (20-­‐30	  years	  away)	  - G.	  Estrin,	  "Organiza.on	  of	  computer	  systems:	  the	  ﬁxed	  plus	  variable	  structure	  computer,"	  Proc.	  WJCC,	  1960	  - GPUs	  –	  bad	  version	  of	  Cray	  vectors	  	  8Other	  Open	  ISAs	  § SPARC	  V8	  -­‐	  To	  its	  credit,	  Sun	  Microsystems	  made	  SPARC	  V8	  an	  IEEE	  standard	  in	  1994.	  	  Sun,	  Gaisler	  oﬀered	  open-­‐source	  cores.	  ISA	  now	  owned	  by	  Oracle.	  
§ OpenRISC	  -­‐	  GNU	  open-­‐source	  eﬀort	  started	  in	  1999,	  based	  on	  DLX.	  64-­‐bit	  ISA	  was	  in	  progress.	  
§ Open	  Processor	  Founda+on	  -­‐	  Patents	  expiring	  on	  Hitachi	  SH	  architecture,	  so	  open-­‐sourcing	  tools	  and	  implementa.ons	  § LaHce	  Micro	  32	  (LM32)	  –	  Simple	  FPGA	  soL	  core.	  
§ All	  RISC	  ISAs	  RISC-­‐V	  Background	  § In	  2010,	  aLer	  many	  years	  and	  many	  projects	  using	  MIPS,	  SPARC,	  and	  x86	  as	  basis	  of	  research,	  .me	  to	  look	  at	  	  ISA	  for	  next	  set	  of	  projects	  § Obvious	  choices:	  x86	  and	  ARM	  § x86	  impossible	  –	  too	  complex,	  IP	  issues	  Intel	  x86	  “AAA”	  InstrucAon	  § ASCII	  Adjust	  ALer	  Addi.on	  § AL	  register	  is	  default	  source	  and	  des.na.on	  § If	  the	  low	  nibble	  is	  >	  9	  decimal,	  or	  the	  auxiliary	  carry	  ﬂag	  AF	  =	  1,	  then	  - Add	  6	  to	  low	  nibble	  of	  AL	  and	  discard	  overﬂow	  - Increment	  high	  byte	  of	  AL	  - Set	  CF	  and	  AF	  § Else	  - CF	  =	  AF	  =	  0	  § Single	  byte	  instruc.on	  11

RISC-­‐V	  Background	  § In	  2010,	  aLer	  many	  years	  and	  many	  projects	  using	  MIPS,	  SPARC,	  and	  x86	  as	  basis	  of	  research,	  .me	  to	  look	  at	  	  ISA	  for	  next	  set	  of	  projects	  § Obvious	  choices:	  x86	  and	  ARM	  § x86	  impossible	  –	  too	  complex,	  IP	  issues	  § ARM	  mostly	  impossible	  	  -­‐	  complex,	  IP	  issues	  § So	  we	  started	  “3-­‐month	  project”	  in	  summer	  2010	  to	  develop	  our	  own	  clean-­‐slate	  ISA	  § Four	  years	  later,	  we	  released	  frozen	  base	  user	  spec	  - But	  also	  many	  tapeouts	  and	  several	  research	  publica.ons	  along	  the	  way	  2015	  RISC-­‐V	  Project	  Goal	  Become	  the	  industry-­‐standard	  ISA	  for	  all	  compu.ng	  devices	  13

RISC-­‐V	  is	  NOT	  an	  Open-­‐Source	  Processor	  § RISC-­‐V	  is	  an	  ISA	  speciﬁca.on	  § Will	  be	  expanding	  to	  be	  speciﬁca.ons	  for	  SoCs	  including	  I/O	  and	  accelerators	  § Most	  of	  cost	  of	  chip	  design	  is	  in	  soLware,	  so	  want	  to	  make	  sure	  soLware	  can	  be	  reused	  across	  many	  chip	  designs	  § Want	  to	  encourage	  both	  open-­‐source	  and	  proprietary	  	  	  implementa.ons	  of	  the	  RISC-­‐V	  ISA	  speciﬁca.on	  14

RISC-­‐V	  Base	  Plus	  Standard	  Extensions	  § Three	  base	  integer	  ISAs,	  one	  per	  address	  width	  - RV32I,	  RV64I,	  RV128I	  - Only	  40	  hardware	  instruc.ons	  needed	  § Standard	  extensions	  - M:	  Integer	  mul.ply/divide	  - A:	  Atomic	  memory	  opera.ons	  (AMOs	  +	  LR/SC)	  - F:	  Single-­‐precision	  ﬂoa.ng-­‐point	  - D:	  Double-­‐precision	  ﬂoa.ng-­‐point	  - G	  =	  IMAFD,	  “General-­‐purpose”	  ISA	  - Q:	  Quad-­‐precision	  ﬂoa.ng-­‐point	  § All	  the	  above	  are	  a	  fairly	  standard	  RISC	  encoding	  in	  a	  ﬁxed	  32-­‐bit	  instruc.on	  format	  § Now	  frozen	  15In the base ISA, there are four core instruction formats (R/I/S/U), as shown in Figure 2.2. All area fixed 32 bits in length and must be aligned on a four-byte boundary in memory. An instruction
address misaligned exception is generated if the pc is not four-byte aligned on an instruction fetch.

RISC-­‐V	  Standard	  Base	  ISA	  Details	  

31

25 24

funct720 19

rs2

imm[11:0]
imm[11:5]

rs2
imm[31:12]

15 14

12 11

7 60

rs1

funct3rd

opcodeR-typers1funct3rd

opcodeI-typers1funct3

imm[4:0]

opcodeS-typerd

opcodeU-type§ 32-­‐bit	  ﬁxed-­‐width,	  aturally	  ligned	  instruc.ons	  Figure 2.2: nRISC-V
baseainstruction
formats.
§ 31	  integer	  registers	  x1-­‐x31,	  plus	  x0	  zero	  register	  The RISC-V ISA keeps the source (rs1 and rs2) and destination (rd) registers at the same position
in all formats
simplify decoding.
Immediates
are packed
the leftmost available bits in§ No	  toimplicit	  registers,	  rs1/rs2/rd	  in	  ﬁtowards
xed	  loca.on	  the instruction and have been allocated to reduce hardware complexity. In particular, the sign bit§ Floa.ng-­‐point	  adds	  f0-­‐f31	  registers	  plus	  FP	  CSR,	  also	  for all immediates is always in bit 31 of the instruction to speed sign-extension circuitry.

fused	  mul-­‐add	  four-­‐register	  format	  Decoding
register specifiers
is usually P
onIC	  theand	  criticalpaths in implementations,and so the in§ Designed	  to	  support	  dynamic	  linking	  struction format was chosen to keep all register specifiers at the same position in all formats at

the expense of having to move immediate bits across formats (a property shared with RISC-IVaka. SPUR [12]).
16
In practice, most immediates are either small or require all XLEN bits. We chose an asymmetric immediate split (12 bits in regular instructions plus a special load upper immediate instruction with 20 bits) to increase the opcode space available for regular instructions. In addition,

“A”:	  Atomic	  OperaAons	  Extension	  Two	  classes:	  § Atomic	  Memory	  Opera.ons	  (AMO)	  - Fetch-­‐and-­‐op,	  op=ADD,OR,XOR,MAX,MIN,MAXU,MINU	  § Load–Reserved/Store	  Condi.onal	  - With	  forward	  progress	  guarantee	  for	  short	  sequences	  § All	  atomic	  opera.ons	  can	  be	  annotated	  with	  two	  bits	  (Acquire/Release)	  to	  implement	  release	  consistency	  or	  sequen.al	  consistency	  17Why	  do	  SoCs	  have	  so	  many	  ISAs?	  
§ Applica.ons	  processor	  (usually	  ARM)	  § Graphics	  processors	  § Image	  processors	  § Radio	  DSPs	  § Audio	  DSPs	  § Security	  processors	  § Power	  management	  processor	  § IP	  bought	  from	  diﬀerent	  places,	  each	  proprietary	  ISA	  § Home-­‐grown	  ISA	  cores	  § Apps	  processor	  ISA	  too	  huge	  for	  base	  accelerator	  ISA	  § Rebuild	  whole	  soLware	  stack	  for	  each	  ISA	  to	  speed	  up	  <1%	  of	  the	  total	  code!!!	  

18

Variable-­‐Length	  Encoding	  Byte Address:

xxxxxxxxxxxxxxaa

16-bit (aa 6= 11)xxxxxxxxxxxxxxxx

xxxxxxxxxxxbbb11

32-bit (bbb 6= 111)

· · ·xxxx

xxxxxxxxxxxxxxxx

xxxxxxxxxx011111

48-bit· · ·xxxx

xxxxxxxxxxxxxxxx

xxxxxxxxx0111111

64-bit· · ·xxxx

xxxxxxxxxxxxxxxx

xnnnxxxxx1111111(80+16*nnn)-bit, nnn6=111· · ·xxxx

xxxxxxxxxxxxxxxx

x111xxxxx1111111

Reserved forbase+4base+2base

192-bits§ Extensions	  can	  use	  any	  mul.ple	  of	  16	  bits	  as	  Figure 1.1: RISC-V instruction length encoding.

instruc.on	  length	  § Branches/Jumps	  target	  16-­‐bit	  boundaries	  even	  in	  ﬁxed	  32-­‐bit	  base	  19

“C”:	  Compressed	  InstrucAon	  Extension	  § Compressed	  code	  important	  for:	  - low-­‐end	  embedded	  to	  save	  sta.c	  code	  space	  - high-­‐end	  commercial	  workloads	  to	  reduce	  cache	  footprint	  § Standard	  extension	  (s.ll	  in	  draL,	  not	  frozen)	  adds	  16-­‐bit	  compressed	  instruc.ons	  - 2-­‐address	  forms	  with	  all	  32	  registers	  - 	  3-­‐address	  forms	  with	  most	  frequent	  8	  registers	  § Each	  C	  instruc.on	  expands	  to	  a	  single	  base	  ISA	  instruc.on	  § All	  original	  32-­‐bit	  instruc.ons	  retain	  encoding	  but	  now	  can	  be	  16-­‐bit	  aligned	  § Approximately	  25%	  reduc.on	  in	  code	  size,	  with	  performance	  improvement	  from	  reduced	  I$	  misses	  20

1.1draft: Volume
II: RISC-V Privileged
RISC-­‐V	  Privileged	  Architecture	   Architectures

2Application
ABI
AEE

Application Application
ABI
ABI
OS
SBI
SEE

Application Application Application Application
ABI
ABI
ABI
ABI
OS
OS
SBI
SBI
Hypervisor
HBI
HEE

Provide	  clean	  split	  between	  layers	  of	  the	  soLware	  stack	  § Applica.on	  communicates	  with	  Applica.on	  Execu.on	  the OS, which provides the AEE. Just as applications interface with an AEE via an ABI, RISC-V
operatingsystems interface(witha supervisor
execution environment(SEE)
via a supervisor
binaryEnvironment	  AEE)	  via	  Applica.on	  Binary	  Interface	  (ABI)	  interface (SBI). An SBI comprises the user-level and supervisor-level ISA together with a set ofOS	  communicates	  ia	  acrossSupervisor	  Execu.on	  Environment	  SBI§ function
calls. Using a single v
SBI
all SEE implementations
allowsa single OS binary
image to run on any SEE. The SEE can be a simple boot loader and BIOS-style IO system in a(SEE)	  via	  System	  Binary	  Interface	  (SBI)	  low-end hardware platform, or a hypervisor-provided virtual machine in a high-end server, or athinlayer overa host operating systemarchitecture simulation§ translation
Hypervisor	  communicates	  via	  inHanypervisor	  Binary	  environment.
Interface	  to	  Hypervisor	  Execu.on	  Environment	  The rightmost
configurationshows a virtualmachine monitor
configuration where multiple multiprogrammed OSs are supported by a single hypervisor. Each OS communicates via an SBI with the§ All	  levels	  of	  ISA	  designed	  to	  support	  virtualiza.on	  hypervisor, which provides the SEE. The hypervisor communicates with the hypervisor execution
Figure1.1: Di↵erent implementation stacks supporting various forms of privileged execution.
§environment (HEE) using a hypervisor binary interface, to isolate the hypervisor from details21
ofthe hardware platform.

OS or hypervisor, and which can also be shared with the boot environment.

Hardware implementations of the RISC-V ISA will generally require additional features beyond theprivileged ISA to support the various execution environments (AEE, SEE, or HEE), but these we
consider separately as part of a hardware abstraction layer (HAL), as shown in Figure 1.2. NoteRISC-­‐V	  Hardware	  AbstracAon	  Layer	  Application
ABIAEE
HAL
HardwareApplication Application
ABI
ABI
OS
SBI
SEE
HAL
HardwareApplication Application Application Application
ABI
ABI
ABI
ABI
OS
OS
SBI
SBI
Hypervisor
HBI
HEE
HAL
HardwareExecu.on	  environments	  communicate	  with	  hardware	  plazorms	  via	  Hardware	  Abstrac.on	  Layer	  (HAL)	  Figure 1.2: Hardware abstraction layers (HALs) abstract underlying hardware platforms from the§
execution environments.

§ Details	  of	  execu.on	  environment	  and	  hardware	  plazorms	  isolated	  from	  OS/Hypervisor	  ports	  22

Four	  Supervisor	  Architectures	  § Mbare	  - Bare	  metal,	  no	  transla.on	  or	  protec.on	  § Mbb	  - Base	  and	  bounds	  protec.on	  § Sv32	  - Demand-­‐paged	  32-­‐bit	  virtual	  address	  spaces	  § Sv43	  - Demand-­‐paged	  43-­‐bit	  virtual	  address	  spaces	  § Designed	  to	  support	  current	  popular	  opera.ng	  systems	  § Where’s	  the	  draL	  spec????	  

- This	  is	  taking	  some	  .me,	  very	  soon	  now.	  
- It	  won’t	  be	  ﬁnalized	  for	  a	  while,	  since	  we	  need	  feedback	  23

RISC-­‐V	  Ecosystem	  www.riscv.org§ Documenta+on	  § Hardware	  Tools	  - User-­‐Level	  ISA	  Spec	  v2	  - Zynq	  FPGA	  Infrastructure	  - Reviewing	  Privileged	  ISA	  - Chisel	  § So;ware	  Tools	  § So;ware	  Implementa+ons	  - GCC/glibc/GDB	  - ANGEL,	  JavaScript	  ISA	  Sim.	  
- LLVM/Clang	  - Spike,	  In-­‐house	  ISA	  Sim.	  
- Linux	  - QEMU	  - Yocto	  § Hardware	  Implementa+ons	  - Veriﬁca.on	  Suite	  - Rocket	  Chip	  Generator	  - RV64G	  single-­‐issue	  in-­‐order	  pipe	  - Sodor	  Processor	  Collec.on	  RISC-­‐V	  Outside	  Berkeley	  § Adopted	  as	  “standard	  ISA”	  for	  India.	  	  IIT-­‐Madras	  building	  6	  diﬀerent	  open-­‐source	  cores,	  from	  microcontrollers	  to	  servers	  § Bluespec	  Inc.	  developing	  RISC-­‐V	  cores	  for	  use	  in	  .ghtly	  integrated	  hardware/soLware	  IP	  blocks	  § LowRISC	  project	  based	  in	  Cambridge,	  UK	  producing	  open-­‐source	  RISC-­‐V	  based	  SoCs.	  Led	  by	  one	  of	  the	  founders	  of	  Raspberry	  Pi,	  and	  privately	  funded	  § First	  commercial	  RISC-­‐V	  cores	  have	  already	  shipped!	  
§ Mul.ple	  commercial	  silicon	  implementa.ons	  for	  sale	  later	  this	  year	  25

RISC-­‐V	  FoundaAon	  § In	  progress,	  establishing	  a	  non-­‐proﬁt	  RISC-­‐V	  founda.on	  “to	  standardize,	  protect,	  and	  promote	  the	  free	  and	  open	  RISC-­‐V	  instruc;on	  set	  architecture	  and	  its	  hardware	  and	  so=ware	  ecosystem	  for	  use	  in	  all	  compu;ng	  devices.”	  § Expect	  to	  have	  RISC-­‐V	  founda.on	  up	  and	  running	  by	  .me	  of	  second	  RISC-­‐V	  workshop	  in	  Berkeley,	  summer	  2015	  § Sign	  up	  on	  mailing	  lists	  or	  twiber	  at	  riscv.org	  to	  get	  announcements	  26

HPCA/CGO/PPoPP	  Tutorial	  Goals	  § Bring	  academic	  community	  up	  to	  speed	  on	  RISC-­‐V	  developments	  and	  tools	  ecosystem	  § Agenda:	  - Intro,	  Krste	  Asanovic	  - “Rocket	  Chip”	  SoC	  generator	  overview,	  Yunsup	  Lee	  - RISC-­‐V	  soLware	  stack	  overview,	  Palmer	  Dabbelt	  - Break	  - RISC-­‐V	  soLware	  bootcamp,	  Albert	  Ou	  - Rocket	  bootcamp,	  Colin	  Schmidt	  	  	  27

RISC-­‐V	  Research	  Project	  Sponsors	  § DoE	  Isis	  Project	  § DARPA	  PERFECT	  program	  § DARPA	  POEM	  program	  (Si	  photonics)	  § STARnet	  Center	  for	  Future	  Architectures	  (C-­‐FAR)	  § Lawrence	  Berkeley	  Na.onal	  Laboratory	  § Industrial	  sponsors	  (ParLab	  +	  ASPIRE)	  - Intel,	  Google,	  Huawei,	  LG,	  NEC,	  MicrosoL,	  Nokia,	  NVIDIA,	  Oracle,	  Samsung	  28