Задача следующая: в системе есть работающий OLED дисплей резолюцией 320хRGBx240, 6 бит на цвет (т.е. 18 бит на пискель). Входной видео тайминг данного OLEDа включает горизонтальный и вертикальный syncs (VSYNC, HSYNC), data valid (DV) и ессно клок данных (на пиксель по 3 клока).
Есть блок в FPGA который форматирует все это в 18 бит выход с соотв. частотой клока и syncs.
Тайминг его таков что его syncs идут шириной в один клок и сразу следом наичается DV и данные. Т.е. на выходе форамтирующего блока FPGA идут данные шириной 18 бит так что на 320 пикселей в строке идет 321 клок (320 клока данных + один клок sync который либо HSYNC при переходе строки либо HSYNC одновременно с VSYNC при переходе фрейма). Сканирование ессно progressive.
И так, bottom line: имеем на входе 321 клок в строке (каждый клок их 320 - данное, 321ый клок - sync), всего 240 строк, итого 77040 клоков на фрейм.


Нужно данный тайминг выходе форматирующего блока подогнатаь под тайминг стандартного TFT дисплея который тоже резолюцией 320хRGBx240 но его стандартный входной тайминг подогнан под стандартный TV сигнал (NTSC). Т.е. первые 7 строк - пустые, затем идет 320 строк видео, после чего еще 15 строк пустых (для обратного хода луча). Ессно есть стандартные syncs: VSYNC, HSYNC, DEN (data enable внутри строки) и PCLK (pixel clock). Каждая строка имеет длинну между соседними HSYNCs: 400 клоков, из них данных: ессно 320 клоков. Ширина пульса HSYNC - 96 клоков, ширина VSYNC - 2 строки. Значит полная ширина строки (от фронта до фронта HSYNCа): 496 клоков, ширина VSYNCа: 992 клока.

Понятно что нужен буфер памяти (FIFO) для подгонки таймингов: т.е. например буфер на время тех 22 TV строк TFT дисплея. Буфер начинает заполняться видео данными по первому VSYNC/HSYNC OLEDа в течении 22ух TFT строк (что равно примерно 35 OLED строкам), затем начинаем читать видео данные наружу на TFT. Но проблема в том что величина буфера в 22 TFT строке не будет постоянной ибо кол-во клоков в каждой строке TFT значительно больше кол-ва клоков строки OLEDа.
Как мне кажется, буфер со временем переполниться вследствии разницы в длине строк (в клоках), т.е. будет нарастающее запаздывание считывания по сравнению с записью.
Забыл отметить: выход OLEDа (вход буфера) и вход TFT (выход буфера) идут по одному клоку, т.е. на одной частоте.

Действительно ли FIFO буфер в таком случае будет переполняться и получиться бардак ? Или я не совсем правильно это себе представляю ?

Спасибо.

Судя по вашему описанию буфер будет переполняться. На TFT получается нужно выдавать данные с более высоким клоком на величину необходимую для передачи пустых строк.

Спасибо.
Да, так я себе и представлял что буфер будет переполняться. Но мне кажется не по причине тех цельных пустых строк (22), а по причине разницы в длинах строк (в клоках) между HSYNCs и разницы в ширине HSYNC, VSYNC пульсов между OLEDом и TFT.

В принципе я думаю соглашусь что для решения проблемы на TFT нужно выдавать данные по более высокому клоку который должен быть выше входного как отношние длин строк. Т.е. если кол-во клоков в строке OLEDа будет 321, а у TFT: 496 (включая ширину HSYNCа), значит клок данных на TFT по идее по частоте равен Foled*(496/321). Тогда время считывания из FIFO строки на TFT будет равно времени записи строки OLEDа. И в таком случае gap междy поинтерами записи данных OLEDа на входе и считыванием на TFT на выходе будет постоянен и равен 22 строкам TFT (или примерно 35 строкам OLEDа)

Я не прав ?

Во время передачи пустых строк фифо заполнится заполнится и после разница никуда не денется так как скорости записи и считывания одинаковые, к следующим пустым строкам оно ещё заполнится и т. д. в итоге будет переполнение.

