.................................................................................................................................................................................................................

AN AGILE APPROACH TO BUILDING
RISC-V MICROPROCESSORS.................................................................................................................................................................................................................

THE AUTHORS ADOPTED AN AGILE HARDWARE DEVELOPMENT METHODOLOGY FOR 11
RISC-V MICROPROCESSOR TAPE-OUTS ON 28-NM AND 45-NM CMOS PROCESSES. THIS

Yunsup Lee
ENABLED SMALL TEAMS TO QUICKLY BUILD ENERGY-EFFICIENT, COST-EFFECTIVE, AND
Andrew Waterman
COMPETITIVE HIGH-PERFORMANCE MICROPROCESSORS. THE AUTHORS PRESENT A CASE
Henry CookSTUDY OF ONE PROTOTYPE FEATURING A RISC-V VECTOR MICROPROCESSOR INTEGRATEDBrian Zimmer
WITH SWITCHED-CAPACITOR DC–DC CONVERTERS AND AN ADAPTIVE CLOCK GENERATOR
Ben Keller
IN A 28-NM, FULLY DEPLETED SILICON-ON-INSULATOR PROCESS.
Alberto Puggelli
Jaehwa Kwak
The era of rapid transistor per- in software development, demarcated by theRuzica Jevtić formance improvement is coming to an end, publication of The Agile Manifesto in 2001.
increasing pressure on architects and circuit The philosophy of agile software development
Stevo Bailey designers to improve energy efficiency. Mod- emphasizes individuals and interactions overern systems on chip (SoCs) incorporate a large processes and tools, working software over
Milovan Blagojević and growing number of specialized hardware comprehensive documentation, customer colunits to execute specific tasks efficiently, often laboration over contract negotiation, and
Pi-Feng Chiu organized into multiple dynamic voltage and responding to change over following a plan.
clock frequency domains to further save In practice, the agile approach leads to small
Rimas Avizienis energy under varying computational loads. teams iteratively refining a set of working-butThis growing complexity has led to a design incomplete prototypes until the end result is
Brian Richards productivity crisis, stimulating development acceptable.
Inspired by the positive disruption of The
of new tools and methodologies to enable theJonathan Bachrach completion of complex chip designs on sched- Agile Manifesto on software development, we
propose a set of principles to guide a new
and within budget.
David Patterson ule We
propose leveraging lessons learned agile hardware development methodology.
the software world by applying aspects Our proposal is informed by our experiences
Elad Alon fromof the software agile development model to as a small group of researchers designing andTraditionally, software was devel- fabricating 11 processor chips in five years.
Borivoje Nikolić hardware.
oped via the waterfall development model, a Lacking the massive resources of industrial
process that consists of distinct design teams, we were forced to abandon
Krste Asanović sequential
phases that rigidly follow one another, just as standard industry practices and explore differ-......

1is done for hardware design today. Overbudget, late, and abandoned software projects
were commonplace, motivating a revolution

ent approaches to hardware design. We detailthis approach’s benefits with a case study of
one of these chips, Raven-3, which achieved

Published by the IEEE Computer Society0272-1732/16/$33.00 c 2016 IEEE.......................................................

8groundbreaking energy efficiency by integrating a novel RISC-V vector architecture withefficient on-chip DC–DC converters. Taken
together, our experiences developing these academic prototype chips make a powerful argument for the promise of agile hardware designin the post-Moore’s law era.

An Agile Hardware Manifesto
Borrowing heavily from the agile softwaredevelopment manifesto, we propose the following principles for hardware design:

Incomplete, fabricatable prototypes
over fully featured models.
Collaborative, flexible teams over rigid
silos.
Improvement of tools and generators
over improvement of the instance.
Response to change over following a
plan.

Here, we explain the importance of theseprinciples for building hardware and contrast
them with the original principles of agile software development.

