tion in waterfall development. Small
programming teams quickly developed
working-but-incomplete prototypes and
got customer feedback before starting
the next iteration. The scrum version of
agile development assembles teams of
five to 10 programmers doing sprints of
two to four weeks per iteration.
Once again inspired by a software
success, the third opportunity is agile hardware development. The good
news for architects is that modern
electronic computer aided design
(ECAD) tools raise the level of abstraction, enabling agile development, and
this higher level of abstraction increases reuse across designs.
It seems implausible to claim sprints
of four weeks to apply to hardware, given the months between when a design
is “taped out” and a chip is returned.
Figure 9 outlines how an agile development method can work by changing the
prototype at the appropriate level.
innermost level is a software simulator,
the easiest and quickest place to make
changes if a simulator could satisfy an
iteration. The next level is FPGAs that
can run hundreds of times faster than a
detailed software simulator. FPGAs can
run operating systems and full benchmarks like those from the Standard
Performance Evaluation Corporation
(SPEC), allowing much more precise
evaluation of prototypes. Amazon Web
Services offers FPGAs in the cloud, so
architects can use FPGAs without needing to first buy hardware and set up a
lab. To have documented numbers for
die area and power, the next outer level
uses the ECAD tools to generate a chip’s
layout. Even after the tools are run, some
manual steps are required to refine the
results before a new processor is ready to
be manufactured. Processor designers
call this next level a “tape in.” These first
four levels all support four-week sprints.
For research purposes, we could stop
at tape in, as area, energy, and performance estimates are highly accurate.
However, it would be like running a
long race and stopping 100 yards before the finish line because the runner
can accurately predict the final time.
Despite all the hard work in race prepa-
ration, the runner would miss the thrill
and satisfaction of actually crossing the
finish line. One advantage hardware en-
gineers have over software engineers is
they build physical things. Getting chips
architects learn from mistakes of its
predecessors. Unlike first-generation
RISC architectures, it avoids microar-
chitecture or technology-dependent
features (such as delayed branches and
delayed loads) or innovations (such as
register windows) that were supersed-
ed by advances in compiler technology.
Finally, RISC-V supports DSAs by reserving a vast opcode space for custom
Beyond RISC-V, Nvidia also announced (in 2017) a free and open architecture29 it calls Nvidia Deep Learning Accelerator (NVDLA), a scalable,
configurable DSA for machine-learning
inference. Configuration options include data type (int8, int16, or fp16 )
and the size of the two-dimensional
multiply matrix. Die size scales from
0.5 mm2 to 3 mm2 and power from 20
milli Watts to 300 milli Watts. The ISA,
software stack, and implementation
are all open.
Open simple architectures are synergistic with security. First, security experts do not believe in security through
obscurity, so open implementations
are attractive, and open implementations require an open architecture.
Equally important is increasing the
number of people and organizations
who can innovate around secure architectures. Proprietary architectures
limit participation to employees, but
open architectures allow all the best
minds in academia and industry to
help with security. Finally, the simplicity of RISC-V makes its implementations easier to check. Moreover, the
open architectures, implementations,
and software stacks, plus the plasticity
of FPGAs, mean architects can deploy
and evaluate novel solutions online
and iterate them weekly instead of annually. While FPGAs are 10× slower
than custom chips, such performance
is still fast enough to support online
users and thus subject security innovations to real attackers. We expect open
architectures to become the exemplar
for hardware/software co-design by architects and security experts.
Agile Hardware Development
The Manifesto for Agile Software Development (2001) by Beck et al.
revolutionized software development, overcoming
the frequent failure of the traditional
elaborate planning and documenta-
do not believe in
obscurity, so open
require an open