Subversion Repositories rtfbitmapcontroller

Description:

This core is a low to medium resolution bitmap display controller. It was engineered for use on the
Nexsys2 board, a Spartan3e FPGA board, but is readily adaptable to other environments.


Features

- small size
- low to mid resolution bitmap display
- fixed format display
- 32 byte burst fetching
- memory bandwidth consideration
- line buffer
- independent video and bus clocks

While small, this controller core has a number of interesting features. It features low resolution
(low resolution these days) bitmap display. The resolution is 416 x 262 x 8bpp. Memory usage is
about 128Kb. The controller is of a fixed display format, and hence doesn't need any software
control. It does have a control signal to allow page flipping between two different address ranges.
The design of the controller takes into consideration the amount of memory bandwidth available to
the system, using 32 byte burst fetches to fill a line cache. A trick to achieving a low resolution
bitmap display, is to use a video line cache instead of a video fifo. 


Operation:

The line cache allows the same video data to be retrieved several times for a given video display
row, without accessing main memory.

Briefly, a fifo works by filling the fifo buffer once it becomes a certain percentage empty. As data
is retrieved for display from the fifo, new data for future display is fetched and loaded into the
fifo. A video line cache works slightly differently, by buffering entire video display lines in
a line buffer.

The video line cache is periodically filled at a rate that keeps up with the video
display. While one video row is being displayed, a to-be-displayed video row is being fetched from
memory and stored in the line cache. The advantage of a line cache over a fifo is that the same
video data may be redisplayed without refetching the data. This allows data for the display to be
fetched across the duration of several scan lines, when a lower resolution mode is in use.

A video fifo is driven by the fifo status, if the status indicates that the fifo is
becoming empty, more data is fetched. The line cache is driven directly by video timing instead.
Rather than monitoring empty/full status, it simply automatically fetches data at periodic
intervals.

The disadvantage of a video line cache is that it requires a larger memory reousrce than a video
fifo would require. Often a fifo only needs to be a few dozen bytes in size. The line cache needs to
buffer at least two entire lines, which can result in it being several kilobytes in size, depending
on the video mode. Timing control for a line cache is more complex than a fifo.

The controller fetches data in 32 byte bursts at periodic intervals. One might think that it would
be a lot simpler and more efficient to just fetch an entire line in a long burst. However this would
have the drawback of consuming memory bandwidth for an extended duration of time. The 32 byte
burst fetches are geared towards allowing other devices in the system to access the same memory. So
that the peformance of the entire system isn't adverse. The controller relies on the memory system
to support burst mode fetchs. In this case page-mode of the PSRAM is used.

The controller uses two independent clocks, one each for bus timing and video timing. Except for
the video request flip-flop, all cross clock domain data is handled using a block ram resource. The
block ram itself allows a different clock to be used on each port. Data is written to the block
ram under control of the bus clock, and read from the block ram on the second port using the
video timing clock. A clock domain crossing synchronizer is used to allow the video request signal
to cross the clock domain.