Incomplete, Fabricatable Prototypes over Fully
Featured Models
We believe the primary benefit of adopting
the agile model for hardware design is that itlets us drastically reduce the cost of verification and validation by iterating throughmany working prototypes of our designs. In
this article, we use the standard definition ofverification as testing that determines whether
each component and the assembly of components correctly meets its specification (“Arewe building the thing right?”). In hardware
design, the term validation is usually narrowly applied to postsilicon testing to ensurethat manufactured parts operate within
design parameters. We use the broader and,to our minds, more useful definition of validation from the software world, in which validation ensures that the product serves its
intended purposes (“Are we building theright thing?”).
Figure 1 contrasts the agile hardware development model with the waterfall model.
The waterfall model, shown in Figure 1a,relies on Gantt charts, high-level architecture
models, rigid processes such as register-transfer level (RTL) freezes, and CPU centuries of simulations in an attempt to achieve asingle viable design point. In our agile hardware methodology, we first push a trivial prototype with a minimal working feature set all
the way through the toolflow to a point where
it could be taped out for fabrication. We referto this tape-out-ready design as a tape-in.
Then we begin adding features iteratively,
moving from one fabricatable tape-in to thenext as we add features. The agile hardware
methodology will always have an available
tape-out candidate with some subset of features for any tape-out deadline, whereas theconventional waterfall approach is in dangerof grossly overshooting any tape-out deadline
because of issues at any stage of the process.
Although the agile methodology provides
some benefits in terms of verification effort, it
particularly shines at validation; agile designs
are more likely to meet energy and performance expectations using the iterative process.
Unlike conventional approaches that use
high-level architectural models of the whole
design for validation with the intent to later
refine these models into an implementation,
we emphasize validation using a full RTL
implementation of each incomplete prototype
with the intent to add features if there is time.
Unlike high-level architectural models, theactual RTL is guaranteed to be cycle accurate.
Furthermore, the actual RTL design can be
pushed through the entire very large-scale
integration (VLSI) toolflow to give early feedback on back-end physical design issues thatwill affect the quality of results (QoR), including cycle time, area, and power. For example,
Figure 1b shows a feature F1 being reworked
into feature F10 after validation showed that it
would not meet performance or QoR goals,
whereas feature F3 was dropped after validation showed that it exceeded physical design
budgets or did not add sufficient value to theend system. These decisions on F1 and F3 canbe informed by the results of the attempted
physical design before completing the final
feature F4.
Figure 1c illustrates our iterative approachto validation of a single prototype. Eachcircle’s circumference represents the relative
time and effort it takes to begin validating adesign using a particular methodology.
Although the latency and cost of these.............................................................

MARCH/APRIL 20169

..............................................................................................................................................................................................
HOT CHIPS

F1

F2

Specification

F1

F2

DesignF1

Implementation
Verification

Validation

Tape-out

Verification

F4

Implementation

F3

DesignF2Specification

F1

(a)

F3

F4

F1’

F3

F4

F2

F1’

F3

F4

F1

F2

F1’

F3

F4

F1

F2

F1’

F3

F4

Tape-in

F1/F2 F1’/F2/F3 F1’/F2/F4

Validation

F1/F2 F1’/F2/F3 F1’/F2/F4

Tape-out

F1’/F2/F4(b)

Big tape-out
Small tape-out
Tape-in
ASIC flow
FPGA
C++Specification+ design+ implementation(c)Figure 1. Contrasting the agile and waterfall models of hardware design. The labels FN represent various desired features ofthe design. (a) The waterfall model steps all features through each activity sequentially, producing a tape-out candidate only
when all features are complete. (b) The agile model adds features incrementally, resulting in incremental tape-out candidates
as individual features are completed, reworked, or abandoned. (c) As validation progresses, designs are subjected to lengthierand more accurate evaluation methodologies.

prototype-modeling efforts increase toward
the outer circles, our confidence in the validation results produced increases in tandem.
Using fabricatable prototypes increases validation bandwidth, because a complete RTL
design can be mapped to field-programmablegate arrays (FPGAs) to run end-application
software stacks orders of magnitude fasterthan with software simulators. In agile hardware development, the FPGA models of iterative prototype RTL designs (together withaccompanying QoR numbers from the VLSI
toolflow) fulfill the same function as working
prototypes in agile software development, providing a way for customers to give early andfrequent feedback to validate design choices.
This enables customer collaboration as envisioned in the original agile software manifesto.

............................................................

10

IEEE MICRO

Collaborative, Flexible Teams over Rigid Silos
Traditional hardware design teams usually
are organized around the waterfall model,
with engineers assigned to particular functions, such as architecture specification,
microarchitecture design, RTL design, verification, physical design, and validation.
This specialization of skills is more extreme
than for pure software development, as
reflected in the specificity of designers’ job
titles (architect, hardware engineer, or verification engineer). Sometimes, entire functions, such as back-end physical design, areeven outsourced to different companies. As
the design progresses through these functional stages, extensive effort is required
to communicate design intent for eachblock, and consequently to understand thedocumentation received from the preceding
stage. Misunderstandings can lead to subtle
errors that require extensive verification toprevent, and QoR suffers because no engineer views the whole flow. End-to-end
design iterations are too expensive to contemplate. Considerable effort is required
to push high-level changes down throughthe implementation hierarchy, particularly
across company boundaries. This leads toinnovation-stunting practices such as the
RTL freeze, in which only show-stoppingbugs are allowed to unfreeze a design. In
addition, balancing the workload across thedifferent stages is difficult because engineers
focused in one functional area often lackthe training and experience to be effective
in other roles.
In the agile hardware model, engineers
work in collaborative, flexible teams that candrive a feature through all implementation
stages, avoiding most of the documentation
overhead required to map a feature to thehardware. Each team can iterate on the highlevel architectural design with full visibility
into low-level physical implementation andcan validate system-level software impacts on
an intermediate prototype. Figure 1b shows
how multiple teams can work on different
features in a pipelined fashion, each iterating
through multiple levels of abstraction (asshown in Figure 1c). A given tape-in willaccumulate some small number of feature
updates and integrate these for whole-systemvalidation. Engineers naturally develop acomplete vertical skill set, and the focus ofproject management is on prioritizing features for implementation, not communication between silos.

