cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
pphani
Newbie
Newbie
488 Views
Registered: ‎05-14-2021

Data getting corrupted while transferring from PL to PS on ZCU102

Hi,

I am trying to process a 32-bit data in DUT from PL to PS DDR but data it getting corrupted at few places when data is read back from PS DDR on ZCU102. 

Input from HDMI to PS (32-bit) -> PL DUT (32-bit) -> To PS DDR (128 bit) -> From PS DDR ( 128 bit) -> To PL DUT (32-bit) -> To PL DMA (64-bit) -> To PS DDR (128-bit).

The DUT is a simple image processing pipeline working on a 32-bit RGB data. The DUT sends data to PS DDR to store the data. And then reads it back for further processing , before sending it back to PS DDR which is then accessed back to host machine.

I am able to get correct data when it is sent to PS DDR.

But while reading data back to PL DUT from PS DDR, the data is getting corrupted in few places.

I went through the forums and there was mention about PL-PS DDR showing corrupted data when the data width is not 128-bit but nothing seem to work in my case.

I am using AXI interconnect before interfacing with PS DDR and am using  AXI HP0 FPD , AXI HP1 FPD , AXI HP3 FPD ( all configured to 128-bit) on MPSoC.

Can anyone let me know if i am missing anything ?

 

Thanks

Tags (3)
0 Kudos
6 Replies
drjohnsmith
Teacher
Teacher
447 Views
Registered: ‎07-09-2009

You need to locate where your problem is by looking at each element in turn,

Do other DDR read . write work, have you run a memory test from the CPU ?

Does the simulation work ?

Is the design constrained ? Does the synthesis / P&R pass with no timing errors ?

looking at the AXI interface with the ILA, are there any "lock"  "error" conditions on the AXI bus ?

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
pphani
Newbie
Newbie
427 Views
Registered: ‎05-14-2021

Hi, So the thing is same design with PL DDR works. In case of PL DDR, DUT gets interfaced with PL DDR using MIG and that works fine.

It's only when we interface DUT with PS DDR that the data is corrupted at few places.

0 Kudos
drjohnsmith
Teacher
Teacher
420 Views
Registered: ‎07-09-2009

Do other DDR read . write work, have you run a memory test from the CPU ?

Does the simulation work ?

Is the design constrained ? Does the synthesis / P&R pass with no timing errors ?

looking at the AXI interface with the ILA, are there any "lock"  "error" conditions on the AXI bus ?

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
dgisselq
Scholar
Scholar
419 Views
Registered: ‎05-21-2015

@pphani ,

This is a common AXI compliance error.  AXI slaves can differ in their implementation from one slave to another.  Small differences, such as subtle timing differences, or when during a handshake data get sampled from the bus, can make for a big hassle later on if your design isn't truly protocol compliant.  In this case, your design complies with one AXI interface implementation (MIG), but not another (PS), so then your design is probably not following the AXI protocol properly.

If you post the design, we can examine it for bugs for you.  You might also wish to try connecting a protocol checker to your design, if you don't want to post it.

Dan

pphani
Newbie
Newbie
337 Views
Registered: ‎05-14-2021

Thanks for the replies and suggestions.

@drjohnsmith 

1: Yes , design meets timings. 

2: Havent checked simulations and using ILA for debugging 

3: till now haven't seen errors in while debugging AXI transactions in ILA.  However I am not capturing entire set of data transactions. The output data is 'almost correct', except for few locations. So need to see how exactly can I get those memory locations.  Maybe check for change in axi resp signals in ILA. Will try.

@dgisselq 

1  : Haven't went till protocol checking as I thought the design working with PL DDR should work with PS DDR. Will try out suggestion with protocol checker.

2 : So the data is coming fine most of time except for few places. If the design isn't protocol complaint,  then I would assume to be getting incorrect data almost all the time, but not at random memory locations. Isn't this assumption correct?

 

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

@pphani ,

> Isn't this assumption correct?

No.

Just as a bit of background, I set out about two years ago to learn how to formally verify AXI interfaces.  I wrote a set of formal properties, and then went in search of any AXI design I could find to test my properties on and, in hindsight, to build my chops.  That goal has led me to these forums, looking for examples to test and check.  If anything with the word "AXI" in it crosses the forums, I get excited to take a peek.  All that's to say, I've seen some really weird behavior from broken designs.

One recent bug I chased down had to do with a design that didn't drop AWVALID when AWREADY was true, but a couple cycles later.  This had the effect of requesting a second write transaction, but not one the designer was aware of.  By the time the designer realized he had a problem--several transactions later, he was noticing that the wrong values were getting written by his design.

The most common problem I've seen so far, however, has been design lockup.  This usually follows from someone building off of Xilinx's (broken) demonstration designs.  Sure, all the tutorials tell you to "Create and Package New IP", but most often the IP you create that way will end up being broken.  Xilinx's has yet to fix those bugs.  Yes, Xilinx IP has other bugs too--but most of the bugs I see on these forums are in user designs.

I've also seen a lot of individuals who didn't necessarily understand the AXI specification and built a design to match an interface--say the MIG interface for example, or maybe Xilinx's AXI block RAM controller or their template design.  These individuals often then get tripped up later when attempting to access another AXI slave that doesn't respond the same.  In this case, the common problem is setting AWVALID and waiting on AWREADY before setting WVALID.  With some slaves this works, but it is definitely non-compliant with the spec.

Another frustration I run into commonly is a user with a problem who doesn't wish to share their design.  Frankly, there's just not that much I can do to help in those cases.  Sometimes users share only portions of their design, for perhaps only what they consider to be the "relevant" portions--not realizing that the bug is actually in a place they're not looking.

All that's to say I've seen some pretty strange bus behavior.  It's most often caused by user designs.  Most user complaints about things not working will lead you away from the actual problem, and leave you looking in the wrong place.  Only the RTL itself, plus a good formal tool, will guarantee finding the bugs you are struggling with, although a good desk check from a second pair of eyes will work every now and then as well.

Dan