Subversion Repositories wb_vga

<!--# set var="title" value="Title" -->
<!--# include virtual="/ssi/ssi_start.shtml" -->
<link REL="stylesheet" TYPE="text/css" HREF="/people/tantos/styles.css">
 
<h1>Wishbone Monitor Controller Accelerator</h1>
<h2>Description</h2>
<strong>Wishbone Monitor Controller Acclereator</strong> 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 
<a href="/cores/wb_tk/wb_extensions.shtml">WishboneTK extensions</a>. 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.
 
<h3>Accelerator functions</h3>
<p>
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:
<ul>
	<li>Paging</li>
	<li>Indirect addressing</li>
</ul>
Both implementations are quite common in various places. For this core I'm planning to use 
the second approach with a little twist. You can imagine the indirect addressing of a
frame buffer as having a cursor on it. Writes will overwrite values under the cursor and reads
will return the value under the cursor. Writes to the index register will alter the cursor
position, reads will return cursor location. That fits seamlessly to the way many algorithm
thinks about the display. However there is one drawback: you need two accesses in average to reach
a pixel. First you have to set the cursor position by writing the index register and then you can
access the requested memory position. The first approach (Paging) excels in this. It can provide
the same information at the same time. 
<p>
The important thing is that while paging provides two type of information in one cycle (what 
and where) indirect addressing provides only one. 
<p>
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.
 
<p>
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:
<pre>
   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
</pre>
<p>
The same thing with indirect addressing:
<pre>
   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
</pre>
<p>
And finally the same thing with the accelerator functions:
<pre>
   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
</pre>
<p>
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.
<p>
If you think about the most common functions you will find that this approach fastens at least the
following operations
<ul>
	<li>copy one part of the screen to another location, especially</li>
	<ul>
		<li>scroll</li>
		<li>mouse cursor</li>
		<li>character rendering</li>
	</ul>
	<li>Copy from local memory to frame buffer or back</li>
	<li>Line-drawing. Both vertical, horizontal, and Brezenhelm algorithms can benefit from it</li>
	<li>Drawing continuos curves of nearly any kind</li>
</ul>
Of course there is a downside:
<ul>
	<li>It takes time to set-up the engine and to program the various post-increment values</li>
	<li>Generaly, when arbitrary pixels are needed to be accessed it's not any faster than indirect addressing</li>
	<li>Required address range comparable to paged access</li>
</ul>
 
<h3>Programming information</h3>
<p>
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 <code>video_addr_width</code> number of bits. This register
can be read or written by asserting the cur_stb_i pin in a valid Wishbone cycle.
<p>
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 <code>data_width</code> is less than <code>video_addr_width</code> such a
location cannot be updated in one access. In that case the lower <code>data_width</code> bits of the location written
or read directly form the data bus of the master Wishbone bus when the <code>ACC_STB_I</code> signal is asserted.
The upper part of the location is written to/from the extension register. That register can be accessed by
asserting the <code>EXT_STB_I</code> signal. Pixel memory accesses are performed upon the assertion of the
<code>MEM_STB_I</code> 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.
<p>
The accelerator has 2**accel_size locations.
 
<h3>Wishbone datasheet</h3>
<table border>
<tr><th>Description</th><th>Specification</th></tr>
<tr><td>General Description             </td><td>Monitor controller accelerator.</td></tr>
<tr><td>Supported cycles                </td><td>Slave read/write<br>Slave block read/write<br>Slave rmw<br>
												 Master read/write<br>Master block read/write<br>Master rmw<br></td></tr>
