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 640×480 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):
Best Answer
EDID is used, among other things, to query the monitor for the timings it would like. It isn't used to transmit any video information.
I guess it's been so long that no one remembers, but VGA monitors back in the day had adjustments for the image location on the CRT. You could move it left or right, up or down, or scale it horizontally or vertically. More advanced monitors had additional adjustments. These allow you to compensate for whatever timing was in use, whatever local magnetic field there might be distorting the picture, etc.
Of course, what these adjustments are doing behind the scenes is adjusting the timing parameters. They were necessary because the VGA signal doesn't explicitly say how much blanking time there is. As you've noticed, there are some general conventions, and the monitor can (through EDID) advertise support for particular timings, but there's no requirement that those timings are what will be sent to the monitor.
What you can do, and what LCD monitors that still have VGA interfaces do when you press the "auto adjust" button, is guess at what the blanking time might be simply by looking at the R, G, and B signals. These should be black for the blanking time, and probably they aren't black otherwise. Of course someone could be looking at a black screen, and this approach won't work.
Similarly, I don't think there's anything in the VGA signal that will tell you what the resolution is. You can guess at it by looking for the edges between pixels, and timing them, and this is again what LCD monitors do. But remember, VGA is an analog signal, designed to be displayed on an analog device. It has no concept of "pixels".