AFRL-RY-WP-TP-2019-0127

REVERSE ENGINEERING RISC-V GENERATOR-BASED

DESIGNS FOR TRUST AND ASSURANCE

Jeffrey Durrum, Adam Bryant, and Jeremy Porter

Trusted Electronics Branch
Aerospace Components & Subsystems Division

JULY 2019
Final Report

Approved for public release; distribution is unlimited.

See additional restrictions described on inside pages

STINFO COPY

AIR FORCE RESEARCH LABORATORY

SENSORS DIRECTORATE
WRIGHT-PATTERSON AIR FORCE BASE, OH 45433-7320
AIR FORCE MATERIEL COMMAND
UNITED STATES AIR FORCE
 Form Approved
REPORT DOCUMENTATION PAGE OMB No. 0704-0188
The public reporting burden for this collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering and
maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information, including
suggestions for reducing this burden, to Department of Defense, Washington Headquarters Services, Directorate for Information Operations and Reports (0704-0188), 1215 Jefferson Davis Highway, Suite
1204, Arlington, VA 22202-4302. Respondents should be aware that notwithstanding any other provision of law, no person shall be subject to any penalty for failing to comply with a collection of information if it
does not display a currently valid OMB control number. PLEASE DO NOT RETURN YOUR FORM TO THE ABOVE ADDRESS.

1. REPORT DATE (DD-MM-YY) 2. REPORT TYPE 3. DATES COVERED (From - To)

July 2019 Technical Paper 15 May 2019 – 16 May 2019
4. TITLE AND SUBTITLE 5a. CONTRACT NUMBER
REVERSE ENGINEERING RISC-V GENERATOR-BASED DESIGNS FOR FA8650-17-F-1044, FA8650-18-
TRUST AND ASSURANCE D-1614, FA8650-18-F-1615, and
FA8075-14-D-0025 DO 0013
5b. GRANT NUMBER
5c. PROGRAM ELEMENT NUMBER
N/A
6. AUTHOR(S) 5d. PROJECT NUMBER
Jeffrey Durrum, Adam Bryant, and Jeremy Porter N/A
5e. TASK NUMBER
N/A
5f. WORK UNIT NUMBER
N/A
7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) 8. PERFORMING ORGANIZATION
REPORT NUMBER
Air Force Research Laboratory, Sensors Directorate (AFRL/RYDT) AFRL-RY-WP-TP-2019-0127
Wright-Patterson Air Force Base, OH 45433-7320
Air Force Materiel Command,
United States Air Force
9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES) 10. SPONSORING/MONITORING AGENCY
ACRONYM(S)
Air Force Research Laboratory AFRL/RYDT
Sensors Directorate
11. SPONSORING/MONITORING AGENCY
Wright-Patterson Air Force Base, OH 45433-7320 REPORT NUMBER(S)
Air Force Materiel Command AFRL-RY-WP-TP-2019-0127
United States Air Force
12. DISTRIBUTION/AVAILABILITY STATEMENT
Approved for public release; distribution is unlimited.
13. SUPPLEMENTARY NOTES
PAO case number 88ABW-2019-2242, Clearance Date 8 May 2019. To be presented at the GOMAC, Albuquerque,
NM, May 15, 2019.This is a work of the U.S. Government and is not subject to copyright protection in the United
States.. Report contains color.
14. ABSTRACT
We reverse engineered the open source Rocket-Chip system-on-a-chip (SoC) generator so we could understand the
constructs and IP generation in sufficient detail to trust it for technology transition into our own SoC. We investigated its
parameterization and use, configuration of the core, design of generated interfaces and peripherals, and how it ultimately
generates Verilog register transfer language code that will be input to the synthesis work flow. Our goal was to
understand and verify the assumptions involved in generation at each stage of the tool chain so we can have higher
assurance in our ultimate design, and that we could verify the IP we will be using in our system. We discuss the reverse
engineering methodology we used to gain precise information about details of the chip, and discuss areas for future work
in creating tests and extracting information to verify generator-based designs.
15. SUBJECT TERMS
reverse engineering, RISC-V
16. SECURITY CLASSIFICATION OF: 17. LIMITATION 18. NUMBER 19a. NAME OF RESPONSIBLE PERSON (Monitor)
a. REPORT b. ABSTRACT c. THIS PAGE OF ABSTRACT: OF PAGES Vipul Patel
Unclassified Unclassified Unclassified SAR 8 19b. TELEPHONE NUMBER (Include Area Code)
N/A
Standard Form 298 (Rev. 8-98)
Prescribed by ANSI Std. Z39-18
 Reverse Engineering RISC-V Generator-Based