Improvement of Tools and Generators over
Improvement of the InstanceModern software systems could not be built
economically without the extreme reuse
enabled by extensive software libraries written in modern programming languages, orwithout functioning compilers and an automated build process. In contrast, most commercial hardware design flows rely on rather
primitive languages to describe hardware,and frequent manual intervention on tool
outputs to work around tool bugs and longtool runtimes. The poor languages and buggy

tools hinder development of truly reusable
hardware components and lead to a focus onbuilding a single instance instead of designing components that can be easily reused infuture designs.
An agile hardware methodology relies on
better hardware description languages (HDLs)
to enable reuse. Instead of constructing an
optimized instance, engineers develop highly
parameterized generators that can be used toautomatically explore a design space or to
support future use in a different design.
Better reuse is also the primary way in whichan agile hardware methodology can reduceverification costs, because the verification
infrastructure of these generators is also portable across designs.
An agile hardware methodology also strives
to eliminate manual intervention in the chip’sbuild process. Replacing or fixing the many
commercial CAD tools required to completea chip design is not practical, but most ofa chip’s flow can be effectively automatedwith sufficient effort. Perhaps the mostlabor-intensive part of a modern chip flow isdealing with physical design issues for a newtechnology node. However, most new chip
designs are in older technologies, because
only a few products can justify the cost ofusing an advanced node. Also, as technology
scaling continues to slow, back-end flows
and CAD tools will have time to matureand should become more automatable, evenfor the most advanced nodes. The end of
scaling will also coincide with a greaterneed for a variety of specialized designs,
where the agile model should show greater
benefit.
Our emphasis on tools and generators is
not at odds with the agile software development manifesto, which emphasizes collaboration over tools. Our proposed methodology
also values collaboration more than specifictools, but we feel that modern hardware
design is far less automated and exhibits far
less reuse than modern software development(or even software development in 2001).
Accordingly, there is a need to emphasize theimportance of reuse and automation enabled
by new tools in the hardware design sphere,
because few modern hardware design teams
emphasize these universally accepted software
principles.

.............................................................

MARCH/APRIL 201611

..............................................................................................................................................................................................
HOT CHIPS

Response to Change over Following a Plan
This principle mirrors the original manifesto.
Unlike software, a chip design will ultimately
be frozen into a mask set and mass-manufactured, with no scope for frequent updates.
However, even over the timeframe of a single
chip’s development, requirements will change
owing to market shifts, customer feature
additions, or standards-body deliberations.
In agile design, change can result from validation testing (as opposed to the waterfall
model, in which designs will only change in
response to verification problems).
An agile hardware development processembraces continual change in chip specifications as a means to enhance competitiveness.
Every incremental fabricatable prototype, notonly the most recent, becomes a starting
point for the changed set of design requirements, with any change treated as a reprioritization of features to implement, drop, or
rework. By first implementing features thatare unlikely to change, designers minimize
the effort lost to late changes.

Implementing the Agile Hardware
Methodology
Here, we describe the steps we took toward
implementing an agile hardware design process. All of our processors, both general purpose and specialized, were built on the free
and open RISC-V instruction architecture(ISA). We developed our RTL source codeusing Chisel (Constructing Hardware in a
Scala-Embedded Language), an open-source
hardware construction language, and expressed the code as libraries of highly parameterized hardware generators. We developed ahighly automated back-end design flow to
reduce manual effort in pushing designs
through to layout. Finally, we present theresulting chips from our agile hardware design
process.

RISC-V
RISC-V is a free, open, and extensible ISA
that forms the basis of all of our programmable processor designs.2 Unlike many earlier
efforts that designed open processor cores,
RISC-V is an ISA specification, intended toallow many different hardware implementations to leverage common software develop-............................................................

12IEEE MICRO

ment. RISC-V is a modular architecture, withvariants covering 32-, 64-, and 128-bit address
spaces. The base integer instruction set is lean,requiring fewer than 50 user-level hardware
instructions to support a full modern software
stack, which enables microprocessor designers
to quickly bring up fully functional prototypes
and add additional features incrementally. In
addition to simplifying the implementation of
new microarchitectures, the RISC-V design
provides an ideal base for custom accelerators.
Not only can accelerators reuse common control-processor implementations, they can sharea single software stack, including the compiler
toolchain and operating system binaries. This
dramatically reduces the cost of designing andbringing up custom accelerators.
Further information on RISC-V is available from the nonprofit RISC-V Foundation,
which was incorporated in August 2015 tohelp coordinate, standardize, protect, and promote the RISC-V ecosystem.3 A free and open
ISA is a critical ingredient in an agile hardware
methodology, because having an active anddiverse community of open-source contributors amortizes the overhead of maintaining
and updating the software ecosystem, whichmakes it possible for smaller teams to focus ondeveloping custom hardware.4 A free ISA is
also a prerequisite for shared open-source processor implementations, which can act as abase for further customization.5

ChiselTo facilitate agile hardware development byimproving designer productivity, we developed Chisel6 as a domain-specific extension to
the Scala programming language. Chisel is
not a high-level synthesis tool in which hardware is inferred from Scala code. Rather,
Chisel is intended to be a substrate that provides a Scala abstraction of primitive hardware
components, such as registers, muxes, andwires. Any Scala program whose execution
generates a graph of such hardware components provides a blueprint to fabricate hardware designs; the Chisel compiler translates agraph of hardware components into a fast,cycle-accurate, bit-accurate Cþþ software
simulator, or low-level synthesizable Verilog
that maps to standard FPGA or ASIC flows.
Because Chisel is embedded in Scala, hardware developers can tap into Scala’s modernmasters(1)
AHB-Lite crossbar

masters(0)masters(0,1)

master
AHB-Lite bus

AHB-Litecrossbar

AHB-Lite bus

AHB-Lite bus

slaves(0,1,2)
ins(0,1)slaves(0,1,2)

Arbiter
AHB-Liteslave mux

Arbiter

Arbiter

Arbiterslave muxoutslaves(0)slave muxslaves(1)slave muxslaves(2)(a)
A class AHBXbar(nMasters: Int, nSlaves: Int) extends Module
B {C
val io = new Bundle {D
val masters = Vec(new AHBMasterIO, nMasters).flip
E
val slaves = Vec(new AHBSlaveIO, nSlaves).flip
F}GH
val buses = List.fill(nMasters){Module(new AHBBus(nSlaves))}I
val muxes = List.fill(nSlaves){Module(new AHBSlaveMux(nMasters))}
J
K(buses.map(b => b.io.master) zip io.masters) foreach {
L
M
N
O
P }

case (b, m) => b <> m }(muxes.map(m => m.io.out) zip io.slaves) foreach {case (x, s) => x <> s }for (m <- 0 until nMasters; s <- 0 until nSlaves) yield {buses(m).io.slaves(s) <> muxes(s).io.ins(m)}(b)
Figure 2. Using functional programming to write a parameterized AHB-Lite crossbar switch in Chisel. (a) Block diagrams. (b)Chisel source code. The code is short and easy to verify by inspection, but can support arbitrary numbers of masters and slave
ports.

programming language features—such as
object-oriented programming, functional programming, parameterized types, abstract datatypes, operator overloading, and type inference—to improve designer productivity byraising the abstraction level and increasingcode reuse. Furthermore, metaprogramming,code generation, and hardware design tasks are
all expressed in the same source language,
which encourages developers to write parame-terized hardware generators rather than discrete instances of individual blocks. This inturn improves code reuse within a given design
and across generations of design iterations.
To see how these language features interact in real designs, we describe a crossbar thatconnects two AHB-Lite master ports to three
AHB-Lite slave ports in Figure 2a. In the figure, the high-level block diagram is on theleft, the two building blocks (AHB-Lite buses.............................................................

MARCH/APRIL 201613

..............................................................................................................................................................................................
HOT CHIPS

idiom
A (1,2,3) map { n => n + 1 }
B (1,2,3) zip (a,b,c)
C ((1,a),(2,b),(3,c)) map { case (left,right) => left }D (1,2,3) foreach { n => print(n) }E for (x <- 1 to 3; y <- 1 to 3) yield (x,y)

result(2,3,4)((1,a),(2,b),(3,c))(1,2,3)123(1,1),(1,2),(1,3),(2,1),(2,2),(2,3),(3,1),(3,2),(3,3)

Figure 3. Generic functional programming idioms to help understand the crossbar example.

and AHB-Lite slave muxes) are in the middle, and the final design is shown on theright. To help understand the Chisel code,
Figure 3 shows some generic functional programming idioms. Idiom A maps a list of
numbers to an expression that adds 1 tothem. Idiom B zips two lists together. Idiom
C iterates over a list of tuples, uses Scala’s casestatement to provide names of elements, andthen operates on those names. Idiom D iterates over a list when the output values are notcollected. Idiom E is a for-comprehension witha yield statement.
Figure 2b shows the Chisel code thatbuilds the crossbar. Line A declares the
AHBXbar module with two parameters:
number of master ports (nMasters) andslave ports (nSlaves). Lines C through F
declare the module’s I/O ports. Lines H and I
instantiate collections of AHB-Lite buses and
AHB-Lite slave muxes. Lines K through N
connect the building blocks together. Notethat the Chisel operator <> connects module I/O ports together. Line K extracts themaster I/O port of each bus, zips it to the corresponding master I/O port of the crossbar
itself, and then connects them together. Line
L does the same thing for each slave mux output and each slave I/O port of the crossbar.
Lines M and N use for-comprehension to
generate the cross-product of all port combinations, and use each pair to connect a specific slave I/O port of a specific bus to thematching input of the corresponding mux.
This code’s brevity ensures that it is easily
verified by inspection. Although the example
shows two buses and three slave muxes, these
10 lines of code would be identical for any
number of buses and slave muxes. In contrast,
implementations of this crossbar module written in traditional HDLs, such as Verilog or............................................................

14

IEEE MICROVHDL, would be difficult to generalize into aparameterizable crossbar generator. This is justa small example of Chisel’s power to bringmodern programming language constructs tohardware development, increasing code maintainability, facilitating reuse, and enhancing
designer productivity.

