GPIF II Designer questions

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

 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.

0 Likes
9 Replies
Anonymous
Not applicable

Hi,

   

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

   

Regards,

   

Anand

0 Likes
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

 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

0 Likes
Anonymous
Not applicable

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

0 Likes
Anonymous
Not applicable

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. 

0 Likes
Anonymous
Not applicable

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.

0 Likes
Anonymous
Not applicable

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

0 Likes
vaogc_284256
Level 1
Level 1

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

0 Likes
vaogc_284256
Level 1
Level 1

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.

0 Likes
Anonymous
Not applicable

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

0 Likes