[ibis-macro] Re: Clocks
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: <scott@xxxxxxxxxxxxx>, "Mike Steinberger" <msteinb@xxxxxxxxxx>
- Date: Thu, 1 Apr 2010 08:58:04 -0700
Scott,
The clock_times vector was not intended to be used as
an input to the DLL. The Tx clock_times vector was
not intended to be used for forwarded clocks. In fact,
it came up in the discussions why we have to for Tx
at all if it doesn't have CDR. The answer was to keep
the same DLL function footprint.
Similarly, the cross talk waveforms were not intended to
be used for inputting clock to the DLL.
These intensions may not be written down, so we might
consider mentioning them in a clarification BIRD.
I think what you are trying to need to be discussed,
but were not considered before (as far as I understand
and remember).
Arpad
=========================================================
________________________________
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Scott McMorrow
Sent: Thursday, April 01, 2010 10:43 AM
To: Mike Steinberger
Cc: IBIS-ATM
Subject: [ibis-macro] Re: Clocks
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
* 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.
* A forwarded clock can also be output by the Tx, so there
is some sense to this type of flow.
* 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.
* 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.
* 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.
* 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(r) 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(r) is the registered service mark of
Teraspeed Consulting Group LLC
Other related posts:
