Home
Small footprints >>
<< On-chip Memory
Usenet Postings
By Subject
By Date
FPGA CPUs
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
Transputers
FPGA CPU Speeds
Synthesized CPUs
Register files
Register files (2)
Floating point
Using block RAM
Flex10K CPUs
Flex10KE CPUs
Multiprocessors
Multis and fast unis
Inner loop datapaths
Supercomputers
Systems-on-a-Chip
SoC On-Chip Buses
On-chip Memory
VGA controller
Small footprints
CNets
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
Miscellaneous
Floorplanning
Pushing on a rope
Virtex speculation
Rambus for FPGAs
3-D rendering
LFSR Design
|
|
|
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
>find
>> 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:
>www.fpgacpu.org/xsoc
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
|