[ibis-macro] Re: Clocks
- From: Scott McMorrow <scott@xxxxxxxxxxxxx>
- To: Mike Steinberger <msteinb@xxxxxxxxxx>
- Date: Thu, 01 Apr 2010 12:55:44 -0400
Mike
I'm confused. You said:
For example, at SiSoft we routinely add a c*lock 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.
I assume you mean clock reference frequency offset. If I understand,
since this is a Model Specific parameter it is static for the duration
of a GetWave call, and may only change for each call instance. It could
not be used to inject additional deviation in the clock reference, and
could not be used for receiver tolerance correlation using MJSQ. It is
these sorts of compliance tests that will allow us to "believe" that the
CDR is modeled correctly. If the CDR is not modeled correctly, all bets
are off on any clock tick produced by an AMI model, or any BER
extrapolations performed.
regards,
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:
