Sun Proprietary/Confidential: Internal Use Only


Starfire POST & redx Information Home Page

Starfire POST Glossary

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0-9



A



abc
Address bus configuration. Usually represented as a 4-bit hex value, with each bit 1 if the corresponding address bus is in the current configuration, and 0 if it is not. Starfire can operate in any of the fifteen non-0 abc's. The normal abc is F, indicating all four buses operational.

abus
Address bus. Starfire has four independent address paths for interconnect transactions. A given transaction will use a given address bus based on a decoding of several bits in the Physical Address of the transaction. This routing is done by the PC asic, based on its configuration registers. All PCs in a Starfire must be identically configured in this respect, so that all transactions for a given address will always use the same bus.

Within a system board, each of the four abuses is handled by one of the four CIC asics, which route the bus off-board as a Global Address Bus (GAB).


AL Test
Address Line Test. Used in testing memory and DTAGs, this test verifies that none of the address lines to the resource are stuck. This test runs in four passes all of which run through the address range under test by shifting a single binary 1 or 0 through that range. (e.g. If the memory range is 0-0xff then the access sequence for the walking ones pattern will be 0x1, 0x2, 0x4, 0x8, 0x10,...,0x80). The test is run in two passes: First, memory is written such that the address is written to the address (i.e. memory(address) = address); second, each location is read and verified. Then this is repeated for the walking 0 passes.

ECC or parity errors are also caught if they occur.


ascii
American Standard Code for Information Interchange. An encoding of printable and control characters into 7-bit or 8-bit values. See the man page ascii(1).

asic
Application-specific integrated circuit. Used in the Starfire context to mean any of the large main chips in the design, including (incorrectly, strictly speaking) the UltraSparc processor.

arbitration stop
Also called Arbstop. A condition which occurs when one of the chips detects a parity error or equivalent fatal system error. Bus arbitration is frozen, so all bus activity stops. The system is dead until the SSP detects the condition by polling the board LAARB CSRs via JTAG, and clears the error condition.

When this occurs during online OS (or OBP) operation, this will normally be detected by Edd polling scripts. hpost -D will be called to create a dumpfile of hardware system state on the SSP, and then hpost will be called to reboot the affected domain. The dumpfile can be examined using redx to determine the cause of the error.

For a basic guide to understanding Arbstops and how to deal with them, see Starfire Arbstops and redx 101.


AT Test
Address Transition Test. Used in testing memory, DTAGs, and bbsram, this test verifies the resources' integrity by performing consecutive accesses to addresses as widely different as possible. Thus, at-speed transitions of the memory addressing are tested. This test runs in two passes: First, all of the memory (or DTAGs) is written such that a location's address is stored at that location (i.e. memory(address) = address); second, beginning at the furthest ends of the address range consecutive reads of the highest and lowest addresses are made, working toward the middle. (e.g. If the range is 0-0xff, then the test reads in the following order: 0, 0xff, 0x1, 0xfe, 0x2, 0xfd, 0x3, 0xfc,..., 0x7f, 0x81).

Errors are caught by explicit comparison of the read data with the expected value.

B



bank
An array of 8 dram DIMMs logically related and connected to a single MC and pair of PUPs, which collectively supply memory data + ECC words for the same physically addressed 64 byte cacheline. In Starfire, bank and group are synonymous.

BBC
Bootbus Controller. The portion of the PC asic that controls the local bootbus.

BIST
Built-in selftest. A feature of the Starfire asics which provides a cabability for the chip to perform a diagnostic test of itself when requested using JTAG operations. The result of the selftest is a signature left in a reserved register in the chip. Test programs can invoke BIST, then examine the signature to see if it is the correct value for this version of the chip, determined by examining the chip's component ID register. BIST is not currently used by POST. It is used during chip and board manufacturing test.

Blackbird
The nickname of the UltraSPARC-II processor.

bbsram
See bootbus sram.

BDA
Board Desciptor Array

blacklist
An SSP text file that is read by POST. It declares certain system components to be treated as failed a priori. See Blacklist and Redlist in the POST User's Guide, and man page: blacklist(4M).

bootbus
A slow speed bytewide bus controlled by the PC asics, used for running diagnostics and boot code. Interconnects the PC, XDB, and for processor PCs, bootbus sram. On the I/O PC, an LED register takes the place of the sram. The bootbus also provides the data interface for PC system registers, since the PC does not have a datapath connection. An abbreviated version of a bootbus exists in the MC to support its system register datapath.

bootbus sram
Also called bbsram. A 256 KByte static ram attached to each processor PC, shared by the two processors. Through the PC, it can be accessed for read/write from JTAG or any processor. Downloaded at various times with POST and OBP startup code, and provides shared data between the downloaded code and the POST PCS. Also provides a low-bandwidth boot and service communication path between the OS and the control board during system operation

