Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Altera_Forum
Honored Contributor I
736 Views

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
0 Kudos
3 Replies
Altera_Forum
Honored Contributor I
45 Views

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
Honored Contributor I
45 Views

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
Honored Contributor I
45 Views

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
Reply