Фоновая подсветка HDMI-FPGA-LED. Часть 3: Парсинг TMDS

Блог им. Perfer
В статье:
  • Платы от SeeedStudio.com полученные еще летом;
  • Поверхностное описание алгоритмов приема/передачи HDMI/DVI видео-потока на FPGA семейства Spartan 6;
  • Некоторые подробности реализации DDC и EDID;
  • Первые результаты работы устройства.

Платы от SeeedStudio.com

Долгожданные печатные платы от SeeedStudio были получены 19.07.2013 — прошло ровно 2 месяца с момента заказа. Качество плат достойное, непротравов не замечено, следы от электроконтроля присутствуют на каждой плате. Расстраивает качество шелкографии — после спирта с зубной щеткой, шелкография частично стирается.

После запайки всех компонент и устранения основных недочетов в разводке, устройство выглядит следующим образом:

Страшновато, но не в красоте дело.

Поверхностное описание алгоритмов приема/передачи HDMI/DVI видео-потока на FPGA семейства Spartan 6

Сразу оговорюсь, большинство ниже изложенного про TMDS (Transition-minimized differential signaling) на FPGA это выдержки AppNote от Xilinx о которых упоминалось в первой части, а также стандартов/спецификаций «Digital Visual Interfase Revision 1.0» и «High-Definition Multimedia Interface Specification Version 1.3a». Все (без исключения) стандарты/спецификации которые упоминаются в статье замечательно googl-ятся и за просмотр никто денег не просит.

Передатчик

На вход блока передатчика TMDS сигналов поступают стандартный набор видео сигналов RGB888, HSYNC и VSYNC генерируемый согласно спецификация VESA и аудио сигналы HDMI AUX. Далее эти сигналы попадают на энкодер выполняющий 8b/10b кодирование. Назначение это кодирование — избавление от постоянной составляющей в сигнале и возможность определение ошибок передачи, в общем повышается помехозащищенность. Видео кадр имеет сложную структуру, поэтому работа энкодера на каждой части кадра происходит по разному. При передачи активной области кадра на вход энкодера поступают 8 битные RGB, при передачи не активной области (Data Island) все усложняется:

10-битный сигнал с выхода энкодера поступает на первую ступень сериализации (3x Gear Box), где из 10 битного параллельного кода превращается в 5 битный последовательно-параллельный. Данное преобразование выполняется для встроенных в Spartan 6 аппаратных 5/1 сериализаторов (I/O Logical), которые управляют встроенными в Spartan 6 дифференциальными передатчиками TMDS сигналов (I/O Electrical).

Приемник

Как видно схема приемника несколько сложнее схемы передатчика. Основное отличие — необходимость подстройки фазы PCLKx10 и определения начала байта (пакета) данных поступающих на вход десериализаторов. Подстройка осуществляется изменением времени задержки блоков IODELAY2. Данные с выходов десериализаторов попадают на вход gearbox, где преобразуется в 10 битный параллельный код из 5 битного. Затем, в блоке Clock and Data Recovery, реализуется функционал, исключающий ошибки выбора начала блока данных в параллельном коде (на входе десериализаторов). Так как данные с десериализаторов каждого из каналов могут поступать не одновременно, а декодеру это «не очень нравится», применяют блок Chanal Deskew выравнивающий момент появления данных на входе декодера. Декодер выполняет обратное преобразование 8b/10b.
На этом тему приема и передачи TMDS сигналов можно считать закрытой. Напомню что HDMI/DVI это не только TMDS сигналы, но еще CEC (Consumer Electronics Control) и DDC.

DDC и EDID

DDC (Display Data Channel) — это протокол передачи информации между монитором (или иным устройством отображения) и графическим адаптером.
Реализаций DDC несколько: DDC1, DDC2B, DDC2AB, DDC2Bi, E-DDC и DDC/CI (подробнее здесь Display Data Channel (wiki)). В основе большинства реализаций лежит протокол I2C. Наибольшее распространение получили реализации E-DDC и DDC/CI. Вот сравнительная табличка стянутая из VESA-вского стандарта «Display Data Channel Command Interface Standard Version 1.1 October 29, 2004»

Как видно, основное отличие E-DDC от DDC/CI в том, что последний поддерживает команды MCCS (Monitor Control Command Set) управления изображением на дисплее (под командами здесь подразумеваются различные коррекции цвета, размеров, положения изображения и др.), а E-DDC — нет.
Для имитация подключения монитора в HDMI-разъем видеокарты, достаточно реализации передачи EDID (Extended display identification data), поэтому рассматривается реализация DDC2B, подразумевающая использование адреса 0xA0 без поддержки команд управления (MCCS). Иными словами, будет реализованно I2C-slave device с 256 байт памяти на борту. Протокол обмен из стандарта один в один повторяет протокол Serial EEPROM, например AT24C16.
За основу дизайна I2C-slave был взят код модуля i2c_squash_edid.v проекта NeTV. Модуль состоит из трех конечных автоматов: два анти-дребезга для сигналов SCL/SDA, и один — обеспечивает логику I2C-slave.
EDID — это те заветные 256 байт которые будут передаваться по DDC2B. Структура EDID хорошо описана в wikipedia, но мне было откровенно лень формировать эту структуру в ручную. Есть ряд программ позволяющий получить содержимое EDID подключенного монитора в Windows, например MonInfo, чем я и воспользовался. Стянув EDID из MonInfo в скорректированный модуль i2c_squash_edid.v и залив все это добро на FPGA, видеокарта распознала в моей платке монитор и начала активно слать TMDS сигналы.

