ff_rx_mod in TSE bug?

--- Quote Start ---

I am using the TSE with 32-bit wide data. When transmitting I'm using the ff_tx_mod[1:0] signal to truncate bytes off the last 32-bit word transmitted by the TSE. all modes work except mode "10" when I want to transmit only the the first 2 bytes of the 32-bit word. The TSE still transmits all four bytes. I'm using the cyclone III 120 Dev. Board and actually connected the two ff_tx_mod signals to two dip switches, just for testing, and transmitted the same data in all modes and got an error in all modes.

--- Quote End ---

I have a similar problem.

With signaltap i can see that tx_mod is properly set ('10') but the TSE refuse to transmit these 2 bytes...

I've done it with 11.1sp2

--- Quote Start ---

I have a similar problem.

With signaltap i can see that tx_mod is properly set ('10') but the TSE refuse to transmit these 2 bytes...

I've done it with 11.1sp2

--- Quote End ---

If i assert tx_mod (empty signal) to '10' only when eop is true (else to '00') then the TSE is working propertly. This is a bug since Avalon ST interface specifications said that the empty signal is evaluated only when eop is true. Interesting this odd behaviur is visible only with an empty value of '10'.

--- Quote Start ---

This is a bug since Avalon ST interface specifications said that the empty signal is evaluated only when eop is true. Interesting this odd behaviur is visible only with an empty value of '10'.

--- Quote End ---

I don't think that Altera tests this part a lot, because I had some problems with the SGDMA that did weird things if the empty signal wasn't "00" on a non-end-of-packet word. So now just to be safe on my IPs that generate an Avalon Stream I always ensure that empty is always "00", except on an end of packet where it is the expected value.