A High-Level Synthesis Approach for a RISC-V RV32I-Based System on Chip and Its FPGA Implementation ^†

Abstract

In this paper, we present a RISC-V RV32I-based system-on-chip (SoC) design approach using the Vivado high-level synthesis (HLS) tool. The proposed approach consists of three separate levels: The first one is an HLS design and simulation purely in C++. The second one is a Verilog simulation of the HLS-generated Verilog implementation of the CPU core, a RAM unit initialized with a short assembly code, and a simple output port which simply forwards the output data to the simulation console. Finally, the third level is the implementation and testing of this SoC on a low-cost FPGA board (Basys3) running at a clock speed of 100 MHz. A sample C code was compiled using the GNU RISC-V compiler tool chain and tested on the HLS-generated RISC-V RV32I core as well. The HLS design consists of a single C++ file with fewer than 300 lines, a single header file, and a testbench in C++. Our design objectives are that (1) the C++ code should be easy to read for an average engineer, and (2) the coding style should dictate minimal area, i.e., minimal resource utilization, without significantly degrading the code readability. The proposed system was implemented for two different I/O bus alternatives: (1) a traditional single clock cycle delay memory interface and (2) the industry-standard AXI bus. We present timing closure, resource utilization, and power consumption estimates. Furthermore, by using the open-source synthesis tool yosys, we generated a CMOS gate-level design and provide gate count details. All design, simulation, and constraint files are publicly available in a GitHub repo. We also present a simple dual-core SoC design, but detailed multi-core designs and other advanced futures are planned for future research.

1. Introduction

In this paper, we present a RISC-V RV32I-based system-on-chip (SoC) design and implementation using a high-level synthesis (HLS) approach. The complete core design was carried out with HLS and then simulated at the C level, then at the Verilog level, and finally tested on a low-cost FPGA board at 100 MHz clock speed. Both assembly programs and C programs compiled with the GNU RISC-V toolchain were used as RAM images for testing the HLS-generated core. The proposed HLS core design has a single C++ file with fewer than 300 lines and is designed to be both highly-readable and use minimal hardware resources.

There are several published papers for CPU design in different hardware description languages (HDLs). In [1], a very simple reduced instruction set (RISC) processor design is presented with about 120 lines of Verilog code. See [2,3,4] and references therein for related work. RISC-V is a free and open source instruction set architecture [5,6]. The standard defines various ISAs starting with the base architecture RV32I. There are numerous Verilog implementations of RISC-V architectures, with varying degrees of performance and resource utilization. The paper [7] presents a review of some of the well-known open source designs and links to relevant GitHub repos for source codes. One disadvantage of these Verilog implementations is the length of the source codes, which is the main motivation for the HLS-based approach adapted in this work. The HLS-based approach can be quite useful for rapid prototyping of complex ideas, especially for systems with complex state machines. To the best of author’s knowledge, there is limited published work where an HLS-based approach is used for a RISC-V core design. In [8], an HLS design is presented, but the source code is split into multiple files, making it difficult to read. This work presents a single file design which is relatively short, easily readable, and yet suitable for an FPGA implementation with clock speeds of 100 MHz. Open source RISC-V cores can be quite useful for computer architecture education too; see [9]. The proposed HLS RISC-V RV32I core source codes are available in the public GitHub repo [10]. Finally, the author would like to cite [11] as a source of inspiration for this work.

This paper is organized as follows: In Section 2, we summarize the RISC-V RV32I instruction set architecture. In Section 3, a high-level synthesis approach for design and simulation is presented. Verilog simulations of our RISC-V SoC are presented in Section 4, CMOS gate-level design using the open-source synthesis tool yosys and gate count details are given in Section 5, and the FPGA implementation and testing are presented in Section 6. A sample C program was used for testing the HLS-generated core, as outlined in Section 7. A multi-core RISC-V SoC approach is outlined in Section 8, and finally some concluding remarks are given in Section 9.

2. RISC-V RV32I Architecture

In this section, we summarize the RISC-V RV32I instruction set architecture (ISA) [5,6] in

Table 1. RV32I instructions [5,6].

Inst	Type	Description
add	R	rd = rs1 + rs2
sub	R	rd = rs1 - rs2
xor	R	rd = rs1 rs2
or	R	rd = rs1 | rs2
and	R	rd = rs1 & rs2
sll	R	rd = rs1 << rs2
srl	R	rd = rs1 >> rs2
sra	R	rd = rs1 >> rs2
slt	R	rd = (rs1 < rs2)?1:0
sltu	R	rd = (rs1 < rs2)?1:0
addi	IA	rd = rs1 + imm
xori	IA	rd = rs1 imm
ori	IA	rd = rs1 | imm
andi	IA	rd = rs1 & imm
slli	IA	rd = rs1 << imm[0:4]
srli	IA	rd = rs1 >> imm[0:4]
srai	IA	rd = rs1 >> imm[0:4]
slti	IA	rd = (rs1 < imm)?1:0
sltiu	IA	rd = (rs1 < imm)?1:0
lb	IM	rd = M[rs1+imm][0:7]
lh	IM	rd = M[rs1+imm][0:15]
lw	IM	rd = M[rs1+imm][0:31]
lbu	IM	rd = M[rs1+imm][0:7]
lhu	IM	rd = M[rs1+imm][0:15]
sb	S	M[rs1+imm][0:7] = rs2[0:7]
sh	S	M[rs1+imm][0:15] = rs2[0:15]
sw	S	M[rs1+imm][0:31] = rs2[0:31]
beq	B	if(rs1 == rs2) PC += imm
bne	B	if(rs1 != rs2) PC += imm
blt	B	if(rs1 < rs2) PC += imm
bge	B	if(rs1 >= rs2) PC += imm
bltu	B	if(rs1 < rs2) PC += imm
bgeu	B	if(rs1 >= rs2) PC += imm
jal	J	rd = PC+4; PC += imm
jalr	IJ	rd = PC+4; PC = rs1 + imm
lui	U1	rd = imm << 12
auipc	U2	rd = PC + (imm << 12)
ecall	IE	Trap/Halt
ebreak	IE	Trap/Halt

. From a programming perspective, there are 32 registers x0,⋯,x31 and a program counter PC, all having 32-bit size. The register x0 is hardwired to 0, and the instructions are divided into six different groups R (Register), I (Immediate), S (Store), B (Branch), J (Jump), and U (Upper) [5,6]. Full details of the instruction encoding and instruction fields are given in [5,6]. For the HLS implementation of the instruction decoder stage, we divide $\mathtt{I}$ type instructions into IA (Immediate arithmetic), IM (Immediate memory), IJ (Immediate jump), and IE (Immediate exception) groups. Furthermore, $\mathtt{U}$ type instructions are divided into U1 (Upper1) and U2 (Upper2). All of the instructions are 32 bits in size and have a 7-bit opcode field located between bits 6 down to 0. Furthermore, there are 3-bit func3, 7-bit func7, and imm fields, but not all instructions have all of these three additional fields [5,6].

The sra and srai instructions use the most significant bit (MSB) extension rule, whereas the instructions sltu,sltiu,lbu,lhu,bltu, and bgeu use the zero extension rule. The instructions ecall and ebreak are implemented as trap/halt. All unaligned memory accesses are also implemented as trap/halt.

3. HLS Approach for Design and Simulation

The HLS design consists of the C++ file riscv32i.cc and the header file riscv32i.h. There is also a C simulation testbench file riscv32i_tb.cc. In this section, we simply summarize the main design ideas. The full source code is available in our GitHub repo [10].

We start with the outline of the design file riscv32i.cc; see Outline I. This file has only the cpu() function, which has two pointer arguments. For C simulation, they have the usual semantics, but for hardware synthesis, the first one is interpreted as a single-port RAM, and the other is implemented as a 4-bit write-strobe signal. The local array reg_file[] is interpreted as a multi-port RAM for hardware synthesis, which will correspond to the internal register file. The HLS tool has a standard C compiler which works according to standard semantic rules for simulations, but for hardware synthesis semantic details are different and can be controlled by using the #pragma HLS directives. Full details are available in the Vivado HLS User Guide [12].

As seen in Outline I, immediately after resetting the program counter and all of the registers are initialized to zero, there is an infinite while loop which will be exited if an ECALL or EBREAK instruction is executed or an unaligned memory access is requested, basically causing the CPU core to halt.

The HLS tool converts this while loop to a state machine with 11 states using the one-hot encoding. Inside the loop, we have the usual instructions fetch, decode, execute, write-back, and branch handling. For example, insn = mem[pc >> 2] will be synthesized as a memory read operation, and opcode = insn(6,0) will be synthesized as selecting the least significant 7 bits of the 32-bit value read from the memory. Note that, by using the operator overloading features of C++, we are able to express slicing and concatenation in C++; see [10,12] for full details. For example, in the instruction decode stage, we have the lines

• immI = ( ((ap_int<ARCH>) insn) >> 20 );
• immS = ( immI(31,5), insn(11,8), insn(7,7) );
• immB = ...
• immJ = ...
• immU = ( insn(31,12), ((ap_uint<12>) 0) );

