Является ли ПЛИС жизнеспособной для такого проекта?

В настоящее время я работаю над Super OSD - проектом на экране. http://code.google.com/p/super-osd содержит все подробности.

На данный момент я использую MCU dsPIC для выполнения этой работы. Это очень мощный DSP (40 MIPS при 80 МГц, трехканальные одноцикловые операции и блок MAC), и, что немаловажно, он поставляется в DIP-пакете (потому что я использую макет для его прототипирования). Я действительно получаю все до последней части производительности, используя OSD - чип имеет около 200 нс или 10 циклов на пиксель на этапе вывода, поэтому код должен быть очень оптимизирован в этой части (по этой причине он всегда будет записываться в сборка.)

Теперь я рассматривал возможность использования FPGA для этого, потому что из-за параллельной архитектуры такого чипа возможно иметь простую логическую программу, работающую на OSD. Такие вещи, как рисование линий и алгоритмический код, будут обрабатываться MCU, но фактический вывод будет сделан с помощью FPGA. И некоторые простые вещи, такие как установка пикселей или рисование горизонтальных и вертикальных линий, которые я хотел бы интегрировать в FPGA, чтобы улучшить скорость.

У меня есть несколько вопросов:

1. Это будет стоить значительно больше? Самые дешевые ПЛИС, которые я нашел, составляли ~ 5 фунтов стерлингов каждая, а dsPIC - 3 фунта стерлингов каждый. Так это будет стоить дороже, но на сколько?
2. DsPIC помещается в корпус SO28. Я не хотел бы идти больше, чем SO28 или TQFP44. Большинство FPGA, которые я видел, поставляются в пакетах BGA или TQFP> 100, которые на данный момент недоступны из-за размера ножниц и сложности их пайки самостоятельно.
3. Какой ток используется ПЛИС? В настоящее время решение dsPIC потребляет около 55 мА +/- 10 мА, что на данный момент нормально. Будет ли FPGA потреблять больше или меньше? Это переменная или она в значительной степени статична, как dsPIC?
4. Мне нужно как минимум 12 КБ графической памяти для хранения графики OSD. Есть ли у FPGA этот вид памяти, доступный на чипе, или это доступно только с внешними чипами?

В принципе, это хороший кандидат на проектирование на основе FPGA. Относительно ваших требований:

Объявление 1. Скорее всего, ПЛИС будет дороже, в зависимости от того, какое устройство вы выберете. На первый взгляд самого маленького спартанца 3 от Xilinx (XC3S50AN) будет более чем достаточно для этой задачи (~ 10 £ от Farnell). Я думаю, вы можете предположить, что это верхний предел стоимости (он имеет оперативную память 56 КБ, так что это больше, чем нужно). Вы можете найти более дешевое устройство либо у Xilinx, либо у конкурентов Altera и Lattice.

объявление 2. Пакет - сложная проблема, я не видел FPGA с меньшей площадью. Однако, возможно, вы можете использовать устройство CPLD (ради аргумента, CPLD - маленькие FPGA), которые могут быть в меньшем пакете (PLCC или QFN). С положительной стороны они будут дешевле (даже один доллар), с отрицательной стороны, скорее всего, не будет оперативной памяти внутри. С CPLD, вероятно, вам понадобится внешний чип SRAM.

Объявление 3. Ток потребления ПЛИС и CPLD сильно зависит от запрограммированного дизайна. Однако есть большая вероятность, что FPGA и особенно CPLD дизайн будет потреблять меньше, чем ваше текущее решение.

объявление 4. FPGA имеет такую ​​память внутри, CPLD, скорее всего, нет. Это может быть решено с помощью внешнего чипа Sram (или двух). Например:

| SRAM 1 | <-> | CPLD | <-> | uC |
| SRAM 2 | <->

В таком случае, когда ОК записывает в SRAM 1, CPLD будет отображать данные из SRAM 2. CPLD должен иметь возможность обрабатывать обе задачи одновременно.

Конечно, вы можете решить эту проблему и другими способами:
1) использовать более быстрый uController (например, ARM)
2) использовать устройство с некоторой программируемой матрицей и внутренним интерфейсом (например, FPSLIC от Atmel, однако я никогда не использовал такие устройства и знаю очень немного о тех)

