rsd-devel/rsd

RSD: RISC-V Out-of-Order Superscalar Processor

RSD RISC-V Out-of-Order Superscalar Processor

RSD is a 32-bit RISC-V out-of-order superscalar processor core. RSD is very fast due to aggressive OoO features, while it is very compact and can be synthesized for small FPGAs. The key features of RSD are as follows:

• ISA
  • Support RV32IMF
  • Support Zephyr applications
• Microarchitecture
  • 2-fetch front-end and 6-issue back-end pipelines
  • Up to 64 instructions are in-flight.
    • These parameters can be configurable.
  • A high-speed speculative instruction scheduler with a replay mechanism
  • Speculative OoO load/store execution and dynamic memory disambiguation
  • Non-blocking L1 data cache
  • Support AXI4 bus
• Implementation
  • Written in SystemVerilog
  • Can be simulated with Modelsim/QuestaSim, Verilator, and Vivado
  • Can be synthesized with Synplify, Vivado and Design Compiler
    • Design Compiler support is experimental
  • Can run on a Xilinx Zynq board
    • Avnet Zedboard
  • FPGA optimized RAM structures

Getting started

Simulation on Verilator/Modelsim/QuestaSim/Vitis

1. Install the following software for running simulation.

   • GNU Make, Python3, and GCC (x86-64) 6 or later
   • GCC (RISC-V) 7 or later
   • Verilator or Modelsim/QuestaSim or Xilinx Vitis 2019.2

   Tested environment:

   • GNU Make 4.0
   • Python 3.4.2
   • GCC 6.5.0 (x86-64)
   • GCC 8.1.0 (RISC-V)
   • Verilator 4.026 2020-01-11 rev v4.026-2-g0c6c83e
   • QuestaSim 2019.4.2
   • Vitis 2019.2

2. Refer to scripts in Processor/Tools/SetEnv.sh and set environment variables.

   • RSD_ROOT must be set for running simulation.
   • RSD_VERILATOR_BIN, RSD_QUESTASIM_PATH or RSD_VIVADO_BIN must be set.
     • See this page.

3. Go to Processor/Src and make as follows.

   • For Modelsim/QuestaSim

     make            # compile
     make run        # run simulation
     make kanata     # run simulation & outputs a konata log file
     

   • For Verilator, add -f Makefile.verilator.mk like make -f Makefile.verilator.mk run
   • For Vivado, add -f Makefile.vivado.mk like make -f Makefile.vivado.mk run

4. If the simulation ran successfully, you find "kanata.log" in Processor/Src.

   • Note that, the above sub-command is "kanata", not "konata".

5. You can see the execution pipeline of your simulation above with Konata.

   • Konata is a pipeline visualizer and can be downloaded from here
   • An example is shown below.
   • 

Run on a Xilinx Zynq board

• See this RSD wiki page.

Documents

• See RSD Wiki.

License

Copyright 2019-2023 Ryota Shioya ([email protected]) and RSD contributors, see also CREDITS.md. This implementation is released under the Apache License, Version 2.0, see LICENSE for details. This implementation integrates third-party packages in accordance with the licenses presented in THIRD-PARTY-LICENSES.md.

References

Susumu Mashimo et al., "An Open Source FPGA-Optimized Out-of-Order RISC-V Soft Processor", IEEE International Conference on Field-Programmable Technology (FPT), 2019. A pre-print version is here.

rsd's Issues

Booting Linux

Hello!

Thanks for your fantastic core. I was wondering if it is capable of booting Linux. I've not find any specific statment regarding this so far.

Thank you very much,

Daniel J.M

flow to synthesis netlist and bitstream from Vivado alone

I find out that this project has a branch "support-vivado-alone-synthesis". Does this mean rsd is able to synthesis by Vivado only(no need Synplify)?

In Project/Vivado/Zedboard(support-vivado-alone-synthesis branch), it contains some vivado and xsdk script to generate vivado project. However, Project/Vivado/Zedboard/Script also contains some script to create vivado synthesis project. Whats the difference between two vivado post-synthesis scripts? In Project/Src/Makefiles/Vivado.inc.mk seems that it has rsd.vm (Synplify generate netlist) dependency.

