Дизайн прошивки ПЛИС: Насколько большой слишком большой?

У меня есть особенно большое преобразование обработки сигналов, которое нужно перенести из matlab в VHDL. Это определенно требует некоторого разделения ресурсов. Немного расчета дал мне следующее:

• 512 ффтов по 64 очка
• 41210 операций многократного добавления

Учитывая, что самая большая FPGA Virtex 6 имеет ~ 2000 блоков DSP48E, я знаю, что могу разделять ресурсы, чтобы повторно использовать ресурсы несколько раз. Время выполнения на самом деле не является проблемой, время обработки может быть относительно длительным с точки зрения FPGA.

Глядя на использование ресурсов, использование архитектуры radix-2 lite дает мне блоки 4dsp / FFT = 2048 блоков DSP, всего ~ 43k. самая большая Virtex FPGA имеет 2 тыс. блоков или 20 операций / мукс.

Очевидно, что включение таких больших муксов в ткань также займет кусочки. Где я могу найти верхний предел этого предела? Я не могу бесконечно делиться ресурсами ПЛИС. Множители 41210 слишком велики? Как рассчитать слишком большой размер?

Я также посмотрел на другие ресурсы (ломтики, Брамс и т. Д.). Radix-2 Lite также дает 4 x 18 тыс. Брэмов / фут = 2048 брэмов. Самая большая FPGA Xilinx содержит 2128 брэмов. очень пограничный Я обеспокоен тем, что мой дизайн слишком велик.

ОБНОВИТЬ:

Еще немного информации о самом дизайне. Я не могу вдаваться в подробности, но вот что я могу дать:

Initial conditions -> 512 ffts -> 40k multipliers ---------|----> output data to host 

                 ^------re-calculate initial conditions----|

спецификация выходных данных: "быстрее, чем симуляция Matlab"

Мудрый расчет, вот где я нахожусь:

БПФ этап: легко. Я могу реализовать 1/2/4/8 БПФ, сохранить результаты в SDRAM и получить доступ позже. Относительно маленький, даже если это займет много времени, все в порядке. используя radix-2 lite, я могу получить 2 DSP48Es и 2 18k BRAMS / FFT. потоковая передача дает 6 DSP48Es 0BRAMS / FFT. в любом случае, 64-разрядное БПФ мало с точки зрения ресурсов ПЛИС.

Множители : это моя проблема. Входные данные умножения берутся либо из справочных таблиц, либо из данных БПФ. Это действительно целая куча многократных добавлений. Там не так много, чтобы оптимизировать. Не фильтр, но имеет характеристики, похожие на фильтр.

Учитывая совместное использование ресурсов в FPGA, математика работает следующим образом: один LUT-6 может использоваться в качестве 4-полосного мультиплексора. Формула для N-way, M bit mux выглядит следующим образом:

N*M/3 = number of luts, or N*M/12 = slices (4 LUTS/slice).

хруст числа для моей реализации не дает хороших результатов. 90% семейства virtix-6 не имеют достаточного количества срезов для совместного использования ресурсов DSP для выполнения операций по 40 тыс.

Интересно, есть ли другой взгляд на проблему?

Воспроизведение вашей оценки 512 операций FFT (64 балла каждая) и 42k операций MAC ... Я полагаю, это то, что вам нужно для одного прохода по алгоритму?

Теперь вы нашли ядро ​​FFT, использующее 4 модуля DSP ... но сколько тактовых циклов требуется для FFT? (пропускная способность, а не задержка)? Скажем, 64 или 1 цикл на очко. Затем вы должны выполнить эти 42 тыс. Операций Mac за 64 цикла - возможно, 1 тыс. MAC за цикл, при этом каждый MAC обрабатывает 42 операции.

Теперь пришло время взглянуть на остальную часть алгоритма более подробно: определить не MAC, а операции более высокого уровня (фильтрация, корреляция и т. Д.), Которые можно использовать повторно. Создайте ядра для каждой из этих операций с возможностью повторного использования (например, фильтры с различными выбираемыми наборами коэффициентов), и вскоре вы сможете обнаружить относительно небольшое количество мультиплексоров между относительно большими ядрами ...

Также возможно ли снижение прочности? У меня были некоторые случаи, когда умножения в циклах требовались для создания квадратиков (и выше). Развернув их, я мог бы итеративно генерировать их без умножения: я был очень доволен собой в тот день, когда я создал разностный движок для FPGA!

