Reason for the CRC_A extra timing

Richard Moore r_moore at
Tue May 18 09:11:06 PDT 1999

* From the T10 Reflector (t10 at, posted by:
* Richard Moore <r_moore at>
Rob Elliott wrote:

>Existing hardware might not have optimized timing paths for P_CRCA due
>to this exemption, although no one has made that protest yet.  

What exemption?

>Some expanders need the CLOCK assertion time to be longer than the
>DATA hold time plus the DATA setup time.  For fast-80DT: 
>    receiver
>        assertion period 10 
>        DATA hold time plus setup time 1.45 + 1.45 = 2.9
>    transmitter
>        assertion period 11.5
>        DATA hold time plus setup time 4.8 + 4.8 = 9.6
>So, it has no trouble handling DATA.
>When P_CRCA transitions, this doesn't hold true.  
>    receiver
>        assertion period 10
>        CRC hold time plus setup time 1.45 + 11.45 = 12.9
>    transmitter
>        assertion period 11.5
>        CRC hold time plus setup time 4.8 + 14.8 = 19.6

But by definition, the actual assertion period (leading edge to trailing
is at least the minimum hold time (leading edge to earliest allowable CRCA
plus the minimum setup time (latest allowable CRCA transition to trailing
edge). Even
though we don't explicity specify a longer clock assertion or negation
period during
the cycles where CRCA transitions, we cannot extend setup time without
extending this
period so the requirement is there implicitly.

>The minumum assertion time is overwhelmed by the CRC hold time plus 
>the CRC setup time.  The expander has trouble regenerating the long
>CRC transmit setup time under these conditions.

If the problem is regenerating the signals with the full added setup time,
being constrained by the clock granularity of the expander, perhaps the
solution is
to require expanders to only provide 5 ns of added setup for CRCA, while
that target devices must meet the full original requirement. We won't
support either
extending or reducing the original requirements for devices other than

>spi3r06 just came out.  The old algorithm of adding 10 ns for CRC setup 
>and hold compared to DATA setup and hold doesn't hold true any more.  I 
>assume that is an editorial problem.

I don't know. I think r06 contains the numbers exactly as Gene proposed
them. It would seem that
not adjusting the numbers for CRCA, as they were for ATN, was an oversight
in the proposal.

>Nevertheless, the CRC Receive setup and hold were reduced quite a bit for
>fast-10DT, fast-20DT, and fast-40DT.  I think we'd be happy with
>12.5 ns more than the normal assertion/negation periods for each
>of the speeds:
>receive REQ assertion or negation period with P_CRCA transitioning:
>92.5, 52.5, 32.5, 22.5
>transmit REQ assertion or negation period with P_CRCA transitioning:
>104,5, 58,5, 35.5, 24

Defining additional terms such as "Transmit REQ Assertion Period with P_CRCA
seems like overkill. Meeting the spec on CRCA setup and hold already
requires extending
the REQ assertion and negation periods during CRCA transition.

 -- Richard Moore
    QLogic Corp.
* 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