Буду благодарен за советы более опытных 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, запостил ветку дважды по ошибке.
Прошу отвечать в первой, модератору: буду благодарем ежели данную ветку уберете.

Спасибо.

Размер 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ем ?)

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

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

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

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

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

Спасибо, звучит обнадеживающе..
Дать кол-во срок одинаковое для обоих дисплеев - реально, думаю так и сделаю. Скажем 262 строки в кадре. В таком случае, начиная считывание почти сразу после начала записи, считывание действительно окончится до начала записи новой строки. Однако, промежуток между видео датой соседних сртрок второго дисплея (dummy clocks in line) тоже регламентированно, и скажем равно 80.
Это делает привязку таймингов записи/считывания более жесткой...
Я так понимаю (опустошение) буфера должно завершиться точно за 80 выходных клоков до начала считывания след. строки, т.е. за менее чем 80х1.31=105 клоков записи (если 1.31 есть отношение частоты клока входа к выходному).
Или я чего-то недопонял ?

насчте самих дисплеев - тут к счастью все не сложно - оба управляются исключительно внешними syncs как и говоирл ранее, что им давать, то они и едят, только придерживаться рамок тайминга syncs и т.д. как в их datasheet. Она они не имеют буфера, либо он прозрачен для внешнего инерфейса.

Сорри за глупый вопрос, что такое ФАПЧ ? честно говоря я не очень знаком с русскоязычными терминами..

Нам это не важно, главное "скармливать" дисплею 320х240 пикселей 50 раз в секунду, там он сам разберется...


ФАПЧ = Фазовая АвтоПодстройка Частоты = PLL

Тут у нас такая история получается: частота кадров у обоих дисплеев одна = 50 кадров в сек.
Частоту строк мы делаем тоже одну = 262 строки на кадр = 13,1 КГц
Длительность строки одинаковая = 76,33... мкс
Разница только в тактовой частоте и, соответственно в количестве отсчетов - как активных, так и тех, которые в гашении (dummy). Для первого дисплея эта частота (и кол-во отсчетов) задается источником видеопотока. Для второго дисплея мы должны сами сформировать эту частоту таким образом, чтобы в строку (76,33... мкс) "вписывалось" ровное число отсчетов, причем это число должно быть постоянно стабильным, иначе рано или поздно получится "разбежка" и все наши старания пойдут насмарку - наткнемся на overflow/underrun.

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

Да, спасибо, такая раскладка кажется весьма перспективной.
Попробовал подобрать параметры чтобы "и волки сыты и овцы целы..":
минимальное кол-во строк первого дисплея = 255 (по его dataheet) - берем 256 строк в кадре. Это константа для обоих дисплеев. 50 кадров таким образом дают ровно 12.8 kHz строчной частоты.
Минимально-допустимая частота первого дисплея должна превышать 20 MHz. Он работает в режиме serial RGB, т.е. 3 последовательных слова (6 бит каждое в ширину) на пиксель. Получаем 960 клоков полезного видео для него. Что-б удовлетворить 20 MHz минимум - берем 1572 клока в его строке, т.е. 960 полезных и еще 612 - dummy. Итого эквивалентно 524 полных пикселя в строке (204 dummy).
Итого имеем 1572 х 256 х 50 = 20.1216 MHz.

При этом, для второго дисплея: в 12.8 kHz умещаются 393 клока (393 полных пикселя) - получаем ровно 5.0304 MHz - частота клока второго дисплея. Допустимое число total клоков/пикслей в строке у него - от 360 до 450, значит 393 вполне подходит. Получаем 73 dummy.
теперь задача привязать PLLем частоты обоих - 20.1216 делится ровно на 4 и получаем ровно 5.0304, это значит можно легко получить искомые 5.0304 MHz из 20.1216 встроенным в FPGA PLLем.

При таком раскладе, ставим dummy пиксели первого дисплея в конце строки (т.е. буфер начинает заполняться с появлением первого клока после DV), я dummy пиксели второго дисплея ставим в начале строки, т.е. после его DV - идут вначале 73 пустых клока, затем начинаем читать буфер FIFO. За то время (время 73ох пикселей второго), запишется примерно 93-94 пикселя первого.
Вполне вероятно что и размер буфера FIFO будет нужен меньший чем на всю строку (т.е. менее чем на 320 пикселей) - нужно посчитать насколько максимально может вырасти буфер вследствии более быстрой записи (разница в скоростях записи/чтения в 1.33333 раза).

Поправьте ежели я ошибаюсь в прикидках. Спасибо.

Вроде как получается. Удачное соотношение частот. Причем PLL и не понадобится, если входная частота у вас 20,1216 МГц, вторую получите простым делением на счетчике.
И еще, в отличие от ТВ сигнала, я понимаю, здесь нет жестких временных рамок, поэтому частоту можно взять и "покруглее", например 20МГц, главное выдержать соотношение частот, попасть в заданные временные диапазоны. А длительность строки принципиального значения не имеет.

Да, начну писать код под эти параметры. Эта частота (20.1216 MHz) просто делиться и на 3 и на 4, мне нужно и то и другое (на 4 для чтения на второй дисплей, на 3 - параллелизация входного серийного потока RGB - три последовательных входных клока дают цельный RGB пиксель. Запись в FIFO буфер идет по входному клоку деленному на 3 и ессно по накоплению 3х последовательных входных слова по 6 бит каждое). Посему это и есть причина такого странного числа
Другое дело - как делить ровно на 3. Я сделал на логике - делить ровно на три что и показывает функциональная симуляция. Там используется счетчик до 3 + чуть логики. Но в реальности будет ессно фазовый сдвиг относительно входной частоты вследствии задержек логики. Вот и думаю не было-бы желательно делить на 3 через PLL ? С другой стороны, если частоту второго дисплея тоже получать делением на 4 счетчиком, то тоже получаем фазовый сдвиг по той-же причине. Т.е. оба клока - и саписи и считывания из буфера будуту с фазовым сдвигом относительно входного клока и относотельно друг друга.

С третьей стороны, эти фазовые сдвиги постоянны во времени, посему наверно не будут проблемой...