В проекте с FPGA еще осталась ресурсы. Появилось желание вывести графику на TFT через VGA (D-Sub) или DVI-D (HDCP), т.е. связать напрямую FPGA и монитор TFT.

Вопросы к тем, кто уже прошел по этой дороге и возвращается назад:
1. Что и где почитать про протоколы и физику процессов на уровне сигналов?
2. VGA или DVI-D, что предпочтительнее и проще в реализации?
3. Есть ли готовые примеры реализации, программы и схемы?
4. Какие здесь есть тонкости, узости и прочие подводности?

Заранее спасибо за обстоятельные ответы.

информации на эту тему достаточно, от простой http://www.fpga4fun.com/PongGame.html
до расширеной http://opencores.org/project,vga_lcd

Добрый день.
В принципе задача не очень сложная, необходимо только где-то найти место для видеопамяти - внутри кристалла или за его пределами.
Удачи.

Вот еще:
http://www.marsohod.org/index.php/projects/172-phframe1
http://www.marsohod.org/index.php/projects/173-phframe2
http://www.marsohod.org/index.php/projects/174-phframe3

Вообще много зависит от того, какого формата графика интересует. полноценная реализация VGA на современных мониторах с большим разрешением потребует хорошего VideoDAC. Я некоторое время назад выбрал THS8200 от TI. Немного заморочисто настраивался, но в итоге получил картинку 1920x1080x60Hz. Что касается аналогового вывода, то тут крайне важно в точности соблюдать тайминги GTF и держать стабильный pixel clock, иначе линии на TFT дрожать начинают. Встраиваемые панели TFT имеют простые цифровые интерфейсы, которые практически без дополнительной логики можно соединять с FPGA. Цифровой вывод дает гарантии от дребезга пикселей, при этом скорости там вполне умеренные, а ширина шины не больше, чем те же RGB для video dac. Так что Вы подумайте, стоит ли осваивать VGA. C DVI не работал, поэтому ничего тут не скажу. В свое время только проглядывал стандарт TMDS, но на ПЛИС не примерял. насколько помню, он там был на основе 3.3V LVDS, так что как минимум нужны будут дополнительные драйверы.

Ув. 'Hoodwin' можете подсказать какой максимально допустимый "Jitter pixel clock", к примеру, VGA 800x600 60Hz для TFT монитора ? И есть ли вообще такой параметр?

Так дело даже не в джиттере как таковом. Дело в том, что например, 1920 на 1923 нацело не делится. А именно это и происходит, когда временных характеристики hsync не позволяют монитору выбрать правильный pixel clock для оцифровки входа. Например, вот есть такой калькулятор в сети http://www.epanorama.net/faq/vga2rgb/calc.html.
С его помощью можно получить, что для HD pixel clock - 182.5 MHz. Я специально подключил к PLL3 в Циклоне, которая тактируетм у меня видео-ЦАП, два генератора, на 27 и 48 МГц, потому что большинство стандартных VESA режимов - как раз на основе 27 МГц. А для HD из 27 МГц можно сделать было с помощью встроенной PLL только 182.25 МГц. Казалось бы - фигня, ошибка в 3 пикселя из почти двух тысяч, монитор автоподстройкой поправит. А он не поправил, а в тестовой сетке появились нечеткие вертикальные линии с подрагиванием. Ладно, взял тогда клок на 25 МГц, который приходит от DSP и питает совсем другую PLL1, и в PLL3 попадает в обход всего кристалла. И квартус на него ругается, что вот тут-то я точно весь джиттер соберу. А на практике - идеальная картинка, ничего не дрожит, все линии четкие.

Так что: джиттер - это конечно плохо, но он проявится только если ошибка в тактовых частотах вашего ЦАП и АЦП в мониторе будет больше, чем, где-нибудь, пол-пикселя на всю строку. Во всех остальных случаях автоподстройка в мониторе решит вопрос. Если, конечно, не понаделать косяков с питанием и правильно соединить земли монитора с землей видео-ЦАП. Но это обычно проявляется не на уровне дрожания отдельных вертикалей, а просто по картинке ползет всякий шум мелкий вверх или вниз.

Сообщение отредактировал Hoodwin - Jan 26 2012, 06:36

А вы горизонтальные поля бланкинга не забыли увеличить на эти 3 пиксела? Если вы выдавали 1923 пиксела под data enable - ни один монитор не исправит.