Designs for Trust and Assurance
Jeff Durrum Jeremy Porter Adam Bryant
Booz Allen Hamilton The Design Knowledge Company The Design Knowledge Company
Dayton, Ohio 45433 Dayton, Ohio 45433 Dayton, Ohio 45433
Email: durrum jeffrey@bah.com Email: jporter@tdkc.com Email: abryant@tdkc.com

Abstract—We reverse engineered the open source Rocket-Chip 4) Ancillary generated files (JSON, C++, RISC-V, ELF,
system-on-a-chip (SoC) generator so we could understand the GraphML, ASCII, Device Tree files, etc.),
constructs and IP generation in sufficient detail to trust it 5) Test files (RISC-V, C++, Scala), and
for technology transition into our own SoC. We investigated
its parameterization and use, configuration of the core, design 6) Data from simulation.
of generated interfaces and peripherals, and how it ultimately While we spent time to learn each of the technologies involved,
generates Verilog register transfer language code that will be we directed our main focus to understanding how the circuit
input to the synthesis work flow. Our goal was to understand
works by studying the Verilog code that the generator emits.
and verify the assumptions involved in generation at each stage
of the tool chain so we can have higher assurance in our ultimate
design, and that we could verify the IP we will be using in our
II. C ONFIGURATION
system. We discuss the reverse engineering methodology we used We targeted our first milestone, “Build-0,” at constructing
to gain precise information about details of the chip, and discuss a self-hosted default configuration of the Rocket-Chip. We
areas for future work in creating tests and extracting information
to verify generator-based designs. planned no modifications, parameterizations, or configuration
changes other than modifying the boot-up process.
I. I NTRODUCTION Rocket-Chip requires installation of the RISC-V tools which
In our plans to create a RISC-V system-on-a-chip (SoC), we are included as submodules in the Rocket-Chip git repository.
investigated the open source Rocket-Chip SoC generator [1] These include several packages:
developed from work started at The University of California, • riscv-fesvr – the front end server,
Berkeley. The core idea behind the Rocket-Chip is that users • riscv-isa-sim – the Spike instruction set simulator,
specify their design using a high-level hardware generation • riscv-gnu-toolchain – the compiler tool chains including
language called Chisel [2], use the supplied tools to compile GDB, Binutils, QEMU, GCC, glibc, and DejaGnu,
it to the FIRRTL intermediate representation language [3], • riscv-gnu-linux – needed to build the Linux kernel,
and can quickly generate a customized RISC-V chip design. • riscv-open-ocd – the OpenOCD debugger interface,
Designers then can use higher-level programming constructs • riscv64-unknown-elf – programs to build Linux,
to constrain and parameterize changes to their chip design. • riscv-pk – a proxy kernel for handling system calls,
Design modifications propagate from the alteration point to • riscv-opcodes – RISC-V instruction opcodes,
the rest of the SoC structure, or alternately, they flag errors to • riscv-tests – a battery of processor tests [5].
be caught and handled at design time. The process enables an We built the RISC-V tools and Rocket-Chip software on
agile methodology that allows late stage design modifications hosts connected to our local Research & Development Test
and feature additions [4]. & Engineering Network (RDT&E) and on the cloud-based
Our team is including a RISC-V core into our design, Trusted Silicon Stratus platform. Like many secured networks,
however, there is not enough information to trust the Rocket- these environments restrict users from having root access or
Chip generator or the SoC designs it can produce. For this installing their own software. This required installing more
reason, we sought to: than 30 packages, which required network approval. They
• Understand IP generation, could have also been built with user-level software installations
• Informally evaluate its quality, such as LinuxBrew [6], but in our experience, these solutions
• Generate IP for our SoC, and are at worst prohibited by network policy, and at best seriously
• Develop methods to trust generated IP. mistrusted by network administrators.
We analyzed numerous artifacts including: Installing Rocket-Chip in a “secured” environment can
1) The Rocket-Chip source code (mostly Scala with some require weeks to work through configuration issues. Our team
Chisel), ran into numerous such problems such as:
2) The build system (FIRRTL, sbt metadata, Make), • Bootstrapping GCC 5.0+ and GLibC,
3) The generated RTL (Verilog), • Installing the Scala Build Tool (SBT) and compiler,

