TSE UDP Streaming Problem

[Altera_Forum]

Hi everyone, 

 I know similar problems were discussed in this forum several times but no thread helped me on my problem.  My design is targeting the DE2-115 and is based on the UDP Offload example.  I have a Triple Speed Ethernet core running with SGDMA. This datapath is fully working. I can ping my board and the NicheStack automatically gets the IP from a DHCP server. Now I added the cores from the UDP offload example which should generate data, UDP header, alignment and the stream is multiplexed with the SGDMA stream and forwarded to the TSE core.  But the TSE does not transmit the generated data.   When I take a look at the multiplexer I can see that packet header of the InterNiche packets and my generated packets seem to be the same and all packets a forwarded to the TSE.  Does anyone have an idea about that?  Regards  Michael

[Altera_Forum]

How do you know the packets aren't transmitted? How do you detect them? If you are using a packet sniffer on a PC, in some cases the packets are dropped by the network hardware before they make it to the sniffer (especially when bad checksums or headers). 

Do you seen them going between the TSE and the PHY chip?

[Altera_Forum]

I am using Wireshark for network monitoring and it should give me all packets on the network no matter if they are corrupted or valid. 

 The packets are not transmitted to the PHY by the TSE.  In the design the UDP hardware is continuously generates packets but there is no action on the TX led on the board or on the wires to the PHY.  When I start pinging from my desktop computer I can see a blinking TX led in time with the ping response and I can observe the ping response on the TSE output.  For additional information: The Quartus version is 11.1sp2 and the TSE is working in MII 10/100 mode.

[Altera_Forum]

Did you check with SignalTap all the signals between the multiplexer and the TSE, when you send a packet? IIRC there is no reason why the TSE wouldn't transmit a packet that is placed on its Avalon stream sink, so as long as this protocol is followed correctly (start of packet, data, end of packet, and respect of the ready/valid signals). 

Did you try to ping the board after trying to send a packet through the hardware UDP cores? Just to be sure the TSE isn't stuck in a strange state.

[Altera_Forum]

I checked all connections to the TSE, see attached a screen capture of SignalTap. On input 0 is the SGDMA with the data from InterNiche and on input 1 is the UDP hardware. 

 As far as I can see everything of the protocol stuff is working correctly. Pinging the board does always work.  Also interesting: In my design the UDP hardware theoretically generates too much data for a 10/100 MBit connection but the TX buffer never gets full. As you can see in the SignalTap the Ready signal for the multiplexer output is always high.

[Altera_Forum]

SOLVED! 

 As you could see on SignalTap the stream was valid, BUT: The automatically inserted ST Channel Adapter surely only forwards one channel. With using the multiplexer it creates a stream with two channels and the channel adapter deletes the "valid"-signal of the second channel. So all of the data was coming to the TSE but with a constant low "valid"-signal.  By manually altering the channel adapter verilog file it works. Every packet is completely transmitted by the TSE.  But I am still wondering why the adapter is automatically inserted after a multiplexer... by discarding one channel there would be no need for the multiplexer...

[Altera_Forum]

Oh yes I didn't think about that. The channel adapter is added automatically because the multiplexer creates a channel signal (to indicate which source the packet came form) but the TSE's sink doesn't support channels. Now from the documentation: 

--- Quote Start ---  You can also use  this adapter to connect a source with a wider channel to a sink with a narrower  channel. If the source provides data for a channel that the sink cannot receive, the data  is not transferred.  --- Quote End ---  This is rather unintuitive. The adapter isn't even configurable so you can't say what channels you want through, it will just discard the extra channels. IT looks like the only solution is to write your own adapter, or modify the existing one (but in that case be very careful that SOPC Builder/QSys doesn't overwrite your code the next time you generate!).