FPGA Intellectual Property
PCI Express*, Networking and Connectivity, Memory Interfaces, DSP IP, and Video IP
The Intel sign-in experience has changed to support enhanced security controls. If you sign in, click here for more information.
6160 Discussions

Qsys PCIe random temporary transfer stop

Honored Contributor II


we have implemented a PCIe unidirectional data transfer between a Terasic TR4 board (Stratix IV GX230) and a PC (Windows 7), via PCIe cable and PCA adapter, 4 lanes gen1 using a Qsys SGDMA design (streaming) on Quartus 13.1 and Windriver. 

We get a continuous, sustained and stable throughput higher than 600Mbyte/sec (transfer speed measured via Windows timer every 1 second) stopping momentary the data generator when Avalon bus is not ready. The data transfer end is actually checked using polling (with intermediate wait), as we get higher transfer rate than using interrupt. 

Trying to transfer 400Mbyte/sec from an uninterruptible source, we noticed random momentary transfer stops from less than 1 mS (more times in a second) up to more than 100mS (one time after several minutes of continuous transfer), and so data loss, as only minimal buffering is actually used. The same happen on different PCs and also a Dell server machine. 

In this situation, we need something like 100Mbyte of FIFO in order to cope with momentary transfer suspensions and not loosing data. 

Before to start the FIFO design using the DDR3 memory available on the TR4, we would know if this behaviour may be considered normal or we have to find a bug somewere. 

May the problem be related to (if it is still true) lack of completion timeout support by Qsys PCIe IP? (parameter completion_timeout = "NONE" in sopc_top_pcie_hard_ip_0.v file) 

In case the DDR3 FIFO is really required (if this beaviour is "normal"), it would be better to implement a Memory Mapped DDR3 to PCIe scheme or a custom FIFO with DDR3 on generator side (no Avalon for FIFO) ? 


Best regards, 

0 Kudos
1 Reply
Honored Contributor II


no one can give me an answer ?  

It is useful also to know that the problem don't arise in other context, and so our design is wrong somewhere!