1
Approved for public release; distribution is unlimted.
 • Build errors caused by an outdated Java compiler,
• Errors building systemd (a pre-requisite for libusb), and
• Difficulties installing the IntelliJ and the yEd viewer.
Each of these challenges is surmountable with time and
patience, but combined, they factor heavily into the overall
cost and schedule of an SoC project.
III. R EVERSE E NGINEERING
The Rocket-Chip generates a single RTL file with around
400 thousand lines of behavioral Verilog. It also generates
several other ancillary Verilog and data files. Because of the
size and ambiguity of the code, it did not provide an intuitive
understanding of the design. It was difficult to discern the data
path or determine the locations of important structures such
as the register files, boot ROM, SRAM memories, busses, and
core modules.
To better understand the data path and visualize the proces-
sor logic, we used three techniques:
1) Separate the file into individual Verilog files with one
module per file (resulting in 273 files), Fig. 1. The default RISC-V SoC structure as a tree
2) Follow the data flow on the Cadence Palladium Z1
Enterprise Emulation Platform to verify the functionality
of individual logic units, and (MMIO), an error module, a memory bus, a front bus, and a
3) Build simple visualizations to track connections between periphery bus. The periphery bus is connected to two interrupt
modules and between assignment statements. controllers (platform-level and core local interrupt), a debug
module, and a module called “TLROM” that provides logic to
Rocket-Chip builds a GraphML file containing information
handle the first stage boot up process. This information helped
about the connections between important modules in the SoC.
us isolate which modules were important to finding the register
It shows the as-described connections between components
files and which were not.
and can be viewed with an application that can process
Secondly, we searched for anything related to “register,”
GraphML files, such as the yEd viewer [7]. The names in
“register file,” or “regfile” in the Verilog, but these searches
the GraphML diagram do not directly correlate to the names
only led us to numerous register red herrings in places such
of the modules in the generated Verilog and neither directly
as the floating point unit or or the location of the command
correlate to class or object names in the Chisel source code.
status registers (CSR). We used regular expressions to find a
This made it difficult to track down the location and use of
2-dimensional array of 32 registers that are either 32 or 64
each module with precision. Each line of the RTL file contains
bits wide. In the “Rocket” module, we found the declaration:
auto-generated annotations that point the user to locations in
Chisel and FIRRTL files. These are usually helpful in locating reg [63:0] T 1671 [ 0 : 3 0 ] ;
a Chisel file, but are less helpful in locating specific variables
and assignments. In some cases there will be up to 40 lines By excluding other candidates, we interpreted the Rocket
of Verilog all with the same annotation pointing to a location module to contain the processor’s data path and this to be the
in a seemingly unrelated source code file. main register file. It only has 31 registers because the zeroth
register is hard-wired to zero.
A. Finding the RISC-V Registers One thing that was surprising was that the register file
A central feature of the RISC-V instruction set architecture had a temporary auto-generated variable name of “ T 1671.”
is that it is designed around a set of 32 registers and uses On subsequent re-compilations, the variable name changed.
them carry out instructions so finding where the Rocket- Ideally, important constructs would have permanent and inten-
Chip implements its registers was very important. Finding tional variable names, but often that is not the case when the
the RISC-V application binary interface (ABI) registers was Rocket-Chip generates RTL. This makes it difficult to locate
not straightforward because there was nothing specifically important structures and to create test benches to verify the
indicating their location in the RTL. We had to narrow down pre- or post-synthesis Verilog.
possible locations using the hierarchical structure of the SoC
exposed with Cadence SimVision (Figure 1). B. Initial Experimentation
The single Rocket-Chip core is located in a structure called After generating the chip and identifying important compo-
a tile. The tile communicates to other internal SoC modules nents, the next step was to emulate it and observe its activity.
through a system bus over the TileLink protocol. The system We wanted to see how the chip communicates data to and from
bus is connected to the main tile, a memory-mapped I/O unit the registers. This required knowing what stimulus to provide,

