Subversion Repositories wb_vga
Compare Revisions
- This comparison shows the changes necessary to convert path
/wb_vga
- from Rev 9 to Rev 10
- ↔ Reverse comparison
Rev 9 → Rev 10
Wishbone Monitor Controller Accelerated VGA Core
+Description
+Wishbone Monitor Controller Accelerated VGA Core adds a +acceleration and palette support to the +VGA core module. All it's interfaces are WishboneTK compatible +and thus can be used to integrate with into a SoC design. It has no +directly mapped pixel memory seen from the CPU side. It is intended as +a DEMO application rather than a real-world example. + +Author & Maintainer
++Andras Tantos + Index: web_uploads/palette.shtml =================================================================== --- web_uploads/palette.shtml (nonexistent) +++ web_uploads/palette.shtml (revision 10) @@ -0,0 +1,73 @@ + + + +
Wishbone Monitor Controller Palette RAM
+Description
+Wishbone Monitor Controller Palette RAM is a small piece of +dual-ported memory. One of the interfaces is a Wishbone compatible interface +with the WishboneTK extensions. +This interface is write-only. Any read operations attempted on the port would +result in an error (ERR_O goes active). The other port is an asyncronous +read-only port. For that port an enable signal is (BLANK) provided. If that signal +is active all output bits are driven to 0. Otherwise the output will be the data +stored in the memory location identified by the address provided. This type of +memory is ideal for palette memory in a monitor controller. + +Wishbone datasheet
+Description | Specification | ||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
General Description | Monitor controller palette RAM. | ||||||||||||||||||||||
Supported cycles | Slave read/write Slave block read/write Slave rmw | ||||||||||||||||||||||
Data port size | Configurable | ||||||||||||||||||||||
Data port granularity | Bus size | ||||||||||||||||||||||
Data port maximum operand size | Bus size | ||||||||||||||||||||||
Data transfer ordering | n/a | ||||||||||||||||||||||
Data transfer sequencing | n/a | ||||||||||||||||||||||
Supported signal list and cross reference to equivalent Wishbone signals |
+
|
Parameter description
+Parameter name | Description |
---|---|
v_dat_width | True-color pixel output width |
v_adr_width | Palettized pixel input width |
cpu_dat_width | CPU data width |
cpu_adr_width | CPU address width |
Signal description
+Signal name | Description |
---|---|
Signals to connect to the pixel memory master | |
CYC_I | Wishbone cycle signal. High value frames blocks of access |
STB_I | Wishbone strobe signal. High value indicates cycle to this particular device |
WE_I | Wishbone write enable signal. High indicates data flowing from master to slave |
ACK_O | Wishbone acknowledge signal. High indicates that slave finished operation sucessfully |
ACK_OI | WhisboneTK acknowledge chain input signal |
ERR_O | Wishbone error signal. High indicates that slave cannot complete the last cycle in the block. |
ERR_OI | WhisboneTK error chain input signal |
ADR_I(cpu_adr_width-1..0) | Wishbone address bus signals |
DAT_I(cpu_dat_width-1..0) | Wishbone data bus input (to slave direction) signals |
DAT_O(cpu_dat_width-1..0) | Wishbone data bus output (to master direction) signals |
DAT_OI(cpu_dat_width-1..0) | WhisboneTK data bus chain input signal |
Non Wishbone signals | |
BLANK | Blanking input signal. If active (high) output is forced to all 0s |
V_DAT_I(v_adr_width-1 DOWNTO 0) | Palettized data input |
V_DAT_O(v_dat_width-1 DOWNTO 0) | True-color data output |
Author & Maintainer
++Andras Tantos + Index: web_uploads/vga_chip.shtml =================================================================== --- web_uploads/vga_chip.shtml (nonexistent) +++ web_uploads/vga_chip.shtml (revision 10) @@ -0,0 +1,21 @@ + + + +
Wishbone Monitor Controller VGA Chip
+Description
+Wishbone Monitor Controller VGA Chip adds a simple +asyncronous master +and slave +interface to the VGA core module. +It also resolves all generics with constants thus +before and after sythetesys simulation can be performed with the same +test-benches. It is ideal to be used with external CPUs and SRAM-based +pixel memory when there is enough address space available to directly +map the whole pixel memory to the CPUs address space. No acceleration +functions are included nor palette is incorporated. It is intended as +a DEMO application rather than a real-world example. + +Author & Maintainer
++Andras Tantos + Index: web_uploads/vga_core.shtml =================================================================== --- web_uploads/vga_core.shtml (nonexistent) +++ web_uploads/vga_core.shtml (revision 10) @@ -0,0 +1,223 @@ + + + +
Wishbone Monitor Controller Central Core
+Description
+Wishbone Monitor Controller is a set of freely available VHDL cores. It contains +a central building block containing the basic functionality. This core comprises of a +sync generator, a pixel data generator, a memory interface and a CPU interface. These functions +of course implemented in separate entities but this is the smallest fully functional building-block +of the Wishbone Monitor Controller project. The functionality of this module can then be expanded +by adding external modules. ++The Wishbone Monitor Cotroller Central Core is 100% Wishbone compatible with the +WishboneTK extensions. It incorporates 3 +Wishbone interfaces. One salve interface for register accesses another slave interface for +pixel memory accesses and one master interface for the pixel memory. Arbitation between +the core and the external master accessing the pixel memory handled by the core internally. + +
Features
+-
+
- Highly customizable sync generation with polarity control +
- Capable of driving EGA/VGA/Hercules/CGA monitors +
- Multi-scan support for low resolution modes +
- Internal memory for multi-scan, for even less memory accesses +
- FIFO de-coupled memory interface and pixel output circuit +
- Wisbone pixel memory interface +
- 16-bit pixel memory support (later parametrizable) +
- Programmable color depth (1,2,4,8 bits per pixel) +
- ~80Mhz pixel clock (wish) +
- Standard parametrizable Wishbone CPU bus interface +
- Syncron internal structure +
- Fully synthesizable (using Leonardo Spectrum) +
Wishbone datasheet
+Description | Specification | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
General Description | Monitor controller central core. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Supported cycles | Slave read/write Slave block read/write Slave rmw + Master read/write Master block read/write Master rmw | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Data port size | Configurable on slave side, 16-bits on the master side | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Data port granularity | 8-bit | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Data port maximum operand size | Bus size | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Data transfer ordering | Little endien | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Data transfer sequencing | n/a | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Supported signal list and cross reference to equivalent Wishbone signals |
+
|
Parameter description
+Parameter name | Description |
---|---|
v_dat_width | Pixel memory data width |
v_adr_width | Pixel memory address width |
cpu_dat_width | CPU data width |
cpu_adr_width | Pixel memory access interface address width |
reg_adr_width | Register access interface address width |
fifo_size | Size of the internal FIFO buffers in v_dat_width bits |
Signal description
+Signal name | Description |
---|---|
Signals to connect to the pixel memory master | |
VMEM_CYC_I | Wishbone cycle signal. High value frames blocks of access |
VMEM_STB_I | Wishbone strobe signal. High value indicates cycle to this particular device |
VMEM_WE_I | Wishbone write enable signal. High indicates data flowing from master to slave |
VMEM_ACK_O | Wishbone acknowledge signal. High indicates that slave finished operation sucessfully |
VMEM_ACK_OI | WhisboneTK acknowledge chain input signal |
VMEM_ADR_I(cpu_adr_width-1..0) | Wishbone address bus signals |
VMEM_SEL_I(cpu_dat_width/8-1..0) | Wishbone byte-selection signals |
VMEM_DAT_I(cpu_dat_width-1..0) | Wishbone data bus input (to slave direction) signals |
VMEM_DAT_O(cpu_dat_width-1..0) | Wishbone data bus output (to master direction) signals |
VMEM_DAT_OI(cpu_dat_width-1..0) | WhisboneTK data bus chain input signal |
Signals to connect to the register master | |
REG_CYC_I | Wishbone cycle signal. High value frames blocks of access |
REG_STB_I | Wishbone strobe signal. High value indicates cycle to this particular device |
REG_WE_I | Wishbone write enable signal. High indicates data flowing from master to slave |
REG_ACK_O | Wishbone acknowledge signal. High indicates that slave finished operation sucessfully |
REG_ACK_OI | WhisboneTK acknowledge chain input signal |
REG_ADR_I(reg_adr_width-1..0) | Wishbone address bus signals |
REG_SEL_I(cpu_dat_width/8-1..0) | Wishbone byte-selection signals |
REG_DAT_I(cpu_dat_width-1..0) | Wishbone data bus input (to slave direction) signals |
REG_DAT_O(cpu_dat_width-1..0) | Wishbone data bus output (to master direction) signals |
REG_DAT_OI(cpu_dat_width-1..0) | WhisboneTK data bus chain input signal |
Signals to connect to the pixel memory | |
V_CYC_O | Wishbone cycle signal. High value frames blocks of access |
V_STB_O | Wishbone strobe signal. High value indicates cycle to this particular device |
V_WE_O | Wishbone write enable signal. High indicates data flowing from master to slave |
V_ACK_I | Wishbone acknowledge signal. High indicates that slave finished operation sucessfully |
V_ADR_O(m_addr_width-2..0) | Wishbone address bus signals |
V_SEL_O(s_bus_width/8-1..0) | Wishbone byte-selection signals |
V_DAT_I(s_bus_width-1..0) | Wishbone data bus input (to slave direction) signals |
V_DAT_O(s_bus_width-1..0) | Wishbone data bus output (to master direction) signals |
Non Wishbone signals | |
H_SYNC | Horizontal sync pulse. Active level programmable. |
H_BLANK | Horizontal blank pulse. Active level programmable. |
V_SYNC | Vertical sync pulse. Active level programmable. |
V_BLANK | Vertical blank pulse. Active level programmable. |
H_TC | Horizontal terminal count. Active high signal, active for one clock cycle/line |
V_TC | Vertical terminal count. Active high signal, active for one clock cycle/refresh |
BLANK | Blank signal. Active high signal. |
VIDEO_OUT(7 downto 0) | 8-bit video output. If bit-depth is less than 8, value is right alligned and padded with 0s. |
Register description
++The core has several programmable registers which control its behaviour. All registers can be written and checked. All registers reset to 0. +It is recomended that the enable bit turned off prior any write to any of the registers and than enable bit turned off after all registers +are programmed to their new values. Registers are shown in 8-bit layout however the actual grouping of registers into access units depending +on the bus-width of the CPU interface. Address-decoding is allways little-endien. + +
Offset | Bit number | Description | |||||||
---|---|---|---|---|---|---|---|---|---|
7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | ||
0 | V_MEM_END | Last location in the memory being part of the frame buffer. Counted in v_dat_width units. | |||||||
1 | |||||||||
2 | |||||||||
3 | |||||||||
4 | V_MEM_START | First location in the memory being part of the frame buffer. Counted in v_dat_width units. | |||||||
5 | |||||||||
6 | |||||||||
7 | |||||||||
7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | ||
8 | reserved | ||||||||
9 | |||||||||
10 | |||||||||
11 | |||||||||
12 | |||||||||
13 | |||||||||
14 | |||||||||
15 | |||||||||
7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | ||
16 | FIFO_TRESHOLD | Number of words in the internal pixel FIFO after pixel memory access priority changes. | |||||||
17 | res. | MSS | res. | BPP | MSS: Multi-scan-select. If 0 multi-scan feature is disabled. + BSS: Bits per pixel. 00 - 1 bpp, 01 - 2 bpp, 10 - 4 bpp, 11 - 8 bpp | ||||
18 | HBS | Horizontal blank start in 8 pixels. (Horizontal resolution) | |||||||
19 | HSS | Horizontal sync pulse start in 8 pixels. | |||||||
20 | HSE | Horizontal sync pulse end in 8 pixels. | |||||||
21 | HTOTAL | Horizontal line total length in 8 pixels. | |||||||
22 | VBS | Vertical blank start in 8 lines. (Vertical resolution) | |||||||
23 | VSS | Vertical sync pulse start in 8 lines. | |||||||
7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | ||
24 | VSE | Vertical sync pulse end in 8 lines. | |||||||
25 | VTOTAL | Vertical total screen size in 8 lines. | |||||||
26 | PSS | Pixel pre-scaler: Pixel-clock := System-clock/(PSS+1). | |||||||
27 | EN | res. | VBP | HBP | VSP | HSP | +EN: 1 - normal operation, 0 - core is in reset state + HSP: 0 - positive h sync, 1 - negative h sync + VSP: 0 - positive v sync, 1 - negative v sync + HBP: 0 - positive h blank, 1 - negative h blank + VBP: 0 - positive v blank, 1 - negative v blank | ||
28 | reserved | ||||||||
29 | |||||||||
30 | |||||||||
31 | |||||||||
7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
Features explained
+Capable of driving EGA/VGA/Hercules/CGA monitors
++Of course the FPGA cannot provide the correct signal levels not to mention the analog output +required by VGA monitors. This statement means that all the necessary sync signals can be +generated. +
Multi-scan support for low resolution modes
++On VGA monitors low resolution modes (320x200, 320x240) are generated with this feature. Each +video memory line scanned twice, so the physical screen will contain 400/480 scan-lines. +
FIFO de-coupled memory interface and pixel output circuit
++The use of FIFO buffer allows long bursts from the CPU without being interrupted by the pixel +generation engine. It also somewhat relaxes memory speed requirements as FIFO-fill cycles can +continue through blanking periods. +
16-bit pixel memory support
++This device is designed to be simple and easy to use. It's not about using many megs of +frame-buffer. The optimal size of the frame-buffer would be around 64kWords. Such a size +of memory can most easily be constructed from SRAM chips. They are also faster and easier +to interface to than DRAM let alone SDRAM devices. An external Wishbone bus interface should +be used to interface the core to the pixel memory so any memory type that has such an interface +can be used. For SRAM devices the WisboneTK +Asyncronous slave interface in a practical choice. +
~80Mhz pixel clock
++Depends of course on technology but this is the minimum to support reasonable resolutions with +usable refresh-rates. + +
Author & Maintainer
++Andras Tantos + Index: web_uploads/accel.shtml =================================================================== --- web_uploads/accel.shtml (nonexistent) +++ web_uploads/accel.shtml (revision 10) @@ -0,0 +1,215 @@ + + + + +
Wishbone Monitor Controller Accelerator
+Description
+Wishbone Monitor Controller Acclereator is a small address-generator +which can (when used properly) fasten up various common video memory operations. +The core is 100% Wishbone compatible with the +WishboneTK extensions. It incorporates 2 +Wishbone interfaces. A salve interface for accessing it's internal registers and to +generating access cycles to the pixel memory and one master interface for the pixel memory. +The data width on the two interfaces should be the same but address might not. + +Accelerator functions
++Many 8-bit systems has very limited address space. It's common that they can't access more +than 64k of memory but often the available address spaces for video buffer is even much +smaller. There are two ways to overcome this: +
-
+
- Paging +
- Indirect addressing +
+The important thing is that while paging provides two type of information in one cycle (what +and where) indirect addressing provides only one. +
+Many algorithms uses relative addressing which is quite time-consuming to implement in SW. they +would say things like, write to the pixel to the left, or up; Go two rows down, etc. The +accelerator part of the design will do such post-modification of the cursor automatically by HW. +It will have a set of modify registers (a small bunch of RAM). It will also has a separate address +space of (lets say) 256 locations, used for indirect frame-buffer access. A write operation on this +address space will identify a post-modify register and provide the information to be written to the +frame-buffer. After the write completes, the cursor location will be incremented/decremented by the +value in the addressed post-modify register. Read operation can work the very same way only +returning data instead of writing it to the frame-buffer. + +
+Let's have an example! Let's say we would like to implement an algorithm of scrolling the screen +up by one line. With direct access the code for that would be something like this: +
+ mov R1, frame_buffer_addr + mov R2, frame_buffer_addr+xres/8 + mov R3, frame_buffer_size-xres/8 +loop: + mov R4,[R2] + mov [R1],R4 + inc R1 + inc R2 + dec R3 + jnz loop ++
+The same thing with indirect addressing: +
+ mov R1, 0 + mov R2, xres/8 + mov R3, frame_buffer_size-xres/8 +loop: + mov [cursor_reg],R2 + mov R4,[pixel_reg] + mov [cursor_reg],R3 + mov [pixel_reg],R4 + inc R1 + inc R2 + dec R3 + jnz loop ++
+And finally the same thing with the accelerator functions: +
+ mov R1, -xres/8 + mov [cursor_post_inc_reg1],R1 + mov R1, 1+xres/8 + mov [cursor_post_inc_reg2],R1 + mov R1, frame_buffer_addr + mov [cursor_reg],R1 + mov R2, frame_buffer_size-xres/8 +loop: + mov R1,[cursor_post_inc_reg1] ; will modify cursor position to the upper byte + mov [cursor_post_inc_reg2],R2 ; will modify cursor position to the lower-right pixel + dec R2 + jnz loop ++
+As you can see for this particular algorithm this approach is faster than even the direct access +method to the frame-buffer. Hence the pompous word, accelerator. +
+If you think about the most common functions you will find that this approach fastens at least the +following operations +
-
+
- copy one part of the screen to another location, especially +
- scroll +
- mouse cursor +
- character rendering +
- Copy from local memory to frame buffer or back +
- Line-drawing. Both vertical, horizontal, and Brezenhelm algorithms can benefit from it +
- Drawing continuos curves of nearly any kind +
-
+
-
+
- It takes time to set-up the engine and to program the various post-increment values +
- Generaly, when arbitrary pixels are needed to be accessed it's not any faster than indirect addressing +
- Required address range comparable to paged access +
Programming information
+
+As discussed above the accelerator maintains and updates a cursor register. That register is large enough to address all
+possible locations in the pixel memory, that is it has video_addr_width
number of bits. This register
+can be read or written by asserting the cur_stb_i pin in a valid Wishbone cycle.
+
+Each location in the accelerator memory functions as an increment value to the cursor. Thus each location has the same
+size as the cursor register itself. If data_width
is less than video_addr_width
such a
+location cannot be updated in one access. In that case the lower data_width
bits of the location written
+or read directly form the data bus of the master Wishbone bus when the ACC_STB_I
signal is asserted.
+The upper part of the location is written to/from the extension register. That register can be accessed by
+asserting the EXT_STB_I
signal. Pixel memory accesses are performed upon the assertion of the
+MEM_STB_I
signal. The accelerator location is selected by the address bits, the pixel memory location
+will be the current value of the cursor register, and the cursor register is updated with the value read from the
+accelerator location.
+
+The accelerator has 2**accel_size locations. + +
Wishbone datasheet
+Description | Specification | ||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
General Description | Monitor controller accelerator. | ||||||||||||||||||||||||||||||||||||||||||||||||||
Supported cycles | Slave read/write Slave block read/write Slave rmw + Master read/write Master block read/write Master rmw | ||||||||||||||||||||||||||||||||||||||||||||||||||
Data port size | Configurable on slave side, same on the master side | ||||||||||||||||||||||||||||||||||||||||||||||||||
Data port granularity | Bus size | ||||||||||||||||||||||||||||||||||||||||||||||||||
Data port maximum operand size | Bus size | ||||||||||||||||||||||||||||||||||||||||||||||||||
Data transfer ordering | Little endien | ||||||||||||||||||||||||||||||||||||||||||||||||||
Data transfer sequencing | n/a | ||||||||||||||||||||||||||||||||||||||||||||||||||
Supported signal list and cross reference to equivalent Wishbone signals |
+
|
Parameter description
+Parameter name | Description |
---|---|
accel_size | Address size of the accelerator memory |
video_addr_width | Address size of the pixel memory |
data_width | Data size of the interfaces |
Signal description
+Signal name | Description |
---|---|
Signals to connect to master | |
CYC_I | Wishbone cycle signal. High value frames blocks of access |
CUR_STB_I | Wishbone strobe signal. High value indicates cycle to the cursor register |
EXT_STB_I | Wishbone strobe signal. High value indicates cycle to the extension register |
ACC_STB_I | Wishbone strobe signal. High value indicates cycle to the accelerator memory |
MEM_STB_I | Wishbone strobe signal. High value indicates cycle to the pixel memory |
WE_I | Wishbone write enable signal. High indicates data flowing from master to slave |
ACK_O | Wishbone acknowledge signal. High indicates that slave finished operation sucessfully |
ACK_OI | WhisboneTK acknowledge chain input signal |
ADR_I(accel_size-1..0) | Wishbone address bus signals |
SEL_I(data_width/8-1..0) | Wishbone byte-selection signals |
DAT_I(data_width-1..0) | Wishbone data bus input (to slave direction) signals |
DAT_O(data_width-1..0) | Wishbone data bus output (to master direction) signals |
DAT_OI(cpu_dat_width-1..0) | WhisboneTK data bus chain input signal |
Signals to connect to the pixel memory | |
V_CYC_O | Wishbone cycle signal. High value frames blocks of access |
V_STB_O | Wishbone strobe signal. High value indicates cycle to this particular device |
V_WE_O | Wishbone write enable signal. High indicates data flowing from master to slave |
V_ACK_I | Wishbone acknowledge signal. High indicates that slave finished operation sucessfully |
V_ADR_O(video_addr_width-2..0) | Wishbone address bus signals |
V_SEL_O(data_width/8-1..0) | Wishbone byte-selection signals |
V_DAT_I(data_width-1..0) | Wishbone data bus input (to slave direction) signals |
V_DAT_O(data_width-1..0) | Wishbone data bus output (to master direction) signals |
Author & Maintainer
++Andras Tantos + Index: web_uploads/index.shtml =================================================================== --- web_uploads/index.shtml (nonexistent) +++ web_uploads/index.shtml (revision 10) @@ -0,0 +1,85 @@ + + + + +
Wishbone Monitor Controller
+Description
+Wishbone Monitor Controller is a set of freely available VHDL cores. It contains +a central building block containing the basic functionality. It can then be sorrounded by +various helper functions to add functionality. The central core comprises of a +sync generator, a pixel data generator, a memory interface and a CPU interface. It is specificly +designed for slow 8-bit systems (although CPU interface size can be set) with no high needs +about a display. It is also designed to be simple and small (cheap). The target is the whole +design to be well fit in an Altera ACEX 1k30 device which is available for around 10USD. + +Individual module decriptions
+Building blocks + +Sampe configurations +-
+
- VGA chip +
- Accelerated VGA core +
Features
+For a fast breafing here are the main design goals and features of the various modules: +-
+
- Highly customizable sync generation with polarity control +
- Capable of driving EGA/VGA/Hercules/CGA monitors +
- Multi-scan support for low resolution modes +
- Internal memory for multi-scan, for even less memory accesses +
- FIFO de-coupled memory interface and pixel output circuit +
- Wisbone pixel memory interface +
- 16-bit pixel memory support (later parametrizable) +
- Programmable color depth (1,2,4,8 bits per pixel) +
- ~80Mhz pixel clock (wish) +
- Standard parametrizable Wishbone CPU bus interface +
- Syncron internal structure +
- Fully synthesizable (using Leonardo Spectrum) +
- Palette support (3x5 bits plus key bit in each entry) +
- Accelerator functions for common display operations +
- Mouse cursor support if it fits to the chip (wish) +
Status
+-
+
- Central core implemented +
- Palette and Accelerator implemented +
- Cores compile under ActiveHDL and Leonardo Spectrum +
- Cores simulate well (some more validation still needed) +
- All functionality fits into a 1k30 chip +
- Synthesized central core works as expected but max. clock rate is ~60MHz +
- When all function synthesized max. clock rate is ~35MHz :-((( +
ToDo
+-
+
- More simulation to proove all core functionality +
- Port to other (Xilinx Spartan-II) FPGA architectures +
- Optimize design to encrease clock speed +
- Implement Mouse sprite block +
- More sample applications (complete designs) +
- Sample programs +
- Parametrizable pixel memory interface +
- Generic version for fixed configuration (even much smaller) +
- LCD support (??) +
- high-color support (??) +
- Develop a target board and try the core in real +
Download
++The first beta version of the Memory Controller can be downloaded from from the CVS repository. +You can browse the repository here or +use CVSget with module name wb_vga. +The design uses the WishboneTK so you will also need that. + +
Author & Maintainer
++Andras Tantos + Index: web_uploads/mouse.shtml =================================================================== --- web_uploads/mouse.shtml (nonexistent) +++ web_uploads/mouse.shtml (revision 10) @@ -0,0 +1,32 @@ + + + +
Wishbone Monitor Controller Mouse Sprite Module
+Description
+Wishbone Monitor Controller Mouse Sprite Module is a +future extension to the existing VGA core. The need for such a module is +pretty obvious I think. It takes a lot of time to keep track of mouse cursor position and +prevent destroying it. Alternatively you can remove the mouse from the screen prior each WR access +and restore it afterwards. Not only it takes a lot of time it also makes the cursor blinking and +interfere with the refresh of the screen. HW support for mouse cursor overlay can make graphical +application's life much easier. ++The planned functionality will use one 512 bytes chuck on on-chip RAM. +The 32x32 pixel image of the mouse with 2 bits per pixel is planned to be placed there. The 512 +bytes of available memory allows for 2 mouse images to be stored. The overlay engine than takes +care of reading the content and put it on the output video data. As the memory is dual-ported +there can no collisions occur. Thus de-coupling is not needed for this functionality and the +overlaying can be done in the part of the core synchronized with the pixel clock. +
+The meaning of each pixel planned to be the following: +
00 | No effect, transparent |
01 | Invert all bits of the underlaying pixel. Allways done on all 8 pixels of the output even when BPP is less than 8. |
10 | Opaue: replace output with all bits with 0s |
11 | Opaue: replace output with all bits with 1s |