Stratix4 PCIE endpoint Hard IP and Avalon ST

[Altera_Forum]

In order to throttle the Avalon ST bus, I am using the Valid signal of the Avalon ST Interface from my application verilog module to PCIe endpoint Hardpoint. In this case, my application module wants to transmit completion with Data packet. The ready signal from the hard IP to my application module is always high - that means the hard IP is always ready to accept the packets from my application module. But the application module is throttling the 64 bit tx_st_data bus using Valid signal. In this mode, the simulation passes for 4, 8 and 12 DW completions with data but fails for 16 DW complation with data. I am not sure why. If I do not throttle the 16 DW read completion packet then it passes. I looked at txdata[31:0] in epmap and it seems to be going unknown for few clocks.  

 The failing completion cycle looks like this.   Clock1 Valid = 1, SOP = 1, tx_st_data[63:0] = 0108_0010_4a00_0004,  Clock2 Valid = 1, SOP = 0, tx_st_data[63:0] = bebe_0180_0000_0004 Clock3 Valid = 0, SOP = 0, tx_st_data[63:0] = bebe_0180_0000_0004 Clock4 Valid = 1, SOP = 0, tx_st_data[63:0] = bebe_0181_baba_0000 Clock5 Valid = 0, SOP = 0, tx_st_data[63:0] = bebe_0181_baba_0000 Clock6 Valid = 1, EOP = 1, tx_st_data[63:0] = 9f1a_220a_baba_0000   As you can see that the application is clearly sending 4DWs of data starting from clock2. I am not sure why the simulation hangs for this case. The read request had Address bit 2 set so the read access was not QW aligned. This is why in clocks2, upper DATA is valid but in clock6 upper data is not valid.   Above completion packet was in response to a read request at byte non-prefetchable address 20_0004 with DW count of 4.    Again if remove the throttling using Valid signal, it passes. So I am not sure why the throttling due to Valid makes the simulation hang.    Any suggestions will be great.

[Altera_Forum]

I see that this is really old, so maybe this has been figured out by now. Just in case... 

 I think the problem is related to a requirement placed on the valid signal between the sop and eop. The requirement stated in the user guide is that valid must be continuously asserted b/w sop and eop when ready is asserted. So, if you truly have ready=1 all the time, it is not legal to drop the valid anywhere in between your sop=1 and eop=1 cycles. (Refer to tx_st_valid description in Table 5-4 of the PCI Express Compiler User Guide, version 9.1).

[Altera_Forum]

Thanks BrettFavre for pointing that out. What I don’t get is why such an important deviation of the Avalon ST protocol is not explained in more detail in the PCIe Compiler User Guide. Don’t want to know how many developers already spent hours searching for the bug in her IP finding only the cryptic explanation of the signal. To an uninitiated, it looks more like a description of the AST readLatency property than a red colored note about a major deviation from the AST protocol. 

 In addition, the restriction doesn’t make sense at all: The AST adaptor has to buffer the frame anyway for being able to handle tx_st_err<n> properly. Allowing stop-and-go DW indication could avoid the additional buffering now required for any application not able to drive the data stream at full rate. A generic approach is to place a Fifo in front of the AST Tx I/F that forwards a frame only if it was finished by the actual sender. This accounts to higher latency, more IP, more bugs, more memory, more power dissipation, for no good reason.  Maybe – hopefully! – Altera will redesign their AST adaptor to allow tx_st_valid to be driven arbitrarily, so this restriction can go away someday.