by zinnc »
Thanks for reply.
I found a bug in my project now it get fixed.
Besides, I have to extend FIFO depth to 16,384 to make things right(16384 is not a precise boundary, it's kind of trial-and-error result, cause 8,192 didn't work). But I found some saying in <Xillybus host application programming guide for Linux>:
''While the data flow is stalled, the IP core might be busy with other activities, for example copying data on some other stream’s behalf (i.e. draining another intermediate FIFO). As a result, there might be a random delay between the deassertion of the “empty” signal by the FIFO and the resumption of fetching data from it. This delay varies, but the overall design guarantees that a FIFO of 512 words will not overflow(as long as the average rate is within limit)."
So, '16,384', the correct FIFO depth in my project, means that the average data input rate is out of PCIe limit in my design?
Thanks for reply.
I found a bug in my project now it get fixed.
Besides, I have to extend FIFO depth to 16,384 to make things right(16384 is not a precise boundary, it's kind of trial-and-error result, cause 8,192 didn't work). But I found some saying in <Xillybus host application programming guide for Linux>:
''While the data flow is stalled, the IP core might be busy with other activities, for example copying data on some other stream’s behalf (i.e. draining another intermediate FIFO). As a result, there might be a random delay between the deassertion of the “empty” signal by the FIFO and the resumption of fetching data from it. This delay varies, but the overall design guarantees that a FIFO of 512 words will not overflow(as long as the average rate is within limit)."
So, '16,384', the correct FIFO depth in my project, means that the average data input rate is out of PCIe limit in my design?