Viewing hardware and software interaction is much easier with a logic analyzer style trace. In almost every job I’ve had I’ve added a VCD tracer to the instruction set simulator. Both the “big picture” state flow can be seen, and the “little details” of bus/register/interrupt/io interaction can be seen.
For that purpose I’ve forked the RISC-V ISA Simulator, https://github.com/five-embeddev/riscv-isa-sim/tree/vcd_trace.
About the fork
This fork adds a few features.
- Tracing of registers and memory bus.
- Time limit for simulation.
- New commands to trace variables.
- Two way symbol <-> address lookup.
This is an example of a firmware writing to the
In a previous post I used docker to containerize building for a RISC-V target.
In this post I’ll simulate that target file in a containerized RISC-V ISA Simulator.
Spike ISA Sim
The official reference ISA simulator for RISC-V is spike. There are other more functional and performant open source and commercial simulators , however the aim of this post is to describe a solution for quick and easy debugging and simulation of the low level examples on this blog.
Spike implements a functional model of the RISC-V hart(s) and the debug interface. GDB must connect to OpenOCD, which will in turn connect to Spike’s model of the RISC-V serial debug interface. Spike’s Readme file describes how to do this, but it’s pretty tedious to load an example program.
The container example downloads and builds the appropriate source code and manages running the independent tools.
The docker files are in https://github.com/five-embeddev/build-and-verify. Assume it’s checked out to
Modern development is moving towards packaging tools in containers. There are several benefits to containerizing development tools:
- A simpler tool deployment process, the binary image with all dependencies can simply be pulled from a server and run.
- An automated and consistent deployment process that can be shared between development machines and cloud based build servers.
- A consistent set of tools for all team members.
- The ability to build with General Purpose IDE’s rather than whatever tools a device vendor may provide.
- Isolation of dependencies used for different devices and build targets.
For RISC-V there are a few more benefits:
- A “recipe” to consistently build the vendor neutral tools at, such as https://github.com/riscv-collab/riscv-gnu-toolchain.
- New versions of the tools with support for new extensions etc can be easily deployed.
I’ve put together a set of Docker images and Docker Compose build and run configurations with the aim of deploying them with GitHub’s workflows.
They are located here: https://github.com/five-embeddev/build-and-verify
Information about extending cross compilation with PlatformIO has been added.
As RISC-V is a new architecture so there will be new development at all layers of the software and hardware stack. Rather than write code based on human language specifications from scratch, a smarter way to work can be to translate a machine readable specification to code.
“Machine Readable” does not need to be an all encompassing formal model of the architecture, there are many convenient formats such as csv, yaml, xml and json that can be parsed and transformed using the packages available in most scripting languages.
An example of cross compiling a baremetal program to RISC-V with CMake.
Note to self: When compiling the riscv-toolchain for embedded systems, set the configure options!
The toolchain can be cloned from the RISC-V official github. Once the dependencies are installed it’s straight forward to compile.
An initial toolchain quick reference.
NOTE: Since this was written the riscv-toolchain-conventions document has been released.
Getting started with RISC-V. Compiling for the RISC-V target. This post covers the GCC machine architecture (-march), ABI (-mabi) options and how they relate to the RISC-V base ISA and extensions. It also looks at the multilib configuration for GCC.