But we don't allow write to register x0... ... except maybe on load instructions (which aren't generated by compilers). I will double check and fix the write enable on loads.
The failure mode is fairly easy to understand. If you allow writes to x0 then it effectively becomes corrupted and any arithmetic operation that uses x0, will then fail. The following snippet highlights the issue. In my testbench I'm printing chars by writing to 0xFFFF_FFF4 and ending the sim by writing to 0xFFFF_FFFC. This is reusing your tb/debug/app1.c
test.
int main(void)
{
puts("Hello world\n");
asm volatile("li t0, -12"); // Write to t0 to end the test
asm volatile("li t1, 0x61"); // ASCII character 'a' written to
asm volatile("lui t2, 0x0");
asm volatile("addi t2,t2,-16");
asm volatile("sw t2, 0(t2)");
// asm volatile("lb zero,0(t2)");
asm volatile("nop");
asm volatile("nop");
asm volatile("sw t1, 0(t0)");
puts("\n");
finish();
return 0;
}
Uncommenting the line with the load byte to zero will cause the test to hang.
I'm not sure what you mean by "prevents the use of a registered SRAM"? You can fix it anyway you see fit as long as a read of x0 always returns 0.
Yes, you're right.
Yes, I'd like to see the individual testcase that shows the issue.
I am not sure the proposed MR is correct: it prevents the use of a registered SRAM.
Closes #5
Shareef Jalloq (ad636735) at 12 Feb 22:12
Hey,
I'm starting to integrate WR into our flow and we use FuseSoC as a dependency manager and tool runner. I haven't looked in detail at hdlmake
but I assume it offers some similarities.
I've created a branch on GitHub where I'm integrating the changes and you can have a look at the files and try the flow. For example, to run the Verilator lint flow I would:
git clone https://github.com/nuquantum/urv-core.git -b fusesoc urv-core-fusesoc
cd urv-core-fusesoc
. sourceme
module load verilator/v5.014
fusesoc run --target lint ohwr:urv:cpu_core
The main addition are the *.core
files that define the files to use and the various tool flows.
I'll create an MR when I get a chance. The pre-commit hooks don't rely on CI to run - they run locally when you 'git commit'. It helps to catch issues before they hit CI.
Why do you need to write it?
In terms of a testcase, the "riscof" branch has documentation on how to run the suite. Or did you want an individual testcase to show the behaviour?
Shareef Jalloq (de5044f0) at 12 Feb 16:47
feat[riscof]: adding riscof arch tests
Shareef Jalloq (8aa5523b) at 12 Feb 15:15
feat[riscof]: adding riscof arch tests
Please provide a MR. There is a very limited support of CI with ohwr, but we plan to migrate this year. So probably we could support a pre commit hook in the future.
Tristan Gingold (44511c82) at 12 Feb 12:19
Tristan Gingold (ad636735) at 12 Feb 12:19
Merge branch '3-would-you-be-happy-to-integrate-fusesoc-core-files-...
... and 1 more commit
Closes #3
Hey, just about to start reporting some issues here and noticed that the option to Fork the repo is greyed out. Is this intentional? If so, what's your flow for incorporating pull requests?
Shareef.
You are now developer so you can create branches.
Please, provide a MR.
Can you share a testcase where you can modify x0 ?
(We need at least to write x0 during reset).
Shareef Jalloq (0fed8220) at 12 Feb 09:43
feat[riscof]: adding riscof arch tests