This chapter describes the CF Bus.
The CF Bus, shown in Figure 3-1, is a uni-directional 16-bit data bus that connects LeoCommand with the LeoFloat ASICs. LeoCommand sends data to the LeoFloat ASICs in packets. A packet consists of up to 32 32-bit words.
The words are sent in either a packed primitive format or an unpacked format. In the packed format, LeoCommand converts a 32-bit floating point word to a 16-bit fraction and sends the fraction to LeoFloat in one clock cycle. In the unpacked format, LeoCommand sends a 32-bit word to LeoFloat in two clock cycles. The packed word is reconverted to a 32 bit floating point word in LeoFloat.
Figure 3-1 CF Bus Block Diagram
There are three basic types of packets transmitted over the CF Bus: graphics primitive packets, pass-through packets, and SRAM packets. Graphics primitive packets - for dot, vector, and triangle primitives - contain the vertex data for the specific primitive being transmitted. Pass-through packets contain data that is passed to LeoFloat or to LeoDraw. SRAM packets contain data for the LeoFloat static RAM (SRAM),
These packet types are described in more detail later in this chapter.
Most of the packets are formatted as shown in Figure 3-2. The first 16-byte word sent across the bus is a header followed by the data. As you will see later in the chapter, some packets may contain other components also.
Figure 3-2 Basic CF Bus Packet Format
The header, described in more detail later, contains specific information that identifies the type of packet being transmitted. Some pass-through packets have no header.
Table 3-1 summarizes the CF Bus signals.
Table 3-1 CF Bus Signals
------------------------------------------------------------------------------------------------------
Signal Name No. Pins I/O Type Description ------------------------------------------------------------------------------------------------------
CF_DAT<15:0'> 16 O Bi-state Data
CF_BUF_AVL<0'> 1 I Bi-state Buffer available from LeoFloat #0
CF_BUF_AVL<1'> 1 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
------------------------------------------------------------------------------------------------------
These are the 16 data lines for the CF Bus. LeoCommand controls which LeoFloat the data is intended for by asserting the appropriate CF_LOAD signal.
Each LeoFloat ASIC sends a `buffer available' signal to LeoCommand. 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. This signal indicates to the LeoFloat that it should receive the data on the CF_DAT pins according to the encoding on the control bits.
These encoded bits describe the word format of the data on the bus. The format can be one of four types:
The end of the packet is also encoded on these bits. The code for the last word also indicates 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.
When CF_CTL<2:0 = 110, the least-significant bit of CF_DAT (CF_DAT<0) is used to define two functions for the LeoFloat ASICs:
Table 3-2 lists the CF_CTL encodings.
Table 3-2 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. End of packet.
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.
---------------------------------------------------------------------------------------------
Data passed from LeoCommand to one of the LeoFloat chips is transmitted as packets. A packet consists of an optional header and a variable number of data words. There are three packet types:
In addition, there are two types of headers:
These packet elements are described in detail below.
Graphics primitive packets include dot, vector, and triangle packets. Each graphics primitive packet contains a header, optionally a subelement pick ID, and one, two, or three vertices, as shown in Figure 3-3.
Figure 3-3 Graphics Primitive Packets
LeoCommand creates the subelement pick ID code and sends it as part of the primitive packets sent to LeoFloat. Once the value is set by software, LeoCommand increments the value with each packet sent. The subelement pick ID code is used to invoke a separate picking dispatch table within the LeoFloat microcode.
The individual packets are further described below. For a description of the header, see "Header" on page 3-11. For descriptions of the vertex data, see "Vertex Formats" on page 3-16.
The dot primitive packet typically contains a header and one vertex. The vertex is one of the four types described under "Vertex Formats" on page 3-16.
The minimum packet size requires seven bus cycles for:
Header (one cycle)
Plain vertex (six cycles)
The maximum packet size requires 20 bus cycles for:
Header (one cycle)
Subelement pick ID (one cycle)
RGB normal vertex (12 to 18 cycles)
The vector primitive packet typically contains a header and two vertices. Each of the vertices is one of the types described under "Vertex Formats" on page 3- 16.
The minimum packet size requires 13 bus cycles for:
Header (one cycle)
Vertex #1 (six cycles for plain vertex)
Vertex #2 (six cycles)
The maximum packet size requires 38 bus cycles for:
Header (one cycle)
Subelement pick ID (one cycle)
Vertex #1 (up to 18 cycles for RGB normal vertex)
Vertex #2 (up to 18 cycles)
The triangle primitive packet typically contains a header and three vertices. Each of the vertices is one of the types described under "Vertex Formats" on page 3-16.
The minimum packet size requires 19 bus cycles for:
Header (one cycle)
Vertex #1 (six cycles for plain vertex)
Vertex #2 (six cycles)
Vertex #3 (six cycles)
The maximum packet size requires 56 bus cycles for:
Header (one cycle)
Subelement pick ID (one cycle)
Vertex #1 (up to 18 cycles for RGB normal vertex)
Vertex #2 (up to 18 cycles)
Vertex #3 (up to 18 cycles)
All primitive packets contain at least one header. The dispatch header identifies the type of packet and processing requirements executed by the LeoFloat ASICs. If a second header is used, it contains sub-element pick identifiers. All headers carry a CF_CTL<2:0 tag of 100.
Pass-through packets contain from 3 to 32 non-interpreted words and any headers. A minimum-sized pass-through packet (three 32-bit words) takes six bus cycles. The maximum pass-through packet size of 32 32-bit words takes 64 bus cycles.
There are three variations on pass-through packets:
The count value is used as an ID of the pass-through packets for Raster Copy.
Figure 3-4 shows the pass-through packet format.
Figure 3-4 Pass-through Packets
A pass-through packet may contain zero, one, or two headers. A header can be added to the transparent, incoming packet from a LeoCommand internal register. The header contains packet content and destination flags, which are defined by host software.
A second header is attached to a series of raster copy packets. The latter header provides an ID, a count value that is unique for each packet of the series. All pass-through headers carry a CF_CTL<2:0 tag of 100.
There are two types of SRAM packets: read and write.
LeoFloat uses these three words of transmitted data to generate an address and the number of words to be read from SRAM. LeoFloat reads SRAM and loads the data into its `O' register. LeoFloat then signals LeoCommand (via the CD Bus) that an output packet is ready. LeoCommand can then read the output packet via the CD Bus.
An SRAM read takes six bus cycles (three 32-bit words).
LeoCommand can write from 3 to 32 32-bit words to one or more LeoFloat SRAMs. This packet is the same as a pass-through packet, except for the control bits of the last half word. LeoFloat generates addresses and stores this data into SRAM. A maximum SRAM write of 32 words takes 64 bus cycles.
There are four data types sent across the bus: header, fixed-point fraction, floating-point number, and pass-through packet.
The header contains three fields, as shown in Figure 3-5. The first field, bit 15, is always zero. The other two fields are described below.
Figure 3-5 Header Format
The vertex header contains two types of bits:
The vertex header field is coded as follows:
Table 3-3 Vertex Header Field
----------------------------------------------------
Bit Meaning ----------------------------------------------------
14 Hollow edge between vertices 1 and 2
13 Hollow edge between vertices 3 and 1
12 Hollow edge between vertices 2 and 3
11 Draw highlighted edge between vertices 1 and 2
10 Draw highlighted edge between vertices 3 and 1
9 Draw highlighted edge between vertices 2 and 3
----------------------------------------------------
The dispatch opcode field is the dispatch address to the microcode in the LeoFloat chip. This is known as the dispatch table. The first part of the dispatch table is used for the geometry functions: dots, vectors, and triangles. The second part of the dispatch table is for the attributes.
Table 3-4 lists the meanings of the dispatch opcodes.
Table 3-4 Dispatch Opcode
-----------------------------------------------------------
Opcode Function -----------------------------------------------------------
000 Cold initialization (startup or reset routine)
001 Plain dot
002 RGB dot
003 Dot with normals
004 Dot with RGB and normals
005 Plain vector
006 RGB vector
007 Vector with normals
008 Vector with RGB and normals
009 Triangle with normals
010 Triangle with RGB
011 Triangle with RGB and normals
012 Hollow triangle with normals
013 Hollow triangle with RGB
014 Hollow triangle with RGB and normals
015 Raster data copy
016 - 031 Reserved for other geometry functions
032 Pass-through
033 Load context
034 Store context
035 Matrix processing (NPC)
036 View matrix processing (NPC)
037 Poke matrix
038 Matrix processing (LC)
039 --
040 Picking enabled
041 Face culling method
042 Use back props
043 Front lighting degree
044 Inverse view matrix
045 Facet normals enabled
046 Front surface normal
047 Back surface color
048 Eye vector properties
049 Front material properties cached
050 Back material properties cached
051 Light sources cached
052 Front material properties uncached
053 Back material properties uncached
054 Light sources uncached
055 Light counters
056 Front specular color
057 Back specular color
058 Raster XY position
059 Model clipping enable
060 Model clip planes load matrix
061 Diagnostic mode (SunDiag SRAM selftest)
062 Read micro-code revision level
063 Build dot branch tables
064 Build vector branch table
065 Build triangle branch table
066 Build lighting degree
067 Model clipping number
068 - 080 Reserved
081 - 128 Undefined
-----------------------------------------------------------
The fixed-point fraction, shown in Figure 3-6, is a sign+magnitude 16-bit fraction. The binary point is just to the right of the sign bit. LeoFloat converts this to a 32-bit floating-point word.
Figure 3-6 Fixed-Point Fraction Format
The 32-bit floating-point number, shown in Figure 3-7, is the way most vertices are presented to LeoFloat. LeoCommand converts the 32-bit floating-point number to two 16-bit words before sending the data across the bus. LeoFloat re-assembles the two 16-bit words into a 32-bit floating point number. The least-significant 16 bits are sent on the first clock cycle, the most-significant 16 bits are sent the second clock cycle.
Figure 3-7 Floating Point Number
The pass-through packet sends non-interpreted words to LeoFloat.
Figure 3-8 Pass-through Packets
The graphics primitive packets contain vertex data. There are four types of vertex data: plain, RGB, normal, and RGB normal.
Plain vertex data consist of three 32-bit floating point numbers:
X - 32-bit floating point number
Y - 32-bit floating point number
Z - 32-bit floating point number
Each of these is divided into two 16-bit packets, as described under "Floating Point Number (Unpacked Format)" on page 3-15, requiring six bus cycles to transmit.
RGB vertex data consist of six floating point numbers or fixed-point fractions, as follows:
X - 32-bit floating point number
Y - 32-bit floating point number
Z - 32-bit floating point number
R - 32-bit floating point number or 16-bit fixed-point fraction
G - 32-bit floating point number or 16-bit fixed-point fraction
B - 32-bit floating point number or 16-bit fixed-point fraction
Each of the floating point numbers is divided into two 16-bit packets, as described under "Floating Point Number (Unpacked Format)" on page 3-15 and require two cycles per number. The 16-bit fixed-point fractions require only one cycle per number.
This gives a range of bus cycles of from nine (six cycles for three floating-point numbers plus three cycles for three 16-bit fractions) to 12 (six floating-point numbers).
Normal vertex data consist of six floating point numbers or fixed-point fractions, as follows:
X - 32-bit floating point number
Y - 32-bit floating point number
Z - 32-bit floating point number
Nx - 32-bit floating point number or 16-bit fixed-point fraction
Ny - 32-bit floating point number or 16-bit fixed-point fraction
Nz - 32-bit floating point number or 16-bit fixed-point fraction
This gives a range of bus cycles of from nine to 12, the same as for RGB vertex.
RGB normal vertex data consist of nine floating point numbers or fixed-point fractions, as follows:
X - 32-bit floating point number
Y - 32-bit floating point number
Z - 32-bit floating point number
R - 32-bit floating point number or 16-bit fixed-point fraction
G - 32-bit floating point number or 16-bit fixed-point fraction
B - 32-bit floating point number or 16-bit fixed-point fraction
Nx - 32-bit floating point number or 16-bit fixed-point fraction
Ny - 32-bit floating point number or 16-bit fixed-point fraction
Nz - 32-bit floating point number or 16-bit fixed-point fraction
This gives a range of bus cycles from 12 to 18.
In the following timing diagrams, the sequence begins when a LeoFloat asserts "buffer available" (CF_BUF_AVL).In three phases (half clock cycles), LeoCommand can activate the "load" signal (CF_LOAD) and drive the data and control lines.
When LeoFloat sees CF_LOAD high, it must drop CF_BUF_AVL if its other input buffer is not within three phases of becoming empty. However, if its other input buffer is within three phases of being empty, CF_BUF_AVL can remain high and LeoCommand could immediately begin sending the next packet to the same LeoFloat.
Figure 3-9 shows the timing for the transfer of a dot primitive with plain vertex.
Figure 3-10 is an example of a read SRAM packet. This is the shortest packet, without header, taking only four cycles. Notice that LeoCommand can immediately send the next packet to this LeoFloat. LeoFloat could remove CF_BUF_AVL on cycle 4. But since its other input buffer is available, CF_BUF_AVL remains high.
Figure 3-10 Read SRAM Packet Transfer Timing
Figure 3-11 is a typical example of a write SRAM packet. This is also an example of the longest packet. It requires 64 clock cycles to transfer the 64 words from LeoCommand to LeoFloat. Notice that LeoCommand does not look at CF_BUF_AVL until three half cycles before the end of the packet.
Figure 3-11 Write SRAM Packet Transfer Timing
Figure 3-12 is an example of a triangle packet using an RGB vertex. The type of vertex remains unchanged within a packet. The RGB values are packed 16-bit fractions throughout the packet. Notice that CF_BUF_AVL becomes active after the packet was transmitted. This causes a three clock cycle delay between the end of this packet and the possible start of the next packet to this LeoFloat.
Figure 3-12 Triangle Packet Transfer Timing
Figure 3-12 Triangle Packet Transfer Timing (Continued)
Figure 3-13 shows the timing delay for the control signals over the CF Bus.
Figure 3-13 CF Bus Latch Diagram