2
Approved for public release; distribution is unlimted.
how to send instructions to the processor, and what protocol At this point, the chip activity diverged from what we
was needed to send instructions. Unfortunately, documentation expected. Rather than jump to the BBL we had loaded into
did not provide adequate insight and none of these things were memory via a Tcl emulation load command, the processor
immediately obvious. went into an idle state. The instruction buffer froze on the
We began an exploratory probe of the chip with Tcl last boot loader instruction, ’h0000 BFF5, and all observable
commands using the Cadence Palladium XeDebug gui while signals went static.
observing signal activity in the Cadence Simvision Simulation It appeared that the chip was expecting an interrupt, or
Analysis Environment. In these initial emulation efforts, the some further instructions, possibly from the front end server
Rocket Chip system showed very few signs of expected as if it were in tethered mode. We investigated numerous
functionality. We tried writing bare metal RISC-V instructions explanations for this deadlocked boot sequence but had no
directly to the FPU, data cache, periphery bus, and front bus success until we mapped out crucial structures of the RISC-V
modules (fpu, dcache, pbus, and fbus, respectively). We also and traced the path from the registers, through the logic and
tried toggling bits on the core local interrupt (clint), platform routing of the chip, and then correlated this with the boot ROM
level interrupt (plic), and debug module control (dmcontrol) assembly code. Once we did this, we were able to understand
modules. None of these actions seemed to coax the system the problem and get the chip to boot correctly.
into an operational state.
After a lot of observations and bolstered by documents D. Global Reset Vector and moving on to BBL
published by the Lo-RISC project [8], we began to investigate The presence of over 500 RISC-V instructions in the disas-
the concept of a tethered vs. un-tethered Rocket Chip. We sembled boot ROM image file raised the question of how the
eventually realized supplying the processor with instructions processor chooses the eight values from the boot ROM after
and other associated signals, as we had been attempting, was reset. The bootrom module instance is simply a look-up table
the role of the front end server (fesvr) connected to a tethered with no control over what it does. Its indexing operations are
RISC-V chip. performed elsewhere in the chip.
Our goal was to run the processor in an un-tethered mode Working backwards from the address port of the bootrom
and tape it out on an ASIC, so it was necessary to make module, we saw that the address originates from somewhere
the chip come to life with only a clock and a reset signal. in the periphery bus. A module instance in the periphery
The processor still would be sent instructions, but it would be bus, called fragmenter and nested within in an instance called
the logic of the un-tethered Rocket Chip System that would coupler to slave named bootrom, generates the address sig-
handle this task, rather than a software-driven routine from a nal. It does this by OR-ing a static vector (the hex value
co-processor. ’h1 0040) with a signal that counts upward from ’h8 to ’h38
in increments of eight. This addressing logic targets a burst
C. Monitoring Boot Sequence of eight sequential values that begin at a specific address; the
The first observable activity should be the emergence of vector establishes the first address of the burst and the counter
instructions from a Boot ROM, followed by a larger boot signal steps through the values.
loader – in this case, the Berkeley Boot Loader (BBL). For The generation of the signal that increments the index into
this reason, we focused on how the signals propagate from the boot ROM demonstrates how the Rocket Chip implements
reset through the boot sequence to see how the chip initializes. logic networks. It is driven by a long chain of temporary
This focus drove our discovery of a large area of the chip’s signals, automatically named with a number and the prefix
architecture and data flow. ” T ” and linked together with Verilog assign statements.
Five clock cycles after reset, the initial signals eventually Each step in this cascade performs some sort of logical
flow through an instance of a TLROM module instance called operation, comparison, negation, or arithmetic on the previous
bootrom which issues a burst of eight 64-bit words. In addition temporary-named signal. This is also how the Rocket Chip
to these eight values, there are about 300 other 64 bit values implements the look-up table functionality of the bootrom
in the bootrom module instance. The eight 64-bit values module.
are propagated through the logic of the Rocket Chip and We traced the source of the ’h1 0040 vector through the
13 clock cycles after emerging from the bootrom module, system bus and RocketTile module, all the way back to
they appear on the instruction buffer, parsed into sixteen 32- a magic numbered register called global reset vector. The
bit instructions. The first five instructions are valid RISC- global reset vector is generated in the BootROM.scala file
V instructions (’hF140 2573, ’h0000 0597, ’h03C5 8593, and given the value of 0x1 0040. This value corresponds to
’h1050 0073, and ’h0000 BFF5), followed by eleven more a parameter called hang that serves the additional function of
that are populated with zeros. creating a hang boot routine at that same address, which is
We disassembled these instructions, which are hard coded as the same as what is described in the bootrom.S file (Listing
muxes in the bootrom module of the RTL. We compared that 1).
code to the “bootrom/bootrom.img” and “bootrom/bootrom.S” The code in the _hang routine initializes a hardware thread,
files in the rocket-chip source tree and found that they are points the a1 register to a space allocated for a device tree
almost identical. blob, clears machine mode interrupts, and then spins waiting

