Приверствую уважаемые посетители форума !
Возник вопрос про синхронизацию вывода изображения на VGA.
Поскольку альтеровское ядро scaler II"платное" - пришлось разработать собственный scaler в основе которого лежит алгоритм билинейной интерполяции.
Особых проблем при написании scaler у меня не возникло и моделирование показывает - что все работает правильно.
Но я столкнулся с тем, что никак не могу придумать как правильно синхронизировать вывод отмасштабированного видео с новым разрешением.
Чуть подробнее про проблему:
Допустим что scaler понижает масштаб видео с 800х600х60hz (Vertical refresh 37.878787878788 kHz) до 640х480х60Hz (Vertical refresh 31.46875 kHz). Так вот у нас получается, что не совпадают периоды Vertical refresh на этих разрешениях. И это несовпадение периодов приводит к тому, что выходной видеобуффер либо постоянно переполняется, либо слишком быстро опустошается, в зависимости от того какое разрешение масштабируется. Вот и сижу ломаю голову как правильно синхронизировать новый отмасштабированный видеопоток с выходным разрешением. Очень хотелось бы услышать подсказку от более опытных коллег !

Берем 3 буффера.
В один пишем, из другого читаем, третий на подхвате (кто раньше освободится - чтение или запись).
И так по кругу - для чтения берем последний записанный, для записи - любой свободный. Увеличивая количество буфферов мы получаем меньшую вероятность потери/дублирования кадров.
Или я не правильно понял вопрос?

Ну тут бы получилось работать по такому алгоритму, если бы частота чтения и записи совпадала. (вернее среднее количество записанной информации и считанной за период) А у меня не совпадает частота чтения с частотой записи. Из-за этого данные либо кончаются в буфере, либо их слишком много и мы не успеваем их читать. Количество буферов не поможет....
Хотя про тройную буферизацию стоит подумать...

У Вас кадровые частоты всегда равны?

Если да, то так существенно проще синхронизировать начало вывода картинки с окончанием получения исходной. Тогда может пересмотреть архитектуру формирования вывода?


Что если сделать так:

1. По поступлению входного кадра формировать пиксель выходной кадр изображения в выходной буффер (допустим с двумя портами: первый на запись, второй на чтение).

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

Если кадровые равны - начало вывода подсинхронизировать к окончанию масштабирования кадра.

Если нет - то зависит от задачи. Если транслируется гуй - то можно выводить полкадра старого. пол кадра нового, если качественное видео - тогда всё сложнее. Нужна межкадровая интерполяция.

Не понял. У вас строчная потоков данных 600*60=36000 и 480*60=28800.

А уж с какой частотой вы собрались со всеми полями выдавать 28800 - это ваше дело.

Нет. Входная кадровая частота зависит от входного разрешения, которое может быть любым начиная от 640x480 заканчивая 1680x1050. Выходная кадровая всегда одинаковая. Например 1024х768. Scaler автоматически определяет входное разрешение и перенастраивает свои коэффициенты.
Самое интересное, что в Альтеровских IP корках - они как-то реализовали это без применения внешнего буфера.
Но для начала будем считать что они фиксированы. Для начала я хочу сделать масштабирование какого-то фиксированного разрешения, чтобы разобраться. А далее буду "прикручивать" возможность детектирования входного разрешения.


Не совсем понял Вас. Т.е Вы предлагаете отойти от стандартов VESA и выдавать строки быстрее чем того требуется ? Или я не так понял ?

Возьмите картинку 800x600 отскалируйте её до 640x480 и выведите в левом верхнем углу экрана 800х600.

Что нам останется сделать чтобы получить 640x480@60 ? Очевидно не выводить некоторые строки снизу и подрезать длину строки.

С какой там точностью VESA от вас требует Vertical refresh 31.46875 kHz?

Про точность Vertical refresh не скажу т.к стандарта у меня нет, и боюсь никогда не будет , а на просторах сети, я не встретил каких-либо рекомендаций. Да и до этого работал по принципу: что указано на сайте http://tinyvga.com/vga-timing то и применял. Но опыт работы показывает что в несколько процентов ошибка вполне допустима. Т.к PLL например не всегда позволяет получить с большой точностью необходимый pixel_clk.


Так это понятно. Можно вообще посередине экрана вывести. Вот только есть один нюанс: картинка поступает с разрешением 800x600 и после масштабирования становится с другим разрешением. Но выводится то она так-же на разрешение 800х600. И тут фактически частота поступления данных и частота вывода данных одна и та-же. В таком ключе задача то вообще простая.

А в моем случае есть ЖК матрица, тайминги которой соответствуют VESA. И понимает она только одно разрешение: 1024х768 60 Hz.
А входной видеопоток может быть любым: от 640x480 до 1680x1050 60 Hz. И задача состоит в том, чтобы преобразовать входной поток в разрешение ЖК матрицы. Я прекрасно осознаю, что в процессе преобразования может быть небольшое искажение данных, и качество "неродного" разрешения будет хуже....
Так вот я сейчас тестирую scaler на обычном VGA мониторе. Пытаюсь входной видеопоток 800х600 понизить до 640x480 и вывести в формате 640x480. Такие разрешения выбрал просто "на шару". Первое что попало в голову. Вот тут я и перестал понимать, как это сделать.
P.S. Прошу прощения за тупые вопросы, но мозг уже слишком зациклился на текущей задаче и могу банально тупить и не видеть решения перед носом....

