[ibis-macro] Re: issues with retimer
- From: Mike Steinberger <msteinb@xxxxxxxxxx>
- To: ibis-macro@xxxxxxxxxxxxx
- Date: Wed, 19 Feb 2014 14:02:51 -0500
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
Other related posts:
