[PIO CSR] Access PIO reg 0x84 will cause bus to hang up

[nelson-ou]

Hello!
I'm are seeing read to PIO queues 0x80/0x84/0x88/0x8C when PIO_CONTROL.ENABLE is not enabled is causing the system bus to hang up.
This is causing some headache on FPGA when debugger reads a block of memory address.
I'm aware the limitation described in 0xB0
But...isn't it better to have the CSR read to return some garbage value? instead of freezing up the bus?
Thanx!

[nelson-ou]

Will this issue be checked/look-at ?
Thanx!

[bharatpillilli]

@kgugala are you checking on this?

[nelson-ou]

Checking back on this issue. Will there be any update?

[kgugala]

Hi @nelson-ou - those CSRs are not used within the Caliptra context, and there doesn't seem to be a relation between the PIO_CONTROL.ENABLE and read logic from the FIFOs you mention.

The stall you see is most probably caused by the fact you try to read from empty FIFOs, so the logic handling the read is waiting for any data to appear to be able to finish the transaction. On the TTI side (used in Caliptra), similar logic was modified to return 0 on empty FIFO. The user is supposed to first read a CSR holding the amount of data available in the FIFO and only if this is not zero read the FIFO itself. Such a change could potentially be applied to PIO, but we would need to check for any side effects.

Please let us know if this is consistent with your observations, and whether you have any thoughts on whether this change would help in your case (and we will factor this into our analysis/discussions with the consortium).

[jchanga]

I think it's still good to apply the TTI side behavior to PIO and avoid hanging the bus fabric. Although is not used in Caliptra application today, it does cause issue with IDE debugging environment. The debugger reads and displays all locations falling in the "memory" window automatically. Such non-functional accesses have caused the environment to freeze up. In general, hanging the bus fabric is undesired. It is not a showstopper, but it can be a nuisance to firmware development. I recommend the WG to fix the issue.
Thanks.

[bharatpillilli]

We understand your desire; we have had too many late bugs with I3C and therefore don't want enhancements to logic that might cause more bugs and it's easier to make sure FW does the right thing than having silicon issues.

[jchanga]

We understand your desire; we have had too many late bugs with I3C and therefore don't want enhancements to logic that might cause more bugs and it's easier to make sure FW does the right thing than having silicon issues.

The enhancement is recommended only. It is understood and it is fine with the WG's decision either way. This particular case can be closed.

[bharatpillilli]

Let me mark it as future so that it's not off the radar