Как управляющие сигналы VGA работают в Verilog/HDL?

Question

Я новичок в FPGA и трудно понять, как управление VGA сигналов и V взаимодействуют, и как правильно генерировать управление VGA сигналов (с Verilog) для более сложных спецификаций:

1. Казалось бы, низкими порты в сигналах горизонтальной и вертикальной синхронизации соответствуют переходу от одной строки к следующей и переходу из нижнего правого угла в верхний левый угол соответственно. Но - это VGA «управляемый» этими низкими сигналами? Делают ли эти низкие сигналы «рассказывают» VGA, чтобы переключиться на следующую строку или вернуться к исходной точке?

2. Есть ли заднее крыльцо и переднее крыльцо для удовлетворения времени установки и провести время? Являются длительности подъездов приведены в VGA таблице синхронизации только требуемого минимум (т.е. я могу установить подъезды быть намного больше, чем заданных значений в таблице синхронизации?)

3. Это то, что меня смущает больше всего: от два непрерывных сигнала горизонтальной и вертикальной синхронизации , как на самом деле VGA знает (или я знаю) точно, что точка на экране отображается? Если выбор времени является единственным фактором, значит ли это, что я должен уделять большое внимание соответствующим сигналам управления RPG и сигналам h-sync и v-sync? Если ответ да, то у меня есть еще больше проблем, которые я могу только описать, используя мое назначение в качестве примера:

В этом задании мы используем встроенный 50MHz часами ПЛИС (Spartan стартер), а пиксели VGA - 800x600. Частота кадров задана равной 72 Гц.

В таблице синхронизации VGA дает следующие сигналы синхронизации структуры:

ч-синхронизации: | 0 --- back-porch (104) --- 103 | 104 --- дисплей (800) --- 903 | 904 --- передняя крыльца (16) --- 919 | 920__ ширина импульса (120) __ 1039 |

v-sync: | 0 --- back-porch (23) --- 22 | 23 --- дисплей (600) --- 622 | 623 --- передняя крыльца (37) --- 659 | 660__ ширина импульса (6) __ 665 |

Это означает, что для каждого пикселя в строке на экране я трачу 1 тактовый цикл (20 нс) на нем. Однако для многих сложных случаев я бы хотел бы контролировать цвет пикселя в зависимости от его местоположения на экране и, возможно, дополнительных условий, таких как отношение текущей позиции с другим местоположением, определенными состояниями и т. Д. Теперь , если местоположение пикселя зависит от горизонтальных и вертикальных счетчиков пикселей, а цвет зависит от местоположения, как я могу сопоставить их во времени? Кроме того, что, если моя логика должна потратить больше 20 нс, чтобы определить цвет пикселя? Это полностью разрушит изображение на экране VGA?

На самом деле я как-то закончил свое назначение, но я нахожу мой код грязный и я совершенно не имею, почему это сработало:

Например, часть задания требуется нам, чтобы показать звезду, меняет цвет каждые 0,5 сек.Моя реализация выглядит следующим образом:

