This chapter describes the LeoDraw ASIC.
The LeoDraw ASIC (U0301, U0401, U0501, U0601, and U0701 on the upper board schematic) receives rendering commands over the CD Bus, executes the command, and renders the pixels to the Frame Buffer. Leo104 has five LeoDraw ASICs, one for each of the five Frame Buffer banks.
Figure 7-1 shows the LeoDraw ASIC block diagram. LeoDraw consists of four primary sections, as follows:
Figure 7-1 LeoDraw ASIC Block Diagram
The DDA bus interface unit monitors the CD Bus for accelerator command packets. Since the type of command is encoded in the first word of the packet, the sequence and format of each word in the packet is known. As successive words are written to LeoDraw, the Controller in this section saves the words in the appropriate double-buffered register. When a complete command is assembled in the register, the interface unit initiates a handshake sequence that loads each word of the command into its respective current buffer register in the DDA unit.
Most of the data in the incoming packet is written directly to the double buffered registers. The data is not modified in any way. All X coordinates are, however, adjusted for the five-way interleave with a single add operation.
The Direct Port Bus Interface Unit monitors the CD Bus for direct port commands. This manages the execution of all direct port commands and the handshake sequence with LeoCommand.
All direct port commands, with a few exceptions, require a Frame Buffer access. Since these resources are controlled by the Memory Control Unit (described later), the direct port control assembles a command and starts a handshake sequence that causes the necessary Frame Buffer access in the Memory Control Unit. Read data sent back to LeoCommand is placed in the Read Buffer. LeoCommand can read this buffer at any time.
The DDA Unit performs edge walking and span interpolation functions for triangles, a simple DDA for vectors, and a pass operation for dots. This unit also computes end point correction, anti-aliasing alpha calculations, and depth cue scale factors.
The output from this section consists of X and Y coordinates, red, green, blue, and depth values, and alpha for every pixel rendered to the Frame Buffer. The DDA Unit generates a new pixel every four clock cycles.
The output is put into a set of double-buffered registers. When an output pixel is complete, a handshake sequence is started that loads the command into its respective double buffered register in the Memory Control Unit.
The Memory Control Unit receives requests for Frame Buffer access from the DDA Unit, the Direct Port Bus Interface Unit, and VRAM and DRAM refresh. The Memory Control Unit arbitrates among these requests and generates the control signals to read or write pixels to the VRAM.
The Memory Control Unit also performs several address- and data-related functions. Address-related functions include address translation, viewport clipping, and page-mode access detection. Data related functions include blending and logical operations on data, Z-buffering, window ID checking, screen door transparency, and so on.
The Memory Control Unit also includes a video refresh counter for transfer VRAM cycles. DRAM refresh is handled using CAS-before-RAS cycles. This unit operates at twice the clock frequency of the rest of the ASIC (at 50 MHz).
LeoDraw has five major interfaces: Frame Buffer, CD Bus, Refresh Control, and external.
Table 7-1 summarizes the Frame Buffer interface signals.
Table 7-1 LeoDraw Frame Buffer Interface Signals
-----------------------------------------------------------------------------------------------
Signal Name No. Pins I/O Type Description -----------------------------------------------------------------------------------------------
LDn_IM_DAT<7:0'> 8 I/O Tri-state Frame Buffer red
LDn_IM_DAT<15:8'> 8 I/O Tri-state Frame Buffer green
LDn_IM_DAT<23:16'> 8 I/O Tri-state Frame Buffer blue
LDn_IM_DAT<31:24'> 8 I/O Tri-state Frame Buffer overlay
LDn_Z_DAT<23:0'> 24 I/O Tri-state Frame Buffer Z (depth)
LDn_WID_DAT<5:0'> 6 I/O Tri-state Frame Buffer P window ID (PWID)
LDn_WID_DAT<9:6'> 4 I/O Tri-state Frame Buffer Q window ID (QWID)
LDn_WID_DAT<15:10'> 6 I/O Tri-state Frame Buffer fast clear
LDn_ADR_R<8:0'> 9 O Bi-state Frame buffer address
LDn_RASA_L_R 1 O Bi-state Frame Buffer RAS for RGB buffer A
LDn_RASB_L_R 1 O Bi-state Frame Buffer RAS for RGB buffer B
LDn_RASZ_L_R 1 O Bi-state Frame Buffer RAS for Z-buffer DRAM
LDn_RAS_L_R 1 O Bi-state Frame Buffer RAS for overlay, fast clear, and WID
VRAMs
LDn_CAS_L_R 1 O Bi-state Frame Buffer CAS for all planes
LDn_WE_L_R 1 O Bi-state Frame Buffer write enable for all VRAMs
LDn_OE_L_R 1 O Bi-state Frame Buffer output enable for all planes
LDn_DSF_R 1 O Bi-state Frame Buffer special function for all planes
-----------------------------------------------------------------------------------------------
Frame Buffer image planes. This bidirectional bus transfers the red, blue, green, and overlay data between LeoDraw and the VRAMs. The red, green, and blue values are double-buffered, and overlay is single-buffered. Data from either buffer A or buffer B can be accessed at a time.
Frame buffer depth planes. This bi-directional bus transfers Z-buffer data between LeoDraw and the VRAMs. The depth is single-buffered.
Frame Buffer control planes: P window ID, Q window ID, and fast clear. This bi-directional bus transfers Frame Buffer control data between LeoDraw and the VRAMs. The control planes are single-buffered.
The image and window ID groups are used for hardware clipping as well as display control on a window basis. The fast clear planes use the VRAM flash write capability to quickly clear windows to background color.
Frame Buffer address. This address bus transfers row and column addresses to all the Frame Buffer VRAM and DRAM devices. The row and column addresses are nine bits each for the 256 \xb4 8 VRAM and 256 \xb4 16 DRAM.
Frame Buffer row address strobes to the VRAM and DRAM devices. Data on the LD_ADR<8:0 lines is strobed into VRAM on the falling edge of LD_RAS_L_R. Image buffer A and buffer B use separate RAS signals: LD_RASA_L_R and LD_RASB_L_R. The DRAMs used for the Z buffer need a separate RAS signal, LD_RAS_Z_L_R, to prevent VRAM color write cycles from being interpreted as memory write signals. The overlay and window planes use the LD_RAS_L_R signal.
Frame Buffer column address strobe to the VRAM and DRAM devices. Data on the LD_ADR<8:0 lines is strobed into VRAM on the falling edge of LD_CAS_L_R. This signal is common to all VRAM and DRAM devices.
Frame Buffer write enable. The falling edge of this signal strobes data on the LD_IM_DAT, LD_Z_DAT, and LD_WID_DAT lines into VRAM and DRAM. This signal is also used to load a fast clear mask into the VRAM for a flash write memory cycle. This signal is common to all VRAM and DRAM devices.
Frame Buffer output enable. When low, this signal enables read data from the VRAM and DRAM devices onto the LD_IM_DAT, LD_Z_DAT, and LD_WID_DAT lines. This signal is common to all VRAM and DRAM devices.
Frame Buffer data special function. The VRAM devices sample this signal on the falling edge of the LD_RAS_L_R and LD_CAS_L_R signals to encode several "special" VRAM cycles. This signal is common to all the VRAM devices. The DRAM devices do not use this signal.
Table 7-2 summarizes the CD Bus interface signals. See Chapter 4, "CD Bus," for more information on this interface.
Table 7-2 LeoDraw CD Bus Interface Signals
---------------------------------------------------------------------------
Signal Name No. Pins I/O Type Description ---------------------------------------------------------------------------
CD_DAT<15:0'> 16 I/O Tri-state CD data bus
ACC_LOAD 1 I Bi-state Load strobe for the accelerator port
DIR_LOADn 1 I Bi-state Load strobe for the direct port
DRAW_ENn 1 I Bi-state LeoDraw drive enable
ACC_BUF_AVLn 1 O Bi-state Accelerator port buffer available
DIR_BUF_AVLn 1 O Bi-state Direct port buffer available
DRAW_INTRn 1 O Bi-state Interrupt to LeoCommand from LeoDraw
---------------------------------------------------------------------------
CD Bus data. This bus transfers commands from LeoCommand or LeoFloat to LeoDraw, read pixel and register data from LeoDraw to LeoCommand, and exchange data between the LeoDraw ASICs during block copy operations.
Load accelerator data or command. This signal is a write strobe for accelerator commands or data. LeoFloat drives the data onto the CD_DAT bus and LeoCommand generates the ACC_LOAD signal. The ACC_LOAD signal is three clock phases before LeoDraw needs to sample data on the CD_DAT lines.
Load direct port data or command, where n defines the LeoDraw ASIC. This signal is a write strobe for direct port commands or data. LeoCommand drives the data onto the CD_DAT bus and asserts the DIR_LOAD signal. The DIR- LOAD signal is one clock phase before LeoDraw samples data on the CD_DAT bus.
Output enable read data, where n defines the LeoDraw ASIC. In response to this signal, LeoDraw enables data in its read buffer onto the CD_DAT bus. Following any read command, LeoDraw puts read data into its read buffer and waits for the DRAW_EN signal to drive data onto the CD_DAT bus.
Accelerator buffer available, where n defines the LeoDraw ASIC. LeoDraw asserts this signal when the direct port is ready to receive a new command. This signal is sent to LeoCommand three cycles before the direct port is really ready, to account for control latency.
Direct port buffer available, where n defines the LeoDraw ASIC. LeoDraw asserts this signal when the direct port is ready to receive a new command. This signal is sent to LeoCommand three cycles before the direct port is really ready, to account for control latency.
LeoDraw interrupt, where n defines the LeoDraw ASIC. On pick-hit or load- semaphore conditions, LeoDraw asserts this signal to send an interrupt to LeoCommand. LeoCommand can determine the condition that caused the interrupt by reading the LeoDraw status register.
Table 7-3 summarizes the LeoCross interface signals.
Table 7-3 LeoDraw LeoCross Interface Signals
----------------------------------------------------------------------------------
Signal Name No. Pins I/O Type Description ----------------------------------------------------------------------------------
XFER_REQ<2:0'> 3 I Bi-state Encoded video refresh request from LeoCross
----------------------------------------------------------------------------------
Transfer request. LeoCross uses these lines to send requests for VRAM transfer cycles during the horizontal and vertical blanking interval. A non-idle request is asserted for one cycle. These signals are encoded as follows:
---------------------------------------------------------------------------------
Bit 2 Bit 1 Bit 0 Meaning ---------------------------------------------------------------------------------
0 0 0 No request (idle)
0 0 1 Not used
0 1 0 Not used
0 1 1 DRAM CAS-before-RAS refresh
1 0 0 Increment video counter, split transfer
1 0 1 Increment video counter, non-split transfer
1 1 0 Initialize video counter = left-even register, use left-even
offset, non-split
1 1 1 Initialize video counter = right-odd register, use right-odd
offset, non-split
---------------------------------------------------------------------------------
Table 7-4 summarizes the external interface signals.
Table 7-4 LeoDraw External Interface Signals
----------------------------------------------------------------------------------------
Signal Name No. Pins I/O Type Description ----------------------------------------------------------------------------------------
TCK 1 I Bi-state JTAG scan clock in. Tied to CLK_25M_LDn.
TDI 1 I Bi-state JTAG scan test data in
TMS 1 I Bi-state JTAG scan test mode select
TDO 1 O Tri-state JTAG scan test data out
LEO_RST_L 1 I Bi-state System reset signal from LeoCommand
TEST_OE 1 I Bi-state Global output enable for test. Normally pulled up.
CLK_25M_LDn 1 I Bi-state 25 MHz clock for the Memory Control Unit
FB_ORING_VSS 16 - - Frame Buffer output ring Vss
FB_ORING_VDD 16 - - Frame Buffer output ring Vdd
CD_ORING_VSS 5 - - CD output ring Vss
CD_ORING_VDD 5 - - CD output ring Vdd
IRING_VSS 4 - - Input ring Vss
IRING_VDD 4 - - Input ring Vdd
CLK_VDD 1 - - Clock Vdd
CLK_VSS 1 - - Clock Vss
CORE_VDD 6 - - Core Vdd
CORE_VSS 6 - - Core Vss
----------------------------------------------------------------------------------------
For a description of the TDI and TDO signals, see "The JTAG Scan In and Out Signals" on page 2 - 19.
This section describes the detailed architecture of the four blocks that make up the LeoDraw ASIC.
The DDA Bus Interface Unit, shown in Figure 7-2, handles the CD Bus interface operations for the LeoDraw accelerator port. This unit unpacks all the incoming data packets from LeoFloat and places them into the corresponding double-buffered registers.
Since there is no address information associated with each set of data, the format of data packets is fixed. The first word of the packet (header) identifies the packet and its format and length. The header is loaded into the first double-buffered register, dbr0. Based on the header information, the control for this unit generates the addresses for the rest of the double-buffered registers, dbr1 through dbr23.
Table 7-5 lists the format of all accelerator port commands. The table also shows the double-buffered register used for each parameter in the command packet.
Note that, except for register dbr0, all formats are 32 bits wide. Since the CD Bus is a 16-bit bus, dbr0 is loaded in a single bus write, while all the other double-buffered registers are loaded by two writes. In these two writes, the least-significant half-word is loaded before the most-significant half-word. Some of these registers are shared by parameters in different commands.
For most interface unit operations, the 16-bit CD_DAT bus is connected directly to the 16-bit output bus, the EW_DB_IN (edge-walk double buffered in) bus. However, all x coordinates are adjusted to the interleave using a single add. Note that only the integer portion of the x address, the most-significant 16 bits for simplicity, need be sent through the adder.
The DDA Bus Control is also responsible for handshaking with the DDA Unit to ensure that double-buffered commands are transferred to the current buffers in an orderly fashion. The contents of all the double-buffered registers can be transferred to their corresponding current buffers simultaneously. This is done by the "load current buffer" (LOAD_CB) signal. Following this transfer, the control asserts the ACC_BUF_AVL signal to allow LeoCommand to load the next command into the double-buffered registers.
Figure 7-2 LeoDraw DDA Bus Interface Unit
Table 7-5 LeoDraw Accelerator Port Command Format
------------------------------------------------------------------------------------------------------
Accelerator Port Commands ------------------------------------------------------------------------------------------------------
Reg # Format Data RGB-Dot Vector RGB- Triangle WR-Reg Fast Clear Raster Write Vector ------------------------------------------------------------------------------------------------------
dbr0 16 bit Header Header Header Header Header Header Header Header
dbr1 32 bit x x us us xs x x
dbr2 32 bit y y vs vs xe2 y y
dbr3 32 bit z z zs zs zs
dbr4 32 bit r r rs Data r
dbr5 32 bit g g gs g
dbr6 32 bit b b bs b
dbr7 32 bit ue ue xe
dbr8 32 bit dzDu dzDu dzDu
dbr9 32 bit drDu drDu
dbr10 32 bit dgDu dgDu
dbr11 32 bit dbDu dbDu
dbr12 32 bit dvDu dvDu dxe2Dv
dbr13 32 bit ys
dbr14 32 bit count12 Count
dbr15 32 bit count13
dbr16 32 bit dxsDv
dbr17 32 bit dxeDv
dbr18 32 bit dzDv
dbr19 32 bit drDv
dbr20 32 bit dgDv
dbr21 32 bit dbDv
dbr22 32 bit
------------------------------------------------------------------------------------------------------
The latencies involved in the handshake protocol need prediction of control signals in advance. The signal is generated in advance based on the state of this unit and the DDA Unit, which is four writes before the last data of the last packet is loaded into the double-buffered registers and four cycles before the DDA Unit finishes execution of the last command. The DDA Unit accomplishes this operation by asserting the DDA_ADV_RDY signal four cycles ahead. The "real" ready signal (DDA_RDY) is generated right after the last command is completed.
The DDA Unit, shown in Figure 7-3, performs edge walking and span interpolation. The name "DDA" comes from the Digital Differential Analyzer algorithm used to draw lines in Leo.
Figure 7-3 LeoDraw DDA Unit Block Diagram
The edge walking function interpolates down triangle edges, generating information for each scan line on which the span interpolation function can operate. See Figure 7-4. For both scan lines and vectors, the edge walker adjusts the end points such that the starting and ending points have integral axis values. For anti-aliased vectors, the edge walker generates the three vectors necessary to paint all appropriate pixels. For anti-aliased dots, the edge walker generates three anti-aliased dots.
The span interpolation function steps pixel-by-pixel across a triangle span (along the X axis) or along a vector (along the major axis) performing all the per-pixel interpolations.
The DDA Unit consists of the following interpolators:
Figure 7-4 DDA Triangle Rendering
The edge walker address interpolator is shown in Figure 7-5.
Figure 7-5 Edge Walker Address Interpolator
The Edge Walker Counters are shown in Figure 7-6.
Figure 7-6 Edge Walker Counters
The Edge Walker ZRGB Interpolation is shown in Figure 7-7.
Figure 7-7 Edge Walker ZRGB Interpolation
The ZRGB Span Interpolator, shown in Figure 7-8, steps pixel-by-pixel across a triangle span (along the X axis) or along a vector (along the major axis), performing all the per-pixel interpolations. The span interpolator accepts Z, R, G, and B data from the Edge Walker ZRGB Interpolator and generates the X, Y, and Z addresses,
Figure 7-8 ZRGB Span Interpolator
The Setup and Generation Unit is shown in Figure 7-9.
Figure 7-9 Setup and Address Generation Unit
The Direct Port Interface Unit, in conjunction with the Memory Interface Unit, executes all the direct port commands. The unit consists of three major blocks, as shown in Figure 7-10:
The Address Computation Unit allows X and Y addresses coming over the CD Bus into the Memory Control Unit. This is the case for all pixel read and write commands. For block copy, vertical scroll, and fill commands, pixel address generation is done in LeoDraw and is described below.
The pixel write command writes data to one of the three plane groups: image, depth, or window. The write operation is performed using either state set 0 or state set 1, as determined by the state set bit in the direct command header.
The pixel read command reads data from one of the three plane groups: image, depth, or window. The read operation is performed using either state set 0 or state set 1 registers.
For stencil write, LeoDraw extracts the data and mask bits from the correct bits in the input packet. If the mask bit is 0, the pixel is not touched. If the mask bit is 1, the pixel is written with the foreground color, the background color is left untouched, based on the data bit and the transparency bit. Stencil operations are possible only in state set 0.
The vertical scroll implementation is a non-pipelined version of the Blt (block transfer). Each vertical scroll command causes a pixel from (xs, ys) Src registers to be written to (xd, yd). Since both the source and destination pixels are in the same LeoDraw chip, no data exchange is needed. Both pixel mode and byte mode vertical scroll operations are possible.
Performance for vertical scroll is expected to be 10M pixels per second in pixel mode and 16M pixels per second in byte mode.
The fill command causes up to four pixels starting at (xd, yd) to be written. Data written is from the stencil/fill foreground register. Memory is accessed with one random and three page-mode read-modify-write cycles.
Performance for fill is expected to be 25M pixels per second.
Block copy is accomplished through three separate instructions: Blt_Read, Blt_Read_Transmit, and Blt_Write_Transmit. Operation of these instructions in pixel mode is given below. In byte mode, four pixels instead of one are read, written, and transmitted with each command.
The Blt_Read instruction causes a pixel to be read from (xs, ys) and read data is put in the block copy read buffer. The xs register is then incremented and the x-source-size register is decremented.
The Blt_Read-Transmit instruction causes a pixel to be read from (xs, ys) and read data is put in the block copy read double buffer. After LeoCommand reads data from the read buffer, data from the double buffer is moved to the read buffer. The xs register is then incremented and the size register is decremented.
The Blt_Write_Transmit instruction copies the data from the write buffer into the write double buffer, and then writes the data to (xd, yd). The xd register is then incremented and the x-destination-size register is decremented. A pixel is then read from (xs, ys) and the read data is put in the block copy read double buffer. After LeoCommand read data from the read buffer, data from the double buffer is moved to the read buffer. The xs register is then incremented and the size register is decremented.
The Memory Control Unit provides the following functions:
LeoDraw viewport clips all memory accesses. This includes all direct port memory accesses and accelerator port accesses. LeoDraw has two viewports, one for each state register set.
There are two viewport clipping registers:
The data format is as follows:
The viewport clipping logic, simplified in Figure 7-11, clips to a single rectangular viewport. This makes guardband clipping clip properly even in cases where the window ID region is larger than the screen space viewport region. The viewport clipping logic performs two range comparisons:
Left Boundary \xa3 X \xa3 Right Boundary
Top Boundary \xa3 Y \xa3 Bottom Boundary
If either comparison fails, the write request is deleted from the queue (the pixel is clipped). Read requests are passed unaffected.
Left Boundary, Right Boundary, Top Boundary, and Bottom boundary are four 11-bit registers in Frame Buffer control space. These registers may be set to any value within the current screen size. For example, for an 1152 by 900 display, Right Boundary must not exceed 1151 and Bottom Boundary must not exceed 899. Viewport clipping is disabled by setting the bounds equal to or greater than the screen size.
Note - The viewport clipping logic only operates on writes that use state set 1 (accelerated).
Figure 7-11 Viewport Clipping Logic
LeoDraw implements all the logical operations supported by Hawk. The logical operations, known as raster operations or ROPs, are specified by four bits in the LeoDraw Attribute register. These bits select the desired boolean ROP as shown in Table 7-6.
Table 7-6 Raster Operations Codes
----------------------------------------------------
ROP Code Boolean Raster Operation (Hex) ----------------------------------------------------
0 DST = all bits zero
1 DST = ~(SRC or DST)
2 DST = ~SRC and DST
3 DST = ~SRC
4 DST = SRC and ~DST
5 DST = ~DST
6 DST = SRC xor DST
7 DST = ~(SRC and DST)
8 DST = SRC and DST
9 DST = ~SRC xor DST
A DST = DST
B DST = ~SRC or DST
C DST = SRC
D DST = SRC or ~DST
E DST = SRC or DST
F DST = all bits one
----------------------------------------------------
LeoDraw support two blending modes: Blend to background and blend to frame buffer. When blending is enabled, raster operations are disabled. When blending is disabled, raster operations are enabled.
Z buffering allows a constant to be written to the Z (depth) planes, which is useful as a WID extension for window clipping. Also useful for parallel pixel mode writes (plane group = `11') of RGBO (state set 1 only).
Four bits in the LeoDraw Attribute register control Z-buffering, as shown in Table 7-7.
Table 7-7 Z-Buffering Control
--------------------------------------------------------
Z-Buffering Bits Control Operations --------------------------------------------------------
17 HSR (hidden surface removal)
16 Z write enable
15 Constant Z enable
14 Window ID (WID) extension clip enable
--------------------------------------------------------
The four Z-buffering control bits for hidden surface removal functions are coded as shown below.
---------------------------------------------------------------------------------------------------------------------------------------------------------
Code Z Compare Z Update Application ---------------------------------------------------------------------------------------------------------------------------------------------------------
0000 No No Don't write Z
01c0 No Yes Write Z, no HSR
10c0 Yes No Write to RGB only, if Z is in front
11c0 Yes Yes Write RGB and Z, if Z is in front
---------------------------------------------------------------------------------------------------------------------------------------------------------
For WID functions, using the Z buffer as a WID extension, the four Z-buffering bits are coded as shown below.
-----------------------------------
Code WID Ext Clip WID Ext Replace -----------------------------------
0010 No No
0011 Yes No
0110 No Yes
0111 Yes Yes
-----------------------------------
Leo has two window ID fields: image and overlay. Leo does not provide a user window ID. As far as LeoDraw is concerned, window IDs are used for hardware clipping. The window ID can also be used for picking.
Leo implements 16 by 16 screen door transparency. Screen door transparency is specified using 16 16-bit screen door column registers. These registers define the 16 by 16 screen door transparency pattern. If the pattern bit is a one, the object is solid (visible) at that pixel. If the pattern bit is a zero, the object is transparent and the pixel is not drawn.
Picking, also known as pick aperture clipping, defines a three-dimensional pick aperture volume. Objects that draw any pixels inside this volume are picked as they pass the subsequent Z buffer test. The pick aperture clipping logic performs three range comparisons:
Left Boundary \xa3 X \xa3 Right Boundary
Top Boundary \xa3 Y \xa3 Bottom Boundary
Front Boundary \xa3 Z \xa3 Back Boundary
If all these comparisons pass, LeoDraw freezes the accelerator pipe after rendering the primitive that causes the pick hit. This preserves the pick ID registers and no update is possible to them. LeoDraw asserts the DRAW_INTRPT to LeoCommand as soon as pick hit is detected.
Leo supports video refresh (interlaced and non-interlaced) from a frame buffer of width 1280. Support for stereo from a frame buffer of width 960 is also provided.
Requests for video refresh are generated by LeoCross and sent to all LeoDraw ASICs over the XFER_REQ<2:0 lines. In stereo mode, XFER_REQ<2:0 =1 00, causes split transfer cycles to be generated.
For a frame buffer of width 1280 (used for 1280 \xb4 1024, 1152 \xb4 900, as well as interlaced NTSC and PAL), a transfer request is generated every horizontal sync. For a frame buffer of width 960 (used for stereo 960 \xb4 680), a request is generated at horizontal sync 1, 2, and 3 and skipped for line 4. The pattern then repeats.
DRAM refresh is supported by CAS-before-RAS VRAM access. LeoDraw has a refresh counter that generates an internal refresh request 512 times every 8 milliseconds.
Before the start of a new frame, LeoDraw clears the appropriate fast clear plane to all zeros (using a special high-speed clear mode) indicating that the values stored in the image and depth planes are invalid for the specified window ID.
As pixels are rendered into the image buffer, LeoDraw writes a one into the fast clear plane at the pixel location, indicating that the image and depth are now valid. During display refresh, all valid pixels (fast clear = 1) are displayed using the color value stored in the image or overlay buffers. Invalid pixels (fast clear = 0) are displayed using the color value stored in the Fast Clear Background Color Register assigned to that fast clear set.
Leo does not treat the fast clear planes as double-buffered. This means that it is necessary to specify one out of eight fast clear planes for use at any time. In addition, two fast clear planes need to be allocated explicitly for double- buffered windows.
Leo uses 2M bit VRAMs organized as 256K \xb4 8. For the Z buffer, 4M bit DRAMs are organized as 256K \xb4 16. Each LeoDraw controls ten VRAMs and two DRAMs.
The maximum load on signals to and from VRAM is 12 loads, or around 100 pF. This is for the VRAM/DRAM address, CAS, WE, and OE signals. No external buffering is needed for these signals.
Figure 7-12 shows the interface between LeoDraw and the Frame Buffer.
Figure 7-12 Frame Buffer Interface Block Diagram
The tables in this section describe the pixel operations for the following plane groups:
Fast Clear Planes, Table 7-8
Window ID Planes, Table 7-9
Image (ORGB) Planes, Table 7-10
Depth Planes, Table 7-11
These tables show the conditions that are checked before a pixel is written to the frame buffer.
The following paragraphs define the information shown in the various columns of the tables.
A "1" indicates that the pixel is in the viewport as defined by the View Clip Minimum Bound and View Clip Maximum Bound registers.
A "1" indicates a Pick Control code (bits 31:29 of LD Attribute register) of 10x - enable picking and do not render while picking.
For each bit that is 1 in the WID Clip Mask register, the bit in FB Data In = Current Window ID data register bit.
H is bit 17 (Hidden Surface Removal enable) of the LD Attribute register.
X is bit 14 (WID extension clip enable) of the LD Attribute register.
For X = 0, H = 0: hsr.win = 1
For X = 0, H = 1: if (Znew <= Zold) hsr.win = 1; else hsr.win = 0
For X = 1, H = 0: if (Znew == Zold) hsr.win == 1; else hsr.win = 0
For X = 1, H = 1: if (Znew == Zold) hsr.win == 1; else hsr.win = 0
This is bit 10 (Fast Clear Enable) of LD Attribute register.
A "1" indicates that the I and D planes are valid.
I = Image (ORGB) planes, Direct Port write or read
D = Depth (Z) plane, Direct Port write or read
W = Window (FC + WID) planes, Direct Port write or read
ID = Image + Depth, Accelerator Port write only or Direct Port write only
The element "Bit M (m, Side 1, Side 0)" means that for each bit in mask m: if m = 0, select Side 0 bit; if m = 1, select Side 1 bit.
"FB Data In" means that data written out to the frame buffer is the same as data read in from the frame buffer. The pixel is not modified.
The first line of Table 7-10 means that for a window access, data is never written out to the frame buffer ORGB planes (Data Out to FB = FB Data In).
The second line of Table 7-10 means that (for an I, D, or ID access) if the pixel is not in the viewport, the pixel is not written (Data Out to FB = FB Data In).
The eighth line of Table 7-10 means that for an I or ID pixel access, if all the conditions to the left of the vertical line are met, then: the data read in from the frame buffer is passed to the ROP and blend units unchanged AND data written out to the frame buffer is the output of the ROP/Bland Unit (under control of the Write Mask).
Table 7-8 Fast Clear Planes
----------------------------------------------------------------------------------------------------------------------------
Pix In Pick WID HSR Win Screen Fast Access Data Out to Frame Buffer Viewport without Match Door Clear Mode Render Write Enable Enable ----------------------------------------------------------------------------------------------------------------------------
1 x x x x x W Bit M (Window Mask, Pipe data,
FB Data In)
0 x x x x x W FB Data In
0 x x x x x I, D, ID FB Data In
x 1 x x x x I, D, ID FB Data In
x x 0 x x x I, D, ID FB Data In
x x x 0 x x I, D, ID FB Data In
x x x x 0 x I, D, ID FB Data In
1 0 1 1 1 0 I, D, ID FB Data In
1 0 1 1 1 1 I, D, ID Bit M (Decode FC Plane, 0x3F, FB
Data In)
----------------------------------------------------------------------------------------------------------------------------
Table 7-9 Window ID Planes
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Pix In Pick WID HSR Win Screen Window Access Data Out to Frame Buffer Viewport without Match Door Enable Mode Render Write Enable ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
x x x x x 0 W FB Data In
0 x x x x 1 W FB Data In
1 x x x x 1 W Bit M (Window Mask, Pipe Data,
FB Data In)
0 x x x x x I, D, ID FB Data In
x 1 x x x x I, D, ID FB Data In
x x 0 x x x I, D, ID FB Data In
x x x 0 x x I, D, ID FB Data In
x x x x 0 x I, D, ID FB Data In
x x x x x 0 I, D, ID FB Data In
1 0 1 1 1 1 I, D, ID Bit M (Window Mask, Pipe Data,
FB Data In)
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Table 7-10 Image (ORGB) Planes
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Pix Pick WID HSR Screen Image Fast Fast Access ROP Data Out to In without Match Win Door Enb Clear Clear Mode or Frame Buffer View Render Write Enb Bit Blend Port Enable Source (SRC) ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
x x x x x x x x W x FB Data In
0 x x x x x x x I, D, ID, x FB Data In
x 1 x x x x x x I, D, ID x FB Data In
x x 0 x x x x x I, D, ID x FB Data In
x x x 0 x x x x I, D, ID x FB Data In
x x x x 0 x x x I, D, ID x FB Data In
x x x x x 0 x x I, D, ID x FB Data In
1 0 1 1 1 1 0 x I, ID FB D In Bit M (Mask,
ROP/Blend Out, FB
Data In)
1 0 1 1 1 1 1 1 I, ID FB D In Bit M (Mask,
ROP/Blend Out, FB
Data In)
1 0 1 1 1 1 1 0 I, ID BG Bit M (Mask,
ROP/Blend Out, BG )
1 0 1 1 1 1 0 x D x FB Data In
1 0 1 1 1 1 1 1 D x FB Data In
1 0 1 1 1 1 1 0 D x BG
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Table 7-11 Depth Planes
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
Pix In Pick WID HSR Screen Z Z Write Fast Fast Access Data Out to Viewport without Match Win Door Group Enable Clear Clear Mode Frame Buffer Render Write Enable Enable Bit Enable -------------------------------------------------------------------------------------------------------------------------------------------------------------------
x x x x x x x x x W FB Data In
0 x x x x x x x x I, D, ID FB Data In
x 1 x x x x x x x I, D, ID FB Data In
x x 0 x x x x x x I, D, ID FB Data In
x x x 0 x x x x x I, D, ID FB Data In
x x x x 0 x x x x I, D, ID FB Data In
x x x x x 0 x x x I, D, ID FB Data In
1 0 1 1 1 1 1 0 x ID, D Znew
1 0 1 1 1 1 1 1 1 ID, D Znew
1 0 1 1 1 1 1 1 0 ID, D Znew
1 0 1 1 1 1 0 0 x ID, D FB Data In
1 0 1 1 1 1 0 1 1 ID, D FB Data In
1 0 1 1 1 1 0 1 0 ID, D 0xFF FFFF
1 0 1 1 1 1 x 0 x I FB Data In
1 0 1 1 1 1 x 1 1 I FB Data In
1 0 1 1 1 1 x 1 0 I 0xFF FFFF
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
Figure 7-13 shows the Direct Port timing for a pixel write operation.
Figure 7-13 Direct Port Pixel Write Timing
Figure 7-14 shows the Accelerator Port timing.
Figure 7-14 Accelerator Port Timing
The following figures show the LeoDraw VRAM interface timing.
Figure 7-15 VRAM Timing - Page RMW
Figure 7-16 VRAM Timing - Random RMW
Figure 7-17 VRAM Timing - Page Read
Figure 7-18 VRAM Timing - Random Read
Figure 7-19 VRAM Timing - Video Refresh (Non-split, Split)
Figure 7-20 VRAM Timing - DRAM Refresh
Figure 7-21 VRAM Timing - Color Register Load
Figure 7-22 VRAM Timing - Flash Write
