User Profile
corestar
ContributorJoined 7 years ago
User Widgets
Contributions
Re: How to handle tx_st_ready for Cyclone V PCIe
Hello VenT_Altera , Sorry for the late response; we're on Holiday here. I've implemented timing as per the diagrams and it seems to work, but I always like to understand things. I think what was confusing me is the statement that the readyLatency is two clock cycles: I think what they mean to say is the readyLatency is up to two clock cycles. Is the following a valid way to look at things: The PCI core always accepts data when tx_st_valid is high. However, it tx_st_ready goes low, you must deassert tx_st_valid within two clock clock cycles and not reassert until at least one clock cycle after tx_st_ready goes high again. Regards, DaveCan an Application Ignore PCIe flow Control Credits?
I'm using a Cyclone V GT with PCIe core using Gen 1 Avalon-ST 64-bit endpoint interface. Occasionally packet sending would stall and I had thought it was because I was ignoring the flow control credits. But after properly handling tx_st_ready going low, the problem seems to have gone away. So the question is can I ignore the flow control signals as long as I throttle the sending when tx_st_ready goes low? In the flow control section of the UG-011110 dated 2020.06.02, it says That is not important for our application. But then after spending several paragraphs explaining how the PCIe Hard IP tracks and checks credits, it make says: Can I assume that is only in the case described in the yellow highlight? Also, in the flow control update loop description, is says: Is that where the Hard IP is lowering tx_st_ready so the App is indirectly handling credits? If so, one odd thing is that sometimes tx_st_ready does not go low until toward the end of a packet write (ie closer to the EOP and the SOP). I would think it would do the credit check as soon as it had the TLP headers which contain the type, number of dwords etc. Just a suggestion, but for Apps that did want to optimize throughput, it would have been helpful to just expose the credit limits to the App instead of making it independently keep track of them. The credit system is a bit confusing.How to handle tx_st_ready for Cyclone V PCIe
I'm using a Cyclone V GT with PCIe core using Gen 1 Avalon-ST 64-bit endpoint interface. Everything works pretty well including sending and receiving data, DMA transfers etc. But so far I've ignored the situation where tx_st_ready is deasserted during a packet transmission. Time to deal with it, but the docs are a bit confusing. For example, the following implies I have some sort of control over the readyLatency, but I see nothing in the core generator to set that. How to I know what the readyLatency is? And what to they mean the "typical case"? In the above, are they saying I should register them? I see nothing in the core generator to say if they should be registered or not. They give a timing diagram below which is a bit confusing.
