FPGA Intellectual Property
PCI Express*, Networking and Connectivity, Memory Interfaces, DSP IP, and Video IP
The Intel sign-in experience has changed to support enhanced security controls. If you sign in, click here for more information.
6156 Discussions

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

Honored Contributor II

Any smart Avalon-ST interface knowledgeable people able to figure this one out? 


This works as connected in Qsys on via the Avalon-ST interface:  

TSE recieve --> error packet discard module --> TSE transmit 


This does NOT work and valid signal disconnected at point marked by **: 

TSE recieve --> error packet discard module --> additional logic module -->** TSE transmit 




Hi all. I tried connecting a custom Avalon-ST source to the Triple Speed Ethernet (TSE) Megacore sink. Using SignalTap, I discovered the 'valid' signal of my source would not drive the sink of the TSE module transmit. Has anyone else had this issue? Is this a bug? 


My guess is it that the Avalon-ST adapter that QSYS automatically generates disconnected it. I was able to solve by exporting both signals and connecting them manually in my top-level instantiation template, but I'd rather have it internally connected. Anyone experience this before? 


I tried hard to figure this out for three days straight. I tried the Avalon-ST Error Adapter IP as well as tried writing my own adapter, but I could not drive the valid signal using Qsys. I triple checked my signals to make sure they were associated properly. I tried forcing a constant 'valid' signal. It simply wouldn't drive. I did notice that Qsys made an adapter for me, and it was at that adapter connection point that the signal would not transmit. Definitely was pulling out my hair trying to figure it out. Good thing my hair is short and I couldn't pull too much out. ;-) Any comments would be much appreciated.
0 Kudos
5 Replies
Honored Contributor II

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?
Honored Contributor II



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.
Honored Contributor II


Honored Contributor II

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 


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 ---  

Honored Contributor II

I found out what the problem was. I didn't store the correct PHY address before trying to configure them, so they were simply going off their default settings in an unconfigured state. (Marvell 88EE1111 for the Terasic DE2-115 Cyclone IV Dev Kit)