FW: Pls forward to the the fast-20 committee, thanks

Lohmeyer, John JLOHMEYE at cosmpdaero.ftcollinsco.ncr.com
Tue Feb 7 19:25:00 PST 1995


+   To: SCSI Reflector (scsi at wichitaks.ncr.com)
+ From: John Lohmeyer (john.lohmeyer at hmpd.com)
+   Cc: ktcnslt at gate.net

I received the following message with a request that it be directed to the 
appropriate people involved with Fast-20 & Fast-40.  Any comments?  Please 
send a cc: on any comments to ktcnslt at gate.net as Tim apparently is not 
currently on the SCSI Reflector.

John

 --
John Lohmeyer             E-Mail:  john.lohmeyer at hmpd.com
NCR Microelectronics       Voice:  719-573-3362
1635 Aeroplaza Dr.           Fax:  719-573-3037
Colo Spgs, CO 80916     SCSI BBS:  719-574-0424 300--14400 baud



        John,

        I wanted to make sure.. that my proposal gets considered for the
        fast-20, fast-40 SCSI specifications.  I am one of the most
        active designers in the SCSI field, with many years of SCSI
        battle(field) design experience(8).

        I had sent out a similar email to the SCSI Ansi member at trimm,
          but never got a response.


    Proposal to add an Implementers note to the fast-20, fast40
        SCSI specifications.

        ------

        It is recommended that the SCSI interface maintain the following
        minimum assert and deassert time values when driving either
        /Req or /Ack according to the following formula.

        Min_assert period > (Negoiated rate between ITL nexas(ns) / 2 *.8 )
        Min_deassert period > (Negoiated rate between ITL nexas(ns) / 2 *.8 
)


                I.E. 20mhz ( 50ns / 2 *.8 = 20ns assert/deassert period )
                     10mhz (100ns / 2 *.8 = 40ns assert/deassert period )
        -------

    This corrects one of the big errors that occured in the leap to
  SCSI-II fast.

    The min assert/deassert periods where 90ns in SCSI 1, which is
  roughly equals 5.5mhz harmonics on req/ack lines vs 5mhz data (not
serious).
  Then SCSI-2 fast comes along and decreases the min assert time to
  30ns, which equals 16.6mhz harmonics on req/ack for anything over
  5mhz ITL data rate. I.E. Cable/drivers must be good to 16mhz even if
  the devices only negoatiate at 5.2mhz ITL or even if the OS limits the
  ITL date rate to 8mhz.  This also prevents a reasonable back down 
algorithm
  when errors do occur. I.E. One must step back to 5mhz ITL to get back
  to a reasonable req/ack harmonic on the cable..

    Now the ultra spec compounds the problem by dropping then assert/
  deassert period to 15ns for anything over 10mhz ITL data rate..
  I.E. 33mhz primary harmonics, bad news for FCC compliance, and
   cable reflections, etc...

   By following the suguested guildlines, which aren't all that difficult
  to achieve in hardware. We won't have to pay for 20mhz all at once.
  Plus if the guildlines are followed the top end primary harmonic will be
  25mhz..(20ns assert/deassert), thus keeping the FCC out of our hair.

    Please forward this email to anyone who might interested on the
  subject.


        Tim Keating
        Keating Consulting
        2273 Discovery Circle West
        Pompano Beach, Fl 33064
        ktcnslt at gate.net
        (305) 427-9795
        (305) 427-4776 (fax)

        SCSI, RAID and Networking Solutions for the 90's.







More information about the T10 mailing list