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

About this list Date view Thread view Subject view Author view

From: Heiko Dudek ([email protected])
Date: Tue Aug 01 2000 - 07:48:47 PDT


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 : [email protected]
>
>
>**** To unsubscribe from si-list or si-list-digest: send e-mail to
>[email protected]. 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: [email protected]

**** To unsubscribe from si-list or si-list-digest: send e-mail to
[email protected]. 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