[ibis-macro] Re: issues with retimer
- From: Kumar Keshavan <ckumar@xxxxxxxxxxx>
- To: Mike Steinberger <msteinb@xxxxxxxxxx>
- Date: Wed, 19 Feb 2014 11:38:13 -0800
Mike:
You made my day. I agree you should be able to tell whether clock ticks are
valid or not by just looking at the vector. But my understanding is that the
spec apparently adds another conditionality /exception in case of a redirver
where the eda tool is supposed to ignore the clock ticks even if it is valid.
From: Mike Steinberger [mailto:msteinb@xxxxxxxxxx]
Sent: Wednesday, February 19, 2014 2:30 PM
To: Kumar Keshavan
Cc: ibis-macro@xxxxxxxxxxxxx
Subject: Re: [ibis-macro] Re: issues with retimer
Kumar-
Thanks for the clarification.
What this looks like to me is a feature of the EDA tool. Just because a model
is a redriver model rather than a retimer model doesn't mean that the EDA tool
is forced to ignore any clock ticks that might be present. That's a decision to
be made by the EDA vendor (perhaps based on input from the users). The nice
thing about the clock ticks interface (kudos to you, as it happens) is that the
EDA tool can tell whether or not it's getting valid clock ticks from a given
model.
Mike S.
On 02/19/2014 01:21 PM, Kumar Keshavan wrote:
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>
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Mike Steinberger
Sent: Wednesday, February 19, 2014 2:03 PM
To: ibis-macro@xxxxxxxxxxxxx<mailto: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
Other related posts:
