ebreak compliance test make no sense on machine mode softcore ?

[Dolu1990]

Currently, the softcore has to pass the ebreak complience test, but I don't see any sense in this for a softcore which only implement the machine mode / without linux.

Also, it has the side effect of not don't allowing some debugging architecture where the ebreak instruction is natively handled by a debug module into the CPU. (ex : VexRiscv debug module)

[AnttiLukats]

I would agree, but then we could start a long discussion about the "minimal" requirements. I would say implementing "mscratch" CSR is also not needed to pass the RV32I ISA tests, but well the tests use it.

Your point about native handling of ebreak makes sense of course. But we can not go from the prospective that only things that "make" sense are needed and will be tested. If you have a design that passes EVERYTHING else and fails on ebreak because of "native" handling, I guess the judges would accept that as exception, if properly documented by you.

[AnttiLukats]

Based on the new official FAQ it seems that you actually have to pass EBREAK testing.

[Dolu1990]

Unfortunatly ^^

[mithro]

Are you talking about https://github.com/riscv/riscv-compliance/blob/master/riscv-test-suite/rv32i/src/I-EBREAK-01.S ?

[Dolu1990]

Yes ^^

[mithro]

Isn't that just like any other trap instruction?

[mithro]

@AnttiLukats - I agree that the RV32I ISA tests requiring the CSR registers isn't weird. Maybe someone should send them patch to make them unneeded?

[Dolu1990]

Yes it is exactly ilike a ecall, except the mcode is different.
The thing is that there is multiple ways to handle debug support which all make sense in different context (from my knowledge):

• OS way for user land: ebreak trap, then the supervisor manage it via software
• CSR way for low level debug: where ebreak make the CPU enter into a mode which is even depper than the machine mode, and it do software in this mode into a special rom.
• The native way : When a ebreak run, the CPU stop and is directly controled by jtag. I implemnted this version in VexRiscv, as it use less logic, is adapted for machine mode only application, and is standalone (no rom, no target software required, no CSR support required, the cpu can be interrupt less)

[mithro]

While I doubt it would be /actually/ accepted to use something else - it's really only implied that you need to use the standard RISCV binutils assembler...

There doesn't look to be any rules against post processing the binary while loading or embedding in your Verilog from what I can see?

The FAQ mentions that doing soft implementations of less used instructions by trapping is allowed too...

[AnttiLukats]

haha, post processing.. no I would say it is prohibited. The FAQ is very close to nonsense, it is possible to comply to the rules as original rules but it is not possible to comply to the FAQ any more.

[mithro]

Please explain?

[AnttiLukats]

explain what? that post processing is not OK, or that FAQ makes rules nonsense? if TRAP is OK, then the tests would NOT PASS. So either the rules in original form apply or the FAQ changes them. The test cases write mtvec - so they will use their own trap handler that DOES NOT emulate anything. hence without modififying the test case sources, the test cases can no longer pass (if trap emulation is ok by the faq)

[mithro]

Have your CPU trap to my_internal_mtvec, if the instruction is actually illegal jump to mtve, if instruction has emulation then perform it and return from trap.

The code doing the emulation at my_internal_mtvec can even be embedded into your CPU design, thus not requiring any changes to the input assembly.

This can be 100% transparent to the running code - it just looks like your CPU is just really slow at trapping?

Why wouldn't something like that work?

[AnttiLukats]

you can CHEAT many ways

1 you could leave CSRxxx instructions as illegal and trap to hard coded trap, then you can grab the writes to mtvec CSR
2 you could trap to hard coded trap, no matter what is written to mtvec

both would be cheating and violation - the test cases DO WRITE to mtvec ! and they should run also if compiled to memory space that does not include your hard coded trap handler address - if the CPU is compliant it would work, the test case sets mtvec and traps and tests everything

[mithro]

The contest rules explicitly state;

additional points awarded for novel approaches to the implementation itself.

The FAQ also says;

The aim is to enable new innovative designs.

I would say they are explicitly looking for how far you can push things while not exposing the implementation details. It doesn't matter what goes on "behind the curtain" as long as all there are no visible changes in the output.