[ibis-macro] Re: Response to BIRD-190

  • From: Walter Katz <wkatz@xxxxxxxxxx>
  • To: <Arpad_Muranyi@xxxxxxxxxx>, <ibis-macro@xxxxxxxxxxxxx>
  • Date: Mon, 19 Jun 2017 17:37:43 -0400 (EDT)

Arpad,



The original intent was to allow users to:

1.      Define repeater records in an IBIS file so that an Rx could be paired 
with a Tx to form a repeater
2.      Define two kinds of repeaters, a Retimer and a Redriver
3.      Define the sequence of Init flows and GetWave flows for both Redrivers 
and Retimers
4.      Self-Optimization was always considered for both the Tx2 and Rx2. If 
not, 
why is the input to the Tx2 the IR of the downstream channel? The answer was 
so the Tx2 could optimize itself. For Retimers, the input to the Rx2 was 
just the output of the Tx2. For the Redriver, it was an oversite to not 
include the output of Rx1 in either the input to the Tx2 or the input to the 
Rx2.



No flow is valid unless it incorporates the ability of an Rx to optimize 
itself. AMI specifically supports this because the AMI_Init can return the 
values of AMI parameters such at tap coefficients. There are examples of 
this in the specification (e.g. mySampleAMI on page 210.



Walter



Walter Katz

wkatz@xxxxxxxxxx <mailto:wkatz@xxxxxxxxxx>

Phone 303.449-2308

Mobile 303.335-6156

From: ibis-macro-bounce@xxxxxxxxxxxxx 
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Monday, June 19, 2017 5:13 PM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: Response to BIRD-190



Walter,



In this case, whether the redriver reference flow is correct or wrong seems

to depend on what you want to do in the simulation.  What I am hearing in

this conversation is that the flow is only wrong if the Init function 
contains

optimization.  But if the original intent of the spec did not include such

optimizations, then the flow seems to be OK.



So what was the original intent?



Thanks,



Arpad

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



From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Monday, June 19, 2017 4:04 PM
To: Muranyi, Arpad <Arpad_Muranyi@xxxxxxxxxx 
<mailto:Arpad_Muranyi@xxxxxxxxxx> >; ibis-macro@xxxxxxxxxxxxx 
<mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: RE: [ibis-macro] Re: Response to BIRD-190



Arpad,



Yes, there are reference flows, and the Redriver reference flow is wrong. It 
has an error in it. The error should be corrected because it gives the wrong 
result. I announced that this error existed as soon as I found it. The error 
is there whether Rx2 has a DFE or not. Even if the Rx2 was LTI in your 
definition of LTI (e.g. it has a CTLE that can be changed as a function of 
the IR of the upstream channel).



If the standard gives the wrong answer and if IBIS is unable to correct it, 
then all we can do is document that IBIS 6.1 flow is incorrect, and that 
SiSoft follows a flow that is correct.



Walter



Walter Katz

wkatz@xxxxxxxxxx <mailto:wkatz@xxxxxxxxxx>

Phone 303.449-2308

Mobile 303.335-6156

From: ibis-macro-bounce@xxxxxxxxxxxxx 
<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> 
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Monday, June 19, 2017 4:30 PM
To: ibis-macro@xxxxxxxxxxxxx <mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] Re: Response to BIRD-190



Walter,



What happened to the promise of interoperability and portability?

Also, pg. 177 states the following:







So while the flows are not a requirement, the purpose of them is to

establish something that can be followed to arrive to the same results…

If all EDA vendors can do anything they want, and generate different

results because they feel it is the correct answer, we might as well

kiss the spec good bye…



Thanks,



Arpad

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





From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Monday, June 19, 2017 3:21 PM
To: Bob Miller (APD) <bob.miller@xxxxxxxxxxxx 
<mailto:bob.miller@xxxxxxxxxxxx> >; Ambrish Varma <ambrishv@xxxxxxxxxxx 
<mailto:ambrishv@xxxxxxxxxxx> >
Cc: Muranyi, Arpad <Arpad_Muranyi@xxxxxxxxxx 
<mailto:Arpad_Muranyi@xxxxxxxxxx> >; ibis-macro@xxxxxxxxxxxxx 
<mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: RE: [ibis-macro] Re: Response to BIRD-190



All,



Ultimately, AMI is a specification of the format and syntax of a .ami file 
and what the inputs and outputs are of a DLL. It is important that the model 
makers write DLLs in accordance with the standards defines of their inputs 
and outputs.



It is not a requirement of an EDA tool follow the flows suggested in the 
standard. SiSoft and other companies believe the flow in IBIS 6.1 gives the 
wrong answer, as we stated three years ago. SiSoft uses a flow that gives 
the correct answer, and submitted BIRD 166 to document this.



If other EDA companies state that they are getting the correct answer 
because they religiously execute the flows documented in IBIS 6.1, so be it.



Bottom line is when a customer gets a different results from different EDA 
vendors we can point them to this discussion and they can decide who is 
right, since we cannot.



Walter



Walter Katz

wkatz@xxxxxxxxxx <mailto:wkatz@xxxxxxxxxx>

Phone 303.449-2308

Mobile 303.335-6156



PNG image

Other related posts:

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