- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!
Solved! Go to Solution.
- Labels:
-
USB Superspeed Peripherals
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Rashi