Чи FPGA життєздатний для такого проекту?

Зараз я працюю над Super OSD - проектом на екрані. http://code.google.com/p/super-osd містить усі деталі.

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

Тепер я розглядав можливість використання для цього FPGA, оскільки завдяки паралельній архітектурі такої мікросхеми можливо мати просту логічну програму, що працює під управлінням OSD. Такі речі, як малювання ліній та алгоритмічний код, обробляються MCU, але фактичний вихід буде виконаний за допомогою FPGA. І деякі прості речі, такі як встановлення пікселів або малювання горизонтальних і вертикальних ліній, я б хотів інтегрувати в FPGA, щоб підвищити швидкість.

У мене є кілька питань:

1. Буде коштувати значно дорожче? Найдешевші FPGA, які я знайшов, складали ~ 5 фунтів стерлінгів, а dsPIC - 3 фунта. Так це обійдеться дорожче, але на скільки?
2. DsPIC вписується в пакет SO28. Мені не хотілося б перевищувати SO28 або TQFP44. Більшість FPGA, які я бачив, поставляються у пакунках BGA або TQFP> 100, які на даний момент не є можливим через розмір зсуву та труднощі їх пайки самостійно.
3. Скільки струму використовує FPGA? Наразі розчин dsPIC споживає близько 55mA +/- 10mA, що на даний момент нормально. Чи спожив би FPGA більше чи менше? Він мінливий, або він майже статичний, як dsPIC?
4. Мені потрібно щонайменше 12 КБ графічної пам'яті, щоб зберігати екранну графіку. Чи є у FPGA такий тип пам'яті доступний на мікросхемі чи це лише у зовнішніх мікросхем?

В принципі, це хороший кандидат на базі FPGA-дизайну. Щодо ваших вимог:

ad 1. FPGA, швидше за все, буде дорожчим, на скільки це залежить від обраного вами пристрою. На перший погляд найменшого спартанця 3 від Xilinx (XC3S50AN) буде більше, ніж для цього завдання (~ 10 фунтів від Farnell). Я думаю, ви можете припустити, що це верхня межа вартості (у неї всередині оперативної пам’яті 56 кБ, тому це більше, ніж вам потрібно). Ви можете знайти дешевший пристрій або від Xilinx, які пропонують, або від конкурентів "Альтера" та "Решітка".

ad 2. Пакет є непростим питанням, я також не бачив FPGA з меншим розміром. Однак, можливо, ви можете використовувати пристрій CPLD (заради аргументу CPLD - це невеликі FPGA), які можуть бути в меншому пакеті (PLCC або QFN). З іншого боку, вони будуть дешевшими (навіть один долар) на негативній стороні, швидше за все, не будуть мати оперативної пам'яті всередині. З CPLD, ймовірно, вам знадобиться зовнішній чіп SRAM.

ad 3. FPGA та споживання струму CPLD сильно залежать від запрограмованої конструкції. Однак є хороший шанс, що FPGA і особливо CPLD дизайн буде споживати менше, ніж ваше поточне рішення.

ad 4. У FPGA є такий тип пам'яті всередині, CPLD, звичайно, ні. Це може вирішити зовнішня мікросхема sram (або два). Наприклад:

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

У такому розташуванні, поки UC пише в SRAM 1, CPLD відображатиме дані з SRAM 2. CPLD повинен мати можливість одночасно обробляти обидва завдання.

Звичайно, ви можете вирішити це і іншими способами:
1) використовувати швидший uController (наприклад, ARM)
2) використовувати пристрій з деякою програмованою тканиною і uC всередині (наприклад, 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-пам'ять. FPGA + Flash, ймовірно, в 3 рази перевищує вартість dsPIC ... приблизно 10 доларів за невелику FPGA і 3 долари для невеликого Flash.

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

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

4) FPGA зазвичай мають блочну оперативну пам'ять всередині них. Усі, крім найменших FPGA, повинні мати стільки пам’яті.

Інші згадують CPLD. Якщо ви ретельно розділите дизайн, ви, ймовірно, зможете перенести деякі невеликі, але дорогі операції в CPLD. Це було б як міні-спільний процесор.

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

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

Використовуючи гідно 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 Мбіт / с без особливих труднощів шляхом перемежування циклів пам'яті; найбільшою хитрістю буде запобігання пошкодженню даних, якщо імпульс синхронізації не настане в очікуваний точний момент.