which correspond to generating the 32-bit immediate value for various types of instructions. Note that ap_uint<p> is used for p-bit unsigned integers, insn(p,q) corresponds to slicing, and ( … , … , … ) corresponds to concatenation. These are possible because of the standard operator loading features of C++. Note that the C simulation semantics and the hardware synthesis semantics are different.

There are various switch statements, which are synthesized as wide-multiplexers. Nested switch statements correspond to cascaded multiplexers. To make sure that minimal number of adders, comparators, barrel-shifters, etc., are synthesized, and no hardware resources are wasted or underutilized, we defined first program variables src1, src2, res and then wrote several switch statements. This coding style may appear slightly unusual but is still highly readable and is adapted purely for optimal hardware synthesis. In other words, the C++ coding style used in HLS greatly affects the final generated hardware, and we tried to keep a reasonable balance between C++ code readability and hardware optimality.

The HLS tool automatically generates Verilog files in a human-readable format but also allows C-simulation-based testing using the file riscv32i_tb.cc. This C-simulation testbench reads a text file of hexadecimal values in a human-readable format, initializes the memory by using these values, and passes the control to the cpu() function. Immediately after return, all register values and the memory are dumped to separate text files. In Figure 1, Vivado HLS C simulation for the following short assembly program is given:

•       li      x1,1020
•       sw      x0,0(x1)
• loop: lw      x2,0(x1)
•       addi    x2,x2,1
•       sw      x2,0(x1)
•       j       loop

Values stored in registers and memory as well as internal signals are displayed in the debug window. Hexadecimal values for each instruction are written to the file mem.txt, and conversion is carried out by using an online assembler tool. See [10] for full details.

4. RISC-V SoC Simulation in Verilog

In this section, we present Verilog simulation of the HLS-generated RISC-V core. Either one can copy the HLS-generated Verilog files to the Vivado project folder or create an IP object for a block-diagram-based design. We simply copy and paste the generated Verilog files from one folder to the other, but in the next FPGA-based design we will use the block-diagram-based design approach for better visualization of the overall system.

The simulation testbench outline is given in Outline II, and the RAM with the I/O devices is presented in Outline III. Basically, we have a simple system on chip consisting of a single RISC-V RV32I core, a 4 KB RAM with single clock cycle read/write delay, and a 32-bit output port at memory address 0x0ff.

In Figure 2, Verilog simulation results are shown. We are using the assembly program given in the previous section, which basically writes the values 0, 1, 2, … to the address 0x0ff. The program counter PC is shown in the timing diagram, and the values written to the output port at address 0x0ff are shown both in the simulation console and the timing diagram. There is a specific reason why $write("%c", din[7:0]) is used for the memory mapped I/O at address 0x0ff. If we use a C-compiler and implement putc() as a write to the I/O address 0x0ff, then all printf(…) and cout << … will write to the Verilog simulation console. This allows more complex C/C++ programs to be tested with the HLS-generated RISC-V core.

In our simulation testbench, we also have a block RAM option, shown as SRAM. This allows the HLS-generated RISC-V core to be tested using block RAMs available on most Xilinx FPGAs; see Figure 3.

5. RISC-V RV32I Core Synthesis Gate Counts

In this short section, we present gate count results for the CMOS gate-level design generated by the open-source synthesis tool yosys. The following script is for the synthesis tool

• read_verilog cpu.v cpu_reg_file_V.v
• hierarchy -check
• proc; opt; fsm; opt; memory; opt
• techmap; opt
• read_liberty -lib cmos_cells.lib
• abc -liberty cmos_cells.lib
• splitnets -ports; opt
• stat

and the following gate-count results are reported by the synthesis tool:

• === cpu ===
• Number of wires:                  8282
• Number of cells:
•      $_DFF_P_                      321
•      NAND                         2689
•      NOR                          3714
•      NOT                           924
• === cpu_reg_file_V ===
• Number of wires:                  7714
• Number of cells:
•      $_DFF_P_                     1056
•      NAND                         4726
•      NOR                          1505
•      NOT                           387

In summary, a total of 1377 D-type flip-flops are used, including the register file of depth 32 and width 32. We have forced the synthesis tool to design using only two input NAND and NOR gates, and with that constraint the total number of two-input NAND gates is 7415, two-input NOR gates is 5219, and NOT gates is 1311.

6. RISC-V SoC Implementation on an FPGA

In this section, we will present a simple RISC-V SoC implemented on an FPGA. High-level details are presented in Figure 4, and the elaborated design is shown in Figure 5.