Rocket Chip Generator
Chisel’s first-class support for object orientation and metaprogramming lets hardware
designers write generators, rather than individual instances of designs, which in turn
encourages the development of families ofcustomizable designs. By encoding microarchitectural and domain knowledge in thesegenerators, we can quickly create different
chip instances customized for particular
design goals and constraints.7 Constructionof hardware generators requires support forreconfiguring individual components basedon the context in which they are deployed;
thus, a particular focus with Chisel is toimprove on the limited module parameterization facilities of traditional HDLs.
The Rocket chip generator is written in
Chisel and constructs a RISC-V-based platform. The generator consists of a collectionof parameterized chip-building libraries that
we can use to generate different SoC variants.
By standardizing the interfaces used to connect different libraries’ generators to one
another, we have created a plug-and-playenvironment in which it is trivial to swap out
substantial components of the design simply
by changing configuration files, leaving the
hardware source code untouched. We canalso test the output of individual generatorsand perform integration tests on the whole
design, where the tests are also parameterized,
so as to exercise the entire design under test.

Figure 4 presents the collection of librarygenerators and their interfaces within the
Rocket chip generator. These generators canbe parameterized and composed into manyvarious SoC designs. Their current capabilities include the following:












Core: the Rocket scalar core generator
with an optional floating-point unit,
configurable pipelining of functional
units, and customizable branchprediction structures.
Caches: a family of cache and translation look-aside buffer generators withconfigurable sizes, associativities, andreplacement policies.
Rocket Custom Coprocessor: the RoCC
interface, a template for applicationspecific coprocessors that can expose
their own parameters.
Tile: a tile-generator template forcache-coherent tiles. The number
and type of cores and accelerators are
configurable, as is the organization ofprivate caches.
TileLink: a generator for networks ofcache-coherent agents and the associated cache controllers. Configuration
options include the number of tiles,
coherence policy, presence of sharedbacking storage, and implementationof underlying physical networks.
Peripherals: generators for AXI4-/
AHB-Lite-/APB-compatible buses andvarious converters and controllers.

Physical Design Flow
We frequently translate Chisel’s Verilog output
into a physical design through an ASIC CAD
toolflow. We have automated this flow and optimized it to generate industry-standard GDSformat mask files without designer intervention.
Automatic nightly regressions provide thedesigner with regular feedback on cycle time,area, and energy consumption, and they also
detect physical design problems early in thedesign cycle. Automatic verification and reporting on the quality of results allow more points inthe design space to be evaluated, and reduce thebarriertoimplementingmoresignificantchanges
atlaterstagesinthedevelopmentprocess.
One major hindrance to agile methodology for hardware design is CAD tool run-RocketTile

RocketTile

RoCC
Rocket L1I$ accel.

RoCC
Rocket L1I$ accel.

FPU

FPU

L1D$

L1D$

A

Rocket

B

Cache

C

RoCC

D

Tile

L1 network

L2$ bank

E TileLink

L2 network

F

Periph.

TileLink/AXI4
bridge
AXI4 crossbar

DRAM
controller

Highspeed
I/O device

AHB and APB
peripherals

Figure 4. The Rocket chip generator comprises the following
subcomponents: (a) a core generator, (b) cache generator, (c) Rocket
Custom Coprocessor-compatible coprocessor generator, (d) tile generator,(e) TileLink generator, and (f) peripherals. These generators can beparameterized and composed into many various system-on-chip designs.

time. The deployment process for hardware
is significantly more time-consuming thanfor software. Using an initial hardware
description to generate a GDS that is electrically and logically correct can require many
iterations. Because each iteration can takemany hours to run to completion, the process
could require weeks or months for larger
designs. To avoid the productivity loss ofthese long-latency iterations, we initially
focus on smaller designs, from which GDS
can be generated more rapidly. Iterating onthese smaller-scale tape-ins has proven valuable, because major problems are uncoveredmuch earlier in the design process, and evenmore so when we target a new process technology. Additionally, the parameterizable
nature of hardware generators reduces the.............................................................

MARCH/APRIL 201615

..............................................................................................................................................................................................
HOT CHIPS

Raven-3
Raven-1

Raven-2

SwerveRaven-4
May
2011

Apr.

Aug.

2012

Feb.

July

2013

Mar.

Sept.

Nov.

2014

EOS16

EOS18

Apr.

2015
EOS22

EOS14

Mar.

EOS24

EOS20

Figure 5. Recent UC Berkeley tape-outs using RISC-V processors for three lines of research. The Raven series investigatedlow-voltage reliable operation with on-chip DC–DC converters, the EOS series developed monolithically integrated silicon
photonic links, and Swerve experimented with dynamic redundancy techniques to handle low-voltage faults.

