Once when the author was developing an image, he did not take a picture of the input image and directly output it to the display terminal. The image was sometimes good or bad, or the image color was incorrect. Finally, the problem was solved by taking a picture.
//配置为16-Bit SDR ITU-R BT.656模式时pixel_data[23:16]为高阻。
always @(posedge pixel_clk ) begin
pixel_data_d1<=pixel_data[15:0];
pixel_data_d2<=pixel_data_d1;
end
always @(posedge pixel_clk ) begin
hs_d1<=hs;
hs_d2<=hs_d1;
end
always @(posedge pixel_clk ) begin
vs_d1<=vs;
vs_d2<=vs_d1;
end
always @(posedge pixel_clk) begin
de_i_d1<=de_i;
de_i_d2<=de_i_d1;
end
assign pixel_o[19:10] = {
pixel_data_d2[15:8], 2'b00 } ;//LUMA
assign pixel_o[9:0] = {
pixel_data_d2[7:0] , 2'b00 } ;//CHROMA
assign pixel_clk_o = pixel_clk;
Unsnapped color distortion:
Input synchronized picture: normal color.
Don’t understand: In a general sense, the understanding is that it is an external single-bit asynchronous input, and it needs to be hit to eliminate metastability. If the accompanying clock and data come in from outside, why do we need to use the accompanying clock to beat the accompanying data and synchronization signal and then the display is normal?
Input parallel 16-bit image data. At first, I directly assigned the output to the display driver chip on the FPGA, but the display was abnormal. Finally, I used the incoming clock to synchronize all the signals and output them, and the display was normal. I still don’t understand, what has changed after synchronized shooting?
Some netizens explained: The synchronization signals need to be strictly aligned, and taking pictures is a fool's errand. Because the pin to pin traces directly through the FPGA are not the same length. The set_max_delay constraint needs to be used.