[SI-LIST] Re: Common Clock and Source Synchronous Timing Margins

  • From: "Inmyung Song" <imsong@xxxxxxxxxxxxxx>
  • To: <hirshtal@xxxxxxxxxxxxx>, <ARIAZI@xxxxxxxxxxx>
  • Date: Thu, 24 Jan 2002 09:50:36 +0900



-----Original Message-----
From: si-list-bounce@xxxxxxxxxxxxx [mailto:si-list-
bounce@xxxxxxxxxxxxx]On Behalf Of Itzhak Hirshtal
Sent: Wednesday, January 23, 2002 9:18 PM
To: ARIAZI@xxxxxxxxxxx
Cc: si-list@xxxxxxxxxxxxx
Subject: [SI-LIST] Re: Common Clock and Source Synchronous Timing
Margins


Hello,

Here are some comments, which I hope will be valuable:

(1) It seems to me that the source-synchronous method requires the data bits
to be
transmitted a little AFTER the strobe signal, otherwise you'll probably find
it difficult
to avoid setup AND hold violations. Don't you agree?
-> Yes, I think you're right. Additionally the skew among the data bits.

(2) Also, it seems your equations for the source-synchronous method contain
some errors and
inappropriate parameters:
    - Tco_strobe is not a usable parameter; what is it referenced to? As I
understand it,
only Tco_data is relevant, and it is referenced to the strobe signal itself
in the data
sheet.
    - What is Tdelay exactly? Can you explain? It seems a non-relevant
parameter as well.
    - One must use Tco_min in the hold equations (for source-synchronous as
well as common
clock). I shall call this parameter Toh_data.
    - In my opinion, the 2 equations should be:

        Tsetup_margin = Tcycle + Tflt_strobe - Tco_data - Tsetup - Tflt_data

        Thold_margin = Tflt_data - Tflt_strobe + Toh_data - Thold

-> How about the clock jitter?

(3) You haven't mentioned the opposite direction equations, which are
different for the
source-synchronous case (Tflt_strobe sign is inverted).

(4) To be very accurate one must use the minimum and maximum parameters and
simulation
results as appropriate.

(5) I would like to comment on the solution you propose for setup and hold
failures. It is
very difficult to compensate for them by lengthening or shorting the data
traces, since
they are generally numerous. It is much easier to do the same for one of the
clock signals,
thus generating a deliberate skew. This, of-course, assumes the problem is
one-way, and the
solution does not cause a new problem.

(5) The Interconnectix (ICX) simulator also provides a means for
automatically compensating
for the load difference between the test load and the actual PCB trace load.
But this
method depends, of course, on the manufacturer to supply the appropriate
test load
parameters. Since the IBIS model, on which ICX simulations are based,
assumes a certain
configuration of test capacitance and resistance, this presents a problem
where the
manufacturer uses a different configuration. For example, I encountered a
manufacturer who
claimed he used a current-source test load, with a different current load
for the high and
low states of the tested outputs. I had to use approximations in order to be
able to
simulate these outputs using an IBIS model. Has anyone encountered such a
problem and have
a solution?

-> I use the test circuit in the datasheet, if the IBIS model's test load is
not same with that I reinput
        the value from the datasheet.


Abe Riazi wrote:

