riscv-software-src / riscv-isa-sim Goto Github PK

Since Spike is the main reference implementation of RISC-V, I think it should be flexible and easy to understand. Since we have qemu support for faster simulation, I think we can afford some loss of performance in favor of configurability and cleanliness.

Here are some of the things I had in mind (I've already done some of these, and I'll have them in a fork soon):

• Separate hardware that is not part of the processor into a platform_t class. This includes dram, rtc, debug module. This could easily be extended to include a custom uart for processors that may not have a debug module.
  • One possible constructor for this class could take in a configuration string as an input and parse it to find what devices exist and where they go.
• Move the "icache" entirely within processor_t to get instruction decoding out of the mmu. Also rename it to something else since its really caching decodings and trying to providing unique call sites for each decoded instruction function to help the host next address predictor (maybe "execution cache"?).
• Have tlb store physical addresses instead of pointers to host memory offset by the full virtual address
• Don't reuse TLB tags for trigger status
• Try to fit some debug module details into a separate debug module class.

There are some pieces of code in Spike that are obviously tuned for performance (sometimes very cleverly), but I think since we have qemu as a faster simulator, I think we can pivot Spike towards flexibility and cleanliness to benefit the RISC-V community. What do you all think? If you agree, I would be happy to send some pull requests and finish up some of the work I was doing towards these goals.

edit: I pressed enter too soon (github needs an undo button like gmail) and posted this before I finished it. Sorry if you got an e-mail with random bits of stream of consciousness about Spike and Qemu.

Using the following commands:

riscv64-unknown-elf-gcc -nostdlib -nostartfiles -Tlink.ld -m32 -o inst inst.s
spike --isa=RV32I -d inst

and then inside spike any of these:

pc 0
reg 0
mem 200

the values are displayed as 64 bit values (16 hex digits).

Is there a way to make spike simulate a 32 bit ISA with 32 bit pc, 32 bit registers and memory content displayed as 32 bit words?

Hi

I am seeing an issue with processing the -p and -m options for spike? Note that I pulled the repo as a submodule of the riscv-tools repo.

Stephen

root@c6403e37998e:/opt/riscv# spike -m 128 +disk=linux-3.14.41/root.bin bbl linux-3.14.41/vmlinux quit
spike: argument required for option -m
usage: spike [host options] [target options]
Host Options:
-p Simulate processors [default 1]
-m Provide MiB of target memory [default 4096]
-d Interactive debug mode
-g Track histogram of PCs
-l Generate a log of execution
-h Print this help message
--isa= RISC-V ISA string [default RV64IMAFDC]
--ic=:: Instantiate a cache model with S sets,
--dc=:: W ways, and B-byte blocks (with S and
--l2=:: B both powers of 2).
--extension= Specify RoCC Extension
--extlib= Shared library to load

Hi,

When I use the spike as the golden model to run a tests, I found the spike is not supporting the unaligned load/store instructions. But in ISA, this is the baseline feature which have to be supported. Is there any reason why Spike not support it, any plan to fix this issue?

Thanks
Bob

Following the instructions on http://riscv.org/download.html#tab_isa-sim to simulate a new instruction, I always run into a build error:

make: *** No rule to make target insns_ut/ut_beq.h', needed byut_beq.cc`. Stop.

I've installed riscv-isa-sim through the risc-v tools, have setup the prefix at $RISCV properly, I have not touched ut_beq and I followed step 3 by running ./build-spike-only.sh in riscv-tools.

Is there anything else I can add?

The readme shows spike --gdb-port 9824 pk tests/debug as a way to set up debugging with gdb, but running this command doesn't work as the gdb-port option has been replaced with the rbb-port option as of d1f2cf3.

$ spike --gdb-port 9824 pk sample
spike: unrecognized option --gdb-port
usage: spike [host options] <target program> [target options]
Host Options:
  -p<n>                 Simulate <n> processors [default 1]
  -m<n>                 Provide <n> MiB of target memory [default 2048]
  -m<a:m,b:n,...>       Provide memory regions of size m and n bytes
                          at base addresses a and b (with 4 KiB alignment)
  -d                    Interactive debug mode
  -g                    Track histogram of PCs
  -l                    Generate a log of execution
  -h                    Print this help message
  -H                 Start halted, allowing a debugger to connect
  --isa=<name>          RISC-V ISA string [default RV64IMAFDC]
  --pc=<address>        Override ELF entry point
  --ic=<S>:<W>:<B>      Instantiate a cache model with S sets,
  --dc=<S>:<W>:<B>        W ways, and B-byte blocks (with S and
  --l2=<S>:<W>:<B>        B both powers of 2).
  --extension=<name>    Specify RoCC Extension
  --extlib=<name>       Shared library to load
  --rbb-port=<port>     Listen on <port> for remote bitbang connection
  --dump-dts  Print device tree string and exit

I am unfamiliar with rbb. Is it some kind of debugging software like gdb? And why was support for gdb removed?

Hi,

I followed the instructions for the installation and even if the --with-fesrv option is used (the library is found by the configure step), the path for the fesrv include files is not added to the g++ command line.
I need to do:
CPPFLAGS=-I$(RISCV)/include make
to get a successful compilation

When I try to run a simple Hello World test over spike pk simulating 2 processors, the system fails. I am invoking it like this:

$ spike -p2 pk hello

What I get from terminal is this:

Am I doing something wrong here?

When launching the simulator in debug mode with the -d flag, the inner loop of the "interactive" mode in interactive.cc uses 2 as a hard coded argument to the readline function. This relates to the stderr stream, rather than the stdin stream.

• Call to readline
• Definition of readline

This isn't a problem when typing commands from a shell, but when controlling the simulator automatically from other scripts/flows/programs it means that one cannot automate command sequences. For example:

$> cat command-list.txt
run 100
reg 0
q
$> spike -d hello.out < command-list.txt
: 

will not pipe the contents of command-list.txt into the simulator. The user is just dumped into the debug mode prompt.

Fixing the issue is a simple matter of changing the hard-coded 2 to a 0 on line 82 of interactive.cc. I'd submit a pull request, but I don't know if this is deliberate.

The last commit a95b44df9d142a49f3e1bfe4a60d259ed41ca247 seemed to have broken the simulator for me. Now when building riscv-isa-sim (or the entire riscv-tools) I get a huge amount of errors that all go something like this:

ui64_to_f64.o: In function `softfloat_shortShiftRightJam128':
ui64_to_f64.c:(.text+0x180): multiple definition of `softfloat_shortShiftRightJam128'
f32_add.o:f32_add.c:(.text+0x180): first defined here
ui64_to_f64.o: In function `softfloat_shortShiftRightJam128Extra':
ui64_to_f64.c:(.text+0x1c0): multiple definition of `softfloat_shortShiftRightJam128Extra'
f32_add.o:f32_add.c:(.text+0x1c0): first defined here
ui64_to_f64.o: In function `softfloat_shiftRightJam64Extra':
ui64_to_f64.c:(.text+0x210): multiple definition of `softfloat_shiftRightJam64Extra'
f32_add.o:f32_add.c:(.text+0x210): first defined here

When reverting to bea283531abfd013811e83c75ff6189a0d9b3075 it builds fine.

I'm building on Fedora 23 and I'm just following the instructions in the Readme. So I'm not doing anything special. Just running

git submodule update --init --recursive
export RISCV=/opt/riscv/
./build.sh

And when it gets to the part where it builds riscv-isa-sim, the errors I pasted above come up. Same happens if I go to riscv-isa-sim/build and try to make it manually from there.

When I run spike --isa=RV32IM -H --gdb-port=7777 and after connecting with gdb I run info registers

Spike dies with the the error message

gdbserver code died: handle_register_read

gdb displays the following

ra             0x0000000000000000   0
sp             0x8000000000000000   -9223372036854775808
gp             0x0000000000000000   0
tp             0x0000000000000000   0
t0             0x0000000000000000   0
t1             0x0000000000000000   0
t2             0x0000000000000000   0
fp             0x0000000000000000   0
s1             0x0000000000000000   0
a0             0x0000000000000000   0
a1             0x0000000000000000   0
a2             0x0000000000000000   0
a3             0x0000000000000000   0
a4             0x0000000000000000   0
a5             0x0000000000000000   0
Remote connection closed

I think gdb is trying to read 64* 32 bits of registers rather than 32*32 bits like it should.

I am having a problem building the toolchain.

`[promach@localhost riscv-tools]$ ./build.sh
Starting RISC-V Toolchain build process

Removing existing riscv-fesvr/build directory
Configuring project riscv-fesvr
Building project riscv-fesvr
Installing project riscv-fesvr

Removing existing riscv-isa-sim/build directory
Configuring project riscv-isa-sim
Building project riscv-isa-sim
../spike_main/disasm.cc: In constructor ‘disassembler_t::disassembler_t(int)’:
../spike_main/disasm.cc:257:1: note: variable tracking size limit exceeded with -fvar-tracking-assignments, retrying without
disassembler_t::disassembler_t(int xlen)
^~~~~~~~~~~~~~
../riscv/gdbserver.cc: In member function ‘virtual bool halt_op_t::perform_step(unsigned int)’:
../riscv/gdbserver.cc:352:9: error: statement will never be executed [-Werror=switch-unreachable]
gs.tselect_valid = false;
^~
cc1plus: all warnings being treated as errors
make: *** [Makefile:319: gdbserver.o] Error 1
[promach@localhost riscv-tools]$ `

I have googled but no-one has the same error. I suppose -Werror is not encouraged in release code, https://blog.flameeyes.eu/2009/02/future-proof-your-code-dont-use-werror/ or am I missing something ?

My system configurations are as follows:
Arch Linux, gcc (GCC) 7.1.1 20170528 , GNU ld (GNU Binutils) 2.28.0.20170506

