Forum Discussion
Altera_Forum
Honored Contributor
15 years agoHi Brendan,
Yes, I found a solution (which I don’t use yet): Just use the undocumented signal of that name that is actually present on the hard IP interface, despite of the docs that show it just on the descriptor/data IP macro. Regarding your receive buffer management issues: After spending quite some time implementing something that looks to be compliant to what’s written in the PCIe Spec and the Altera PCIe Compiler Guide, I took a look at UG517 from Xilinx. Appendix E from my edition (v5.0), »Managing Receive-Buffer Space for Inbound Completions«, not only describes just a simple algorithm but gives a complete overview of this topic and lists multiple options of different complexity/size/efficiency, together with more or less complete descriptions of algorithms for immediate implementation. The only topic missing in this chapter is proper Completion Timeout handling in the given context. BTW: I found out the code I had written was an implementation of DATA_FC while my interfaces were designed like STREAM_FC. The chapter reading showed me that there are other, simpler ways of implementing the required functionality which I hadn’t thought of. Hint: The less receive completion buffers you allocate (»Desired performance for received requests« towards Maximum, »Desired performence for received completions« towards Low) the more effect will the granularity (efficiency) of your DMA read completion buffer allocation have for your throughput. edit: well, beside the hard ip macro where it’s an undocumented feature, the signal is actually not present on the soft ip macro but on the descriptor/data interface, and that’s where it’s documented.