Fast-20 Timing Definition

Tak Asami (Asami asami at
Thu Jan 5 19:54:40 PST 1995

Following is a proposal I prepared for X3T10 meeting next week.
It relates to the Fast-20 rev 2 document which we just voted to
forward to the review.  WD voted "yes with a comment", and this
proposal is what make the voite a "clean yes".
I will bring in hardcopies to the meeting, but I appreciate if
I can get any early feedback on the subject....


TO:    ANSI X3T10 Committee           Document Number: X3T10/95-109r0

DATE:  January 5, 1994                FROM:  Tak Asami
                                             Western Digital Corp.
RE:    Fast-20 Timing Definition


SCSI-3 FAST-20 draft standard document X3T10/1071D Rev 2 has a serious 
omission, which could result in interoperability problems if abused. 
This is to do with "transfer period" during the data in/out phase.

Even though the Foreword section of the document mentions "to support 
transfer rates of 20, 40, or 80 megabytes per second corresponding to 
the data path width implemented",and Section 4 "General" states "to 
operate at 20 mega-transfer per second", nowhere else in the document 
mentions how that timing is defined. As a result, the document can be 
interpreted to support implementations where the device has to operate 
at much faster rate than the "transfer rate" specified.

SCSI-3 Parallel Interface (SPI) document uses the term "transfer period" 
in the text to classify the transfer rate, though the term is never 

It is my intention to propose an addition to the document to clearly 
define what is meant by the transfer rate/period.

The Table 1 (page 8) in the draft document defines Transmit Assertion 
Period and Transmit Negation period to be 15nsec each. Consequently, 
a transmitting device that generates REQ (if a target) or ACK (if an 
initiator) pulse train show below is operating legally.

      |<--------------------  200nsec  ----------->|
      |15|15|15|15|15|15|15|                       |
    __    __    __    __    _______________________    __    __
      |__|  |__|  |__|  |__|                       |__|  |__|

   (numbers are in unit of nsec)

And it is still transferring at 20 megatransfer per second. A device 
capable of receiving this would be capable of operating at 30 mega-
transfers per second, and costs more than 20 megatransfer per second 

Even if the "transfer period" is defined in term of each cycle, we 
can still have a situation like below. Note none of the individual 
cycle exceeds 50nsec, yet the receiving device still has to deal 
with 30MHz timing (back-to-back 15nsec). 
This dictates the resolution of the synchronizing circuit, therefore 
its complexity, speed and clock frequency.

    ____    __        ______    ___
        |__|  |______|      |__|

   (numbers are in unit of nsec)

In order to allow for cost optimized implementations on Fast-20 bus, 
I propose to ban the timing described above.

To do this, I would like to:

a) define the "transfer period" to be measured between an assertion 
   edge to the next assertion edge of the REQ/ACK signals;

b) clearly define the lower-bound number for the above-defined 
   transfer period.

I propose to revise the X3T10/1071D rev 2 document as follows:

Page 8: Add a row to Section 6, Table 1

Table 1: SCSI bus timing values
| Timing description                       | fast-20  fast  slow  asynch   |
| Transfer Period during                   |                               |
| Synchronous Data Transfer Phases (note 5)| 50nsec  100nsec  200nsec  n/a |
Notes -

5) The transfer period is measured from an assertion edge of REQ (ACK) 
   signal to the next assertion edge of the signal.

Tak Asami ==================================================================
Western Digital Corp.
I/O Product Engineering
(714)932-7621 : Voice
(714)932-6496 : Fax

More information about the T10 mailing list