Off by one error in leading 0 count loop?

Looks like there's an off by one in this for loop

rsd/Processor/Src/FloatingPointUnit/FP32PipelinedFMA.sv

Line 138 in bc874fc

for(leading_zeros_count = 0; leading_zeros_count <= 76; leading_zeros_count = leading_zeros_count + 1)

It should either be '<76' or '<=75', given it iterates over a 76b vector.

Vivado synth 8-659 : type mismatch in port association

Hi,
I am trying to synthesize the rsd for Zynq zcu102 board. I have the following issues/observations

1. Main_Zynq_wrapper still uses SystemVerilog constructs - Worked around by writing two wrappers.
2. The RAM_Vivado.sv - DistributedMultiPortRAM is missing the ENTRY_NUM parameter
3. I get the synthesis error
   Eg. [Synth 8-659] type mismatch in port association: bit [5:0]A[0:0] vs. bit [3:0]B[0:0] ()
   This happens on ports .wa and .ra of DistributedMultiPortRAM
   This is Xilinx recommendation - https://www.xilinx.com/support/answers/64034.html

However, I am trying to unpack the structure for every instance

Example :
Before fixing (original)

DistributedMultiPortRAM #(
    .ENTRY_NUM( ISSUE_QUEUE_ENTRY_NUM ),
    .ENTRY_BIT_SIZE( $bits(Entry) ),
    .READ_NUM( WAKEUP_WIDTH ),
    .WRITE_NUM( DISPATCH_WIDTH )
) dstRAM (
    .clk( port.clk ),
    .we( write ),
    .wa( writePtr_flat ),
    .wv( writeData ),
    .ra( readPtr_flat ),
    .rv( readData )
);

---

AFTER fixing

reg [$bits(IssueQueueIndexPath)+1:0] writePtr_flat[DISPATCH_WIDTH];
always_comb begin
    for(int i = 0; i < DISPATCH_WIDTH; i=i+1) begin
        writePtr_flat[i] = port.writePtr[i];
    end
end

reg [$bits(IssueQueueIndexPath)+1:0] readPtr_flat[WAKEUP_WIDTH];
always_comb begin
    for(int i = 0; i < WAKEUP_WIDTH; i=i+1) begin
        readPtr_flat[i] = readPtr[i];
    end
end


DistributedMultiPortRAM #(
    .ENTRY_NUM( ISSUE_QUEUE_ENTRY_NUM ),
    .ENTRY_BIT_SIZE( $bits(Entry) ),
    .READ_NUM( WAKEUP_WIDTH ),
    .WRITE_NUM( DISPATCH_WIDTH )
) dstRAM (
    .clk( port.clk ),
    .we( write ),
    //.wa( writePtr ),
    .wa( writePtr_flat ),
    .wv( writeData ),
    //.ra( readPtr ),
    .ra( readPtr_flat ),
    .rv( readData )
);

---

I fixed at multiple places but there are far too many. Is there a generic solution to avoid this manual hacking for Xilinx synthesis?

Thanks,
Jagannath

Add benchmark / resource usage information

Would you mind adding some benchmark / resource usage information for the core?

The VexRISCV README has the following;

VexRiscv smallest (RV32I, 0.52 DMIPS/Mhz, no datapath bypass, no interrupt) ->
    Artix 7     -> 233 Mhz 494 LUT 505 FF
    Cyclone V   -> 193 Mhz 347 ALMs
    Cyclone IV  -> 179 Mhz 730 LUT 494 FF
    iCE40       -> 92 Mhz 1130 LC

....

VexRiscv full max dmips/mhz -> (RV32IM, 1.44 DMIPS/Mhz 2.70 Coremark/Mhz,, 16KB-I$,16KB-D$, single cycle barrel shifter, debug module, catch exceptions, dynamic branch prediction in the fetch stage, branch and shift operations done in the Execute stage) ->
    Artix 7     -> 140 Mhz 1767 LUT 1128 FF
    Cyclone V   -> 90 Mhz 1,089 ALMs
    Cyclone IV  -> 79 Mhz 2,336 LUT 1,048 FF

