Forum Discussion

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

problem sending mem write TLPs using PCIE core

Hi,

I am having some problem in simulation while sending memory write TLPs from Endpoint to Host. Whenever i pulled down the tx_valid (while tx_ready is asserted) in between the header words, I got a corrupted TLP at the Root port.

For example if I try to send a 3DW header memory write TLP and insert gap between header words ( let say 3 cycle gap between {H1,H0} and {D0, H2} ) I received correct Header words but the invalid data words. If I try to avoid the gap my simulation runs perfect.

I am using a stratix IV 64-bit user interface PCIE core.

Is there any recommendation fro Altera regarding tx_valid?

Thanks in advance

3 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    You are not allowed to deassert tx_valid during your whole packet, you have to stream it to the hard IP TX port at once. The only situation where you have to stop is when tx_ready is de-asserted. This means that you either have to be prepared to do the streaming at full 64 bit I/F width from your data source or you need some kind of intermediate buffering and only start the transaction when you are prepared for a sustained data rate.

    – Matthias
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Thanks Matthias,

    But i didn't found any thing regarding tx_valid in the datasheet. Its not mentioned that you have to keep the valid high for the entire packet transmission or if the tx_ready is de-asserted. Is this related to avalon-st specification?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Look at the pcie user guide (http://www.altera.com/literature/ug/ug_pci_express.pdf). Table 5–4 specifically says about tx_st_valid<n>:

    --- Quote Start ---

    Clocks tx_st_data<n> into the core. Between

    tx_st_sop<n> and tx_st_eop<n>, must be asserted if

    tx_st_ready<n> is asserted. When tx_st_ready<n>

    deasserts, this signal must deassert within 1, 2, or 3

    clock cycles for soft IP implementation and within 1 or 2

    clock cycles for hard IP

    --- Quote End ---

    So you have to read it that way: Must not be de-asserted during a packet transmission, except when the hard IP indicates flow control by de-asserting tx_st_ready<n>.

    – Matthias