The elaborated design has 1296 cells and 1968 nets.

The resource utilization of the implemented design is 1078 LUT (5.18%), 326 FF (0.78%), and 3% of the BRAM. The final system has 1.41 ns worst-case negative slack for the setup time for 100 MHz clock. The power consumption is estimated as 81 mW at 100 MHz clock. Figure 6 shows the FPGA implementation of the SoC for the Basys3 board. Note that the whole SoC design fits into a portion of the clock region X0Y0. The large rectangular block at the center of Figure 6 is the 4 KB RAM used for the system on chip.

We use the same assembly program given in Section 3 and make sure that the hex values corresponding to assembly instructions are loaded to the SoC RAM. After the system is reset using the button btnC, the CPU core can be started using the button btnU. Figure 7 shows a Basys3 board implementation of our RISC-V SoC with the output port connected to the on-board LEDs. Note that bits 20 down-to 13 of the 32-bit value written to memory are routed to the I/O port using the slice block shown in Figure 4. The assembly program given in Section 3 has a loop execution time of 170 ns, i.e., 17 clock cycles loop execution time. The slicing block effectively slows down the counting speed so that counting can be observed by the naked eye.

7. Testing with a Sample C Program

We used a short C program for simulating the RISC-V H1 core designed earlier. Our testcode is given below

• #define OUTPORT (0x0ff)
• #include <stdint.h>
•  
• void main(void);
• void main(void) {
• *((volatile uint32_t*)OUTPORT) = ’R’;
• *((volatile uint32_t*)OUTPORT) = ’I’;
• *((volatile uint32_t*)OUTPORT) = ’S’;
• *((volatile uint32_t*)OUTPORT) = ’C’;
• *((volatile uint32_t*)OUTPORT) = ’\n’;
• }

It is compiled with the GNU RISC-V compiler to generate the RAM image. As shown in Outline III, we have a $readmemh to initialize the RAM for the Verilog simulation. Again as shown in the Outline III, all writes to address 0x0ff are forwarded to the simulation console using the $write command. In summary, when the SoC is simulated with the GNU RISC-V compiler to generate the RAM image, we see the string ‘RISC’ written to the console followed by a newline, which serves as another verification of the H1 core. In a future version of the paper, we will use longer C programs for more comprehensive testing.

8. A Multi-Core RISC-V SoC

In this section, we briefly summarize our multi-core RISC-V SoC implementation. We started by changing the memory interface from block RAM to a AXI master, i.e., changing the HLS directive to #pragma HLS INTERFACE m_axi depth=1024 port=mem. This resulted in a different RISC-V RV32I core equipped with the AXI master interface. The Vivado HLS generates a Verilog implementation with 42 states, which we call the H2 core. For this AXI-equipped H2 core, we need to delete the write-strobe port, wstrb, and use

• (mem[addr >> 2])( 7,0) = res;
• (mem[addr >> 2])(16,0) = res;
• (mem[addr >> 2])(32,0) = res;

to implement byte, word, and double-word sized memory write operations, respectively. Note that the bit-slicing operator (.,.) can be used both on the left- and right-hand side of expressions.

In Figure 8, we have a dual-core RISC-V RV32I system with 8K on-chip RAM, two 8-bit output ports, a 16-bit input port, and a single UART port. The H2 core does not have a tightly coupled memory (TCM) inside the unit, but this will be addressed in a future version of the paper. Basically, in the current implementation, both cores are using the on-chip static RAM over the AXI bus. All GPIOs and the UART unit are also on the AXI-bus. We have added a JTAG to AXI unit which can be used for debugging and initialization of the on-chip static RAM. For this dual-core SoC to function properly, both cores should have different reset vectors so that they can execute different programs independently.

Based on our preliminary results, we see that the dual-core RISC-V system shown in Figure 8 does fit into a Basys3 board.

9. Conclusions

In this paper, we have presented a high-level synthesis approach for RISC-V RV32I system design. The CPU core was designed and simulated at the C level, then the HLS-generated Verilog code was tested with RAM and I/O devices at the Verilog simulation level. Finally, the complete system-on-chip design with memory and I/O devices was implemented and tested on a low-cost FPGA board. Timing closure, resource utilization, and power consumption estimates are presented. The CMOS gate-level design and gate counts were generated by using an open-source synthesis tool. We have also outlined a dual-core system design. The HLS-generated CPU core has 14 states for a traditional single clock cycle delay memory interface and 42 states if the AXI bus support is needed. For such more complex systems, design in Verilog will be more demanding and error-prone compared to an HLS-based approach. Detailed analysis of multi-core designs are planned for future research.