User guide

User Guide CC8-BLUES • Multi-Processing CompactPCI CPU
- 30 -
EKF Elektronik GmbH • Philipp-Reis-Str. 4 • 59065 HAMM • Germany
Tel. [phone] • Fax. [phone] • E-Mail [e-mail] • Internet http://www.ekf.de
Non-Transparent PCI Bridge
Unlike the VMEbus, the CompactPCI bus was not designed for multiple processor boards which
share a common backplane. Instead, (only) one system slot controller (CPU board) has been
defined; all other card slots are reserved for peripheral I/O boards. In order to achieve multi-
processing, additional CPU boards on the CPCI bus must hide themselves behind a so called
non-transparent PCI bridge. This is what mainly distinguishes the CC8-BLUES from system slot
controllers such as the CC7-JAZZ, which is provided with a transparent PCI bridge.
The CC8-BLUES is equipped with a 21555 non-transparent PCI bridge. The Intel® 21555 is a PCI
peripheral device that performs PCI bridging functions for embedded and intelligent I/O
applications. The 21555 has a 64-bit primary interface, a 64-bit secondary interface, and 66-
MHz capability. The 21555 is a “non-transparent” PCI-to-PCI bridge that acts as a gateway to an
intelligent subsystem. It allows a local processor to independently configure and control the
local subsystem. The 21555 implements an I
2
O message unit that enables any local processor to
function as an intelligent I/O processor (IOP) in an I
2
O-capable system. Since the 21555 is
architecture independent, it works with any host and local processors that support a PCI bus.
Unlike a transparent PCI-to-PCI bridge, the 21555 is specifically designed to bridge between two
processor domains. The processor domain on the primary interface of the 21555 is also referred
to as the host domain, and its processor is the host processor. The secondary bus interfaces to
the local domain and the local processor. Special features include support of independent
primary and secondary PCI clocks, independent primary and secondary address spaces, and
address translation between the primary (host) and secondary (local) domains. The 21555 uses
a Type 0 configuration header, which presents the entire subsystem as a single “device” to the
host processor. This allows loading of a single device driver for the entire subsystem, and
independent local processor initialization and control of the subsystem devices. Since the 21555
uses a Type 0 configuration header, it does not require hierarchical PCI-to-PCI bridge
configuration code. The 21555 forwards transactions between the primary and secondary PCI
buses as does a transparent PCI-to-PCI bridge. In contrast to a transparent PCI-to-PCI bridge, the
21555 can translate the address of a forwarded transaction from a system address to a local
address, or vice versa. This mechanism allows the 21555 to hide subsystem resources from the
host processor and to resolve any resource conflicts that may exist between the host and local
subsystems.
The 21555 is functionally similar to a transparent PCI-to-PCI bridge (PPB) in that both provide a
connection path between devices attached to two independent PCI buses. A 21555 and a PPB
allow the electrical loading of devices on one PCI bus to be isolated from the other bus while
permitting concurrent operation on both buses. Since the PCI Local Bus Specification restricts PCI
option cards to a single electrical load, the ability of PPBs and the 21555 to spawn PCI buses
enables the design of multi device PCI option cards. The key difference between a PPB and the
21555 is that the presence of a PPB in a connection path between the host processor and a
device is transparent to devices and device drivers, while the presence of the 21555 is not. This
difference enables the 21555 to provide features that better support the use of intelligent
controllers in the subsystem such as the CC8-BLUES. A primary goal of the PCI-to-PCI bridge
architecture was that a PPB be transparent to devices and device drivers. For example, no
changes are needed to a device driver when a PCI peripheral is located behind a PPB. Once
configured during system initialization, a PPB operates without the aid of a device driver. A PPB
does not require a device driver of its own since it does not have any resources that must be
managed by software during run-time. This requirement for transparency forced the usage of a