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

А что такое валидность?
Вообще, если посмотреть по картинке, с авалоном будто бы всё в порядке, пакеты выдаются/принимаются как положено, ерроры в нулях. Битые данные на выходе могут быть от нарушения целостности данных на входном порту. А провалы source_valid это нормально.
А что на входе fftpts?

Под валидностью я имею в виду source valid. Да в том то и дело, что с авалоном вроде всё в порядке, но данные коверкаются. Входные данные одинаковые в обеих случаях, на входе корки проверял - целостность не нарушена. Да и при большем интервале между пакетами всё хорошо строит. Провал source valid был бы нормальным, если бы общая длина пакета была бы N точек, а у меня N + расстояние между пакетами. fftpts out тоже корректное.

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

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

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

На картинке в user guid нарисована ситуация, когда всё работает и с меньшими интервалами между макетами, чем N, поэтому предполагал что она будет нормально работать. Да и обычно подобные состояния, когда новые данные могут повредить старые, запрещаются интерфейсом, например можно было бы повесить сигнал busy, который бы запрещал запись. Сброс врятли бы помог, т.к. source valid опускался немного позже, чем начинали повреждаться данные. Самое простое, что можно предпринять, это подавать данные с достаточным интервалом