effort to scale up to larger designs later in thedesign process. Regardless of design size, we
ensure that each tape-in passes static timing
analysis, is functionally equivalent to the
RTL model, and has only a small number ofdesign-rule violations. Together, these properties ensure that the design is indeed tapeout ready.
As a particular tape-out deadline approaches, we evaluate whether to tape out themost recently taped-in design, usually on thebasis of whether the set of new features validated by the tape-in is sufficiently large. If we
decide to tape out, we clean up the remaining
design-rule violations and run final checks on
the resulting GDS. The full cycle of taping
out the GDS and testing the resulting chip ismore involved than a tape-in, but qualitatively it is just another, longer, iteration in theagile methodology. Thus, we focus on producing lineages of increasingly complicatedfunctioning chips, incorporating feedback
from the previous chip into the next in theseries. We believe that this rapid iterative
process is essential to improve the productivity of hardware designers and enable iterative
design-space exploration of alternative system
microarchitectures.

Silicon Results
Figure 5 presents a timeline of UC Berkeley
RISC-V microprocessor tape-outs that wecreated using earlier versions of the Rocket
chip generator. The 28-nm Raven chips com-............................................................

16

IEEE MICRO

bine a 64-bit RISC-V vector microprocessor
with on-chip switched-capacitor DC–DC
converters and adaptive clocking. The 45-nm
chips integrate a 64-bit dual-core RISC-V
vector processor with monolithically integrated silicon photonic links.8,9 In total, we
taped out four Raven chips on STMicroelectronics’ 28-nm fully depleted silicon-oninsulator (FD-SOI) process, six photonics
chips on IBM’s 45-nm SOI process, and one
Swerve chip on TSMC’s 28-nm process. The
Rocket chip generator forms the shared codebase for these 11 distinct systems; we incorporated the best ideas from each design backinto the code base, ensuring maximal reuseeven though the three distinct families ofchips were specialized differently to test out
distinct research ideas.

Case Study: RISC-V Vector Microprocessor
with On-chip DC–DC Converters
We applied our agile design methodology toRaven-3, a 28-nm microprocessor that
integrates switched-capacitor DC–DC converters, adaptive clocking circuitry, and lowvoltage static RAM macros with a RISC-V
vector processor instantiated by the Rocket
chip generator.10 The successful developmentof the Raven-3 prototype demonstrates how
architecture and circuit research was supported by the combination of the freely
extensible RISC-V ISA, the parameterizable
Chisel-based hardware implementation, andTo off-chip oscilloscope

...

1.8 V

Vout

1.0 V

CORE (1.19 mm2)

RISC-V scalar core
ScalarRF
FPU

Vector accelerator
Vector issue unit

toggleint

24 switched-capacitor
DC–DC unit cells

Sharedfunctional units
64-bit integer multiplierSingle-precision FMA
Double-precision FMA

int

int

int

int

int

Crossbar
Vector memory unit

Vref

+
–

FSM

...

(16-Kbye vector RF uses eightcustom 8T SRAM macros)...

DC–DC controller
2-Ghz
ref

clk

1.0 V

Adaptive clock
generator

16-Kbyte scalarI-cache(Custom 8T
SRAM macros)

32-Kbyte sharedD-cache(Custom 8T
SRAM macros)

8-Kbyte vector
I-cache(Custom 8T
SRAM macros)

Arbiter
Asynchronous FIFO
between domains
UncoreWire-bonded chip-on-board

To/from off-chip FPGA FSB and DRAM

Figure 6. Raven-3 system-level block diagram. A RISC-V processor core with a vector coprocessor runs with varying voltage
and frequency generated by on-chip switched-capacitor DC–DC converters and an adaptive clock generator.

fast feedback via iteration and automation aspart of the agile methodology.
Figure 6 shows the Raven-3 system-level
block diagram. The Raven-3 microprocessor
instantiates the left RocketTile in Figure 4
with the Hwacha vector unit implemented asa RoCC accelerator. We did not include an
L2 cache in this design iteration, leaving thisfeature for implementation in future tape-ins
and tape-outs. The chip consists of two voltage domains: the varying core domain andthe fixed uncore domain. The core domain
connects to the output of fully integrated
noninterleaved switched-capacitor DC–DC
converters11 and powers the processor and its
L1 caches. The fixed 1-V domain powers theuncore. The DC–DC converters generate
four voltage modes between 0.5 and 1 Vfrom 1 and 1.8 V supplies; they achieve better than 80 percent conversion efficiency,

while requiring no off-chip passives, which
greatly simplifies package design.10 The clock
generator selects clock edges from a tunable
replica circuit powered by the rippling corevoltage that mimics the processor’s critical
path delay, and it adapts the clock frequency
to the instantaneous voltage.12
The design of Raven-3 benefitted greatly
from the agile hardware design methodology.
By aspiring to build an incomplete prototype(rather than, for instance, a many-core design
implementing these technologies), we dramatically improved the odds of project success. The unique integration of the power
delivery, clocking, and processor systems was
only possible because the design teambroadly shared expertise about all aspects ofthe project. The processor RTL could largely
be reused from previous tape-outs, with only
incremental improvements and configuration.............................................................

MARCH/APRIL 201617

..............................................................................................................................................................................................
HOT CHIPS

VectorRF

VectorRF

VI$

SC DC-DC
Scalar core +vector accelerator

D$

SC DC-DC
Scalar core +vector accelerator
D$

I$

I$

