Minutes of the P1996 HiRelPCI working group

[ShawnM2298@aol.com]

Here are my minutes of the last meeting
Please let me know if anything was omitted.

Jan. 29 1997 Meeting of HiRelPCI (IEEE P1996 Working Group)

* Review HiRelPCI for new comers.

* Review changes from last meeting.

** Discussion of "board profiles"
	A brief discussion of the four "profiles" was provided.
	The four profiles are:
	
	6SU 32bit with I/O : This profile uses a 32 bit PCI bus and allows
		the upper address and control lines to be used as I/O
		pins.  These boards can NOT be inserted into a 6SU 64 bit
		backplane slot, as they may damage other equipment.
		A Key mechanism for the board and backplane will be defined
		to ensure that only appropriate boards may be inserted in
		the slot.

	6SU 64 bit :  This profile uses the entire 64 bit address/data
		path of HRPCI.  This board may be inserted into a 
		6SU 32bit slot, provided that the slot does not have
		any signals connected to the high address/data and control
		lines.  The board and backplane shall be keyed to preclude
		insertion of this profile board into a 32 bit slot with 
		active I/O lines.
		
	12SU 64 bit with I/O: This profile uses the upper bus as a full 
		64 bit HRPCI bus (same as 6SU 64 bit pinout).  The lower
		connector provides addtional power and I/O pins.  This
		board may NOT be inserted into a 12 SU dual 64 bit slot.
		Board and backplane keying shall ensure that this will not
		occur.
		
	12SU dual 64 bit: This profile implements dual independant 64 bit
		HRPCI interfaces.  This board MAY be inserted into a 12 SU
		64 bit with I/O slot, provided that no I/O is connected on
		the lower bus (pins floating).  Keying options are provided
		that will ensure that a slot may be keyed to indicate active
		I/O is present, and will preclude the insertion of this 
		profile into an active I/O slot.
		
** Discussion of maintenance bus.
  Purpose: Provide a low cost mechanism to perform necessary board 
	startup and configuration and shutdown. 

    	A board being inserted into a running system should not impact the
    	main bus in order to perform basic configuration.  It also
	can not become active on the main bus until it is configured.
	The maintenance bus provides a low cost method of configuring
	newly inserted boards.  It is not the only method of performing
	configuration, but provides an alternate path.

	It also provides an alternate path to cause the shutdown of
	a board that is not operating properly, one which might be 
	causing main bus failures.

	The maintenance bus is based on the 1149.5 standard, and may
	support the ability to perform JTAG testing of the board prior
	to making the board operational on the bus.

	ISSUE: Should all CSR's be accessible via the maintenance bus?
	This might put significant, unnecessary cost into the boards in
	order to support two different data access paths to CSR's.
	This might best be left to the board designers and system 
	integrators to settle.  The maintenance bus shall provide a
	defined method of accessing on board resources, but this 
	capability may not be required.

	There was significant discussion concerning the use of the 
	maintenance bus to perform more significant debug and test
	operations than the 1149.5 implementation would support.  It
	was agreed that those systems that require this support, can
	utilize the 1394 serial bus (also part of the standard) to
	obtain those services that require more bandwidth than the 
	maintenance bus would provide.  It was agreed to keep the
	maintenance bus as simple as possible.

	ISSUE #2: Protocol - There was a desire to have the additional
	maintenance bus protocol be consistent with 1394 (or 1394.2) in
	order to simplify the software and bridging issues.  With a 
	common protocol, the only issue is one of routing (i.e. which
	bus does the message get passed on).  An the work of reformatting
	messages is eliminated, or greatly reduced.
	ACTION: The committee will make every effort to keep as consistent
	with the other serial protocols as possible.  It was agreed that
	this is a highly desirable goal.

** Discussion of Priority arbitration

	The 0.51 draft of P1996 has allocated four signals as arbitration
	priority signals.  Work is still being done to determine how these
	signals will be used.  The goal was to provide at least 16 levels
	of priority requests in order to support rate monotonic system 
	scheduling algorithms.  However to date there is not any known 
	(to this group) proof, or systems that utilize such a method.
	Those requesting this feature, actually want 256 levels, but 
	the limited number of pins does not allow this (unless user I/O
	signals are used). 
	It is also unclear that this prioritized bus requesting mechanism
	would operate as anticipated due to the problem of "priority inversion"
	problems.  It is possible for a high priority requestor to be blocked
	from performing it's task due to a resource that is owned by a lower
	priority task, running on a different board.  The lower priority
	task may never gain access to the bus, if sufficient high priority
	requests are pending, or it may gain access to late to allow the 
	blocked higher priority task to meet it's deadline.
	It may actually be better to continue to use the "round robin" method
	of performing arbitration, and factor in the worst case latency into
	the rate monotonic scheduling.
	However, the pins will remain defined as priority signals, but the
	method of operation for these signals still needs to be completed.

	The issue here is how are existing bus requests removed, when they
	see that higher priority requests are pending?  What is the priority
	encoding, and removal process that will deal with the fact that these
	signals are wire OR'ed.  The problem here is that a priority 1 request
	and a priority 2 request will look like a priority 3 request! How
	are the requests removed in order to guarantee that the highest
	priority requestor does not release it's request because it believes
	that a higher priority request exists.  This will require some
	incremental removal policy that adds time to the arbitration decision
	time.  Will this time exceed the "overlap" time that the PCI bus
	implements currently?  Is this mechanism throwing more effort at 
	something with minimal rewards?

 ** PCI interrupt support
	The 0.51 draft removed the PCI INTA, INTB, INTC and INTD signals from
	the bus, and reused these for the priority arbitration mechanism
	above.
	The argument for this was that systems would exist that had I/O
	controllers only, and no main processor to field interrupts.  
	Therefore, "interrupt" messages should be used to indicate the need
	for service, since these messages can be easily bridged.  Making
	the interrupt support more efficient, and consistent whether the
	servicing processor is local or remote.
	The argument against removing all interrupt support is that it 
	precludes the use of many existing PCI I/O chips that do not 
	provide the processing power needed to handle messaging.  One of
	the goals was to allow for lower cost I/O to be supported, perhaps
	not with the same level of performance, or fault tolerance as 
	the more sophisticated approach.  These "simple" I/O boards would
	need a processor on the local bus to either service the interrupt
	directly, or create the interrupt message on behalf of the device.
	DECISION: The group concensus was to provide an interrupt signal
	for each slot, to allow backward compatibility.  There is only
	a single interrupt line, but this is easily handled on a board with
	an OR gate.  It was also noted that most PCI chips only provide a
	single interrupt output anyway.  One of the remaining reserved pins
	was allocated for the INT function.

 * Discussion of next meeting time and place:

	Due to the short time between this meeting and the planned Feb. 13
	meeting, and the existing workload of both the chair and editor,
	The Feb. meeting has been cancelled.

	The next meeting of the P1996 working group will be March 26 1997
	from 9:00 AM till 1:00 PM in Room 325 of the engineering building
	at Santa Clara University.  This meeting will be in conjunction
	with other SCIzzle meetings.

Yˆw