Reason for the CRC_A extra timing

Robert Elliott relliott at
Sat May 15 17:05:14 PDT 1999

* From the T10 Reflector (t10 at, posted by:
* relliott at (Robert Elliott)
Richard Moore <r_moore at>:
> 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.

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

Gene's numbers were better for fast-10DT and fast-20DT, but insufficient
for fast-40DT and fast-80DT.  

> 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?

Ideally, an expander accepts the receive minimums at one port and 
generates (better than) the transmit minimums on its other port.  At
fast-80DT rates, a DATA signal should be able to arrive with 1.45 ns 
setup on one bus segment and be regenerated with 4.8 ns setup time 
on the other bus segment.

Some expanders need the CLOCK assertion time to be longer than the
DATA hold time plus the DATA setup time.  For fast-80DT: 
        assertion period 10 
        DATA hold time plus setup time 1.45 + 1.45 = 2.9
        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.  
        assertion period 10
        CRC hold time plus setup time 1.45 + 11.45 = 12.9
        assertion period 11.5
        CRC hold time plus setup time 4.8 + 14.8 = 19.6

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.

Options 1 and 3 address this problem.  Option 2 gives up, forcing the 
expander to be considered only as part of one bus segment rather than a 
bridge between two bus segments.  By reducing the receiver setup time, 
the expander has more room to degrade the signals.  The receive setup 
time at the expander must be better than the worst case allowed at a 
normal receiver or the whole bus segment won't meet timing.

We prefer Option 3.  

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.

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

Rob Elliott      UNIX mailto:relliott at    
Houston, TX        PC mailto:Robert.Elliott at
* 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