//----------------pixel counters---------------- 
always@(posedge CLK or posedge RESET) begin 
    if(RESET) h_count <= 11'd 0; 
    else if (h_count >= 11'd 1039) h_count <= 11'd 0; 
    else h_count <= h_count + 11'd 1; 
end 

always@(posedge CLK or posedge RESET) begin 
    if(RESET) v_count <= 10'd 0; 
    else if (v_count >= 10'd 665) v_count <= 10'd 0; 
    else if (h_count == 11'd 1039) v_count <= v_count + 10'd 1; 
    else v_count <= v_count; 
end 

//----------------h- and v- sync---------------- 
always@(posedge CLK or posedge RESET) begin 
    if(RESET) VGA_HSYNC <= 1'b 0; 
    else VGA_HSYNC <= (h_count >= 11'd 0) & (h_count <= 11'd 919); 
end 

always@(posedge CLK or posedge RESET) begin 
    if(RESET) VGA_VSYNC <= 1'b 0; 
    else VGA_VSYNC <= (v_count >= 10'd 0) & (v_count <= 10'd 659); 
end 

//----------------a frame counter and a flag---------------- 
always@(posedge CLK or posedge RESET) begin 
    if(RESET) frame_count <= 6'd 0; 
    else if (frame_count >= 6'd 49) frame_count <= 6'd 0; 
    else if(v_count == 10'd 665) frame_count <= frame_count + 6'd 1; 
    else frame_count <= frame_count; 
end 

always@(posedge CLK or posedge RESET) begin 
    if(RESET) color_flag <= 1'd 0; 
    else if (frame_count == 6'd 49) color_flag <= ~(color_flag); 
    else color_flag <= color_flag; 
end 

//----------------RGB control---------------- 
always@(posedge CLK or posedge RESET) begin 
    if(RESET) VGA_RGB <= 3'b 000; 
    else if(display) begin //display is high when counters in valid range 
     casez({tree, star, snow}) //these are outputs from submodules that decides the "shapes" of objects on screen 
      3'b ??1: VGA_RGB <= 3'b 111; //white snow 
      3'b ?10: VGA_RGB <= (color_flag) ? (3'b 110) : (3'b 111); 
       //switching between yellow and white 
      3'b 100: VGA_RGB <= 3'b 010; //green tree 
      default: VGA_RGB <= 3'b 001; //blue background 
    endcase 
    end 
    else VGA_RGB <= 3'b 000; //for transitions 
end 

Мне кажется, что мой h_count и v_count напрямую решает мою VGA_HSYNC и VGA_VSYNC. Но мой VGA_RGB зависит, по крайней мере, от color_flag, что в дальнейшем зависит от frame_count, который зависит от h_count и v_count. Разве это не должно задерживать несколько тактов? Код был синтезирован и сделал то, что я хотел показать. Но как же моя VGA_RGB синхронизировала с VGA_HSYNC и VGA_VSYNC во времени ??? Могу ли я переубедить эту проблему? Или мне просто повезло? Что я упустил?

Answer 1

Большинство ваших вопросов объясняется тем фактом, что VGA является аналоговым стандартом, который изначально был предназначен для работы на аналоговых устройствах. Импульсы h-sync и v-sync просто запускают их соответствующие катушки отклонения обратно в их начальные позиции, в то время как передние и задние крыльцы учитывают тот факт, что луч запускается и заканчивается за пределами видимой части экрана.

Что касается точности, это лучше, чем раньше: отправка плохо синхронизированного сигнала VGA на аналоговый монитор в течение многих лет может нанести ему ущерб. Теперь все изменилось с помощью ЖК-дисплеев и т. Д., Схемы которых способны обнаруживать и отображать широкий диапазон разрешений при любых частотах обновления. По моему опыту, хотя количество свободного пространства у вас меньше, чем вы думаете, и сильно зависит от модели и модели устройства отображения ... многие из них даже перечисляют немного разные тайминги в своих руководствах пользователя! Если вы хотите быть уверены, что ваша схема будет работать на оборудовании, на котором работает ваш тестер, вы должны придерживаться одного из «официальных» разрешений настолько точно, насколько сможете.

Что касается времени на пиксель, то сигнал 800x600x72Hz требует 50 МГц часов, и у вас, таким образом, есть 20nS, в котором вы сможете получить ваши пиксельные данные (это говорит о том, что я не уверен на 100%, что ваши синхронизирующие и ведомые тайминги верны , они отличаются от тех, что были в VGA Timings, которые я сам использовал в прошлом). Если 20nS недостаточно, вам нужно использовать несколько схем, например. один для нечетных пикселей и другой для выравнивания. В качестве альтернативы вы можете реализовать этапы трубопровода, например. для пикселя, который вы выведете в цикле X, вы читаете его значение из ПЗУ в цикле X-1 и вычисляете адрес для чтения в цикле X-2. Еще один трюк, который я использовал в прошлом, - это двойной буфер отображения на экране с двумя строками оперативной памяти, то есть на любой заданной строке, которую вы рисуете непосредственно из одного буфера, одновременно записывая следующий; это дает вам больше времени для рендеринга каждой строки, но обычно добавляет дополнительную сложность отдельных тактовых областей между рендерингом и отображением.