I am using DDS compiler IP with AXI-Stream Interface. As we know that "s_axis_data_tvalid" is the input to the IP and "m_axis_data_tvalid" is the output valid generated by the IP with respect to the latency configured through GUI.
So the moment "s_axis_data_tvalid" is asserted high, "m_axis_data_tvalid" will be asserted after the said latency and similarly the de-assertion also takes place likewise (i.e "s_axis_data_tvalid" is asserted low then "m_axis_data_tvalid" also de-asserted after the said latency). Basically the time "s_axis_data_tvalid" is high should be equal to the time "m_axis_data_tvalid" is high.
But for the particular DDS compiler IP, the behavior is different, whenever "s_axis_data_tvalid" is de-asserted "m_axis_data_tvalid" is also being de-asserted the same instant. So losing the data of latency cycles. And according to Xilinx documentation the behavior is expected and recommended to use tready with full AXI-stream.
When used packet framing with tlast signal and tready signal also, similar behavior is observed like tlast signal is observed in the next instant "s_axis_data_tvalid" is going high not in the current instant.
What should one do to get the "m_axis_data_tvalid" as expected like in other IPs
snapshot1.png shows the expected behaviour of tlast and valid signal for complex_mult IP. And snapshot2.png for DDS compiler IP where m_axis_data_tlast is coming after next instant of s_axis_data_tvalid goes high.