Small footprints >>
<< On-chip Memory
Why FPGA CPUs?
Altera, Xilinx Announce
32-bit RISC CPU
Superscalar FPGA CPUs
FPGA CPU Speeds
Register files (2)
Using block RAM
Multis and fast unis
Inner loop datapaths
SoC On-Chip Buses
CNets and Datapaths
Generators vs. synthesis
FPGAs vs. Processors
CPUs vs. FPGAs
FPGAs as coprocessors
Regexps in FPGAs
Life in an FPGA
Pushing on a rope
Rambus for FPGAs
Subject: Re: VGA interface and VHDL
Date: Thu, 30 Mar 2000 11:56:03 -0800
Leon Heller wrote in message <email@example.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
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
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,
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.
Gray Research LLC
Copyright © 2000, Gray Research LLC. All rights reserved.
Last updated: Feb 03 2001