Результаты

После получение текущего значения цвета пикселя от модуля приемника TMDS сигналов, необходимо расcчитать среднее арифметическое значение цвета в заданной области. Задание области осуществляется через USB-RS232 от ПК. Дизайн расчета среднего значения цвета базируется на работе блоков DSP48s и двух BlockRAM по 9Kb, для одной компоненты цвета.
Результаты расчета среднего цвета передаются на вход модуля передатчика TMDS сигналов (вывод на светодиоды пока не реализован).
Собрав все выше описанное вместе, получилось следующее:

Размазанная цветная полоска в верхней части экрана, это и есть результат работа алгоритма усреднения, количество зон — 50. В алгоритме обрабатывается каждый пиксель заданной области, на каждом кадре изображения. Видео-ряд The Arctic Light от TSO Photography

15 комментариев

avatar
Поздравления! Уже виден свет в конце туннеля!

Кстати, а что насчет DRM? Оно по умолчанию не работает или отключается?
avatar
Спасибо!
Источник пытается несколько раз опросить приемник на возможность приема шифрованного контента, если не удачно — то шифрование не используется (все передается как в стандарте записано), а при попытки передачи контента требующего шифрование потока формируется сообщение о невозможности такой передачи.
На данный момент прием/передача шифрованного контента у меня не реализованы
avatar
Уважаемый автор, ваш пост вызвал в мине странные чуйства!..

В кои-то веки мне захотелось собрать чужую самоделку, вместо того чтоб купить готовую конструкцию. =)
Поэтому, будьте так добры — продолжайте! Должна получиться действительно стоящая и интересная вещь.

теперь, на правах флуда, риторический вопрос о необходимости перехвата трафика
Когда-то обсуждали вот такую загогулину: автономное устройство, снабжено примитивнейшей оптикой, r-g-b фильтром и тремя фотодиодами. Устройство «смотрит» на фрагмент экрана и пытается «повторить» его цвет. Естественно, нужно несколько таких устройств на один телевизор.

Ща попытаюсь изобразить это убожество на бумажке:



Минусы: торчащие «рога» сенсоров на передней панели телевизора; наверняка низкокачественное воспроизведение цвета; мало зон усреднения.
avatar
Можно присоединить камеру к anroid mini pc и поставить снизу перед телевизором — это легче будет, чем делать 150 фотодиодов. Но всё равно в такой системе будут сильно искажаться цвета из-за разного освещения в комнате.
avatar
Ниже автор пишет, что это коммерческий проект; зря я так возрадовался.
avatar
Кстати недавно вышел Prismatik для Android — lightpack.tv — работает отлично; по этому поводу оперативно собрал себе типа lightpack, но на SPI ленте.
avatar
Поделитесь пожалуйста своими планами по устройству! Откроете исходники или собираетесь делать коммерческий проект? Если да, то в каком виде (готовое/киты)?
avatar
Исходники на время разработки 100% будут закрыты. В дальнейшем, видится коммерческий проект в виде готового устройства.
Даже примерные сроки релиза не определены.
avatar
Поспешите, Lightpack 2.0 HDMI pass throught обещают в марте 2014 production ready, и финансирование на покупку HDMI/HDCP лицензии у них есть, www.slideshare.net/OlgaPerova/lightpack-summary p.26
avatar
Да они вначале отмазывались что там все запатентовано, что дорого стоить будет. На само деле сделать не могли. Сейчас наверное нашли хорошего инженера и у него получилось. Но были уже готовые разработки 2 года назад подобного устройства, ищите APTILIGHT.
avatar
На цифровой ленте сразу делай, сейчас она подешевела и работать с ней легко и удобно.
avatar
Тут человек пошел другим путём: воткнул в raspberry pi Hdmi спиттер и плату hdmi2av:
www.youtube.com/watch?v=tRDAzJrfZiM
avatar
avatar
Нет, не мое :)
PS Большое спасибо за ссылку! Правда времени на проект почти не остается
avatar
Начало нравится. Осталось «дотянуть» гибкое зонирование (что там кстати насчет различных разрешений по входу?), усреднение, вывод на ленту и вменяемый интерфейс настроек/управления.
«Коммерческий проект» говорите? Лады! Лишь бы «времени» хватило, Удачи!
… перекинуть вход на выход конечно задача, но не великая. Дальше будет серьезнее. Повторюсь — Удачи!
С Ув.
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.