Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
16 years ago

Stratix4 PCIE endpoint Hard IP and Avalon ST

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.

2 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    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.