8 Replies Latest reply on Sep 14, 2016 4:00 PM by clopez_1600431

    GPIF II Designer questions

    william.smith

       I have a question with regard to the GPIF II Designer:

         

      I am trying to create a simple local bus interface where the FX3 is the master and have noticed that whenever I describe a group of states to perform a read of a slave that the IN_DATA action appears to want the data bus to be driven by the slave at least 1 state early if not 2 depending on how you want to look at it.  The attached jpg file is a screen shot of the timing diagram created by GPIF II Designer and in the state machine IN_DATA is an action in the FIFO_RD_1ST state.  I wouldn't expect the data to have to be valid until at least that state if not the one after depending on how IN_DATA is treated.

         

       

         

      I don't have a software resource available yet or I would just try it to find out the answer.  At this point I am just trying to charcterize the interface to see what is possible and how best to utilize the FX3 in our designs.

        • 1. Re: GPIF II Designer questions
          anand.srinivasan.asokan

          Hi,

             

          Please upload the project here. I would like to take a look at it.

             

          Regards,

             

          Anand

          • 2. Re: GPIF II Designer questions
            william.smith

             Here is just a crude example of 8 reads from a synchronous FIFO that I did just to play with the controls and see what effect changing where actions were placed in the state machine.  I removed the loop count of 2 in the FIFO_RD_WAIT state that seems necessary to have the data sampling in the correct place.  Of course I could just be interpreting the waveform incorrectly.

               

            Thanks Bill

            • 3. Re: GPIF II Designer questions
              manish.rao

               Refer  Section 4.6.2 (Analyzing Timing) in GPIF II Designer User Guide for analyzing the timing.

              • 4. Re: GPIF II Designer questions
                william.smith

                Thanks for responding but section 4.6.2 wasn't much help!

                   

                "The user can verify the their design by simulating the timing waveform in the Timing canvass.  The user needs to create a "Timing scenario" to simulate the taming [sic] waveform for a specified path."

                   

                "The following screen shot captures timing scenario for the READ path."  This is a ansynchronus slave read (FX3 is a slave).

                   

                screen shot of scenario

                   

                "Note that each state in the timing scenario is simulated for a single clock cycle evaluating the output.  In the above case the state machine is expected to be in READ_WAIT for six clock cycles.  Therefore the timing scenario should have six READ_WAIT states in sequence."

                   

                "Screen shots capturing simulated timing for Read and Write paths are captured in the following figurres."

                   

                2 blurry screen shots of a read and a write to the FX3

                   

                Lets see my question was about what appears to be a very early, by 2 states, data in on a synchronous read where the FX3 is the master.  Since I am never driving an address out in this case the only thing that should appear on the address/data bus is the data and as far as I can figure out the FX 3 wants the data to be driven in 2 states before the actual IN_DATA action.  The first IN_DATA action is in FIFO_RD_1ST state.  By the way the example that I have sent in the zip file is not how I would prefer to do a block read but just a simple example that shows what I believe to be a bug.  Even when doing a simple read cycle where I do use an address to address a specific device/register the data winds up overlaping the address unless I put in wait states. 

                • 5. Re: GPIF II Designer questions
                  marshall.sharpe

                  Check out page 16 of the CYUSB3014 datasheet, which gives timing parameters for synchronous applications in GPIF II.  This is probably closer to what you are expecting to see for timing.  I do find it strange that there is activity on the data lines anytime before 50 ns.

                  • 6. Re: GPIF II Designer questions
                    manish.rao

                     Thanks for the reporting the potential bug. Will be reported to the concerned team.

                    • 7. Re: GPIF II Designer questions
                      vaagn.oganesyan

                      Hi,

                         

                      I have got the same problem with IN_DATA. Waveform editor in GPIF Designer shows that data is latched earlier than I call IN_DATA. My SDK is 1.3.3, GPIF Designer  1.0  (1.0.1198.2). 

                      I haven't tested my FSM yet, but I want be to sure that it's only an incorrect waveform in the editor. Three years passed, are there any news? 

                         

                      Best regards

                      • 8. Re: GPIF II Designer questions
                        vaagn.oganesyan

                        Hi,

                           

                        Answering my own question...

                           

                        I tested my FSM, now I'm pretty sure that there is no trouble with waveform editor in GPIF. Looks like FX3's GPIF has an internal pipeline for data. And if you want to latch correct data at the state, where you call IN_DATA, the actual data should be forced at the bus for 2 clk cycles earlier. Nevertheless I can't find this information in datasheet.

                        • 9. Re: GPIF II Designer questions
                          clopez_1600431

                          Hi,

                             

                          I see the same behavior both in GPIF II Designer and also in hardware. The first data word to be latched by IN_DATA should be present on the bus 2 clock cycles earlier to the state. I thought that this was an error in my state machine or something else but now that I see these posts I can confirm that this is the "expected" behavior. Is this documented somewhere?

                             

                           

                             

                          Best regards,

                             

                          Carlos