> Dear Scholars:
>
> The need for "common-clock" and "source synchronous"  timing analyses,
> arises regularly in pre-route and post-route simulations of  high speed
PCBs.
>
> In a "common-clock" approach, with bus driver and receiver sharing
> the same clock, the setup and hold timing margins are often governed by:
>
> Tsetup_margin = Tcycle - Tpcb_skew - Tclock_skew - Tjitter - Tco_data
>      - Tflt_data - Tsetup
>
> Thold_margin = Tco_data + Tflt_data + Tclock_skew + Tpcb_skew - Thold
>
> Common clock timing techniques are limited to  medium speed (e.g.
frequencies
> below ~ 200 or 300 MHz) buses [Reference 1]; therefore, at higher
> frequencies another means such as source synchronous signaling can be
required.
>
> In the source synchronous scheme the same driver chip is used to send the
> data and strobe signals to the receiver, with strobe signal usually
transmitted a
> short time after transmission of data bits. Applicable formulas include:
>
> Tsetup_margin = (Tco_strobe - Tco_data) +  (Tflt_strobe - Tflt_data ) +
Tdelay - Tsetup
>
> Thold_margin = (Tco_data - Tco_strobe ) + (Tflt_data - Tft_strobe) +
Tdelay - Thold
>
> In above equations Tcycle represents cycle time (clock period) and,
>
> Tpcb_skew = PCB flight time skew ( for clock traces).
> Tco_data =  Driver's data output valid delay (at pad).
> Tclock_skew = The output clock buffer skew.
> Tjitter =  Cycle to cycle variations of clock period.
> Tflt_data =  Data PCB trace (from driver to receiver) propagation delay.
> Tdelay = Offset between data and strobe.
> Tco_strobe = Driver delay of the strobe (at pad).
> Tflt_strobe = Flight time of strobe interconnect.
> Tsetup = Receiver's input set up requirement (at pad).
> Thold = Receiver's hold time requirement (at pad).
>
> Certain parameters (such as Tco ) are usually obtainable from data sheets,
> whereas determining the data and strobe flight times (e.g. Tflt_data and
Tflt_strobe)
> requires simulation.
>
> System flight time corrections are frequently necessary to avoid double
counting of
>  driver rise and fall times and to compensate for system loading effects.
This
>  implies subtracting the rising/falling delays of the buffer driving into
the standard
> test load [ References 2 and 3] from the PCB driver to receiver
propagation delay.
> However, this correction may be also accounted for by the simulation
program.
> For example,  XNS has an enable option for automatic subtraction of
driver's
>  TIME_TO_VM  before reporting the rise and fall times.
>
> The Excel program is quite popular for processing and presenting timing
> simulation results.  A timing spreadsheet can include a listing of
simulated
> buses (nets), driver and receiver nodes, flight times and setup and
> hold margins, etc.
>
> In order for the data to be timely latched in,  it is essential
> to avoid violating the receiver's setup and hold requirements. If
> a net indicates negative setup (or hold) margins, then it is necessary
> to ascertain the cause of  timing violation (this often involves careful
> examination of associated waveforms) and ways of eliminating
> the problem.
>
> Although, there are usually more than one approach for fixing
> system timing problems, setup margin failures are frequently repaired
> by shortening the driver to receiver data trace.  Similarly, negative
> hold margins are often eliminated by lengthening the data line.
>
>  As signal frequencies/edge rates get faster, effects due to non-ideal
> return paths, SSO, ISI, noise, etc. can  significantly increase skew
> and complicate utilization of source synchronous technique.
> Several alternative ways of bus signaling  aimed at minimizing
> skew effect are discussed in Reference 1.
>
> In closing, the common clock and source synchronous formulas
> provide a means for monitoring those timing elements critical
> to system performance, maximum allowable speed,  and setup/hold
> budgets.  Timing spreadsheets in conjunction with waveform
> analyses are commonly applied to identify the causes of failed
> setup/hold margins and means of eliminating these violations.
>
> REFERENCES:
>
> 1. Stephen H. Hall, Garrett W. Hall, James A. McCall, "High Speed Digital
Design
>  A Handbook  of Interconnect and Design Practices", John Wiley & Sons,
Inc.
> 2. Todd Westerhoff, "Basic SI and Timing Budgets for common Clock
Designs",
>  Cadence Design systems, Inc.
> 3. Syed B. Huq, "Effective Signal Integrity Using IBIS Models", DesingConn
2000.
>
> I appreciate your valuable comments.
>
> Respectfully,
>
> Abe Riazi
> ServerWorks
>
> ------------------------------------------------------------------
> To unsubscribe from si-list:
> si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
>
> or to administer your membership from a web page, go to:
> //www.freelists.org/webpage/si-list
>
> For help:
> si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
>
> List archives are viewable at:
>                 //www.freelists.org/archives/si-list
> or at our remote archives:
>                 http://groups.yahoo.com/group/si-list/messages
> Old (prior to June 6, 2001) list archives are viewable at:
>                 http://www.qsl.net/wb6tpu



--
Itzhak Hirshtal

Elta Electronics

POB 330 Ashdod

Israel 77102

Tel   : 972-8-8572841

Mobile: 972-64-238631

Fax   : 972-8-8572978

email: hirshtal@xxxxxxxxxxxxx




------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field

or to administer your membership from a web page, go to:
//www.freelists.org/webpage/si-list

For help:
si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field

List archives are viewable at:
                //www.freelists.org/archives/si-list
or at our remote archives:
                http://groups.yahoo.com/group/si-list/messages
Old (prior to June 6, 2001) list archives are viewable at:
                http://www.qsl.net/wb6tpu


------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field

or to administer your membership from a web page, go to:
//www.freelists.org/webpage/si-list

For help:
si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field

List archives are viewable at:     
                //www.freelists.org/archives/si-list
or at our remote archives:
                http://groups.yahoo.com/group/si-list/messages 
Old (prior to June 6, 2001) list archives are viewable at:
                http://www.qsl.net/wb6tpu
  

Other related posts: