No subject

Jim McGrath Jim.McGrath at quantum.com
Wed Sep 9 20:20:28 PDT 1998


* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
* Jim McGrath <Jim.McGrath at quantum.com>
*

Two weeks ago Thursday I had a 90 minute con call with representatives from
other companies in T10 (including IBM, WD, Seagate, QLogic, Symbios,
Adaptec, Compaq) to discuss the status of the CRC/Double Transition document
(98-177), with the aim of approving it for inclusion in SPI-3 at this
September's meeting (i.e. next week).  The focus was on identifying issues
that needed closure.  I would like to drive to some closure at that meeting.

When this item comes up I am suggesting that a straightforward process of
identifying the issues, stating the possible options, limited debate (since
many of these options have been debated before), and the a vote on the
options with the aim of driving the issue to closure.  If the group is
divided, then if necessary we should discuss it at the plenary, but I hope
that we will get some significant support for a single position on each
issue.  To facilitate this I asked the group on the con call to identify the
outstanding issues, with the promise that I would turn the document one more
time to provide appropriate wording for the alternatives mentioned.  In that
way, we will not have to waste time wording on an exact wording change at
the meeting, but rather will have "pre packaged" wording from the author for
the various positions, allowing the committee to focus on the substance of
the issues.

The key unresolved issues were divided into policy issues and "minor"
technical issues.  

The policy issues were:


	8 bit mode: the draft currently explicitly allows implementation for
both 8 bit and 16 bit data transfer widths for the DT data phases.  While
there is agreement that the proposal provides enough information to
implement either 8 bit or 16 bit, there is a dispute over the desirability
of implementing 8 bit.  This appears to be a "policy," not a technical issue
per se.  Since there are people with decided opinions on this topic, I
suggest we vote on the following options:

			1) 16 bit only, 8 bit forbidden
			2) 16 bit only, silence on 8 bit
			3) 16 bit recommended but and 8 bit allowed
			4) 16 bit and 8 bit allowed

	These options span from the most 8 bit unfriendly to the most 8 bit
friendly.  If this range is acceptable then I will discuss suitable voting
arrangements with John.

	Based on conversation with people, I would recommend the second or
third options.  I think that the first and fourth options would result in
something that some people could not feel comfortable with, while the second
and third options minimize this "backing into the corner."  In any event, I
will adjust the proposal to include wording to support any of the four
options, and so as to make it very clear what the final wording would be
regardless of the decision.


	 Single ended mode: the draft currently implicitly allows
implementation for both single ended and LVD signaling technology for the DT
data phases by being silent on the topic of transceivers.  While not as
hotly debated as the previous issue, I think we should make our position
clear on this topic as well.  This appears to be a "policy," not a technical
issue per se.  Since there are people with decided opinions on this topic, I
suggest we vote on the following options:

			1) LVD only, single ended forbidden
			2) LVD only, silence on single ended
			3) LVD recommended but and single ended allowed
			4) LVD and single ended allowed

	These options span from the most single ended unfriendly to the most
single ended friendly.  If this range is acceptable then I will discuss
suitable voting arrangements with John.

	Based on conversation with people, I would recommend the fourth
option.  I do not have a strong opinion on this matter, but do not see how
forbidding single ended (running at a maximum of Fast-20 speeds) makes
anyone's implementation any easier.  In any event, I will adjust the
proposal to include wording to support any of the four options, and so as to
make it very clear what the final wording would be regardless of the
decision.


The purely technical issues were:


	P1 line in DT data phase: the draft currently has this being parity
for all 16 bits, as per very early discussion of the working group.  During
the con call it was determined that the group was in flux on this issue, and
it needed a firm resolution.  My reading of the group indicates a decline in
support for using this line as a 16 bit line, and instead specifying it as
reserved for future use.  I am proposing two options for consideration:

			1) the current wording indicating that it is 16 bit
parity
			2) new wording indicating that the line is reserved
for future use

	Since there is some confusion over what "reserved" means for a line,
I propose wording that during the DT phase, the device that did not
previously drive the signal in the ST (old SCSI) phase continue to refrain
|from driving that signal.  That is, in DT DATA OUT the target cannot drive
the signal; in DT DATA IN the initiator cannot drive the signal.  The other
device (e.g. target in DATA IN, initiator in DATA OUT), may drive the signal
(but no faster than the data lines), but that the signal shall be considered
invalid and the value ignored by the receiving device.  This wording would
appear to maintain maximum compatibility with previous uses of the signal in
the ST mode, and is a minimum burden on implementers.  By making the value
invalid (instead of, say, 16 bit parity) it prevents the users from starting
to rely on this signal for a particular function when in reality we will be
redefining this function in the future (most likely in Ultra4).  This is
consistent with a future definition of this line as a free running clock
(previously discussed in the working group).  While I have not discussed
this with everyone, this would appear to be acceptable to a number of
people.  

	Note that the driving device may assert, deassert, or tristate the
line.  One possible additional vote could be taken to outlaw tri-stating if
people felt uncomfortable about having a line "float" so close to the high
speed REQ/ACK and data lines.

	Based on conversation with people, I would recommend the reserved
option.  In any event, I will adjust the proposal to include wording to
support either proposal, and so as to make it very clear what the final
wording would be regardless of the decision.


	Pad byte values: we still have no resolution over whether the pad
bytes should be required to have a certain value.  Two suggestions have been
offered in the past:

			1) 00, and,
			2) anything

	I suggest we simply decide between these two once and for all.

	Based on conversation with people, I would recommend the first
option.  In any event, I will adjust the proposal to include wording to
support either proposal, and so as to make it very clear what the final
wording would be regardless of the decision.


I would appreciate any feedback on these issues before the meeting (or
failing that at the meeting).

Jim


*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at symbios.com





More information about the T10 mailing list