Я не знаю утройство шины TFT, но если там есть сигналы enable то не обязательно соотношение клоков должно равнятся определённой величине, просто клок TFT должен быть выше чтобы успевать формировать паузы когда реальные пиксели не передаются, когда же из за более высокой скорости считывания из фифо оно будет опустошаться то соответственно чрез управление enable ничего не будет передаваться.

Если предположить одинаковые скорости записи и считывания и глубину буфера FIFO чуть больше чем кол-во пустых строк то я это представляю как циклический буфер, т.е. начинается запись, продолжается в течении тех, скажем 22ух пустых строк. При этом считывание - блокировано. Затем, немедленно после заполнения 22х строк (или 35 строк OLEDа), начинается считывание со скоростью записи. Глубина буфера скажем 22 стоки TFT + одно данное. Это одно данное позволит циклическое заполнение/считывание буфера. Как только 22 строки TFT заполнились, немедленно со селд. клоком начианется считывание первого данного (поинтер считывания с нуля), при этом еще одно данное записывается в последнюю ячейку буфера. Затем поинтер заполнения обнуляется и буфер заполняется по новой. Таким образом поинтер считывание с этого момента опережает поинтер записи хотя-бы на одно данное, и тогда не проблема что очередное заполнения - трет те предыдущие 22 строки.

Насчет пауз и enable - клок TFT действительно должен быть выше для успевания формирования пауз, но как мне кажется все-таки выше именно на отношение длин строк ибо длины пауз как раз и определяются отношением длин строк. Насчет enable - если я вас правильно понял, имеется ввиду что даже если клок TFT считывания будет выше более чем на отношение длин строк и буфер будет опустошаться, то это не проблема ибо в таком случае считываие на TFT можно блокировать enableом и разрешать его когда буфер достаточно заполниться ?
Если так, то проблема в том что data enable у TFT дислея тоже довольно жестко привязан к строковому таймингу, т.е. к HSYNCам

Пусть есть склад на 23 ящика. Дядя Вася на камазе завозит 22 ящика в неделю. Дядя Петя вывозит 22 ящика в неделю. Изначально склад пуст, и не заполняется т к скорость завоза равна скорости вывоза. Вдруг дядя Петя забухал на неделю. Дядя Вася за неделю заполнил склад на 22 ящика. Таким образом на складе 22 ящика и их количество не уменьшается т к скорость завоза равна скорости вывоза. Опять дядя Петя забухал на неделю. Куда дяде Васе возить свои ящики?



Если поток данных на TFT дисплей нельзя притормозить то конечно всё намного сложнее.

Дык тут-то дядя Петя - не пьющий и после того как первый раз дядя Вася завез те 22 ящика, Петя их исправно вывез и продолжает вывозить каждую неделю, как только дядя Вася завозит очереденую порцию 22ух ящиков. Факт предположения что время заполнения строки и считывания равны (в результате подгонки клоков записи и считывания) равноценны факту трезвенника дяди Пети.
Как только заполнились первые 22 строки - начонается чтение с подходящей скоростью так что время записи строки = времени считывания. Тогда промежуток между поинтерами записи и чтения будет постоянен и равен 22ум строкам.
Ну а ессно что-бы время записи входной строки было равно времени считывания выходной строки (в тайминге которой есть еще 50% пустых данных) - нужно что-бы клок считывания был на те 50% выше клока записи.

Пока не вижу ошибки в своей логике...ежели она там, буду благодарен ежели укажите...

Нетрезвость дяди Пети это - "Т.е. первые 7 строк - пустые...после чего еще 15 строк пустых (для обратного хода луча)." А скорость вывоза (заполнения строк) одинаковая.

Да, вероятно что в таком случае будет проблемка, нужно мне еще врубиться...
Я подразумевал что пустые строки идут сплошным блоком в 22 строки вначале или в конце фрейма...но ежели они разбиты на 2 куска (вначале и в конце фрейма), тогда картина может быть действительно другая....