Replies: 1 comment
-
Mea culpa. Turned out to be a bug in my test bench. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I have been doing some testing (currently under simulation - but have tested and verified single packet transmittion) of an application where I might want to quickly send packets back to back. I wait for tx_udp_hdr_ready to go true as an indicator that it is ready for the header, and then I assert tx_udp_hdr_valid. I then see, as expected, tx_udp_payload_axis_tready become asserted, and I fill the FIFO with my packet data and assert tlast with the last byte of my data.
At this point, for the very first packet, an ARP request is sent out, and a reply is received (generated by my test bench for simulation)
HOWEVER tx_udp_hdr_ready goes true again almost immediately - before this ARP process can start and complete and the data packet transmitted, and while transmission of the data packet does wait for the ARP process to finish, the data that gets sent out for the second (and third, actually) packets is a duplicate of the first packet. The other two are lost.
Then, after a button press, I repeat sending the three packets, and again, and this time even without the ARP process, essentially the same thing happens: tx_udp_hdr_ready goes true just two clock cycles after tx_udp_payload_axis_tlast is asserted and then deasserted.
What am I missing? What should my process be waiting for besides tx_udp_hdr_ready to make sure a packet is sent before I put another packet into the FIFO?
JRJ
Beta Was this translation helpful? Give feedback.
All reactions