[SI-LIST] Re: Timing Methodology (renamed from Question about Simulation in Spectraquest)

  • From: Scott McMorrow <scott@xxxxxxxxxxxxxxxx>
  • To: jdowlin2@xxxxxxxxx
  • Date: Mon, 13 Aug 2001 20:12:35 -0700

Jonathan,

Answers to your questions are below.


> Your proposal sounds similar to the standard/legacy
> methodology in use today for driver and receiver
> characterization.

Yes, it is.  The difference being that the method is documented and extended.
I have no problem with the current timing test load methodology.
Where the problem exists is in it's application.  There is no documented
method for isolating package effects from die and board effects.

>
>
> What is the difference between the standard/legacy
> reference load and the one that you propose?

None.

> It sounds
> like you want to calculate a crosstalk/SSO budget for
> the package that is separate from the rest of the
> net and report a delay/skew/Tco at the package pin.

No, I want to be able to correct the manufacturers timing for the
instantaneous package conditions at a switching edge.  Without
documented switching patterns and accurate coupled package modeling,
this is currently impossible, without resorting to full Spice logic-to-logic
simulation.

>
> That's not the goal of Chris's methodology as I
> understand it.  If there is a reference load,
> wouldn't it have to essentially model the entire
> network?

As I understand it, Chris' methodology is to simulate with
Spice from driver input to receiver output.  In that case, yes,
the load is the entire network and there is no need to de-embed.
This is the preferred method when you have control over
all elements of the design.

I advocate this whenever there is a captive design where absolute
maximum performance is required.  I advocate a modification of
the current standard test load method for all other non-captive
applications.

>
> What is the difference between the "de-embedding" of
> silicon timing you mention relative to the standard/legacy
> way that we think about Tsu/Thold?

In principal, none.  The difference is in the details.  To accurately
de-embed timing internal to the device, you have to  be
able to fully characterize the signalling path, which is composed of
a complex coupled matrix of paths.  Current methodology (in general)
uses a package model which has been transformed and reduced from
a very complex coupled matrix form, into a very simple single ended
form with fixed ground reference.  Information important to timing (and noise)
is lost in this transformation.

> De-embedding timing
> is not the goal of the methodology either.
>

I am suggesting a methodology.  Not necessarily Chris'.
Ultimately, the goal of any timing methodology is to simulate a
system and guarantee timing to within some error tolerance.  I am
suggesting a method which is capable of reducing the error tolerance.

>
> What would you propose to add to the DDR-II spec to
> help support a logic-to-logic timing methodology?
>

Again, I suggest exactly what I did previously:

1) A 50 ohm load on all balls(pins) of a device.
2) Defined data test patterns for output and input testing.
3) Package models which have been correlated for signalling and
    return path effects under all switching conditions.

With these items I can:

a) De-embed the silicon timing from the package effects.
b) Correct the in-system timing at all operating conditions.
c) Perform worst case skew and jitter analysis.

Without established test data patterns you cannot:

i) Differentiate the origin of jitter and skew between the silicon,
package or system.
ii) Determine whether the jitter and skew you are measuring in
simulation was accounted for by the manufacturer's specification.

Without fully coupled, correlated package models, you cannot:
i) Differentiate whether the jitter and skew that you simulate has
been accounted for within the manufacturer's specification.
ii) Correctly simulate crosstalk effects on timing in a system.
iii) Correctly simulate crosstalk in a system.

> The legacy Flight Time Methodology will be King as long
> as there are no crisp answers to the simple questions
> I have posed regarding the application of the proposed
> alternative logic-to-logic timing methodology to current
> and future industry standard interface specifications.

I have given crisp answers.  In some cases, such as is the
case with DRAM, it may be impossible to dislodge the drivers
and receivers from the internal logic.  In this case, my modified
Flight time method should be used.

> Any timing method which aims to dislodge the Flight Time
> method as a standard must be widely integrated into
> industry specs.  Puffing up and claiming superiority
> alone will not be sufficient.

I will state, absolutely, that the logic-to-logic timing method
is always superior to the flight time method, when it is possible
to do so.  Generally, this is limited to captive systems where
all drivers, receivers and packages are "owned" by the
designer.

When one part of a system is owned by a designer, such as
with an ASIC driving DDR memory, I advocate a logic-to-flight time
method, where timing at the ASIC side is performed using
the internal logic node method, and timing at the memory side
is performed using the flight time method.

Finally, when no part of a system is owned by a designer, such
as a standard controller driving a DDR memory system, I advocate
the Flight time method, unless the manufacturer has also provided
timing to the logic.

Currently, industry standard specifications for timing are incomplete.
Timing specified to a pin of a device is ambiguous without knowledge
of the measurement method and the network between the silicon and
the pin.  Timing to a pin is not a "unique" number.  There are many
ways to attain this particular specification.  All of which have implications
on total system noise and timing performance.  I suggest that either
we switch to logic-to-logic modeling for timing and noise simulation, or
unambiguously specify our method for pin oriented Flight Time.

Unfortunately, many vendors of components will balk at unambiguous
timing specifications.  They hide behind the ambiguity.


best regards,

scott


--
Scott McMorrow
Principal Engineer
SiQual, Signal Quality Engineering
18735 SW Boones Ferry Road
Tualatin, OR  97062-3090
(503) 885-1231
http://www.siqual.com






------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
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: