FPGA Intellectual Property
PCI Express*, Networking and Connectivity, Memory Interfaces, DSP IP, and Video IP
Intel Support hours are Monday-Fridays, 8am-5pm PST, except Holidays. Thanks to our community members who provide support during our down time or before we get to your questions. We appreciate you!

Need Forum Guidance? Click here
Search our FPGA Knowledge Articles here.
5952 Discussions

problem sending mem write TLPs using PCIE core

Honored Contributor II



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
0 Kudos
3 Replies
Honored Contributor II

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
Honored Contributor II

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?
Honored Contributor II

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