I've been trying to code a simple VGA controller
to run on my 
Altera DE1 board. You can see my code here: 

http://pastebin.com/GMfxs6Xz

Note that my board has a DAC which converts the 4-bit digital 
signal for each of the RGB colors to the analog signal required 
by VGA. The timings are as found here for example: 

640x480@60Hz" target=_blank rel="nofollow">http://tinyvga.com/vga-timing/640x480@60Hz

When I run this code the monitor leaves the "No Signal Found" 
indication but it stays black no matter which color I choose.

I know that the board works because the VGA output works fine 
with the demonstration provided by Altera.

Any help greatly appreciated.

On Jun 23, 12:55=A0pm, Giorgos Tzampanakis
<g...@hw.ac.uk> wrote:
> I've been trying to code a simple VGA controller to run on my
> Altera DE1 board. You can see my code here:
>
> http://pastebin.com/GMfxs6Xz
>
> Note that my board has a DAC which converts the 4-bit digital
> signal for each of the RGB colors to the analog signal required
> by VGA. The timings are as found here for example:
>
> 640x480@60Hz" target=_blank rel="nofollow">http://tinyvga.com/vga-timing/640x480@60Hz
>
> When I run this code the monitor leaves the "No Signal Found"
> indication but it stays black no matter which color I choose.
>
> I know that the board works because the VGA output works fine
> with the demonstration provided by Altera.
>
> Any help greatly appreciated.


Have you simulated this?  Just looking quickly I don't see how
vga_hs works.  It looks like maybe your sync pulses are only
one clock long.  That won't drive any monitor I know of.

-- Gabor

Gabor <g...@alacron.com> wrote in
news:cc66c286-0547-416a-
9...@f8g2000vbl.googlegroups.com:

> Have you simulated this?  Just looking quickly I don't see 
how
> vga_hs works.  It looks like maybe your sync pulses are only
> one clock long.  That won't drive any monitor I know of.

I run it on the board and look at the signals using SignalTap 
or an external logic analyzer. It doesn't simulate correctly on 
the simulator, but the signals are as expected on the logic 
analyzer.

The pulses are not one clock long, notice:


case (next_state)
      `vertical_sync: begin
                         vga_vs <= 1'b0;
                         if (line_count ==     	    	    	    
	    	    	`max_vertical_sync_count && pulse_count ==     
	    	    	    	`max_pulse_count)
                         next_state <= `vertical_front_porch;
      end

etc...

So the low value on the sync pin will stay until the machine 
moves on to the next state. Why did you think that the pulse 
only stays for one clock cycle?

>I've been trying to code a simple VGA
controller to run on my 
>Altera DE1 board. You can see my code here: 
>
>http://pastebin.com/GMfxs6Xz
>
>Note that my board has a DAC which converts the 4-bit digital 
>signal for each of the RGB colors to the analog signal required 
>by VGA. The timings are as found here for example: 
>
>640x480@60Hz" target=_blank rel="nofollow">http://tinyvga.com/vga-timing/640x480@60Hz
>
>When I run this code the monitor leaves the "No Signal Found" 
>indication but it stays black no matter which color I choose.
>
>I know that the board works because the VGA output works fine 
>with the demonstration provided by Altera.
>
>Any help greatly appreciated.
>

I simulated your code @ 25 Mhz after striping out the divider on clock_50and
it shows:

4 us Horizontal pulse every 33.5 us
67.1 us Vertical pulse every 17.6 ms


Your running it at 15 hz

John

	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

On Jun 23, 7:01=A0pm, Giorgos Tzampanakis
<g...@hw.ac.uk> wrote:
> Gabor <ga...@alacron.com> wrote in news:cc66c286-0547-416a-
> 9edf-3c43de9b7...@f8g2000vbl.googlegroups.com:
>
>
>
> > Have you simulated this? =A0Just looking quickly I don't see
> how
> > vga_hs works. =A0It looks like maybe your sync pulses are only
> > one clock long. =A0That won't drive any monitor I know of.
>
> I run it on the board and look at the signals using SignalTap
> or an external logic analyzer. It doesn't simulate correctly on
> the simulator, but the signals are as expected on the logic
> analyzer.
>
> The pulses are not one clock long, notice:
>
> case (next_state)
> =A0 =A0 =A0 `vertical_sync: begin
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vga_vs <=3D 1'b0;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (line_count =3D=3D =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 `max_vertical_sync_count =
&& pulse_count =3D=3D =A0 =A0
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 `max_puls=
e_count)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0next_state <=3D `verti=
cal_front_porch;
> =A0 =A0 =A0 end
>
> etc...
>
> So the low value on the sync pin will stay until the machine
> moves on to the next state. Why did you think that the pulse
> only stays for one clock cycle?