Ну дело все в том, что VGA - это аналоговый интерфейс. Он вообще не содержит понятия пиксель. Когда я подключаю к ПЛИС внешний DAC, то естественно, посылаю туда данные как-бы попиксельно, но количество пикселей может быть произвольной величиной. Монитор видит только аналоговые сигналы RGB, как он узнает, сколько пикселей в них? Я так понимаю, что частично проблему решили путем стандартизации частоты и скважности импульсов hsync и vsync, зафиксировав размеры полей вокруг картинки, предназначавшихся ранее для обратного хода луча. Так вот, современный ЖК-монитор может оцифровывать мой сигнал на разных частотах. Вопрос: как он узнает на какой частоте ему оцифровывать сигнал? Возможно, он определяет параметры HSYNC, по которым рассчитывает параметры начала и конца отображаемой зоны, а потом выбирает частоту оцифровки равной время отображения / число точек в матрице. А возможно, он просто пытается по параметрам сигналов синхронизации выбрать параметры по таблице. И скорее всего именно так и делает, учитывая возможности юстировки. Но если так, то все упирается в набор тех частот, которыми располагает опорный генератор в мониторе. Если он сможет выбрать чатоту, совпадающую с моей, то он увидит строку длиной ровно 1920 пикселей, а если они разъедутся, то часть пикселей не влезет, а на часть будет выглядеть нечетко.

Если речь идет об аналоговом сигнале - пиксельная частота извлекается из HSYNC, подбором делителя PLL таким образом, чтобы активная область соответствовала какому-то видеорежиму. Если вы посылаете в активной области 1923 точки - PLL на приемнике частоту подберет так, чтобы активная область сигнала поделилась на 1920, так как это ближайший известный ему режим. А так как аналоговый сигнал будет менятся 1923 раза за это время - в некоторых местах будет непопадание точка-в-точку и описываемый вами эффект дрожания.

У VideoDAC есть сигнал, DE (data enable). Вы, формируя сигнал, должны при активном DE послать ровно 1920 точек, а оставшиеся точки строки (бланкинг) - при неактивном DE. Точки, которые вы ему дали при неактивном DE VideoDAC отправит с уровнями RGB "чернее черного" (черный цвет в активной области соответствует уже ненулевому напряжению), и приемник поймет, что это неактивная область.

Вы снова меня не поняли. Я всегда посылаю ровно 1920 точек, но у меня цап работал вначале на частоте 182.25 МГц, а не 182.5. Современные мониторы умеют подстраивать свою частоту оцифровки таким образом, что активная область может у них превратиться, к примеру, и в 1923 точки, и в 1917. Но попасть ровно в 1920 точек они не могут (при выводе на 182.25 Мгц). В результате появляются вышеописанные эффекты, но они связаны с джиттером косвенно. А вот если я выведу свои 1920 точек на частоте 182.5 МГц, то они могут оцифровать активную зону ровно в 1920 точек. И даже больший джиттер не приводит к дрожанию пикселей.

В целом это такая же точно проблема, как бывает с baud rate генераторами в UART на разных концах. Просто точности гораздо выше нужны.

Что касается всяких там DE, то у THS8200, о котором я писал, таких сигналов нет. В VGA вообще нет уровней "чернее черного", все уровни начинаются просто от черного до белого. (см. например http://microvga.com/faq/electrical/what-ar...-voltage-levels)
В тех режимах, где действительно такие уровни есть, он их делает автоматически, сам выступая мастером и запрашивая данные у видеоконтроллера. В задачу контроллера входит только в правильное время данные свои вставлять относительно hsync, который для него в этом режиме является входом, а для ths8200 - выходом.

Сообщение отредактировал Hoodwin - Jan 26 2012, 14:20

Я некоторое время участвовал в разработке контроллеров Genesis, которые стоят в том числе и в современных мониторах, и могу сказать: они любое число могут использовать. В частности, отдельные микрухи ADC для выделения синхронизации берут период HSYNC и умножают его на произвольное целое число (чтобы в активной области было, в данном случае, 1920 точек). Они не знают и даже не думают о том, что там должно получиться 182.5MHz.


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


Там зато есть HS_Delay, HS_Duration и Total_Pixel в конфигурации. DE=Current_pixel_number<(Total_pixel-HS_Delay-HS_Duration).


Есть, в зеленом канале. Ранее эта подставка использовалась еще и для синхронизации, сейчас - только чтобы бланкинг маркировать. См. ADV7123 например, на его примере это все лучше понятно. Там и бланкинг отдельным входом, и рисунки есть, как он делается.

Ув. DmitryR, а может ли отсутствие этой самой подставки у зелёного влиять на общее качество изображения или сихронизацию TFT мониторов?
У меня после fpga просто резисторный цап и никаких подставок нет.

В сорцах LEON3 (GRLIB) от Gaisler есть пример реализации VGA.

Я вам честно скажу - сам строить схемы, которые бы формировали VGA сигнал я не пробовал. Я пользовался микросхемами, которые это делают (теми же ADV), разбирался как именно и почему именно так ими надо управлять, на основании этого опыта пишу. Синхронизацией по зеленому мониторы уже давно не пользуются, так как она идет по отдельным линиям, а бланкинг передать в VGA я не вижу другого способа, кроме как в зеленом канале. Такого, чтобы в видеосигнале не было бланкинга, а был строб HSYNC на всю невидимую область (что теоретически бы сделало передачу информации о бланкинге ненужной) - я тоже не встречал.