riscv-verification / rvvi Goto Github PK

Hey
We are developing risc-v simulator and try to simulator XV6 os, we failed, somehow it crash after executed millions instructions. Can this framework help us to amend the errors, we believe we simulate virtio wrongly?
thanks
Peter

https://github.com/riscv-verification/RVVI/tree/main/RVVI-VLG states:

halt

When this signal is true, it indicates that the hart has gone into a halted state at this instruction.

Which official RISC-V instructions would you expect would raise this signal (if any)?

Hello,

There is a rvviDutTrap() function in https://github.com/riscv-verification/RVVI/blob/main/include/host/rvvi/rvviApi.h.

Is the parameter dutPc the last retired PC or the exception PC?

When taking trap/exception, the current PC is the exception PC that has not retired yet and will be jumped back to after the trap. Thus, there is no retired PC upon taking trap/exception. However, the comment states the dutPc is the retired PC. Does the dutPc here mean exception PC?

Thank you.

https://github.com/riscv-verification/RVVI/tree/main/RVVI-VLG states:

ISSUE

This is the maximum number of instructions that can be retired during a valid event.

Can the signal be renamed to RETIRE if that is what is means?

The SystemVerilog Interface rvvi_vlg.sv declares two "clocks" that are delay-shifted from "clk":

wire                       clk;
wire                       clk1;                                  // clock+1
wire                       clk2;                                  // clock+2
assign #1 clk1 = clk;
assign #2 clk2 = clk;

These clocks are used in ImperasHome/ImpPublic/source/host/rvvi/rvvi-vlg.sv and ImperasHome/ImpProprietary/source/host/rvvi/vlg2api.sv (part of the ImperasDV SDK).

It is generally considered bad form to use delayed clocks to sample signals and in theory is not needed.

Is there a reason we have these?

https://github.com/riscv-verification/RVVI/tree/main/RVVI-VLG states:

intr

When this signal is true, it indicates that this retired instruction is the first instruction which is part of a trap handler.

Any trap handler, so not only regular interrupts, but also NMI, exceptions, debug entry, debug exception entry?

Hi!

In the current version of the trace interface, the mode field only incorporates M, S and U. This is all fine, but for hardware with hypervisor capabilities there is from what I can tell no way to signal the current virtualization mode V. Is this something which you plan to add to RVVI?

https://github.com/riscv-verification/RVVI/tree/main/RVVI-VLG states:

csr_wb, csr

If the bit position within csr_wb is true, then a the position indicates a write into csr, eg if csr_wb=0x1, then the ustatus register (address 0x000) has been written. If csr_wb=(1<<4 | 1<<0) then address 0x004 and 0x001 have been written concurrently csr_wb=0x0 indicates no written csr.

Are these used as well to report the side effects of taken interrupts?

Please provide a brief description about the order and trap signals used in trace interface.

Thanks

https://github.com/riscv-verification/RVVI/tree/main/RVVI-VLG states:

trap

When this signal is true along with valid, an instruction execution has undergone a synchronous exception (syscalls, etc). This event allows the reading of internal state. The instruction address trapped is indicated by the pc_rdata variable. If this signal is false when valid is asserted, then an instruction has retired. This signal will not be asserted during an asynchronous exception.

What is meant by ‘asynchronous exception’. In RISC-V terminology exceptions are by definition synchronous.
How about synchronous debug mode entry; will they lead to trap = 1?