# Update:

The VGA Simulator is up and running. You can go simulate your own designs or just use the example file to see it working. I also wrote a blog post to help anyone get started using it for their own VHDL designs.

I am making a VGA simulator or virtual monitor because Xilinx takes too long to synthesize VHDL (on my pc, and in general for large projects). With this VGA simulator, I can just run my testbench which logs to a file while running in a normal simulator such as Isim and then use that log file in my VGA simulator to generate the frames.

The VGA simulator decodes hsync, vsync, and rgb (5 major signals) to generate the frames.

Is there a way to get the resolution or pixel clock rate from just the 5 major signals? Right now I just have some text fields that you have to put it in manually (see form). I need the pixel clock rate in order to keep track of what pixel the system is working on.

I am assuming that every monitor uses 640x480 at 60 Hz as a default setting for VGA because I don't have to fiddle with anything to get it working. I understand that there is some EDID pins and some newer serial interface that are spec'ed out but are they actually used to determine a different resolution or fps/Hz? On the Basys 2, they are just grounded.

My simulator is working great right now but doesn't account for the back porch so I have blank space at the top left and some cut off at the bottom right. This is because I just look for a rising edge in hsync and vsync and start capturing. This is not a huge deal and easy to fix but I am unsure of the correct value to put for the back porch in order to work with a variety of peoples log files.

My VHDL design(based off of this design) has back porch of 48 clock cycles and for example this document says it should be 45, and this one says 48. What is the correct tolerance for the back porch or the proper way to synchronize to avoid these discrepancies?

Of course a monitor is designed to take this all into account but what are the proper ways to deal with tolerance in not only the pixel clock but how many cycles each process takes (front porch, back porch, resolution, fps)?

An example of a discrepancy: My design just divides the 50 Mhz clock on the Basys 2 by two to get a 25 Mhz pixel clock to drive the VGA when it is spec'ed at 25.175hz everywhere but of course you have to put your pixel clock in the form so it is non-issue at the moment for my design.

Here is just a nice diagram of timing of hsync and vsync (just a good reference):

• It may help to recall that back in the day, video was produced by steering an electron beam. Sync pulses were roughly those intervals in which the beam could be snapped back to the left (HS) or top (VS). The 'porches' are nothing more than some margin to allow the beam to get back into the visible display area. Porch times basically adjust the centering of the image. Get the overall line time right, and you can divvy it up between the porches and the active pixels more or less however you like. – JustJeff Dec 7 '13 at 4:00
• @JustJeff I knew that a CRT worked with a electron beam and scanning it across the screen but it did not quite click that the signal I am sending to the screen explicitly controls the analog circuitry in the monitor instead of it being interpreted and beamed out (the beam just being the technology running the screen instead of a lcd). When you change the position option on the monitor you essentially modify the back porch values and I have added a couple of range inputs so people can align their signal. – MLM Dec 7 '13 at 6:17
• @JustJeff: Although VGA is usually output using separate wires for the for sync signals, it was hardly uncommon to feed it into monitors that expect sync to be superimposed on the "green" signal. Extracting sync from a composite signal requires that the signal be at a consistent stable voltage before the sync pulse; the front porch ensures that's the case. If VGA did not include a front porch, then VGA-to-3-wire adapters would have had to delay horizontal sync in order to add one. – supercat Dec 7 '13 at 23:24
• @JustJeff: The "analog" behavior of monitors makes it possible for monitors (especially monochrome ones) to show a variety of resolutions "perfectly", unlike LCD screens which have a particular fixed resolution and have to scale any other resolution up or down. – supercat Dec 7 '13 at 23:30
• @supercat - just trying to lend some perspective to the situation. Often in electronics we find seemingly strange interfaces that preserve odd bits of OBE technology. Thanks for expanding on this. – JustJeff Dec 8 '13 at 15:33