Reason for the CRC_A extra timing

Richard Moore r_moore at qlc.com
Thu May 13 17:44:23 PDT 1999


* From the T10 Reflector (t10 at symbios.com), posted by:
* Richard Moore <r_moore at qlc.com>
*
Rob (and T10 Reflector Subscribers),

We have now seen 3 options presented for this proposal. Option 1 in rev 0
has the problem I outlined earlier. The new Option 3 in rev 1 states,
"Existing implementations probably generate the extra pause as a multiple
of the fundamental data period. For Fast-80 DT, the pause would be a
multiple of 12.5 ns or 25 ns. Requiring 12.5 ns extra shouldn't break any
existing implementations." This conclusion is correct only for Fast-80 DT
since only 12.5 ns is being added to the assertion and negation times, and
that is the amount which existing implementations will add to get the extra
10 ns setup time. But for the slower rates, existing implementations may
still be adding only 12.5 ns setup time, when the proposal calls for 25 ns,
50 ns, or 100 ns to be added. The bottom line is that Option 3 will break
existing implementations.

Going back to rev 0 Option 2, on careful review I don't think this option
breaks the principle requiring added setup time. Option 2 does not change
the
transmit setup time for P_CRCA, which means that the signal arriving at the
receiver will have the added robustness (we may be changing an assumption
about the medium but we are not changing the medium itself, so the
difference
appears as added margin which in fact is the point of the extra setup time).
The receiver shouldn't require any extra setup time for this signal compared
to the data, so reducing the receive setup time isn't likely to break any
implementations on the receiving end. However, since all we are doing is
tightening a requirement on the receiving device, we cannot assume that this
spec change will result in any change of the received signal. So it is hard
to see how this will fix any problems. Even if Option 2 does provide a
solution,
since this option states that Gene's numbers (99-183) would be the preferred
numbers, the proposal seems unnecessary since 99-183 has been adopted.

I have no objection to Option 2 if it actually solves a real problem, but I
do not have a clear understanding of what the problem is and how Option 2
solves it. Can you elaborate?

 -- Richard Moore
    QLogic Corp.


>-----Original Message-----
>From: relliott at hobbit.eng.hou.compaq.com
>[mailto:relliott at hobbit.eng.hou.compaq.com]
>Sent: Thursday, May 13, 1999 11:44 AM
>To: t10 at Symbios.COM
>Subject: Re: Reason for the CRC_A extra timing
>
>
>* From the T10 Reflector (t10 at symbios.com), posted by:
>* relliott at hobbit.eng.hou.compaq.com (Robert Elliott)
>*
>> The justification for keeping the extra setup time is as follows:
>>  
>> 2. If detection of CRC_A true at the initiator occurs too 
>late on a pad word
>> transfer, then the initiator will think there are no pad bytes and:
>
>This reason was convincing.  Maybe the pad bytes shouldn't have been
>included in the DT CRC calculation.
>
>We've prepared a new version of the proposal that is now on the T10
>web site: 
>  ftp://ftp.symbios.com/pub/standards/io/t10/document.99/99-185r1.pdf
>
>This version extends the minimum assertion or negation period during
>P_CRCA transitions.  I added one data width (12.5 ns for fast-80DT) to 
>the current value, which should be compatible with current 
>implementations.  
>The setup and hold times are left the same.
>
>This guarantees the minimum period is greater than the hold time plus 
>the setup time.  With the current numbers, that is true for 
>normal data 
>phases but fails for P_CRCA transition phases.
>
>-- 
>Rob Elliott      UNIX mailto:relliott at hobbit.eng.hou.compaq.com    
>Houston, TX        PC mailto:Robert.Elliott at compaq.com
>*
>* For T10 Reflector information, send a message with
>* 'info t10' (no quotes) in the message body to majordomo at symbios.com
>
*
* 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