Потенциальная оценка ресурсов под аппликацию, Нужна помощь в оценке ресурсов для подбора development board Опции

[Саша Z]

Я пока не могу похвастаться солидным опытом в FPGA, пока заканчиваю определенный маленький дизайн.
Планируется в обозримом будущем расширение фунциональности дизайна, посему ссоти вопрос о покупке evaluаtion/development system с конкретным FPGAем который позволить в дальнейшем расширение функциональности.
Работаем в Lattice, посему и система от Lattice.

Вследствии отсутствия пока более-менее серьезного опыта, буду благодарен за подсказки насчет оценки будущих ресурсов под проэкт, соответственно приципы подбора FPGAев под оценочные ресурсы (ну и соотв. его evaluation/development board).

Итак, на данный момент имплементирован data driver на LCD дисплей, получающий последовательный поток RGB данный с видео синхронизацией и т.д. и преобразующий это в 18 бит параллельный RGB поток с соответствующей синхронизацией (syncs, etc..). Кроме того имплементирован генератор синтетического изображения (RGB поля) который моделирует последовательный RGB поток с синхронизацией вместо реального входа и может подсоединяться к data driver для проверки последнего.
Кроме того на данный момент нужно добавить I2C core ибо нужен setup LCD/controllerа. Пока не в курсе сколько ресурсов он может занять.

В Альтере Cyclone все это заняло мизер ресурсов (менее 1% каждого вида ресурсов судя по репорту синтезатора).

То что планируется в обозримом будущем:
Конвертация того-же входного RGB потока в TV PAL сигнал на вход видео encoderа в формате CCIR656.
Дле сего нужна следующая цепочка flow:
1. Гамма корекция входного RGB потока - имплементируется с помощью LUTа на 64 значения (6 бит на sample цвета). Входное данное (6 бит) используется как адрес LUTа из которого вытаскивается корректирование значение данного.
2. Конвертация в 4:2:2 CbYCr поток - согласно известным уравнениям (каждое значение Y, Cb, Cr вычисляется на основе полного R, G, B пикселя). Входной фрейм: 320х240, progressive. Значит если на входе идет поток в 960х240 байт, в 4:2:2 получаем 640х240 (2 байта на пиксель)
3. Интерполяция на VGA (640х480). Интерполяция делается как bicubic на Y и наверно nearest на цвет (Cb, Cr). В результате получаем объем active video данных на фрейм: 1280х480 байт. Затем "оборачиваем" active video а пиксели черного поля (окантовка) в целях подгонки полного фрейма под стандартный PAL размер (и/или NTSC). Получаем что-то типа 720х525 (или строчки чуть длинее - не помню, проверю в стандарте) на NTSC либо 858х625 на PAL. В формате 4:2:2 YCrCb получаем примерно
1072500 байт на полный фрейм (PAL, для NTSC - меньше). Половину из него нужно хранить в внешней памяти (буфер) в целях interlacingа. В выходной поток вставляются коды синхронизации по мере надобности.
4. Interlacing + video synchronization coding. Тут видимо не обойтись без внешней памяти как буфер размером в поле (пол фрейма для interlacingа). В выходной поток вставляются коды синхронизации по мере надобности.


Вот нужно понять какого объема FPGA чип подойдет и соответственно под него покупать development board. Нужно понять на каком этапе и сколько нужно внутренней памяти (например для этапов 1, 2, 3) и т.д. и т.п.

Ессно, многие посоветуют вначале написать код под все, затем по результатам синтезатора прикинуть ресурсы и подходящие девайсы, но тут есть проблема. Проблема в том что на данный момент нужно имплементировать только первую часть (LCD driver), все что казается канала TV - в посследствии, после того как LCD будет работать. Посему нет возможности сейчас писать весь код на весь проэкт.

Буду благодарен и за советы общего плана оценки потенциальных ресурсов по конкретные задания.

[eugen_pcad_ru]

Добрый день!
Мне приходилось заниматься похожей разработкой (аппаратный дециматор VGA-сигнала).
Обращаю внимание на 2 подв. камня:
1 Надо точно определиться с используемыми в работе мониторами и разрешениями
2 0чень желательно поиметь где-нить стандарт на RGB (нам его за бесплатно найти не удалось), поэтому пришлось работать по ходу дела додумывая временнЫе диаграммы
В качестве памяти использовали SRAM (до DDR руки не дошли).
Если что могу поделиться схемным решением, хотя там ничего особенного нет.
Проект под ПЛИС был сыроват и более-менее корректным получился (по причине указанных выше проблем) только для разрешения 1024x768.

[Саша Z]

Добрый день!
Мне приходилось заниматься похожей разработкой (аппаратный дециматор VGA-сигнала).
Обращаю внимание на 2 подв. камня:
1 Надо точно определиться с используемыми в работе мониторами и разрешениями
2 0чень желательно поиметь где-нить стандарт на RGB (нам его за бесплатно найти не удалось), поэтому пришлось работать по ходу дела додумывая временнЫе диаграммы
В качестве памяти использовали SRAM (до DDR руки не дошли).
Если что могу поделиться схемным решением, хотя там ничего особенного нет.
Проект под ПЛИС был сыроват и более-менее корректным получился (по причине указанных выше проблем) только для разрешения 1024x768.

Спасибо, понял.
Насчет входа RGB - тут все понянто и просто - есть готовая система которая гонит наружу RGB на OLED дисплей. Есть все данные этого дисплея, включая его timing diagrams и т.д., я свой код синтетической картинки подгонял под него, т.е. генератор выдает data и синхронизацию идентичную этому OLEDу.

Насчет выходных разрешений - тут наверно определимся на PAL ибо он больше по объему data, а значит при надобности можно будет потом переделать в NTSC.
Думаю тоже остановиться на SRAM ввиду более простой имплементации да и кол-ва единичные, посему выжимание последнего цента конечного продукта не актуально.

Спасибо за предложение схемы - я с видео работал, и с TV стандартами тоже, так что тут все понятно, но все равно спасибо.

А как вы гнали 1024х768 на стандартный телевизор ? Там ведь только PAL/NTSC (ну или SECAM у вас что в принципе близко к PALу)..

[eugen_pcad_ru]

А как вы гнали 1024х768 на стандартный телевизор ? Там ведь только PAL/NTSC (ну или SECAM у вас что в принципе близко к PALу)..
[/quote]
А на ТВ мы и не выводили, работали исключительно с дисплеями в формате VGA (RGB как по входу так и по выходу)...