axisafety.v in ZYNQ Ultrascale+ works for read operations, but not for write operations

[madorskya]

Hello, I've been using axisafety.v in a ZYNQ-7000 firmware design very successfully. It reliably detects a missing AXI slave during read and write operations. However, in ZYNQ Ultrascale+, the behavior is different. The missing AXI slave is detected only for read operations. The bus is still blocked solid for any write operation to the missing slave. I have updated the code to the latest version available in this repository, but still seeing the same behavior. Would it be possible to fix that? thanks.

[ZipCPU]

Would it be possible to fix that?

Absolutely!

Can you tell me any more about what's going on? Do you have a trace you can share that shows this behavior getting triggered? Any information you can provide will help me chase this down.

Dan

[madorskya]

Hi Dan, unfortunately, the board that I'm working on does not have a direct JTAG cable connection. I'm using Xilinx Virtual Cable (XVC) to run ILAs on it. But as soon as the bus is blocked, the entire system is locked up, so XVC is not working as well. That makes it impossible to catch the problem red-handed. I'll see what I can do to provide more diagnostics. thanks. Alex.

[ZipCPU]

Do you have a spare serial port? PMod? Can you make one? If so, you could use that for debugging ...

Also, please consider using one (or both) of the fault detectors to drive some LEDs. It would be worth knowing if the bus detects a fault at all, and might help us diagnose what's going on.

Do you have OPT_SELF_RESET set or clear? And ... what value do you have for OPT_TIMEOUT?

Looking over the logic for AWREADY, can you try removing the clear_fault condition on lines 395-396? It's been a while since I looked at the IP, and that ... just doesn't look right. Similarly, lines 976-977 appear to have the same bug.

Dan

[madorskya]

Hi Dan, I managed to catch the issue in ILA. The axisafety module settings are:

The screenshot:

This is a single write operation to a non-existent AXI slave. I can see that after timeout the module detects write fault, and seems to be sending a response on the AXI bus. However, the ZYNQ system is somehow not happy with that response, and is completely blocked... Could you take a look and let me know if you see anything wrong? thanks a lot. Alex.

[madorskya]

Also, forgot to mention: I modified the code as you suggested earlier, by removing sections in lines 395-396] and 976-977. Unfortunately, that made no difference... Alex.

[madorskya]

this is the AXI master bus coming out of axisafety module, during the same failed transaction:

[ZipCPU]

Thank you.

Let me take a further look.

[ZipCPU]

Wait, if the return is correct but still causing you problems, then perhaps you are struggling to handle the BUS error return. Try this: set BRESP to 2'b00 in all cases. See if that fixes your issue. If it does, then you know the bus error was the problem.

Dan

[madorskya]

Hi Dan, I replaced this line: m_bresp = `SLAVE_ERROR; with this: m_bresp = 0; // replaced by 0 on advice from Dan

After that, the write operation does not block the bus anymore! It also does not report Bus error though. The read operation still reports Bus error as before.

Even though this is already MUCH better than before, I wonder if you have any insight of what's going on? I really don't have any control over how ZYNQ processes bus errors internally... thanks a lot. Alex.

[ZipCPU]

Ok, I'm going to close this issue then. The IP operates as designed. It seems you are having problems with how the Zynq handles bus errors.

In general, a bus error (should) produce an interrupt. You might wish to look at where and how this interrupt is getting handled inside the Zynq.

Dan

[madorskya]

OK, thanks a lot for your help! Alex.