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
<mailto:wkatz@xxxxxxxxxx> wkatz@xxxxxxxxxx
Phone 303.449-2308
Mobile 303.335-6156
Attachment:
To_Dual_Or_Not_To_Dual.pptx
Description: application/vnd.openxmlformats-officedocument.presentationml.presentation
