Согласование 2х дисплеев по таймингу - размер FIFO, 2 дисплея с разным таймингом должны показывать один сигнал.. Опции

[Саша Z]

Буду благодарен за советы более опытных FPGAщиков/"алгоритмистов" нежели я.
Итак, есть 2 дисплея, оба резолюцией 320х240, оба работают по RGB по входу, получают стандартные syncs (VSYNC, HSYNC, DV (Data Valid)) и pixel clock. Источник сего видео - некая система.
Первый дисплей получает видео в формате serial RGB, т.е. R->G->B передаются побайтно один за другим (точнее слово - 6 бит), значит для строки в 320 пикселей имеем 960 pixel clocks полезной инфы.
Формат кадров - progressive, 50 fps и это справедливо для обоих дисплеев.
Задача - принять данный вход в FPGA и переоформить его для вывода на второй дисплей входной формат которого: parallel RGB (18 bit) + Syncs.
Понятно, что по входу в FPGA идет блок который форматирует данные ис сериального RGB в параллельный (т.е. каждые 3 входных слова в 6 бит каждое дает одно слово в 18 бит) с выходным pixel clock который есть входной деленный на 3.

Проблема: pixel rate (clock) первого дислея - немного более 20 MHz, т.е. кроме тех 960 клоков видео даты в каждий строке идут еще примерно 700 клоков dummy (активная область данных на те 320 пикселей строки вырезается сигналом DV), т.е. межды двумя соседними HSYNC у него примерно 1660 клоков.
Кроме того, в каждом полном кадре имеем минимум 255 строк (можно больше, скажем 262), тогда как только 240 из них - активное видео, остальные - пустые.
Итого, в каждом кадре имеем (примерно) 1660х255 = 423300 клоков. Проверяя себя в расчет на 50 кадров в секунду: 423300х50 = 21.165 MHz как и предполагалось, после упаковки по 3 получаем 7.055 MHz (примерно 533 клока в строке)

Второй дисплей работает на частоте примерно 6.3 MHz (typical), тоже 320х240, тоже syncs, но у него в строке кол-во клоков может быть в пределах 360-450 (т.е. dummy клоков в строке может быть от 40 до 130).
Кроме того, кол-во строк в кадре может быть в пределах 251 - 280 (т.е. от 11 до 40 dummy строк).
Значит, его pixel clock может варьироваться в пределах от 360 х 251 х 50 = 4.518 MHz до 450 х 280 х 50 = 6.3 MHz.

Все лишние (dummy) клоки в строке у обоих дисплеев могут располагаться либо в начале строки, либо в конце, либо разбиты ка 2 куска - часть в начале строки часть в конце. Тоже самое с лишними строками в кадре.


Я так понимаю что необходим буфер в виде dual port FIFO с отдельными клоками и управлением записи/считывания. Данные на входе (т.е. те что одновременно идут на первый дисплей) после их форматирование в тройки записываются в буфер по таймингу входа, данные на второй дисплей считываются ис буфера по таймингу второго дисплея. Естественно, в буфер пишуться только вктивное видео, не dummy.
Вопрос, как правильно рассчитать минимально необходимый размер FIFO и тайминг управления разрешением записи/считывания так чтобы удовлетворить обеим дисплеям и избежать overflow/underrun ? Нужно ли играться кол-вом dummy клоков у обеих дисплеев поак не найти подходящее отношение ?
Что посоветуете ?

Спасибо.




Sorry, запостил ветку дважды по ошибке.
Прошу отвечать в первой, модератору: буду благодарем ежели данную ветку уберете.

Спасибо.

[DmitryR]

Размер FIFO будет максимум два кадра, один пишется - предыдущий читается. Однако, в таком случае второй дисплей будет отставать на кадр. Если это приемлемо - тогда все просто, так как кадровая частота одинакова. Если нет - тогде надо делать буфер на несколько строк, писать/читать циклически с небольшим отставанием. В таком случае алгоритм достаточно сложен, так как строчная и пиксельные частоты отличаются из-за различий в размерах бланкинга (то, что вы называете dummy).

[Саша Z]

