Slave-Master transfer works but FPGA-Master (FX3) transfer is not working

[LeDe_2880731]

Hi Cypress,

We bought two CYUSB3KIT-003 Explorer kits and used AutoMaster<=>AutoSlave in AN87216 Designing a GPIF™ II Master Interface to transfer the data between the two kits. They are working perfectly.

Then we modified the GPIF II programs to change the 32-bit bus to 16-bus. They also work very well.

Now we use our FPGA to simulate the Slave FIFO. We can transfer the data to FPGA without any problem. However, when we tried to send the data from FPGA to AutoMaster we got nothing even though FLAGA indicated data available and it was low after the some clock cycles.

When using the two kits to transfer 8 bytes from Slave to Master, the timing diagram shows 6 clock cycles and then SLRD goes high which is correct: 2 + 8/2 = 6 cycles. Please check out the attached Master_Slave.png for details.

However, when using our FPGA to transfer 8 bytes to Master, the timing diagram shows 1024 clock cycle reads even if FLAGA goes low after 10 clock cycles (only 8 words in the FIFO) the Master is still trying to read and the PC program read 0 byte. Please see the attached Master_FPGA.png for the timing diagram.

Anybody knows what is going on here and how to solve the problem?

[YashwantK_46]

Hi,

->Can you please probe the FLAGC as well in both cases?

   There is significance of FLAGC in case of AutoMaster state machine.

->Also, do you have the FX3 and the FPGA on the same board?

->Can you please tell what the buffer size are you using?

Also, can you please state the changes that you have done on the master firmware?

Regards,

Yashwant

[LeDe_2880731]

Hi Yashwant,

Thank you for the answers. I am traveling right now so I will check FLAG_C next week when I am back to my office.

To answer your questions:

->Also, do you have the FX3 and the FPGA on the same board?

Answer: No, they are on the separate boards and interconnected with the header connector.

->Can you please tell what the buffer size are you using?

Answer: I was using the following code to set the In size in Windows app before the FPGA has data but it doesn't seem to work:

long totalTransferSize = 6; // epBulkIn->MaxPktSize * PACKETS_PER_TRANSFER;

epBulkIn->SetXferSize(totalTransferSize);

The SLRD asserts when the data is available in FPGA and FX3 read clock is 1024. Then the Windows software reads the data with the following code:

long BytesXferred = epBulkIn->XferData(buffersInput, totalTransferSize, FALSE);

totalTransferSize is 6 also but BytesXferred = 0;

->Also, can you please state the changes that you have done on the master firmware?

Answer: I didn't change anything on the firmware.

Thanks again and best regards,

Lee

[LeDe_2880731]

Hi Yashwant,

I didn't find any information about FLAGC in AN87216 but I found the inconsistency about FLAGA and FLAGB.

On page 5:

FLAGA/FLAGB

FX3 flag outputs. These can be programmed in FX3 to indicate various slave states. In this application FLAGA

is configured to indicate the availability of data on the slave side and FLAGB is configured to indicate the

availability of a free buffer on the slave side.

On page 7:

A read burst transfer is shown in the second half of Figure 5. For burst mode, the SLRD# and the SLOE# are left

asserted during the duration of the read. When the SLOE# is first asserted, the data bus is driven (with data from the

previously addressed FIFO). For each subsequent rising edge of PCLK, while the SLRD# is asserted, the FIFO

pointer is incremented and the next data value is placed on the data bus. In the Figure 3 example, the retrieved FIFO

word is the last word in the FIFO, indicated by the FLAGB signal indicating “empty”.

Is the last sentence a typo?

Thanks,

Lee Deng

[YashwantK_46]

Hi Lee Deng,

Thanks for bringing this to our notice. I have informed the respective authority to update the application note and correct it.

The last sentence is a typing mistake and FLAGA is supposed to be there instead of FLAGB.

Can you please provide the probing graphs as requested soon?
FLAGC is to be taken into consideration and should be probe for a better insight to help solve the issue.

Regards,

Yashwant

[LeDe_2880731]

Hi Yashwant,

Thank you for the quick reply.

As I mentioned earlier, I am using the Master Interface to transfer data with our FPGA as the Slave described in AN87216 "Designing a GPIF™ II Master Interface". There is no FLAGC in this application note. So we don't know which pin is FLAGC.

We checked the application note AN65974 "Designing with the EZ-USB® FX3™ Slave FIFO Interface" and found GPIO23 is FLAGC but it is FLAGB in application note AN87216 so we are confused and do not know which pin to probe. Please give us some advice.

Thanks,

Lee Deng

[YashwantK_46]

Hey Lee Deng,

Please probe GPIO_25 as it is FLAGC in both the cases, you can check the GPIF state machines and get an idea of all the GPIO's used and which ones to probe for FLAGs.

GPIO_21 - FLAGA

GPIO_23 - FLAGB

GPIO_25 - FLAGC

Regards,

Yashwant

[LeDe_2880731]

Hi Yashwant,

Thank you very much for the tip. We probed FLAGC and found the following diagram:

It seems that FLAGC indicates no more data in FIFO when it is high, just similar to FLAGA. However, it starts low before FLAGA goes high as shown below:

At what condition should FLAGC be high? I will check AN65974 to see any description and implement FLAGC in our FPGA design.

Thanks again and best regards,

Lee Deng

[LeDe_2880731]

Updates!

GPIF II state machine for the Master shows that the rising edge of FLAGC makes the state go to RD_SHORT_PKT. From the signal diagram we can see that FLAGA and FLAGC change the state at almost the same time so we tried to use FLAGA instead of FLAGC to indicate the short packet:

We changed the condition

!ADDR_CNT_HIT&FLAG_C

to:

!ADDR_CNT_HIT&!FLAG_A

And it works just well. We will try with our FPGA and will update the results later.

Question:

Why did the Master state machine check FLAGA instead of FLAGC originally?

Thanks,

Lee

[YashwantK_46 · Accepted solution]

Hi Lee,

The master state machine is supposed to check FLAGA from the start because FLAGA indicates that Thread_1_DMA_Ready which indicates that either the slave has some data and the master should accept it or the slave is ready to accept data from the master. This operation depends on the THREAD being used and the producer and consumer in the setup.

Whereas, FLAGC is supposed to be the watermark value, which indicates exactly how many bytes of the master can read from or write to the slave. FLAGC is defined in the firmware and after it is asserted the slave only read/ write the exact number of bytes specified.

Hope this helps.

Regards,

Yashwant

[LeDe_2880731]

Hi Yashwant,

Thank you for the reply and the explanation. Now we use FLAGA to indicate the short packet and our design works just fine. The following timing diagram shows the termination of SLRD:

Thank you for all the support. I may come back with a different problem for our design but for now you can close the case.

Best regards,

Lee