[ibis-macro] Re: Comments on BIRD166.3 and last week's ATM discussion

  • From: Mike LaBonte <mlabonte@xxxxxxxxxx>
  • To: <Arpad_Muranyi@xxxxxxxxxx>, <ibis-macro@xxxxxxxxxxxxx>
  • Date: Wed, 7 Jun 2017 15:48:32 -0400 (EDT)

The key phrases are “if GetWave_Exists was required for both” and “if 
Init_Returns_Impulse was required for both”. If we are proposing that tools 
need only support the all-GetWave and all-Init cases, then not all pairs of 
TX and RX delivered today pass that test.



Mike



From: ibis-macro-bounce@xxxxxxxxxxxxx 
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Wednesday, June 07, 2017 3:20 PM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: Comments on BIRD166.3 and last week's ATM 
discussion



Scott,



I kind of guessed that, but how about the “could be simulated” phrase?



Thanks,



Arpad

===========================================================



From: Scott McMorrow [mailto:Scott@xxxxxxxxxxxxx]
Sent: Wednesday, June 7, 2017 2:18 PM
To: Muranyi, Arpad <Arpad_Muranyi@xxxxxxxxxx 
<mailto:Arpad_Muranyi@xxxxxxxxxx> >; ibis-macro@xxxxxxxxxxxxx 
<mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: RE: Comments on BIRD166.3 and last week's ATM discussion



Arpad,



He’s talking about interoperability of AMI models.  Pair meaning one Tx and 
one Rx model.



Scott McMorrow, CTO Signal Integrity Group

Samtec

Office 401-284-1827 | +1-800-726-8329

 <http://www.samtec.com/> www.samtec.com



From: ibis-macro-bounce@xxxxxxxxxxxxx 
<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> 
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Wednesday, June 7, 2017 3:16 PM
To: ibis-macro@xxxxxxxxxxxxx <mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] Re: Comments on BIRD166.3 and last week's ATM 
discussion



Mike,



I am sorry but I don’t understand what you mean by “could be simulated as a 
pair” and

“could be simulated”.  Could you explain this please?



Does this imply that 51% of the models you looked at do not have matching 
GetWave_Exists

values, and over 90% of the models you looked at do not have matching 
Init_Returns_Impulse

values?



Thanks,



Arpad

=========================================================================



From: ibis-macro-bounce@xxxxxxxxxxxxx 
<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> 
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Mike LaBonte
Sent: Wednesday, June 7, 2017 12:24 PM
To: ibis-macro@xxxxxxxxxxxxx <mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] Re: Comments on BIRD166.3 and last week's ATM 
discussion



Just to add a bit of data, an examination of a few hundred TX/RX model pairs 
from many vendors finds that about 51% could be simulated as a pair, if 
GetWave_Exists was required for both. Over 90% could be simulated if 
Init_Returns_Impulse was required for both. But of course those are likely 
best case numbers; the sticky point is how users fare when models from 
different companies must work together, especially in a repeater chain.



Mike



  _____

From: "Ken Willis" <kenw@xxxxxxxxxxx <mailto:kenw@xxxxxxxxxxx> >
To: "Arpad Muranyi" <Arpad_Muranyi@xxxxxxxxxx 
<mailto:Arpad_Muranyi@xxxxxxxxxx> >, ibis-macro@xxxxxxxxxxxxx 
<mailto:ibis-macro@xxxxxxxxxxxxx>
Sent: Wednesday, June 7, 2017 9:13:29 AM
Subject: [ibis-macro] Re: Comments on BIRD166.3 and last week's ATM 
discussion



Hi all,



I am not in favor of giving the EDA tool the responsibility to “invent” 
model functionality that the model developer did not put into the model. I 
think if the modeler wants to support a statistical channel simulation flow, 
they need to put the appropriate Init functionality in. Likewise, if they 
want to support a time domain channel simulation flow, they need to put the 
appropriate Getwave functionality in. Simple.



I don’t think this is any different from the scenario we have had with 
non-repeater AMI models since the beginning. I would rather not see the 
complexity take a step function now for the repeater case.



Thanks,



Ken










Ken Willis   |   Product Engineering Architect – Signal Integrity


P: 860-878-8481     www.cadence.com <http://www.cadence.com/>











From: ibis-macro-bounce@xxxxxxxxxxxxx 
<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> 
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Tuesday, June 06, 2017 12:02 PM
To: ibis-macro@xxxxxxxxxxxxx <mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] Re: Comments on BIRD166.3 and last week's ATM 
discussion



Walter,



To be honest, I am quite confused about your response.



Regarding #1:



How would the EDA tool make a proxy model for Init?  Where would the 
information

come from to do so?  When we talk about a proxy model for GetWave, we can do

that based on the information used or generated by Init, but I don’t see a 
similar

option for a proxy Init function.  Could you explain what you have in mind?



Regarding #2:



I thought we did proxy GetWave functions based on the same model’s Init 
function.

I don’t understand what you mean by making a proxy GetWave “using the other

AMI_GetWave results of those models in the channel that have 
GetWave_Exists=True”.

How could the GetWave function of other devices provide the information for 
making

a proxy model for a different vendor’s part?



Regarding #3:



I don’t understand why you are proposing/hoping to agree on something that 
is

problematic.  I thought your previous suggestion to agree to document the 
flows

for only three model types (Init only, GetWAve only and Dual) was because 
those

were the only non-problematic flows/model types.  If anything, I thought you 
would

hope to agree on that…



Thanks,



Arpad

==================================================================





From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Tuesday, June 6, 2017 4:51 AM
To: Muranyi, Arpad <Arpad_Muranyi@xxxxxxxxxx 
<mailto:Arpad_Muranyi@xxxxxxxxxx> >; ibis-macro@xxxxxxxxxxxxx 
<mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: RE: [ibis-macro] Comments on BIRD166.3 and last week's ATM 
discussion



Arpad,



Your assessment is correct. The sum total of this discussion is that the 
only Redriver flows that we should all be able to agree on is the 
statistical flow when all models have Init_Returns_Impulse=True, and a time 
domain flow when all models have GetWave_Exists=True as defined in BIRD166. 
We should also be able to agree that:

1.      If any model has Init_Returns_Impulse=False, the EDA tool must create a 
proxy AMI_Init function for that model to get statistical results.
2.      If any model has GetWave_Exists=False then the EDA tool must create a 
proxy AMI_GetWave function in order to get time domain results using the 
other AMI_GetWave results of those models in the channel that have 
GetWave_Exists=True.
3.      The implementation of either proxy AMI_Init or proxy AMI_GetWave 
functions can be problematic.



I would be satisfied if the Open Forum passed a resolution agreeing to the 
above statement, and just leave BIRD 166 in purgatory, and not include it in 
IBIS 7.0.



Walter



From: ibis-macro-bounce@xxxxxxxxxxxxx 
<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> 
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Monday, June 05, 2017 9:21 PM
To: ibis-macro@xxxxxxxxxxxxx <mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] Comments on BIRD166.3 and last week's ATM discussion



Hello Everyone,



I decided to write this email to the ATM reflector, so that Walter can also 
respond

(since he will not be able to attend our meeting tomorrow).



This is based on the latest posted version of BIRD166 is draft 5 for 
BIRD166.3:

http://ibis.org/macromodel_wip/archive/20170523/walterkatz/BIRD%20166.3%20Resolving%20problems%20with%20Redriver%20Init%20Flow%20draft%205/bird166.3_draft5.docx
 
<https://urldefense.proofpoint.com/v2/url?u=http-3A__ibis.org_macromodel-5Fwip_archive_20170523_walterkatz_BIRD-2520166.3-2520Resolving-2520problems-2520with-2520Redriver-2520Init-2520Flow-2520draft-25205_bird166.3-5Fdraft5.docx&d=DwMGaQ&c=aUq983L2pue2FqKFoP6PGHMJQyoJ7kl3s3GZ-_haXqY&r=PwYbiL3iX2o1-4U7zFZgCQ&m=RrRoq2jBSWXa8W83gHHFbu8K-f7EXsToGY5JUxV694w&s=OJac4kvunB6QJ1NNlpDS8x9421jVzTqnnS1Iiem-a8o&e=>



The main comment I have is about step 8b, which could be summarized as 
follows:

If any of the GetWave functions are missing, the TD flow relies entirely on 
the Init

functions.  But this will only work if the Init_Returns_Impulse 
parameter=true for

every single Init function.  While the spec does require that 
Init_Returns_Impulse

must be true for a model in which GetWave_Extists=false, there is no 
requirement

or guarantee  that any other model will also have Init_Returns_Impulse set 
to true.

(This statement is actually true even for a regular single channel 
simulation).   For

this reason, the rule in 8b is not guaranteed to work, unless every one of 
the models

has GetWave_Exists=false.  But then we are back to an “Init_only flow” 
executed in

TD simulations.



With that, I wonder if having 8b in the spec helps to solve anything...



Having said that, if we decided to remove 8b from the BIRD, the only 
remaining question

seems to be whether we should go with the idea of “only document the three 
cases”

(Init only, GetWave only and Dual models) and say that do all other 
combinations “at your

own risk”.  If we all agree with that, we could  be done.  (But this is a 
mild way of saying

that we really don’t support any other cases).  Otherwise the only way I see 
out of this

situation is to do something along the lines of Fangyi’s proposal (or its 
variants, i.e.

execute Init multiple times, etc…) as the solution.



Comments, questions, suggestions are welcome…



Thanks,



Arpad

=======================================================================



JPEG image

JPEG image

Other related posts:

  1. Home
  2. ibis-macro
  3. Archive
  4. 06-2017