This chapter describes the CD Bus.
The CD Bus, shown in Figure 4-1, is a 16 - bit data bus that connects LeoCommand, the LeoFloat ASICs, and the LeoDraw ASICs. The CD Bus also provides addresses to the Boot PROM. Boot PROM data is read via the CX Bus.
All data transfer is synchronous to a 25 MHz clock signal that is distributed to all ASIC's.
LeoCommand controls all data transfers over the bus. The LeoDraw and LeoFloat ASICs send status signals to LeoCommand, and LeoCommand sends load and enable driver signals to the LeoDraw and LeoFloat ASICs. Each data transfer is in one of the five directions listed below:
This is commonly referred to as the accelerator port - the main rendering pipeline to the frame buffer. Data is transmitted in variable size packets of known format. The first word of a packet (the header) contains information related to the format and length of the packet. LeoDraw decodes this information and modifies the Frame Buffer accordingly. Packet transfers are initiated whenever the ACC_BUF_AVL signals of all the LeoDraw ASICs are active and a LeoFloat requests to output a packet.
Figure 4-1 CD Bus Block Diagram
This is commonly referred to as the direct port. LeoCommand executes all high - level (LeoHost) commands to the Frame Buffer through this port. LeoDraw ASICs send direct buffer available (DIR_BUF_AVL) status signals to indicate their readiness to accept a data packet. LeoCommand drives the direct load (DIR_LOAD) signals to each LeoDraw. The packet can be broadcast to more than one LeoDraw through individual control of the direct load signals.
During Block Image Transfer (Blt) commands, Frame Buffer data from one LeoDraw is transferred to another LeoDraw.
Data from LeoFloat's SRAM is sent to LeoCommand.
Table 4-1 summarizes the CD Bus signals.
Table 4-1 CD Bus Signals
-------------------------------------------------------------------------------------------------
Signal Name No. Pins I/O Type Description -------------------------------------------------------------------------------------------------
Signals Common to All: CD_DAT<15:0'> 16 I/O Tri-state Data bus LeoDraw Signals: ACC_LOAD 1 O Bi-state Accelerator port load to all LeoDraw ASICs DIR_LOAD<4:0'> 5 O Bi-state Direct port load for each LeoDraw DRAW_EN<4:0'> 5 O Bi-state Drive enable for each LeoDraw ACC_BUF_AVL<4:0'> 5 I Bi-state Accelerator port buffer available DIR_BUF_AVL<4:0'> 5 I Bi-state Direct port buffer available DRAW_INTR<4:0'> 5 I Bi-state Interrupt LeoFloat Signals: FLT0_ST<1:0'> 2 I Bi-state LeoFloat #0 output section status FLT1_ST<1:0'> 2 I Bi-state LeoFloat #1 output section status LeoFloat Signals (Continued): FLT2_ST<1:0'> 2 I Bi-state LeoFloat #2 output section status FLT3_ST<1:0'> 2 I Bi-state LeoFloat #3 output section status FLT_EN<3:0'> 4 O Bi-state Drive enable for each LeoFloat -------------------------------------------------------------------------------------------------
These are the 16 data lines 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 tell the LeoDraw ASICs to load data into the accelerator port buffer.
LeoCommand uses this signal to tell one or more LeoDraw ASICs to load data into the direct port buffer.
LeoCommand uses these signals to tell one of the LeoDraw ASICs to drive the CD_DAT lines.
This signal indicates when a LeoDraw ASIC is ready to accept a new accelerator port packet from LeoFloat. This signal goes inactive when the first word of the packet 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.
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.
These signals indicate that an interrupt occurred in one of the LeoDraw ASICs.
LeoCommand uses these signals to tell one of the LeoFloat ASICs to drive the CD_DAT lines.
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 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 4-2.
----------------------------------------------------------------------------------------------------------
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_EN. 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_EN. 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_EN 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_EN. 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_EN 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_EN 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_EN 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_EN. ----------------------------------------------------------------------------------------------------------
Commands on the CD Bus are transmitted as packets. A packet consists of a header followed by a variable number of data words. This section describes the packet format of all CD Bus commands. There are two groups of packet formats: accelerator port packets and direct port packets.
Accelerator port packets are sent from LeoFloat to LeoDraw. These packets have a header followed by the data in the packet. The header identifies the type of packet and is encoded according to the hexadecimal values in Table 4-3.
Table 4-3 Accelerator Port Header Format
-------------------------------------------------------------
Header Packet Type CD_DAT<15:0'> -------------------------------------------------------------
00FF Dot command 02FF RGB dot command 04FF Vector (x_major) command 05FF Vector (y_major) command 06FF RGB vector (x_major) command 07FF RGB vector (y_major) command 08FF Triangle (dec_x) command 09FF Triangle (inc_x) command 0CFF Write accelerator port state register command 0EFF Fast clear command 0FFF Raster write command -------------------------------------------------------------
The packet formats for each command are shown below.
The Dot command packet contains a 16-bit header and three 32-bit words, one each for x, y, and z, as shown in Figure 4-2. The Dot command packet requires seven bus cycles to transmit, one cycle for the header and two each for the three 32-bit words.
Figure 4-2 Dot Command Packet Format
The RGB Dot command contains a 16-bit header and six 32-bit words, one each for x, y, z, r, g, and b, as shown in Figure 4-3. The RGB Dot command packet requires 13 bus cycles to transmit, one cycle for the header and two each for the six 32-bit words.
Figure 4-3 RGB Dot Command Packet Format
The Vector command contains a 16-bit header and six 32-bit words, one each for us, vs, zs, ue, dzDu, and dvDu, as shown in Figure 4-4. The Vector command packet requires 13 bus cycles to transmit, one cycle for the header and two each for the six 32-bit words.
Figure 4-4 Vector Command Packet Format
The RGB Vector command contains a 16-bit header and 12 32-bit words, as shown in Figure 4-5. The Vector command packet requires 25 bus cycles to transmit, one cycle for the header and two each for the 12 32-bit words.
Figure 4-5 RGB Vector Command Packet Format
The Triangle command contains a 16-bit header and 21 32-bit words, as shown in Figure 4-6. The Triangle command packet requires 43 bus cycles to transmit.
Figure 4-6 Triangle Command Packet Format
Figure 4-6 Triangle Command Packet Format (Continued)
The Write Accelerator State Register command contains a 16-bit header and two 32-bit data words, as shown in Figure 4-7. The Write Accelerator State Register packet requires five bus cycles to transmit.
The Fast Clear command contains a 16-bit header and three 32-bit data words, as shown in Figure 4-8. The first word is unused. The "yr" word is the starting row address shifted left by one bit. "count13 is the number of flash write cycles. The Fast Clear command packet takes seven bus cycles to transmit.
Figure 4-8 Fast Clear Command Packet Format
The Raster Write command contains a 16-bit header and seven 32-bit data words, as shown in Figure 4-9. The Raster Write command packet takes 15 bus cycles to transmit.
Figure 4-9 Raster Write Command Packet Format
Direct port packets from LeoCommand to LeoDraw have a header followed by the data in the packet. The header identifies the type of packet and is encoded according to the hexadecimal values in Table 4-4.
It is important to note that the following packet descriptions describe the packet that is loaded into a particular LeoDraw's direct port. What occurs on the CD Bus could be very different. For example, the stencil header can be broadcast to all LeoDraw ASICs followed by the second word for two of the LeoDraw ASICs using the load signals to select only those two. The next word on the bus could then be the second word for the other three LeoDraw ASICs. This is the common method of operation for stencil, byte access, or monochrome mode.
Table 4-4 Direct Port Header Format
----------------------------------------
Header Packet Type CD_DAT<15:11'> ----------------------------------------
00 Stencil write command 01 Pixel read command 02 Pixel write command 03 Byte read command 04 Byte write command 05 LeoDraw read command 06 LeoDraw write command 07 Vertical scroll command 08 Blt read command 09 Blt readx command 0A Blt writexread command 0B Block fill command 0C - 1F Not used ----------------------------------------
The Stencil Write command packet contains a 16-bit header and two 16-bit data words, as shown in Figure 4-10.
Figure 4-10 Stencil Write Command Packet Format
The Pixel Read command packet contains a 16-bit header and three 16-bit data words, as shown in Figure 4-11
Figure 4-11 Pixel Read Command Packet Format
The Pixel Write command contains a 16-bit header and three 16-bit data words, as shown in Figure 4-12.
Figure 4-12 Pixel Write Command Packet Format
The Read Byte command contains a 16-bit header and two 16-byte data words, as shown in Figure 4-13.
Figure 4-13 Read Byte Command Packet Format
The Byte Write command contains a 16-bit header and two 16-bit data words, as shown in Figure 4-14. The Image Write Mask in LeoDraw determines which of the four bytes in the Image plane are written.
Figure 4-14 Byte Write Command Packet Format
The LeoDraw Read command contains a 16-bit header, as shown in Figure 4-15. This one-word packet reads one of the internal 32-bit status or control registers in LeoDraw.
Figure 4-15 LeoDraw Read Command Packet Format
The LeoDraw Write command contains a 16-bit header and two 16-bit data words as shown in Figure 4-16. This command writes a 32-bit data word into any of the internal registers in LeoDraw. The act of writing the destination registers for block fill or block copy initiates the execution of the command. Block copy and block fill are atomic operations. The LeoDraw ASICs cannot be stopped in the middle of one of these operations.
Figure 4-16 LeoDraw Write Command Packet Format
The Vertical Scroll command contains a 16-bit header, as shown in Figure 4-17. This one-word packet tells the LeoDraw ASICs to read a pixel and write it to another location within the same interleave. This command is state set 0 only.
Figure 4-17 Vertical Scroll Command Packet Format
The Blt Read command contains a 16-bit header, as shown in Figure 4-18. This one-word packet tells the LeoDraw ASICs to read the first pixel for the beginning of a block move command. This command is always broadcast to all LeoDraw ASICs. It is state set 0 only.
Figure 4-18 Blt Read Command Packet Format
The Blt readx command contains a 16-bit header and two 16-bit data words, as shown in Figure 4-19. This packet tells the LeoDraw ASICs to read the second pixel in a block move command. This command is always broadcast to all LeoDraw ASICs. This command is always the second command of a block move operation. It is state set 0 only.
Figure 4-19 Blt Readx Command Packet Format
The Blt writexread command contains a 16-bit header and two 16-bit data words as shown in Figure 4-20. This packet tells LeoDraw to write the enclosed data to the destination address and read the pixel with the source address. This command is state set 0 only.
Figure 4-20 Blt Writexread Command Packet Format
The Block Fill command contains a 16-bit header, as shown in Figure 4-21. This one-word packet tells the LeoDraw ASICs to write the foreground register to the destination pixel. This command is state set 0 only.
Figure 4-21 Block Fill Command Packet Format
The following timing diagrams show the control signal timing for some typical CD Bus data transfers.
Figure 4-22 shows the LeoDraw ASICs waiting for the LeoFloat to send the packet. Notice that LeoCommand can halt a packet transfer at any time during the transfer for an arbitrary length of time. At the end of the transfer, the same LeoFloat immediately requests transfer for the next packet. But the LeoDraw ASICs aren't ready, so the request isn't granted.
Figure 4-22 Accelerator Port Timing, Waiting for LeoFloat
Figure 4-23 shows the next LeoFloat waiting for a LeoDraw to become available. In this case the transfer was halted on the last word of the packet. Leofloat continues to send the request until it is granted the bus.
Figure 4-23 Accelerator Port Timing, Waiting for LeoDraw
The latch diagram in Figure 4-24 shows the timing delay for the status and control signals used by the accelerator port.
Figure 4-24 Accelerator Port Latch Diagram
The direct port concerns the LeoDraw ASICs and LeoCommand. LeoDraw sends a DIR_BUF_AVL signal to LeoCommand. LeoCommand responds by sending either a DIR_LOAD to load data into the buffer or a DRAW_EN to drive data onto the bus.
These transactions are one of two types. A write transaction loads words into the direct port and expects no output from LeoDraw. A read transaction loads words into the direct port and expects to receive words back from LeoDraw. Figure 4-25 shows a write transaction.
Figure 4-25 Direct Port Timing, Write Transaction
Figure 4-26 shows a read transaction.
Figure 4-26 Direct Port Timing, Read Transaction
Figure 4-27 shows a write transaction sandwiched between a read transaction. LeoCommand must remember that there is data in LeoDraw's direct port waiting to be driven onto the bus. Notice that DIR_BUF_AVL is no longer active after the write transaction begins.
The latch diagram in Figure 4-28 shows the timing delay for the control signals used by the direct port.
Figure 4-28 Direct Port Latch Diagram