3
Approved for public release; distribution is unlimted.
 Fig. 2. Boot ROM instructions on the Instruction Buffer resultant writes.

for an interrupt. The bootrom.S file also defines a routine out of the boot ROM after reset. These include several writes
called _start which we experimentally determined to be we could verify on the ABI registers (Figure 2).
at location ’h1 0000 in the TLROM. The _start routine The first two instructions increment the s0/fp (saved reg-
loads a pointer to a memory value into the s0 register, ister/frame pointer) register and left shift the base ’1f (31
initializes a hardware thread, loads a simple device tree blob bits) to the most significant bits of that register, setting the
into the a1 register, then jumps to the memory address frame pointer to the value of DRAM_BASE (’8000 0000).
loaded earlier (DRAM_BASE: ’h8000 0000). By changing The third instruction cssrw (atomic read/write to command
global reset vector to ’h1 0000, we successfully booted the status register) writes zero to register 10 (fa0) to indicate the
chip in _start mode. Booting from _start prompted the hardware thread that is executing. The fourth and fifth instruc-
chip to perform an AXI-4 request for the BBL from the tions (auipc and addi), write the program counter (set to
memory module at the DRAM BASE address ’h8000 0000. ’h0001 0044) and add ’h74 to register 11 (fa1), changing it to
’h0001 0080 and setting up the address of the device tree blob.
Listing 1. hang routine in bootrom.S. The last instruction jumps to the memory mapped address
_hang:
written to register 8 (s0/fp) Figure 3 illustrates this boot
f1402573 csrrs a0, mhartid
00000597 auip a1, 0x0 sequence as well as the bursts of BBL data from the memory
03C58593 add a1, a1, 0x3C that result from the jump to DRAM_BASE (’8000 0000).
1:
10500073 wfi F. RISC-V Instruction Disassembly / Assembly
0000bff5 j -0x4 To make sense of the inner activity of the RISC-V, we
had to understand the instructions appearing on the instruction
Listing 2. start routine in bootrom.S. buffer. Disassembling the instructions by hand became tedious
_start: and the version of objdump included with the RISC-V tools
0010041b addiw s0, zero, 0x1 was only suited for disassembling binary files. We adapted an
01f41413 slli s0, s0, 0x1f open source RISC-V disassembler [9] to meet our needs by
f1402573 csrrs a0, mhartid, zero
00000597 auipc a1, 0 porting the C code to Python and modifying it to disassemble
07458593 addi a1, a1, 0x74 individual instructions and perform on-the-fly instruction bit
00008402 jr s0 width adjustment. This let us compare code in the bootrom.img
file, bootrom.S, and the bootrom module in the Verilog RTL
The Berkeley Boot Loader (or another suitable boot loader)
(Listing 3).
should be loaded at DRAM BASE to set up the processor to
load and run code, and then to load and execute the operating Listing 3. Boot ROM generation in Verilog.
system. . . .
Figure 2 shows the boot instructions on the instruction assign index = auto_in_a_bits_address[11:3];
buffer module named ibuf and the resultant writes on the assign high = auto_in_a_bits_address[15:12];
assign _T_673 = high != 4’h0;
ABI registers. The base address is written to register 8 assign _GEN_1 = 9’h1 == index ? 64’
(so/fp, signal FRAME_POINTER[63:0]) and the pointer to h597f1402573 : 64’h1f414130010041b;
the device tree blob is written to register 11 (fa1, signal assign _GEN_2 = 9’h2 == index ? 64’
DEVICE_TREE[63:0]). h840207458593 : _GEN_1;
On reset, the default tethered mode initializes the device . . .
then waits for an interrupt from an external module to send it
instructions to execute. After modifying the global reset vector, G. Boot ROM Generation and Device Tree Extraction
our Build-0 boots in emulation and directly initializes the first- As shown in Listing 3, the boot ROM is hardcoded into the
stage boot loader (FSBL) from the Boot ROM. chip. The device tree code follows the boot ROM. From the
Verilog code we were able to extract the boot ROM and device
E. Boot Sequence Execution Flow tree and compare it with the bootrom.img and bootrom.S files.
Using the RISC-V specification v2.2, we disassembled the The boot ROM and device tree match what is in the boot ROM
six instructions corresponding to the _start routine coming in the Verilog.

