My first compliance test passed!

[Eric Smith]

After fixing a number of bugs in my core, the Python microarchitecture simulator passed the I-ADD-01 test. Of course, that means that a bunch of other instructions must be basically working. I spent a bunch of time today trying to figure out why I was getting wonky add instruction results, when it turned out that the add instruction was fine and that other instructions like bltu and srai were broken and were screwing up the output.

I haven't yet tested the Verilog; I've written the Verilog code and compiled it with both Icarus and Verilator, but I haven't yet got usable Verilator testbench code. I'll probably run the other 54 compliance tests on the Python simulator before I run them on the Verilog simulator.

I'm still not at all confident that I'll have this wrapped up by the deadline, but I'll keep trying.

Eric

[Antti Lukats]

On Sunday, 18 November 2018 07:31:06 UTC+1, Eric Smith wrote:

After fixing a number of bugs in my core, the Python microarchitecture simulator passed the I-ADD-01 test. Of course, that means that a bunch of other instructions must be basically working. I spent a bunch of time today trying to figure out why I was getting wonky add instruction results, when it turned out that the add instruction was fine and that other instructions like bltu and srai were broken and were screwing up the output.

ADDI-01 does not use BLTU or SRAI

if you compile ADD-01 with IO assertions disable and no added funky code, the compliance test itself does not use any conditional branches or SRAI

but some tests use "surprise" instructions ;) 

RF_width as example uses SLLI .. etc

I haven't yet tested the Verilog; I've written the Verilog code and compiled it with both Icarus and Verilator, but I haven't yet got usable Verilator testbench code. I'll probably run the other 54 compliance tests on the Python simulator before I run them on the Verilog simulator.

You should try to setup somewhat usable verilator testbench ASAP, it helps also helps to avoid running out time, well I said that to myself too, but am still not yet done with the verilator, still on to-do

 

I'm still not at all confident that I'll have this wrapped up by the deadline, but I'll keep trying.

Eric

Time is running, faster and faster.. verilator can be managed with little overhead but some other secondary task may consume more time

Antti

[Eric Smith]

On Sun, Nov 18, 2018 at 1:49 AM Antti Lukats <antti....@gmail.com> wrote:

ADDI-01 does not use BLTU or SRAI

No, but the code to output the results to the UART in hexadecimal (code by Charles Papon) does.

You should try to setup somewhat usable verilator testbench ASAP, it helps also helps to avoid running out time, well I said that to myself too, but am still not yet done with the verilator, still on to-do

I definitely should, but it's so much easier to test with my Python microarchitecture simulator.

My core is now passing all except MISALIGN_LDST, SLT, SLTI, SLTIU, SLTU.

I think the RV32I compliance test for misaligned load/store is flawed. It assumes a misaligned access will cause a trap, which is allowed but not required by the RISC-V ISA spec v2.2. My core implements misaligned accesses without trapping, which is also allowed. If the test was written properly, the trap handler would perform the misaligned access the way the architecture intends, and then the test would pass whether it traps or not. However, the test is actually written to assume the trap, and the trap handler records mtvec(mbadaddr) and mcause into the result signature but does not emulate the misaligned access.

Eric

[Antti Lukats]

The tests are not perfect, and some of them could be argued to be wrong/meaningless, but for the context of this contest those tests are the confirmance test case selected, so you need to pass test as primary goal

g

Antti

 

[Eric Smith]

On Sun, Nov 18, 2018 at 4:12 AM Antti Lukats <antti....@gmail.com> wrote:

On Sunday, 18 November 2018 11:54:39 UTC+1, Eric Smith wrote:

I think the RV32I compliance test for misaligned load/store is flawed. It assumes a misaligned access will cause a trap, which is allowed but not required by the RISC-V ISA spec v2.2. My core implements misaligned accesses without trapping, which is also allowed. If the test was written properly, the trap handler would perform the misaligned access the way the architecture intends, and then the test would pass whether it traps or not. However, the test is actually written to assume the trap, and the trap handler records mtvec(mbadaddr) and mcause into the result signature but does not emulate the misaligned access.

The tests are not perfect, and some of them could be argued to be wrong/meaningless, but for the context of this contest those tests are the confirmance test case selected, so you need to pass test as primary goal

 I fixed my SLT[I][U] problem. I don't have any complaints about any of the other RV32I tests, but as a test of architectural compliance, I-MISALIGN_LDST-01 isn't arguably wrong/meaningless; it's ACTUALLY wrong.

I had to add totally unnecessary logic to my core to force a misaligned data trap in order to pass the test, when the code is architecturally compliant without the trap. Whoever wrote that test was testing to a specific implementation, not testing to the architecture spec.

Anyhow, now that all 55 tests pass against my Python microarchitecture simulator, it's time to go to bed (about five hours overdue), but tomorrow I'll try to test the Verilog code.

Eric