Не зная приложения, я не могу дать более подробную информацию, но некоторый такой анализ, вероятно, сделает возможным несколько существенных упрощений.

Кроме того - поскольку это звучит так, как будто вы не имеете в виду определенную платформу - подумайте, можете ли вы разделить на несколько FPGA ... взгляните на эту плату или ту, которая предлагает несколько FPGA на удобной платформе. У них также есть плата со 100 устройствами Spartan-3 ...

(ps я был разочарован, когда парни из софта закрыли этот другой вопрос - я думаю, что по крайней мере там уместно)

Edit: re your edit - я думаю, вы начинаете добираться туда. Если все входы множителя являются либо выходами FFT, либо коэффициентами «без фильтра», вы начинаете видеть вид регулярности, который вам необходимо использовать. Один вход для каждого умножителя подключается к выходу FFT, другой вход для ПЗУ коэффициента (BlockRam реализован как постоянный массив).

Последовательность различных операций БПФ через один и тот же блок БПФ будет автоматически чередовать выходы БПФ после этого умножителя. Последовательность правильных коэффициентов в другом входе MPY теперь «просто» является вопросом организации правильных адресов ПЗУ в правильное время: организационная проблема, а не огромная головная боль MUX.

По производительности: я думаю, что Дейв Твид был излишне пессимистичным - БПФ выполняло n * log (n) операций, но вы можете выбрать O (n) блоков бабочки и O (logN) циклов, или O (logN) единиц и O ( n) циклы или другая комбинация в соответствии с вашими ресурсами и скоростью. Одна такая комбинация может сделать структуру умножения после FFT намного проще, чем другие ...

Если у этой проблемы нет жестких ограничений в реальном времени, и похоже, что ее нет - вы просто хотите, чтобы она работала «быстрее», тогда кажется, что она может быть вполне пригодна для ускорения на одном или нескольких графических процессорах. Есть несколько программных библиотек, которые делают это относительно простым предложением, и это будет примерно на порядок проще, чем переходить прямо к пользовательскому оборудованию ПЛИС.

Просто Google для «библиотеки с GPU» или «библиотеки с GPU-ускорением», чтобы начать.

Можно использовать специализированное аппаратное обеспечение или FPGA (или даже CPLD), чтобы значительно ускорить определенные виды математических операций. Главное, что нужно учитывать при разработке аппаратного обеспечения (схемотехники или логики ПЛИС) для ускорения математических операций, - это выяснить, какие данные о порядке должны поступать в ваше устройство и выходить из него. Устройство с эффективной компоновкой ввода-вывода может предложить гораздо лучшую производительность, чем устройство с неэффективной компоновкой, даже если последнее устройство требует гораздо больше схем.

Я не пробовал разрабатывать аппаратно-вспомогательный дизайн для FFT, но один из тех, на которые я обратил внимание, - это аппаратная помощь для больших операций с несколькими умножениями (которые могут использоваться для шифрования RSA). Многие микроконтроллеры, даже те, которые оснащены специальным оборудованием быстрого умножения, не очень эффективны при таких операциях, потому что они требуют большой перестановки регистров. Аппаратное обеспечение, которое было разработано для минимизации замены регистров, могло бы обеспечить гораздо лучшую производительность с операциями умножения с высокой точностью, даже если само оборудование не было таким сложным. Например, аппаратные средства, которые могут выполнять конвейерное умножение 16xN по два бита за раз (сдвиг на два младших бита умножения и сдвиг двух верхних битов результата), могут достичь лучшей производительности, чем аппаратные средства, которые могут выполнять умножение 8x8 за один цикл, даже если первый может потребовать меньше схем (и благодаря конвейерной обработке иметь более короткий путь передачи критических данных). Ключ в том, чтобы выяснить, как будет выглядеть «внутренний цикл» необходимого кода, и выяснить, есть ли недостатки, которые можно легко устранить.

Насколько мало проблем у нас времени выполнения?

Это действительно похоже на ситуацию, когда вам действительно нужно внедрить программный микроконтроллер, FPGA со встроенным микроконтроллером или даже отдельное устройство MCU и сериализовать все ваши операции.

Предполагая, что у вас есть время выполнения, выполнение ваших БПФ в программном обеспечении будет намного проще в отладке и, вероятно, намного проще в разработке.