SPI-3 & Packetized

Gerry_Houlder at notes.seagate.com Gerry_Houlder at notes.seagate.com
Thu Dec 10 10:16:38 PST 1998

* From the T10 Reflector (t10 at symbios.com), posted by:
* Gerry_Houlder at notes.seagate.com
The original packetized definition allowed for slower rates with packetized
because at the time we thought that ST and DT clocking would be done with
the SAME data phase. Thus the former DATA IN/ DATA OUT would handle both
types for parallel and the the new INFORMATION IN/ INFORMATION OUT could do
both types for packetized.

Unfortunately the "DT for phases" didn't follow that model. It was changed
to use the new DT DATA phases (same phase as INFORMATION) to make things
easier for bus analyzers and expanders to interpret things without knowing
the precise transfer agreement in place for that pair of devices. That kind
of forced packetized to do DT only so that it followed that convention. We
don't really want to add a packetized option to ST DATA phases, do we? That
probably costs more effort than it is worth.

I'm sure the "fast-80 without packetized and QA" backers like this
situation because it limits the situations where packetized is a
"competitor". If you want CRC protection and slower speeds, this is the
only option. I think the packetized backers accept the situation because
the performance simulations show that packetized is only a 10% to 30%
performance boost at speed below fast-80 (not enough to justify the switch)
but can be a 40% to 60% boost at fast-80 speeds (definitely justifies a

Larry, you work for a company that should understand the desires of the
"systems marketplace" better than most. You should be in a better position
to tell the T10 committee what the customers want than most of us. What do
your customers want?

* 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