Strange behaviour with ARTY 100 and VGA PMOD with Digilent Example

[engi]

I am using an ARTY 100 with the VGA PMOD and a reduced VGA example project. The issue is that I somehow cannont constantly drive a full 1 level to all of the colour channels to obtain white.

I started with a setting like this here:

  vga_red   <= h_cntr_reg(10 downto 7);
  vga_green <= h_cntr_reg( 6 downto 3);
  vga_blue  <= v_cntr_reg( 6 downto 3);

to see all possible colour on one screen, but got this output on image 1. It is TOO Yellow so obviously BLUE is to low. I expected a false routing with green or a bad PIN to I exchanged green and blue:

  vga_blue <= h_cntr_reg( 6 downto 3);
  vga_green <= v_cntr_reg( 6 downto 3);

.. and got the second image. Now suddenly GREEN is to low. This shows, the electrically the pins are driven totally (all 4 bits) of all 4 colours.
 

But how can this be?

Can I have to do with a bad bank voltage setting as mentioned here?

 

 

[engi]

As on can see, the vertical colour component is somehow not driven the same way. To test this, I mapped alle colours from  HCOUNT  and drove them all completely with one bit:

vga_red   <= h_cntr_reg(8) & h_cntr_reg(8) & h_cntr_reg(8) & h_cntr_reg(8);
vga_blue  <= h_cntr_reg(7) & h_cntr_reg(7) & h_cntr_reg(7) & h_cntr_reg(7);
vga_green <= h_cntr_reg(6) & h_cntr_reg(6) & h_cntr_reg(6) & h_cntr_reg(6);

So the green colour changes every bar, the blue every second and the red one is half off and on (for the upper 4 of 8 bars).

The image is as expected:

So the full driven bits cause the expected colours, and es especially WHITeE for 1,1,1 - (it is really totally white, even if the photo appears to show a bit grey). So the does not seem to be an electrical level issue or a scan issue (some Monitors scan the VGA levels the wrong way). I even changed monitor input to different colour seetings (warm, cold, sVGA etc) but di not see a stronge change.

The colour bar is ok.

-------------------------------------------------

This is different when I use the VCOUNT:

vga_red   <= v_cntr_reg(8) & v_cntr_reg(8) & v_cntr_reg(8) & v_cntr_reg(8);
vga_blue  <= v_cntr_reg(7) & v_cntr_reg(7) & v_cntr_reg(7) & v_cntr_reg(7);
vga_green <= v_cntr_reg(6) & v_cntr_reg(6) & v_cntr_reg(6) & v_cntr_reg(6);

The image is not ok, see the right one "image 4".

It seems as if the 4 bit (bit #3) is somehow "Weak"!  The relevant bit only works for the colour 4,5 but fail for 6,7.

What the hell is going on three?

ChipScope ILA prooves that VCOUNT shows also all bits and counts correctly. There is no bit missing.

 

[engi]

I expected this to be a power problem, but do not see any change if i connect an additional power supply.

When I plug it in, (9V/1A) I do not see any change of the FPGA-behaviour,

When I plug it off, the FPGA PCB stops, reloads and recovers, so obviously USB takes over powering again.

Anybody else using the VGA PMOD?

Here is the project:

vga_test.zip

[thinkthinkthink]

You probably need more pipelining to get rid of the weird VGA artifacts.

[artvvb]

Hi @engi

Have you tried another monitor and/or VGA cable?

Edit:

I highly doubt this is a power issue. Your design is quite small, and the Pmod VGA does not provide any power to the monitor. The iostandards for all banks relevant to the design are applied in the xdc file and all of the power rails on the Arty run at fixed voltages.

-Arthur

Edited January 19, 2022 by artvvb

[engi]

********************

The issue is solved!

********************

It was a specific problem with the monitor and the pattern I was using: If one looks close to the pattern one can see the effect that the colour already slightly changes over the vertical coordinate!  Reason: The Monitor scans the VGA signal in order to get the limits for VMAX and blank and with my pattern this worked only partly. I did not correctly blank the VGA channels in the HSYNCH and VSYNCH periods. Regarding the code above, the "active" signal has to be taken into account. Then it works fine.

And yes:  No power supply is required for this design. It works without.

 

[artvvb]

The syncs and pixel data might be misaligned, depending on the constants used in the compares. There are a different number of register stages in the sync and color data paths, and a redundant extra output stage. Data arrives from the counters (through combi logic in the case of the sync data path) to the first set of registers "at the same time", assuming that timing is met.

Refer to the attached screenshot of the RTL analysis schematic view in Vivado.

Thanks,

Arthur

[engi]

I checked the alignment and some wrong CCs wont do much harm ecept of an image shift. The issue I was describing above was indeed the missing active area treatment: When stripping down the example, I simply did not blank the VGA outs correctly. However I will check the alignmet again - but according to a test I did in the meanwhile (using a frame of 1 pixel width) this is right.
Here is an example of a vid pattern (ARTY 100, PmodVGA placed at ports B+C)

 

 

 

vga_pattern_test.zip

[mwagner]

Thanks for sharing this project and information.

I have a question regarding the VGA-options: What is the highest frequency for the pixel clock which can be used together with this VGA option board?Is

 

[engi]

With an Artix it is possible to treat UHD at 297MHz, most probably not with an analog VGA:-)
In the example above, I am using 148.5MHz for HDMI, which is already pretty high for analog purposes.

With a Spartan I also used 148.5 and also 162 to drive 1600x1200. The issue here is the monitor which only prints nice at 1920x1080, so there is no other choice at first glance.

With a different timing scheme it might be possible to go with almost 200MHz, but did not try this. See the table below.
https://www.mikrocontroller.net/articles/Projekt_VGA_Core_in_VHDL