V4FX PPC ICU data transfer timeout?

Hi.

Debugging a board with V4FX12 I noticed a strange behaviour of the PPC ICU. It seems that the ICU has an undocumented data transfer timeout.

According to the docs, the PLB arbiter implements a timeout for the address transfer. My slave acknowledges a read address immediately, but then sits for a long time (up to 80 cycles) before it actually starts delivering data.

On my board, I observe PPC crashes. Almost immediately before a crash, the PPC ICU seems to give up on such a lengthy data transfer stage. After about 70 cycles or so, it suddenly issues a new read request, for the address that follows the pending read. As if it had given up and dropped the previous one.

Shortly after, the program crashes. I couldn't confirm, but I suppose that "to give up" also means "mark the instruction cacheline as valid, although it isn't".

There's another symtom as well. Since my slave and the arbiter do not have the timeout implemented, the data is eventually delivered. On the 3rd of 4 cycles (where my slave asserts RdComp), the ICU suddenly sends PLB_ABORT. This is while it has the new read request already pending (as secondary read).

After the secondary request is removed, I see that ICU issues 9 times a read request (for an unrelated address or recently executed code) that is immediately followed by PLB_ABORT. The abort is so quick that the request never makes it into the PAValid=1 stage. Nonetheless this pattern is repeated 9 times.

It seems to me that the PPC ICU has some kind of timeout, which is triggered by the lengthy data transfer time of my slave. It also seems to have some "purge" or "recover from errors" mode where it exhibits that strange ABORT behaviour.

Can anyone confirm this? Did I miss it in a datasheet?

I "fixed" my slave by reducing the aack to rddack time. Now I reject incoming requests with REARBITRATE until they can be served more timely. However, I'm unsure about how many cycles my slave is allowed to consume. While the crashes did go away, I would like to know for sure that they won't come back when my program code/data map happens to have a "worst case" layout (with respect to the PLB access patterns generated by executing it).

Kind regards & have a nice weekend, Marc

Reply to
jetmarc
Loading thread data ...

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.