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.

Hi,

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

Regards,

Anand

 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

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

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. 

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.

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