07-13-2017 02:27 PM
I have a design that connects a couple of different peripherals to a MIG via the smartconnect. One of my peripherals is able to talk to the memory, while another is causing DECERR to be returned to it via the RRESP signals when it tries to perform a read. The inexplicable part here is that after examining the signals, none of the three situations that PG247 lists as causes for DECERR is occurring. Furthermore by peeking on the MASTER bus that connects the smartconnect to the MIG, I can see the smartconnect issuing a request to the MIG and getting a non-error response. That suggests to me that the smartconnect is erroring out after it has received the response from the MIG. Why this is the case I have no idea. The following is a basic breakdown of the read request
8 beat burst, ARLEN = 7
Read addr is 0, the MIG itself is mapped starting at physical address 0
Bus width is 64bits
ARSIZE = b110 for 64bytes
No lock or protection or cache or region or qos.
This is with Vivado 2017.1, and I am completely stumped.
07-14-2017 10:08 AM
Okay, this is now getting interesting. I've done some additional testing and debugging and I'm seeing something that is going against expectations. So an explanation and their results.
1) I inserted the AXI protocol checker into the design and I am seeing the AR_SUPPORTS_NARROW_CACHE signal going high. That seemed a bit odd, since smartconnect documentation indicates it should support narrow transfers. This did raise my suspicions however as the request was not supposed to be a narrow transaction in the first place. The data bus between the smartconnect and the master peripheral is 64bits, and I am requesting beats of 64bits. So I then took a look at the ARSIZE port, which is b011, which indicates 8 bytes, which should be correct.
2) I had a test peripheral intended to try to minimally duplicate the burst transaction that is failing. There was some copypaste involved but it also uses a 64bit data bus connected to the smartconnect which then connects to the MIG. This one worked in reading memory. What became interesting however was I made a mistake in the pasting and did not correct the ARSIZE value, which was hardcoded to b110, which indicates a beat size of 64 bytes, not 8 bytes. This was correct in the source that I copied the code from, where the data bus was 512bits in width and directly connected to the MIG. It is however NOT correct, at least according to the AXI spec copy that I have, for a master with a 64bit data bus.
So this is obviously more than a bit unexpected. My assumption with the smartconnect's slave interfaces is the master that connects to it needs to send transactions formatted based on the size/config of the smartconnect's SI, not the config of the smartconnect MI that eventually forwards the transaction onto the destination the first peripheral is trying to reach. Is this not the case? Or is this actually some sort of bug within the smartconnect?
07-17-2017 07:46 AM
The AR_SUPPORTS_NARROW_CACHE appears to be a red herring. There is one very strange characteristic of the waveform I'm catching from the debug probes though. The AXI master logic (not written by me) has this blip wherein the RREADY signal goes high for one cycle. This is before RVALID goes high, so in theory it shouldn't do anything, but immediately after in the cycle when it goes low, the RRESP value changes to b11. I don't know if this is the problem, as my efforts to reproduce the problem have all failed to manifest this behavior.
07-19-2017 12:48 AM
Set ARCACHE=1 in your master. The NARROW_CACHE error is real and will cause data corruption issues. The combination of a datawidth upsize + ARCACHE will cause a narrow burst, which is illegal if SUPPORTS_NARROW_BURST is not advertised.