This chapter describes the LeoCommand ASIC.
The LeoCommand ASIC, U0401 in the Lower Board schematic, acts as the system controller for all Leo devices and provides the sole interface between the host workstation and the Leo devices. LeoCommand also controls access for data transmission between all Leo devices and the host workstation. A Leo device is any SBus-addressable component on the card, such as the ASICs, boot PROM, and Output RAMDAC.
The device registers and other storage locations accessible to the host workstation are memory-mapped in Leo address space. Graphics and control data are transmitted between Leo and the host workstation over the SBus. LeoCommand generates SBus slave and DMA protocols under control of the SBus interface. As both an SBus slave and DMA master, LeoCommand reads graphics data from host memory in a DMA mode, while the host can load or read Leo registers in programmed I/O mode.
LeoCommand has two ports: direct and accelerator. Both the direct and accelerator ports can read data from host memory and write via the SBus. Both ports can also be accessed by programmed I/O using the LeoCommand internal bus, LC_Main.
Figure 2-1 shows the LeoCommand block diagram. The various blocks are introduced below and described in more detail under "Functional Description" on page 2-21.
The accelerator port reads host memory to transfer linked lists of vertices or pass-through packets containing graphics parameters. All packets processed by the accelerator port are uni-cast or multi-cast on the CF Bus to the LeoFLoat ASICs.
The direct port provides access to all the Leo devices, except the LeoFloat ASICs. The direct port is used mainly for the window system and for access to the Leo registers.
The Central Controller is the principal control for all on-chip and Leo device registers and storage. The Central Controller provides reset and mode controls for context switching and transmits all Leo status flags to the host via polling and maskable interrupt operations.
The Central Controller decodes SBus addresses to control LC_Main Bus distribution to the ports as well as access through the direct port to other Leo devices.
LeoCommand is an SBus slave when the host reads data from or writes data to Leo control and status registers, the Frame Buffer, or the Boot PROM. LeoCommand is an SBus master to read data directly from host main memory and to write to host memory.
Figure 2-1 LeoCommand ASIC Block Diagram
The CX Bus interface is used to access the LeoCross ASICs and output RAMDAC. For example, to access the look-up tables, configuration registers, video timing registers, and so on.
LeoCommand has five major interfaces: SBus, CF Bus, CD Bus, CX Bus, and external port.
Table 2-1 summarizes the SBus interface signals.
Table 2-1 LeoCommand SBus Interface Signals
--------------------------------------------------------------------------------------------------------------------------------------------------------
Signal Name No. Pins I/O Type Description --------------------------------------------------------------------------------------------------------------------------------------------------------
SB_DAT<31:0'> 32 I/O Tri-state SBus data.
SB_ADR<27:0'> 28 I Bi-state SBus physical address.
SB_SIZ<2:0'> 3 I/O Tri-state SBus transfer size.
SB_ACK<2:0_L 3 I/O Tri-state SBus transfer acknowledge.
SB_SEL_L 1 I Bi-state SBus slave select.
SB_RD 1 I/O Tri-state SBus transfer direction.
SB_AS_L 1 I Bi-state SBus address strobe.
SB_LERR_L 1 I/O Bi-state SBus late data error.
SB_BR_L 1 O Bi-state SBus request.
SB_BG_L 1 I Bi-state SBus grant.
SB_RST_L 1 I Bi-state SBus reset.
SB_CLK 1 I Bi-state SBus clock.
SB_INTR_L<5'> 1 O Tri-state SBus interrupt (open drain).
--------------------------------------------------------------------------------------------------------------------------------------------------------
SBus data. Transfers data and virtual addresses. The SBus supports three SBus data formats:
SBus physical address.
Transfer size. Describes the transfer size, as follows:
----------------------------------------------------
SB_SIZ<2:0'> Transfer Size ----------------------------------------------------
000 32-bit, one word (four byte) transfer
001 8-bit transfer
010 16-bit transfer
011 Not used
100 64-bit, four-word burst (not used)
101 64-bit, eight-word burst (not used)
110 64-bit, 16-word burst (not used)
111 Not used
----------------------------------------------------
Transfer acknowledgment. Encoded as follows:
----------------------------------------------
SB_ACK<2:0'> Transfer Acknowledge Meaning ----------------------------------------------
000 Reserved
001 Half-word (data) acknowledgment
010 Reserved
011 Word (data) acknowledgment
100 Rerun acknowledgment (retry)
101 Byte (data) acknowledgment
110 Error acknowledgment
111 Idle/wait
----------------------------------------------
Slave select (one per slave). Indicates that the physical address (PA<27:0) is intended for the receiving slave.
Transfer direction. Asserted, means the master is reading data from the slave. De-asserted, means the master is writing data to the slave.
Address strobe. The address on SB_ADDR<27:0 is valid.
Late data error.
Bus request (one per master). Asserted by LeoCommand to alert the SBus controller that Leo wants to become bus master.
Bus grant (one per master). Asserted by the SBus controller to grant bus mastership of the SBus. Given in response to SB_BR.
Reset. Initializes all SBus devices at power up.
SBus clock. A master clock reference for all SBus devices.
Interrupt request. Requests an interrupt of the host. Leo uses only the level five interrupt.
Table 2-2 summarizes the CF Bus interface signals. See Chapter 3, "CF Bus for more information on this interface.
Table 2-2 LeoCommand CF Bus Interface Signals
--------------------------------------------------------------------------------------------------------------------------------------------------------------
Signal Name No. Pins I/O Type Description --------------------------------------------------------------------------------------------------------------------------------------------------------------
CF_DAT<15:0'> 16 O Bi-state Data for CF Bus.
CF_BUF_AVL<0'> 4 I Bi-state Buffer available from LeoFloat #0
CF_BUF_AVL<1'> 4 I Bi-state Buffer available from LeoFloat #1
CF_BUF_AVL<2'> 1 I Bi-state Buffer available from LeoFloat #2
CF_BUF_AVL<3'> 1 I Bi-state Buffer available from LeoFloat #3
CF_LOAD<0'> 1 O Bi-state Load data into LeoFloat #0
CF_LOAD<1'> 1 O Bi-state Load data into LeoFloat #1
CF_LOAD<2'> 1 O Bi-state Load data into LeoFloat #2
CF_LOAD<3'> 1 O Bi-state Load data into LeoFloat #3
CF_CTL<2:0'> 3 O Bi-state Data type encoding, control.
--------------------------------------------------------------------------------------------------------------------------------------------------------------
This bus sends data from LeoCommand to the LeoFloat ASICs. Data is sent in packets of less than 32 words (32-bits). These words are sent in either a packed format or an unpacked format. In the packed format, a 32-bit word is converted from floating point to a 16-bit fraction and sent to LeoFloat in one clock cycle. In the unpacked format, a 32-bit word is sent to LeoFloat in two clock cycles. The lower 16 bits are zero-extended to create a 32-bit word in LeoFloat. The upper 16 bits are sent the following clock cycle and overwrite the zero extension of the previous clock cycle. A 16-bit word can also be sent in unpacked format. The word is sent in one clock cycle and is zero-extended to create a 32-bit word in LeoFloat.
Each LeoFloat ASIC sends a `buffer available' signal to LeoCommand.
CF_BUF_AVL<0 = LeoFloat #0 buffer available
CF_BUF_AVL<1 = LeoFloat #1 buffer available
CF_BUF_AVL<2 = LeoFloat #2 buffer available
CF_BUF_AVL<3 = LeoFloat #3 buffer available
This signal indicates to LeoCommand that in three phases (half clock cycles) the input buffer can accept data. The latency from the `buffer available' signal going active to data on the CF_DAT pins is three phases. LeoFloat should try to predict in advance that its input buffer will become available to hide the latency.
Each LeoFloat receives a `load' signal from LeoCommand.
CF_LOAD<0 = Load LeoFloat #0
CF_LOAD<1 = Load LeoFloat #1
CF_LOAD<2 = Load LeoFloat #2
CF_LOAD<3 = Load LeoFloat #3
This signal indicates to the LeoFloat that it should receive the data on the CF_DATA pins according to the encoding on the control bits.
These encoded bits describe the word format of the data on the bus. The end of the packet is also encoded on these bits. The code for the last word will also indicate whether the packet should be read or written to SRAM. The start of execution and interruption of the LeoFloat microprocessor is covered by one of the codes. Table 2-3 lists the encodings.
Table 2-3 CF_CTL<2:0 Encoding
-----------------------------------------------------------------------------------------------
CF_CTL<2:0'> Format LeoFloat Operation -----------------------------------------------------------------------------------------------
000 Packed Load 16-bit fraction, convert to floating point
001 Packed Load 16-bit fraction, convert to floating point. End of packet.
010 Unpacked Load 16-bit upper half of 32-bit word.
011 Unpacked Load 16-bit upper half of 32-bit word. End of packet.
100 Unpacked Load 16-bit lower half of 32-bit word, zero extend.
101 Unpacked Load 16-bit upper half of 32-bit word, SRAM read.
110 CF_DAT<0 = 1 Reset all LeoFloats (CF_LOAD = 0).
CF_DAT<0 = 0 Interrupt/run (push PC onto the stack, jump to 0; run if halted).
111 Unpacked Load 16-bit upper half of 32-bit word. SRAM write. End of packet.
-----------------------------------------------------------------------------------------------
Table 2-4 summarizes the CD Bus signals. See Chapter 4, "CD Bus for more information on this interface.
Table 2-4 LeoCommand CD Bus Interface Signals
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Signal Name No. Pins I/O Type Description ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
CD_DAT<15:0'> 16 I/O Tri-state Main data bus.
ACC_LOAD 1 O Bi-state Accelerator port load to all LeoDraw ASICs.
DIR_LOAD<4:0'> 5 O Bi-state Direct port load to each LeoDraw ASIC.
DRAW_EN<4:0'> 5 O Bi-state Drive enable for each LeoDraw ASIC.
ACC_BUF_AVL<4:0'> 5 I Bi-state LeoDraw accelerator port buffer available.
DIR_BUF_AVL<4:0'> 5 I Bi-state LeoDraw direct port buffer available.
DRAW_INTR<4:0'> 5 I Bi-state LeoDraw interrupt occurred.
FLT_EN<3:0'> 4 O Bi-state Drive enable for each LeoFloat ASIC.
FLT0_ST<1:0'> 2 I Bi-state Status of LeoFloat #1.
FLT1_ST<1:0'> 2 I Bi-state Status of LeoFloat #2.
FLT2_ST<1:0'> 2 I Bi-state Status of LeoFloat #3.
FLT3_ST<1:0'> 2 I Bi-state Status of LeoFloat #2.
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
These are the 16 data pins for the CD Bus. LeoCommand determines which chip drives the bus and which chip (or chips) load data from the bus. LeoCommand drives the bus high if no one else is driving the bus.
LeoCommand uses this signal to load data into the accelerator port buffer.
LeoCommand uses these signals to tell one or more LeoDraw ASICs to load data into the direct port buffer.
DIR_LOAD<0 = Load to LeoDraw #0 from CD Bus
DIR_LOAD<1 = Load to LeoDraw #1 from CD Bus
DIR_LOAD<2 = Load to LeoDraw #2 from CD Bus
DIR_LOAD<3 = Load to LeoDraw #3 from CD Bus
DIR_LOAD<4 = Load to LeoDraw #4 from CD Bus
LeoCommand uses these signals to tell one of the LeoDraw ASICs to drive the CD_DATA lines.
DRAW_EN<0 = Enable LeoDraw #0 output to CD Bus
DRAW_EN<1 = Enable LeoDraw #1 output to CD Bus
DRAW_EN<2 = Enable LeoDraw #2 output to CD Bus
DRAW_EN<3 = Enable LeoDraw #3 output to CD Bus
DRAW_EN<4 = Enable LeoDraw #4 output to CD Bus
This signal indicates when a LeoDraw ASIC is ready to accept a new accelerator port command. This signal goes inactive when the first word of the command is written into the accelerator port double buffer. If an accelerator port packet is interrupted by a direct port command, LeoCommand disregards the ACC_BUF_AVL signal until the start of the next packet.
ACC_BUF_AVL<0 = LeoDraw #0 accelerator buffer available
ACC_BUF_AVL<1 = LeoDraw #1 accelerator buffer available
ACC_BUF_AVL<2 = LeoDraw #2 accelerator buffer available
ACC_BUF_AVL<3 = LeoDraw #3 accelerator buffer available
ACC_BUF_AVL<4 = LeoDraw #4 accelerator buffer available
This signal indicates when a LeoDraw ASIC is ready to accept a new direct port command. This signal goes inactive as soon as the first word of the command is received. For a `read' command, the signal remains inactive until the required data is in the LeoDraw ASIC's output buffer. For a `write' command, the signal remains inactive until the direct port input buffer becomes available again.
DIR_BUF_AVL<0 = LeoDraw #0 direct port buffer available
DIR_BUF_AVL<1 = LeoDraw #1 direct port buffer available
DIR_BUF_AVL<2 = LeoDraw #2 direct port buffer available
DIR_BUF_AVL<3 = LeoDraw #3 direct port buffer available
DIR_BUF_AVL<4 = LeoDraw #4 direct port buffer available
These signals indicate that an interrupt occurred in one of the LeoDraw ASICs.
DRAW_INTRPT<0 = LeoDraw #0 interrupt
DRAW_INTRPT<1 = LeoDraw #1 interrupt
DRAW_INTRPT<2 = LeoDraw #2 interrupt
DRAW_INTRPT<3 = LeoDraw #3 interrupt
DRAW_INTRPT<4 = LeoDraw #4 interrupt
LeoCommand uses these signals to tell one of the LeoFloat ASICs to drive the CD_DATA lines.
FLT_EN<0 = Enable LeoFloat #0 output to CD Bus
FLT_EN<1 = Enable LeoFloat #1 output to CD Bus
FLT_EN<2 = Enable LeoFloat #2 output to CD Bus
FLT_EN<3 = Enable LeoFloat #3 output to CD Bus
Each LeoFloat ASIC (0, 1, 2, and 3) sends its encoded status to LeoCommand. LeoCommand remembers the order of the packets into the LeoFloat ASICs to maintain the same order out of the LeoFloat ASICs into the LeoDraw ASICs. However, each input packet can generate zero, one, or more output packets. Also, some output packets are sent to LeoCommand rather than to LeoDraw. Each LeoFloat sends this information to LeoCommand with its two status bits.
The two status bits are encoded as follows:
00 = No action
01 = Request last word of current packet
10 = Request next word of current packet
11 = Request last word of not last packet
The LeoFloat ASIC status generator operates in one of three modes: idle, LeoDraw output, or LeoCommand output. With the mode information and the status, LeoCommand performs the action described in Table 2-5.
---------------------------------------------------------------------------------------------------------------
LeoFloat Mode FLT_ST<1:0'> LeoCommand Action ---------------------------------------------------------------------------------------------------------------
Idle 00 No Action.
01 Null packet. The next input packet generates no output packets.
10 Request to LeoDraw. LeoFloat requests to send an output packet to LeoDraw.
LeoFloat continues to request until it sees FLT_ENABLE. Change to LeoDraw
output mode.
11 Request to LeoCommand. LeoFloat requests to send an output packet to
LeoCommand. LeoFloat continues the request until it sees FLT_ENABLE.
Change to LeoCommand output mode.
LeoDraw Output 00 No action.
01 Request for last word of last output packet. LeoFloat requests to send the last
word of the last output packet associated with the input packet currently being
processed. LeoFloat continues the request until FLT_ENABLE and then returns
to Idle mode.
10 Request for another word of present output packet. LeoFloat requests to send
another word of the present output packet. The request is repeated until
FLT_ENABLE.
11 Request for last word of not-the-last output packet. LeoFloat requests to send
the last word of this output packet. After receiving FLT_ENABLE and sending
the word, LeoFLoat returns to Idle mode.
LeoCommand 00 No action.
Output
01 Request for last word of last output packet. LeoFloat requests to send the last
word of the last output packet associated with the input packet currently being
processed. LeoFloat continues the request until FLT_ENABLE and then returns
to Idle mode.
10 Request for last word of not-the-last output packet. LeoFLoat requests to send
the last word of this output packet. After receiving FLT_ENABLE and sending
the word, LeoFloat returns to Idle mode.
11 Request for another word of present output packet. LeoFloat requests to send
another word of the present output packet. The request is repeated until
FLT_ENABLE.
---------------------------------------------------------------------------------------------------------------
Table 2-6 summarizes the CX Bus interface signals. See Chapter 5, "CX Bus for more information on this interface.
Table 2-6 LeoCommand CX Bus Interface Signals
-----------------------------------------------------------------------------------------------------------------------------------------------------
Signal Name No. Pins I/O Type Description -----------------------------------------------------------------------------------------------------------------------------------------------------
CX_DAT<7:0'> 8 I/O Tri-state Address and data bus
PROM_CS_L 1 O Bi-state Boot PROM chip enable
LX_CE_L 1 O Bi-state LeoCross chip enable
CX_DAC_CS_L 1 O Bi-state Output RAMDAC chip enable
CX_R_WL 1 O Bi-state Read or write enable
CX_CTL<2:0'> 3 O Bi-state CX Bus control
-----------------------------------------------------------------------------------------------------------------------------------------------------
This bus contains addresses or data for the LeoCross ASICs, to load look-up tables and programmable registers, which determine LeoCross operational functions.
The chip enable line for the Boot PROM. When asserted, the Boot PROM enables its data onto the CX Bus data lines. Although not directly involved with the CX Bus, this device is mentioned here to emphasize the fact that LeoCommand must produce this signal and because the CX Bus data lines are used to convey Boot PROM data. The Boot PROM address lines and the remaining control lines reside on the CD Bus.
The chip enable line for LeoCross. When asserted, LeoCross monitors the CX Bus for requested activities.
The chip enable line for the Output RAMDAC. When asserted, the Output RAMDAC monitors the CX Bus for requested activities.
CX Bus read or write enable. When this signal is low, LeoCommand drives the CX Bus. Depending on which devices are enabled at the time, LeoCross takes the bus information and performs a write operation to the specified register.
When this signal is high, LeoCross performs the read cycle. Within a specified number of clock cycles, the enabled LeoCross drives its requested data (set by CX_CTL<2:0, and its internal address register) onto the CX Bus.
CX Bus control. These signals are derived from the SBus address and are used to differentiate between direct and indirect accesses. They also provide the direct access device address. The exact meaning of these control bits depends on whether LeoCommand is accessing the LeoCross or the Output RAMDAC, as defined by the CX_CE and CX_DAC_CS_L signals, as shown in Table 2-7.
Table 2-7 CX Bus Control Signals
-----------------------------------------------------------
CX_CTL -----------------------------------------------------------
Select C2 C1 C0 Description Access -----------------------------------------------------------
LeoCross 0 0 0 LeoCross address pointer Direct
LeoCross 0 0 1 LeoCross control registers Indirect
LeoCross 0 1 0 LeoCross color tables Indirect
LeoCross 0 1 1 Video frame counter Direct
LeoCross 1 0 0 Cursor address pointer Direct
LeoCross 1 0 1 Cursor CSR Direct
LeoCross 1 1 0 Shadow cursor address Direct
LeoCross 1 1 1 Cursor functions Indirect
RAMDAC 0 0 0 RAMDAC address pointer Direct
RAMDAC 0 0 1 RAMDAC color table Indirect
RAMDAC 0 1 0 RAMDAC control register Indirect
RAMDAC 0 1 1 RAMDAC mode register Direct
-----------------------------------------------------------
The external interface contains those signals required to keep synchronization among chips, the light pen input, and to interface with JTAG for test and diagnostics. Table 2-8 summarizes the LeoCommand external interface signals.
Table 2-8 LeoCommand External Interface Signals
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
Signal Name No. Pins I/O Type Description -------------------------------------------------------------------------------------------------------------------------------------------------------------------
CLK_25M_LC 1 I Bi-state 25 MHz (40 ns) clock.
TEST_OE 1 I Bi-state Output enable. Normally pulled high.
VERT_INTR 1 I Bi-state Vertical blanking interrupt.
TCK2, TCK1 1 I Bi-state JTAG clock. Tied to CLK_25_LC.
SCAN_TMS 1 I Bi-state JTAG test mode select.
SCAN_TDI 1 I Bi-state JTAG data in from the test fixture.
CMD_TDO 1 O Bi-state JTAG data out to the first LeoFloat ASIC.
SCAN_RST_L 1 I Bi-state JTAG scan reset.
BURN_IN 1 I Bi-state Burn in.
RESET_L 1 O Bi-state Reset. Derived from SBus reset.
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
This input signal drives the on-chip clock generator. It is a symmetrical clock with a nominal 40 nanosecond period. It is used to derive the chip internal clocks PHASE_A and PHASE_B.
Figure 2-2 shows the system clock (CLK_25) and the two chip internal clocks. The PHASE_A and PHASE_B clocks are non-overlapping, with time Td1 or Td2 between the falling edge of one and the rising edge of the other. LeoCommand is designed with transparent latches that are open during the phase and closed at the falling edge of the phase.
Figure 2-2 PHASE_A and PHASE_B Clocks
A global test pin driven by the board tester to tri-state all output pins.
Vertical blanking interrupt signal.
A free-running test clock signal imposed by JTAG. Connected to the 25 MHz Leo clock, CLK_25M_LC.
A JTAG test mode select signal.
A JTAG test data input signal.
JTAG test data output signal.
This input is a reset signal used to initialize some of the chip internal nodes.
Burn in signal.
Becomes the LEO_RST_L signal. Derived form the SBus reset signal, SB_RST_L.
The JTAG scan input and output signals run serially through all the ASICs on both the upper and lower Leo boards, as shown in Figure 2-3. The scan in and out signals simply verify that all ASICs on both boards are installed and that the two boards are properly connected.
Figure 2-3 JTAG Scan In and Out Signals
When the board is under test, the JTAG_MPR_L signal is asserted low to disable the internal 25 MHz clock and enable the JTAG clock, JTAG_TCK. See Figure 2-4. This allows the tester to bypass the internal clock and provide the source of the Leo clock.
Figure 2-4 Sources of Leo Clock Signal
For simplicity, LeoCommand is described in four parts: the SBus interface, accelerator port, direct port, and central controller.
The SBus interface, shown in Figure 2-5, operates in two separate time domains: Sbus and Leo. At the top of the figure is the SBus time domain, representing portions of the interface that operate at the SBus clock frequency (between 16 MHz and 25 MHz). Below the center horizontal line in the figure is the Leo time domain, representing portions of the interface that operate at the Leo clock frequency (25 MHz).
In addition to the logic shown in the figure, several of the LeoCommand registers also operate in the SBus time domain. The remainder of the registers operate in the Leo time domain.
LeoCommand acts as an SBus slave when the host reads or writes data to Leo control and status registers, the Frame Buffer, or the Boot PROM. All commands to Leo are memory-mapped. The SBus slave interface supports the following SBus transfer sizes:
Figure 2-5 SBus Interface Block Diagram
Figure 2-6 shows the operation of an SBus slave read.
Figure 2-6 SBus Slave Read Operation
Figure 2-7 shows the operation of an SBus slave write.
Figure 2-7 SBus Slave Write Operation
LeoCommand acts as an SBus master to read data directly from the host workstation main memory. The host sets up this process by writing a physical address (word address) and a word count to double-buffered registers in LeoCommand. The host then writes to the location that tells LeoCommand to begin the DMA operation. The "DMA_active" bit is set.
The Physical Address register is loaded differently than all other Leo registers - two write operations are involved. The first write loads SB_ADR<21:0 into the low order 22 bits of the register. The second write, to the same location, loads SB_DAT<21:12 into the high order ten bits of the register.
The SBus master interface can be configured to use the following transfer sizes:
------------------------------------------------------
Transfer Code Meaning ------------------------------------------------------
000 32-bit one word transfer
001 32-bit byte transfer
010 32-bit half word transfer
011 Illegal
100 64-bit SBus, four word burst transfer
101 64-bit SBus, eight word burst transfer
110 64-bit SBus, 16 word burst transfer
111 Illegal
------------------------------------------------------
The four SBus status bits, which are read-only, are as follows:
------------------------
Bit Meaning ------------------------
1 SBus error
2 DMA active
3 PA/count #1 loaded
4 PA/count #2 loaded
------------------------
Context switch is not allowed whenever there is a physical address in the SBus address generator. Once the host begins a DMA activity, it must go to completion before doing a context switch.
Figure 2-8 shows the operation of an SBus master write.
Figure 2-8 SBus Master Write Operation
Figure 2-9 shows the operation of an SBus master read.
Figure 2-9 SBus Master Read Operation
If the SBus master is set up to do burst transfers, the first address is not aligned to the burst size. The SBus does address wrapping and LeoCommand throws away the unwanted data at the end of the transaction. All following address are aligned to the transfer size.
Four-word transfers have addresses ending in "0000". Eight-word transfers have addresses ending in "00000". LeoCommand throws away data at the end of the first and last transfer.
Figure 2-10 through Figure 2-15 show the SBus timing.
Figure 2-10 LeoCommand SBus - SBus Domain Register Writes
Figure 2-11 LeoCommand SBus - SBus Domain Register Reads Timing
Figure 2-12 LeoCommand SBus - Leo Domain Register Writes Timing
Figure 2-13 LeoCommand SBus - Leo Domain Register Reads Timing
Figure 2-14 LeoCommand SBus - Leo as SBus Master, Table Walk Timing
Figure 2-15 LeoCommand SBus - Leo as SBus Master, Read DMA (32-Byte Burst) Timing
The accelerator port, shown in Figure 2-16, performs the following functions:
The LeoCommand accelerator port provides graphics functions that pre- process vertex data contained in vertex display lists. Coordinates and other vertex data are organized into packets that are transmitted from memory to the accelerator port through the SBus. The packets are loaded into the Bucket Buffer either through the DMA data path or through the internal LC_Main bus from the SBus slave interface. A sync buffer in the DMA path synchronizes incoming data between different clock rates.
Under control of the Input Controller state machines, writes to the Bucket Buffer are sequential, which emulate a FIFO storage mechanism. Registers of the list control file, which were pre-loaded from the host via LC_Main, define packet parameters and graphics operations on all vertices of the current list.
Figure 2-16 LeoCommand Accelerator Port Block Diagram
Operations on a vertex begin when a complete packet has been loaded and the loading for the next packet has begun. The output of the Bucket Buffer feeds the Format Converter. The Format Converter performs format unpacking, numerical conversion to 32-bit IEEE floating-point format, and reordering of vertex data to standardize address locations within a vertex packet. The new packet format is then stored sequentially in one of four vertex locations in the Vertex Buffer.
The Format Controller generates read addressing to the Bucket Buffer, write addresses to the Vertex Buffer, and controls for all format conversions. The Format Controller also passes pointers to the Output Controller. These pointers define which vertices form the next primitive and the transmission order of vertices within the larger primitive packet sent to LeoFloat.
When the transmission of a primitive packet to a LeoFloat frees a vertex packet location in the Vertex Buffer, the next vertex begins flowing through the Format Converter to fill the replacement location. When sufficient vertices have been loaded to define the current primitive, this new set of vertices or primitive packet flows from the Vertex Buffer into the Vertex Converter and then out onto the CF Bus to the LeoFloat ASICs.
The Vertex Converter performs specified substitutions and reordering operations on vertex data as specified by pointers from the Format Controller and flags from the List Control File. These operations and read address sequencing from the Vertex Buffer are controlled by the Output Controller, which also sequences primitive packet data to the CF Bus.
After processing the vertex data, the Vertex Converter compresses certain vertex data from 32-bit floating point to 16-bit fixed notation to reduce transmission time for primitive transfer on the CF Bus.
As shown in the block diagram, the internal LC_Main bus provides context switching and diagnostic access to the accelerator port buffers and registers. Pass-through packets also flow through the accelerator port, bypassing the Vertex Buffer and processing functions.
The LeoCommand accelerator port executes commands in two modes:
In the DMA mode, the accelerator port fetches data by way of DMA reads from host memory, and stores the data in the Bucket Buffer. In the immediate mode, a host process builds the above data in the Bucket Buffer by writes to buffer locations via the SBus slave interface.
In both modes, the required state and list control registers, such as the translation or other control registers, are pre-loaded via the slave interface. Processing starts upon packet load completion or, in the immediate mode, by a host-to-slave write to a group of memory-mapped addresses. After packet loading and initiation, operations and controls for both modes are identical.
The addresses of accelerator port registers are specified by multiple mappings in memory. For pass-through (unprocessed, transparent), packets of data and diagnostic operations, unique memory maps include:
For packet list processing operations, unique memory maps include:
The action of writing to a memory-mapped location via the slave interface sets a flag, which initiates the operations defined by pre-loaded list control registers.
The graphics data read from the host memory is organized in groups or packets of 32-bit words. Packets are of two types: vertex and pass-through. Each vertex packet contains vertex data for some triangle, vector, or dot and is processed as it flows through the accelerator port. A pass-through packet contains data that are transparent to any packet processing functions.
One or more vertex packets comprise a vertex list, while one or more pass- through packets comprise a pass-through list. Pre-loaded list control registers specify the input packet size. All pre-loaded list control registers remain unchanged for the duration of either list passage through the port.
Due to limitations on the size of the LeoFloat input buffer, the Bucket Buffer can accommodate lists of one or multiple packets or pass-through packets of variable size up to a 32 word maximum. For lists of multiple packets of greater than 16 words, the Bucket Buffer can store only one complete packet while partially loading a second packet in what remains of the other 16 words.
The special structure of the Vertex Buffer accommodates only four 16-word sub-buffers for standard vertex formats.
To control accelerator port operations, the host must load register flags into the list control file via writes from the slave interface. These registers are loaded first and then the vertex or pass-through list functions are initiated. Accesses to these registers are held constand so that changes cannot occur until the vertex or pass-through list is exhausted. Data contained in this file include packet descriptors, vertex parameters, format conversion operators, vertex processing flags, and special headers.
After a vertex packet is loaded into the Bucket Buffer, the accelerator port begins processing the packet. A sequence of vector conversion operators is read from registers to control the reformatting and numerical conversion of diverse vertex types into a standard format.
The vector conversion operators define the numerical operation to be performed on data randomly accessed from the Bucket Buffer. A five-bit relative address field offset from a packet base pointer locates the 32-bit operand, while a three-bit field defines the operation performed. See Table 2-10 on page 2-50.
Packed eight-bit colors and packet 16-bit normals are converted to IEEE 32-bit floating point numbers. Other 32-bit floating point numbers are read from the buffer, un-modified. Double precision 64-bit floating point numbers are reduced to single precision by truncation of the significand and modification of the exponent, as required.
The order in which the vertices of a primitive are transmitted form a part of the graphics transformation. The accelerator port performs a number of vertex ordering operations that modify the number and order of vertices per primitive. These operations are:
The operations are specified by the input vertex header and the list control file flags.
Vertex replacement operations specify how the following primitive relates to prior primitives of a list. A vector or edge may share a common vertex, while a triangle may share one edge or no edges if a restart occurs within the list. The orientation of a triangle to its predecessor is determined by which vertex of the prior primitive, Vo, Vm, Vn [6]) is replaced. Flags in the header of Vn of the last triangle indicate whether Vo or Vm should be replaced to form the next primitive. For XGL, Vo is used as the control header for the later functions.
To accommodate front/back facing handedness, triangle vertices are ordered for transmission on the CF Bus by representation of clockwise triangles as vertex order: Vo, Vm, Vn. The standard triangle primitive format transmitted on the CF Bus is shown in Figure 2-17.
Figure 2-17 Standard Triangle Primitive Format
The vertex order for counter-clockwise triangles is: Vm, Vo, Vn. For clockwise handedness with oldest vertex replacement, the reordering is first and every other triangle clockwise, and the rest counter-clockwise. For clockwise handedness with Vm, mid-vertex replacement, the reordering would be the first and subsequent triangles clockwise.
When a restart occurs, a header flag and list control register flags define the initial rotation of the first triangle following restart. The handedness specifies the vertex input order of precedence for LeoFloat computations. These derive the surface normal for front or back facing.
For edge hilighting of triangles, a vertex list is first processed without hilighting, and then repeated with edge highlight flags enabled. In this case, if two edges are specified, two vector primitives are output to the LeoFloat for one triangle. The highlight flags for the current primitive are carried in the new, Vn, vertex header, or Vo for XGL.
When a discontinuity in a list occurs because two isolated primitives do not share a common vertex, a restart flag is enabled in the Vn vertex. After the latter primitive has been off-loaded, a complete set of new vertices must now define a next primitive. In this case, the contents of the Vertex Buffer are discarded and a reload initiated.
A vertex contains coordinates and optional colors and normals components. A header and one or more vertices define a primitive packet. The accelerator port provides several substitution operations that modify the standard primitive packet with multiple vertices. These substitutions are:
These operations are specified by the index vertex header and the list control register flags.
When the normals flag is active, the normal of the Vn vertex is replicated across all vertices of a triangle. If the normal flags also specify a forced substitution of a color/normal component, one of two alternate components from the list control registers are forced. A header containing destination and dispatch operations codes for LeoFloat is always added as the first 16-bit word of a CF Bus transmission.
To compensate for the narrower 16-bit CF Bus width, the accelerator port provides two functions:
Under control of list control option flags, lesser precision normals and colors are converted from 32-bit floating point to 16-bit fixed-point fraction as a sign and magnitude number. LeoFloat converts the 16-bit fixed-point fraction back to 32-bit floating point at its input.
Data is transferred from the host in the DMA mode by the SBus operating at clock rates of 20 or 25 million 32-bit words per second. The Sync Buffer performs a rate reduction and synchronization of the 32-bit words. The Sync Buffer is burst-loaded by DMA while it is unloaded by the Accelerator Input Controller at a peak rate of 12 million single words per second. The Sync Buffer signals when it is ready to unload a word to the Bucket Buffer.
The list control file is a set of list control registers. These registers are loaded via the LC_Main bus from the SBus slave input. The list control file specifies the destination, accelerator mode, primitive header, and packet/vertex processing fields. These fields and headers control accelerator functions for all packets of pass-through and display lists.
The list control file is loaded prior to the start of a new list and remains constant until the list packet count expires. To process vertex packets through the Format Converter, vector conversion operators (VCS Ops) are read from the file to random-access vertex data from the Bucket Buffer, and convert it.
Other control fields are passed down to the Format and Output Controllers for loading and output operations from the Vertex Buffer. Single buffering of these registers is provided. Host software disallows loading of the file too soon after the prior list vertex count has expired. Accelerator port status flags signal when the Bucket Buffer is empty. For context switch operation, the list control file may be saved or restored by programmed I/O operations via the SBus slave.
The input Bucket Buffer is a dual-port RAM buffer with 32 words of 32 bits, for temporary storage of accelerator port incoming packets. Each incoming packet initial address is marked by a packet base pointer.
Three addressing modes are controlled by the Accelerator Input Controller:
During normal FIFO operation, the Bucket Buffer receives a new packet base pointer pointing to the last packet location plus one, when the previous packet loading is complete. The latter packet base pointer is passed to a multiple- pointer FIFO. FIFO packet outputs require queueing if the LeoFloat processing delays back up the Accelerator pipeline.
From the Bucket Buffer output, pass-through packets are directed to LeoFloat, bypassing vertex processing.
The Input Controller coordinates the input of display list and graphics parameter data to the accelerator pipeline. The Accelerator Input Controller controls the flow from the DMA and slave SBus interfaces into the Bucket Buffer. The controller is composed of a buffer pointer queue and two sequencers: a Bucket Buffer Sequencer and a DMA Data Sequencer.
The Bucket Buffer Sequencer is a state machine that controls the following functions:
The Bucket Buffer Sequencer controls the address generation and write enables for all loading operations into the Bucket Buffer. The content of the packets loaded into the buffer are generally transparent to the Bucket Buffer Sequencer in either the DMA mode from the Sync Buffer or the immediate mode from the SBus slave. The Bucket Buffer Sequencer generates write address relative to the packet base pointer, which points to the first 32-bit word of the packet.
Because the number and size of the packets vary, the multiple packets stored in the Bucket Buffer have several interim pointers. Since the buffer addresses wrap in a FIFO mode, the available space is computed from the base pointer of the first and last packets in the buffer. If sufficient space is available, as indicated by the Accelerator Port Status register, the next DMA transfer is initiated.
In the Immediate mode, relative addresses are supplied from the SBus slave and writes occur randomly relative to the packet base pointer. In either case, when the packet size count expires or an Immediate mode initiate occurs, the next packet base pointer is loaded as the current pointer address plus packet size.
The DMA Data Sequencer is a state machine that performs the following functions in the DMA mode:
When the DMA mode is activated, the Sequencer monitors the Sync Buffer Data Available flag. If the flag is a one, a word is written to the Bucket Buffer and the buffer address is incremented. This action continues to assemble a packet until the total word count reaches the word size, or the Sync Buffer Data Available flag goes to zero. The latter condition indicates the SBus DVMA control has requested a new burst of list data from host memory or the end of the list has been reached. In the latter case, the DMA mode turns off.
When the Sync Buffer Data Available flag has remained true sufficiently for the assembled words to reach packet size, the packet pointer is sent to the address queue. A new address pointer for the next packet is then generated at the last Bucket Buffer address plus one, and assembly of the next packet started. If the address queueing FIFO was empty, the last packet pointer write actuates a Packet Ready signal to the Format Controller. When the FOrmat Controller reads and empties the queueing FIFO, the Packet Ready signal turns off.
The Format Converter, shown in Figure 2-18, unpacks and modifies vertex data into IEEE 32-bit floating point data from fixed point or other representations. Incoming 32-bit floating point vertex data are not modified for underflow, overflow, or other purpose. Input numerical vertex data is converted as shown in Table 2-9. The table shows the acceptable numerical ranges of fixed-point numbers, N, and 64-bit floating-point numbers, FD, which are input from the host. Traversal software must guarantee these ranges to avoid port computation errors.
Table 2-9 LeoCommand Format Converter
--------------------------------------------------------------------------------------------------------------------------------------
Numerical Conversions Input Range Output FP Limits Conversion F = S \xb4 2(e + 127) --------------------------------------------------------------------------------------------------------------------------------------
RGB fixed-point unsigned, 1 - 2(-8) N 0 (biased exponent) (biased exponent)
absolute 2 \xb4 2(126) 0 >'> 0.0 \xb4 2(0)
> F 1 \xb4 2(119)
Normals fixed-point two's 1 - 2(-15) 2 \xb4 2(126) 0 >'> 0.0 \xb4 2(0)
complement N -1.0 > |F| 1 \xb4 2(112) -1.0 >'> -2 \xb4 2(126)
Double precision floating- 2 \xb4 2(1023) 2 \xb4 2(254) Overflow >'> S\xa2 \xb4 2(255)
point > FD -2 \xb4 2(1023) > |F| 1 \xb4 2(1) Underflow >'> S\xa2 \xb4 2(0)
where:
N = fixed-point numbers, input from the host
FD = 64-bit floating-point numbers, input from the host
F = result of conversion to 32-bit floating point numbers
S = significand
--------------------------------------------------------------------------------------------------------------------------------------
Figure 2-18 Format Converter Block Diagram
The table output column shows the result of conversion to 32-bit floating-point numbers, F, including the significand, S, and the biased exponent range. Special handling or conversion to (>) special end-limit values from conversion underflow or overflow is shown in the last column. S\xa2 represents a truncated version of 64-bit significand.
The format converter also converts 64-bit IEEE floating-point to 32-bit floating- point numbers. No incoming limitation is placed on the 64-bit double word, such that converted 32-bit NaNs (Not a Number - the result of an overflow) and Denorms (underflow numbers) are represented as specified below.
To convert, the least-significant word is truncated to the three high-order bits and concatenated to form a 23-bit significand. The exponent field is converted and contracted from 11 bits to eight bits. No rounding is performed. Note that an underflow condition sets a ZERO exponent, and underflow and NaNs set a maximum exponent of 255 while the truncated S\xa2 remains unchanged.
The Format Converter is subdivided into three paths: the 64-bit conversion, the passthrough/32-bit floating point, and the packed data conversion paths. The packed path uses a four-way multiplexer for eight-bit color and a two-way multiplexer for 16-bit normals. These are combined into a signed-extended 16- bit word through a two-way multiplexer and through a complementer to produce a sign and absolute magnitude number.
A shift generator counts leading zeros in the latter number and this count is fed to a barrel shifter for normalization of the significand. The count also goes to the exponent generator where a biased exponent is derived.
Incoming vertex 32-bit floating point numbers bypass conversion operations through an independent path. The path for 64-bit conversion is divided into sign/exponent and significand segments. The sign and 11-bit exponent merges with that of the packed path into the exponent generator while 20 bits of the most-significant path concatenate with three bits of the least-significant word to form the 23-bit significand. Exponent and significand multiplexers merge the 32-bit floating-point formats into the Vertex Buffer; all are 32-bit words. All control signals for the Format Converter are generated by the Format Controller.
The Format Controller provides address generation and control signals to:
The Format Controller consists of three sequencers and address generators for the two buffers:
The Format Conversion Sequencer is a state machine that performs the following functions:
When the Format Conversion Sequencer completes the prior output packet to the Format Converter, a pointer to the next packet in the Bucket Buffer is transferred to its address generator. If a Vertex Buffer Space Available flag is active, the Format Conversion Sequencer begins output of the next packet.
The output sequence is controlled by a series of micro-operators, vector conversion operators (VCS Ops), which are read from the list control file. Each vector conversion operator specifies a relative address location to be added to the packet base pointer to randomly access an operand and specify the operand operation. The operation is decoded and control signals are generated to unpack and convert to 32-bit floating point as required, as the operand flows through the Format Converter.
The series of vector conversion operators generates a standard vertex format from many different input formats, including conversion from double to single floating point representation. As a result of these operations, all data stored in the Vertex Buffer is 32-bit vertex floating point words. All packed normals and colors that require conversion to floating point must have the format specified below:
To optimize performance, the Format Conversion Sequencer provides a look- ahead count of the vector conversion operators to detect the last packet word. When space is available, the output of a new vertex to the Vertex Buffer can start without delay. Table 2-10 defines the vector conversion operator's three- bit operations codes.
Table 2-10 Vector Conversion Operator Operations Codes
-----------------------------------------------------------------------------------------------------------------------------------
VCS_OP<2:0'> Operation -----------------------------------------------------------------------------------------------------------------------------------
000 Data<15:8 Æ Float<31:0 (Red)
001 Data<23:16 Æ Float<31:0 (Green)
010 Data<31:24 Æ Float<31:0 (Blue)
011 Header1
100 Double Float<63:0 Æ Float<31:0'>2
101 Data<31:0 Æ Data<31:0'>
110 Data<15:0 Æ Float<31:0 (Nx, Nz)
111 Data<31:16 Æ Float<31:0 (Ny)
-----------------------------------------------------------------------------------------------------------------------------------
The vector conversion operator counter is loaded with an initial value from the list control registers. All vector conversion operators, except 64-bit double floating point operations, trigger one count. The count down to zero marks the end of the vertex conversion. Only four vertex sizes remain after format standardization: header with XYZ coordinates followed by:
All are in 32-bit floating point representation.
The Vertex Replacement Sequencer coordinates the loading and unloading functions of the Vertex Buffer. The Vertex Replacement Sequencer implements:
The Vertex Replacement Sequencer generates a register specification for the next primitive in the vertex list. When space is available in the Vertex Buffer to form the next primitive, the Vertex Replacement Sequencer downloads the current specification and examines the header of the controlling vertex passing through the Format Converter.
From the header flags, the Vertex Replacement Sequencer derives a specification for the primitive to be formed by the next vertex passing to the Vertex Buffer. This register specification contains fields that specify the pointer to the next vertex location to be replaced, the buffer locations and order of outputs of the primitive vertices, and primitive type and mode. The Output Controller uses these register fields to locate the vertex packets in the Vertex Buffer and control the number and order of vertex transfers to the CF Bus.
The Vertex Buffer Write Sequencer controls the loading of the Vertex Buffer with vertex packets. When the Vertex Buffer Write Sequencer receives a Vertex Buffer Space Available signal from the Output Controller, a set of packet pointers are down-loaded from the Vertex Replacement Sequencer which define the buffer vertex locations of the next primitive. The Vertex Buffer Write Sequencer loads the pointer for the new, Vn, vertex in its address generator and begins loading the next vertex at successive locations relative to the pointer. The Vertex Buffer Write Sequencer receives an end of packet flag from the Format Conversion Sequencer to end packet writing.
If a primitive restart is not specified, the Vertex Buffer Write Sequencer then signals the Output Controller that the next primitive is ready. The primitive pointer set is then passed to the latter controller. If a restart is in progress, the Vertex Buffer Write Sequencer continues to load vertices until the restart requirements are satisfied.
The Vertex Buffer contains 48 words of 32-bit storage, organized into four 12- word sub-buffers. The Vertex Buffer holds standard vertex and pass-through packets of 12 words or less.
The Vertex Buffer, shown in Figure 2-19, contains an example of the data that may be present along with identifying tupples that are used in the text. Note that the Vertex Buffer is partitioned into four segments of 12 32-bit words. Each 12-word group is associated with the x, y, z, normal, and color for one vertex. The buffer can therefore hold up to four vertices at one time.
In normal operation, the Vertex buffer is automatically written by the hardware from the Bucket Buffer under control of the VCS Opcodes. It accumulates vertices that are read out of the Bucket Buffer and processed.
Figure 2-19 Vertex Buffer
The Header and PID Path, shown in Figure 2-20, provides a control for subsequent control of generation of primitives by the Vertex Converter.
Figure 2-20 Header and PID Path Block Diagram
The Vertex Converter, shown in Figure 2-21, receives packets from the Vertex Buffer or the Header and PID Path. After formatting, a primitive packet contains a header space followed by the first and subsequent vertices.
Figure 2-21 Vertex Converter Block Diagram
The standard vertex format (without header) contains a XYZ 32-bit coordinate followed by optional first and second triples for normals and color. See Figure 2-22.
Control flags from the list control registers specify the number of triples in the variable length vertex, the number of vertices per primitive transmission, and changes in the number of vertices per primitive with hilighting options. Other flags control the modification of a vertex triple from the buffer with two alternate triples from the latter file. Substitutions of facet normals/colors in the new, Vn, vertex for like values in subsequent vertices are also programmed.
Figure 2-22 Standard Vertex Format
Following transmission ordering and override operations, control flags steer the triples, bypassing or flowing through a floating-point to 16-bit fixed converter to pack the primitive triples for transfer over the CF Bus. For conversion, the 32-bit floating point value is segmented to send the exponent to the shift generator while the significand is converted to sign and magnitude and then denormalized in a barrel rotator.
An output multiplexer then divides a 32-bit word into a high and low half- word for transfer on the 16-bit CF Bus. The latter also inserts header dispatch op-codes for LeoFloat. Timing signals are provided to minimize transmission, between packets, when both packets and LeoFloat buffers are available.
To avoid erroneous floating point to fixed 16-bit conversion of vertex data, the Leo traversal software must guarantee the underflow or overflow limits of 32- bit floating point values (single-precision floating point or "SF") to be converted. Any SF values specified for conversion must be within the following underflow or overflow limits:
0.0 \xb4 20, +1.0 \xb4 2112 \xa3 SF < +1.0 \xb4 2127 or
-0.0 \xb4 20, -1.0 \xb4 2112 SF -1.0 \xb4 2127 or
+0, +1 \xb4 2-15 \xa3 N.fix \xa3 1.0 - 1 \xb4 2-15 or
-1 \xb4 2-15 N.fix -1.0 + 2(-15)
with SF = -1.0 \xb4 2127 as an end-limit case.
SF = -1 \xb4 (1.0 - 1 \xb4 2-15) or
(SF = -1.0 \xb4 2127) Æ (N.fix = -1.0 + 1 \xb4 2-15)
Numbers SF, with biased exponent 126 (except -1.0 \xb4 2127) shall be set to an N.fix value of -0.0 to indicate the existence of an overflow or NaN condition of SF. For SF values with biased exponent <112, the N.fix value shall be set to +0.0.
The Output Controller reads primitive vertex packets from the Vertex Buffer, controls override and data compression on the vertices, and transfers them on the CF Bus to the LeoFloat ASICs. The controller has an address generator to read the Vertex Buffer and three control state machines:
When the new or final vertex of a primitive has been loaded into the Vertex Buffer, that primitive is ready for output to LeoFloat. The Vertex Buffer Read Sequencer provides address sequencing for reading Vertex Buffer and timing signals that control the overrides and float to fix numerical operations of the Vertex Converter data path.
When a complete primitive or other packet is ready, the CF Bus Sequencer generates CF Bus timing signals that control the packet transfers to LeoFloat. The LeoFloat Selection Sequencer monitors the input buffer available flags from each LeoFloat and selects the next LeoFloat buffer to be loaded.
The CF Bus Sequencer state machine coordinates the transfer of data to the LeoFloat input buffers and provides timing for the CF Bus. When the next packet is ready for output and one or more LeoFloat selection assignment pointers are received, the LeoFloat selectors are enabled for single or multi-cast transfers. CF Bus write enables are sent with each 16-bit data word. A header is written first, followed by multiple formatted word transfers, and ending with a special write enable that specifies the end and type of packet.
The LeoFloat Selection Sequencer state machine selects the next LeoFloat to receive a primitive or pass-through packets. This sequencer monitors the Input Buffer Available flags from LeoFloat. When the next LeoFLoat is requested and one is available, a priority selector implements LeoFloat selection. A pointer to the next LeoFloat is sent to the Packet Scoreboard when the next packet is ready for output from the Vertex Buffer. This pointer is also sent to the CD Bus scheduler logic to maintain the sequential order for LeoFloat task scheduling. Other selection modes include packet output to a specified LeoFloat or multi- casts to all. When required, mode flags such as LeoFLoat output/no-output are also sent to the Scoreboard to control subsequent transfers of output packets from LeoFloats to LeoDraws or LeoCommand.
The direct port, shown in Figure 2-23, handles all access to the frame buffer that bypasses the LeoFloat ASICs. The direct port supports block copy, block fill, and the following methods of frame buffer access:
The direct port also supports access to the registers of the LeoCross, LeoDraw, and Output RAMDAC. The Boot PROM can be programmed and read through the direct port.
Figure 2-23 LeoCommand Direct Port Block Diagram
Pixel access mode allows the host to read and write one pixel per transfer. Transfer size is always four bytes wide. Three plane groups are allowed: Image, Depth, and Window. This mode is set through the Frame Buffer Address Space register.
Stencil access mode is a write only mode. Stencil mode is effective in writing text or quick pattern fill. The host can use this mode to access up to 32 pixels in any frame buffer plane with a single write.
The host writes eight, 16, or 32 bits of stencil data (each bit represents one pixel) to LeoCommand in one transfer. The stencil data are re-grouped based on the stencil starting address and to which LeoDraw ASIC each bit is going to be written. Each bit of the stencil data is combined with the mask bit at the same bit location in the mask register and the transparency flag. The LeoDraw ASIC determines if a pixel should be written to the frame buffer based on the stencil mask and transparency flag.
Figure 2-24 shows the address and data formats required for stencil mode transfers.
Figure 2-24 Address and Data Formats in Stencil Access Mode
The byte access mode is used to access any one of the four image channels (red, blue, green, and alpha). This mode emulates the old Sun eight-bit frame buffers. Each byte represents one pixel. During a write request, LeoCommand sends the `write byte' commands to the proper LeoDraw ASIC. The write mask in LeoDraw determines which channel is affected.
Besides the basic read/write modes, the block copy function allows a block of pixels to be copied from one part of the screen to another. The LeoCommand assists block copy by supplying all read and write addresses to the LeoDraw ASICs. Pixel data is transferred among the LeoDraw ASICs only.
The Copy Dir/Size register defines a rectangular area to be copied and the copy direction. The Copy Source register defines the starting address of the source area. The Copy Destination register defines the starting address of the destination area. Note that writing to the Copy Destination registers triggers a block copy. LeoCommand sends a copy of these three registers to the LeoDraw.
The copy operation is actually divided into bursts of pixel reads and writes. Because of the five-way interleaved memory arrangement and limited queue space in the LeoDraw ASICs, LeoCommand copies five pixels in one burst. The LeoDraw ASICs have source, destination, and size registers that generate all the necessary read and write addresses for the block copy operation to the VRAM.
LeoCommand monitors the `direct buffer available' signals. The LeoDraw ASICs execute a read from VRAM. When all five are available, LeoCommand exchanges the five data words among the five LeoDraw ASICs. The LeoDraw ASICs then execute a write to VRAM. This process continues until the size register in LeoCommand indicates that the block move is complete.
The Block Copy and Block Fill operation are interrupted by any frame buffer access and other Leo device access. Pixel access, byte access, and stencil have a higher priority than block operation. Block operation resumes where it left off when there are no more direct port commands on the pipe.
Similar to a 2D block copy, LeoCommand also supports 2D block fill. Both the Copy Dir/Size register and the FG0 (foreground color) register must be set up before writing to the Fill Destination register with the starting fill address. The Fill Destination register also exists in state 0 only. Writing to the Fill Destination registers is the Fill Command, which triggers block fill.
Upon receiving the Fill Command, LeoCommand sends a series of write requests to the LeoDraw ASICs, filling one scan line at a time with the same color defined by the FG0 register. When one scan line is finished, the Fill Destination Y address is advanced and X address reset to the starting address, and continue filling the next scan line.
LeoCommand can access all direct and indirect registers on the LeoCross ASIC and the RAMDAC through the CX bus. The LeoCross and RAMDAC devices contain registers and memories used to program the video timing generator and to control the cursor, as well as the transformation of the pixel data.
The direct port is also used to write and read the Boot PROM. The PROM address is sent out on the CD bus and data is read back from the CX bus.
The Pick Control services LeoDraw interrupts caused by pick hits or semaphore. When LeoCommand detects a LeoDraw interrupt, it reads each status register of the five LeoDraws to determine which LeoDraw generated the interrupt and if a pick hit or a semaphore have occured.
If the pick hit bit is set, LeoCommand reads the pick IDs of the LeoDraws which has the draw_interrupt signal active. The pick IDs are then loaded to the Pick FIFO and generates an SBus interrupt if the Pick FIFO Not Empty bit in the SBus Interrupt Enable register is enabled. The Pick FIFO Empty bit on the DMA Status register is also set to 0, which the host can poll as to when pick data is available on the Pick FIFO.
After servicing all the interrupting LeoDraws, LeoCommand sends a `Clear Pick Hit' write strobe to the LeoDraw.
If the LeoDraw interrupt was caused by semaphore, LeoCommand generates an SBus interrupt if the Semaphore Interrupt Enable is set.
The CD Bus Control arbitrates who uses the CD bus. Access to the frame buffer, LeoDraw, LeoCross, RAMDAC and Boot PROM have the highest priority for using the CD bus. Commands for these devices are executed in the order as it comes in the pipe. The direct port looks ahead on the next command in the pipe and will not release the CD bus until there are no more commands that will use the CD bus.
Block operations are special cases since they are sent through the same direct port pipe. Block operations have second priority on the CD bus. Block Copy and Fill operations are interruptable by any other direct port commands, releasing the CD bus. The operation resumes when no more commands are in the pipe.
The third priority is the Pick controller using the CD bus. When the LeoDraw interrupt is active, the Pick Control sends a bus request to the CD Bus control. If no direct port operation is in progress, the Pick Control gets a grant to use the CD bus, otherwise it will wait. The Pick Control is also interruptable by any direct port access. It releases the CD bus and resumes when it gets back the grant.
The last priority is the accelerator port using the CD bus. The accelerator port uses the CD bus when writing data from the LeoFloat to all LeoDraw ASICs or reading data from LeoFloat's SRAM to LeoCommand.
The Central Controller is the principal control for on-chip and all Leo device registers and storage. The Central Controller provides reset and mode controls for context switching and transmits all Leo status flags to the host via polling and maskable interrupt operations. The decoding of SBus addresses by the Central Controller allows control of LC_Main bus distribution to the two ports, as well as access through the Leo buses to all Leo devices.
The Central Controller consists of a Mode Control and several Port Status registers.
The Mode Control coordinates with the autonomous operation of the direct and accelerator ports, based on commands written to Mode registers by the host. The Mode Control then reports the status of these operations back via the Port Status registers.
While the accelerator port is processing a display list, the direct port can proceed with scan line or other direct port operations to the frame buffer and LeoDraw. Events such as vertical retrace or pick interrupts can modify operation priorities to perform more critical tasks. Look-up table or raster copy tasks may switch the DMA data stream from the accelerator to direct port input.
During context switching, save and restoration operations are enabled by this controller. This control provides address decoding and control of LC_Main bus read and write operations as well as address functions for all Leo devices.
The Port Status registers provide port status information when polled by the host. The Input Buffer Control sets a flag to signal sub-packet space available in the Bucket Buffer. When list control or other context registers are free to accept changes after the end of a list or context save, condition flags are set. A mask register is also provided to generate interrupts when selected condition flags are set.
The context switching strategy is developed to simplify the control states needed to restore and restart a process after reloading the context. This includes minimizing the number of restored registers and thereby hardware and performance costs. In the accelerator port, context switching occurs within the duration of processing a pass-through or display list. In this case, both the list constant registers and states associated with a partial packet or primitive in the Bucket Buffer or Vertex Buffer require restoration as a minimum.
To update one graphics window, while another graphics window is active requires a context switch where the latter graphics content is saved for later update and restoration. Context switch initiation must occur at any time during the duration of a pass-through or display list for the current window. Context switch operations for the Accelerator Port are totally independent of Direct Port status.
The Accelerator Port enters the context switch mode when the Context Mode flag is activated by a slave write. If the Immediate mode is active, the programmed I/O slave writes terminate immediately and packet assembly in the Bucket Buffer ends, leaving a partial packet while any completed packets of the current process drain to the CF Bus.
If the DMA mode is active, the DMA read action is terminated by a slave write to stop the DVMA control. The Accelerator port receives the context mode start by subsequent slave write in this case. The packet content of the Sync Buffer will drain to an empty condition and the Bucket Buffer again may contain a partial packet.
If the above context switch mode occurs in the midst of a vertex display list, the Vertex Buffer may contain several completed vertex packets comprising a partial primitive that cannot be drained. As a consequence, both buffers may contain context, which must be saved and restored. All buffer locations (both buffers) are saved and restored to simplify restoration.
Operations to save the Accelerator Port context cannot start until all completed output packets have reached the CF Bus and their respective ordering and destination flags have been stored in the Packet Scoreboard. As LeoFloats complete processing of the draining packets, the processed packets are transferred via the CD Bus to the LeoDraws under control of the Packet Scoreboard flags.
When the Packet Scoreboard is empty, all LeoFloats will have drained to an idle state. When both the LeoFloats and the LeoDraws have drained, saving their context and subsequently writing new context can begin.
The saving of LeoCommand context can begin while the Packet Scoreboard and LeoFloats are still draining. The idle or fully drained condition is detected by slave reads of two flags in the Port Status registers; the Bucket Buffer Busy and Vertex Buffer Busy flags. When only a partial packet remains in the Bucket Buffer and partial primitive in the Vertex Buffer, both flags go to zero. A context save is initiated.
A context save and subsequent writing of buffers is done by slave SBus reads and subsequent slave writes. The context to be saved and restored are:
When the context of the new process has been written to the above registers, the context switch mode can be exited by a slave write to turn off the Context Switch flag. When the exit operation is initiated, a Context Switch state machine generates controller resets, loads new states into the Input and Format Controllers, and enables the latter to reach a restored condition. This action automatically restores pass-through, vertex, and DMA modes in the Accelerator Port, but the SBus DMA control must be restored and started before exiting. Completion of auto-restoration is signalled by testing the Accelerator Port Status flag (Context Switch Flag = 0) before restarting the host restored process software. The Output Controller has no machine state context since it controls only completed output packets.
