Cache Failing

[yunjie-zhang]

Hi,

When I was trying to simulate mor1kx with modelsim, the execution flow always somehow "halted" after around 4700 instructions executed if I enabled DCache and ICache in mor1kx.v. The cache works for around 2000 instructions but halted after that. I haven't made any modification to anything else except mor1kx.v. Do I need to make any configuration to make it work properly or it should not be enabled.

Thanks.

[stffrdhrn]

Thanks for the report

Can you give some details of how to reproduce? Are you using a completely custom setup or mor1kx-generic with fusesoc? Can you provide the test program we can try to use to reproduce?

[yunjie-zhang]

Thanks for the report

Can you give some details of how to reproduce? Are you using a completely custom setup or mor1kx-generic with fusesoc? Can you provide the test program we can try to use to reproduce?

Hi,

Thanks for replying. I think I changed configuration in mor1kx.v in this way:

parameter OPTION_OPERAND_WIDTH = 32,

parameter OPTION_CPU0		= "CAPPUCCINO",

parameter FEATURE_DATACACHE		= "ENABLED",
parameter OPTION_DCACHE_BLOCK_WIDTH	= 5,
parameter OPTION_DCACHE_SET_WIDTH	= 9,
parameter OPTION_DCACHE_WAYS	= 2,
parameter OPTION_DCACHE_LIMIT_WIDTH	= 32,
parameter OPTION_DCACHE_SNOOP = "NONE",
parameter FEATURE_DMMU		= "NONE",
parameter FEATURE_DMMU_HW_TLB_RELOAD = "NONE",
parameter OPTION_DMMU_SET_WIDTH	= 6,
parameter OPTION_DMMU_WAYS		= 1,
parameter FEATURE_INSTRUCTIONCACHE	= "ENABLED",
parameter OPTION_ICACHE_BLOCK_WIDTH	= 5,
parameter OPTION_ICACHE_SET_WIDTH	= 9,

We are simulating it on other platform instead of FuseSOC with compiled MiBench.

[stffrdhrn]

Thanks, I'll have a try. Btw these are the settings I use in my tests. Which version of mor1kx are you using. Do you have a link to your mibench setup?

My settings...
https://github.com/stffrdhrn/mor1kx-generic/blob/master/rtl/verilog/orpsoc_top.v