VexRiscv full with MMU (RV32IM, 1.24 DMIPS/Mhz 2.35 Coremark/Mhz, with cache trashing, 4KB-I$, 4KB-D$, single cycle barrel shifter, debug module, catch exceptions, dynamic branch, MMU) ->
    Artix 7     -> 161 Mhz 1985 LUT 1585 FF
    Cyclone V   -> 124 Mhz 1,319 ALMs
    Cyclone IV  -> 122 Mhz 2,710 LUT 1,501 FF

VexRiscv linux balanced (RV32IMA, 1.21 DMIPS/Mhz 2.27 Coremark/Mhz, with cache trashing, 4KB-I$, 4KB-D$, single cycle barrel shifter, catch exceptions, static branch, MMU, Supervisor, Compatible with mainstream linux) ->
    Artix 7     -> 170 Mhz 2530 LUT 2013 FF
    Cyclone V   -> 125 Mhz 1,618 ALMs
    Cyclone IV  -> 116 Mhz 3,314 LUT 2,016 FF

My general guidance around the performance of soft-cores is listed in the following table;

Meltdown on RSD processor

Hi,

I am the master student from Taiwan. I'm currently studying the issue about meltdown attack. Because RSD processor is an out of order processor, I would like to ask whether this processor has any safety concerns about meltdown?

Thank you very much!

wrong pointer used for poping btb queue

Literally in the btbQueuePointer the comment pointes out The "tailPtr" points the address of a next pushed entry.

BTB used headPtr for pushing entry. See code line below.

    else if (pushBtbQueue) begin
        btbQueue[headPtr].btbWA <= btbWA[INT_ISSUE_WIDTH-1];
        btbQueue[headPtr].btbWV <= btbWV[INT_ISSUE_WIDTH-1];
    end 

Similarly, to pop the queue, tailPtr was used so stale/invalid data was fetched:

    // Pop btb Queue
    if (!empty && !updateBtb) begin
        popBtbQueue = TRUE;
        btbWE[0] = TRUE;
        btbWA[0] = btbQueue[tailPtr].btbWA;
        btbWV[0] = btbQueue[tailPtr].btbWV;
    end 

The low bit of mepc is not updated correctly

Observed Behavior

The low bit of mepc is always zero, as described in Chapter 3.1.19 of RISC-V Privileged Architectures.

mepc is an XLEN-bit read/write register formatted as shown in Figure 3.20. The low bit of mepc (mepc[0]) is always zero. On implementations that do not support instruction-set extensions with 16-bit instruction alignment, the two low bits (mepc[1:0]) are always zero.

For example, csrw mepc, 0x1 is a instruction to set the low bit of mepc. In the current RSD implementation, when such an instruction is executed, the low bit of mepc is set. If the low bit of mepc is updated correctly, the low bit of mepc will always be zero.

Steps to reproduce the issue

The code below writes the value 1 to mepc and then reads the value of mepc. When you execute the following code, you can confirm that the value of mepc is 1. Correctly, the value of mepc should be zero.

int main(void){
    asm volatile ("csrw mepc, 0x1;\
                   csrr t0, mepc");
}

Attempts to access a non-existent CSR don't raise illegal instruction exceptions

Observed Behavior

An illegal instruction exception should be raised when accessing a non-existent CSR, as described in Chapter 3.6.1 of RISC-V Privileged Architectures.

Attempts to access a non-existent CSR raise an illegal instruction exception.

For example, csrr t0, 0x394 is a instruction to access a CSR with address 0x394 that does not exist.

Therefore, this instruction should raise an illegal instruction exception, but in the current RSD, this instruction is executed normally without raising an illegal instruction exception. This issue applies to other CSRs as well.

Steps to reproduce the issue

When executing an instruction that accesses a non-existent CSR, as shown in the following code, you can confirm that the illegal instruction executes normally without raising an illegal instruction exception.

int main(void){
    asm volatile ("csrr t0, 0x394");
}

error running the Makefile.verilator.mk

