3 Replies Latest reply on Sep 12, 2018 7:03 AM by abga

    Need to confirm FX3 DMA flag behavior

    premji.chaudhari_3505471

      Hi All,

       

      Since I get code written by someone and need to understand how FLAGs works exact, please let me know what he has done here:

       

      Let me give first application context:

      - FPGA acts as Master

      - FX3 acts as 32-bit Slave-FIFO

      - Total 2 threads taken with their respective socket as below:

         [1] Thread0 with Socket0 used for data flow from Host PC (producer) -> FX3 GPIF (consumer socket) -> FPGA

               This is for to send, at a time only,  4-bytes (single 32 bit word) data as an address of FPGA register. When FPGA reads this address, it will send back corresponding single 32 bit data on Thread1(with Socket1).

         [2] Thread1 with Socket1 used for data flow from FPGA -> FX3 GPIF (producer socket) -> Host PC USB (consumer)

               This is to read data back from FPGA against address sent on Socket0.

       

      - FLAG-B is used for Thread0 with following configuration in GPIF Design tool:

        [1] It is Active Low with Initial value as LOW

        [2] It is 'Thread_0_DMA_Ready' flag.

        Also, in FX3 firmware (C-code), that API is called like CyU3PGpifSocketConfigure(0, CY_U3P_PIB_SOCKET_0, 1, CyFalse, 1);

      - FLAG-A is used for Thread1 with following configurations:

        [1] It is active-High with initial value as HIGH

        [2] It is 'Thread_1_DMA_Ready' flag.

        Also, in FX3 firmware (C-code), that API is called like CyU3PGpifSocketConfigure(1, CY_U3P_PIB_SOCKET_1, 1, CyFalse, 1);

       

      Now let me ask these queries:

      [1] Is this code correct ? In API, watermark value is 1 with flagOnData as 'False' while GPIF tool configures the FLAGs as 'Thread_DMA_Ready'. Can you please explain how this works exact ?

      [2] Why FLAG-B kept as active-low and FLAG-A kept active-high ?

       

      It will great help to resolve my doubts and to move ahead.

       

      Thanks,

      Premji

        • 1. Re: Need to confirm FX3 DMA flag behavior
          hman

          Hello Premji,

           

          CyU3PGpifSocketConfigure() API is used to

          1. Associate a particular thread to particular socket.

          In your code, thread 1 is associated to socket 1 and thread 0 to socket 0.

           

          2. Third parameter sets the water mark level. This is used when partial flag is in the GPIF-FPGA interface.

          Please refer to section 8.3 of the app note AN65974: (http://www.cypress.com/file/136056/download )

           

          The parameter flagOnData:

          When set to CyFalse: The partial flag will be set when the socket contains less data than the watermark. (Generally used in this way)

          Note: Here watermark indicates number of bytes as mentioned in section 8.3 of above app note.

          When set to CyTrue  : The partial flag will be set when the socket contains more data than the watermark. (Generally used in this way)

           

          Both the watermark value and the flagOnData parameters of CyU3PGpifSocketConfigure() does not make sense for DMA_Ready_Flag. Those are for partial flags which can be used by adding them in the GPIF II designer tool.

           

          3. Regarding: "Why FLAG-B kept as active-low and FLAG-A kept active-high?"

          - It depends on how the FPGA interprets them. From FX3's point of vew:

          • If a DMARDY Flag for a socket which takes data into FX3 is configured as:

                         a. Active low: the flag is asserted (driven low) when the socket is full.

                         b. Active High: the flag is asserted (driven high) when the socket is full.

          • If a DMARDY flag, for a socket where data is read out by external device is configured as:

                         a. Active low: the flag is asserted (driven low) when no buffer is available to be read

                         b. Active High: the flag is asserted (driven high) when no buffer is available to be read.

           

          Regards,

          Hemanth.

          • 2. Re: Need to confirm FX3 DMA flag behavior
            premji.chaudhari_3505471

            Hi Hman Thanks for Reply.

             

             

            Note: Here watermark indicates number of bytes as mentioned in section 8.3 of above app note.

            I think this is number of data words, not in bytes. corrrect ?

             

            Can you please let me know what settings I need in GPIF-design tool for both flag in CyU3PGpifSocketConfigure() API.

             

            Let me tell you my usage:

            Host will send one word register address (e.g. 0x0000_0004) via GPIF thread0 (socket0) using BLK-OUT End-point. Flag-B is used for this thread-socket.

            In return, FPGA will respond one word (4 bytes like 0x0011_2233) data of this addressed register to FX3 via thread1 (socket1).

            Flag-A us used for this thread-socket.

             

            Since this transaction is for only one-word at a time in both direction, what settings I should use in API and GPIF-design tool for flags ??

            Meanwhile let me think it from side as well.

             

            Thanks,

            Premji

             

             

            • 3. Re: Need to confirm FX3 DMA flag behavior
              abga

              --> I think this is number of data words, not in bytes. corrrect ?

              Yes it is the no. of data words (each data word is equal to the data bus width).

               

              As per your application. I think there is no need to make use of WATER_MARK_FLAG. You can make use of READY_FLAG to check if there is any data present in the dma buffer(while sending command from the host). But you have to use counter on the FPGA side so that you can read only 4 bytes from the GPIF.

              Now while sending data from the GPIF to the USB you can make use of PACKET_END signal. First check for the DMA_READY_FLAG and then write the data (4 Bytes) and then assert the PKT_END signal( this will commit the partial buffer to the USB side).

               

              Hope this will help.

               

              Thanks & Regards

              Abhinav