BIST
SC-DCDC Controller

BIST
SC-DCDC Controller
Unit cell
Adaptive clock

(a)

VI$

Adaptive clock(b)

Unit cell

(c)

(d)

Figure 7. Raven-3 implementation: the (a) floorplan, (b) micrograph of the resulting chip, (c) wire-bonded chip on the package
board, and (d) test setup.

changes required to validate it for the particular feature set desired. As physical design onpartial feature sets gave incremental results,
we were able to adjust design features toimprove feasibility and QoR.
The agile hardware design methodology
was especially important in this design due tothe complexity and risk introduced by thecustom voltage conversion and clocking, as
illustrated by the following example. Tapeins of a simple digital system with a single
DC–DC unit cell were small enough to simulate at the transistor level, and these simulations found a critical bug in the DC–DC
controller. These transistor-level simulations
showed that a large current event could cause
the output voltage to remain below thelower-bound reference voltage even after theconverter switched. A bug in the controller
would cause the converter to stop switchingand drop the processor voltage to zero forthis case. We believe this bug, which was
fixed early in the design process by the addition of a simple state machine in the lowerbound controller, would have been foundvery late (if at all) with waterfall design
approaches.
Figure 7 shows the floorplan and micrograph of the resulting chip, the wire-bonded
chip on the package board, and the test setup.
The resulting 2:37-mm2 Raven chip is fully
functional and boots Linux and executes
compiled scalar and vector application codewith the adaptive clock generator at all operating modes, while the DC–DC converter
can transition between voltage modes in less............................................................

18

IEEE MICRO

than 20 ns. Raven-3 runs at a maximum
clock frequency of 961 MHz at 1 V, consuming 173 mW, and at a minimum voltage of
0.45 V at 93 MHz, consuming 8 mW.
Raven-3 achieves a maximum energy efficiency of 27 and 34 Gflops per watt whilerunning a double-precision matrix-multiplication kernel on the vector accelerator withand without the switched-capacitor DC–DC
converters, respectively. These results validate
the agile approach to hardware design.

O

ur agile hardware development methodology played an important role insuccessfully taping out 11 RISC-V microprocessors in five years at UC Berkeley. Witha combination of our agile methodology,
Chisel, RISC-V, and the Rocket chip generator, a small team of graduate students at UC
Berkeley was able to design multiple microprocessors that are competitive with industrial designs. Although there is much work
left to do to show that this approach can scale
up to the largest SoCs, we hope these projects
serve as an opportunity to shed some light oninefficiencies in the current design process, torethink how modern SoCs are built, and to
MICRO
revitalize hardware design.

Acknowledgments
We thank Tom Burd, James Dunn, Olivier
Thomas, and Andrei Vladimirescu for theircontributions and STMicroelectronics forthe fabrication donation. This work was
funded in part by BWRC, ASPIRE, DARPAPERFECT Award number HR0011-12-2-

0016, STARnet C-FAR, Intel ARO, AMD,
SRC/TxACE, Marie Curie FP7, NSF
GRFP, and an Nvidia graduate fellowship.

....................................................................
References
1. K. Beck et al., The Agile Manifesto, tech.
report, Agile Alliance, 2001.
2. A. Waterman et al., The RISC-V Instruction
Set Manual, Volume I: User-Level ISA, Version
2.0, tech. report UCB/EECS-2014-54, EECS
Dept., Univ. California, Berkeley, May 2014.
3. R. Merritt, “Google, HP, Oracle Join RISCV,” EE Times, 28 Dec. 2015.

Yunsup Lee is a PhD candidate in the
Department of Electrical Engineering andComputer Sciences at the University ofCalifornia, Berkeley. He received an MS incomputer science from the University ofCalifornia, Berkeley. Contact him at
yunsup@eecs.berkeley.edu.
Andrew Waterman is a PhD candidate in
the Department of Electrical Engineeringand Computer Sciences at the University ofCalifornia, Berkeley. He received an MS incomputer science from the University ofCalifornia, Berkeley. Contact him atwaterman@eecs.berkeley.edu.

4. V. Patil et al., “Out of Order Floating Point
Coprocessor for RISC-V ISA,” Proc. 19thInt’l Symp. VLSI Design and Test, 2015;
doi:10.1109/ISVDAT.2015.7208116.
5. K. Asanović and D. Patterson, “The Case forOpen Instruction Sets,” Microprocessor
Report, Aug. 2014.
6. J. Bachrach et al., “Chisel: Constructing
Hardware in a Scala Embedded Language,”
Proc. Design Automation Conf., 2012, pp.
1216–1225.
7. O. Shacham et al., “Rethinking Digital Design:
Why Design Must Change,” IEEE Micro, vol.
30, no. 6, 2010, pp. 9–24.
8. Y. Lee et al., “A 45nm 1.3GHz 16.7 Double-

Henry Cook is a PhD candidate in the
Department of Electrical Engineering andComputer Sciences at the University ofCalifornia, Berkeley. He received an MS incomputer science from the University ofCalifornia, Berkeley. Contact him at
hcook@eecs.berkeley.edu.
Brian Zimmer is a research scientist in the
Circuits Research Group at Nvidia. He
received a PhD in electrical engineering andcomputer science from the University ofCalifornia, Berkeley, where he performed
the research for this article. Contact him atbrianzimmer@gmail.com.

