DR_GPIO latency vs. DR_DATA latency in GPIF II

[Anonymous]

Using the GPIF_DESIGNER, inside the same state, I drive an early mode control (DR_GPIO) and also data (DR_DATA). 

   

According to what I understood from the Cypress documentation, the control has a 2-clock latency while data is driven right away. So, control is reaching the FPGA interface 2 clocks later than the moment state was active and also 2 clocks after data reaches the FPGA interface. 

   

We could not see this by actual measurement. Actually both the control and data come at the same time. I believe documentation should have details about relative timing between controls and data.

   

I will appreciate clarifications on this. The system is synchronous (PCLK used), GPIF II on 32 bits and driving data while a control (WE) is asserted needs to be precisely controlled.

[Anonymous]

Are you using AN65974 example? We have provided the read timing in figure 3 of the application note. Please record the signals so that we can also see and compare the behavior. Link to application note:http://www.cypress.com/documentation/application-notes/an65974-designing-ez-usb-fx3-slave-fifo-inter...

   

Are you talking about the latency in reflecting the flg status? This can be found in table 4 of the above document.

[Anonymous]

Hi Nishant,

   

Thank you for your reply.

   

In our case FX3 GPIF II is master. My understanding from the specs is that if I assert WE control now, it will be available at the interface with the FPGA 2 PCLK later. At the same time, data will be available at the I/F on the same clock. I executed DR_GPIO and DR_DATA for the exact same data for 4 consecutive clocks. The guys dealing with the FPGA are telling me they see data and WE at the same time, for all 4 clocks, like there is no latency difference between GPIO and DATA in GPIF. 

   

The intention in the GPIF project is to send the same data for 4 PCLK and then new data on the following PCLK. Please give me all the details so I truly apply correctly the "latency" that Cypress docs talk about.

   

I uploaded the *.cyfx project if you could have a look. It is mandatory for me to exercise correctly at PCLK level all the assertions or the FPGA design will not work properly.

   

Thank you,

   

Zar

[Anonymous]

 I see that you are talking about the timings at the FPGA side. I believe that it can also be due to routing on the board. I request you to test the signals on the GPIF/FX3 end to make sure that the routing are not causing the delay. I have checked, and I do not see any such problem. I notice that the GPIO toggles before the data in case of early signaling. I used FX3 explorer kit and the attached firmware to check. Can you check under a same environment? 
---------------------------------
Please find the attached project. I tried to drive data and assert the GPIO in the same state (see in the attached GPIF project). The Dr_data is already having a 3 cycle delay. So, when the GPIO is configured as delayed (3 cycle), you will see that the GPIO and the data bit getting asserted at the same time. If you set the GPIO as early, you should notice that the GPIO is asserted in the previous cycle to the DR_data action. I verified this and saw the same behavior. I request you to try using the attached project. As previously mentioned, the DR_data already has a 3 cycle delay. Please check and let me know if you see any different behavior. 
---------------------------------