Reason for the CRC_A extra timing

Bruce Leshay Bruce.Leshay at
Wed May 19 12:13:45 PDT 1999

* From the T10 Reflector (t10 at, posted by:
* Bruce Leshay <Bruce.Leshay at>
Sorry to come into this discussion a little late.

I agree with Richard Moore's last reply that in reality it can never be true
that the pulse width of REQ is narrower than the setup/hold time of CRC_A -
if you extend the setup time, the only way you can do that is by extending
the REQ width.

Also, our existing implementation simply adds 1 clock tick (12.5ns) of extra
CRC_A setup time, regardless of the negotiated speed, so we'd obviously be
against any solution which breaks that.  Removing the extra setup time as
Rob Elliot originally proposed would not break any existing implementation,
but as Richard points out, the extra setup time was insurance since the
CRC_A line can affect whether the pad bytes are treated as pad or data.

So after all that - are we back to 10ns (or 12.5ns) extra setup on CRC_A?
Can the companies which design expanders chime in on whether this really
gives them a problem?

				Bruce Leshay
				Quantum Corporation
* 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