You are here

GPIF II hiccup first time through buffer ring | Cypress Semiconductor

GPIF II hiccup first time through buffer ring

Summary: 2 Replies, Latest post by Cletus on 30 Dec 2015 11:00 AM PST
Verified Answers: 0
Last post
Log in to post new comments.
Cletus's picture
7 posts

We're using a Cypress FX3 GPIF II Slave FIFO interface in a many-to-one configuration driven by a custom FPGA.  We have noticed an issue that we cannot explain.

Our FPGA is running on a continuous 112MHz sampling clock generating 16kB frames of data.  We are using two ping-pong buffers 4 deep for both channels feeding the socket.  Every such frame, the FPGA updates a unique 16 bit ID that is placed in the frame to allow us to ensure data integrity - we need to avoid gaps.  During normal operation, the system works just fine.  The initial startup is the problem - the very first time we cycle back to the front of the DMA buffer ring (that is, after the eight frame), we see a gap in the data.  Our frame IDs run through a sequence 0, 1, 2, 3, 4, 5, 6, 7, 77, 78.....

We start and stop the FPGA when starting and stopping data acquisition frequently during normal operation, which also pauses the Slave FIFO interface.  Upon restart, there is no such gap in the data.  It happens only on the very first startup of the channel.  Another product uses a similar system but a different DMA buffer count, and it too sees the exact same wrap around problem once and only once every power cycle.  Let me add that the actual channel creation and state machine startup happens much earlier than the first acquisition, so we believe the system to be fully up and running when this happens.  

So it seems that there is a 1-time delay associated with wrapping the GPIF II engine back around to the front of the DMA buffer queue.  Is this expected?  

PRAG's picture
Cypress Employee
173 posts

Hi Cletus,

You mentioned  your fpga runs on 112MHz sampling clock. Are you running the FPGA-Fx3 interface also on this clock?

This interface can only take a max clock of 100MHz; behaviour at higher clocks is not defined.

Does the fpga poll the dma flags for the two sockets and write into fx3 only when buffers are available?


Cletus's picture
7 posts

Thanks for the questions.

We are running the interface at 100MHz.  We pack two samples into every transaction, buffered by the FPGA.  Yes, the FPGA uses the socket flags to determine when buffers are available.  In steady state mode, the system works flawlessly.  We can run for hours and hours with no dropped samples or other issues.  It is ONLY on the very first cycle back to the front of the DMA buffer ring that we see this one-time hiccup.  It is 100% repeatable, every time.  

Log in to post new comments.