As I said I only looked at it quickly and saw lines 74 and 75 setting
the sync pulses high (outside the state machine case statement), which
is something I usually do to create pulses.  Looking back at the code
I see that the value is assigned throughout the state.

If your monitor doesn't lock, you should make sure that the sync
signals
are actually reaching the sync pins of the monitor.  Also check if the
working version of the VGA code gives the same active level for the
sync pulses.  Most monitors use the sync active level as a code to
suggest a resolution standard.  This comes from the original VESA
definitions for PC video.  Getting it wrong doesn't usually prevent
the monitor from syncing, but your monitor may be more finicky.

Regards,
Gabor

"jt_eaton"
<z3qmtr45@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> wrote
in news:0...@giganews.com: 

> I simulated your code @ 25 Mhz after striping out the
> divider on clock_50 and
> it shows:
> 
> 4 us Horizontal pulse every 33.5 us
> 67.1 us Vertical pulse every 17.6 ms
> 
> 
> Your running it at 15 hz
> 

These times look about correct based on http://tinyvga.com/vga-
timing/640x480@60Hz .

Am I missing something? The page says these are the 60 Hz 
timings.

Gabor <g...@alacron.com> wrote in
news:2...@c10g2000yqi.googlegro
ups.com: 

> If your monitor doesn't lock, you should make sure that the
> sync signals
> are actually reaching the sync pins of the monitor.  Also
> check if the working version of the VGA code gives the same
> active level for the sync pulses.  Most monitors use the
> sync active level as a code to suggest a resolution
> standard.  This comes from the original VESA definitions for
> PC video.  Getting it wrong doesn't usually prevent the
> monitor from syncing, but your monitor may be more finicky. 
> 

I will check those suggestions, but I have no control over the 
level, I can only set it to 0 or 1 within the fpga, so it's 
unlikely that there is some problem there, given that the demo 
program runs fine.

Giorgos Tzampanakis <g...@hw.ac.uk> wrote
in
news:Xns9DA0B66A6D054fdnbgui7uhu5h8hrnuio@188.40.43.230: 

> I've been trying to code a simple VGA controller to run on
> my Altera DE1 board. You can see my code here: 
> 
> http://pastebin.com/GMfxs6Xz
> 
> Note that my board has a DAC which converts the 4-bit
> digital signal for each of the RGB colors to the analog
> signal required by VGA. The timings are as found here for
> example: 
> 
> 640x480@60Hz" target=_blank rel="nofollow">http://tinyvga.com/vga-timing/640x480@60Hz
> 
> When I run this code the monitor leaves the "No Signal
> Found" indication but it stays black no matter which color I
> choose. 
> 
> I know that the board works because the VGA output works
> fine with the demonstration provided by Altera.
> 
> Any help greatly appreciated.

Fixed. The problem was that I was only driving the horizontal 
sync pulses while the pixel rgb values were driven.

On Jun 24, 11:17=A0am, Giorgos Tzampanakis
<g...@hw.ac.uk> wrote:
> Gabor <ga...@alacron.com> wrote innews:2b315a7b-decf-407a-a018-97425e8691=
0...@c10g2000yqi.googlegro
> ups.com:
>
> > If your monitor doesn't lock, you should make sure that the
> > sync signals
> > are actually reaching the sync pins of the monitor. =A0Also
> > check if the working version of the VGA code gives the same
> > active level for the sync pulses. =A0Most monitors use the
> > sync active level as a code to suggest a resolution
> > standard. =A0This comes from the original VESA definitions for
> > PC video. =A0Getting it wrong doesn't usually prevent the
> > monitor from syncing, but your monitor may be more finicky.
>
> I will check those suggestions, but I have no control over the
> level, I can only set it to 0 or 1 within the fpga, so it's
> unlikely that there is some problem there, given that the demo
> program runs fine.

What I meant by "levels" was active high vs active low, not the
actual voltage which should be TTL.  Anyway glad to see you've
got it fixed.

regards,
Gabor

>"jt_eaton"
<z3qmtr45@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> wrote
>in news:0...@giganews.com: 
>
>> I simulated your code @ 25 Mhz after striping out the
>> divider on clock_50 and
>> it shows:
>> 
>> 4 us Horizontal pulse every 33.5 us
>> 67.1 us Vertical pulse every 17.6 ms
>> 
>> 
>> Your running it at 15 hz
>> 
>
>These times look about correct based on http://tinyvga.com/vga-
>timing/640x480@60Hz .
>
>Am I missing something? The page says these are the 60 Hz 
>timings.
>
My Bad. I grabbed the wrong number when I divided.

John	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com