Precision GFLOPS/W RISC-V Processor
with Vector Accelerators,” Proc. 40th European Solid-State Circuits Conf., 2014, pp.
199–202.
9. C. Sun et al., “Single-Chip Microprocessor
that Communicates Directly Using Light,”
Nature, vol. 528, 2015, pp. 534–538.
10. B. Zimmer et al., “A RISC-V Vector Processor with Tightly-Integrated SwitchedCapacitor DC–DC Converters in 28nm
FDSOI,” Proc. IEEE Symp. VLSI Circuits,
2015, pp. C316–C317.
11. H.-P. Le, S. Sanders, and E. Alon, “Design
Techniques for Fully Integrated SwitchedCapacitor DC–DC Converters,” IEEE J.
Solid-State Circuits, vol. 46, no. 9, 2011, pp.
2120–2131.
12. J. Kwak and B. Nikolić, “A 550-2260MHz SelfAdjustable Clock Generator in 28nm FDSOI,”
Proc. IEEE Asian Solid-State Circuits Conf.,
2015; doi:10.1109/ASSCC.2015.7387471.

Ben Keller is a PhD student in the
Department of Electrical Engineering andComputer Sciences at the University ofCalifornia, Berkeley. He received an MS inelectrical engineering from the University ofCalifornia, Berkeley. Contact him atbkeller@eecs.berkeley.edu.
Alberto Puggelli is the director of technology at Lion Semiconductor. He received a
PhD in electrical engineering from the University of California, Berkeley, where heperformed the research for this article.
Contact him at alberto.puggelli@gmail.
com.
Jaehwa Kwak is a PhD candidate in the
Department of Electrical Engineering andComputer Science at the University ofCalifornia, Berkeley. He received an MS inelectrical engineering and computer sciences.............................................................

MARCH/APRIL 201619

..............................................................................................................................................................................................
HOT CHIPS

from Seoul National University. Contact
him at jhkwak@eecs.berkeley.edu.
Ruzica Jevtić is an assistant professor at the
Universidad de Antonio de Nebrija in
Madrid. She received a PhD in electricalengineering from Technical University of
Madrid and was a postdoctoral fellow at the
University of California, Berkeley, where
she performed the research for this article.
Contact her at rjevtic21@gmail.com.

Jonathan Bachrach is an adjunct assistantprofessor in the Department of ElectricalEngineering and Computer Sciences at the
University of California, Berkeley. He
received a PhD in computer science fromthe University of Massachusetts, Amherst.
Contact him at jrb@pobox.com.

Stevo Bailey is a PhD student in the
Department of Electrical Engineering andComputer Science at the University ofCalifornia, Berkeley. He received an MS fromthe University of California, Berkeley. Contact him at stevo.bailey@eecs.berkeley.edu.

David Patterson is the Pardee Professor ofComputer Science at the University of California, Berkeley. He received a PhD in computer science from the University of California, Los Angeles. Contact him at pattrsn@
eecs.berkeley.edu.

Milovan Blagojević is a PhD student in a
CIFRE program at the Berkeley WirelessResearch Center, STMicroelectronics, andInstitut Superieur d’Electronique de Paris.
He received an MSc in electrical engineeringfrom the University of Belgrade, Serbia.
Contact him at milovan.blagojevic@st.com.

Elad Alon is an associate professor in the
Department of Electrical Engineering andComputer Sciences at the University ofCalifornia, Berkeley, and a codirector of theBerkeley Wireless Research Center. He
received a PhD in electrical engineeringfrom Stanford University. Contact him at
elad@eecs.berkeley.edu.

Pi-Feng Chiu is a PhD student in the
Department of Electrical Engineering andComputer Sciences at the University ofCalifornia, Berkeley. She received an MS inelectrical engineering from the National
Tsing Hua University. Contact her at
pfchiu@eecs.berkeley.edu.
Rimas Avizienis is a PhD candidate in the
Department of Electrical Engineering andComputer Sciences at the University ofCalifornia, Berkeley. He received an MS incomputer science from the University ofCalifornia, Berkeley. Contact him atrimas@eecs.berkeley.edu.
Brian Richards is a research staff engineer
at the University of California, Berkeley,
and a founding member of the Berkeley
Wireless Research Center. He received an
MS in electrical engineering and computer............................................................

20

IEEE MICRO

science from the University of California,
Berkeley. Contact him at richards@eecs.
berkeley.edu.

Borivoje Nikolić is the National Semiconductor Distinguished Professor of Engineering at the University of California, Berkeley.
He received a PhD in electrical and computer engineering from the University ofCalifornia, Davis. Contact him at bora@
eecs.berkeley.edu.
Krste Asanović is a professor in the Department of Electrical Engineering and Computer Sciences at the University of California,
Berkeley. He received a PhD in computerscience from the University of California,
Berkeley. Contact him at krste@berkeley.edu.