1 2 Previous Next 22 Replies Latest reply on Mar 7, 2019 9:10 PM by HemanthR_06

    EZ-USB FX3 Read FIFO latency


      Hi Cypress,


      I am working on the EZ-USB FX3 development. The FX3 works as a bridge between the PC and FPGA.


           PC > FX3 (slave) >>>>>> FPGA (master)


      The GPIF interface used between FX3 and FPGA is based on AN87216. The problem that I am facing is during the SLAVE_RD. According to the application note, the valid data always appears after 2 cycles while the SLRD is low. From the capture below, CLK[221] and SLRD = 0, the valid data should be appeared at CLK[223]. However, the valid data [001F] appeared at CLK[224].


      This above case always happens when the SLRD goes from low to high. Any idea?


      ** I forgot to mention that the watermark is 2.

           CyU3PGpifSocketConfigure(1, CY_U3P_PIB_SOCKET_1, 2, CyFalse, 1);


      And, I read the application note AN65974 section 8.3. Did it mean the #SLRD should keep asserted for one more clock cycle (2 x (32/16) - 3) for the data 001f?




        • 1. Re: EZ-USB FX3 Read FIFO latency

          Hi Jason,


          The waveform indicates that the data at clk 220 and 221 did not change. For your question, yes, SLRD should be kept asserted for one cycle after the partial flag is sampled by the FPGA. Currently are you doing the same? If yes, can you please share the waveform indicating the same.




          • 2. Re: EZ-USB FX3 Read FIFO latency

            Hi Hemanth,


            I fixed the above issue by delaying 2 clock cycles on signal SLOE and SLCS after SLRD goes high.


            However, I am facing another issue:


                 >>>     FX3_1     >>>

            PC                                  FPGA

                 <<<     FX3_2     <<<


            COM3 is the log from FX3_1.

            COM14 is the log from FX3_2.


            Case 1a: I send 6 bytes to FX3_1, I can get first 4 bytes.

            Case 2a: I send 3 bytes to FX3_1, I can get those 3 bytes + 1 zero padding.

            Case 3a: I send <=2 bytes to FX3_1, I cannot get any data. The USB control center return error code: -997.


            In addition, I try also:


            Case 2b: I send 7 bytes to FX3_1, I can get those 7 bytes + 1 zero padding.

            Case 3b: I send 5 bytes to FX3_1, I can get first 4 bytes.


            Q1: It looks like 4 bytes alignment issue. Any limitation to the short packet transfer??

            Q2: Does it relate to the DMA alignment?

            Q3: Any way to print out all the data received from slave GPIF interface?




            • 3. Re: EZ-USB FX3 Read FIFO latency

              Hi Jason,


              - We cannot print the data that is sampled over GPIF.

              - The issue is seen when non-multiple of 4 bytes is sent before sending a PKTEND signal to the slave. In the slave state machine, when !SLWR&!PKTEND is true, INTR_CPU is called. INTR_CPU generates a callback in the firmware in which CyU3PDmaChannelSetWrapUp() is called.

              So, making use of CyU3PDmaChannelSetWrapUp() in conjunction with sending non-multiple of 4 bytes is causing the issue.


              Instead what I have tested is:

              - Instead of using Slave fifo state machine from AN87216, use AN65974 state machine where COMMIT action is used when !SLWR&!PKTEND is true.

              - But in that case, we cannot directly use the master state machine as in AN87216. The reason being: In master, when you commit a short packet, let's say 4 bytes, the waveform will look like below(if the GPIF bus width is 16 bit wide):


              According to the above picture, two 16 bit words will be sent out and then at the next edge PKTEND is asserted (along with SLWR and SLCS).

              If this waveform is created at the AN65974 slave interface, it would sample 3 16 bit words and commit the buffer to USB.


              So, a slight modification has to be done on the Master side to assert PKTEND exactly at the end of 2 cycles/after 4 bytes.


              In your final product if you are using FPGA, then this can be taken care easily. Please let me know if you are using FX3 as master in your final application.





              • 4. Re: EZ-USB FX3 Read FIFO latency

                Hi Hemanth,


                1. We will use the following setup for the prototype state:


                     >>>     FX3_1     >>>

                PC                                  FPGA master

                     <<<     FX3_2     <<<



                However, for development phase, I am currently using the following setup:


                       >>> FX3_1 (Master)

                PC          [two FX3 are back-to-back connected]

                       <<< FX3_2 (Slave)


                The master FX3 receives the data from PC then write the data to the slave by GPIF.

                The slave FX3 receives the data from master via GPIF then commit to the USB (PC).


                The non-multiple of 4 bytes issue is found while testing by USB control center. Let me show you the state machine of both master and slave side:







                Besides the previous issue, I have other questions:

                1. May I ask why the latency is 3 clock cycles instead of 2? I read the timing diagram and the latency should be 2.

                csn = SLCS

                oen = SLOE

                rdn = SLRD

                Watermark = 3

                Data bus width = 16-bit


                2. The FX3 hangs up when sending more than 1024 bytes by using USB Control Center.


                *COM3 is master side, COM14 is slave side.

                *Master prints the GPIF state every seconds.


                1st transfer is 1024 bytes (max packet size) and the master still can print out the state. However, I send 1200 bytes in USB control center. The master hanged but it can print out 2 split buffers (1024 + 176) in DMA event callback. Do you have any idea?




                • 5. Re: EZ-USB FX3 Read FIFO latency

                  Hi Jason,


                  - I understand that in your final application, FPGA is the master and two FX3 will act as slaves. In that case, there should not be any alignment problem if you use COMMIT action in SHORT_PKT state in your slave state machine. And while asserting PKTEND signal FPGA should take care that it is asserted along with the last word sent by the FPGA.

                  Please let me know if you have any question regarding this.

                  - Regarding the 3 cycle latency: You have measured from the point 100(where SLRD goes low) to 103. But can you also see this timing diagram with respect to Clock? The time difference between the first rising edge where SLRD is asserted to the first rising edge where the data driven is valid should be two clock cycles.

                  - You are not supposed to perform UART Debug prints in DMA callback. This may be the issue that you are facing. Please remove and let me know.




                  • 6. Re: EZ-USB FX3 Read FIFO latency

                    Hi Hemanth,


                    1. Do you mean I should update the state machine as follow?



                    2. In the picture each integer point represents a rising edge of the clock (each segment represents a clock cycle).

                    Therefore, it shows that the latency, from the first rising edge when #SLRD is asserted to the first rising edge when the data is valid, is 3 instead of 2.


                    3. The hang up issue disappeared after I changed the DMA mode from manual to auto.




                    • 7. Re: EZ-USB FX3 Read FIFO latency

                      Hi Jason,


                      - SHORT_PKT state should have IN_DATA along with COMMIT. But along with that, you should also take care that the PKTEND is asserted by the master(FPGA) along with the last word being sent(not one clock cycle after).

                      - The hang up may not be related to Auto/Manual mode.




                      • 8. Re: EZ-USB FX3 Read FIFO latency

                        Hi Hemanth,


                        I found that the PCLK is uneven. Any idea?




                        • 9. Re: EZ-USB FX3 Read FIFO latency

                          In your firmware, is clockConfig.setSysClk400 is set to true?




                          • 10. Re: EZ-USB FX3 Read FIFO latency

                            Yes. Below is the clock setup segment.


                                CyU3PIoMatrixConfig_t io_cfg;

                                CyU3PReturnStatus_t status = CY_U3P_SUCCESS;

                                CyU3PSysClockConfig_t clkCfg = {


                                2, 2, 2,





                                /* Initialize the device */

                                status = CyU3PDeviceInit (&clkCfg);

                                if (status != CY_U3P_SUCCESS)


                                    goto handle_fatal_error;



                                // PIB initialize

                                CyU3PPibClock_t pibClock;

                                CyU3PReturnStatus_t apiRetStatus = CY_U3P_SUCCESS;



                                /* Initialize the p-port block. */

                                pibClock.clkDiv = 4;

                                pibClock.clkSrc = CY_U3P_SYS_CLK;

                                pibClock.isHalfDiv = CyFalse;

                                /* Disable DLL for sync GPIF */

                                pibClock.isDllEnable = CyFalse;

                                apiRetStatus = CyU3PPibInit(CyTrue, &pibClock);

                                if (apiRetStatus != CY_U3P_SUCCESS)


                                    CyU3PDebugPrint (4, "P-port Initialization failed, Error Code = %d\r\n",apiRetStatus);




                                CyFxApplnSetPibDllParameters (CyTrue, 1, 0, 11);





                            static void

                            CyFxApplnSetPibDllParameters (

                                    CyBool_t isEnable,              /* Whether to enable the DLL. */

                                    uint8_t  corePhase,             /* Delay selection for the PIB core clock.

                                                                       Takes a value between 0 and 15, and applies a delay of

                                                                       (corePhase * 22.5 degrees) from the master clock. */

                                    uint8_t  syncPhase,             /* Delay selection for the data synchronizer clock used in async modes. */

                                    uint8_t  opPhase                /* Delay selection for the output clock driven by FX3. */



                                /* Disable DLL */

                                CY_FX3_PIB_DLL_CTRL_REG &= ~(CY_FX3_PIB_DLL_ENABLE);

                                CyU3PBusyWait (1);



                                if (!isEnable)




                                /* Configure and enable the DLL. */

                                CY_FX3_PIB_DLL_CTRL_REG = (

                                        ((corePhase & 0x0F) << CY_FX3_PIB_DLL_CORE_PHASE_POS) |

                                        ((syncPhase & 0x0F) << CY_FX3_PIB_DLL_SYNC_PHASE_POS) |

                                        ((opPhase & 0x0F)   << CY_FX3_PIB_DLL_OP_PHASE_POS) |

                                        CY_FX3_PIB_DLL_HIGH_FREQ |





                                /* Reset the DLL */

                                CY_FX3_PIB_DLL_CTRL_REG &= ~(CY_FX3_PIB_DLL_RESET_N);

                                CyU3PBusyWait (1);



                                /* Clear Reset */

                                CY_FX3_PIB_DLL_CTRL_REG |= CY_FX3_PIB_DLL_RESET_N;

                                CyU3PBusyWait (1);



                                /* Wait for DLL to lock */

                                while (!(CY_FX3_PIB_DLL_CTRL_REG & CY_FX3_PIB_DLL_LOCK_STAT));


                            • 11. Re: EZ-USB FX3 Read FIFO latency

                              Hi Jason,


                              I have not seen such clock in my setup.




                              • 12. Re: EZ-USB FX3 Read FIFO latency

                                Hi Hemanth,


                                1. The hang up issue is resolved after removed those debug print out.

                                2. PCLK uneven issue is resolved because the sampling rate of the logic analyzer.

                                3. IN_DATA is added back to the SHORT_PKT state along with COMMIT and the master asserts the PKTEND along with the last word being sent. We have the following observation:


                                DMA mode = AUTO

                                DMA size = 1024,

                                DMA count = 16,

                                Watermark = 3 (i.e. 3 x (32bit/2) - 4 = 2 clock cycles),

                                USB max packet size = 1024


                                a. Master sends short packet (< 1024 bytes) to slave, then bulk-in the short packet in USB control center, we can get the correct data and data length.


                                b. However, if master sends data with size larger than the DMA size (i.e. 1024KB + 128 bytes) to the slave, the 128 bytes are lost.


                                The above capture shows the start of the 1024B transfer.

                                * aful - DMA watermark flag

                                  csn - SLCS

                                  wrn - SLWR

                                  pen - PKTEND


                                In master side, DMA watermark flag is used as a trigger for beginning a transfer. And, the GPIF state machine is started after DMA channel created.


                                The above capture shows the end of the 1024B transfer.


                                The above capture shows the last 128B transfer.


                                The above capture shows the transition from 1st 1024B transfer to last 128B transfer.

                                The above capture is the state machine of the slave side.


                                Do you have any idea? My understanding is that once the master sends 1024K data (same as the DMA size) to the slave, then the FX3 will commit the data automatically to the USB and switch to the next DMA buffer after DMA_RDY flag is de-asserted. Therefore, no PKTEND asserted for this case. After the DMA_RDY flag de-asserted, the master can send the remaining 128B (i.e. short packet) to the slave with PKTEND asserted at the last word.


                                By the way, does short packet means the size of the packet is less than the DMA size of one DMA slot?




                                • 13. Re: EZ-USB FX3 Read FIFO latency

                                  Hi Jason,


                                  - Yes, if the DMA buffer size of the slave is 1024 bytes, then, once slave receives 1024 bytes, the buffer gets committed to USB and no PKTEND is required in that case.

                                  When the number of bytes sent to the slave over GPIF is less than the DMA buffer size then it is a short packet and PKTEND assertion is required in that case.


                                  - To debug current scenario, make the channel as MANUAL and see if you are getting a callback when COMMIT is executed in the state machine. If it is received check what is the count.




                                  • 14. Re: EZ-USB FX3 Read FIFO latency

                                    Hi Hemanth,


                                    I have tested 2 cases:


                                    a. 1024 + 128 bytes


                                    The result always have last 128 bytes data missed.


                                    b. 2048 bytes


                                    For test case b, I did twice, the above print out is done in the DMA callback (PROD event) and the results are different:


                                    Test b1 (blue rectangle): It indicates that the FX3 received 2KB data but error code 997 is shown when bulk-in in USB control center.


                                    Test b2 (green): only 1026 bytes are received by FX3 and same number of bytes are received in USB control center. For this case, I have a screen capture and a strange behavior of the DMA partial flag. The DMA partial flag did not assert even reach the watermark level (watermark = 3) in the last 1KB transmission.


                                    ^ overall transmission waveform


                                    ^ correct DMA partial flag waveform (1st 1KB transmission)


                                    ^ strange behavior of DMA partial flag waveform (2nd 1KB transmission)


                                    * Also, the FPGA side always assert the PKTEND in the last transmission (This is wrong implementation but I think it's not related to this data missing issue)




                                    1 2 Previous Next