CRC Protection for Non-Data transfer phases

Jim McGrath Jim.McGrath at
Mon Mar 1 14:57:04 PST 1999

* From the T10 Reflector (t10 at, posted by:
* Jim McGrath <Jim.McGrath at>


Thanks for your response.  The non-compatibility with the 8 bit bus was not
deemed to be a factor since the T10 committee had previously ruled out
extending the new protocols to 8 bit buses (the Ultra 3 features are 16 bit
only).  Given this, the upper 8 bits are "free".

Our initial approach was to insert CRC transfers at points in the protocol
(although using 8 bits only).  The problem is that the
COMMAND/MESSAGE/STATUS phase state machines are very complex, and so
inserting additional transfers for CRC would end up requiring a similarly
complex state machine.  There was a large negative reaction to contemplating
a proposal of such complexity that a software implementation (as you
described) would be desirable, for fear of decreasing performance
(unfortunately, customers like added protection without performance
degradation).  Then the observation that the upper 8 bits were "empty" was
made, and things started to click into place.  Using them allows the
protection protocol to be atomic, basically stateless (only the sequence ID
introduces any element of dependency, and that is only with the immediately
preceding transfer, regardless of phase).

Note that using the upper 8 bits for information transfer would allow some
overhead savings, but I think it was felt that the changes would be large
enough that it would not meet the customer's requirement (we are talking
about a specific customer here) on backward compatibility.  Note in
particular that the proposed protection protocol is 100% compatible with
existing bus tools (obviously you would have to enhance them to capture and
display the CRC information, but for normal operation they work fine).  And
if we did adopt that approach, then the comments in the previous paragraph
still apply.

The approach advocated does add hardware (e.g. a new CRC
generator/detector), but it is fairly simple and small.  

While a run is pre defined in hardware, I don't know why you would ever want
to change it.  A run is simply the concatenation of information phases
(except for DATA phase, both ST and DT).  I can't think of a simpler
definition that is relatively memoryless (e.g. you just have to remember the
sequence ID from the previous word transferred) and provides enough
transitions to make the sequence ID a valuable feature.


> -----Original Message-----
> From:	Chandru Sippy [SMTP:c_sippy at]
> Sent:	Monday, March 01, 1999 12:23 PM
> To:	'Jim.McGrath at'
> Cc:	't10 at'; Chuck Micalizzi; Shak Kwok; Raj Gandhi; Fardad
> Siavoshi; Greg Goodemote; Jerry Alston
> Subject:	CRC Protection for Non-Data transfer phases
> Hi Jim!
> I read the CRC proposal (T10/99-119 r0b) you put together. It is a very
> interesting idea and quite intriguing. However, my main concerns are the
> following:
> *	You propose a new CRC algorithm that would require additional
> hardware
> *	A run is predefined. Hence if implemented by hardware, it would not
> be easy to change
> *	Not backwards compatible with an 8-bit bus
> I would like to offer a suggestion that accomplishes what you propose but
> has very little impact on any existing or new hardware implementations.
> The
> suggestion is as follows:
> *	Use the same CRC algorithm as the DT transfer phases (no new CRC
> required)
> *	Let the target determine the run described by your proposal and
> request for CRC as done by the current DT implementation. Future
> implementations can be changed easily since implementation in hardware is
> not mandated. The CRC overhead of 4 bytes is a penalty but it is backward
> compatible with an 8-bit bus, if the SPI-3 specification is amended.
> *	Lastly, the CRC overhead introduced above can be reduced by allowing
> non-data transfer phases to use the upper SCSI bus bits 15 - 8 to transfer
> command, message, and status information as well by exchanging PPR
> messages.
> This actually speeds up the non-info transfer to some extent. A typical
> of 10 bytes followed by ID, Tag (2), and PPR msg (8) for a total of 21
> bytes
> can be reduced to 11 + 2 = 13 REQ/ACK handshakes instead of the current 21
> REQ/ACK handshakes needed. This would require some steering logic for
> these
> phases in hardware but the impact should be small since it already exists
> for DT transfer phases. The committee will have plenty of ideas of how to
> deal with extra unwanted ODD byte outlined by the above example. At this
> point, I haven't given it much thought.
> I believe the above suggestions accomplish the same ends as described by
> your new CRC proposal but with much less impact on hardware for any new or
> existing SCSI chip designs.
> Let me know what you think?
> Sincerely,
> Chandru M. Sippy.
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at

More information about the T10 mailing list