im trying to run make -f Makefile.verilator.mk run and i got this error:
../Project/Verilator/obj_dir/VMain_Zynq_Wrapper
MAX_TEST_CYCLES=100000
TEST_CODE=Verification/TestCode/Asm/FP ENABLE_PC_GOAL=1 SHOW_SERIAL_OUT=1
make: ../Project/Verilator/obj_dir/VMain_Zynq_Wrapper: No such file or directory
make: *** [Makefile.verilator.mk:93: run] Error 127
im wondering where does the /Project/Verilator/obj_dir/VMain_Zynq_Wrapper comes from as i couldnt find it in this github, thanks a lot

cannot convert ‘const VlWide<92>’ to ‘const uint32_t (&)[92]’ {aka ‘const unsigned int (&)[92]’}

I use the verilator branch v4.026-2-g0c6c83e to run Simulation. But when I make Makefile.verilator.mk, I get the error
"In file included from ../../../Src/SysDeps/Verilator/TestMain.cpp:4:
../../../Src/SysDeps/Verilator/VerilatorHelper.h:475:85: error: cannot convert ‘const VlWide<92>’ to ‘const uint32_t (&)[92]’ {aka ‘const unsigned int (&)[92]’}
475 | d->memberName0.memberName1 = h->DebugRegister_##memberName0##_##memberName1(r);
| ^
| |
| const VlWide<92>
../../../Src/SysDeps/Verilator/VerilatorHelper.h:732:5: note: in expansion of macro ‘RSD_MAKE_STRUCT_ACCESSOR_LV2’
732 | RSD_MAKE_STRUCT_ACCESSOR_LV2(DebugRegister, perfCounter, DataPath, numBranchPredMissDetectedOnDecode)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from ./VMain_Zynq_Wrapper__Syms.h:16,
from ../../../Src/SysDeps/Verilator/TestMain.cpp:2:"
It seems like a verilator version problem, How should I fix it?

compile.tcl file is deprecated

Processor/Project/DesignCompiler/compile.tcl is deprecated.
There is file CachePrimitives.sv on the file list that is no longer in repository (removed in cca6d6e) and there are two files HardwareCounter.sv and HardwareCounterIF.sv that changed their names (in d77ca53)
I don't know if there are other problems.

Can RSD set the access permissions on a certain memory address?

Hi,

I have seen the operation of RSD in memory mapping, and it seems to use simple static address translation instead of a mechanism like Page table. So is RSD unable to set memory permissions like the page table mechanism? Or does RSD have other methods to support memory permissions?

Thank you!

Cache and BP Disable Possible Way

Hello, I want to ask if there is a easy way to disable the I/D cache and BP? It seems some parameters of cache and bp can be adjusted in the configuration file but they cannot be totally disabled. Thank you so much :-)

About the reset cycle

Hi,

I am the master student from National Cheng Kung University, Taiwan, and I'm interesting in your design but there are some problems about the reset cycle.

In ResetController.sv, the CYCLE_OF_RESET_SEQUENCE is set to 10000. Why we need so many cycles to reset the CPU? Is it related to FPGA simulation?

If I use Modelsim/Verilator to simulate and set the CYCLE_OF_RESET_SEQUENCE to a smaller number (e.g. 10), does it influence the simulation result?

Thank you!

Installing Konata

Hey guys,
I am unable to install konata. Readme file says run konata or konata.exe file.
I have downloaded the linux verison, but I am unable to insall the package.
Please help out

UnicodeDecodeError for RunTest.py script when running tests on Docker

"UnicodeDecodeError: 'utf-8' codec can't decode byte 0xff in position 1: invalid start byte"

Files with serial data used for outStr, refStr in SerialOutputComparator class in script Processor\Tools\TestDriver\RunTest.py are opened in UTF-8 on Docker. Maybe it would be better if it was binary comparison.

[Bug Report] RSD didn't update fflags.NX correctly after fnmadd.s instruction

Environment:

RSD version: bd7c5c1

Bug Description:

There is a instruction fnmadd.s fs9, ft0, fs8, fa7, and ft0=0x6041bb47, fs8=0x42ad0f08, fa7=0xf86cc8d7.

After the fnmadd.s instruction, fflags maintains 0x0 in RSD. However, fflags becomes0x1 in spike.

It seems that RSD didn't update fflags.NX correctly?

Issues while compiling the code

