Согласование 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ем ?)

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