"bitwise AND" and "bitwise XOR" are not working

[hossameldin1995]

Hi I synthesised your potato SoC and I tried a "bitwise AND" and "bitwise XOR" and thehre is a bug while execute these operations

This is the "AND" code. In the comment you will find the result that is expected

This is the simulation of "AND" code on modelsim. You will find at 86988ps alu_x = 0x11, alu_y = 0x5B, and alu_result = 0x11.
alu_x should be 0x31 and this is wrong to be sure I will show you the contents of the memory
the output is right as expected because the alu_x is the result as you will understand in "XOR" code.

This is the contents of memory and all is right.

---

This is the "XOR" code. In the comment you will find the result that is expected

This is the simulation of "XOR" code on modelsim. You will find at 25754ps alu_x = 0x31, alu_y = 0x5B, and alu_result = 0x6A.
and all is right as expected
but in the second image you will find at 25805ps alu_x = 0x6A, alu_y = 0x5B, and alu_result = 0x31.
alu_x has the result of the previus operation and this is not expected so the output is 0x31.
This output is stored in the memory as it is not right.

This is the contents of the memory (XOR)
z y x
31 31 5B 00

[skordal]

Hi,
Could you post the assembly code that is generated for this function? It would be helpful to see which instructions are being executed. In addition, which compiler are you using (version/compiler flags)?

[hossameldin1995]

Hi
I am using this version
riscv32-unknown-elf-gcc (GCC) 8.2.0 Copyright (C) 2018 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.

I used this instruction to generate asm file
riscv32-unknown-elf-gcc -S -o xor.s -march=rv32i -Wall -Os -fomit-frame-pointer -ffreestanding -fno-builtin -I../.. -I../../libsoc -std=gnu99 -Wall -Werror=implicit-function-declaration -ffunction-sections -fdata-sections main.c

and this is the asm code for "XOR"
.file "main.c"
.option nopic
.text
.section .text.exception_handler,"ax",@progbits
.align 2
.globl exception_handler
.type exception_handler, @function
exception_handler:
lw a5,8(zero)
ebreak
.size exception_handler, .-exception_handler
.section .text.startup.main,"ax",@progbits
.align 2
.globl main
.type main, @function
main:
addi sp,sp,-16
li a5,91
sb a5,13(sp)
li a5,49
sb a5,14(sp)
lbu a4,13(sp)
lbu a5,14(sp)
xor a5,a5,a4
sb a5,15(sp)
addi sp,sp,16
jr ra
.size main, .-main
.ident "GCC: (GNU) 8.2.0"

and this is for "AND"
.file "main.c"
.option nopic
.text
.section .text.exception_handler,"ax",@progbits
.align 2
.globl exception_handler
.type exception_handler, @function
exception_handler:
lw a5,8(zero)
ebreak
.size exception_handler, .-exception_handler
.section .text.startup.main,"ax",@progbits
.align 2
.globl main
.type main, @function
main:
addi sp,sp,-16
li a5,91
sb a5,13(sp)
li a5,49
sb a5,14(sp)
lbu a4,13(sp)
lbu a5,14(sp)
and a5,a5,a4
sb a5,15(sp)
addi sp,sp,16
jr ra
.size main, .-main
.ident "GCC: (GNU) 8.2.0"

[hossameldin1995]

I think the problem in the execution unit itself

[skordal]

Why do you think so?

[hossameldin1995]

Hi skordal,
I am sorry for late replying. But I made some debuging to the system and I get this conclusion.

I have three scenarios:
1 - cache is enabeled with uart data sending and recieving:
When I enable the cache, the instructions are executing every clock because the cache take a block of
instructions and send them to pp_core but between instructions it sends some characters to uart
to be sent and it takes some time because uart is slow.
2 - cache is enabeld without uart communication.
In this case the instructions are executing every clock because of taking a block of instructions to
cache and this is a fast way.
3 - cache is disabeled and no uart.
the instructions isn't executed every clock because the pp_core requests instructions from memory
and it takes time until it being available to pp_core, and this is a slow system.

All programs that I tried (and - or - xor - not -add - sub) are working perfectly on scenario 1 and 3. That is because the instructions aren't executed continuously. But when I tried using the second scenario the error I mentiond before is present due to continuously execution. The output is double executed! How?
if I need to make this instruction 5+3 = ??
The result should be 8 (this happened in scenario 1 and 3)
But the result is 11 >> 5+3+3 = 11 (what happened in scenario 2).

That is why I think the problem in execution unit as it double execute the instruction when it is pipelined