Баг альтеравской FFT корки, Странное поведение в режиме Variable streaming Опции

[R6L-025]

Всем доброго времени суток! Столкнулся с проблемой- при генерации FFT корки (пробовал в версиях Quartus 11-13) в режиме Variable streaming и представлении данных типа floating point, появляется интересная вещь:
при интервале между входными пакетами меньшем, чем длина самого пакета, первый выходной пакет имеет нормальный вид, а дальше все пакеты идут повреждёнными. На линии source valid появляется провал длительностью в один такт, на расстоянии от начала пакета равному интервалу между пакетами. После такого провала, линия valid поднимается в '1' и держится так ещё N тактов, где N - число точек преобразования. Дальнейшие пакеты имеют нормальную валидность, но битые данные. Если расстояние больше чем N, то всё хорошо.
На форуме Altera толком ничего не нашёл. Кто либо сталкивался с таким поведением корки?

Эскизы прикрепленных изображений

 

[R6L-025]

Разрешилась проблема. Оказалось действительно дело в корке. Такое поведение будет наблюдаться при включённом режиме natural order, при типе данных floating point . При выходе из бабочки порядок битов отличен от прямого, для исправления ситуации в корке есть отдельный блок. В нём входной пакет как есть записывается в память, а потом считывается в определённом порядке, восстанавливая прямой порядок отсчётов. Я в описании к корке заметок на этот счёт не нашёл, но если подавать новые данные раньше, чем через N тактов, записанный в буфер пакет не успевает обработаться, и поверх него начинает перезаписываться новый + сам генератор адреса записи/чтения написан так, что при непредвиденном валиде он начинает выдавать неправильный адрес.
В качестве решения я создал 2 отдельных компонента блока перестановки, а для разрешения порядка их работы - арбитр. Правда платить за это пришлось более большим размером буфера - вместо 2N теперь 4N 32 битных слов. Хотя , я думаю, можно прицепить и внешнюю память, тут обработка уже выходных данных и доп. задержка не должна сказаться на результате.

[Tiro]

Разрешилась проблема. Оказалось действительно дело в корке.

Скорее в ее использовании.

Я в описании к корке заметок на этот счёт не нашёл, но если подавать новые данные раньше, чем через N тактов, записанный в буфер пакет не успевает обработаться, и поверх него начинает перезаписываться новый + сам генератор адреса записи/чтения написан так, что при непредвиденном валиде он начинает выдавать неправильный адрес.

А какое поведение Вы предполагали? Запрет записи новых данных? Сброс результата? Возможно, Вам помогло бы просто сбросить все внутренние данные или саму корку FFT при опускании source valid. Просто любопытно, что можно предпринять в подобной ситуации.