A Streamlined VGA Controller


Small footprints >>
<< On-chip Memory

Usenet Postings
  By Subject
  By Date

  Why FPGA CPUs?
  Homebuilt processors
  Altera, Xilinx Announce
  Soft cores
  Porting lcc
  32-bit RISC CPU
  Superscalar FPGA CPUs
  Java processors
  Forth processors
  Reimplementing Alto
  FPGA CPU Speeds
  Synthesized CPUs
  Register files
  Register files (2)
  Floating point
  Using block RAM
  Flex10K CPUs
  Flex10KE CPUs

  Multis and fast unis
  Inner loop datapaths

  SoC On-Chip Buses
  On-chip Memory
  VGA controller
  Small footprints

  CNets and Datapaths
  Generators vs. synthesis

FPGAs vs. Processors
  CPUs vs. FPGAs
  Emulating FPGAs
  FPGAs as coprocessors
  Regexps in FPGAs
  Life in an FPGA
  Maximum element

  Pushing on a rope
  Virtex speculation
  Rambus for FPGAs
  3-D rendering
  LFSR Design

Google SiteSearch
Newsgroups: comp.arch.fpga
Subject: Re: VGA interface and VHDL
Date: Thu, 30 Mar 2000 11:56:03 -0800

Leon Heller wrote in message <8bvg75$j9i$1@nnrp1.deja.com>...
>Anshuman Sharma  wrote:
>> ... I want help with the VGA display. Basically if anyone can help me
>> something on how I can build a VGA module that will interact with my
>> datapath and the game as a whole.
>The XSOC FPGA CPU has a VGA display. You'll find details here:

Thanks.  First let me recommend this VGA app note by Dave Vanden Bout of
XESS: www.xess.com/vga.pdf.

The XSOC system-on-a-chip, including the VGA display, is described in the
forthcoming May 2000 (issue #118) issue of Circuit Cellar, and the
schematics (and shortly, the Verilog version) are available as part of the
XSOC distribution at www.fpgacpu.org/xsoc

Here is a brief description of the design of the XSOC video display
controller, which produces a VGA-timing compatible bilevel 576x455 display
using the XESS XS40's 32 KB of SRAM.

A video signal is a series of frames, each frame a series of lines, each
line a series of pixels. The video controller is responsible for fetching
the video data, shifting it out (serializing it), and for asserting the
horizontal and vertical sync pulses that frame the pixel stream into lines
and fields.

A video address counter is required to fetch each word of video data. Often
the video controller shares memory with another agent (such as a processor)
that writes the video data, and this usually requires an address multiplexer
to select either the video address or the writing agent address.

A horizontal pixel counter and vertical line counter are required to
generate horizontal and vertical blanking and syncs. Each counter need four
equality comparators, to determine when the counter reaches 1) start of
blanking, 2) start of sync, 3) end of sync, and 4) end of line/frame.

After first considering a software (interrupt handler) approach to fetching
video data and generating syncs, I settled on a simple, fast, low cost,
hardware approach.

1. The video address counter and the address mux are subsumed by one channel
of the DMA engine in the xr16 processor core. This engine costs only 20 LUTs
and 3 flip-flops.

2. The horizontal and vertical counters are 10-bit LFSR counters that use
only 1-2 LUTs and 10 FFs each.  (The lfsr counter design program is also
provided in the LFSR distribution.)

3. The 8 comparators are 10-bit AND trees (3 LUTs each).

4. A video word DMA staging buffer, and a parallel-in serial-out pixel shift
register, use a further 16 FFs and 16 LUTs+16 FFs respectively.

5. There are a further 6 LUTs and 5 FFs of control logic.

Total cost, including the CPU DMA engine, is about (20 LUT, 3 FF) + 2*(2,10)
+ 8*(3,0) + (0,16) + (16/16) + (6,5) = (70 LUT, 60 FF) = ~35 XC4000E CLBs.

But note, as described in issue #6 in
http://www.fpgacpu.org/xsoc/issues.html, the design currently has a defect
that causes premature blanking of the last word on each line, that we will
fix one of these days.

Jan Gray
Gray Research LLC

Copyright © 2000, Gray Research LLC. All rights reserved.
Last updated: Feb 03 2001