4
Approved for public release; distribution is unlimted.
 Fig. 3. Boot Sequence Response on Reset showing activity from the Boot ROM, BBL, and Registers

IV. C ONNECTIONS AND W RITING OUT TO M EMORY analysis on the chip with methods such as data flow analysis,
Most of the modules contain ports that relate to the TileLink address alias analysis, deadlock analysis, and so on. We plan
and AXI-4 connections in the chip. There is no documentation to experiment with these techniques and others, but must first
describing how the modules are connected or the specifics enumerate what is in the circuit, connect what is there, connect
of parameter negotiation. The paper describing the diplomatic the design with the generated IP, and then understand how data
parameter negotiation [10] discusses the process in a general flows between these components.
sense, but not how this theory is implemented in Rocket-Chip. A. Transformations
In the RTL, we saw that each bus communicating outside the
Our trust and assurance goals with the Rocket-Chip are
SoC goes through a sequence of modules that perform various
to focus on the assurances cases. Transformation assurance
tasks, such as:
is one such case. This involves verifying what is in the
• Indexing the message (TLIndexer),
Chisel is represented faithfully in the Verilog. This includes
• Fixing the width (TLWidthWidget),
nothing is inserted or removed during IP generation, and that
• Converting between TileLink and AXI4 (TLtoAXI4),
everything in the RTL and physical design is traceable back
• Fragmenting a burst into beats (AXI4Fragmenter),
to an intentional construct in the Chisel code. There is no
• Disambiguating agents (AXI4UserYanker),
longer a 1-to-1 correspondence between classes in Chisel and
• Sequencing messages (AXI4IdIndexer),
modules in the RTL. This makes it difficult to know what kinds
• Buffering to wait for an enable (AXI4Buffer).
of test benches need to be written. Test benches targeting the
These modules and their use are not documented in the source Verilog RTL miss the point of developing in the agile style
code or in [10]. On the other side of each of these modules described in [4]. However, test benches written in Chisel target
is a cross-bar that maps the sender and receiver modules. a high-level model of the circuit, leaving the quality of the
The MMIO connects from the Tile to a sequence of modules transformations unverified. Other verification work includes
to convert from TileLink messages to AXI4 messages, to a testing single module behaviors, testing module combinations,
cross bar, and then to a buffer before it goes out to the verifying sequences of signals in memory-holding structures,
connected devices mapped on MMIO. The memory bus has and tracing signal flow. To support this, one must understand
communication from a filter and buffer, through a memory bus the input space, behavior, and output space at each of these
cross bar, and then prepares the messages for AXI4 to go out levels of testing.
to the memory controller.
Each of the modules can have slightly different configu- B. Barriers to Understanding Rocket-Chip
rations of the same TileLink and AXI-4 ports. The AXI-4 Besides the challenges of understanding the RTL, the
relevant modules are given by the terminology used in the Rocket-Chip source code is also complex and difficult to
names of the module’s ports, and how that relates to the AXI-4 understand. The Rocket-Chip has several hundred thousand
protocol. There are no documentation or included test benches lines of complex, undocumented Scala code that relies heavily
that determine the extent to which the TileLink and AXI-4 on concepts from the Chisel domain specific language [2]
protocols are implemented. These are areas for future work in and FIRRTL [3] intermediate representation language. It relies
designing test benches and verification for the Rocket-Chip. heavily on deeply-nested object oriented relationships, ad-
vanced functional techniques like partial function application,
V. T RUST AND A SSURANCE delocalized behavior, and dependency inversion patterns. The
Our purpose in studying this chip is to learn how we can code is only sparsely documented and most documentation is
understand generated IP in general. While this is a start, there from space-restricted archival or conference publications. The
are many things we still do not know how to do. We know learning curve factors heavily into the time and cost of any
there are many potential vulnerabilities that can be hidden SoC project.
in the transformation steps [11]. Vulnerabilities include mem- It is easy to make major changes to the Chisel source code
ory access patterns, race conditions, improper combinations that change the generated circuit in big ways, but it is difficult
of signals, improper control flow, leaking information, and to predict the effects those changes will have on the RTL.
control flow or data flow integrity issues. Protecting against It is not clear that the features that make Rocket-Chip’s code
these vulnerabilities requires the capability to perform security complex are necessary to generating high-quality circuits. Any

