В проекте с 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 попадает в обход всего кристалла. И квартус на него ругается, что вот тут-то я точно весь джиттер соберу. А на практике - идеальная картинка, ничего не дрожит, все линии четкие.

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

А вы горизонтальные поля бланкинга не забыли увеличить на эти 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 - выходом.

Я некоторое время участвовал в разработке контроллеров 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 на всю невидимую область (что теоретически бы сделало передачу информации о бланкинге ненужной) - я тоже не встречал.

DmitryR
Я вот не участвовал в разработке контроллеров для мониторов, поэтому не возьмусь отвечать за их содержимое. Я могу лишь поделиться опытом, что получается, если взять ПЛИС и выдать развертку на типовой TFT-монитор. Так вот, автоподстройка не может настроиться на правильное отображение картинки, если pixel clock не попадает немного в рекомендованные значения. При этом диапазон регулировок (ручных) самого монитора раз в 20 перекрывает исходную ошибку. Например, разница между 182.5 и 185.25 дает ошибку в 2.5 пикселя при строке в 1920 пикселей, а диапазон регулировок - от -50 до 50 пикселей. Как это объяснить?

Я это объясняю тем, что TFT-монитор имеет ограниченный набор синтезатора частот для pixel clock. И не всегда этот набор может совпасть с той частотой, которая используется видеосистемой. Именно в этом случае никакой автоподстройкой не добиться того, что моя активная область даст ровно столько же пикселей, сколько есть в матрице. И в итоге получается нечеткая картинка. А ведь суть автоподстройки в мониторе именно в том, чтобы выровнять картину и фазы пикселей на экране именно в тех условиях, когда видеосистема выдает их с некоторыми отклонениями от тех параметров, которые ожидаются по GTF.

Что касается уровней, то тут Вы и вовсе, как мне кажется, вводите людей в заблуждение. Вот нарыл интересный документ:
http://www.epanorama.net/links/videosignal.html
Главным образом, он интересен там, что там кратко и по сути есть про все видеосистемы, как компьютерные, так и телевизионные. Так вот:
1) Для систем компьютерного отображения используется покомпонентная передача цветов R, G, B уровнями от 0 до 0.7В. Синхронизация при этом бывает трех типов: HSYNC + VSYNC, Composite SYNC, Sync on green. Насколько я понимаю, VGA - это именно отдельные HSYNC + VSYNC, поэтому никаких там подставок в зеленом компоненте нет вообще. Сейчас специально взял и осциллографом посмотрел развертку обычного компа на VGA, совершенно одинаковый размах для всех компонент, плюс никаких подмесов HSYNC в зеленый. Возможно, есть мониторы, которые умеют работать и по Sync on Green (помимо основной HSYNC + VSYNC), но это их собственные фичи, не являющиеся обязательными для всех видеосистем. И не надо людей запутывать.
2) Что касается подставки в зеленом, то она именно для добавления синхронизации и нужна в композитном сигнале. Никакой бланкинг она не маркирует. Вот взгляните на таблицу 9 стр. 18 в даташите на ADV7123. Там вообще идентичны данные выходов для Black level и blank level. То есть, попросту говоря, бланкинг - это не "чернее черного", а просто обычный черный. А вот SYNC - это настоящий 0В, который действительно ниже уровня черного. Но это и есть собственно композитный сигнал уже, а вовсе не обычный VGA.
3) И вообще пример с ADV7123 неудачный. В даташите нет ни одного упоминания, как применять этот чип для разверки VESA и VGA, зато есть упоминание стандартов RS-170 и RS-343A, которые для телевидения, а не для VGA-мониторов. Да, из него тоже можно сделать VGA уровни, но это будет другая схема, нежели приведенная в рисунке 28, с тремя BNC выходами на монитор и композитным зеленым.

zombi
Да все у Вас нормально будет, нет там никаких подставок на VGA. Все сигналы от 0В (черный) до 0.7В(белый). Конечно, резисторный ЦАП будет не так хорош, как настоящий, но выглядеть будет похоже.

Вообще, в развертке VGA как таковой ничего сложного нет. Подключил ЦАП, который тянет нагрузку в 37.5 ом, сделал hsync и vsync, и все дела. Немного сложнее с таймингами, поскольку для каждого режима есть рекомендованный pixel clock, и нужно так выбрать базовую частоту, чтобы можно было с помощью PLL в ПЛИС получить частоты для всех нужных режимов. Либо просто поставить внешний синтезатор таких частот, но это место и дополнительные затраты.

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

Еще раз говорю, я думаю что у вас что-то еще было неправильно настроено. Если же при всех остальных идентичных настройках 182.5MHz работает, а 182.25MHz - нет, то я бы попробовал на паре мониторов других моделей, потому что это очень странно.


То есть если на монитор сразу после смены видеорежима подать картинку с широкой черной каемкой (или вообще черный экран), он по идее должен принять ее за бланкинг (раз черный и бланкинг в видеосигнале не отличаются) и не смочь установить синхронизацию?


Может он и неудачный, но он стоял на ките FPGA, и поэтому его решили применять, и все работало. И описал я про уровни ровно то, что написано в его даташите, поэтому говорить, что я ввожу кого-то в заблуждение можно только если вы найдете существенные отличия в моей интерпретации от того, что написано в том документе.

Не мучайтесь http://www.xilinx.com/support/documentatio...o_Interface.pdf
На Atlys все работает замечательно. Есть ограничение по максимальному формату в 1280х720 - но это ограничение FPGA (частота выходных сигналов)

На других мониторах не пробовали. Точнее, пробовали уже после того, как выбрали 182.5, поэтому детально сравнениями уже не занимались.
Кстати говоря, моя догадка о дискретности выбора pixel clock в мониторе косвенно подтверждается в стандарте VESA:

То есть, это именно некий программируемый синтезатор частоты, а не PLL, умножающая частоту Hsync на произвольное целое. Единственное, что мне не до конца понятно: ведь 182.5 и 182.25 отличаются как раз ровно на 0.25, о которых речь в стандарте. И стало быть, монитор должен был бы подобрать такую частоту точно. Видимо, либо там сделали синтезатор с меньшим шагом, не кратным 0.25, скажем 1/6 МГц, либо банально где-то накосячили с самим алгоритмом автоподстройки.



Вы будете смеяться, но примерно так и есть. Конечно, мониторы имеют защиту от явных глупостей, но при желании их можно обмануть.
1) Мониторы уже давно (еще со времен ЭЛТ) запоминают параметры синхронизации и ассоциируют с ними конкретные параметры развертки. Поэтому просто переключить видеорежим уже недостаточно, монитор вспомнит, что он такой уже видал, и загрузит вполне сносные параметры. Чтобы его задурить, нужно либо включить режим с новыми параметрами, либо вручную позвать автокалибровку.
2) Если видеорежим новый для монитора, то он может либо посчитать (используя формулы стандарта) параметры развертки, измерив параметры hsync и vsync, а может еще и вдобавок запустить автокалибровку.
3) Автокалибровка в принципе может слишком сильно наврать, если экран черный, поэтому в алгоритмах проверки параметров, полученных с ее помощью, может стоять проверка, не слишком ли сильно они отклонились от того, что должно бы по GTF (или CVTS). Именно это может удержать монитор от глупостей при черном экране, что в целом редко, скажем для Windows.
4) Если же автокалибровка запускается в условиях, когда картинка имеет небольшую окантовку черным цветом, например, такую, размеры которой вполне укладываются в диапазон ручной регулировки, то вот тогда автокалибровка вполне может оттяпать все черные пиксели и остальные растянуть на весь экран. Кстати, не далее как сегодня наблюдал такое. При загрузке тестового компа подключил диск без ОС, и на экране была серая на черном надпись с предложением заменить загрузочный носитель и нажать любую клавишу. Надпись была во второй и третьей текстовых строках экрана. После автокалибровки надпись переехала наверх и влево. После загрузки нортона верхняя строка была не видна, повторная автокалибровка все поставила на свои места.

Все это говорит о том, что монитор не отличает черного в отображаемой области, от черного в неотображаемой. Другое дело, что есть стандарт GTF и CVTS, который связывает размеры экрана с характеристиками HSYNC и VSYNC, и поэтому какой-то видеорежим установить монитор сможет всегда. Читать видеоданные и искать там бланки ему для этого не нужно.




Попробую еще раз объяснить. ЦАП ADV7123 - универсальный, он может выдавать картинку в нескольких режимах, а именно: в режиме VGA и в режиме с подставкой в зеленом. При этом про композитный вариант с подставкой (sync on green) там даны примеры, а про VGA не даны. Но по табличке 9 можно с нескольких попыток углядеть, что если удерживать входы BLANK#=1 и SYNC#=0, то он не будет выдавать никакого смещения в зеленом. Именно это и будет режим обычного VGA. Поэтому утверждение про подставку:

лишь вводит людей в заблуждение. Нету в VGA никакого бланкирования, "чернее черного" и т.п. В телевизионных стандартах - есть, а в VGA - нету.

100%. Постоянно с этим сталкиваюсь. И сильно раздражает необходимость перезапускать автокалибровку на изображении без боковых чёрных областей.

Очень маленький " pixel clock Jitter". Пробовал изменять частоту синхросерий внутренней DLL\PLL ПЛИСа
Xilinx, Lattice - из-за джиттера LCD-дисплей или совсем не включался, или изображение получалось нестабильное.
Правда, сигнал был для DVI. Но синхросигналы аналоговые - они что цифровые.