cancel
Showing results for 
Search instead for 
Did you mean: 

USB Superspeed Peripherals

mcn
New Contributor II

I 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 anything for one clock cycle each DMA buffer, which is a 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? If the latter, is there a workaround?

2) Is there documentation available about the waveform states 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!

0 Likes
1 Solution
Rashi_Vatsa
Moderator
Moderator

Hello,

Unfortunately, we do not have a workaround. As mentioned earlier, when calling DR_DATA in a state the GPIF thread needs to be set before it can be accessed. So, the GPIF II Designer tool mandates to add the extra state.

Regards,
Rashi

View solution in original post

0 Likes
5 Replies
Rashi_Vatsa
Moderator
Moderator

Hello,

Please find my comments below:

1) Is this a bug in GPIF Designer or in the GPIF state machine? If the former, can we get a fix? If the latter, is there a workaround?

>> It is not possible to directly switch between the states in which DR_DATA is called without using STATE 9 and STATE 10 in between them. This is a limitation of GPIF II Designer tool.  Unfortunately, we do not have an update of the GPIF II Designer tool.

Regards,
Rashi
0 Likes
mcn
New Contributor II

Hi Rashi,

Is documentation available for the waveforms (under NDA is fine if necessary) so I can work around this issue? 

Alternatively, is there a process to request a bug fix? Or the source code to GPIF Designer to fix it ourselves?

Thanks!

0 Likes
Rashi_Vatsa
Moderator
Moderator

Hello,

It is not a bug but when calling DR_DATA in a state the GPIF thread needs to be set before it can be accessed. The extra state (state 9 & 10) is used to set the GPIF thread that will be used for driving the data in the next/consecutive state. Hence, the GPIF Designer tool mandates to use the extra state while switching the threads and using DR_DATA

Regards,
Rashi
0 Likes
mcn
New Contributor II

Hi Rashi,

So you're saying there is no way, even with a hand-constructed waveform, for the Cypress to continuously DR_DATA without missing a clock cycle each DMA buffer? Is this not a bug in the FX3 silicon state machine then? Are there any possible workarounds?

Thanks for looking into this!

0 Likes
Rashi_Vatsa
Moderator
Moderator

Hello,

Unfortunately, we do not have a workaround. As mentioned earlier, when calling DR_DATA in a state the GPIF thread needs to be set before it can be accessed. So, the GPIF II Designer tool mandates to add the extra state.

Regards,
Rashi

View solution in original post

0 Likes