cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
joancab
Teacher
Teacher
505 Views
Registered: ‎05-11-2015

Master AXI doesn't write correctly into PS RAM

Jump to solution

I have an HLS IP block that writes the PS RAM. I found it only writes the first 4 bytes of each 16-byte group. It appears as if address bits <2:3> were always 0. 

That was with a TE0803 board. Then I tried on a MYD-CZU3EG and it works like a charm.They both have Zynq ultrascale+

So my conclusion is there is nothing wrong with the HLS or Master AXI, but somehow, somewhere with the DDR.

Looking at these boards, they both have DDR4-2400, different chip brands and also different timing settings in the PS configuration.

I wonder if the timing settings could be wrong. Besides that funny effect, the board works fine (software runs, etc).

Any ideas on what could I try or look at?

Tags (3)
0 Kudos
1 Solution

Accepted Solutions
joancab
Teacher
Teacher
334 Views
Registered: ‎05-11-2015

Thanks everyone for your pointers, @dgisselq and @dpaul24 

At the end, I solved it just by setting the PS slave AXI port width to 128 bits. My block data width is 8 or 32 bits so there is a smart connect in between.

The reason behind is unknown to me, but I'm an engineer not a scientist. And I still don't have any clue of why it works with one board and not another.

View solution in original post

0 Kudos
9 Replies
dpaul24
Scholar
Scholar
499 Views
Registered: ‎08-07-2014

@joancab ,

I would review the AXI4 WRITE group signals in simulation. What is issued out of the HLS block and what is fed in to the DDR4 Controller core.

Do you have an interconnect in between, is it doing something strange?

------------FPGA enthusiast------------
Consider giving "Kudos" if you like my answer. Please mark my post "Accept as solution" if my answer has solved your problem
Asking for solutions to problems via PM will be ignored.

joancab
Teacher
Teacher
497 Views
Registered: ‎05-11-2015

Initially I didn't have an interconnect. I checked the transfers captured with ILA and they look correct, I could see data and all addresses but then when software reads that area, some addresses returned 0. Later on I tried adding an interconnect but didn't change the result (I didn't capture with ILA)

0 Kudos
dpaul24
Scholar
Scholar
464 Views
Registered: ‎08-07-2014

Is the WSTRB signal value same in both cases (if it is being used)?

------------FPGA enthusiast------------
Consider giving "Kudos" if you like my answer. Please mark my post "Accept as solution" if my answer has solved your problem
Asking for solutions to problems via PM will be ignored.

joancab
Teacher
Teacher
459 Views
Registered: ‎05-11-2015

Here I write 64 bytes (16x 32-bits) in consecutive positions, WSTRB is 0xF all the time. This is the 'bad' board.

joancab_0-1619081681274.png

I'm just thinking... another difference with the board that works is that the design has no ILA

 

0 Kudos
dgisselq
Scholar
Scholar
414 Views
Registered: ‎05-21-2015

@joancab ,

Not to be a broken record, but several possibilities have come up as of late on the forums that you might wish to check for:

  1. You might wish to rebuild your (broken) design.  In one user's case, Vitis and Vivado were out of sync with each other and the two didn't agree on the number of bits in the data bus
  2. As always, check the cache.  Many times things get written to PS DDR3/4 SDRAM where the PS doesn't know about it.  If you don't clear the cache, you might not realize what's going on.
  3. Another (pseodu) obvious one: Double check that you have the right SDRAM chip configured.
  4. You can also check this list of items that I've compiled of common AXI problems posted on these forums.  Perhaps yours will show up there.

Beyond that, I've debugged a lot of AXI designs on this forum.  It's really easy to be looking for the bug in the wrong place.  Just because something works on one board and doesn't work on another doesn't necessarily mean the board is at fault.  In many cases, one of the AXI components was at fault and the board just treated the bus differently.  (More or less stall cycles, "peeking" at requests that were then errantly dropped, etc.)  The only way to be sure an AXI master works is to formally verify it.

Dan

joancab
Teacher
Teacher
407 Views
Registered: ‎05-11-2015

@dgisselq 

Appreciate the points to check.

1. I'm rebuilding the design several times a day trying new things. Because lovely Vitis sometimes refuses to update the platform hw specification, a fraction of the times I'm rebuilding it from th xsa.

2. Not sure if the cache applies to PL -> PS writes. I read and present data with software, but anyways what the results show doesn't match a cache problem, in short I write values 0 to F to addresses 0 to F and what I read is values C to F in addresses 0 to 3, all others unchanged, as if it was always writing and overwriting at 0 to 3. It looks to me like another problem.

3. I believe so. I'm using a commercial board, TE0803 and the PS is configured with the board settings from the provided board files. The answer I got from Trenz is that if the DDR had the wrong timing settings it would simply not work, no FSBL, no sw, nothing, what makes sense to me.

4. Is a good collection of unexplained phenomena... One thing that really puzzles me is that I look at ILA signals and everything seems ok, addresses, ready, valid, strobes, etc. but some addresses seem to turn into others. I will have a look at the partial addess decoding, although then the question is, why does it work in another similar board?

0 Kudos
joancab
Teacher
Teacher
405 Views
Registered: ‎05-11-2015

I just added a Xil_DCacheDisable();  at the beginning and no change.

0 Kudos
dgisselq
Scholar
Scholar
397 Views
Registered: ‎05-21-2015

@joancab ,
The last several AXI problems I've helped to troubleshoot on this forum have all involved ILA traces that lead in the wrong direction.  ILA is just a ... real challenge to work with.  It's like looking for a haystack through the eye of a needle.  Even when the trace showed a bug, the trace often led you away from where the bug was at.

  1. In one case, the user dropped AWVALID a couple clock cycles after AWVALID && AWREADY.
  2. In another case, the user didn't check for WVALID when examining WLAST
  3. I seem to recall a case where the user counted xVALID's without also checking for xREADY's as well.
  4. In another recent (master) example, the design checked for RLAST without also checking for RVALID.  (You wouldn't drop RREADY in your master, now would you?)
  5. In another example, the user was issuing write transactions but left the read pins unconnected.  Unconnected read pins then impacted what was taking place in the write ILA--but not something you might notice from the ILA alone
  6. Examining Xilinx logic over the weekend, I found another example where the logic couldn't properly handle AWVALID && ARVALID.  In this case, the ARVALID packet would be accepted, but it would be processed with the AW* parameters: address, length, etc.  I'm pretty certain they've never noticed these problems, yet probably believe these designs will work when placed in an environment where AWVALID && ARVALID might both be true at the same time.  (I think I've now found 3 Xilinx designs with this bug so far ...)
  7. Just yesterday I examined the NEORV32 core, where the user tried to implement a timeout within the AXI protocol and just dropped a request.  ARVALID && !ARREADY on one cycle, but !ARVALID on the next.

In most if not all of these cases, the ILA would lead you to looking at the bug in the wrong place and hence to blaming the wrong piece of logic.

The one I remember, however, that comes closest to this was one where the design was configured for a 128bit datapath but yet the PS was implementing a 32-bit datapath.  The configuration between the two didn't match.  (At least, that's what I remember--I should re-read the post again.)

Dan

joancab
Teacher
Teacher
335 Views
Registered: ‎05-11-2015

Thanks everyone for your pointers, @dgisselq and @dpaul24 

At the end, I solved it just by setting the PS slave AXI port width to 128 bits. My block data width is 8 or 32 bits so there is a smart connect in between.

The reason behind is unknown to me, but I'm an engineer not a scientist. And I still don't have any clue of why it works with one board and not another.

View solution in original post

0 Kudos