.FEATURE_DEBUGUNIT		("ENABLED"),
	.FEATURE_CMOV			("ENABLED"),
	.FEATURE_EXT			("ENABLED"),
	.FEATURE_INSTRUCTIONCACHE	("ENABLED"),
	.OPTION_ICACHE_BLOCK_WIDTH	(5),
	.OPTION_ICACHE_SET_WIDTH	(8),
	.OPTION_ICACHE_WAYS		(2),
	.OPTION_ICACHE_LIMIT_WIDTH	(32),
	.FEATURE_IMMU			("ENABLED"),
	.FEATURE_DATACACHE		("ENABLED"),
	.OPTION_DCACHE_BLOCK_WIDTH	(5),
	.OPTION_DCACHE_SET_WIDTH	(8),
	.OPTION_DCACHE_WAYS		(2),
	.OPTION_DCACHE_LIMIT_WIDTH	(31),
	.FEATURE_DMMU			("ENABLED"),
	.OPTION_RF_NUM_SHADOW_GPR	(0),
	.IBUS_WB_TYPE			("B3_REGISTERED_FEEDBACK"),
	.DBUS_WB_TYPE			("B3_REGISTERED_FEEDBACK"),
	.OPTION_CPU0			(pipeline),
	.OPTION_RESET_PC		(32'h00000100)

I see you have disabled dmmu. Also, I noticed a strange issue with caches recently when all 32 pic pins were not connected. Can you confirm?

[stffrdhrn]

Hello, I think I was able to reproduce the issue, I am getting some failures after disabling IMMU/DMMU, but keeping CACHE's enabled. I'll look to see what the issue is.

[stffrdhrn]

BTW, under mibench there are many tests, which test are you running?

[stffrdhrn]

I did some additional investigation and testing, I found an issue in my test suite but not in the mor1kx. I cannot reproduce. I'll keep trying, but it would be helpful to get the code you are running to reproduce this.

[yunjie-zhang]

I did some additional investigation and testing, I found an issue in my test suite but not in the mor1kx. I cannot reproduce. I'll keep trying, but it would be helpful to get the code you are running to reproduce this.

Appreciate your replying. The platform we are using is CEP (https://github.com/mit-ll/CEP). I am not sure if you have any participation in that project. In the last two weeks, we were trying to figure out where the error occurs. Since you have told me that it works well on FuseSOC, I think there might be something wrong with its memory design. We might move to FuseSOC in our next step.

We got our code from http://vhosts.eecs.umich.edu/mibench/
And this is the makefile we are using:

FILE1 = basicmath_small.c rad2deg.c cubic.c isqrt.c
FILE2 = basicmath_large.c rad2deg.c cubic.c isqrt.c

all: basicmath_small basicmath_large

basicmath_small: ${FILE1} Makefile

or1k-elf-gcc -static -O3 -mboard=or1ksim-uart ${FILE1} -o basicmath_small -lm

basicmath_large: ${FILE2} Makefile
or1k-elf-gcc -static -O3 ${FILE2} -o basicmath_large -lm

clean:
rm -rf basicmath_small basicmath_large output*

Thank you.

[stffrdhrn]

Appreciate your replying. The platform we are using is CEP (https://github.com/mit-ll/CEP). I am not sure if you have any participation in that project. In the last two weeks, we were trying to figure out where the error occurs. Since you have told me that it works well on FuseSOC, I think there might be something wrong with its memory design. We might move to FuseSOC in our next step.

Hello, I have never heard of CEP, this looks like a neat project. I'll be happy to help if you have any issues there. I may try to run the tests there to see if I can find anything. I notice it uses an AXI bus instead of wishbone, which might be an issue. Also, it looks like its version of mor1kx (via submodule) is a bit old.

We got our code from http://vhosts.eecs.umich.edu/mibench/
And this is the makefile we are using:

Thanks, with those details I can confirm I am not seeing issues when run under fusesoc.

$ fusesoc sim --sim=icarus mor1kx-generic --elf-load ./basicmath_large --feature_immu NONE --feature_dmmu NONE
INFO: Preparing ::adv_debug_sys:3.1.0-r1
INFO: Preparing ::cdc_utils:0.1
INFO: Preparing ::elf-loader:1.0.2
INFO: Preparing ::intgen:0
INFO: Preparing ::jtag_tap:1.13-r1
INFO: Preparing ::jtag_vpi:0-r2
INFO: Preparing ::mor1kx:5.0-r3
INFO: Preparing ::uart16550:1.5.5-r1
INFO: Preparing ::verilog-arbiter:0-r2
INFO: Preparing ::vlog_tb_utils:1.1
INFO: Preparing ::wb_common:1.0.2
INFO: Preparing ::wb_bfm:1.2.1
INFO: Preparing ::wb_intercon:1.2.1
INFO: Preparing ::wb_ram:1.1
INFO: Preparing ::mor1kx-generic:1.0

iverilog-vpi --name=elf-loader_1.0.2 -lelf -I../src/elf-loader_1.0.2/ ../src/elf-loader_1.0.2/elf-loader.c ../src/elf-loader_1.0.2/vpi_wrapper.c
Compiling ../src/elf-loader_1.0.2/elf-loader.c...
Compiling ../src/elf-loader_1.0.2/vpi_wrapper.c...
Making elf-loader_1.0.2.vpi from  elf-loader.o vpi_wrapper.o...
iverilog-vpi --name=jtag_vpi_0-r2   ../src/jtag_vpi_0-r2/jtag_vpi.c
Compiling ../src/jtag_vpi_0-r2/jtag_vpi.c...
Making jtag_vpi_0-r2.vpi from  jtag_vpi.o...
iverilog -sorpsoc_tb -c mor1kx-generic_1.0.scr -o mor1kx-generic_1.0 -DSIM
vvp -n -M. -l icarus.log -lxt2 -melf-loader_1.0.2 -mjtag_vpi_0-r2 mor1kx-generic_1.0 +elf_load=/home/shorne/work/openrisc/mibench/automotive/basicmath/basicmath_large
Program header 0: addr 0x00000000, size 0x00018831
Program header 1: addr 0x0001A834, size 0x00000DEC
elf-loader: /home/shorne/work/openrisc/mibench/automotive/basicmath/basicmath_large was loaded
Loading       28040 words
                   0 : Illegal Wishbone B3 cycle type (xxx)
********* CUBIC FUNCTIONS ***********
Solutions: 2.000000 6.000000 2.500000
Solutions: 2.500000
Solutions: 1.635838
Solutions: 13.811084
Solutions: -3.947812
Solutions: -8.613092
Solutions: -0.914268
Solutions: 1.183481
Solutions: -9.460302 0.152671 -0.692369
Solutions: -9.454945 0.204689 -0.749744
Solutions: -9.449575 0.251115 -0.801540
Solutions: -9.444193 0.293392 -0.849199
Solutions: -9.438798 0.332431 -0.893633
...