P1996 HRPCI Minutes from 12/10/96 Meeting

[ShawnM2298@aol.com]

HRPCI Meeting  12/10/96

Discussion of "standard" options:
  The need to support a variety of configurations, some geared toward
bandwidth and
multiprocessing, others geared toward I/O configurations is needed.  The
group 
decided that several "profiles" will be defined to accomodate the different
needs.
Such profiles should provide as much interchangability between profiles as
possible by
allowing boards from one profile to be used in another provided such use
would not cause
damage to devices or equipment.

1) Options: By Board size
	6SU
		HRPCI 64 (keyed)
                               Preferred: Uses 64 bit address/data bus.  Key
shall allow this 
                                   board to fit in an HRPCI 32 slot (as long
as User I/O is not keyed
                                   to indicate damage would occur)  Allows
HRPCI 64 boards to be
                                   used in applications that only need 32 bit
address/data transfer
                                   capabilities.  HRPCI 32 boards will NOT
plug into an HRPCI 64
                                   slot.
                            HRPCI 32 with addtional User I/O (keyed)
                                   This profile uses only 32 bit address/data
transfers.  HRPCI 64 
                                   boards will operate correctly in 32 bit
mode, but with reduced 
                                   bandwidth.  Pins normally used to support
64 bit mode are now
                                   defined as User I/O.  Systems that have
slots dedicated to user
                                   I/O functions on these pins shall key the
slot such that an HRPCI
                                   64 board will NOT fit, particularly if I/O
would damage the board 
                                   or the I/O due to a mismatch.  This
profile is geared for lower
                                   lower bandwidth, high I/O applications
that need to fit within a
                                   6 SU space.

	12SU
		Redundant (Could plug in User I/O slot - key option to preclude)
                                  This profile uses redundant HRPCI 64
busses.  These boards
                                  may be capable of plugging into 12SU User
I/O slots, as long as
                                  the slot is not keyed to prohibit redundant
boards.
                                  Two 6SU HRPCI 64 boards may be plugged into
a single 12SU
                                  redundant bus (one above the other).  This
capability requires the
                                  use of a 6SU to 12SU adapter that provides
mechanical support
                                  for the dual boards.
		User I/O ( Can not plug in Redundant slot )
                                  This profile provides additional user
defined I/O signals.  The
                                   User I/O slots may be keyed to prohibit
the insertion of a 
                                   redundant HRPCI board in the event that
damage might occur
                                   to such a board when placed in the slot.
 12SU User I/O boards
                                   shall not be capable of plugging into a
redundant HRPCI slot.

2) MTM bus:
   Discussed performance issues of the MTM bus and how to allow for different
performance to be available over time.  Decision to dedicate a clock for the
MTM
rather than rely on another clock signal (such as 10 MHz reference clock).
Goal to support 10 Kbit/sec operation as a minimum.  Faster operation should
not be
precluded, but would require system design to dictate.
	Add separate CLK for MTM bus ( Use CLKRUN# signal ) -- eliminate the 
  current CLKRUN# signal and use it for the MTM bus.  The MTM bus may then be
used
  to implement the function previously defined for the CLKRUN# signal, namely
startup and
  shutdown of slot functions.
	Implies system must have MTM bus to stop the clock.

3) Interrupt Lines
	Remove from spec (optional in PCI)  Use Special Cycles instead.  Discussion
  revolved around the fact that INTA, INTB, INTC and INTD are "optional" in
the PCI   specification, and that they are not well defined for use in a
multiprocessing environment.
  Tenative decision to remove these signals from the bus, and utilize
directed interrupts
  (via extension packets, or special cycles).  There is some concern about
how this might
  impact boards designed using existing PCI chips.  It was felt that only a
small amount of
  external logic would be required to convert the interrupt signals into
alternate interrupt
  mechanisms was necessary.  This area needs more work to ensure a
compatibility 
  problem will not happen.

4) Add Request Priority (use interrupt lines)
	Bussed or per slot ? (Goal: Support Both)
   There is a desire to have some "priority" information conveyed with bus
requests.
   This is particularly useful for systems that are real time and rely on
rate monotonic
   scheduling to provide deterministic response times.  The decision of
whether the 
   priority signals were bussed (which would not indicate which requestor was
the priority 
   one unless lower priority requestors dropped their requests) or if all
priority signals came
   back to the CSM, which would then allocate the bus to the highest priority
requestor.
   This would add a lot of pins to the CSM!
   This area needs more work, and represents a departure from standard PCI.

5) Open Issues:
      These issues were raised, but time did not permit a full discussion of
them at the 
  last meeting.
	Backplane ID Device (only on CSM) - A capability for providing serial number
and
                  backplane type information that is tied to the backplane
itself should be 
                  provided.  It is acceptable if only the CSM(s) are capable
of reading this
                  information, since they can provide it to other boards on
the bus.

	MTM Addressing (shift up to allow sub busses per board) - A decision on how
                  to define the MTM bus addressing needs to be made.  If
higher order bits 
                  are used then the ability to have "sub busses" on a module
is possible.
                  In general it was felt that this is a good goal, the actual
addressing still
                  needs to be defined and completed.

	Transaction codes for packet bus.
                  The transaction codes for the new PCI packet transfer need
to be defined.
                  The goal is to allow the serial express and SCI codes to be
used, or at
                  least all the functions supported.  While some SCI
functions will be 
                  optional, we do not want to preclude them.
ž<*