boot processor
The processor in a domain whose bbsram is selected to hold the post2obp structure passed to OBP by POST. It is usually the lowest-numbered processor in the domain, but this may be changed with the -p command line option to hpost. The value of the boot processor is returned by hpost as its exit value. The boot processor is also known as "CPU 0" to OBP/Solaris.

board descriptor array
A structure describing the status of the hardware resources in a Starfire system. See Board Descriptor Array in the POST User's Guide.

bringup
An SSP script that controls and sequences the booting of a Starfire. In normal operation, bringup is run by SSP daemon processes when they determine booting is required. bringup runs hpost, among other things.

BSS Test
Binary Search Sequence Test. Used in testing registers, DTAGs, and all levels of memory, this test uses a sequence of simple bit patterns to verify the integrity of each bit cell against stuck-at and adjacency faults. Using memory testing as an example, this test runs in three passes: First, write the pattern in ascending memory address order; second, back-to-back read-write, writing the inverse of the pattern to the location just read; third, read memory in descending order.

For Starfire POST's main memory test, errors are caught via the ECC trap mechanism in the hardware; the value at each location is not explicitly tested. When testing bbsram, DTAGs and registers there is explicit testing of the values.

The BSS pattern itself was developed to reduce the time necessary to test all the bits in a store for stuck-at and adjacency faults. If N is the width of a given location, then the traditional walking ones/zeros requires 2N patterns to be used. The BSS pattern (e.g. 00001111, 00110011, 01010101, 00000000, 11110000, 11001100, 10101010, 11111111) provides the same test coverage but uses only 2(1 + LOG2(N)) patterns, thus saving time.


bus configuration
The combination of the address bus configuration (abc) and data bus configuration (dbc) that a Starfire system is configured in. There are 45 possible valid bus configurations (15 address times 3 data). This is sometimes represented as a two-hex-digit concatenation of dbc abc, so that 3F represents the normal two-data-bus, four-address-bus configuration.

byte
A small group of bits, usually enough to represent a single character. Almost always 8 bits in current use.

C



CBE
Control Board Executive. The firmware running on the control board processor.

CBMP
Control Board Management Protocol. A communications protocol used between CBS and CBE. It runs on top of TCP/IP on the ethernet connection to the control board.

CBS
Control Board Server. A daemon process that runs on the SSP and which controls all SSP communication with the CBE. Clients of CBS (including hpost and redx) interact with CBS through the shared object library libcbs.so.

CE
Correctable error. See ECC.

centerplane
The large circuit board that interconnects the Starfire system boards, control boards, and centerplane support boards, and which contains the Global Data and Address routing and arbitration asics. Starfire has an active centerplane which contains bus interconnection asics.

The Starfire centerplane is logically divided into two separately powered halves for purposes of maintaining availability in the face of failure. Each half provides two GABs of address routing and arbitration, one 72-bit data path (or bus), and one Global Data Arbiter (GDARB) chip. Starfire can operate, with half its normal maximum interconnect bandwidth, with either half-centerplane powered down.


centerplane support board
A circuit board located above the control board at one end of each side of the Starfire cabinet. It provides DC/DC power conversion, local clock distribution, and local JTAG control (JBC) for the asics located on one half-centerplane. Two are normally present in the system.

control board
A circuit board located below the centerplane support board at one end of each side of the Starfire cabinet. Only one is required and operational at any time, the other, if present, is a redundant standby. Provides master clock generation and distribution to the Starfire system, and contains the master JTAG system controller. Also contains some environmental monitoring and emergency shutdown logic, peripheral power control, etc. The control board contains a SPARClite processor which runs the CBE firmware. It communicates by ethernet with the SSP, and normally acts only as an agent of the SSP. The control board has no interface to any of the Starfire system data or address buses, processors, memory, or I/O controllers, except for JTAG scan.

CIC
Coherent Interface Controller asic. Provides the interface between each system board and one of the four GABs. Also provides DTAGs for all onboard processor and I/O caches for the system on that GAB. There are four CICs on each system board, one per GAB. They are numbered 0 through 3.

POST and redx designate a particular CIC as board.gab, e.g., "CIC A.1", meaning the CIC for GAB 1 on system board A (10 decimal).
The redx command to display CIC registers is shcic.


CID
Component ID. A 32-bit value which identifies the chip type and revision. Accessible via JTAG. for all Starfire asics. Also accessible in CSR space for the PC, MC, and CIC asics. The 32 bits are formatted as follows:
	VVVV                               Version (4 bits) [Also called Rev].
	    PPPPPPPPPPPPPPPP               Part Number (16 bits)
			    MMMMMMMMMMM    Manufacturer's ID (11 bits)
				       1   Constant 1 (1 bit)

crunch
An operation internal to POST that infers what components are effectively unuseable (in one or more of the bus configurations) because other components have failed. See Board Descriptor Array in the POST User's Guide.

