bug in Qsys(?). Avalon-ST 'valid' signal broken by Qsys adapters

Your attachment is difficult to see, the forum automatically reduce image sizes. Try to put it in a zip file instead, or to host the image offsite.

Did you check that the stream interface was defined properly in your custom component? The component editor can show you expected timing diagrams for your interfaces. It could be that the ready latency value is not correct.

Alternatively could you share your hdl and *hw.tcl files for your custom component?

Daixiwen,

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.

Ok, looks like my module works now (attached). There was a PHY problem. My orginal setup was two linux virtual machines in VMWare Workstation Pro, with a TerASIC DE2-115 passing the traffic (Cyclone IV FPGA/Marvel 88EE1111 PHY). I had a Microsoft Surface Dock and UGREEN 1Gbps USB adapter to provide Ethernet I/O:

Kali Linux VM <-----> MS Surface Dock <-----> DE2-115 <-----> UGREEN Dongle <-----> Kali Linux VM

I got a hold of another UGREEN 1Gbps dongle for $13 on Amazon (http://a.co/aad7tr):

Kali Linux VM <-----> UGREEN Dongle <-----> DE2-115 <-----> UGREEN Dongle <-----> Kali Linux VM

I really don't understand why. I had set the TSE Control Register to 0x1b (PROMIS_EN, ETH_SPEED, RX_ENA, TX_ENA) and MDIO Control Register to 0x1140 (1GBPS speed, AUTO_NEG_ENABLE, FULL_DUPLEX) and completed a PHY MDIO software reset. I would think that autonegotiation would allow easy communication with the Microsoft Surface Dock gigabit Ethernet adapter, but it seems not so.

I would really like to find out why the Microsoft Surface Dock wasn't communicating, but using the same USB dongles seems to work:

--- Quote Start ---

Dropped packets on ETH0-H: 0

Dropped packets on ETH1-N: 0

TSE_H_BASE aFramesRecievedOK: 50 | aFramesTransmittedOK: 122

TSE_N_BASE aFramesRecievedOK: 122 | aFramesTransmittedOK: 50

Outbound EPD. Processed: 50. Dropped 0:

Inbound EPD. Processed: 122. Dropped 0:

Outbound C2

DISCARD IPv6 OTHR CH3 CH4 CH5 CH6 TOTAL

Count: 0 50 0 0 0 0 0 50

Enable: 0xff

Total packets seen: 50

UDP Checksum Error Count: 0

IPv6 Checksum Error Count: 9

Last Checksum computed: 0xffff

--- Quote End ---