Thanks for formally laying this out, Walter.
I think this statement: "*This also takes a huge load off our shoulders
trying to document effective flows for other combinations of models,*" is
perhaps the biggest deal.
Another implication of this presentation is that it provides impetus for
"adapt-in-init" model makers like me to work toward
"adapt-in-*either*-init-or-getwave".
There are messy implications to this, e.g. init-based tuning algorithms
which were previously monolithic functions passed the model core to be
optimized and the impulse to be equalized now have to be re-structured as
re-entrant functions at the mercy of getwave block size. But I already have
working mechanisms to do this on my "bench". And doing so can produce
optimizations which are responsive to upstream nonlinear impairments
(typically not an issue until the channel has a redriver.Rx/Tx pair).
Regards,
Bob
On Fri, May 12, 2017 at 1:52 PM, Walter Katz <wkatz@xxxxxxxxxx> wrote:
All,
I am enclosing a presentation that describes when not having Dual models
makes defining correct flows is problematic. It concludes that the only
models that can be GetWave Only are Rx models that have a clock and a latch
and sample the data.
Therefore I propose that our flows strictly be limited to this. For a
simple Tx/Rx there will be two defined lows (Tx Dual and Rx either Dual or
GetWave-Only. Repeater/Retimers has 2 flows for the upstream channel and 2
independent flows for the downstream channel. Repeater/Redrivers will have
three flows (Tx1, Rx1 and Tx2 are Dual models, and Rx2 is either Dual or
GetWave-Only).
Init-Only and GetWave-Only Tx models and Init-Only and GetWave-Only
Redriver Rx models and Init-Only terminus Rx models will not be forbidden,
but there will be no flows for them.
When the Keysight BIRD with new IR outputs of AMI_Init is approved, then
models that are “Init-Only” with the additional IR outputs can be treated
as “Dual” models because the EDA tool can build a proxy AMI_GetWave
function from the additional IR outputs of its AMI_Init function.
We are not deprecating anything. IBIS defines what the inputs and outputs
of the models are, and this does not change. We would just be limiting the
defined/supported flows and give ammunition to AMI Models users to insist
that their IC Vendors deliver models that can be used in the IBIS 7.0
documented flows. This also takes a huge load off our shoulders trying to
document effective flows for other combinations of models,
Walter
Walter Katz
wkatz@xxxxxxxxxx
Phone 303.449-2308 <(303)%20449-2308>
Mobile 303.335-6156 <(303)%20335-6156>