Hey guys,
Sorry, I am new to this, so please help me out. I am trying to compile your code via verilator, I am getting the following errors:

%Warning-LATCH: LoadStoreUnit/StoreCommitter.sv:184:5: Latch inferred for signal 'dcWriteUncachable' (not all control paths of combinational always assign a value)
: ... In instance Main_Zynq_Wrapper.main.core
: ... Suggest use of always_latch for intentional latches
184 | always_comb begin
| ^~~~~~~~~~~
%Error: Exiting due to 18 warning(s)
make: *** [Makefile.verilator.mk:84: all] Error 1

Could you help me out in fixing this? Looks like issue from the design code.
This is the command I used : make -f Makefile.verilator.mk

Add to LiteX ecosystem?

RSD looks like it would be a super interesting addition CPU core option for the LiteX Ecosystem. LiteX already supports multiple different RISC-V cores (see https://github.com/enjoy-digital/litex/wiki/Soft-CPU for the list);

• VexRISCV (https://github.com/SpinalHDL/VexRiscv)
• Rocket
• BlackParrot (https://github.com/black-parrot/pre-alpha-release)
• others...

It would be awesome to see RSD in the LiteX system. It would let us very easily compare the resource usage of RSD to Black-Parrot, to Rocket, and VexRISCV in a fair environment.

LiteX-BuildEnv is my environment which uses LiteX to create images for many different FPGA boards. It supports Zephyr, Linux, Micropython and bare metal firmware.

You can find a diagram of this below;

There is also a Linux on LiteX VexRISCV repository which would be cool to port to use RSD as an alternative option.

You can find the existing CPUs at https://github.com/enjoy-digital/litex/tree/master/litex/soc/cores/cpu
Rocket is probably the closest configuration which can be found at https://github.com/enjoy-digital/litex/blob/master/litex/soc/cores/cpu/rocket/core.py

Does RSD support Supervisor mode or User mode?

Hi!

After I read the documents and source codes of RSD, it seems that RSD can only support Machine mode.

Is it possible to support Supervisor mode or User mode? Or does RSD have technology like PMP etc...?

Thanks!

Report 'Memory address 0x1e38 is invalid' when running helloworld.elf in spike

Hi,

I find that when running helloworld.elf(exactly~/rsd/Processor/Src/Verification/TestCode/C/HelloWorld/code.elf) in the latest spike, it reports the following message:

Do you know how to address this problem? I have no idea at the moment.

Looking forward to your reply:)

PC becomes 0x00000000 after jump to 0x80000000 to execute auipc instruction

Modifications made to RSD:

• Let PC_GOAL=0x80000370
• Comment define RSD_NARROW_PC in MemoryMapTypes.sv in order to let pc be 32-bit

Test program:
I set bootrom code block in ROM, and then jump to RAM to execute instructions. The disassembly code of test program is as follows:

Results:
No more instructions are submitted after jumping to pc=0x80000000(including instruction at pc=0x80000000 ), and RSD reports deadlock.
I find that the pc pushed to activelist becomes 0x00000000 after the last pc 0x80000000. That's the reason why it will report deadlock.

Question:
Why pc becomes 0x00000000 and how to address this problem?

Here is the waveform used for debugging.
https://transfer.pcloud.com/download.html?code=5Z2w4X0ZdESCcBq5M9pZWfR3Z56T52K9ksCBqvRc36Fd9UjQhBBpk

[Bug Report] Incorrect upward rounding result of fsub.s instruction

Hi,

When executing the fsub.s ft5, ft5, ft2, rup instruction in Spike, I found that the result is incorrect, where ft5 is initialized as 0x284d52df and ft2 is initialized as 0x7b418a35.
I believe the correct final result in ft5 should be 0xfb418a34 (as Spike does), however, the result calculated in RSD is 0xfb418a35.

[Bug Report] Wrong sign bit when 0 is multiplied by a negative number

Environment:

RSD version: bd7c5c1

Bug Description:

There is an instruction fmul.s ft9, fs4, ft8, where fs4=0x00000000 and ft8=0x998a3664.

After the fmul.s instruction, the result of ft9 in RSD is 0x00000000. However, the result in spike is 0x80000000.

It seems that RSD mistakes the sign bit of the final result?

Any plan about supporting compressed extension?

RVC is supposed to lessen the pressure of icache, it would be amazing to support RVC.

[Bug Report] Wrong result of `+0` minus `+0`

Hi,
when executing +0 minus +0, the result in rsd is -0. However, i think it should be +0.

Is there something wrong in the implementation? Could you help me confirm this problem?

[Bug Report] `fflags.NV` is not set correctly after `fsqrt.s` instruction

Environment:

RSD version: bd7c5c1

Bug Description:

There is an instruction fsqrt.s fa6, ft3, where ft3=0xa18d6339.

After the fsqrt.s instruction, fflags.NV flag in RSD maintains 0 . However, fflags.NV flag in spike is set to 1 .

It seems that RSD doesn't update fflags.NV correctly?

[Bug Report] OF flag bit in fflags is not set correctly after fdiv.s instruction

Hi,

There a floating-point arithmetic instruction fdiv.s ft9, ft6, fs10, which ft6=0xfd5d363b, fs10=0x9b068cda and the original value of fflags=0x00000001. But after executing this instruction, fflags remains 0x00000001, not the expected value 0x00000005(Spike does so).

So I wonder if this is a real bug or a problem on floating-point accuracy?

[Bug Report] `fflags.DZ` set incorrectly after `fdiv.s` instruction

Environment:

RSD version: bd7c5c1

Bug Description:

There is an instruction fdiv.s fs1, fa4, ft7, where fa4=0x47bca361 and ft7=0x00000000.

After the fdiv.s instruction, fflags.DZ flag in RSD maintains 0 . However, fflags.DZ flag in spike is set to 1 .

It seems that RSD update fflags.DZ incorrectly.

[Bug Report] `fflags.UF` is not set correctly after `fdiv.s` instruction

Environment:

RSD version: bd7c5c1

Bug Description:

There is an instruction fdiv.s fs3, fa5, fa4, where fa5=0x3292f14b and fa4=0x71da37da .

After the fdiv.s instruction, fflags.UF flag in RSD maintains 0 . However, fflags.UF flag in spike is set to 1 .

It seems that RSD updates fflags.UF incorrectly?

Illegal shift instructions don't raise illegal instruction exceptions

Observed Behavior

An illegal instruction exception should be raised when the shift amount of the shift instructions is 32 or more, as described in Chapter 4.2 of RISC-V User-Level ISA.

For RV32I, SLLI, SRLI, and SRAI generate an illegal instruction exception if imm[5] 6= 0.

For example, the following three instructions have a shift amount of 32 and are decoded as illegal instructions for RV32I.

0x02029313        slli    t1, t0, 0x20
0x0202d313        srli    t1, t0, 0x20
0x4202d313        srai    t1, t0, 0x20

Therefore, such instructions should raise an illegal instruction exception, but in the current RSD, such instructions are executed normally without raising an illegal instruction exception.

Steps to reproduce the issue

If you execute a code that embeds an invalid shift instruction like the code below, you can confirm that the illegal instruction executes normally without raising an illegal instruction exception.

int main(void){
    asm volatile (".byte 0x13, 0x93, 0x02, 0x02");
}

Any provision for secure coding?

Hi,
I was looking into security aspects of RISCV processors. Is there any provision for making a block of memory secure in rsd? Like TZPC for ARM?
Regards,
Shrinidhi

Error when run in verilator: no viable conversion from 'const VlWide<92>' to 'const uint32_t [92]'

Hi!

When I run sudo make -f Makefile.verilator.mk, it reports errors:

clang++ -D RSD_FUNCTIONAL_SIMULATION_VERILATOR -D RSD_FUNCTIONAL_SIMULATION -D RSD_VERILATOR_TRACE -D RSD_MARCH_FP_PIPE -Wno-attributes -I. -MMD -I/usr/local/share/verilator/include -I/usr/local/share/verilator/include/vltstd -DVM_COVERAGE=0 -DVM_SC=0 -DVM_TRACE=1 -DVM_TRACE_FST=0 -faligned-new -fbracket-depth=4096 -fcf-protection=none -Qunused-arguments -Wno-bool-operation -Wno-tautological-bitwise-compare -Wno-parentheses-equality -Wno-sign-compare -Wno-uninitialized -Wno-unused-parameter -Wno-unused-variable -Wno-shadow -Os -include limits -std=gnu++14 -Os -c -o TestMain.o ../../../Src/SysDeps/Verilator/TestMain.cpp
In file included from ../../../Src/SysDeps/Verilator/TestMain.cpp:4:
../../../Src/SysDeps/Verilator/VerilatorHelper.h:482:5: error: no viable conversion from 'const VlWide<92>' to 'const uint32_t [92]'
RSD_MAKE_DEBUG_REG_STAGE_ACCESSOR(DebugRegister, npReg, logic, valid);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../../Src/SysDeps/Verilator/VerilatorHelper.h:455:64: note: expanded from macro 'RSD_MAKE_DEBUG_REG_STAGE_ACCESSOR'
i.member = h->DebugRegister_##stage####member(r, index);
^
/usr/local/share/verilator/include/verilated_types.h:146:5: note: candidate function not viable: 'this' argument has type 'const VlWide<92>', but method is not marked const
operator WDataOutP() { return &m_storage[0]; } // This also allows []
^
/usr/local/share/verilator/include/verilated_types.h:147:5: note: candidate function
operator WDataInP() const { return &m_storage[0]; } // This also allows []
^
./VMain_Zynq_Wrapper_VerilatorHelper.h:187:54: note: passing argument to parameter 'e' here
bool DebugRegister_npReg_valid(const uint32_t (& e)[92], uint32_t i);
^
In file included from ../../../Src/SysDeps/Verilator/TestMain.cpp:4:
../../../Src/SysDeps/Verilator/VerilatorHelper.h:483:5: error: no viable conversion from 'const VlWide<92>' to 'const uint32_t [92]'
RSD_MAKE_DEBUG_REG_STAGE_ACCESSOR(DebugRegister, npReg, OpSerial, sid);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../../Src/SysDeps/Verilator/VerilatorHelper.h:455:64: note: expanded from macro 'RSD_MAKE_DEBUG_REG_STAGE_ACCESSOR'
i.member = h->DebugRegister##stage##_##member(r, index);
^
/usr/local/share/verilator/include/verilated_types.h:146:5: note: candidate function not viable: 'this' argument has type 'const VlWide<92>', but method is not marked const
operator WDataOutP() { return &m_storage[0]; } // This also allows []
^
/usr/local/share/verilator/include/verilated_types.h:147:5: note: candidate function
operator WDataInP() const { return &m_storage[0]; } // This also allows []
^
./VMain_Zynq_Wrapper_VerilatorHelper.h:186:56: note: passing argument to parameter 'e' here
uint32_t DebugRegister_npReg_sid(const uint32_t (& e)[92], uint32_t i);
^
In file included from ../../../Src/SysDeps/Verilator/TestMain.cpp:4:
../../../Src/SysDeps/Verilator/VerilatorHelper.h:485:5: error: no viable conversion from 'const VlWide<92>' to 'const uint32_t [92]'
RSD_MAKE_DEBUG_REG_STAGE_ACCESSOR(DebugRegister, ifReg, logic, valid);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I don't know why these errors occur. My environment configurations are as follows:

export RSD_ROOT=~/rsd
export RSD_GCC_PATH=/opt/riscv32/bin
export PATH=$PATH:$RSD_GCC_PATH
export RSD_GCC_PREFIX=riscv32-unknown-elf-
export RSD_VERILATOR_BIN=~/verilator/bin

Verilator version: v4.106

zhangkanqi@hwfuzz:~/rsd/Processor/Src$ verilator -V
Verilator 4.106 2020-12-02 rev v4.106
Copyright 2003-2020 by Wilson Snyder. Verilator is free software; you can
redistribute it and/or modify the Verilator internals under the terms of
either the GNU Lesser General Public License Version 3 or the Perl Artistic
License Version 2.0.
See https://verilator.org for documentation
Summary of configuration:
Compiled in defaults if not in environment:
SYSTEMC =
SYSTEMC_ARCH =
SYSTEMC_INCLUDE =
SYSTEMC_LIBDIR =
VERILATOR_ROOT = /usr/local/share/verilator
SystemC system-wide = 0
Environment:
MAKE =
PERL =
SYSTEMC =
SYSTEMC_ARCH =
SYSTEMC_INCLUDE =
SYSTEMC_LIBDIR =
VERILATOR_ROOT = /home/zhangkanqi/verilator
VERILATOR_BIN =
Features (based on environment or compiled-in support):
SystemC found = 0

zhangkanqi@hwfuzz:~/rsd/Processor/Src$ /usr/local/bin/verilator --version
Verilator 4.106 2020-12-02 rev v4.106

gcc version: 13.2.0

zhangkanqi@hwfuzz:~/rsd/Processor/Src$ riscv32-unknown-elf-gcc --version
riscv32-unknown-elf-gcc (gc891d8dc23e) 13.2.0
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Github seems unable to detect this repo as Apache 2.0 licenced

GitHub doesn't see this repository as Apache 2.0 licensed. It would be awesome if this was fixed.

You can find out how license detection works at https://help.github.com/en/github/creating-cloning-and-archiving-repositories/licensing-a-repository#detecting-a-license

Wiki issue

In the Wiki under "en arch microarch" there is a link to refer too:

An Open Source FPGA-Optimized Out-of-Order RISC-V Soft Processor

However this link does not work.

[Bug Report] RSD doesn't update mstatus after `mret` instruction

Bug Description:

The previous value of mstatus is 0x00007800, but after executing mret instruction, mstatus is still 0x00007800.
However, according to the riscv specification as below, mstatus should be 0x80006080, which spike does so.

Konata Wrong Statistics

I wanted to let you know of an issue I discovered regarding the Konata viewer. For a Bubblesort program I run (about 1000000 cycles) the hardware counters report 8926 branch prediction misses whereas the Konata statistics page reports 36 misses out of 2409 fetched branch instructions. I used the latest pre-built version of Konata. I am attaching the hex file and the source code of the bubble sort program and screenshots of the verilator and Konata results


bubblesort.zip

[Bug Report] SD bit in mstatus doesn't update when FS=11

Hi,

After runing instruction csrs mstatus, a0(a0=0x00007800) in rsd, mstatus is set to 0x00007800, not the expected value 0x80007800.

According to the privilege specification of RISC-V, if FS=11, SD should be set to 1.

So I wonder is this a bug in rsd?

Benchmark access (RSD-env)

Hi,

I was looking at some Coremark performance number to compare against https://github.com/SpinalHDL/NaxRiscv, but got multiple issues :

• Can't find any documentation about coremark performances
• Can't find the Coremark port, as it is in the RSD-env closer repository

Would it be possible to either publish the coremark performances, or release some precompiled binaries, or open source a part of RSD-env ?

By the way, I used Konata quite a bit, it was very usefull, thanks ! :D

Charles

Use C libraries like string.h and stddef.h

Is there a way to use some of the libraries included with the gnu toolchain when writing programs ? Whenever I try to use the string library I get the following error

undefined reference to `strlen'

I have tried removing the -ffreestanding -fno-builtin -nostdlib -nodefaultlibs flags from the Makefile but I've had no luck

[Bug Report] `fflags` records the accumulated status incorrectly

Bug Description:

After a fcvt.wu.s instruction, fflags becomes 0x1. But then after a bltu instruction, fflags becomes 0x0.

I find the source code of RSD as follows(in CommitStage.sv):

`ifdef RSD_MARCH_FP_PIPE
        // CSR FFLAGS Update
        fflagsWE = FALSE;
        fflagsData = '0;
        for (int i = 0; i < COMMIT_WIDTH; i++) begin
            if (commit[i]) begin
                fflagsWE = TRUE;
                fflagsData |= activeList.fflagsData[i];
            end
        end
        csrUnit.fflagsWE = fflagsWE;
        csrUnit.fflagsData = fflagsData;
`endif

It seems that RSD wants to record the accumulated status of fflags. If so, fflags should be 0x1 after bltu instruction rather than 0x0.

I wonder if this is a bug? Thank u :)