Mike:
I think your point 2 is like what I am saying.
Let me try to rephrase.
Today if I label a model a retimer and send out a waveform along with
a clock ticks , the eda tool will use the clock ticks and generate a
modified waveform.
The new type of retimer I am thinking of will also send out 2 items,
waveform and clock ticks. However the eda tool in this case will
1.Just transmit the waveform unmodified down stream just as it does
for the redriver
2.It can optionally use the clock ticks to display the intermediate eye
thanx
*From:*ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] *On Behalf Of *Mike Steinberger
*Sent:* Wednesday, February 19, 2014 2:03 PM
*To:* ibis-macro@xxxxxxxxxxxxx
*Subject:* [ibis-macro] Re: issues with retimer
Kumar-
It's not clear what problems you're encountering and/or what changes
you wish to make to the specification.
So that I can better understand what you're saying,
Q: For a more accurate model of a retimer, do you want the waveform
output of the receiver portion of a redriver/retimer to be the input
to the retimer decision latch or the output of the retimer decision latch?
I can see that either possible answer has its limitations, and "both"
is not a practical option.
1. If the output of the retimer receiver model is the input to the
retimer data decision latch, then that provides a useful eye diagram
for the user, but requires that the EDA tool make the decisions.
(Current retimer solution with its benefits and limitations)
2. If the output of the retimer receiver model is the output of the
retimer data decision latch, then it's possible for the model of the
decision process to include all of the nuances of data decision latch
behavior, including the effects of the recovered clock, but then the
eye diagram presented to the user is not very helpful (as you observe
quite correctly).
If we want to have our cake and eat it too, then perhaps we could
consider offering an enhanced specification for the decision process
implemented in the EDA tool. I don't really want to do that because I
believe we still have more critical problems to work on; but it would
be one of the possibilities.
Mike Steinberger
On 2/19/2014 1:22 PM, Kumar Keshavan wrote:
Hi:
The current redriver/retimer spec in IBIS is artificial and
restrictive as I cannot create a true Retimer model that
represents my physical device -- without labeling it as a
Redriver. This, however, forces the EDA tool to ignore the clock
ticks sent out by my retimer model -- which prevents it from
correctly representing the intermediate eye creating doubts in the
users mind.
If I want to model a Retimer in today's specification, I am forced
to hand over part of the regeneration job to the EDA tool. This
restricts me from modeling any non-ideality in the regeneration
process.
This can be resolved by allowing a third option for Repeater_Type
(besides Redriver and Retimer) as which allows a True_Retimer
model which behaves like a Redriver in today's specification --
but also allows the EDA tool to consider the clock ticks coming
from the Retimer model.
Thanx
kumar
