Continuous FX3 GPIF Write doesn't work (GPIF Designer bug? GPIF State Machine bug?)

[mcn]

I have a need to write synchronously to a DAC. No samples can be skipped. This requires multiple threads ping-ponging, just as it does on reading. However...

According to https://community.cypress.com/t5/USB-Superspeed-Peripherals/GPFI-II-question/m-p/84212 there is a bug in GPIF Designer which requires an extra state to be inserted between driving on thread0 and driving on thread1. Without this extra state, GPIF Designer reports:

"'Thread Number' in action 'DR_DATA' of state-'WRITE_TH1' need to be same as 'Thread number' of action 'DR_DATA0' in state 'WRITE_TH0'"

This extra state causes the GPIF to not write a sample every DMA buffer, which is a huge problem.

So, questions:

1) Is this a bug in GPIF Designer or in the GPIF state machine? If the former, can we get a fix? That bug was pointed out more than 6 years ago and prevents synchronous continuous write from working at all. If the latter, is there a workaround?

2) Is there documentation available about the waveform states (alpha, beta, lambda) so I can work around the GPIF Designer bug and write my own state machine? I've tried reverse engineering the bits, but don't want to burn days investigating something which may never work.

I've attached two images--the first is the state machine I want, but GPIF Designer will not let me have. The second is the state machine I can get, but does not work due to the skipped GPIF driving samples.

Thanks for the help!

[Ajeethkumar_P · Accepted solution]

Hello,

Greetings! Attached is the firmware for continuous uninterrupted data transfer. The project has been tested with the SyncSlaveFIFO example project and a modified version of the streamer host application (the only modification was that it prefilled the buffers to a specific pattern(linear data) that I then observed on the oscilloscope). I am also attaching the Saleae logs which show the continuous data transfer which was tested on Win10 with the attached Streamer app and CYUSB3KIT-003.

In the attached project, GPIO17 will be driven high(at every rising edge of PCLK) when there is a data transfer, and GPIO18 will be driven high when there is a Wait state. In the continuous data transfer Saleae log(attached), when GPIO18 is toggled, you can see the DQ0(Least significant bit of the linear data) toggle which clearly shows the continuous data transfer.

In order to generate this project we have made a project with one clock cycle delay which has 2 states (W0 and W1) that are wait states and do not drive data but drive a GPIO for verification. We then patched the generated header file so that data is still driven out in these states.

Figure 1: Without Patching

Figure2: With Patching

The patching was done as follows:
W0 is state 4 and it uses the CyFxGpifWavedataPosition[4] = 3rd row in CyFxGpifWavedata as waveform data. This row is as follows:
{{0x1E739405,0x04000400,0x80000040},{0x00000000,0x00000000,0x00000000}}
Here, the first 96bits are for the left waveform and the next 96 are for the right. These are loaded into the LEFT_WAVEFORM and RIGHT_WAVEFORM registers.
And in that, bits 45:38 (or bits 13:6 of the second 32-bit word) represent the left alpha outputs. These are 00010000 indicating a GPIO is being driven but not the outputs. This is changed to 00010011 so that data is driven out. The row is hence changed to
{{0x1E739405,0x040004C0,0x80000040},{0x00000000,0x00000000,0x00000000}}

The same changes are done to the W1 state.

For more details about the GPIF block, please refer to the FX3 Technical Reference Manual.

GPIF hardware have two kinds of outputs.
(1)"Alphas" are driven as soon as the state transitions.
(2)"Betas" are driven out when the new state is loaded.
Thread switching signal is beta which caused a delay of 1 cycle in your project.

Please note the following for your information:
1. The state machine has very rudimentary flow control built in. This is to ensure uninterrupted data transfer
2. A consequence of the above point is that the firmware must not introduce any delays in data transfers at all. So, we used an AUTO channel and very large buffers (32KB per buffer; 4 buffers).
3. If the host stopped streaming, the state machine will drain out all available data and will wait in the "WAIT" state. During this process, there may be a few underruns. This is printed out in the PIB Error Callback. As long as too many underruns don't occur, the firmware will work as expected.
4. If you're modifying the state machine to suit your needs, please have the same structure we've given. And you'll need to modify the header after each generation.

Thanks,
Ajeeth