CSB
Centerplane Support Board.

CSR
Control and Status Register. A general term for any embedded register in any of the asics in Starfire.

CSR space.
A specific range of high physical address space which provides access from the UltraSPARC processors to the CSRs in the PC, MC, and CIC asics. The remaining Starfire asics are not directly accessible by the processors, only by the control board via JTAG.

cwd
Current working directory. With respect to POST, this is on the SSP, since there is no Starfire file system accessable to POST. See the man pages for csh(1).

D



dbc
Data bus configuration. Usually represented as a 2-bit hex value, with each bit 1 if the corresponding data bus is in the current configuration, and 0 if it is not. Starfire can operate in any of the three non-0 dbc's. The normal dbc is 3, indicating both buses operational.

dbus
Data bus. The Starfire data path is normally 144 bits wide, with each 64-byte (plus ECC) transaction transferred in four cycles. To configure around failures, however, Starfire can operate on either 72-bit half of the data path, with each transaction using eight cycles. Each 72-bit half-datapath is referred to as a data bus when discussing configuration.

DCache
Data cache, internal to the UltraSPARC microprocessor chip.

DIMM
Dual Inline Memory Module. A small printed circuit card containing memory chips and some support logic. See bank. In Starfire, DIMMs are 72 bits wide, so a group of eight are required for a 576-bit memory superword. This is translated by the PUP asics on the memory module to four cycles on the 144-bit UPA data path.

This is organized so that each DIMM provides the same 18 bits in each cycle of the UPA transaction.


domain
A set of one or more Starfire system boards that are isolated by JTAG configuration registers, and which are capable of running a unique instance of Solaris. Starfire hardware supports up to 16 domains, the software may support fewer.

POST always runs in a single domain, whose name is normally obtained from the SSP environment variable SUNW_HOSTNAME. Using this name, POST queries the SNMP database for information about the system boards in the domain.


domain cluster
A Starfire hardware/firmware term for a set of system boards which have been isolated using the domain cluster mask registers in the GAARB and GDARB asics on the centerplane. Bus transactions in a domain cluster are seen as idle bus cycles by other domain clusters. Arbstops, recordstops, bus hold conditions, etc., are contained within a domain cluster by the filter logic in the GAARB and GDARB. As a result, there is almost complete isolation of hardware faults to a single domain cluster.

Domain clusters will usually contain only a single domain, but will contain more than one if the domains have been configured to share memory.


domain transgression error
An error detected by GDARB in which the LDARB on a system board requests to transfer a data packet to another system board, where the target board is not in the same domain cluster as the source board.

In most cases transgression error would indicate a hardware error, since the data interconnect will not attempt to move data unless an address transaction indicates this should occur, and out-of-domain addreses are filtered by the domain logic in the address arbitration. However, interrupt address transactions sent to out-of-domain boards will be also ignored, and the lack of a NACK causes the data subsystem to try to transfer the mondo vector, so that software can cause this error by sending interrupts to target processors out of its domain.

When enabled, transgression error causes an arbstop in the source domain. However, it has been discovered that certain failures on one system board, such as a power supply failure, can corrupt the LDARB -> GDARB interface so as to cause both a transgression error and a parity error, which causes GDARB to request a global arbstop. To avoid this, transgression error reporting is disabled when configuring GDARB. Transgressing requests will still be inhibited, so they won't affect other domains, but they will not be reported. Real hardware transgresion errors will probably result in more obscure errors within the source domain, such as timeouts or queue underflows. Bogus interrupts will simply be discarded, with no error.

Reporting of transgression error by GDARB can be enabled with the .postrc command dom_transgress_err_enbl, if this is used when POST is run with -C to configure the centerplane. This may be useful in debug environments where more obscure errors are detected and transgression errors are suspected.


DR
Dynamic Reconfiguration.

dram
Dynamic ram. Hardware memory chips that require periodic rewriting to retain their contents. This process is called refresh. In Starfire, dram is used primarily on main memory DIMMs, and on the control board.

DTAG
Duplicate Tag. A copy of the cache tag and state for data in each processor's ecache, and each IOC, maintained by the system interconnect to improve cache coherency performance. Implemented in Starfire by the CICs, and attached static ram chips.

The DTAGs can be a source of confusion when they are detected to have failed. Because the DTAGs for each processor and IOC are distinct hardware resources, POST will often only mark the affected processor or IOC as FAILed, allowing the other resources on the system board to continue operation. However, it is the system board that must be replaced to fix the problem, not the processor or IO module.


dumpfile
An SSP file of Starfire hardware state created by hpost -D, or automatically by POST when it encounters an Arbstop or Recordstop during testing. This is a packed binary file. It can be opened for examination by the redx dumpf command.

