[ibis-macro] Re: A new Repeater question

  • From: Walter Katz <wkatz@xxxxxxxxxxxxx>
  • To: "Arpad_Muranyi@xxxxxxxxxx" <Arpad_Muranyi@xxxxxxxxxx>, "ibis-macro@xxxxxxxxxxxxx" <ibis-macro@xxxxxxxxxxxxx>
  • Date: Fri, 21 Jan 2022 18:09:52 +0000

Arpad,

Some of the solution space parameters apply as a repeater, some as a retimer.

What bad things happen if a model selector is used?

Walter

Walter Katz
Work  508.647-7633
Cell      720.417-3762
[Description: Description: Visit MathWorks.com]

From: ibis-macro-bounce@xxxxxxxxxxxxx <ibis-macro-bounce@xxxxxxxxxxxxx> On 
Behalf Of Muranyi, Arpad
Sent: Friday, January 21, 2022 12:59 PM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: A new Repeater question

Walter,

Thanks for your comments.  Just because it is a rare case now, it doesn’t
mean that it couldn’t become more common in time…

From a technical point of view, is it worth duplicating an entire [Model]
just so that they can point to different .ami files?  Is it that difficult for
EDA vendors to select between the Redriver and Retimer flows based on
the Repeater_Type AMI parameter?  I think we are already doing that,
except that there is no user selection involved.

Whether the model activates its DFE or CTLE based on this selection
wouldn’t have an effect on what the EDA tool does in the AMI flow,
would it?

Thanks,

Arpad
==============================================================

From: Walter Katz <wkatz@xxxxxxxxxxxxx<mailto:wkatz@xxxxxxxxxxxxx>>
Sent: Friday, January 21, 2022 11:44 AM
To: Muranyi, Arpad <Arpad_Muranyi@xxxxxxxxxx<mailto:Arpad_Muranyi@xxxxxxxxxx>>; 
ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: RE: A new Repeater question

Arpad,

I think this is fundamentally a different model, so I would use model selector 
and two different models.

This is admittedly a rare case so I would not want to have to complicate EDA 
tools to deal with something that we can deal with today. An example of the 
complexities is that the Retimer likely will have a DFE while the redriver will 
have a more complicated CTLE.

Walter

Walter Katz
Work  508.647-7633
Cell      720.417-3762
[Description: Description: Visit MathWorks.com]

From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> 
<ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>> On 
Behalf Of Muranyi, Arpad
Sent: Friday, January 21, 2022 12:39 PM
To: ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] A new Repeater question

Hello Everyone,

I ran into an IBIS-AMI Repeater model recently which came with a Model_Specific
parameter through which the user could select whether it would operate as a
Redriver or Retimer.  However, the Repeater_Type parameter of the model
contained the value “Redriver”.

The problem with this is that the EDA tool is told by this Reserved Parameter 
that
the model is a Redriver, but with the Model_Specific parameter the model could
behave as a Retimer, which the EDA tool doesn’t know about.  Yet, the EDA tool
has to do things differently for Redrivers and Retimers.

Looking at the specification I found that the Reserved Parameter Repeater_Type
can only have a single value, either Redriver or Retimer.  I wonder why did we 
not
allow the Repeater_Type parameter to have Format List with these two values so
that the user could chose from them if the model can do both?

Should we write a BIRD to make that possible?  If we agree that this should be 
added
to the specification, this would be a good time to do it, since we are going to 
make
changes in the Redriver flows with BIRD211 in v7.2…

The workaround today would be to make a duplicate [Model] keyword in which
the only difference would be in their [Algorithmic Model] keyword, which would
point to two different .ami files but the same executable .dll.  One of the 
.ami files
would have Repeater_Type Retimer, and the other Repeater_Type Redriver.

Thanks,

Arpad
========================================================================

GIF image

Other related posts:

  1. Home
  2. ibis-macro
  3. Archive
  4. 01-2022