title: How do VGA control signals work in Verilog/HDL?
body: <p>I'm an FPGA beginner and have trouble understanding how VGA control 
  signals and VGA interact, and how to correctly generate VGA control 
  signals (with Verilog) for more complicated specifications:</p>
  
  <ol>
  <li><p>Seemingly, the low portions in horizontal- and vertical- sync signals 
  correspond to transitioning from one row to the next, and transitioning 
  from the bottom-right corner to the upper-left corner, respectively. But 
  is the VGA "controlled" by those low signals? Do those low signals 
  "tell" the VGA to switch to next row or jump back to the starting point?</p></li>
  <li><p>Are the back porch and front porch there to satisfy setup time and 
  hold time? Are the durations of porches given in VGA timing table only 
  required minima (i.e. can I set the porches to be much longer than the 
  given values in the timing table?)</p></li>
  <li><p>This is what confuses me the most: From the two continuous 
  horizontal- and vertical- sync signals, how on earth does the VGA know 
  (or do I know) exactly which <em>point</em> on screen it is displaying? If timing 
  is the only factor, does that mean I must pay a lot of attention to 
  match RPG control signals and h-sync and v-sync signals perfectly? If 
  the answer is yes, then I have even more problems which I can only 
  describe using my assignment as an example:</p></li>
  </ol>
  
  <p>In this assignment we use a built-in 50MHz clock of an FPGA (Spartan starter board) and the pixels of the VGA is specified to be 800x600. The framerate is specified to be 72Hz. </p>
  
  <p>The VGA timing table gives the following sync signal structures:</p>
  
  <p>h-sync:
  | 0---back-porch(104)---103 | 104---display(800)---903 | 904---front-porch(16)---919 | 920__pulse width(120)__1039 |</p>
  
  <p>v-sync:
  | 0---back-porch(23)---22 | 23---display(600)---622 | 623---front-porch(37)---659 | 660__pulse width(6)__665 |</p>
  
  <p>This seems to mean that for each pixel in a row on screen I spend 1 
  clock cycle (20ns) on it. However, for many complicated cases, I would 
  want to control the color of a pixel depending on its location on screen 
  and perhaps a lot of additional conditions such as the relation of 
  current position with another location, certain states, etc. Now, if the location of the pixel depends on horizontal and vertical pixel counters, and the color depends further on the location, how can I match them in time? Also, what if my logic has to spend more than 20ns to decide the color of a pixel? Will that completely crash the image on the VGA screen?</p>
  
  <p>Actually I've somehow completed my assignment, but I find my code messy 
  and I totally have no idea why it worked:</p>
  
  <p>For example, a portion of the assignment required us to show a star that 
  changes its color every 0.5sec. My implementation looks like:</p>
  
  <pre><code>//----------------pixel counters----------------
  always@(posedge CLK or posedge RESET) begin
      if(RESET) h_count &lt;= 11'd 0;
      else if (h_count &gt;= 11'd 1039) h_count &lt;= 11'd 0;
      else h_count &lt;= h_count + 11'd 1;
  end
  
  always@(posedge CLK or posedge RESET) begin
      if(RESET) v_count &lt;= 10'd 0;
      else if (v_count &gt;= 10'd 665) v_count &lt;= 10'd 0;
      else if (h_count == 11'd 1039) v_count &lt;= v_count + 10'd 1;
      else v_count &lt;= v_count;
  end
  
  //----------------h- and v- sync----------------
  always@(posedge CLK or posedge RESET) begin 
    if(RESET) VGA_HSYNC &lt;= 1'b 0;
    else VGA_HSYNC &lt;= (h_count &gt;= 11'd 0) &amp; (h_count &lt;= 11'd 919);
  end
  
  always@(posedge CLK or posedge RESET) begin 
    if(RESET) VGA_VSYNC &lt;= 1'b 0;
    else VGA_VSYNC &lt;= (v_count &gt;= 10'd 0) &amp; (v_count &lt;= 10'd 659);
  end
  
  //----------------a frame counter and a flag----------------
  always@(posedge CLK or posedge RESET) begin
      if(RESET) frame_count &lt;= 6'd 0;
      else if (frame_count &gt;= 6'd 49) frame_count &lt;= 6'd 0;
      else if(v_count == 10'd 665) frame_count &lt;= frame_count + 6'd 1;
      else frame_count &lt;= frame_count;
  end
  
  always@(posedge CLK or posedge RESET) begin
      if(RESET) color_flag &lt;= 1'd 0;
      else if (frame_count == 6'd 49) color_flag &lt;= ~(color_flag);
      else color_flag &lt;= color_flag;
  end
  
  //----------------RGB control----------------
  always@(posedge CLK or posedge RESET) begin
      if(RESET) VGA_RGB &lt;=  3'b 000;
      else if(display) begin //display is high when counters in valid range
          casez({tree, star, snow})  //these are outputs from submodules that decides the "shapes" of objects on screen
              3'b ??1: VGA_RGB &lt;= 3'b 111;  //white snow
              3'b ?10: VGA_RGB &lt;= (color_flag) ? (3'b 110) : (3'b 111);
                  //switching between yellow and white
              3'b 100: VGA_RGB &lt;= 3'b 010;  //green tree
              default: VGA_RGB &lt;= 3'b 001;  //blue background
      endcase
    end
    else VGA_RGB &lt;= 3'b 000;  //for transitions
  end
  </code></pre>
  
  <p>It seems to me that my h_count and v_count directly decides my VGA_HSYNC and VGA_VSYNC. But my VGA_RGB depends at least on color_flag, which further depends on frame_count, which depends on h_count and v_count. Shouldn't that cause delay of a few clock cycles? The code was synthesizable and did produced what I wanted to display. But how on earth did my VGA_RGB sync with VGA_HSYNC and VGA_VSYNC in time??? Am I overthinking this issue? Or was I just lucky? What did I miss?</p>