Forum Discussion
Altera_Forum
Honored Contributor
9 years agoDaixiwen,
I want to first thank you for your quick and thoughful reply! I was distracted in other work for the time being. I just found a solution and am posting it here to help anyone else having issues with Avalon-ST data flow. Attached are images of the problem (signaltap of the problem, block symbols of the interfaces, and the connection finally working). I called the custom module C2 and Tripple Speed Ethernet/MAC Megacore module TSE. We see the C2 module receiving a READY signal from the TSE module. C2 has a valid packet and sends it, asserting VALID. We see the Start of Packet (SOP) and End of Packet (EOP) signals from the C2 source. In return, we see the same SOP and EOP signals at the TSE module sink, as well as the TX_RDY ready that was driving the READY signal. What is missing is the VALID of the source does not drive the TX_WREN of the TSE module. The C2 module has onboard data and channel FIFOs. We see that the C2 module is emptying both of them at the same time, so data is being passed on. At the end of the source cycle, the last of the data is read, and the channel FIFO is acknowledged with a read request. This causes both the data and channel FIFOs to be shown as empty. Note that the usedw signals show “0” as they are not driven by anything; they are disconnected. We do see the EMPTY signals being asserted to validate the face that data is being moved. The problem is that Altera seems to be inserting it's own error adapter but disconnecting the valid signal somehow. After much trial and error with other Avalon-ST Streaming interfaces (notably trying to use channel sizes greater than 8 bits), if the sink and source interfaces do not *exactly* match it will insert it's own error adapter that may or may not modify channel size (limiting it to 8 bits wide) or interfering with other signals. The solution and lesson learned is to *always* match source and sink interfaces exactly with the number and width of ports in order to prevent unpredictable behavior caused by Qsys inserting it's own error adapter. In my case, I had to add a 1-bit wide error signal as well as remove the channel outputs of the custom component C2.