<tr><td>Data port size                  </td><td>Configurable on slave side, same on the master side</td></tr>
<tr><td>Data port granularity           </td><td>Bus size</td></tr>
<tr><td>Data port maximum operand size  </td><td>Bus size</td></tr>
<tr><td>Data transfer ordering          </td><td>Little endien</td></tr>
<tr><td>Data transfer sequencing        </td><td>n/a</td></tr>
<tr><td>Supported signal list and cross reference to equivalent Wishbone signals</td><td>
	<table>
	<tr><th>Signal name</th><th>Wishbone equiv.</th></tr>
	<tr><th colspan="2">Common signals for all ports</th></tr>
	<tr><td>CLK_I       </td><td>CLK_I</td></tr>
	<tr><td>RST_I       </td><td>RST_I</td></tr>
	<tr><th colspan="2">Signals to connect to master</th></tr>
	<tr><td>CYC_I       </td><td>CYC_I</td></tr>
	<tr><td>CUR_STB_I    </td><td>STB_I</td></tr>
	<tr><td>EXT_STB_I    </td><td>STB_I</td></tr>
	<tr><td>ACC_STB_I    </td><td>STB_I</td></tr>
	<tr><td>MEM_STB_I    </td><td>STB_I</td></tr>
	<tr><td>WE_I        </td><td>WE_I </td></tr>
	<tr><td>ACK_O       </td><td>ACK_O</td></tr>
	<tr><td>SEL_I(..)   </td><td>SEL_I()</td></tr>
	<tr><td>ADR_I(..)   </td><td>ADR_I()</td></tr>
	<tr><td>DAT_I(..)   </td><td>DAT_I()</td></tr>
	<tr><td>DAT_O(..)   </td><td>DAT_O()</td></tr>
	<tr><th colspan="2">Signals to connect to the pixel memory</th></tr>
	<tr><td>V_CYC_O       </td><td>CYC_O</td></tr>
	<tr><td>V_STB_O       </td><td>STB_O</td></tr>
	<tr><td>V_WE_O        </td><td>WE_O </td></tr>
	<tr><td>V_ACK_I       </td><td>ACK_I</td></tr>
	<tr><td>V_ADR_O(..)   </td><td>ADR_O()</td></tr>
	<tr><td>v_SEL_o(..)   </td><td>SEL_O()</td></tr>
	<tr><td>V_DAT_I(..)   </td><td>DAT_I()</td></tr>
	<tr><td>V_DAT_O(..)   </td><td>DAT_O()</td></tr>
	</table>
</table>
<h3>Parameter description</h3>
<table border>
<tr><td>Parameter name</th><th>Description</th></tr>
<tr><td>accel_size       </td><td>Address size of the accelerator memory</td></tr>
<tr><td>video_addr_width </td><td>Address size of the pixel memory</td></tr>
<tr><td>data_width       </td><td>Data size of the interfaces</td></tr>
</table>
<h3>Signal description</h3>
<table border>
<tr><th>Signal name</th><th>Description</th></tr>
<tr><th colspan="2">Signals to connect to master</th></tr>
<tr><td>CYC_I       </td><td>Wishbone cycle signal. High value frames blocks of access</td></tr>
<tr><td>CUR_STB_I   </td><td>Wishbone strobe signal. High value indicates cycle to the cursor register</td></tr>
<tr><td>EXT_STB_I   </td><td>Wishbone strobe signal. High value indicates cycle to the extension register</td></tr>
<tr><td>ACC_STB_I   </td><td>Wishbone strobe signal. High value indicates cycle to the accelerator memory</td></tr>
<tr><td>MEM_STB_I   </td><td>Wishbone strobe signal. High value indicates cycle to the pixel memory</td></tr>
<tr><td>WE_I        </td><td>Wishbone write enable signal. High indicates data flowing from master to slave</td></tr>
<tr><td>ACK_O       </td><td>Wishbone acknowledge signal. High indicates that slave finished operation sucessfully</td></tr>
<tr><td>ACK_OI      </td><td>WhisboneTK acknowledge chain input signal</td></tr>
<tr><td>ADR_I(accel_size-1..0)  </td><td>Wishbone address bus signals</td></tr>
<tr><td>SEL_I(data_width/8-1..0) </td><td>Wishbone byte-selection signals</td></tr>
<tr><td>DAT_I(data_width-1..0)   </td><td>Wishbone data bus input (to slave direction) signals</td></tr>
<tr><td>DAT_O(data_width-1..0)   </td><td>Wishbone data bus output (to master direction) signals</td></tr>
<tr><td>DAT_OI(cpu_dat_width-1..0)  </td><td>WhisboneTK data bus chain input signal</td></tr>
<tr><th colspan="2">Signals to connect to the pixel memory</th></tr>
<tr><td>V_CYC_O       </td><td>Wishbone cycle signal. High value frames blocks of access</td></tr>
<tr><td>V_STB_O       </td><td>Wishbone strobe signal. High value indicates cycle to this particular device</td></tr>
<tr><td>V_WE_O        </td><td>Wishbone write enable signal. High indicates data flowing from master to slave</td></tr>
<tr><td>V_ACK_I       </td><td>Wishbone acknowledge signal. High indicates that slave finished operation sucessfully</td></tr>
<tr><td>V_ADR_O(video_addr_width-2..0)  </td><td>Wishbone address bus signals</td></tr>
<tr><td>V_SEL_O(data_width/8-1..0) </td><td>Wishbone byte-selection signals</td></tr>
<tr><td>V_DAT_I(data_width-1..0)   </td><td>Wishbone data bus input (to slave direction) signals</td></tr>
<tr><td>V_DAT_O(data_width-1..0)   </td><td>Wishbone data bus output (to master direction) signals</td></tr>
</table>
 
 
<h2>Author & Maintainer</h2>
<p>
<a href="/people/tantos">Andras Tantos</a>
<!--# include virtual="/ssi/ssi_end.shtml" -->