3
\$\begingroup\$

Besides this, is pixel clock dependant on the VGA resolution and referesh rate or independant of them? What does one know what duration each pixel should have?

\$\endgroup\$
5
  • \$\begingroup\$ I didn't think VGA contained pixel information? \$\endgroup\$ – Andy aka Dec 17 '15 at 21:36
  • \$\begingroup\$ This question is related to writing VHDL design for driving VGA display. I will add tag now. \$\endgroup\$ – quantum231 Dec 17 '15 at 21:57
  • \$\begingroup\$ Why is it not possible to have any "custom" resolution in VGA by toggling the hsync and vsync signals as we want? \$\endgroup\$ – quantum231 Dec 17 '15 at 22:28
  • \$\begingroup\$ Then it wouldn't be VGA and the monitor might not accept it. \$\endgroup\$ – Bruce Abbott Dec 17 '15 at 23:39
  • 1
    \$\begingroup\$ Back and front porch can be defined in absolute time units, it's somewhat more convenient to express them in the number of pixels for a given resolution since it encapsulates all the timing/frequency transformations \$\endgroup\$ – crasic Dec 19 '15 at 20:24
3
\$\begingroup\$

Pixel Clock is related to resolution / refresh rate. You need to clock it so that for a given horizontal line, the pixels plus porch is clocked out...

As for the porch pixels, that is dependent on the monitor, the reason for their existence is so that while the electron beam is moving back to the beginning of a row or frame, it does not show up on the screen. Basically as long as it is approximately correct it will work fine. There are charts that show the timing information based on clk and resolution. Here is one: http://www.epanorama.net/documents/pc/vga_timing.html

\$\endgroup\$
3
  • \$\begingroup\$ This is good but it does not explain why there are a very specific number of pixels present for porch and sync signals. You have said that it depends on the monitor, this means that all monitors are inherently designed by all manufacturers to work with this many pixels for porch and sync signals? \$\endgroup\$ – quantum231 Dec 17 '15 at 22:32
  • \$\begingroup\$ Yes, to my knowledge and I believe Google will confirm that there is no technical standard for porch width. As I said, it is only there to black the electron beam as it sweeps across the screen, but in LCDs that is not a problem, it would be interesting to know if LCDs even detect the porch or completely ignore it. \$\endgroup\$ – MadHatter Dec 18 '15 at 14:50
  • \$\begingroup\$ The porch width is defined in the Coordinated Video Timing specified by VESA. Even an LCD requires some time to change the row. Only vertical blanking can be reduced. \$\endgroup\$ – Martin Zabel Dec 18 '15 at 21:19
3
\$\begingroup\$

Pixel clock is mainly dependent on the resolution. For example 480x640 (VGA) has circa 25 MHz.

If you increase the resolution, you need to transfer more pixels per second to the screen -> higher frequency / pixel clock. The frequency depends on other parameters, too:

  • CVT mode
  • Reduced blanking mode
  • Refresh rate (50/60 Hz)

The porches are related to pixels per line and lines per screen.

There is a Excel sheet from VESA to calculate VGA timings for all known resolutions - I just need to find the link again ....

http://www.vesa.org/vesa-standards/free-standards/


Related SE questions:

\$\endgroup\$
4
  • \$\begingroup\$ I see so a spreadsheet exists? hmm. It is still important to understand the background so I know what is going on. \$\endgroup\$ – quantum231 Dec 17 '15 at 22:43
  • \$\begingroup\$ Can you precise 'background'? E.g. Why VGA has porches? \$\endgroup\$ – Paebbels Dec 17 '15 at 22:45
  • 1
    \$\begingroup\$ Our PoC-Library has a generic VGA controller for different resolutions and PHY interfaces (VGA, DVI). The controller is prepared for release, but not uploaded to the public repo. I could try to upload it tomorrow. So if you would like to have a look into the current timing table for xx known resolutions, give a short reply. \$\endgroup\$ – Paebbels Dec 17 '15 at 22:51
  • \$\begingroup\$ Porches correspond to the blanking interval required for CRT displays to retrace the electron guns back to the left or top of the screen. \$\endgroup\$ – pjc50 Dec 18 '15 at 12:47
2
\$\begingroup\$

As the discussions below the other answers show, the term "pixel clock" is interpreted differently by the authors. There is actually no clock transmitted via the VGA cable.

But, for a resolution of 640x480 @ 60 Hz and using the old Safe Mode Timing (i.e. the one used before Coordinated Video Timings), the controller must output each pixel color value for around 40 ns (see below). This can be achieved with a controller clock of 25 MHz; then the controller must output a new pixel color value every clock cycle. But, the controller can also use a 50 MHz clock, then it must output a new value every second clock cycle, and so on.

Beside the pixel color, the VGA signal also comprises of the HSYNC and VSYNC pulses. The signals must be driven low (or high) for a certain amount of time, to indicate the start/end of a frame (VSYNC) and a scan line (HSYNC) within a frame. Before and after these sync pulses, there is a safe margin (called porch) which separate the sync pulses from the image content. During the sync and porch time, the pixel color lines should be driven low (black) to achieve a proper synchronization. Catode ray tubes need these extra times, to bring the catode ray back to the left/top side. But, even LCDs require at least the sync pulses and even some time to activate the next row in the pixel matrix. The new Coordinated Video Timings allow a reduced vertical blanking for LCDs.