Dynamic Reconfiguration
(DR) A feature of Starfire that allows attach and detach of the resources (processors, memory, and I/O) of a system board to or from a domain while the operating system is running in that domain. A special mode of POST (hpost -H) exists to support DR. See also hotswap.

E



ecache
External Cache. A synchronous static ram second-level cache local to each processor module. Used for both code and data. This is a direct-mapped cache. Sizes can range from 512 KBytes to 16 MBytes (Not all these sizes may actually exist).

ECC
Error correction code. In Starfire, ECC is used in two places. First, the entire datapath, as generated and checked by the UltraSparc processors and IO controllers, and as stored in memory, is protected by 8 redundant check bits on each 64-bit data word. The data ECC used in Starfire allows correction of single-bit errors and detection of all double-bit errors, as well as detection of 3 and 4-bit errors if all erroneous bits are confined to the same nibble (group of 4 bits).

Second, the global address bus (GAB) between the CIC asics and between the CIC and MC asics is protected by eight check bits on each 38 bits of information, allowing correction of single-bit errors and detection of all double-bit errors on these address connections.

See also recordstop.


Edd
Event Detector Daemon. An SSP process responsible for monitoring and responding to events occuring in the Starfire host. Much of its work is done by Tcl scripts downloaded to the control board and run by the CBE.

elf
Executable and Linking Format. A structure and file format for executable object and library files. See man elf(3E). The Starfire POST host executable images downloaded to bbsram are in elf format, and are given the filename extension ".elf", as in "stage1.elf".

F



FPGA
Field Programmable Gate Array. See JBC.

FOM
Figure of Merit. A calculation used by POST to decide how to configure the system in the presence of failures. See Figure of Merit in the POST User's Guide.

FRU
Field Replaceable Unit. A component that can be replaced at a customer's site.

G



GAARB
Global address arbiter asic. One per GAB, (four total) located on the centerplane. GAARB is a mode of the XARB asic.

POST and redx designate a particular GAARB as gab, e.g., "GAARB 1", meaning the GAARB for GAB 1.
The redx command to display GAARB registers is shgaa.


GAB
Global Address Bus. Starfire's address and control interconnect between system boards. There are four GABs, which split up the traffic based on addresses. Starfire can be configured to use three, two, or even one GAB for all the address traffic when failures are present. The GAB interfaces to the CIC on each system board, and is routed by the GAMUX on the centerplane. (See abus).

GAMUX
Global Address MUX asic. Also known as Global Address Router (GAR). Four 12-bit chips are required for each 46-bit GAB. There are four sets, one per GAB, (16 asics total) located on the centerplane. This is a broadcast (one system board to all system boards) routing, but electrically point-to-point. The GAMUX is a mode of the XMUX asic.

POST and redx designate a particular GAMUX as gab.slice, e.g., "GAMUX 1.0", meaning the GAMUX that handles slice 0 (bits [11:0]) for gab 1.
The redx command to display GAMUX registers is shgam.


GDARB
Global data arbiter asic. One per half-centerplane, located on the centerplane. GDARB handles data arbitration for one half of the data crossbar, also referred to as a dbus.

POST and redx designate a particular GDARB as dbus, e.g., "GDARB 1", meaning the GDARB for dbus 1.
The redx command to display GDARB registers is shgda.


global arbstop
A class of error that occurs when the GDARB asic detects multiple errors, as explained below, and requests that GAARB declare an arbstop for all domains in the Starfire cabinet.

GDARB can detect three types of errors on the request bus from the LDARB asic on each system board:

If GDARB detects more than one type of error from one or more system boards, or if it detects errors from more than one system board, it will assert Multiple Error to GAARB, resulting in a global arbstop.

group
An alternate term for bank.

H



hex
Hexadecimal. Base sixteen numerical notation, using symbols A-F to indicate 10-15.

host
The Starfire system proper, as distinguished from the SSP.

hostview
A graphical user interface (GUI), generally run on the SSP, that provides the main user interface for control of Starfire boot and configuration.

hotswap
A feature of the Starfire system that allows some resources, most notably system boards, to be physically inserted and removed from the system with power on and the operating system running on other parts of the Starfire. See also Dynamic Reconfiguration.

hpost
The name of the executable ssp program that contains the POST controller and sequencer (PCS). See man page: hpost(1M). and Starfire POST user's guide.

I



ICache
Instruction cache, internal to the UltraSPARC microprocessor.

interleave
The concept of assigning consecutive periodic ranges of physical address to different hardware components, to level out the memory bandwidth utilization by involving more hardware resources. In Starfire there are three levels of interleave:

Physical addresses are interleaved across the address buses by the initiating PC, depending on the address bus configuration (See abus).

The MC asic may be configured to interleave the banks of memory it controls based on the address bus and physical address, depending on the number of active address buses and memory banks. In many cases, however, this will not provide any further interleave. For example, in the normal case there are four address buses. If there are four banks of memory, then each is connected directly to an abus. If there are two banks of memory, then the address buses are actually de-interleaved as two buses per bank.

Lastly, two boards with the same memory configuration can be interleaved based on a Physical Address bit. This is disabled by default because it can reduce the ability to use Dynamic Reconfiguration detach. It can be enabled from the .postrc file.


IOC
I/O Controller. The interface, generally a single asic, between the UPA bus and an I/O bus. In Starfire, IOCs are located on the IOM (I/O Module) on each system board. See SYSIO and PSYCHO+.

IOM
I/O Module. A daughter board that can be installed on a Starfire system board, which contains one or more IOCs and slots for I/O adapter cards (scards).

J



JBC
Jtag Board Controller. A FPGA or small asic present on each system, control, and centerplane support board, which distributes the JTAG+ interface.

JPR
JTAG Private Register. A 64-byte register in each XDB asic used as the source or destination of data for a few special system operations initiated by SSP software via JTAG operations to the associated PC or MC asic. The most significant of these operations is the capability for the SSP software to send an interrupt to a processor. In this case, the JPR is first loaded with the mondo vector data of the interrupt. This is done by JTAG bootbus operations to the PC. The JPR is in bootbus address space, but only when accessed via JTAG; it is not directly accessible to host-side software.

The JPR also supports some JTAG hardware peek and poke operations to memory and UPA ports. To support the memory functions, the JPR can also be accessed by JTAG directly to the XDB, but this is only possible when no system activity is in process.


JTAG
A serial scan interface specified by IEEE standard 1149.1. The name comes from Joint Test Action Group, which initially designed it. See JTAG+.

JTAG+
An extension of JTAG, developed by Sun Microsystems Inc., which adds a control line to signal that board and ring addresses are being shifted on the serial data line. Often referred to simply as JTAG. JTAG+ is an interface between the Starfire control board and the JBCs on each system, control, and centerplane support board. It is the only interface to the system board and centerplane hardware used by POST.

JTAG Interrupt Test
The Starfire PC and XDB asics have a feature that allows SSP software, via JTAG to the PC, to send an interrupt, including a mondo vector, to any UltraSPARC processor. In the JTAG Interrupt Test, each processor requests a series of interrupts to be sent to itself by the PCS with prescribed data. When the interrupt arrives, the data in the mondo vector is compared with what was expected. Bad data will cause a failure, and if an interrupt does not arrive, the test will timeout and fail.

JTAG lock
An SSP and CBE software mechanism for providing exclusive access to JTAG resources by an application. Performing some system management operations requires an application to have exclusive access to parts of the hardware over several low-level JTAG operations, with no opportunity for a different application to change the hardware state.

To achieve this, SSP core software provides a three-level hierarchical locking facility that allow an application to reserve exclusive access to an individual JTAG ring, an entire board's JTAG resources, or all the JTAG in the entire cabinet.

K



L



LAARB
Local (to system board) address arbiter asic. One per system board. LAARB is a mode of the XARB asic.

POST and redx designate a particular LAARB as board, e.g., "LAARB A", meaning the LAARB on system board A (10 decimal).
The redx command to display LAARB registers is shlaa.


lab
Local Address Bus. The address path interconnection between the PC and CIC asics on a Starfire system board. This is not a multidrop bus, but rather 12 seperate bidirectional point-to- point connections between the three PCs and four CICs. The numbering of the labs is generally with respect to a specific PC or CIC asic's connections. Each PC supports four labs, [3:0]. Each CIC supports three labs, [2:0]. The labs are parity protected, one parity bit on each 19-bit half of the bus.

LDARB
Local (to system board) data arbiter asic. One per system board. LDARB is a mode of the XARB asic.

POST and redx designate a particular LDARB as board, e.g., "LDARB A", meaning the LDARB on system board A (10 decimal).
The redx command to display LDARB registers is shlda.


ldat bus
Local data bus. The 144-bit UPA data connection between the XDB asic and the LDMUX asics. This is not a multidrop bus, but rather a pair of unidirictional point-to-point buses between the LDMUX and each of four XDBs on a system board.

The buses from XDBs to LDMUX are called ldat_x0 - ldat_x3.
The buses from LDMUX to XDBs are called ldat_r0 - ldat_r3.


LDMUX
Local Data MUX asic. Also known as Local Data Router (LDR). Four XMUX asics, each providing a 5 x 36-bit bidirectional multiplexor, interconnect the 144-bit data path between the centerplane (XBAR) and the four XDB chips on each system board. The LDMUX is a mode of the XMUX asic.

POST and redx designate a particular LDMUX as board.slice, e.g., "LDMUX A.2", meaning the LDMUX that handles slice 2 (bits [35:0] of dbus 1) on system board A (10 decimal).
The redx command to display LDMUX registers is shldm.


LDPATH
The pair of LDMUX asics that comprise a system board's interface to one dbus.

LED
Light Emitting Diode.

level
An integer control parameter to POST. that controls the thoroughness of the testing it does. See Levels in the POST User's Guide.

lock
In the POST and SSP context, this usually refers to a software exclusion mechanism provided by CBS that allows an application to secure exclusive access to a JTAG ring, board, or the entire system, for a period of time.

lockfile
An SSP unix file used as a semaphore to prevent simultaneous execution of more than one POST process on a Starfire domain. See the .postrc command "no_lockfile".

M



MC
Memory Controller asic. Supervises the operation of the memory on each Starfire system board. It is not in the memory datapath. It receives a copy of GAB transactions from all of the four CICs, and sequences the drams, PUPs, and memory XDB to effect memory reads and writes directed to it.

POST and redx designate a particular MC as board, e.g., "MC A", meaning the MC on system board A (10 decimal).
The redx command to display MC registers is shmc.


MemAddrMap
Because domains can be joined together to share memory in a domain cluster, it is necessary to guarantee that all Physical Addresses in the Starfire cabinet are unique. This is done by assigning each board a unique 8 GByte address range, sometimes called the "logical memory board" number.

However, certain operations performed by Dynamic Reconfiguration and POST will exchange the assignments of memory addresses on physical boards. This mapping of PA ranges to physical boards is maintained in an SNMP element called the MemAddrMap.


memory module
A daughter board that can be installed on a Starfire system board, which contains sockets for four banks of eight dram DIMMs, and four PUP asics.

MIB
Management Information Base. An element or set of elements of the database provided by an SNMP implementation.

MMU
Memory Management Unit. The hardware in each UltraSPARC processor that handles virtual to physical address translation.

mondo vector
UltraSPARC supports an interrupt mechanism which contains three 64-bit doublewords of data communicated from the interrupt source to the target processor. This extended (over previous architectures) data content allows rapid processing by the target processor by avoiding polling of the interrupt source device.

MOVI Test
Moving Inverses Test. Used in testing memory and DTAGs, this test verifies every cell of the resource for at-speed adjacency and stuck-at faults as well as read-write and write-read contention and speed problems by running a sequence of bit patterns through every location. This test runs in three passes: first, all locations are written with one of the patterns; second, at maximum speed in ascending address order a read-write-read is performed with the write operation storing the inverse of the first pattern; third, at maximum speed in descending address order a read-write-read is performed with the write storing the original pattern.

For Starfire POST's main memory test, errors are caught via the ECC trap mechanism in the hardware; the value at each location is not explicitly tested. When testing other resources, there is explicit testing of the values.

N



netcon
The network console feature of Starfire. This provides the domain's console over the network during OS operation, eliminating the need for a serial interface I/O card, and simplifying remote console operation. During OBP, netcon uses polled mailboxes in bbsram as the communication path.

nibble
Four bits. From "half a byte".

NMB
Non-Memory Board. A system board with no good memory.

NPB
Non-Processor Board. A system board with no good processors.

O



OBP
Open Boot Prom (or Open Boot Process). A layer of software that takes control of the configured Starfire from POST, builds some data structures in memory, and boots the operating system.

OS
Operating system. Usually Solaris.

P



PA
Physical Address.

PC
Port Controller asic. Each PC provides the address and control interface between two UPA ports and the Starfire system interconnect, primarily by connection to four CICs on the local address buses on each system card. Three PCs are used on each system card; two for the four processor slots, and one for the two IOCs on the I/O module. The processor PCs also provide an interface to bbsram for the processors. The PCs on each system board are numbered 0 through 2. PC 0 handles processors 0 and 1. PC 1 handles processors 2 and 3. PC 2 is the I/O PC, handling IOCs 0 and 1.

POST and redx designate a particular PC as board.asic, e.g., "PC A.1", meaning PC asic number 1 on system board A (10 decimal).
The redx command to display PC registers is shpc.


PCB
Printed circuit board.

PCI
Personal Computer Interface. An industry standard I/O Bus.

PCS
Post Control and Sequencer. The logical entity contained in the SSP executable binary file hpost, which controls the operation of POST.

phase
The highest-level organizational stucture of POST. All host processors and the PCS will always be running the same phase at any time. The phase is also the unit of recovery restart when arbstops, recordstops, and processor timeouts occur during POST execution. See An Introduction to Starfire POST Program Structure in the POST User's Guide.

physical address
The addressing used on the Starfire UPA interconnect. This is a 41-bit address, PA[40:0]. See also virtual address.

pid
Process ID. An integer that uniquely identifies each running process in a unix system. See the unix man page for ps(1).

PLL
Phase locked loop. Most of the Starfire asics use a pll in their internal clock distribition to minimize system clock skew.

POST
Power on Self Test. The program that takes uninitialized Starfire hardware and probes and tests its components, configures what seems worthwhile into a coherent initialized system, and hands it off to OBP.

.postrc
A text file of directives that modifies the behavior of POST. See man page: postrc(4M).

post2obp structure
A structure that contains all required information about the configuration created by POST, passed to OBP in bbsram of the boot processor. The post2obp structure includes the Board Desciptor Array, the memory chunk list, and some auxiliary information.

processor module
A small circuit board containing an UltraSPARC processor, two UDB asics, ecache sram, and support logic for them. There are sockets for four processor modules on a Starfire system board.

psi bus
Port/System Interface bus. The 144-bit or 72-bit UPA data connection between the XDB asic and the two associated UPA ports, or for XDB3 on each board, between the XDB and the PUP asics on the memory module.

PSYCHO+
One type of IO Controller that may be used in Starfire in the future. Provides connection of a UPA port to a PCI bus.

PUP
Pack/UnPack MUX. Also called PUMUX. Used on the memory module to convert a 576-bit dram superword into four cycles of 144-bit UPA data words. Four PUPs are used. PUPs 0 and 2 handle banks 0 and 2. PUPs 1 and 3 handle banks 1 and 3. PUPs 0 and 1 handle DIMMs [3:0] of their banks, PUPs 2 and 3 handle dimms [7:4]. (A diagram of these connections can be found in the note Using redx to Debug a Data Recordstop).
PUP is a mode of the XMUX asic.

POST and redx designate a particular PUP as board.asic, e.g., "PUP A.1", meaning the PUP numbered 1 on the memory module on board A (10 decimal).
The redx command to display PUP registers is shpup.

Q



R



RAS
Reliability, Availability, and Serviceability.

recordstop
A condition caused by a data See ECC error, or a correctable See GAB ECC error, which causes the freezing of history buffers in all modes of the XMUX asic, as well as some error capture registers in other asics. Recordstop cannot be directly detected by host software, and has no effect on performance. The recorded information can be dumped, and the dumpfile examined to determine where in the hardware the error occurred.

For a basic guide to understanding recordstops and how to deal with them, see Using redx to Debug a Data Recordstop.


redlist
An SSP text file that is read by POST. It declares certain system components to be completely off limits to POST, and requires that POST not change their state, even indirectly. This is very restrictive, and can cause POST to fail. It is promarily intended for special engineering lab uses. See Blacklist and Redlist in the POST User's Guide. and man page: redlist(4M).

redx
(Pronounced "Red Cross"). Remote Debugger for Xfire. A JTAG-based debugger for Starfire, associated with the POST program. Among other things, it is used to examine the dump files created by hpost -D. See man page: redx(1M) and Introduction to redx.

refresh
See dram.

Rn
redx resident Nurse. A code module that can be downloaded to bbsram of a processor by redx to permit access to system state only available to host processors. A helper module for redx.

S



SBus
A Sun Microsystems Inc. designed I/O bus, now an open standard. One kind of available Starfire IOM supports two SBuses, each with two SBus slots.

scard
An I/O adapter card, either SBus or PCI bus.

shared memory domain.
Synonym for domain cluster.

signature
See BIST. Also see signature block.

signature block
Also called sigblock. A structure maintained in a well-known location in each Starfire processor's bbsram, which provides a standard identification and communication mechanism between the program running on that processor and SSP processes.

POST attempts to maintain a valid sigblock on all processors it is testing, for identification by Edd and hostview. However, there are times during POST execution, such as before it has downloaded any host executables, while it is testing bbsram, and during download of additional host executables, when a valid sigblock will not be present.

Other than providing the POST signature for detection by Edd, and setting the post2obp structure pointer in the boot processor at the end of a successful configuration, POST does not use the sigblock. It uses its own private methods for communication between the host and SSP resident programs.


SIMM
Single Inline Memory Module. Often used to refer generically to memory packages, including the DIMMs used in Starfire.

SMD
Shared memory domain. Synonym for domain cluster

SNMP
Simplified Network Management Protocol. An industry-standard interface for controlling remote computing resources. The Starfire SSP software provides an SNMP service (MIB) for many aspects of the Starfire system. POST is a client of the SSP SNMP server to obtain and set some public MIB elements, but SNMP is not POST's primary interface to the Starfire hardware.

snmpd
SNMP Daemon. An SSP process that is the server for the Starfire SNMP services.

sram
Static ram. Hardware memory chips that retain their contents as long as power is maintained.

SSP
System Service Processor. A Sun workstation containing software for controlling power sequencing, diagnostics and booting of a Starfire. It is connected by ethernet to the Starfire control board, and is usually also networked to the Starfire system IO to provide system console services.

Spitfire
The nickname of the UltraSPARC-I processor.

subtest
In the context of Starfire POST, "subtest" refers to a very specific functionality, the lowest of three hierachical layers of the POST sequence, lower than tests. Subtests are only run in the host-resident code by the UltraSPARC processors. See An Introduction to Starfire POST Program Structure in the POST User's Guide.

syndrome
A value calculated from the data and check bits of an ECC protected word of data by combining them with operations and in combinations specified by the code in use. Each unique syndrome value corresponds to the case of no error, or correctable errors in a specified bit (or bits), or an uncorrectable error.

The redx parse command has options for calculating and interpreting the syndromes used in Starfire data and address paths.


SYSIO
One type of IO Controller (IOC) used in Starfire. Provides connection of a UPA port to an SBus.

system board
The main logic board that contains most of Starfire's functional units. A system board contains slots for 4 UltraSPARC, processor modules, an IOM, and a memory module, as well as bus interface asics, DC/DC converters, JTAG and clock distribution, and other support circuitry. A Starfire cabinet has slots for 16 system boards.

T



tag
A component of a cache subsystem which stores address and control information about the cache current contents.

test
In the context of Starfire POST, "test" refers to a very specific functionality, the middle of three hierachical layers of the POST sequence, higher than subtests, lower than phases. Tests are only run in the PCS on the SSP. They can either invoke the execution of a subtest list in the host-resident code, or execute on the SSP, possibly performing some JTAG configuration on the host. See An Introduction to Starfire POST Program Structure in the POST User's Guide.

transgression error
See domain transgression error.

U



UDB
UltraSPARC Data Buffer. A support chip for the UltraSPARC processor that handles 72 bits of the 144-bit UPA data interface.

UE
Uncorrectable error. See ECC.

UltraSPARC
A family of Sun Microprocessors implementing the SPARC V.9 architecture specification.

Ultra Enterprise 10000
The official Sun product designation for Starfire.

UPA
Ultra Port Architecture. The SMCC specification for the processor/ memory/IO interconnect architecture used by all Ultrasparc I and II products, including Starfire.

UPA Port
The interface between an UltraSPARC processor or an IOC and the Starfire interconnect. Starfire system boards provide sockets for four processor ports and two IOC ports.

V



virtual address
The addressing used internal to a processor. In UltraSPARC I and II, this is a 64-bit address, VA[63:0], but only a 44-bit subset is actually supported. See the UltraSPARC programmers reference guide.

Translation between virtual and physical addresses is through page tables in memory, which may be cached local to a processor. The address translation is done by the processor's MMU, usually transparently to the software.

W



wfail
The redx command that is usually the first thing used to determine what errors are captured in a Starfire hardware dumpfile.

X



XARB
Starfire Arbiter asic. A multimode asic type used to implement the Starfire GAARB, LAARB, and LDARB, functions. The mode is selected with two input pins hardwired on the PCB. It can be read via JTAG for checking.

XBAR
XBAR asic, also called the Global Data Router (GDR), or Global Data Mux (GDMUX). Provides the data interconnect for Starfire. 12 XBAR chips located on the centerplane provide a 144-bit datapath, with up to sixteen simultaneous point-to-point connections between any of the 16 system boards allowed. There are 6 XBARs on each half-centerplane or dbus. In a degraded mode, when configured around failures, the system will operate on either 72-bit half-datapath using 8 cycles instead of 4 to transfer a 64-byte data packet. XBAR is a mode of the XMUX asic.

POST and redx designate a particular XBAR as dbus.slice, e.g., "XBAR 1.2", meaning the XBAR that handles slice 2 (bits [35:24]) for dbus 1.
The redx command to display XBAR registers is shxbar.


XDB
Starfire Data Buffer asic. Provides the datapath interface between a UPA port or memory and the Starfire system interconnect. There are four XDBs on each system board: One associated with each PC asic, and one (numbered 3 on each board) associated with the MC and memory. The XDB has slightly different operating modes in these different applications.

POST and redx designate a particular XDB as board.asic, e.g., "XDB A.1", meaning XDB asic number 1 on system board A (10 decimal).
The redx command to display XDB registers is shxdb.


Xfire
Pronounced "Crossfire". An early nickname, now deprecated, for Starfire.

XMUX
Starfire MUX asic. A multimode asic type used to implement the Starfire GAMUX, LDMUX, PUP, and XBAR functions. The XMUX is basically a 12-bit 36-port universal crossbar multiplexer chip. The mode is selected with two input pins hardwired on the PCB. It can be read via JTAG for checking.

XOR
Logical Exclusive OR.

Y



Z



0-9



5/A Test
This test is identical algorithmically to the BSS Test but only one set of patterns is used. Thus, every bit is tested, but only superficially, for stuck-at-1 and stuck-at-0. The purpose of this test is to provide a very quick, light-weight verification of the resource's functionality.


Maintained by:
Dan Drogichen (drog@marvin.west.sun.com)