AlexZabr 0 17 декабря, 2007 Опубликовано 17 декабря, 2007 · Жалоба Я пока не могу похвастаться солидным опытом в 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 0 17 декабря, 2007 Опубликовано 17 декабря, 2007 · Жалоба Добрый день! Мне приходилось заниматься похожей разработкой (аппаратный дециматор VGA-сигнала). Обращаю внимание на 2 подв. камня: 1 Надо точно определиться с используемыми в работе мониторами и разрешениями 2 0чень желательно поиметь где-нить стандарт на RGB (нам его за бесплатно найти не удалось), поэтому пришлось работать по ходу дела додумывая временнЫе диаграммы:( В качестве памяти использовали SRAM (до DDR руки не дошли). Если что могу поделиться схемным решением, хотя там ничего особенного нет. Проект под ПЛИС был сыроват и более-менее корректным получился (по причине указанных выше проблем) только для разрешения 1024x768. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexZabr 0 17 декабря, 2007 Опубликовано 17 декабря, 2007 · Жалоба Добрый день! Мне приходилось заниматься похожей разработкой (аппаратный дециматор 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 0 17 декабря, 2007 Опубликовано 17 декабря, 2007 · Жалоба А как вы гнали 1024х768 на стандартный телевизор ? Там ведь только PAL/NTSC (ну или SECAM у вас что в принципе близко к PALу).. А на ТВ мы и не выводили, работали исключительно с дисплеями в формате VGA (RGB как по входу так и по выходу)... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexZabr 0 17 декабря, 2007 Опубликовано 17 декабря, 2007 · Жалоба А как вы гнали 1024х768 на стандартный телевизор ? Там ведь только PAL/NTSC (ну или SECAM у вас что в принципе близко к PALу).. А на ТВ мы и не выводили, работали исключительно с дисплеями в формате VGA (RGB как по входу так и по выходу)... Аа, понял. Кстати, дисплеи они тоже interlaced или progressive ? Если вам нужно было делать interlacing, делали ли вы это с буфером внешней памяти на пол-фрейма (одно поле) ? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
eugen_pcad_ru 0 18 декабря, 2007 Опубликовано 18 декабря, 2007 · Жалоба Уточню: делали что-то типа цифрового зума (из входного сигнала 1024х768 выдергивался фрагмент фрейма, пропорционально увеличивается и транслируется на другой монитор тоже в виде 1024х768). В память заносили поочередно (чет-нечет, т.е. два банка) фрагменты фрейма. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexZabr 0 18 декабря, 2007 Опубликовано 18 декабря, 2007 · Жалоба Уточню: делали что-то типа цифрового зума (из входного сигнала 1024х768 выдергивался фрагмент фрейма, пропорционально увеличивается и транслируется на другой монитор тоже в виде 1024х768). В память заносили поочередно (чет-нечет, т.е. два банка) фрагменты фрейма. Понял. Значит делали на выход interlace, но работали с памятью на полный фрейм (т.е. оба поля заносили в память и читали соответственно). Я думаю мне хватит памяти на пол фрейма, т.е. хранить одно поле.. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
