Доброго времени суток. По работе возникла следующая проблема. Дали реализованный на TMS алгоритм с целью переноса его на ПЛИС XILINX XC5VSX50T.
Суть в следующем: обрабатываются блоки по 32768 отсчетов; каждый такой блок подвергается некому подобию циклической свертки с ПСП на такое же кол-во отсчетов. Почему подобию? Потому, что выполняется суммирование произведений не всех 32к отсчетов, а каждых 64, затем суммы складываются. Как мне объяснили, это необходимо для борьбы с набегом фазы.
Реализация сдвигового регистра с отводами на такое кол-во отсчетов требует большого объема затрачиваемых ресурсов, поэтому сам циклический сдвиг реализован на блочной памяти. Частоты позволяют повторное использование одних и тех же блоков, поэтому в каждой ячейке памяти хранится одно 512-битное слово. На первой итерации последовательно считываются все 64 таких слова и затем обрабатываются по правилу описанному выше. Кроме того, в специальный регистр заносится предыдущее считанное слово. Т.о. на следующей итерации, которая подразумевает уже циклический сдвиг всей 32к-битной последовательности на 1 бит, выбираются 512-1 бит текущего слова и 1 бит хранящегося в регистре. Для получения нужного блока из 512 бит требуется разместить "крест-накрест". В итоге на эту операцию уходит такое кол-во LUTs, что их просто не хватает.
Если кто-то сталкивался с чем-то подобным или знает, как этого можно избежать, пожалуйста, отпишитесь. Заранее извиняюсь за возможно сбивчивое или неточное описание.

Рекомендую опубликовать код, который управляет хранением, выборкой и сдвигом данных. И сообщить, какая скорость потока данных. На первый взгляд, тут требуется LUTов совсем чуть-чуть.

Код, к сожалению, сейчас на только на работе. Входные данные поступают с частотой 1.23 МГц, clk = 120 МГц. Хранение и выборка данных - два массива блочной памяти (из одного считываются данные для обработки, в другую в это время пишутся отсчеты, затем они меняются местами), адресация по счетчикам. Проблемное место именно в сдвиге.
-- вектор-указатель, изначально заполнен единичками, на каждой итерации сдвиг:

аналогично формируются еще 3 компоненты, т.к. при перемножении 2-х квадратурных сигналов получаются 4 компоненты.

Без полного кода не вполне понятно, но, похоже, сдвиг вы выполняете через мультиплексирование 512 по (512 в 1), так, конечно, никаких лутов не хватит. Возможно, это следствие прямого переноса алгоритма из Си.

Да что-то такое и получается, судя по RTL-схеме. Да, алгоритм сишный, его использовали на TMS, но потребовалось уменьшить время его выполнения. Просто алгоритм обкатанный, попросили реализовать именно его, естесственно распараллеливая выполнение.
А что вы можете порекомендовать исправить? Хотя бы в общих словах.

Я рекомендую почитать про архитектуру разных КИХ фильтров на FPGA. На эту тему вроде есть аппноты у Альтеры и Ксайлинкса, или ещё можно нагуглить много всякой всячины, у меня в своё время не было с этим проблем. Ваш фильтр, вроде, похож на обычный КИХ фильтр, и можно использовать похожую архитектуру с некоторыми нюансами.

Для начала нужно два блока памяти: в один по кольцу пишутся данные в другом ROM с константами. Вам придется сделать их 8-ми ассоциативными. И на второе автомат выборки и перемножения с накоплением. Вроде все.

Можно чуть подробнее, не очень понятна идея.

Corner все правильно советует
Через двух портовую память. Поток входных данных пишется циклически через один порт, а через второй порт читаете по нужным адресам и обрабатываете данные. Если в двух словах. По ресурсам займет копейки.