У вас тоже простая:

1. Частота кадров одинаковая

2. За один кадр приходит 600 строк выходит 480 строк.

3. На каждые пришедшие 5 строк выдаётся синхронно 4 строки.

4. в каждой принятой строке 800 пиксель клоков внутри строчной - в каждой отданной - 640.

Размер буфера - 5 строк, если интерполировать надо.

Теоретически количество пиксельклоков вне строчного импульса, а также пиксельклоков и строчных импульсов вне кадровой - может быть любым и даже не постоянным.
Практически - может задаваться в контроллере матрицы или быть ограничено максимальной частотой работы.

1080 / 768 = 1,4 строки FIFO, округляется до 2, плюс 1 строка — итого, 3 строки на FIFO и N строк на интерполятор.

FIFO виртуальный — при смене выдаваемой строки его целые строки переходят интерполятору, а FIFO — выпавшие интерполятора.

Частота кадров естественно одна и её естественно задаёт источник.

Я вот так и не понять сути проблемы.
Указал выше, что если скорость получения данных и скорость выдачи отличаются - то в результате как не крути, либо иногда будут выдаваться два подряд одинаковых кадра, либо некоторые кадры будут пропадать.
Всё просто.

Мне стыдно признаться, но даже сейчас я не совсем Вас понимаю . Возможно связано с тем, что я сам себя своими рассуждениями загнал в тупик и не вижу способа из него выбраться.
Попробую обьяснить свою логику, может так получится понять друг друга и если я ошибаюсь мне укажут на ошибку в моих рассуждениях.
Итак, за основу своих рассуждений я беру следующую аксиому: для того чтобы вывести на матрицу правильно изображение я должен выполнить требования стандарта VESA, а именно:


И сли отклонение частоты pixel_clk ±100...500 КГц еще допускается, то изменение длительности Front porch, Back porch приводит к тому, что видимая область изображения будет отображаться за пределами экрана, т.е часть выводимого изображеня будет обрезана. Неточность же Sync pulse приводит к тому, что матрица вообще может отказываться понимать входной видеосигнал.

Итого мы имеем 3 клоковых домена:
Домен Vga_sync_gen - синхрогенератор, который генерирует сигналы H_sync, V_sync, Data_enable для разрешения 640х480х60Hz
Домен source_data - источник виедосигнала, данные которого я масштабирую. Он имеет свои синхросигналы H_sync, V_sync, Data_enable, имеет свой pixel_clk 40MHz.
Домен scaler - собственно сам scaler который работает на частоте выше доменов Vga_out и source_data. Это сделано специально для того, чтобы scaler успевал обрабатывать данные независимо от входной или выходной частоты.

Данные из домена source_data посредством FIFO переносятся в домен scaler, обрабатываются там по алгоритму билинейной интерполяции и scaler выдает сигналы:
Данные нового отмасштабированного пикселя new_pixel.
Сигнал Data_valid - показывающий что данные нового пикселя можно использовать.
Сигнал SOL (start of line ) - сообщающий что это у нас первый пиксель в линии.
Сигнал EOL (end of line ) - сообщающий что это у нас последний пиксель в линии.
Сигнал SOF (start of frame) - сообщающий что это у нас первый пиксель кадра.
Сигнал EOF (end of frame) - сообщающий что это у нас последний пиксель в кадре.


Вы говорите, что:

Но ведь кадровые синхроимпульсы формируются на разных частотах, и частота кадров реально будет разная.
Например прии разрешении 640x480 частота кадров 16.683217477656 ms.
А вот на разрешении 800х600 частота кадров уже 16.5792 ms.

С этими я полностью согласен, да это и так вроде очевидно :



А вот это утверждение уже интересно, и непонятно одновременно. У нас же после строчного импульса - каждый клок начинает отсчитывать рамку Front porch. Соответственно через определенное количество импульсов у нас должны быть поданы данные. Иначе картинка будет смещена относительно краев видимой области.

Для примеря я покажу структуру проекта.



Источник разрешения 800x600 сейчас находится внутри FPGA, но в последствии это будет отдельное внешнее устройство. Сейчас для отладки так удобнее. Поэтому на блок-схеме он изображен пунктиром

А я считаю, что

1. Back porch 48 pixel - может быть хоть 148
2. Back porch 33 lines - может быть хоть 133
3. pixel_clk не 25.175 MHz, а 25 175 000 импульсов в секунду, с довольно свободной скважностью.

у меня покупной видеодатчик, когда из 1600х1200 делает 640х480 выдаёт 4 строчных синхры - потом пропуск. Его что тоже никуда не подключишь?

Отчего же, подключишь. Туда, где есть входной видеобуфер.


По теме - может эта ссылка поможет в понимании вопроса.
https://www.intel.com/content/dam/altera-ww...re/an/an648.pdf

Хм, напрямую к VGA монитору? Тогда у вас на экране будет изображение размером 640х480, но разрешением 1600х1200, остальное черный экран. Если конечно контроллер сможет правильно воспринять, что вы на него подаете. А ТС нужно именно "размытие" кадра 640х480 на весь монитор