Let's take a look at the Safe Mode Timing for 640x480 @ 60 Hz. The total time of each scan line is 31.778 µs consisting of: 25.442 µs for the 640 pixels in each row, 0.636 µs for the front porch, 3.813 µs for the HSYNC pulse and 1.907 µs for the back porch. Thus, the controller has to output each pixel color for $$\frac{25.442 \,\mbox{µs}}{640} = 39.75\,\mbox{ns}$$ Thus, the controller would require a clock of at least \$1 / 39.75\,\mbox{ns} = 25.157\,\mbox{MHz}\$. This value is also refered as the pixel clock frequency int the VESA documents. But, the controller could also use an internal clock twice as fast as mentioned above.

\$\endgroup\$
1
\$\begingroup\$

The VGA system is derived from analogue monitor design. In a pure analogue system there are two fixed-frequency sawtooth generators, one for the horizontal and one for the vertical. These would phase-lock to the hsync and vsync signals, with a small fixed phase offset at the start. That defines the "front porch" period, which is a time period rather than a pixel count.

On an analogue monitor there are a number of tuning knobs which let the user move the picture to fit the screen correctly: these adjust the front porch and frequency of the sawtooth generators.

Later monitors were capable of multiple sync frequencies and would pick one from a table by looking at the sync frequency, allowing the use of 600-visible-line modes as well as the original VGA 480-visible-line mode. Fully digital flat panel monitors add more modes and an ADC stage in the process. Monitors with EDID will tell you what their mode table is.

There's usually a few percentage variance in what will be accepted, so it need not be a precise count of pixels for the front porch and back porch. Autoadjust will usually compensate. You can have your own video modes, (eg PC video "mode X"). If you're outside VGA timings the monitor may not bother to display it.

\$\endgroup\$
0
\$\begingroup\$

The exact timings vary somewhat and as long as you get them approximately right and try to avoid black backgrounds (see below) you should generally be ok. The pixel clock will obviously depend on the resoloution, higher resoloution means both more lines and more pixels to fit into each line.

On old CRT monitors pixel perfect match wasn't needed. There were manual controls to put the picture in the right place and these would have to be adjusted for each resolution. Some monitors had the ability to remember two or more sets of settings for different resoloutions.

Modern LCDs need to turn the VGA signal back into a digital signal. To do this without creating a blurry mess they need to determine discrete pixel positions and they will contain auto-adjustment systems to try and work out the timing of the incoming signal. Sometimes they guess wrong, especially if fed with a black screen or a screen with black borers.

\$\endgroup\$
0
-1
\$\begingroup\$

Pixel clock is independent of VGA resolution and has no effect on refresh rate. The RGB video signals are analogue and can have any value at any time.

If the refresh rate is increased then the pixels will appear stretched out horizontally, because they are taking up a larger proportion of the display time. To correct this you must increase the pixel clock frequency until it matches the horizontal display period. This may be achieved by counting pixel clocks to generate the horizontal display window and sync.

\$\endgroup\$
15
  • 2
    \$\begingroup\$ That's not true! Pixel clock is mainly dependent on the resolution. For example 480x640 (VGA) has circa 25 MHz. If you increase the resolution, you need to transfer more pixels per second to the screen -> higher frequency / pixel clock. There is a Excel sheet from VESA to calculate VGA timings for all known resolutions - I just need to find the link again .... \$\endgroup\$ – Paebbels Dec 17 '15 at 22:33
  • 2
    \$\begingroup\$ Modern LCD displays sample the analogue signal at fixed intervals and generate their own pixels. To capture each pixel accurately the sample rate must match the pixel rate, so frequency is important to them. A tube monitor doesn't care, it just sends the voltages to the electron guns which 'paint' stripes of color on the tube face. \$\endgroup\$ – Bruce Abbott Dec 17 '15 at 22:38
  • 1
    \$\begingroup\$ @Paebbels yes it is true. Resolution is the number of pixels displayed horizontally and vertically. The number of pixels is determined by the display controller. It does not have to match the possible number that can be displayed. A 640x480 VGA bitmap is displayed on a screen that is ~800 pixel clocks wide, but some pixels are in the border area that might not be visible on a tube monitor. A 320x200 bitmap screen is displayed using the same pixel clock frequency (25.175MHz) but has half the resolution. \$\endgroup\$ – Bruce Abbott Dec 17 '15 at 22:51
  • 1
    \$\begingroup\$ @quantum231 yes. provided the monitor is able to display the pixels they could go right up to the sync pulse. The opposite may also be true - I have a computer which displays a 320x200 bitmap scaled up to 640x400 on an '800x600' screen (resolution reported by the monitor). the result is a large border area, but it is possible to trick the controller into displaying extra pixels in the border area. \$\endgroup\$ – Bruce Abbott Dec 17 '15 at 23:01
  • 1
    \$\begingroup\$ This answer is severely mistaken, even with regard to digitizing displays, as those do not sample at a fixed pixel interval, but rather "tune" their sampling to best match the source pixel clock. The basic idea, horribly contradicted at the start of this post, is that resolution is controlled by the number of pixel clocks per line. \$\endgroup\$ – Chris Stratton Dec 18 '15 at 0:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.