ISACOV : Pseudo-instructions

[Jalali]

Hello,
@AnouarZajni create functional coverage for all supported csr in the embedded config using uvm_reg and using the decode instruction coming from ISACOV, what we observe that the come-out result wasn't that good for us, because we have a large tests for CSR.
the problem was that the ISACOV doesn't support pseudo-code, and almost all the csr tests was writing using CSR pseudo-code (CSRR, CSRW, CSRC, CSRS)
here is a screen-shot of ISACOV log :

So could confirm the bug, so I can create a PP to fix it.

[silabs-robin]

the problem was that the ISACOV doesn't support pseudo-code

I'm not convinced there is any issue with that. (You can ask Mike if you'd like more details on the rationale there.)

---

here is a screen-shot of ISACOV log :

"unknown"? "ILLEGAL"?

It seems ISACOV lacks support for whatever those instructions are.
Have you decoded them (or have the objdump) and know what these instructions are?

[Jalali]

It seems ISACOV lacks support for whatever those instructions are.

these are csrr xx mcause (it's a csr instruction)

[silabs-robin]

It seems ISACOV lacks support for whatever those instructions are.

these are csrr xx mcause (it's a csr instruction)

That csrr pseudo instr is ran as an actual csrrs.

But what is the hex of it?
The isacov logger only prints the PC, but it would be convenient if it printed the hex.

But if its only csrrs I don't understand why isacov wouldn't accept it.
Maybe it is just the convert2string function that doesn't support it.

[Mike Thompson]

@silabs-robin is correct, the coverage model does not (and should not) support pseudo-instructions because the core never "sees" pseudo-code. For example csrr rd, csr in a test-program is typically mapped to csrrs rd, csr, x0 and this is what the core fetches and executes. Only the assembler (gcc, llvm, etc.) know anything about pseudo-instructions.

So those "unknown ILLEGAL" instructions cannot be csrr rd, csr because the core will never fetch such an instruction. Perhaps you are 'feeding' instructions to ISACOV from something other than the instruction fetch bus or the RVFI.

[Jalali]

I'm not convinced there is any issue with that. (You can ask Mike if you'd like more details on the rationale there.)

@silabs-robin is correct, the coverage model does not (and should not) support pseudo-instructions because the core never "sees" pseudo-code. For example csrr rd, csr in a test-program is typically mapped to csrrs rd, csr, x0 and this is what the core fetches and executes. Only the assembler (gcc, llvm, etc.) know anything about pseudo-instructions.

So those "unknown ILLEGAL" instructions cannot be csrr rd, csr because the core will never fetch such an instruction. Perhaps you are 'feeding' instructions to ISACOV from something other than the instruction fetch bus or the RVFI.

I didn't say the opposite the core should not know pseudo-code, but the agent doesn't see it, I think the dasm-spike decode csrr rd, csr as csrr rd, csr, 0x, so when the agent try to see if csrr exist in instr_name_t enum, he desn't find it and print UNKNOWN, should the dasm-spike see the pseudo-code ?

After I add CSR pseudo-code to instr_name_t ISACOV :

so the dasm-pike decode it as a pseudo-code

[silabs-robin]

I think the dasm-spike decode csrr rd, csr [...]

Here is what I don't understand:
"csrr rd, csr" is a string.
But AFAIK the decoder takes a raw binary bit-vector as its input.

So what does it mean that "the dasm-spike decode csrr rd, csr as csrr rd, csr, 0x"?

Whatever one's setup is, the pseudo instruction cannot be represented as a binary without first becomming a non-pseudo instruction, and that must have happened before being fed to dasm?