[ibis-macro] Re: Clocks
- From: Scott McMorrow <scott@xxxxxxxxxxxxx>
- To: Mike Steinberger <msteinb@xxxxxxxxxx>
- Date: Thu, 01 Apr 2010 11:43:03 -0400
Mike
Please forgive me if I get this wrong, since I'm catching up on my
IBIS-AMI knowledge. I believe there are two ways to send a clock to
GetWave. Both not documented in the specification.
* pass clock_ticks into the DLL and use them to reconstruct the
reference clock crossing points to drive the DLL
o This is non-standard, since this path is not documented in
the specification, the EDA platform does not know to do it,
nor does it know what the requirements for this clock stream
would be.
o A forwarded clock can also be output by the Tx, so there is
some sense to this type of flow.
o The advantage to this is that reference clock crossing
statistics can be incorporated into the ticks
+ This is limited, as it does not allow for injection of
additional simulated noise into the base clock, since
the actual waveform is not known.
# But one could characterize the additional
statistics and use them for additional
perturbation of the clock_ticks array.
* pass the clock as a crosstalk waveform into the DLL.
o This is non-standard, since the AMI specification defines
additional impulse response channels as aggressors against
the primary channel, and does not identify any secondary
thru channels.
o This is actually an interesting approach, since DJ can be
simulated and added to the ref clock.
+ A separate clock Tx can be modeled and included.
o It is, however, a path that has no standard way of being
defined that is currently unambiguous to all EDA platforms.
If we look at a CDR, noise at the input amplifier/comparator/phase
detector impacts jitter, as does noise in the reference clock input to
the PLL. Both impact loop dynamics in a different way, and are not
linear, since jitter multiplication can occur. We look forward to being
able to simulate this, since the really hard BER problems are related to
CDR performance.
The problem I see, is that the AMI interface is a "roll your own" type
of interface, with little standardization of functions and flows. The
only flows that are documented are simplistic SerDes channels with
crosstalk aggressors, and either statistical or transient simulation.
Beyond this, it is very easy to diverge, and create models that require
specific simulation setup intervention. This makes interoperability
difficult, since there is much a-priori knowledge that must be known to
set up the entire simulation environment correctly.
Scott
Mike Steinberger wrote:
Scott-
Here's a partial answer (sung to the tune of "God Bless the Child", by
Billie Holiday).
I suggest a general principle that if there's something the AMI model
can reasonably be expected to know and model, then the AMI model
should do that modeling. Anything that the AMI model cannot reasonably
be expected to know or to model must be the responsibility of the EDA
platform. ("Mama may have, and Papa may have, but Gob bless the child
who's got his own, who's got his own.")
For example, at SiSoft we routinely add a clock reference offset
parameter to every receiver model. Typically, the vendor's analysis
environment did not run fast enough to simulate enough bits to make a
reference clock offset meaningful, but AMI models run fast enough to
make the modeling of reference clock offset quite practical. The
reference clock offset only takes a few additional statements in the
model, so putting it in makes good sense.
Here's another broad hint: We already have a forwarded clock interface
to the receiver models. No invention required.
Mike S.
Scott McMorrow wrote:
We've been pondering several things over here in TeraspeedLand (sung
to the tune of JungleLand, by Bruce Springsteen)
------------------------------------
Given a SerDes channel where:
* the Tx reference clock is based upon an external clock with it's
own unique stochastic properties
* the reference clock is then forwarded from the Tx to the Rx
* the Receiver uses the forwarded clock as the reference for a CDR
* there are both deterministic and random components to the clock
noise statistics
How would IBIS-AMI be used to model the impact of PLL jitter
transfer, amplification, and noise-injection, along with integrating
that into modeling and simulation of the PLL loop dynamic effect on
DFE cascade errors?
------------------------------------
Given a SerDes receiver where:
* the reference clock is derived from an external clock source
with it's own deterministic and random stochastic noise profile
*
* How would IBIS-AMI be used to model the impact of these noise
sources on the PLL loop dynamics, and their subsequent impact on
equalization and data recovery?
-------------------------------------
Given compliance correlation studies on a serdes receiver:
* how can noise injected into the reference clock be modeled,
along with it's impact on equalization and data recovery?
-------------------------------------
As you can see, I'm wondering how clock "stuff" fits into the flow.
regards,
Scott
--
Scott McMorrow
Teraspeed Consulting Group LLC
121 North River Drive
Narragansett, RI 02882
(401) 284-1827 Business
(401) 284-1840 Fax
http://www.teraspeed.com
Teraspeed® is the registered service mark of
Teraspeed Consulting Group LLC
--
Scott McMorrow
Teraspeed Consulting Group LLC
121 North River Drive
Narragansett, RI 02882
(401) 284-1827 Business
(401) 284-1840 Fax
http://www.teraspeed.com
Teraspeed® is the registered service mark of
Teraspeed Consulting Group LLC
Other related posts:
