|
【范围】
|
This section defines the scope of the document, provides a brief history of the Pi-Bus, discusses
key features of the Pi-Bus, and provides an overview of the operation of the Pi-Bus.
This docum ent is a handbook intended to accompany AS4710 Pi-Bus standard. The purpose of
this docum ent is to provide inform ation to aid users of the Pi-Bus, whether they be im plem entors of
Pi-Bus controllers, architects of system s considering using the Pi-Bus, or program m ers who must
develop applications in a system which uses the Pi-Bus as the backplane com m unications bus.
This docum ent also provides rationale for many of the Pi-Bus requirem ents as defined in AS4710
and a discussion of potential enhancements that are being considered fo r the Pi-Bus.
The follow ing is a mapping of m ajor sections in this docum ent fo r particular audiences:
a. Overview of Pi-Bus and its capabilities: Section 1
b. Pi-Bus rationale: Sections 3 ,4 , and 5
c. inform ation fo r IC designers: Sections 3, 4, 5, 8, and 9
d. Inform ation fo r system designers/architects: Sections 1, 6, 7 and 9
e. Inform ation fo r software designer: Sections 1, 6, and 7
The follow ing is a synopsis of the history of the Pi-Bus.
1.1 H istory of the Pi-Bus:
The Pi-Bus became an SAE standard on 10 May 1993. The history of the Pi-Bus and its path
towards standardization is interesting in that the Pi-Bus was firs t defined in a specification
developed fo r the Very High Speed Integrated C ircuit (VHSIC) program , m aturing of the
specification became possible due to several im plem entations and interoperability studies,
studies were then perform ed to increase the perform ance of the Pi-Bus, and fin a lly industry
standardization occurred. The rem ainder of this paragraph provides a brief synopsis of this
history.
In 1985, IBM, Honeywell, and TRW developed the Pi-Bus specification as part of the VHSIC
program . Its purpose was to provide a highly reliable m ultidrop backplane bus to support the
com m unication between loosely coupled modules via message passing. The VHSIC Pi-Bus
specification defined the Pi-Bus by describing its physical layer and data link layer. W estinghouse
developed the firs t (not com pletely com pliant) Pi-Bus im plem entation in 1987 as part of the
W right Laboratory VAMP program . This im plem entation was im portant in that its device-side
interface, which is not specified in the Pi-Bus specification, was used as the baseline for device-
side interfaces fo r many future Pi-Bus im plem entations. By coincidence in 1987, the original
JIAW G platform s (A-12, ATF DEMA/AL, and LH DEMA/AL) all used the Pi-Bus as their
backplane com m unication bus. Because of this com m onality, the Pi-Bus became the standard
JIAW G backplane interm odule com m unications bus. IBM, TI and Unisys were the prim ary Pi-Bus
vendors fo r the JIAW G program s. In early 1988, through discussions w ithin the SAE Pi-Bus
W orking Group and sim ulations perform ed under the Zycad-Air Force Dem onstration of Avionic
Module Exchangeability via Sim ulation (DAMES) program , it became apparent that the three
im plem entations were not com pletely interoperable. McDonnell Douglas A ircraft initiated a series
of Pi-Bus interoperability working group meetings between IBM, TI and Unisys in the summer of
1988. The purpose of these m eetings was to clarify and com plete the VHSIC Phase 2 Pi-Bus
S pecification to insure that post 1991 Pi-Bus im plem entations provided by different vendors
would be interoperable on the JIAWG platform s. These m eetings were eventually follow ed by
form ation of the JIAW G Pi-Bus W orking Group, which was the group w ithin the JIAW G
responsible fo r producing a JIAWG Pi-Bus Specification. The JIAWG Pi-Bus W orking Group
o fficia lly began m eeting in A pril 1989. Also in 1989 the Navy awarded a contract to IBM to look at
perform ance enhancem ents fo r the Pi-Bus. One of these, a more efficient type of message
called a datagram , was included in AS4710. Also, in this tim efram e, DELCO was awarded a
contract to develop a 32-bit Pi-Bus fo r the F-22 program.
The SAE AS-2 Com m ittee had been used as the industry user's group fo r the Pi-Bus since its
inception in VHSIC Phase 2. The JIAWG Pi-Bus W orking Group met in concert w ith the SAE AS-
2 C om m ittee. This group developed a revised version of the VHSIC Pi-Bus Specification called
the JIAW G Pi-Bus Specification. The updates included specification am biguity cleanup, detailed
specification of error management, and the additions of new features required by JIAW G for a
32-bit datagram message. It was decided in 1989 that the SAE should attem pt to make the Pi-
Bus into an SAE standard so that the Pi-Bus could be truly an open system s interface standard.
During this process, the JIAWG standard was updated to be technically the same as the SAE
draft standard in order that the JIAWG could reference AS4710 instead of the JIAW G Pi-Bus
S pecification. This process com pleted 10 May 1993 with the Pi-Bus becoming SAE standard
AS4710. The JIAW G now references AS4710. Associated with the developm ent of AS4710, the
SAE and DoD worked together to form a Pi-Bus Advisory Board. The Advisory Board consists of
a single member from each service and the chairman of the SAE Pi-Bus W orking Group. The
purpose of the Advisory Board is to provide a form al com m unication mechanism between the
DoD and SAE fo r guidance on revisions of AS4710, handbooks, and user group activities.
1.2 Pi-Bus Key Features:
This section provides a brief discussion of Pi-Bus key features. The view of these features is that
of the user. This section is organized as follow s:
a. Section 1.3.1 discusses general capabilities of the Pi-Bus.
b. Section 1.3.2 describes Pi-Bus message passing features.
c. Section 1.3.3 provides an overview of a typical Pi-Bus software interface.
d. Section 1.3.4 lists several programming paradigms using the Pi-Bus.
1.2.1 G eneral C apabilities: As noted in Figure 1 the Pi-Bus can be either a 16-bit or 32-bit parallel
backplane bus. The Pi-Bus is a loosely coupled, message passing bus. Up to 32 modules can
com m unicate over a single Pi-Bus. A 16-bit Pi-Bus is error detecting (ED), w hile a 32-bit Pi-Bus
is error correcting (EC). [Note this is a change from the VHSIC Pi-Bus Specification in which a
16 or 32-bit Pi-Bus could be either error detecting or error correcting.] The P Bus uses a
synchronous clock which is specified to run at a maximum of 12.5 MHz.
{194aacedef5fc7685afb1bb33bf1787a.jpg}
The m odule connection to the Pi-Bus is a dot-or connection to negatively defined signals.
Therefore, any module can assert a logical one. A logical zero is present only if no module is
asserting a one. G enerally, a ll modules are constantly presenting signals to the Pi-Bus.
However, they are generally logical zeroes.
A Pi-Bus can be in one of two operational states, active or inactive. It is in the inactive state
when no m odule is asserting signals, i.e., no message activity. The Pi-Bus is in the active state
when one or more modules are asserting signals, i.e., there is a vie or message activity.
A m odule consists of a Device and a Bus Interface Unit (BIU) as shown in Figure 2. The
M aster portion of a BIU can obtain control of the Pi-Bus and initiate m essages. The Slave
portion responds to Pi-Bus messages addressed to it. There are two types of modules,
M aster/Slave m odules and Slave Only m odules. Only the M aster/Slave modules can initiate
bus m essages. Both module types can respond to messages. The M aster portion can initiate
a message which addresses its companion Slave portion.
{8e5a3f1f58476b9c6d4e3b327d85f766.jpg}
The Pi-Bus is an open systems standard which has several features which are beneficial for
avionics com puters. Some of these include the follow ing:
a. fa u lt tolerance support
b. backplane m ission tim e distribution source
c. optim ized message passing
d. real-tim e program m ing support
e. logical slave identifiers and labels
f. either centralized or distributed initialization
g. security support
h. sim plified softw are interface.
The follow ing subparagraphs describe each of these items in further detail.
1.2.1.1 Fault Tolerance Support: One of the most distinctive features of the Pi-Bus is its support for
fa u lt tolerance. This section discusses how the Pi-Bus supports fault tolerance.
The Pi-Bus is inherently supportive of module level fault containm ent since it is a loosely
coupled, message passing bus. This is in contrast to the poor fault containm ent provided by
the typical tightly coupled buses which access memory a word (or byte or m ultiple bytes) at a
tim e, such as VME or Futurebus+. This follow s due to Pi-Bus features such as hardware
supported interm odule com m unication containm ent boundaries, an error management
protocol which supports detection and isolation of contam inated memory, the ability for
softw are to control access to its memory, and explicit software control of interm odule
com m unication.
The Pi-Bus provides detection of 100% of single line faults on both data and control lines. In
addition, the 32-bit Pi-Bus provides single line error correction on both data and control lines.
This is in contrast to most buses which either provide no error detection or if they do, it
typically applies only to the data lines.
For a single backplane which desires to support fault tolerance, either a single 32-bit error
correcting Pi-Bus is used or dual 16-bit error detecting Pi-Buses are used. The F-22 CIP
uses a 32-bit error correcting Pi-Bus. In the 16-bit case, typically one bus is used as a
prim ary, w hile the second Pi-Bus is used as a redundant backup in case of failure of the
prim ary. Such is the case fo r the ATF YF-22 D em onstration/Validation M ission Display
Processor, the F-16 Main M ission Computer (MMC), the F-22 Vehicle Management System,
Comanche Helicopter, and F-15 Computer upgrade. For the 16-bit case, typically a single Pi-
Bus Interface Unit (PIU) is used with two sets of transceivers since the typical failure is
expected in the connector pins instead of the electrical circuitry. The PIU is commanded by
softw are to select one of the two. In the 32-bit case, only one bus is typically used. Such is
the case w ith the F-22.
In order to m inim ize the chance of a single module "bringing down" a Pi-Bus, there is no
centralized control - the protocol uses a distributed Vie for gaining M astership of the bus. In
addition, there is an absolute tenure tim e-out to bound a m aster's tenure. If a PIU or its
transceivers are faulted on a module, the module software may disable transceivers to
remove the PIU from one or both buses. In addition, if a TM-Bus is used in the system (as is
suggested in AS4710), then a m odule's transceivers may be disabled from off module via a
TM -Bus command.
The Pi-Bus requires a central, synchronous clock. In order to prevent the clock from being a
single point of failure, many im plem entations im plem ent dual clocks. Use of a synchronous
clock allow s the latching of bus signals after the "w ire-or-glitch" which causes problem s in
other buses that use BTL levels. The synchronous protocol also allow s the use of sim ulation
to prove the validity of a design while an asynchronous design can never be com pletely
proven.
The Pi-Bus is com pact -- it has a relatively sim ple protocol, sm all num ber of pins, and typically
is a single chip im plem entation. This im plies the typical Pi-Bus im plem entation is robust.
Finally, the Pi-Bus supports hardware acknowledgments not only on singlecast messages but
also on m ulticast/broadcast messages. This not only allows for quicker determ ination of the
success of a message, but reduces bus tra ffic by not requiring softw are to transfer
acknowledgm ents to the sender. This allows operating system softw are to im plem ent a retry
protocol w ithout requiring either application interaction or acknowledgm ent messages being
sent on the bus. The hardware acknowledgments also provide additional inform ation which
can be used for fault detection/isolation or determ inations such as a slave or slave's label was
busy when a message transfer was attem pted. (W hat is meant by slave label is discussed in
1.4.1.5.)
1.2.1.2 Backplane M ission Time D istribution: Consistent tim e distribution is a common problem for
distributed system s. The Pi-Bus provides hardware support fo r system tim e distribution. A
PIU im plem ents a 48-bit system tim er register with a 1 MHz clock (i.e., w ith 1 m icrosecond
resolution). A bus interface message is used for transferring system tim e values directly
between the system tim er registers of the M aster and Slave(s). When one module transm its
system tim e to another m odule, the system tim ers are to be synchronized w ithin 12.5M /(Pi-
Bus clock frequency) m icroseconds. Thus, if a 12.5 MHz Pi-Bus is being used, at the end of
distributing system tim e, the system tim e of the M aster and Slaves are guaranteed to be
synchronized w ithin 4 m icroseconds.
The follow ing are example uses of system tim e distribution.
a. If it is im portant fo r applications executing on modules within a backplane to be
synchronized with system tim e outside of the backplane, the follow ing method has been
used. A module w ithin the backplane (e.g., High Speed Data Bus (HSDB) or 1553B
interface m odules) has the capability to accurately receive system tim e external to the
backplane. On receiving a system tim e update, the special module broadcasts the
system tim e to other modules on the backplane. Depending on the accuracy required, the
special module may require hardware support for loading the Pi-Bus system tim er upon
receiving a m ission tim e update from its external source.
b. If applications w ithin a backplane only need to be synchronized among them selves, i.e.,
not w ith applications external from the backplane, then there are two general approaches
fo r system tim e distribution:
(1) A m aster tim e module can be chosen which periodically distributes its system tim e to
the other modules in the backplane. Protocols can be chosen fo r changing the
m aster tim e module. For example, this m ight occur if unacceptable variations are
seen in its tim e distribution.
(2) A m aster tim e module can be chosen whose system tim er is periodically read by all
m odules. Protocols can be chosen for changing the m aster tim e module.
1.2.1.3 O ptim ized Message Passing: The Pi-Bus was designed with message passing as a basic
requirem ent. Because of th is the Pi-Bus includes an optim ized message passing protocol
which supports fault tolerance and real-tim e programming. Some of these optim ized message
passing features are:
a. low overhead message passing protocol
b. message priorities
c. variable length tenure
d. message suspend/resum e
e. several types of messages.
A PIU is a direct memory access (DMA) device which allows Pi-Bus transfers to occur w ithout
causing a scalar processor to stall in either the M aster or Slave(s) m odules. This not only
increases perform ance but also makes data processor execution more determ inistic. This is
in contrast to processors using a tightly coupled bus in which the data processor either acts
as the DMA controller or is stalled or\ read accesses to memory.
The typical PIU supports the sending of "chained" messages so that a M aster may use a
single command to invoke the PIU to transfer a set of messages w ithout requiring additional
processor interaction during the transfer of the m essage(s). In addition, Slave processors are
not involved w ith a message transfer w hile it is in progress - Slaves may be notified of the
arrival of a message by an interrupt with inform ation about the message queued for
O S/application exam ination. Figure 3 provides a pictorial summary of this discussion fo r label
addressed block message transfers. Reference 1.2 .1 .5 ,1.2.3 .2 ,1 .2 .4 .3 and 4.2 fo r a
discussion of label addressing.
{cabc9abdde6c58957c9fd5b97e84d947.jpg}
1.2.1.4 Real-Tim e Programming Support: Special provisions were included in the Pi-Bus to support
real-tim e program m ing based on paradigms such as variations of the Rate M onotonic
algorithm and priority based algorithm s. The basic requirem ents fo r supporting such
paradigm s is the inclusion of message priorities and the ab ility to pre-em pt a lower priority
message by a higher priority message. The Pi-Bus includes message priorities and the ability
to suspend/resum e messages.
A message priority consists of two components: a 5 bit module ID (MID) and a 7 b it logical
priority. During a Vie sequence, the message priority is made up of the concatenation of the
logical priority and MID. The use of the MID allows for a determ inistic, unique selection of a
M aster during a Vie sequence. The logical priority alone is used fo r determ ining whether a
message should be allowed to be suspended. The logical priority is used by an application to
denote the im portance of a message. Typically, if the application softw are designates two
m essages in different modules as having the same logical priority, it considers them to have
the same priority regardless of what hardware module the software is on. In particular, if a
message is currently being transferred, it w ill not be suspended because another module with
a more urgent MID desires to transfer a message of the same logical priority.
There are tw o tim ers associated with a PIU used in the message suspension protocol. These
tim ers are softw are configurable. These tim ers are Vie Interval A R egister and Vie Interval B
R egister, which are 16 and 8 bit registers, respectively, expressed in bus cycles. The tim ers
are used to provide a maximum tim e bound, expressed in bus cycles fo r denoting when a
higher priority message may begin being transferred on the bus. The firs t tim er is used to
denote the am ount of tim e a Master may continue to send messages once a request has
been made fo r it to relinquish the bus due to another module wishing to send a higher priority
m essage. If the M aster has not completed sending a message (chain) by the tim e Vie
Interval A R egister expires, the Master must relinquish the bus by suspending the current
message by the tim e Vie Interval B Register expires or it w ill be aborted. Software configures
the Vie Interval A and Vie Interval B Registers appropriately to guarantee determ inistic
message deliveries of critical messages for its application.
1.2.1.5 Logical Slave Identifiers and Labels: W ithin a message a Slave is denoted by a slave
identifier (ID ). As depicted in Figure 4, the Slave IDs are of three types: 32 physical IDs
denoted by the MIDs, broadcast ID, and 223 logical IDs. The MID can be used to identify a
Slave fo r a message when there is a single Slave and the M aster knows the physical ID of the
Slave. The broadcast ID is used to send a message to all modules on a backplane. Logical
IDs are used to lo g ic a lly 11denote one or more Slaves for message transm ission. A PIU can
be configured dynam ically via either a bus interface message or via on-m odule software
commands to respond to any number of the 223 logical IDs. A M aster is not required to know
the physical address of a Slave module or how many modules w ith which it is com m unicating
if logical IDs are used. Logical IDs are suggested for ease of reconfiguring software. For
exam ple, if physical IDs were being used and an application which was originally allocated to
one m odule was moved to a different module, software w ithin the M aster would require
m odification to support this change. On the other hand, if logical IDs were used, no change
would be required in software.
Block M essages which use label addressing were included in AS4710 to extend the concept
of logical IDs to a greater number and to provide Slave controlled access to Slave memory.
(For a discussion of Block Messages, see 1.2.2.1.) A label extends the logical ID in the
follow ing way. Suppose a label block message is sent to a module, using either logical or
physical IDs. If the corresponding label in the Slave module is not activated, then the Slave
m odule ceases participation in the bus sequence - just as if the m odule was addressed by a
logical ID not activated for the module. If the corresponding label in the module is activated
(and not busy), the message transfer occurs.
{389aa74d7cd75d9916a5de9de3d0b272.jpg}
The use of labels allows the Slave to designate the physical address in Slave memory to
either read or w rite the message. Therefore, changes in Slave memory allocation do not
affect softw are executing in a Master, since the M aster is not required to know the physical
address. In addition, if direct memory addressed messages are not used, this allow s a Slave
to protect its memory from arbitrary access from off module. M ost current PIU
im plem entations allow direct memory addressed messages to be disabled.
1.2.1.6 C entralized and D istributed Initialization: AS4710 defines the Pi-Bus data link registers.
These registers specify configuration param eters for a PIU. For exam ple, the Vie Interval A
and B tim ers and logical IDs registered fo r a module are defined in the data link register set.
The bus interface message allows a centralized approach to Pi-Bus initialization. This is
accom plished by allow ing a single module w ithin a backplane to initialize the data link
registers fo r all modules w ithin the backplane by using bus interface messages. A
decentralized approach is also allowed by having a module initialize its data link registers by
sending a bus interface message to itse lf or by providing a device-side interface to the data
lin k registers. It is generally fe lt that distributed initialization is preferred fo r modules which
are capable of M aster/Slave operation (and thus typically have a processor on the m odule),
w hile centralized control should only be used for initializing modules w ith Slave only
capabilities (and thus typically do not have a processor on the m odule). Allowing distributed
initialization fo r M aster/Slave capable modules avoids potential synchronization problem s,
avoids problem s due to the loss of the control module, and allows initialization to occur in
parallel.
1.2.1.7 Security Support: Most PIU im plem entations contain several features which support data
security.
As noted in 1.2.1.5, label block messages allow a module to restrict access to its memory. It
is suggested that except fo r possibly accessing Slave only m odules, direct addressed block
messages not be used. Most PIU im plem entations provide the capability to disable the
acceptance of direct addressed block messages, preventing application software from either
accidentally or m aliciously accessing a m odule's memory directly.
In m ost current im plem entations, a label table entry includes an entry which states the
maximum buffer size allowed for a message sent/received from that label. In addition, the
maximum label allowed and maximum event label allowed may be specified to further reduce
the access to a Slave module. These features help lim it external access to a m odule's
memory.
The block message and datagram message are allowed to have an extended header -six
additional 16-bit words of application dependent inform ation that is passed with the message.
This inform ation could contain inform ation which could be used to support security.
1.2.1.8 Sim plified Software Interface: An im portant feature supported by current PIUs is the device-
side interface sim plifies the software interface to the Pi-Bus. These features include data
structures used for transm itting messages and receiving messages, a robust error reporting
interface, and the decoupling of the Pi-Bus and software in the sense that a PIU requires little
interaction w ith software to perform message transactions. Section 1.2.3 discusses several of
the key software interface features provided in most PIU im plem entations.
1.2.2 Message Passing Features: The Pi-Bus supports several types of m essages. These include:
a. Block Messages, including both direct and label addressing
b. Param eter W rite, including both logical and event filte r
c. Bus Interface, including both data link register access and system tim er
d. Datagram Messages, including logical addressing only
In addition, Block Messages and Datagram Messages support transfers using either short or
extended headers. This section provides a synopsis on the use of these message types.
1.2.2.1 Block Messages: A block message may transfer between 1 and 65 536 contiguous words of
physical memory. (The word size is 16-bits for a 16-bit Pi-Bus and 32-bits for a 32-bit Pi-
Bus.) A block message may be either a read or a w rite. A read w ill transfer data from a
Slave to the Master. A w rite w ill transfer data from the M aster to one or more Slaves. Due to
the potential size of block messages, block messages are suspendable as noted in 1.2.1.4.
However, a module may be configured to not allow the suspension of block messages. If a
m odule is configured not to support the suspension of block m essages then a message
w hich would have been otherwise suspended during a suspend sequence would be aborted
at the expiration of the appropriate Vie Interval B Register.
Two modes of addressing are aiiowed in block messages: direct addressing and label
addressing. D irect addressing is interpreted by the PIU on the Slave m odule. Some PIUs
address a m odule's memory as though the address were a physical address, while others
address a m odule's memory as though it were a logical address. Sending block messages
using direct addressing is not generally suggested fo r com m unicating w ith other modules
containing a data processor as discussed in 1.2.1.5.
Label addressing, as discussed in 1.3.1.5 supports logical addressing of a slave module.
This is the generally accepted addressing approach suggested fo r block messages.
1.2.2.2 Param eter W rite Messages: The typical Pi-Bus message sequence includes a header
sequence follow ed by a data sequence. The header sequence is used to identify the
S lave(s), identify the type of message to be sent, and to com m unicate message type specific
inform ation (if there is any), such as label for block label messages and datagram m essages,
to the Slave(s). If there is data associated with the message the data is then transferred
during the data sequence. The Parameter W rite message is an optim ized message in the
sense that the entire message is transferred during the header sequence, i.e., all data
associated with the message is included in the message header.
There are two types of param eter w rite messages: logical and event filte r. The logical
param eter w rite message allows for the transfer of three 16-bit words to a Slave. Upon
reception by a Slave, the message header, which includes the three data words, is queued for
access by the Slave processor. In order for application software to make use of the data, a
subset of the data m ust contain inform ation used by application code to denote what the data
is and possibly who it is for. In contrast, the label used in a block message using label
addressing can be used to denote this inform ation.
The event filte r param eter w rite message provides an efficient mechanism for the signaling of
the occurrence of up to 16 events. This can be used to im plem ent synchronization prim itives
such as the signal of a barrier. An overview of the event filte r param eter w rite is presented in
Figure 5. An event filte r param eter w rite message contains (1) a label which denotes one of a
possible 4096 different event labels and (2) event flags which denote between 1 and 16
events. There is an event label table on a Slave module indexed by the label contained in the
event filte r param eter w rite messages. Each event label table entry contains a 16-bit event
mask which denotes the event set associated w ith the label. Each event label table entry also
contains a 16-bit event flags word which is OR'ed with the event flags entry of a param eter
w rite message using a label associated w ith the label table entry. The event flag word shows
how many different events w ithin the event set have occurred. When all the events as
defined by the event mask have occurred, the Slave is signaled. This signaling occurs by
queuing an event report which contains among other things the label associated with the
event and interrupting the Slave processor.
{6f744c2e510fd8b6b23deecdbb4d744d.jpg}
The event filte r param eter w rite message elim inates the need for the processor to be
interrupted more than once and software processing required to denote the occurrence of a
set of events. If an event set contained N events and the event filte r mechanism was not
used, then at least N interrupts (and more if some events were repeated before the entire set
of events had occurred) would be required along with software processing to determ ine the
entire event set had occurred.
1.2.2.3 Bus Interface Messages: There are two types of Bus Interface M essages: data link register
access and system tim e distribution. The Bus Interface Message which accesses the data
link register space of a Slave is used to either read or w rite a Slave's data link register space.
This was discussed in 1.2.1.6.
The Bus Interface Message used for system tim e distribution is used fo r transferring the
system tim e value w ithin one PIU to another. This was discussed in 1.2.1.2.
1.2.2.4 Datagram M essages: There are two types of datagram m essages: nonacknowledged
datagram and acknowledged datagram . Nonacknowledged m essages are intended fo r a
send and forget type system where no message acknowledgm ent from the slave(s) is
needed. Acknowledge datagram messages are used in place of block messages when
header acknowledge inform ation is not needed, but a data acknowledge is. All datagram
m essages are m ulticast.
Both datagram messages provide higher potential throughput than block messages.
Because the header acknowledge has been removed, selected slaves can begin buffering
data w hile processing the label inform ation. If any label problem s are detected, the slave
disconnects from the message and flushes it's data buffer. If all label checks pass, then
m em ory transfer from the slave data buffer to the module memory can begin. Because the
label checks can be done in parallel with the Pi-Bus data transfer, datagram s can have a
m uch higher throughput than block messages. The amount of throughput im provem ent is
greatly dependent on PIU design. The slave must have a data buffer large enough to hold all
of the Pi-Bus data that comes into the slave, while the label checks are being perform ed. It is
desirable to have a Slave DMA throughput that is greater than the Pi-Bus data rate.
1.2.2.5 Short and Extended Headers: Messages are typically sent using short headers. However,
block and datagram messages may also be sent using extended headers. The extended
headers contain a short header plus an additional six 16-bit words which are application
dependent. One use of extended headers is to pass operating system specific inform ation
related to the message w ithout requiring a second message transfer. For exam ple, if a
message dealt w ith file I/O , the extended header could include specific inform ation about the
file operation in the same message which transfers file data.
1.2.3 Softw are Interface: One of the key characteristics of all current PIU im plem entations is they all
provide sim plified software interfaces for Pi-Bus transfers and PIU control. This section gives
exam ples of the types of software interface features included in existing im plem entations. The
features discussed are categorized into Master and Slave interfaces. Figure 6 depicts the two
m ost significant data structures used by software to com m unicate w ith a PIU. The details given
are typical of several interfaces.
{43d82f55f99609cdff219ac6876c7939.jpg}
1.2.3.1 M aster Software Interfaces:
1.2.3.1.1 Chain C ontrol Blocks: The basic structure used for controlling a PIU as a M aster is the
chain control block (CCB). (Reference Figure 6). The typical CCB denotes a Pi-Bus
message to be sent by this module. CCBs may be chained together to allow m ultiple CCBs
to be invoked by a single command from a processor. CCBs in a chain are executed
sequentially. As w ill be noted below, in the typical im plem entation the separate CCBs in a
CCB chain are not required to be contiguous in memory.
In several im plem entations, two types of CCB chains may be invoked sim ultaneously:
norm al chains and priority chains. Typically, a normal chain is commanded to a PIU.
However, if software determ ines it needs to transm it higher priority messages while a
norm al chain is executing, a priority chain may be invoked which w ill suspend the current
chain so that the priority chain can be processed.
A processor may also command the PIU to abort a chain that is currently executing .
A CCB contains control flags used fo r specifying actions to be perform ed. Some of these
actions include whether the CCB is a NOP (no operation is to be taken fo r the CCB),
w hether the CCB is the last in the chain (in which case an end of chain report w ill be posted
and the M aster processor interrupted), and whether the CCB is a jum p CCB (in which case
the CCB denotes the location of the next CCB to execute). A jum p CCB allow s the CCBs
com prising a CCB chain not to be contiguous. If the CCB control flags do not designate the
CCB as a NOP or jum p CCB, the CCB contains the message headers for a Pi-Bus
m essage to transfer and if appropriate a location in memory fo r reading the data fo r
m essage w rites or fo r w riting the data for message reads.
1.2.3.1.2 M aster Interrupt Interface: For typical im plem entations, an interrupt is generated to a Pi-
Bus M aster due to the com pletion of a CCB chain, the com pletion of a CCB "m arked" to
cause an interrupt on com pletion, and the occurrence of an error.
The typical im plem entation also includes a data structure or set o f data structures which
contains inform ation used by software on a Master. Examples of this inform ation include:
a. Inform ation on the CCB that was last executing, such as the CCB address, received
header acknowledge words and received data acknowledge words (where appropriate).
b. For interrupts generated due to errors, inform ation is provided describing the errors.
c. Inform ation on the status of the message such as the Pi-Bus message type, w hether the
message was a m ulticast, whether the message was a w rite, if the header acknowledge
words are valid, if the data acknowledge words are valid, w hether there was a no
response error (i.e., no Slaves responded), and whether any M aster Pi-Bus errors were
detected.
There is typically a PIU register which is accessed upon the occurrence of an interrupt to
allow softw are to determ ine the cause of the interrupt.
1.2.3.2 Slave Software Interfaces:
1.2.3.2.1 Label Table: The basic data structure used fo r Slave processing is the block message label
table (reference Figure 6) and the event filte r label table (reference Figure 5.) These tables
define the Slave interface to label addressed block messages and event filte r param eter
w rite m essages, respectively.
1.2.3.2.1.1 Block Message Label Table: Label block messages provide the m ost robust type of Pi-
Bus m essage. Not only does the label logically denote the address where to read/w rite
the message but it is also used as an index into a table whose entries allow various
paradigm s to be used on a Slave for controlling block messages addressed to that label.
For exam ple in some im plem entations, a label entry can denote w hether double buffering
or single buffering is to be used and whether an interrupt should be generated after the
m essage is received.
AS4710 allows fo r 64K labels. Typical im plem entations restrict the number of labels. A
label table is contiguous in Slave memory and the maximum num ber of labels is software
configurable. In some im plem entations there is also a minimum label designator. If a
label addressed message, whose label is greater than the maximum label size allowed by
a module, is attem pted, the Slave module w ill not participate in the message transfer.
The use of the maximum (and minimum) label designator(s) allow s fo r conservation of
memory since a label table of only the size bounded by these designators is needed.
For several im plem entations, a label table entry contains a set of control flags, buffer
addresses, and a maximum label buffer size allowed. The control flags are typically used
to denote if a label is enabled, if a label is busy, to denote the buffer to be accessed (if
the im plem entation supports m ultiple buffers per label), denote the suspend status of a
label (i.e., whether a message that was being sent to the label is currently suspended),
and to denote whether an interrupt is to occur upon com pletion of a transfer to the label.
The maximum label buffer size is used to ensure that the label addressed message does
not read/write more data than the Slave intends. If a label addressed message attem pts
to read/write more data than the maximum label buffer size fo r the Slave's module label,
the module w ill not participate in the transfer.
For some im plem entations, there is a single Test & Set Register associated with the PIU
used as a semaphore fo r shared memory access to the label table. This is required since
the Pi-Bus and software may be attem pting to access label table entries sim ultaneously.
1.2.3.2.1.2 Event Filter Label Table: The event filte r label table is discussed in 1.2.2.2.
1.2.3.2.2 Slave Interrupt Interface: Interrupts can be generated to a Pi-Bus Slave for several
reasons; for exam ple, due to the occurrence of an error, due to the Slave Receive List
(SRL) being fu ll, and due to receiving a message which indicates that the processor should
be notified.
An SRL entry contains inform ation regarding a received message. This inform ation typically
includes the header words received, the transm itted header acknowledge word 0 and data
acknowledge word 0, the bus priority during the message transfer, Slave detected Pi-Bus
errors, and a code stating the reason for the SRL entry and the validity of the stored header
words and acknowledge words.
Upon the occurrence of an interrupt, the processor looks at a PIU interrupt cause register(s)
to determ ine if the interrupt was due to an SRL entry being posted, SRL being fu ll, or some
other reason.
1.2.3.2.3 C ontrol/C onfiguration Registers: In order to allow a module to configure itself to accept only
the types of messages desired by an application, the typical PIU contains a Slave
configuration register(s). This register denotes whether a Slave w ill accept direct addressed
block message reads, direct addressed block message w rites, label addressed block
message reads, label addressed block message w rites, param eter w rite event filte r, and
param eter w rite logical. In addition, it also allows the Slave to denote whether it supports
suspension of message reads or suspension of message w rites.
A typical use of this register would be to disallow direct memory block message access to a
m odule fo r reasons as discussed in 1.3.1.5.
1.2.4 Program m ing Paradigm s: There are many programming paradigms which the Pi-Bus supports.
This section discusses several of these.
1.2.4.1 Push/Pull Paradigm s: Since Pi-Bus block messages can either read data from a Slave or
W rite data to a Slave, both push and pull mechanisms can be efficiently supported. A push
m echanism is a protocol in which the creator of the data "pushes", i.e ., sends, the data to
users of the data. In contrast a pull mechanism is a protocol in which the users of the data
"pull", i.e ., retrieve, the data only when they want to use it. A pull protocol can be implem ented
w ith Pi-Bus reads. A pull protocol can also be implemented with the user sending a request
message to the creator of the data, follow ed by the creator sending the requested data. The
second pull approach requires more Pi-Bus tra ffic than the firs t approach.
1.2.4.2 D irect Memory Addressing: The Pi-Bus allows direct addressed block messages. As noted
in 1.2.1.5 and 1.2.1.7, direct memory addressing is not considered a safe mechanism for
accessing Slave memory. Therefore, modules should have the capability to disallow their
reception as a Slave of direct addressed block messages. However, a system can use direct
addressed block m essages to treat the memory w ithin modules resident on a backplane as a
global memory space. In this case, a global memory address would consist of a two part
address in the form (M ID, module local address), where MID denotes the module ID of the
m odule in which the memory being addressed is resident.
NOTE: Logical IDs could be used in place of MIDs if appropriate logical ID assignm ents to
m odules were made.)
One common use of direct addressing is to use it during startup fo r downloading, reading
health results, etc. and then having modules disable direct addressing during normal
operation.
1.2.4.3 Label Addressing: As noted in the discussion of block label messages in 1.2.1.5 and
1.2.3.2.1.1 label addressing allows
a. Logical addressing - the Master does not need to know the num ber or the physical
address (i.e., either the module IDs or physical memory address) of the Slaves.
b. The Slave can control access to its memory if label addressing is used.
c. Single buffering or double buffering schemes as well as circular queues can be used.
d. Label block messages can either cause or not cause an interrupt at the Slave on arrival -
thus, blocking, polling, and application defined synchronous schemes (e.g., tim e based)
are supported.
W hen label addressing is used, the application software must have some means to associate
the m essage with the appropriate application. One paradigm is to use the label to denote
w hat the message is or who the destination of the message is. Another paradigm (which may
be com bined with the previous one) is to embed data w ithin the message to provide the
desired inform ation.
The event filte r also uses (event) labels. As noted in 1.2.2.2, the event filte r allows an
e fficie nt im plem entation of a barrier protocol. If it is desired that a Slave should be signaled
on the occurrence of n different events occurring (at least once), the event filte r im plem ents
this in hardware. This reduces the number of processor interrupts and software processing to
im plem ent a barrier synchronization protocol.
1.2.4.4 M ulticast: M ulticast can be efficiently used for sending the same message to m ultiple Slaves.
M ulticasts messages are acknowledged messages fo r all but unacknowledged datagram s. A
typical use of m ulticast messages are periodic health messages exchanged between modules
w ithin a backplane. Care must be taken when considering the use of m ulticast since the
softw are protocol required for error recovery can be com plicated when a subset of the Slaves
successfully received a transfer.
1.2.4.5 Logical Versus Physical Memory: Some PIUs treat module memory as physical memory -
they do not view memory logically as the processor does. This is common for system s in
which caches are used. If data to be transferred is to originate or end up in cached memory,
the follow ing types of protocols must be considered:
a. On sending, the data must either be copied to non-cached memory or (if w rite through
caches are not being used) flushed into physical memory.
b. On reception, the data must be copied from the incom ing buffer to its final memory
destination or the cache must be invalidated (w ithout flushing to physical memory) prior to
the use of the data.
A typical protocol used in such systems is (1) copy data to be sent into an OS buffer prior to
transfer and (2) after the transfer com pletes, copy data from an OS buffer which received the
data into an application buffer.
if cached memory is not being used or if all I/O is accessed in non-cached memory, then this
discussion can be ignored.
1.2.4.6 E xtensibility: The Pi-Bus allow s up to 32 modules on the same backplane. Often system s
are designed w ith additional slots for growth m odules. The use of logical IDs and labels
allow s fo r additional m odules (and software) to be added possibly w ithout affecting softw are
in existing m odules. The point being made here is if logical IDs and labels are used, software
can be reconfigured to execute on different modules w ithout m odifications to softw are.
Serious consideration should be given to using logical IDs and labels when designing a
system .
1.2.4.7 C onsistent M ission Tim e: As noted in 1.2.1.2, the Pi-Bus provides hardware support fo r
consistent system tim e distribution w ithin the backplane.
1.2.4.8 A pplication Access Versus OS Access to the PIU: One of the m ajor issues to consider when
designing the software fo r a system using Pi-Bus is what access is going to be allowed to a
PIU.
A common approach is to assume that an operating system (OS) exists between the
application softw are and the Pi-Bus. From the application program m ers interface point of
view , he is not aware of the type of bus being used. Only the OS directly interfaces w ith the
PIU. The OS accepts requests to send and receive messages from the application.
A pplications typically pass the data or a pointer to the data to the OS fo r send operations.
The OS takes care of building CCBs and handles the CCB com plete interrupt, unblocking the
caller, if the send was a blocking operation. Typically for receive operations, a received
m essage generates an interrupt which is handled by the OS. The OS either passes back a
pointer to an OS allocated buffer containing the data or returns the data into a buffer allocated
by the applications.
O ther approaches provide a m ixture of using an OS and allowing applications some
knowledge of the PIU. The follow ing are two alternatives to consider but note the OS
alw ays handles direct interactions with the PIU, i.e., fields all PIU interrupts and initiates all
com m ands to the PIU.
a. For send processing, the applications build CCB chains and passes them to the OS fo r
sending.
b. For receiving m essages, the applications interact directly with the label table. It is up to
the application to change label table entries - not the OS. If an interrupt is generated due
to the arrival of a message, the OS sim ply passes the label and message size (and
maybe the rem ainder of the message report) to the application.
1.2.5 Sum m ary: This section discussed the use of a Pi-Bus from the software/program m er's point-of-
view . The Pi-Bus and Pi-Bus controllers provide a very robust interm odule com m unication bus
which supports fa u lt tolerance, provides a backplane m ission tim e distribution source, provides
optim ized message passing, supports modern day real-tim e program m ing techniques, includes
logical slave identifiers and labels, supports either centralized or distributed initialization,
includes data security supportive features, and provide an sim plified software interface.
1.3 Pi-Bus O peration Overview:
This sections provides an overview of Pi-Bus message control and a typical im plem entation's
data flow .
1.3.1 Pi-Bus Message Control: Once a module obtains control of the bus, it becomes the bus M aster
and starts its bus tenure. The Master sources the Cycle Type signals of the Pi-Bus as shown in
Figure 7. The state machine in the Master drives these signals. The message proceeds
through the follow ing states:
a. HO (Header 0 W ord)
b. H (O ther Header W ords)
c. A (Header Acknowledge, if required by the message)
d. D (D ata, if required by the message)
e. A (Data Acknowledge, if required by the message).
The Slave(s) synchronizes its own state machine with the HO cycle of the Pi-Bus. It then
checks the sequence of the Cycle Type signals to verify that the message is proceeding
correctly.
Both the M aster and Slave can source data for the Data signals. The M aster starts by placing
the header words on the Data signals. This specifies the follow ing:
a. Participating Slave(s)
b. Message Type
c. D irection of Data Transfer
d. Data B uffer
e. Am ount of Data to be Transferred
The Slave responds to the header by asserting the Header Acknowledge(s) on the Data
signals. This provides error data and participating Slave identification to the M aster. The
M aster w ill abort the message if the header and header acknowledge portion of the message
do not com plete correctly. The header acknowledge is follow ed by the M aster (for a transm it
m essage) or the Slave (for a receive message) asserting data on the Data signals.
The Slave sources the Acknowledge Set signals. These lines are used to inform the M aster of
the Slave's participation in the message. The follow ing can be indicated:
a. NS (N ot Selected)
b. RCG (Recognized)
c. ACK (Acknowledge)
d. NAK (Negative Acknowledge)
The M aster m onitors these signals to insure that they follow the proper protocol.
Either the M aster or Slave can source the W ait signals. These signals are used to insert
N on-Transfer (NT) cycles on the Pi-Bus. The cycle after the assertion of the W ait is the NT
cycle. The delayed effect is required because of the pipeline type design of the Pi-Bus. This
NT cycle technique is used to cause a pause in the message to perm it the Master or Slave tim e
to perform tasks such as:
a. Fetch or Store Data
b. Check Label Tables
c. Allow checking fo r Aborts after the End of a Message
d. Store Interrupt Reports
e. Updating Label Tables
f. C alculation of Resume Control W ords
g. Fetching the Next Bus Message Control Block.
The proper use of the W ait signals is one of the most d ifficu lt tasks in the im plem entation of a
BIU. This subject w ill be covered in detail later.
The Bus Request lines can be sourced by any M aster/Slave module. It is used to indicate that
a m odule has a message to transm it which has a priority which is higher than the current bus
priority. The M aster must follow the specified rules concerning suspending and aborting to
relinquish M astership of the bus.
{42f74c8a319c7462b27d5083716e707a.jpg}
1.3.2 Pi-Bus Im plem entation: A typical im plem entation of the data flow for a BIU is shown in
Figure 8. The basic principal is that all data, control and redundancy bits are loaded into an
O utput Register to be asserted onto the Pi-Bus for a com plete cycle. They are asserted onto
the Pi-Bus during the same cycle that they are in the O utput Register. The signals are received
into an Input Register at the end of the bus cycle. Once the data and controls are loaded in the
Input Register, they are checked and decoded during the next cycle. Data is then transferred to
a final destination or End Register.
{5388d0fabd625f9359f072718a713977.jpg}
The im plem entation of a synchronous data flow such as this resem bles a pipeline as shown in
Figure 9. This shows that a Slave destination register is loaded w ith data which was selected
three cycles earlier by the Master Output Mux.
{6bdd5c9f28504dba868cc9535181b545.jpg}
The "pipeline" concept helps explain the Pi-Bus requirem ent of having a Slave assert NAK on
the bus two cycles after an error is detected. The follow ing sequence illustrates why asserting
NAK in two cycles follow ing an error is as fast as it can be accom plished in the natural flow of
the protocol:
Cycle 1 Error occurs on a signal bus of the Pi-Bus
Cycle 2 Slave latches bus signals in the Input Register, detects the error and form s a NAK.
Cycle 3 Slave loads the NAK into the O utput Register and asserts it on the Pi-BusstrRefField
|