Размер FIFO будет максимум два кадра, один пишется - предыдущий читается. Однако, в таком случае второй дисплей будет отставать на кадр. Если это приемлемо - тогда все просто, так как кадровая частота одинакова. Если нет - тогде надо делать буфер на несколько строк, писать/читать циклически с небольшим отставанием. В таком случае алгоритм достаточно сложен, так как строчная и пиксельные частоты отличаются из-за различий в размерах бланкинга (то, что вы называете dummy).

Да, согласен, но буферизация целых кадров очень дорога в ресурсах ибо намереваюсь использовать тол-ко внутренние блоки памяти (конфигурированные как dual port FIFO x 18bit). Нужно посараться не занимать слишком много блоков ибо в том-же FPGAе будут еще аппликации которым видимо тоже понадобятся блоки.
Кадровый буфер при раскладке 320х240х18 занимает более 1.3 Mbit что более чем жирно для моих целей... , не говоря уже о 2х кадрах...

Но вот ежели учесть что у первого дисплея можно подогнать кол-во строк в кадре под второй, скажем в обеих будет по 262 строки в кадре, тогда разброс сужается только до разницы в кол-вах клоков в строке - в одном скажем 524 колка (каждый по 18 бит), у второго по 400. Т.е. имеем отношение клоков в 1.31

По прикидакм на коленке, думаю можно согласовать биферизацию по входу и выходу размером на одну строку ежели правильно кноролировать тайминг записи/считывания.
Например, начинаем запись по первому видео слову первого дисплея (по старту его DV). Одновременно с этим, наичнаем пихать те 80 dummy клоков в начале строки второго дисплея. Вследствии разницы rates в 1.31 раза, за время тех 80 клоков второго дисплея, в буфер запишутся 104-105 клоков (пикселей первого). Затем наинается считывание на воторй дисплей. Оставшиеся 216-215 пикселей клоков) первого дисплея записывающиеся в буфер будут отновременно со считыванием 164-165 выходных пикселей. Т.е. когда закончиться запись полных 320 входных пикселей, входной дисплей будет продолжать считывать оставшиеся 155-156 пикселей опустошая буфер. Запись в буфер остановлена по окончании записи вохдной строки (ибо далее у первого дисплея идут 204 dummy клока). Те 155-156 выходных клока занимают время равное 203-204 клока по входу - т.е. почти ровно столько сколько dummy клоков первого диплея. Затем, цикл повторяется. Значит, полный цикл буферизации строки полностью заполняет и опустошает FIFO не приводя к overflow по входу либо к underrun по выходу.
Но тут проблема в точности клоков. Дробное отношение клоков может приветси к потере пикселя там-сям, либо все-таки может быть в overflow/underrun со временем в результате постепенного накопления/опаздывания на 1 пиксель в строке, кроме того jitters по клоку записи и клоку скитывания может тоже осложнить ситуацию (разве что синхронизировать их PLLем ?)

Я ошибаюсь в прикидках ? Буду балгодарен за мнения..

[Liseev]

Работаю исключительно со стандартным телевизионным растром, там все проще, поскольку число полей, строк, кадровые и строчные гашения строго регламентированы. Честно говоря, никогда не имел дела с описанными Вами дисплеями, но подозреваю, что они имеют встроенный кадровый буфер, иначе как объяснить допускаемые варьирования длительностей строчных и кадровых гашений...

Мое мнение: если Вы уравняете строчные частоты у обоих дисплеев, т.е. доведете общее число строк до одного значения (например, до 262), то легко обойдетесь буфером на строку (320 отсчетов). Поскольку пиксельная частота входного потока выше относительно второго дисплея, чтение будет происходить медленнее и его можно начинать практически сразу после начала записи - в этом случае ни overflow ни underrun не произойдет. А учитывая, что строчные частоты равны, чтение строки на выход закончится всяко раньше, чем начнется запись новой строки.

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

Да, вот еще какой момент. Первый дисплей будет работать на тактовой частоте входного потока, насколько я понял, а вот тактовую для второго дисплея Вам придется генерить самостоятельно с применением ФАПЧ, опираясь на входную строчную частоту