You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The example logic in udp_fpga_core is a loopback - it gets a packet, and then sends it out. I am just trying to send a packet, because eventually I will need to do that. But because the loopback example (I think) has received an entire packet before it generates a response, it doesn't address the timing for these signals.
I can sometimes come up with a combination that at least starts the process (causes the logic to generate an ARP packet which I then successfully reply to in simulation), but then after that the UDP packet it sends out doesn't have any of my data, has a bad checksum (XX), etc. Also, when it does transmit a UDP packet (as I fiddle with hdr_valid and tlast), most fields in the header are fine, except it thinks it is sending a fragment, and the UDP length is 0x09 and I am expecting 0x48, and the IP length field is 0x1D. The MAC and IP addresses, protocol, source/dest ports, etc., are all fine.
So, I can at least receive and send Ethernet frames to and from my test bench.
(Note that because I had problems implementing cocotb, my test bench and top level modules are VHDL, but that really doesn't matter to my query. Also, I have an MII to RMII adapter, which seems to be working just fine - the ARP query and reply are working fine.)
The signals in question are:
wire tx_udp_hdr_valid;
wire tx_udp_hdr_ready;
and the signals that feed udp_payload_fifo (in the example, they are all rx... because it is just doing a udp loopback)
The ones that I am really wondering about is when (and how long) to assert tx_udp_hdr_valid and s_axis_tlast.
(In my logic, I did a copy / paste of that payload FIFO to use my own signals, and verified that things match up accordingly. The payload FIFO does get filled OK.)
What is opaque to me right now is the timing relationship between hdr_valid and filling up the payload fifo and its associated tlast signal. I have tried various combinations, and just can't seem to find one that works.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
The example logic in udp_fpga_core is a loopback - it gets a packet, and then sends it out. I am just trying to send a packet, because eventually I will need to do that. But because the loopback example (I think) has received an entire packet before it generates a response, it doesn't address the timing for these signals.
I can sometimes come up with a combination that at least starts the process (causes the logic to generate an ARP packet which I then successfully reply to in simulation), but then after that the UDP packet it sends out doesn't have any of my data, has a bad checksum (XX), etc. Also, when it does transmit a UDP packet (as I fiddle with hdr_valid and tlast), most fields in the header are fine, except it thinks it is sending a fragment, and the UDP length is 0x09 and I am expecting 0x48, and the IP length field is 0x1D. The MAC and IP addresses, protocol, source/dest ports, etc., are all fine.
So, I can at least receive and send Ethernet frames to and from my test bench.
(Note that because I had problems implementing cocotb, my test bench and top level modules are VHDL, but that really doesn't matter to my query. Also, I have an MII to RMII adapter, which seems to be working just fine - the ARP query and reply are working fine.)
The signals in question are:
wire tx_udp_hdr_valid;
wire tx_udp_hdr_ready;
and the signals that feed udp_payload_fifo (in the example, they are all rx... because it is just doing a udp loopback)
The ones that I am really wondering about is when (and how long) to assert tx_udp_hdr_valid and s_axis_tlast.
(In my logic, I did a copy / paste of that payload FIFO to use my own signals, and verified that things match up accordingly. The payload FIFO does get filled OK.)
What is opaque to me right now is the timing relationship between hdr_valid and filling up the payload fifo and its associated tlast signal. I have tried various combinations, and just can't seem to find one that works.
JRJ
Beta Was this translation helpful? Give feedback.
All reactions