[AlexZabr 0]

Буду благодарен за советы более опытных 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 клоков у обеих дисплеев поак не найти подходящее отношение ?

Что посоветуете ?

 

Спасибо.

[SAR 0]

[Если я все понял правильно - то 18-разрядное FIFO, с глубиной в 320 слов - это вообще максимум, который решит Вашу проблему в случае любой расфазировки строчных синхросигналов. На самом деле, глубина FIFO может быть намного меньше, а если частоты pixel clock возможно жестко привязать друг к другу - то оно вообще не нужно.

[AlexZabr 0]

[Если я все понял правильно - то 18-разрядное FIFO, с глубиной в 320 слов - это вообще максимум, который решит Вашу проблему в случае любой расфазировки строчных синхросигналов. На самом деле, глубина FIFO может быть намного меньше, а если частоты pixel clock возможно жестко привязать друг к другу - то оно вообще не нужно.

 

Да, спасибо, уже прикинуто.

Rates клоков на входе/выходе отличаются в 1 1/3 раза, но время строки одинаковое (как и верям кадра).

Взял буфер FIFO длинной в одни строку активного видео (320), начало считывания задержано относительно записи, ноблагодаря blanks в строчке считывание заканчивается вовремя к началу записи след. строки.