10-16-2019 06:14 AM
I'm developping a S2MM interface using the datamover. This IP is quite driving me nuts.
I have a version running in both simulation and physical tests (ZCU102) using a 64-bits data & address interface.
Now I need another version (same function) with a 128 bits data interface.
I think I respect the way the IP is programmed since it works in 64 -bits.
In simulation, the cmd is passed ok. I have no activity on the STS interface and on the AXI MM interface as well...
What I see is my AXIS inteface providing few 128-bits data beats and then the ready goes to 0 --> stuck.
Is there anybody willing to share its experience with this IP?
11-08-2019 11:49 AM
11-06-2019 01:59 AM
I have no experience with this IP (I usually use the AXI VDMA or DMA which include it).
But if you can share your simulation project, I can have a look.
11-08-2019 11:49 AM
11-14-2019 10:58 AM
I dont see how this discussion helps anyone else? Nothing was shared about the solution. This thread should be deleted, it wasted my time.
11-15-2019 04:02 AM
A nicer way to write your message could be:
"Hello @sebo ,
I was wondering what was your issue and how you solved it because I am also facing an issue with the datamover that I cannot solve
Thank you in advance"
This would be more community friendly ;)
And replying to a topic saying it is was not helpful, is also not helful for the community.
11-15-2019 06:17 AM
@sewal1post put aside, I indeed could give a little more information.
This datamover IP is not quite easy (IMHO) as you have several points to pay attention to when using it. It's all in the datasheet :
-- /!\ AXI DataMover does not support null bytes. (TKEEP completely deasserted). A start of a streaming -- packet is identified by TVALID while its end is determined by TLAST. AXI DataMover does not support -- sparse/null TKEEP between the packet boundaries. TKEEP can be sparse only at TLAST beat. TKEEP can -- also be sparse at the start of a packet when DRE (unaligned transfers) is enabled. -- /!\ In the absence of any S2MM command, AXI DataMover will pull the s_axis_s2mm_tready signal to Low -- after taking in four beats of streaming data. This will throttle the input data stream. To have a -- minimum amount of throttling, ensure that a valid command is issued to the S2MM interface much before -- the actual data arrives. -- /!\ One important aspect of the DataMover operation is the ability to spawn multiple child -- AXI requests when executing a single command from the corresponding Command FIFO. -- Request spawning occurs when the requested Bytes to Transfer (BTT) specified by the -- command exceeds a parameterized burst data beat limit (default is 16 but can also be set -- to 32, 64, 128, or 256). (PG022 page 27)
But, when it get stuck, there is no way to easily debug it. For instance, in case of underflow or overflow, the IP won't explicitly tell what is the real cause of the failure.
Moreover, I'm still investigating an issue in physical tests. The IP seems to have trouble to start from time to time. Using a system ILA, I see that MM interface is stuck (Address or data READY signal to low) but I don't know how it is possible. I've seen in a post that ILA could have an influence.
That's why, I first posted a request for anybody willing to share its experience with this IP.
11-15-2019 10:00 AM
My apologies if I came through as insensitive. Should be more polite. Thanks for the correction.