RE: [SI-LIST] : An Interesting Presentation

Abe Riazi (ariazi@anigma.com)
Wed, 21 Apr 1999 12:18:52 -0700

Dear SI-List Members:

I reviewed all of the communcations related to this subject with lot
of interest. Many thanks.
I utilized the guidelines were provided to calculate a range of
values for the risetimes, from the clock periods. The results
include:

Bus: PC-AT, Clock period: 125 ns, Risetime: 6.25 to 25 ns;


Bus: PCI, Clock period: 16 ns, Risetime: 0.8 to 3.2 ns;

Bus: RAMbus, Clock period: 1.2 ns Risetime: 0.06 to 0.24 ns;

Bus: Ethernet 10BASE-5, Clock Period: 100 ns, Risetime: 5.0
to 20 ns;

Regards,

Abe riazi
ariazi@anigma.com

>----------
>From: Howard Johnson[SMTP:howiej@sigcon.com]
>Sent: Tuesday, April 20, 1999 9:51 PM
>To: si-list@silab.eng.sun.com
>Cc: Chuck Hill
>Subject: Re: [SI-LIST] : An Interesting Presentation
>
>Dear Chuck,
>Thanks for you gracious remarks, which accurately
>reflect the spirit of my presentation.
>
>I should like to point out that in many applications,
>the risetime and clock period are fairly closely related.
>That is, if you look the range of bus architectures that have
>survived the "natural market selection process", you find that
>they typically specify a driver risetime that falls within
>a relatively narrow range.
>If the selected risetime is overly aggressive, the bus fails
>due to the high cost of terminating, shielding, and power
>supply filtering. Cheaper, lower-cost alternatives will
>prevail.
>If the selected risetime is too slow, the bus fails due to
>persistent difficulties managing the timing budget.
>Popular bus architectures seems to migrate towards a
>risetime on the order of five to twenty percent
>of the clock period.
>
>For these reasons, I think it is reasonable when
>contemplating the study of bus designs across mutiple
>orders-of-magnitude of performance to assume that the risetime
>and period are closely enough related that one may look at
>either period or risetime alone, and deduce from that
>simple measure some useful insights.
>
>Best regards,
>Dr. Howard Johnson
>
>At 02:24 PM 4/19/99 -0700, Chuck Hill wrote:
>>Abe,
>>
>>I think your and Howard's point of view are both correct. We SI people see
>>risetime as a more relevant parameter than clock period. But the digital
>>designers that we work with can understand the bus delay and clock period
>>more clearly since the risetime is of only secondary concern to them (if it
>>is a concern at all). The value of Howard's "bus timing ratio" is
>>communicating a general level of difficulty of SI to digital designers in
>>their own terms. It is "a key indicator", but not the only key indicator.
>>
>>
>>Charles Hill, consultant
>>Alta Engineering
>>chuckh@altaeng.com
>>
>>
>>At 09:53 AM 4/17/99 -0700, Abe Riazi wrote:
>>>Dear All,
>>>
>>> Recently, I reviewed an interesting paper by Dr. Howard Johnson, which
>>>had been presented at DesignCon99. It is a PDF file (busarch.pdf)
>>>entitled: "Bus Architecture & Timing", available at the High Speed
>>>Design Web Site: http://www.sigcon.com/
>>>
>>> The paper evaluates design difficulty of several different buses in
>>>terms of bus timing ratio defined by [( bus delay ) / (clock period)].
>>>The results are summarized below:
>>>
>>> Bus: PC-AT, Bus timing ratio: 0.008,
>>>Mode: Slow , Design: Easy;
>>>
>>>
>>> Bus: PCI, Bus timing ratio: 0.062,
>>> Mode: Skew, Design: -------;
>>> Bus: RAMbus, Bus timing ratio: 2.5,
>>>Mode: Distributed clock, Design: -------;
>>>
>>> Bus: Ethernet 10BASE-5, Bus timing ratio: 100, Mode:
>>>Time-space, Design: More difficult;
>>>
>>> In the final slide it is stated: " The ratio (bus delay)/(clock
>>>period) is a key indicator of bus design difficulty".
>>>
>>> Admittedly, I was surprised by the conclusion and method of analysis
>>>employed by this article. Here, a parameter dependent on the PERIOD is
>>>used to evaluate difficulty of bus design. It seems to me that
>>>"Critical Length" is preferable for appraisal of design (or simulation)
>>>complexity of a high speed bus architecture. The Critical Length Lc
>>>varies with the RISE TIME (i.e. Lc = k * Tr / D , where Tr is the Rise
>>>Time ), rather than with the period or frequency.
>>>
>>> Your comments are appreciated.
>>>
>>> Best Regards,
>>>
>>> Abe Riazi
>>> Anigma, Inc.
>>>
>>>**** To unsubscribe from si-list: send e-mail to
>>majordomo@silab.eng.sun.com. In the BODY of message put: UNSUBSCRIBE
>>si-list, for more help, put HELP. si-list archives are accessible at
>>http://www.qsl.net/wb6tpu/si-list ****
>>>
>>
>>
>>**** To unsubscribe from si-list: send e-mail to
>>majordomo@silab.eng.sun.com. In the BODY of message put: UNSUBSCRIBE
>>si-list, for more help, put HELP. si-list archives are accessible at
>>http://www.qsl.net/wb6tpu/si-list ****
>>
>>
>>
>>
>>
>_________________________________________________
>Dr. Howard Johnson, Signal Consulting, Inc.
>tel 425.556.0800 fax 425.881.6149 email howiej@sigcon.com
>
>Upcoming High-Speed Digital Design seminars:
>S E E - - - >>> WWW.sigcon.com
>
>**** To unsubscribe from si-list: send e-mail to majordomo@silab.eng.sun.com.
>In the BODY of message put: UNSUBSCRIBE si-list, for more help, put HELP.
>si-list archives are accessible at http://www.qsl.net/wb6tpu/si-list ****
>
>
>
>
>**** To unsubscribe from si-list: send e-mail to majordomo@silab.eng.sun.com.
>In the BODY of message put: UNSUBSCRIBE si-list, for more help, put HELP.
>si-list archives are accessible at http://www.qsl.net/wb6tpu/si-list ****
>
>

**** To unsubscribe from si-list: send e-mail to majordomo@silab.eng.sun.com. In the BODY of message put: UNSUBSCRIBE si-list, for more help, put HELP. si-list archives are accessible at http://www.qsl.net/wb6tpu/si-list ****