Стандартный отказ от ответственности -> так как проекты - это открытые проблемы, со многими ограничениями и возможными решениями, что бы я ни писал выше, это может не соответствовать вашему случаю. Я считаю, что стоит проверить этот вариант, хотя.

Вы можете использовать CPLD, а не FPGA, например, одну из частей Altera MAX II. Они доступны в пакетах QFP44, в отличие от FPGA. На самом деле это небольшие FPGA, но Altera преуменьшает этот аспект. У CPLD есть преимущество перед большинством FPGA в том, что они имеют встроенную конфигурационную память, FPGA обычно требуют внешней флеш-микросхемы. Конечно, есть и другие CPLD, но мне нравится MAX II.

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

FPGA обычно имеют ограниченный объем встроенной памяти, которую вы можете использовать, но вам потребуется внешняя память с CPLD.

Другим вариантом будет чип XMOS , но самый маленький (XS1-L1) находится в пакете QFP64. Он имеет много встроенной оперативной памяти - 64 КБ.

1) Да, ПЛИС будет дороже. Мало того, что сам чип дороже, но вам также понадобится флэш-память для хранения программ. FPGA + Flash, вероятно, в 3 раза дороже, чем просто dsPIC ... около 10 долларов для маленькой FPGA и 3 доллара для маленькой Flash.

2) Они могут существовать, но я не знаю ни одной FPGA, которая бы не монтировалась на поверхности. Большинство из них, вероятно, QFP или BGA.

3) FPGA, вероятно, будет втягивать примерно в 3 раза больше тока, чем dsPIC, но это может увеличиваться или уменьшаться в зависимости от того, какие функции вы используете. FPGA имеют много функций, которые могут увеличить потребление энергии. Но ожидайте не менее 150 мА.

4) FPGA обычно имеют внутри себя блочную оперативную память. Все, кроме самых маленьких ПЛИС, должны иметь столько памяти.

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

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

Программирование FPGA / CPLD в VHDL / Verilog - довольно крутая кривая обучения, исходящая из C для многих людей. Они также не слишком дешевые запчасти.

Используя прилично способный ARM, может быть, LPC1769? (Cortex-M3), вы также можете заменить PIC18 в своем дизайне.

Что касается проблемы со сквозным отверстием, пока вы можете получить SoC в пакете с открытым контактом типа QFP, просто возьмите некоторые из этих адаптеров для нужного вывода для вашего прототипа.

Я бы хотел использовать что-то для буферизации времени между процессором и дисплеем. Наличие оборудования, которое может показывать весь кадр видео без вмешательства процессора, может быть хорошим, но, возможно, излишним. Я бы предположил, что лучшим компромиссом между аппаратной и программной сложностью, вероятно, было бы создание чего-то с двумя или тремя независимыми 1024-битными сдвиговыми регистрами (два бита на пиксель, чтобы обеспечить черный, белый, серый или прозрачный) и средством переключения между ними. Пусть PIC загрузит сдвиговый регистр, а затем заставит аппарат начать сдвигать его, пока он устанавливает флаг, чтобы PIC мог загрузить следующий. С двумя сдвиговыми регистрами у PIC было бы 64us между временем, когда было сказано, что сдвиговый регистр доступен, и временем, когда все данные должны быть сдвинуты. С тремя сменными регистрами,

Обратите внимание, что хотя 1024-битный FIFO будет так же хорош, как два 1024-битных сдвиговых регистра, а в CPLD FIFO стоит только одну макросоту на бит, плюс некоторая логика управления, в большинстве других типов логики два бита сдвигового регистра будет дешевле, чем один бит FIFO.

Альтернативный подход заключается в подключении CPLD к SRAM и создании простой видеоподсистемы с этим. Эстетически мне нравится генерация видео «на лету», и если кто-то сделает хорошие дешевые 1024-битные микросхемы сдвигового регистра, я бы предпочел этот подход, но использование внешней SRAM может быть дешевле, чем использование FPGA с достаточным количеством ресурсов для сделать несколько 1024-битных сдвиговых регистров. Для вашего выходного разрешения необходимо будет синхронизировать данные со скоростью 12 Мбит / с или 3 МБ / с. Должна быть возможность упорядочить вещи так, чтобы обеспечить синхронизацию данных со скоростью до 10 Мбит / с без особых затруднений путем чередования циклов памяти; самая большая хитрость была бы в том, чтобы предотвратить повреждение данных, если импульс синхронизации не приходит в ожидаемый момент.