5
Approved for public release; distribution is unlimted.
complexity that is not required for the functionality of the R EFERENCES
generator, but which makes the RTL harder to understand, is [1] K. Asanovic, R. Avizienis, J. Bachrach, S. Beamer, D. Biancolin,
a liability for anyone taping out an SoC using these tools. C. Celio, H. Cook, D. Dabbelt, J. Hauser, A. Izraelevitz et al., “The
The Rocket-Chip generator contains many more files be- rocket chip generator,” EECS Department, University of California,
Berkeley, Tech. Rep., 2016.
sides just the Chisel source. A newly-cloned Rocket-Chip [2] J. Bachrach, H. Vo, B. Richards, Y. Lee, A. Waterman, R. Avižienis,
repository contains 372 files in 63 directories. The repository J. Wawrzynek, and K. Asanović, “Chisel: Constructing hardware
grows to 1,115 files in 282 directories after bringing in in a Scala embedded language,” in Proceedings of the 49th
annual design automation conference, ser. DAC ’12. New
the required sub-modules (Chisel3, FIRRTL, HardFloat, and York, NY, USA: ACM, 2012, pp. 1216–1225. [Online]. Available:
Torture); grows to 151,613 files in 8,625 directories after http://doi.acm.org/10.1145/2228360.2228584
bringing in the required sub-modules from the RISC-V tools [3] P. S. Li, A. M. Izraelevitz, and J. Bachrach, “Specification for
the FIRRTL language,” EECS Department, University of California,
repository; and grows to 185,049 files in 10,780 directories Berkeley, Tech. Rep. UCB/EECS-2016-9, Feb 2016. [Online]. Available:
after running the build scripts to create a first working project. http://www2.eecs.berkeley.edu/Pubs/TechRpts/2016/EECS-2016-9.html
The complexity of the build system also makes it difficult to [4] Y. Lee, A. Waterman, H. Cook, B. Zimmer, B. Keller, A. Puggelli,
J. Kwak, R. Jevtic, S. Bailey, M. Blagojevic et al., “An agile approach
understand everything that goes into Rocket-Chip, which also to building risc-v microprocessors,” IEEE Micro, vol. 36, no. 2, pp.
impacts the cost and schedule of projects that use it. 8–20, 2016.
[5] “RISC-V Tools (GNU Toolchain, ISA Simulator, Tests).” [Online].
VI. R ELATED W ORK Available: https://github.com/riscv/riscv-tools
[6] “Linuxbrew: The Homebrew package manager for Linux.” [Online].
Our work builds on and intends to further clarify the Berke- Available: http://linuxbrew.sh/
ley team’s own work such as the Rocket-Chip IP generator [1], [7] “yEd - Graph Editor.” [Online]. Available:
https://www.yworks.com/products/yed
Chisel [2], FIRRTL [3], diplomatic parameter negotiation for [8] “lowRISC.” [Online]. Available: https://www.lowrisc.org/
IP generation [10], and the paper on Chris Celio’s Berkeley [9] M. J. Clark, “riscv-disassembler,” 2018. [Online]. Available:
Out-of-order Machine [12], and the overall agile process these https://github.com/michaeljclark/riscv-disassembler
[10] H. Cook, W. Terpstra, and Y. Lee, “Diplomatic design patterns:
tools support [4]. We have found all of these sources to be A TileLink case study,” in First workshop on computer
incredibly useful. architecture research with RISC-V, Boston, 2017. [Online]. Available:
Lo-RISC performed a similar reverse engineering effort https://carrv.github.io/2017/papers/cook-diplomacy-carrv2017.pdf
[11] K. Thompson, “Reflections on trusting trust,” Commun. ACM,
to ours to develop their platform and provided a lot of vol. 27, no. 8, pp. 761–763, Aug. 1984. [Online]. Available:
documentation that was invaluable to us in our own work [8]. http://doi.acm.org/10.1145/358198.358210
Researchers from the University of Washington also presented [12] K. Asanovic, D. A. Patterson, and C. Celio, “The Berkeley out-of-order
machine (BOOM): An industry-competitive, synthesizable, parameter-
some of their work in understanding how to use and implement ized RISC-V processor,” University of California at Berkeley Berkeley
the Rocket-Chip [13]. With the amount of activity in Rocket- United States, Tech. Rep., 2015.
Chip and Chisel, we expect many more groups to use this IP [13] T. Ajayi, K. Al-Hawaj, S. Dai, S. Davidson, P. Gao, G. Liu, A. Rao,
A. Rovinski, N. Sun, C. Torng, L. Vega, B. Veluri, S. Xie, C. Zhao,
to tape out their own SOCs and we expect each team will R. Zhao, C. Batten, R. G. Dreslinski, R. K. Gupta, M. B. Taylor,
have to go through a process similar to what we have done to and Z. Zhang, “Experiences using the RISC-V ecosystem to design
understand in depth how the various parts of the architecture an accelerator-centric SoC in TSMC 16nm,” in First Workshop on
Computer Architecture Research with RISC-V, 2017. [Online]. Available:
work together. https://carrv.github.io/2017/papers/ajayi-celerity-carrv2017.pdf

VII. C ONCLUSIONS
We presented our preliminary work in understanding the
Rocket-Chip RISC-V implementation for the purposes of im-
proving our methodology in trust and assurance. Our goal was
to understand how the various parts of the Verilog processor
implementation fit together and connect when building up a
system-on-a-chip, and to reverse engineer existing implemen-
tations for helping in design and answering questions. Our
goal is to transition this platform into one for which we can
build and test security and assurance features into the hardware
we generate. As part of that, we must see how these work
together and understand the impacts of these changes. For
future work, there is a lot of need for improved visualization
and understanding of hardware at various levels of abstraction.
There seems to be a lot of promise in manipulating the
FIRRTL description of the circuit, but there is a steep learning
curve to work with that representation. Additionally, there
is work that is needed in visualizations that help us easily
see situations that create vulnerabilities or susceptibilities to
attack.

6
Approved for public release; distribution is unlimted.