| |
 Потенциальная оценка ресурсов под аппликацию, Нужна помощь в оценке ресурсов для подбора development board |
|
|
|
|
 Dec 17 2007, 09:49
|
Знающий
Группа: Свой
Сообщений: 921
Регистрация: 6-04-07
Из: Israel
Пользователь №: 26 822
|
Я пока не могу похвастаться солидным опытом в 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 будет работать. Посему нет возможности сейчас писать весь код на весь проэкт.
Буду благодарен и за советы общего плана оценки потенциальных ресурсов по конкретные задания.
|
|
|
|
|
|
|
 |
Ответов
(1 - 6)
|
|
Dec 17 2007, 10:45
|
Знающий
Группа: Свой
Сообщений: 642
Регистрация: 15-11-07
Пользователь №: 32 353
|
Добрый день! Мне приходилось заниматься похожей разработкой (аппаратный дециматор VGA-сигнала). Обращаю внимание на 2 подв. камня: 1 Надо точно определиться с используемыми в работе мониторами и разрешениями 2 0чень желательно поиметь где-нить стандарт на RGB (нам его за бесплатно найти не удалось), поэтому пришлось работать по ходу дела додумывая временнЫе диаграммы  В качестве памяти использовали SRAM (до DDR руки не дошли). Если что могу поделиться схемным решением, хотя там ничего особенного нет. Проект под ПЛИС был сыроват и более-менее корректным получился (по причине указанных выше проблем) только для разрешения 1024x768.
--------------------
Правильно сформулированый вопрос содержит в себе половину ответа.
P.S.: Некоторые модераторы в качестве ответа так навязчиво предлагают посетить свой сайт, что иначе как саморекламу такие действия интерпретировать сложно.
|
|
|
|
|
|
|
|
Dec 17 2007, 13:03
|
Знающий
Группа: Свой
Сообщений: 921
Регистрация: 6-04-07
Из: Israel
Пользователь №: 26 822
|
Цитата(eugen_pcad_ru @ Dec 17 2007, 14:45)  Добрый день! Мне приходилось заниматься похожей разработкой (аппаратный дециматор 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у)..
|
|
|
|
|
|
|
|
Dec 17 2007, 16:57
|
Знающий
Группа: Свой
Сообщений: 921
Регистрация: 6-04-07
Из: Israel
Пользователь №: 26 822
|
Цитата(eugen_pcad_ru @ Dec 17 2007, 17:47) А как вы гнали 1024х768 на стандартный телевизор ? Там ведь только PAL/NTSC (ну или SECAM у вас что в принципе близко к PALу)..
А на ТВ мы и не выводили, работали исключительно с дисплеями в формате VGA (RGB как по входу так и по выходу)... Аа, понял. Кстати, дисплеи они тоже interlaced или progressive ? Если вам нужно было делать interlacing, делали ли вы это с буфером внешней памяти на пол-фрейма (одно поле) ?
|
|
|
|
|
|
|
|
Dec 18 2007, 11:00
|
Знающий
Группа: Свой
Сообщений: 921
Регистрация: 6-04-07
Из: Israel
Пользователь №: 26 822
|
Цитата(eugen_pcad_ru @ Dec 18 2007, 11:02) Уточню: делали что-то типа цифрового зума (из входного сигнала 1024х768 выдергивался фрагмент фрейма, пропорционально увеличивается и транслируется на другой монитор тоже в виде 1024х768).
В память заносили поочередно (чет-нечет, т.е. два банка) фрагменты фрейма. Понял. Значит делали на выход interlace, но работали с памятью на полный фрейм (т.е. оба поля заносили в память и читали соответственно). Я думаю мне хватит памяти на пол фрейма, т.е. хранить одно поле..
|
|
|
|
|
|
|
 |
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|