The debug ROM writes 1s to the last word in the debug RAM to indicate an exception. However, it also uses the last word for stashing the value of S1 before running the code in the debug RAM, so the exception information is lost. The gdb support checks for exceptions in a couple of places and can misbehave when S1 is non-zero. In particular, it will send an error code for p and P commands, although the latter is masked by an extra OK response (see pull request #83).

Hi,

I wonder if there is a mismatch between the privilege-level spec and the Spike simulator.

In the spec (Version 1.9.1 released on 11/04/16) page 22, the semantics of xRET are described as follows,

The MRET, HRET, SRET, or URET instructions are used to return from traps in M-mode, H-mode, S-mode, or U-mode respectively. When executing an xRET instruction, supposing xPP holds the value y, yIE is set to xPIE; the privilege mode is changed to y; xPIE is set to 1; and xPP is set to U.

Which means if we execute MRET in M-mode, and returns to say S-mode, MPIE should be set to 1, but in the simulator, (riscv/insns/mret.h)

s = set_field(s, MSTATUS_MPIE, 0);

Could anyone tell if this is indeed a mismatch or just my misunderstanding?

Thank you!
Hongce

After building spike without the device tree compiler installed, running spike yields the following message:
Failed to run : No such file or directory

It would be nice if the build failed if dtb isn't found.

It looks like there's a mismatch between riscv-isa-sim and riscv-opcodes with respect to the hwacha instructions.

When I make riscv-opcodes in order to update riscv-isa-sim/opcodes_hwacha_ut.h, there's a large diff (below). I'm guessing an updated version of opcodes_hwacha_ut.h needs to be checked in.

diff --git a/hwacha/opcodes_hwacha_ut.h b/hwacha/opcodes_hwacha_ut.h
index 6a8c326..86bb28b 100644
--- a/hwacha/opcodes_hwacha_ut.h
+++ b/hwacha/opcodes_hwacha_ut.h
@@ -23,6 +23,18 @@ DECLARE_INSN(ut_amoxor_w, 0x2000202f, 0xf800707f)
 DECLARE_INSN(ut_and, 0x7033, 0xfe00707f)
 DECLARE_INSN(ut_andi, 0x7013, 0x707f)
 DECLARE_INSN(ut_auipc, 0x17, 0x7f)
+DECLARE_INSN(ut_beq, 0x63, 0x707f)
+DECLARE_INSN(ut_bge, 0x5063, 0x707f)
+DECLARE_INSN(ut_bgeu, 0x7063, 0x707f)
+DECLARE_INSN(ut_blt, 0x4063, 0x707f)
+DECLARE_INSN(ut_bltu, 0x6063, 0x707f)
+DECLARE_INSN(ut_bne, 0x1063, 0x707f)
+DECLARE_INSN(ut_csrrc, 0x3073, 0x707f)
+DECLARE_INSN(ut_csrrci, 0x7073, 0x707f)
+DECLARE_INSN(ut_csrrs, 0x2073, 0x707f)
+DECLARE_INSN(ut_csrrsi, 0x6073, 0x707f)
+DECLARE_INSN(ut_csrrw, 0x1073, 0x707f)
+DECLARE_INSN(ut_csrrwi, 0x5073, 0x707f)
 DECLARE_INSN(ut_div, 0x2004033, 0xfe00707f)
 DECLARE_INSN(ut_divu, 0x2005033, 0xfe00707f)
 DECLARE_INSN(ut_divuw, 0x200503b, 0xfe00707f)
@@ -66,6 +78,7 @@ DECLARE_INSN(ut_fdiv_d, 0x1a000053, 0xfe00007f)
 DECLARE_INSN(ut_fdiv_h, 0x1c000053, 0xfe00007f)
 DECLARE_INSN(ut_fdiv_s, 0x18000053, 0xfe00007f)
 DECLARE_INSN(ut_fence, 0xf, 0x707f)
+DECLARE_INSN(ut_fence_i, 0x100f, 0x707f)
 DECLARE_INSN(ut_feq_d, 0xa2002053, 0xfe00707f)
 DECLARE_INSN(ut_feq_h, 0xac000053, 0xfe00707f)
 DECLARE_INSN(ut_feq_s, 0xa0002053, 0xfe00707f)
@@ -125,11 +138,15 @@ DECLARE_INSN(ut_fsub_d, 0xa000053, 0xfe00007f)
 DECLARE_INSN(ut_fsub_h, 0xc000053, 0xfe00007f)
 DECLARE_INSN(ut_fsub_s, 0x8000053, 0xfe00007f)
 DECLARE_INSN(ut_fsw, 0x2027, 0x707f)
+DECLARE_INSN(ut_jal, 0x6f, 0x7f)
+DECLARE_INSN(ut_jalr, 0x67, 0x707f)
 DECLARE_INSN(ut_lb, 0x3, 0x707f)
 DECLARE_INSN(ut_lbu, 0x4003, 0x707f)
 DECLARE_INSN(ut_ld, 0x3003, 0x707f)
 DECLARE_INSN(ut_lh, 0x1003, 0x707f)
 DECLARE_INSN(ut_lhu, 0x5003, 0x707f)
+DECLARE_INSN(ut_lr_d, 0x1000302f, 0xf9f0707f)
+DECLARE_INSN(ut_lr_w, 0x1000202f, 0xf9f0707f)
 DECLARE_INSN(ut_lui, 0x37, 0x7f)
 DECLARE_INSN(ut_lw, 0x2003, 0x707f)
 DECLARE_INSN(ut_lwu, 0x6003, 0x707f)
@@ -147,6 +164,10 @@ DECLARE_INSN(ut_remu, 0x2007033, 0xfe00707f)
 DECLARE_INSN(ut_remuw, 0x200703b, 0xfe00707f)
 DECLARE_INSN(ut_remw, 0x200603b, 0xfe00707f)
 DECLARE_INSN(ut_sb, 0x23, 0x707f)
+DECLARE_INSN(ut_sbreak, 0x100073, 0xffffffff)
+DECLARE_INSN(ut_scall, 0x73, 0xffffffff)
+DECLARE_INSN(ut_sc_d, 0x1800302f, 0xf800707f)
+DECLARE_INSN(ut_sc_w, 0x1800202f, 0xf800707f)
 DECLARE_INSN(ut_sd, 0x3023, 0x707f)
 DECLARE_INSN(ut_sh, 0x1023, 0x707f)
 DECLARE_INSN(ut_sll, 0x1033, 0xfe00707f)
@@ -161,6 +182,7 @@ DECLARE_INSN(ut_sra, 0x40005033, 0xfe00707f)
 DECLARE_INSN(ut_srai, 0x40005013, 0xfc00707f)
 DECLARE_INSN(ut_sraiw, 0x4000501b, 0xfe00707f)
 DECLARE_INSN(ut_sraw, 0x4000503b, 0xfe00707f)
+DECLARE_INSN(ut_sret, 0x80000073, 0xffffffff)
 DECLARE_INSN(ut_srl, 0x5033, 0xfe00707f)
 DECLARE_INSN(ut_srli, 0x5013, 0xfc00707f)
 DECLARE_INSN(ut_srliw, 0x501b, 0xfe00707f)

The OS X build breaks partway through due to the new commit 71d04ec with the following error:

In file included from ../riscv/processor.cc:566:
./insn_list.h:1:17: error: expected ';' at end of declaration
DEFINE_INSN(add addi addiw addw amoadd_d amoadd_w amoand_d amoand_w amomax_d amomaxu_d amom...
            ^
../riscv/processor.cc:565:25: note: expanded from macro 'DEFINE_INSN'
    REGISTER_INSN(this, name, opcodes[#name].first, opcodes[#name].second)
                        ^
../riscv/processor.h:141:23: note: expanded from macro 'REGISTER_INSN'
  extern reg_t rv32_##name(processor_t*, insn_t, reg_t); \
                      ^

It seems like this may be caused by a difference in GNU sed and BSD sed. I have gsed installed and changing riscv.mk fixes this bug, but it would be great to not have gsed be a dependence.

I noticed that, while CSR_TIME and CSR_STIME are redirected to CSR_MTIME, CSR_MTIME is not implemented, resulting in an "Illegal Instruction" exception everytime one of these CSRs is used. Although bbl seems to work around the lack of mtime somehow, it would be nice to have support for it in spike.

Hi,

I noticed (by manual inspection) that the code at riscv/sim.cc, line 152 will not work on big-endian machines. The uint32_t words in reset_vec are at first stored in host-endianness, then added to a std::vector, and finally added to a rom_device_t, both of which doesn't affect the endianness. RISC-V instructions must always be encoded in little-endian.
Although big-endian machines are increasingly rare, it's nicer to stay compatible with them.

Hi!

I tried to execute spike this way by navigating to the folder the executable is in:

cd ~/riscv-tools/riscv-isa-sim/build
./spike

I get this error message:

./spike: error while loading shared libraries: libriscv.so: cannot open shared object file: No such file or directory

It is significant that the file it claims to not find is in the same directory as the spike executable (in the build directory) - any help?

I have the need to load some data into the RISCV memory space in spike before I start the simulation, but looking at the code there doesn't seem to be functionality to do this. The closest way I can see seems to be to use the addr_to_mem function in the sim_t class to get access to the memory mapped offset, but those methods are private. Is there an alternative, or should I just hack my local copy and make those public so that I can do what I need to do?

Hi,

spike and spike-dasm e977e22 disassemble 0x00000000 as addi s0, sp, 0, which is wrong in two ways:

• the two least significant bits are 00, so it would be an RVC instruction. One can see in spike's instruction trace mode that it is decoded as 32 bits.
• 0000 is defined as an invalid instruction in the RVC spec 1.9.

Interestingly, when executing a 00000000 word in spike, an illegal instruction trap is generated.

I want to simulate a bare metal code on spike, which is using memory mapped I/O. Is there a way to add an I/O memory region to spike and then read/write to it from host or GDB?

Hello!
We are getting a segmentation fault when trying to simulate bbl in recent versions of this repository.

In particular, we are using commit 75f2a05df9cdff6f3faba748065b3184b9f01b01 and, after some debugging, we could isolate the segmentation fault in the line 174 in file ../riscv/mmu.h.

The corresponding code is as follows:

  inline icache_entry_t* refill_icache(reg_t addr, icache_entry_t* entry)
  {
    auto tlb_entry = translate_insn_addr(addr);
    insn_bits_t insn = *(uint16_t*)(tlb_entry.host_offset + addr); // <---- This is line 174!
    int length = insn_length(insn);

    if (likely(length == 4)) {
      insn |= (insn_bits_t)*(const int16_t*)translate_insn_addr_to_host(addr + 2) << 16;
    } else if (length == 2) {
      insn = (int16_t)insn;
    } else if (length == 6) {
      insn |= (insn_bits_t)*(const int16_t*)translate_insn_addr_to_host(addr + 4) << 32;
      insn |= (insn_bits_t)*(const uint16_t*)translate_insn_addr_to_host(addr + 2) << 16;
    } else {
      static_assert(sizeof(insn_bits_t) == 8, "insn_bits_t must be uint64_t");
      insn |= (insn_bits_t)*(const int16_t*)translate_insn_addr_to_host(addr + 6) << 48;
      insn |= (insn_bits_t)*(const uint16_t*)translate_insn_addr_to_host(addr + 4) << 32;
      insn |= (insn_bits_t)*(const uint16_t*)translate_insn_addr_to_host(addr + 2) << 16;
    }

    insn_fetch_t fetch = {proc->decode_insn(insn), insn};
    entry->tag = addr;
    entry->data = fetch;

    reg_t paddr = tlb_entry.target_offset + addr;;
    if (tracer.interested_in_range(paddr, paddr + 1, FETCH)) {
      entry->tag = -1;
      tracer.trace(paddr, length, FETCH);
    }
    return entry;
  }

We have also tried commit 63c98b41ae2d36808ebbb57e7f8e871ba247d444, where the segfault doesn't occur anymore. However, we could see how spike was stuck in that code region ignoring the previous segfault.

Hi,

I want to get dynamic instruction count via Spike, but the disassembly codes from -d option (i.e., spike -d pk hello and :r) is weird.

How can I get dynamic instruction count via Spike?

Hi,

When I try to use Spike to run with GDB for single-step mode, I found the execution sequence is not expected, and one instruction is lost.

If I run spike with the isa-test rv32uc-p-rvc (from the riscv-tests/isa directory), I can see the instruction trace is like this:

core 0: 0xffffffff800000b0 (0x34129073) csrw mepc, t0
core 0: 0xffffffff800000b4 (0xf1402573) csrr a0, mhartid
core 0: 0xffffffff800000b8 (0x30200073) mret
core 0: 0x00000000800000bc (0x00200e13) li t3, 2 //<---------------------------------------> This instruction
core 0: 0xffffffff800000c0 (0x29a00593) li a1, 666
core 0: 0xffffffff800000c4 (0x00100613) li a2, 1

But when I run this test with GDB in single-step-mode, I can see the trace is like this:
0x800000ac in reset_vector ()
(gdb) ni
0x800000b0 in reset_vector ()
(gdb) ni
0x800000b4 in reset_vector ()
(gdb) ni
0x800000b8 in reset_vector ()
(gdb) ni
0x800000c0 in reset_vector ()//<------------------> We can see after the 0x800000b8, the next instruction here is 0x800000c0. This should not happen, the original 800000bc instruction is lost.
(gdb) ni
0x800000c4 in reset_vector ()
(gdb)

I guess this should be a bug, so report it here.

Thanks
Bob

Any test or benchmark fails at start with error trap_store_access_fault.
any-bit pk.
Why spike can deny storing io?
Latest pull at the time of issue (db6051f)

At the moment fmin(sNaN, normal) returns normal, not qNaN.

I custom two csr (mbase,mbound) in spike projectfor Mbb policy which present on riscv-privileged-v1.9.1 specification.
My step is as follow:
1.add "mbase" and "mbound" in "parse-opcodes" file "riscv-opcode" project and run "make install"
2.in mstatus_init function ,"minit.c" file pk project, add "write_csr(mbound, ms);" to test if it works

when I compile pk project ,gcc failed and notify as follow:
../machine/minit.c: Assembler messages:
../machine/minit.c:25: Error: Instruction csrw requires absolute expression

autoconf on RHEL6 fails with some m4_macro errors. The fix is to swap the position of two lines in configure.ac

Should be

AC_INIT(proj_name,proj_version,proj_maintainer,proj_abbreviation)
AC_LANG_CPLUSPLUS

instead of

AC_LANG_CPLUSPLUS
AC_INIT(proj_name,proj_version,proj_maintainer,proj_abbreviation)

The RISCV ISA spec (linked to from http://riscv.org/download.html) says that return values go into registers x16-x17 (v0-v1), yet these registers don't exist in riscv/regnames.cc. They used to, but commit 992205c changed them to match the 'new' ABI.
What is this new ABI exactly?

From a fresh clone, following the directions:

make
...
g++ -fPIC -MMD -MP -I/opt/riscv/include  -Wall -Wno-unused -g -O2 -std=c++11 -DPREFIX=\"/opt/riscv\" -Werror -I. -I.. -I../riscv -I../dummy_rocc -I../softfloat -I../spike_main -c ../spike_main/spike.cc
../spike_main/spike.cc: In function ‘int main(int, char**)’:
../spike_main/spike.cc:81:9: error: cannot declare variable ‘s’ to be of abstract type ‘sim_t’
   sim_t s(isa, nprocs, mem_mb, halted, htif_args);
         ^
In file included from ../spike_main/spike.cc:3:0:
../riscv/sim.h:19:7: note:   because the following virtual functions are pure within ‘sim_t’:
 class sim_t : public htif_t
       ^
In file included from ../riscv/sim.h:9:0,
                 from ../spike_main/spike.cc:3:
/opt/riscv/include/fesvr/htif.h:39:19: note:    virtual ssize_t htif_t::read(void*, size_t)
   virtual ssize_t read(void* buf, size_t max_size) = 0;
                   ^
/opt/riscv/include/fesvr/htif.h:40:19: note:    virtual ssize_t htif_t::write(const void*, size_t)
   virtual ssize_t write(const void* buf, size_t size) = 0;
                   ^
Makefile:320: recipe for target 'spike.o' failed
make: *** [spike.o] Error 1

Hi, I encountered this problem while debugging coreboot, which doesn't use the HTIF.

If a program doesn't provide the tohost ELF symbol, spike will execute 5000 instructions and then hang in a loop without executing any more instructions. I tested this with spike f5ecf65 and riscvarchive/riscv-fesvr@916191caf3.

One easy way to proproduce this bug is to:

• Write a program that spins a loop
• run spike -l pk ./program to verify that execution doesn't stop
• copy pk into the current directory
• find the tohost string in pk and patch it to something else (like nohost)
• run spike -l ./pk ./program |& tee trace-log; observe that execution stops at some point
• run wc -l trace-log and observe that 5000 instructions have been executed

I haven't fully debugged it, but I've seen the following happening:

• sim_t::run() calls step(INTERLEAVE), INTERLEAVE is defined as 5000
• sim_t::step(n) simulates n instrucions, does some bookkeeping and finally calls htif->tick()
• htif_isasim_t::tick() calls tick_once()
• tick_once() calls htif_pthread_t::recv which calls recv_nonblocking
• recv_nonblocking doesn't find any data, so it calls host.switch_to()
• the other thread (this is some kind of cooperative multitasking, right?) doesn't switch back, because it's stuck in the loop in htif_t::run()

It might not be related to this problem, but I noticed that both spike and libfesvr register their own handlers for SIGINT. As signal handlers don't automatically stack, this is probably a bad idea.

If I revert before that commit, I can boot SMP enabled linux with spike fine.

Compiling on Mac OS X 10.11 results in the following error:

g++ -fPIC -MMD -MP  -Wall -Wno-unused -g -O2 -std=c++11 -DPREFIX=\"/usr/local\" -Werror -I. -I. -I./riscv -I./dummy_rocc -I./softfloat -I./spike_main ./riscv/insn_template.h -o insn_template.h.gch
clang: error: treating 'c-header' input as 'c++-header' when in C++ mode, this behavior is deprecated
make: *** [insn_template.h.gch] Error 1

This is because a C header is being pre-compiled with the C++ compiler, something Clang does not support.

Hi, is the spike updated to the latest spec?
I found out that the ecall will still trap to H mode.
https://github.com/riscv/riscv-isa-sim/blob/5762bedab3a671ddfd279737d370533f31ed979e/riscv/insns/ecall.h

Is there any other detail explanation about add new instructions in RISC-V?
Can you explain it a bit more concretely for me, please?

I use riscv tools version: 886d8131dbd23533fb04d2d76a80be21d5f9ee7a and riscv-isa-sim version: 53d74f4

First I compile hello.c with -g to hello.rv:

$ riscv64-unknown-elf-gcc -g hello.c -o hello.rv

Then I follow README https://github.com/riscv/riscv-isa-sim#debugging-with-gdb in one shell run:

$ spike --gdb-port 9824 pk hello.rv

It quickly prints "hello, word!"

So when I in a second shell I do that:

$riscv64-unknown-elf-gdb hello.rv
(gdb) target remote localhost:9824

It returns "localhost:9824: Connection timed out."

By the way, can I use rocket-chip/emulator with riscv-gdb like the way spike do so?

When compiling with clang under OS X the following warning is generated:

g++ -fPIC -MMD -MP -I/usr/local/riscv/include -Wall -Wno-unused -O2 -std=c++11 -DPREFIX="/usr/local/riscv" -I. -I../riscv -I../hwacha -I../dummy_rocc -I../softfloat -I../spike_main -c ../riscv/interactive.cc
../riscv/interactive.cc:186:14: warning: if statement has empty body
[-Wempty-body]
if (0) ;
^
../riscv/interactive.cc:186:14: note: put the semicolon on a separate line to
silence this warning

I would try to fix this but I'm not sure what the code in interactive.cc is attempting to do or what optimization it is leveraging.

To test Boot ROM images (at least to some limited degree), it would be useful to be able to load files at some common positions in the address space (e.g. at the start), without first having to build an ELF file.

Are there any plans to implement such a feature?

I updated the latest version and run spike simulator but --dc does not work. Has it become obsolete?

tnewsome@debian-lap:~/SiFive/riscv-tools/riscv-isa-sim$ make
make: *** No rule to make target 'riscv/devicetree.h', needed by 'all'. Stop.

Is this a file you forgot to commit?

Hi,
I think a command that disassembles n instructions at a given memory locations would be useful.
Users who want to do that need to first read the memory location with mem and then feed the lower half of the printed 64-bit value into spike-dasm.

Issues when calling make result in errors:

error: 'CAUSE_MISALIGNED_FETCH' was not declared in this scope

error: 'CAUSE_FAULT_FETCH' was not declared in this scope

and about 10 others. Does this imply the install went awry? RISCV tools test seems to imply it is working properly.

Hi folks,

I was wondering if someone is already working on adding basic block vector generation for simpoint flow so that I can collaborate. If not I will be happy to work on adding this feature into Spike. If you think there's something better out there than using simpoint, let me know!

Hello, is there somewhere an exact information about what should be done to make possible compiling the code with added instruction? I followed all steps from "simulating a new instruction" in riscv-isa-sim readme (added a header file and a line in opcodes, and rebuilt spike) but it doesnt allow me to use new instruction. After rebuilding spike i dont have any new files in riscv-isa-sim/build and i doubt if anything is changed anywhere despite the files that i changed manually. When i try to compile code with new instruction i recieve "unrecognized opcode" error. I found somwhere on stackoverflow that the problem is that i somehow have to add instruction to assembler too, not only to simulator, but i don't know how to do it and i can't find any tips. So my question is what do i exactly have to do to write and use new instruction? Do i have to rebuild the whole toolchain or what?

Can you explain please, why am I getting differences in trace in this sim and objdump code
Test is rv32ui-p-simple,
Objdump (32bit):

00000200 <_start>:
200: f1002573 csrr a0,mhartid
204: 00051063 bnez a0,204 <_start+0x4>
208: f0002573 csrr a0,mcpuid

simulator trace (32bit pk):

core 0: 0x0000000000000200 (0x00000093) li ra, 0
core 0: 0x0000000000000204 (0x00000113) li sp, 0
core 0: 0x0000000000000208 (0x00000193) li gp, 0
core 0: 0x000000000000020c (0x00000213) li tp, 0
core 0: 0x0000000000000210 (0x00000293) li t0, 0
core 0: 0x0000000000000214 (0x00000313) li t1, 0
core 0: 0x0000000000000218 (0x00000393) li t2, 0
core 0: 0x000000000000021c (0x00000413) li s0, 0
core 0: 0x0000000000000220 (0x00000493) li s1, 0
core 0: 0x0000000000000224 (0x00000513) li a0, 0
core 0: 0x0000000000000228 (0x00000593) li a1, 0
core 0: 0x000000000000022c (0x00000613) li a2, 0
core 0: 0x0000000000000230 (0x00000693) li a3, 0
core 0: 0x0000000000000234 (0x00000713) li a4, 0
core 0: 0x0000000000000238 (0x00000793) li a5, 0
core 0: 0x000000000000023c (0x00000813) li a6, 0
core 0: 0x0000000000000240 (0x00000893) li a7, 0
core 0: 0x0000000000000244 (0x00000913) li s2, 0
core 0: 0x0000000000000248 (0x00000993) li s3, 0
core 0: 0x000000000000024c (0x00000a13) li s4, 0
core 0: 0x0000000000000250 (0x00000a93) li s5, 0
core 0: 0x0000000000000254 (0x00000b13) li s6, 0
core 0: 0x0000000000000258 (0x00000b93) li s7, 0
core 0: 0x000000000000025c (0x00000c13) li s8, 0
core 0: 0x0000000000000260 (0x00000c93) li s9, 0
core 0: 0x0000000000000264 (0x00000d13) li s10, 0
core 0: 0x0000000000000268 (0x00000d93) li s11, 0
core 0: 0x000000000000026c (0x00000e13) li t3, 0
core 0: 0x0000000000000270 (0x00000e93) li t4, 0
core 0: 0x0000000000000274 (0x00000f13) li t5, 0
core 0: 0x0000000000000278 (0x00000f93) li t6, 0
core 0: 0x000000000000027c (0xf1002573) csrr a0, mhartid
core 0: 0x0000000000000280 (0x02051063) bnez a0, pc + 32
core 0: 0x0000000000000284 (0x0000f117) auipc sp, 0xf
core 0: 0x0000000000000288 (0xd7b10113) addi sp, sp, -645

I assume that the top block of LI is just cpu restart instructions, but they start at pc=0x200, and the first test instruction is on pc=0x27c and then it jumps to 0x284 auipc sp, 0xf when objdump is said to continue with csrr a0,mcpuid. Also the bytecode is different for BNEZ instruction..

Where am I wrong?

In one test I am running, a 16bits instruction code as "8082" was printed as a MV instruction, this is wrong because this instruction is actually the C.JR instruction.

core 0: 0xffffffff8000196e (0x00008082) mv ra, zero // ---------------------This one
core 0: 0xffffffff80001a08 (0x04420613) addi a2, tp, 68

Nevertheless, although it is printed wrongly, but the PC is correct, it is indeeded executed as a C.JR instruction since next PC is jumped away.

Help message for option with values should be improved to specify all available values. Example:
--isa= RISC-V ISA string [default RV64IMAFDC]
I don't get what are all available.