Question about the Avalon ST interface from PCIe Hard IP

[Altera_Forum]

I have a question about the Avalon ST interface that is coming from the Stratix4GX PCIe hard IP. I do not have enough understanding on this so I am not sure whom to ask about this. This is for the Stratix4GX Gen1 x1 PCIe endpoint hard IP simulation and the very first transaction on the Avalon ST bus. I see the following sequence on the waveform viewer.  

 (1) Clock1 - Start of Packet = 1 (Pulse) - Rx_St_Data[63:0] = 0000_000F_4000_0001, Rx_St_Be0[7:0] = F0 Rx_St_Eop0 = 0 (2) Clock2 – Start of Packet = 0 Rx_St_Data[63:0] = 0300_0000_0020_0010, Rx_St_Be0[7:0] = 0F, St_Eop0 = 0 (3) Clock3 – Start of Packet = 0 Rx_St_Data[63:0] = 0000_0003_0000_0003, Rx_St_Be0[7:0] = 0F, St_Eop0 = 1   Can you please help me interpret what this means?    This how I am interpreting this transaction    Header0_Byte0 = 40 – This means 32 Bit Memory write – This is a 3DW memory write (32 bit address and not 64 bit address) Header0_Byte1 = 00 Header0_Byte2 = 00 Header0_Byte3 = 01 – 1 DW write?   Header1_Byte4 = 00 Header1_Byte5 = 00 Header1_Byte6 = 00 - Tag = 0? (This does not make sense) Header1_Byte7 = 0F – First DW is valid.    //Following are the address bytes? Header2_Byte8 = 00 Header2_Byte9 = 20 Header2_Byte10 = 00 Header2_Byte11 = 10 - Address = 0020_0010hex Is that correct? Byte12 to 15 is not valid? This is because Rx_St_Be0[7:0] = 0F for the second clock. This is why there is third clock to complete the tranaction?    The 3rd clock has DW data = 0000_0003h with BE = 0Fh. Lower DW of the Rx_St_Data [63:0] has valid data.    In summary, it is trying to do 3 DW (32 bit address) memory write at address 0020_0010 with data 0000_0003h.    I am not able to locate the internal address/data/command bus to confirm this in the PCIe chaining dma solution. I am not sure whom to ask this question. I do have fsdb wave file which can be viewed using Debussy.    Any suggestions will be great.

[Altera_Forum]

I'm working on a PCIe core design myself right now, so I'll try to help (caveat: my code isn't working yet!). 

 I don't see a problem with tag being 0x00. It just has to be unique among the transactions going on. I wouldn't be surprised if some implementations used 0x00 as the first tag and just incremented for subsequent transactions.   I believe you have the address correct. Since it is a 64-bit aligned address, the data will be in the following word (Altera aligns it as if you are interfacing to a 64-bit memory internally). If it had been a non-64-bit aligned address (say, 0x0020_0014), it would have packed that first (and only) data word into the second clock.   So, anyway, I think you are on the right track. Good luck!

[Altera_Forum]

Since this is a memory write cycle, it is posted cycle. So the tag field does not have any menaing and may be that is why the tag field is 0. As per my understanding any memoy write is posted - regardless of prefetchable or non-prefetchable address range. For my application I may not need I/O write (which is non-posted).  

 Do you use ready signal to throttle the endpoint while the active command is being processed by the application logic? The design example does not seem to use any throtling mechanism.

[Altera_Forum]

Good point on the tag. I only throttle between packets (and doubt that will ever happen in my design). I am putting everything into FIFOs for later handling (a read request FIFO and a write FIFO; eventually one per channel).

[Altera_Forum]

You mention that you are planning on first storing all the information in FIFO. This means that that the FIFO needs to be deep enough to handle the number of transactions the endpoint can handle in post, non-posted and completion channels. Thus the FIFO may need to be fairly deep. Is that correct?