RE: [SI-LIST] : Bus Design Methodology in SpectraQuest

About this list Date view Thread view Subject view Author view

From: Heiko Dudek (heikod@cadence.com)
Date: Tue Aug 01 2000 - 11:27:14 PDT


Farrokh,

you're definitely right. It of course needs to be Tflight(max) instead of Tflight(min).
Thanks for notifiying.

  - Heiko

At 09:23 AM 8/1/00 -0700, you wrote:
>Heiko,
>
>I believe there is a small typo on your first equation. It should be:
>
>Tflight(max) < Clock Period - Driver(Tco(max)) - Skew - Jitter - Crosstalk - Receiver(Setup)
>
>
>Regards,
>
>Farrokh Mottahedin
>
>Quantum Corp.
>500 McCarthy Blvd.
>Milpitas, CA 95035
>(408)324-7934
>farrokh.mottahedin@quantum.com
>>-----Original Message-----
>>From: Heiko Dudek [mailto:heikod@cadence.com]
>>Sent: Tuesday, August 01, 2000 7:49 AM
>>To: si-list@silab.eng.sun.com
>>Cc: Vinh Do
>>Subject: Re: [SI-LIST] : Bus Design Methodology in SpectraQuest
>>
>>Hello Vinh,
>>
>>probably it's all well-known, nevertheless a quick recap of the differences of
>>common clock designs vs source synchronous (aka clock forwarding).
>>
>>In a common-clock situation an external clock signal is delivered to the driver
>>and each receiver. Once the driver sees the clock signal (and a certain time,
>>called clock-to-output aka Tco has passed) it sends the data signal on the way.
>>Once the receiver sees the clock signal (and the setup time has passed), the
>>data signal needs to be available at the receiver for at least the receiver hold
>>time. Of course, all of this has to happen within one clock period.
>>All this comes down to what's known as 'timing-budgeting', for all driver-receiver
>>pathes and all load-conditions these two statements have to be true:
>>
>>Tflight(min) < Clock Period - Driver(Tco(max)) - Skew - Jitter - Crosstalk - Receiver(Setup)
>>Tlight(min) > Receiver(Hold) - Driver(Tco(min)) + Skew + Jitter + Crosstalk
>>(Crosstalk here means the timing-shift because of crosstalk effects)
>>
>>The values for Tco max/min, Receiver(Setup) and Receiver(Hold) can be taken from
>>datasheets or timing models, Clock Period is a design parameter. Hence Tco is
>>measured by the component vendor under a certain load condition (of course, after
>>the output stage) and IBIS models the output-stage (including the delay of the output
>>stage), we need to correct for not taking the output stage delay into account twice.
>>This is done in the 'buffer delay measurements', the IBIS model should contain the
>>exact buffer delay setup the component vendor used to measure Tco.
>>
>>Now let's look at source synchronous. There's no more external clock, the signal
>>for synchronization is built into the driving device (and called 'strobe') (well, RAMBUS
>>is using a slightly modified way, but the principles are still the same). Since the
>>strobe signal is built into the driving device, there's no more Tco and no more clock
>>skew. Acutally, the whole way of doing timing-budgeting (including correcting for
>>buffer delay) is no more valid. Instead, we care about two things:
>>
>>Data at receiver + Receiver(Hold) <= next strobe event at receiver
>>Data at receiver - Receiver(Setup) >= previous strobe event
>>(usually, both the rising and falling edge are used for clocking)
>>
>> ______
>>|______| |_ Strobe
>> _____
>>____| |_____ Data
>>
>> <-> Receiver(Setup)
>> <-> Receiver(Hold)
>>
>>So two things, we need to assign a strobe signal (strobe pin) to data signals and next,
>>we need to do 'relative measurements', comparing strobe and data signals at the
>>receiver. (The SigXp 'Custom Measurements' and 'Set'-'Strobe Pins' can do this job)
>>Additionally, you want to check the receiver signal at the die pad rather than at the
>>component pin (margins usually are very tight) and you want to send not just a rising
>>or falling edge throu your system but a much more complex bus pattern.
>>(Use the '_internal' nodes to measure at the die pads and use 'Custom Stimulus' to
>>define the stimulus pattern.)
>>
>>The constraints you're getting out of this analysis are pretty simple: It's the maximum
>>skew between all data and the strobe lines (some matched length rule).
>>
>>Vinh, I'm going to send you an example SigXp topology with all Strobes and
>>Custom Measurements defined off-line from the SI reflector.
>>
>> - Heiko
>>
>>At 06:11 PM 7/31/00 -0700, you wrote:
>>>Hi all,
>>>
>>>I am trying to figure out how to design the complex buses in SpectraQuest.
>>> >From what I know, there is an option "Custom" in the "IO Cell Stimulus Edit"
>>>in this tool that allow us to set up for synchronous and source synchronous
>>>timing simulation, but I do not fully understand them. I am wondering if
>>>there are anyone who has experience with these that can help me with or give
>>>me the source of information. I would appreciate any help.
>>>
>>>Regards.
>>>
>>>Vinh Do
>>>Phone : 408 - 745 - 8103
>>>Email : vdo@juniper.net
>>>
>>>
>>>
>>>**** To unsubscribe from si-list or si-list-digest: send e-mail to
>>>majordomo@silab.eng.sun.com. In the BODY of message put: UNSUBSCRIBE
>>>si-list or UNSUBSCRIBE si-list-digest, for more help, put HELP.
>>>si-list archives are accessible at http://www.qsl.net/wb6tpu
>>>****
>> Heiko Dudek
>> Technical Marketing Manager | High Speed Systems Design & IC Packaging
>> Cadence Design Systems | 270 Billerica Road | Chelmsford, MA 01824
>>
>> ph: (978) 262-6384
>> fx: (978) 446-6798
>> email: heikod@cadence.com
>
> Heiko Dudek
> Technical Marketing Manager | High Speed Systems Design & IC Packaging
> Cadence Design Systems | 270 Billerica Road | Chelmsford, MA 01824
>
> ph: (978) 262-6384
> fx: (978) 446-6798
> email: heikod@cadence.com

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


About this list Date view Thread view Subject view Author view

This archive was generated by hypermail 2b29 : Wed Nov 22 2000 - 10:50:55 PST