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

  • From: "Bob Miller" <dmarc-noreply@xxxxxxxxxxxxx> (Redacted sender "bob.miller" for DMARC)
  • To: Ambrish Varma <ambrishv@xxxxxxxxxxx>
  • Date: Mon, 19 Jun 2017 16:40:37 -0600

Ambrish, et. al -

If optimization in the Rx AMI_Init and/or DFE equalization is not to be
officially supported by the redriver flow, then my (classic) Broadcom
colleagues doing Init-only models (their designs are LTI enough that they
only need statistical analysis) do not have a clean, simple statistical
analysis solution* within IBIS-AMI*. (they have a partial-but-clean,
adequate-for-their-needs solution today via EDA vendors who support the
modified flow).

I understand that modifications to the statistical flow impose development
and support burdens on EDA vendors. Modifications to models impose similar
burdens on model makers, whether their models are at this point
spit-perfect-rigorous or creatively-simplified. We got here because model
makers wished to take model architectures which always worked beautifully
(if not "officially") in simple channels under multiple (every?) IBIS-AMI
EDA platform and apply them to redriver channels and some EDA vendors
developed straightforward flows to support that wish.

Regards,

Bob


On Mon, Jun 19, 2017 at 3:53 PM, Ambrish Varma <ambrishv@xxxxxxxxxxx> wrote:

Walter,

Your statement:



“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?”



Is flawed. The reason why Tx2 gets the IR of the downstream channel is
because that is the flow of the regular Tx – Rx channel and let Tx2
equalize on its IR.



I sound like a broken record – but optimization in the Rx Init was
discussed and considered – hence the ‘Note’.



Thanks,

Ambrish.





*From:* ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@
freelists.org] *On Behalf Of *Walter Katz
*Sent:* Monday, June 19, 2017 5:38 PM
*To:* Arpad_Muranyi@xxxxxxxxxx; ibis-macro@xxxxxxxxxxxxx
*Subject:* [ibis-macro] Re: Response to BIRD-190



EXTERNAL MAIL

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

Phone 303.449-2308 <(303)%20449-2308>

Mobile 303.335-6156 <(303)%20335-6156>

*From:* ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@
freelists.org <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 ;<wkatz@xxxxxxxxxx>]
*Sent:* Monday, June 19, 2017 4:04 PM
*To:* Muranyi, Arpad <Arpad_Muranyi@xxxxxxxxxx>; 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

Phone 303.449-2308 <(303)%20449-2308>

Mobile 303.335-6156 <(303)%20335-6156>

*From:* ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@
freelists.org <ibis-macro-bounce@xxxxxxxxxxxxx>] *On Behalf Of *Muranyi,
Arpad
*Sent:* Monday, June 19, 2017 4:30 PM
*To:* 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:



[image: cid:image001.png@01D2E91B.BBE7DFD0]



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 ;<wkatz@xxxxxxxxxx>]
*Sent:* Monday, June 19, 2017 3:21 PM
*To:* Bob Miller (APD) <bob.miller@xxxxxxxxxxxx>; Ambrish Varma <
ambrishv@xxxxxxxxxxx>
*Cc:* Muranyi, Arpad <Arpad_Muranyi@xxxxxxxxxx>; 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

Phone 303.449-2308 <(303)%20449-2308>

Mobile 303.335-6156 <(303)%20335-6156>



PNG image

Other related posts:

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