Minutes from the 13 June ibis-atm meeting are attached.
The following document, which was discussed during the meeting, has been
posted to the ATM work archives and submitted to the Open Forum as BIRD 190.
*DATE* AUTHOR <http://ibis.org/atm_wip/archive-author.html> ORGANIZATION
<http://ibis.org/atm_wip/archive-org.html> TITLE
<http://ibis.org/atm_wip/archive-title.html> FORMATS
13-JUN-2017 Ambrish Varma Cadence Design Systems Clarification for Redriver
Flow (zip
<http://ibis.org/atm_wip/archive/20170613/ambrishvarma/Clarification_for_Redriver_Flow.zip>
)(docx
<http://ibis.org/atm_wip/archive/20170613/ambrishvarma/Clarification%20for%20Redriver%20Flow/Redriver_clarification_BIRD.docx>
)
ID#Issue TitleRequesterDate
SubmittedDate
AcceptedSupporting
Version
190 Clarification for Redriver Flow
<http://ibis.org/birds/bird190.docx> Ambrish
Varma, Cadence Design Systems, Inc. June 14, 2017
IBIS Macromodel Task Group
Meeting date: 06 June 2017
Members (asterisk for those attending):
ANSYS: * Dan Dvorscak
* Curtis Clark
Broadcom (Avago): Xingdong Dai
Bob Miller
Cadence Design Systems: * Ambrish Varma
Brad Brim
Kumar Keshavan
* Ken Willis
eASIC: David Banas
Marc Kowalski
Ericsson: Anders Ekholm
GlobalFoundries: Steve Parker
IBM Luis Armenta
Trevor Timpane
Intel: Michael Mirmak
Keysight Technologies: * Fangyi Rao
* Radek Biernacki
Ming Yan
Maxim Integrated Products: Hassan Rafat
Mentor, A Siemens Business: John Angulo
* Arpad Muranyi
Micron Technology: * Randy Wolff
Justin Butterfield
SiSoft: Walter Katz
Todd Westerhoff
* Mike LaBonte
Synopsys: Rita Horner
Kevin Li
Teraspeed Consulting Group: Scott McMorrow
Teraspeed Labs: * Bob Ross
TI: Alfred Chong
The meeting was led by Arpad Muranyi.
--------------------------------------------------------------------------------
Opens:
- Bob noted that Ambrish's new proposal (see ARs below) should be a new item on
the agenda. Arpad agreed and said this was an oversight.
-------------
Review of ARs:
- Ambrish to prepare a BIRD draft extending the warning about optimization in
Init() to the redriver flow section.
- Done. Emailed to ATM.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
- Arpad: Does anyone have any comments or corrections? [none]
- Mike L.: Motion to approve the minutes.
- Ambrish: Second.
- Arpad: Anyone opposed? [none]
-------------
New Discussion:
BIRD 158.6:
- Arpad: Do we have an update on this?
- Radek: I've been away, there has been no recent activity.
- Arpad: What will this revision address? File naming rules?
- Radek: There have been some email discussions that it will address, including
issues you raised.
- Clarification of issues related to whether package models from the IBIS file
are used or not.
- Bob: We want to be clear that the Ts4file can contain a file reference, not
just a file name. We want to use language related to BIRDs 186 and 189.
- Radek: Yes, we need to expand that to a path beyond the current directory.
- Arpad: When will we have a new version?
- Radek: Let's see the status of BIRD 186. It probably shouldn't be done ahead
of BIRD 186.
- We can probably have a new version to review in a couple of weeks.
- Bob: The file reference part of BIRD 186 is very close to finalized.
Ambrish's BIRD draft:
- Ambrish: [sharing the BIRD draft]
- As I was reading through the repeater section, I thought it was clear that
the regular single-channel flow should be followed for each section of the
channel, once the redriver stuff has been taken into account. (so the
existing warning, on pg. 178 of IBIS 6.1, about optimizing in Init() should
already apply).
- However, I wanted to make sure it's very clear to the model maker or
redriver user that this warning is extended to the redriver flow section.
- [Ambrish's proposal inserted the following warning paragraph, derived from
that on pg. 178, into the repeater time domain flow after step 6.]
Note: The Rx executable model file writer for the redriver and downstream
channels should keep in mind that it is not guaranteed that the impulse
response that is presented to the Rx AMI_Init function will always
include the effects of the Tx filter or any upstream equalization.
Therefore the Rx AMI_Init function may not be able to perform accurate
optimization under all circumstances. For this reason, the parameters of
the Rx AMI_Init function should always default to valid values or have a
mechanism to accept user-defined coefficients and allow the user to turn
off any automatic optimization routines to ensure successful simulations.
- Arpad: To recap from last week's meeting:
- Over the last couple months' discussions, it has become apparent that BIRD
166 would have some technical issues.
- It doesn't fix every case.
- It actually makes some cases worse, as demonstrated by Fangyi.
- Can we come up with a version of BIRD 166 that satisfies everyone?
- Walter then proposed the idea to only document the working cases (all
Init Only, all GetWave Only, all Dual)
- I think this is a mild form of saying we don't support anything else.
- So the question is then, does BIRD 166 solve anything?
- Last week we discussed the possibility of rejecting BIRD 166 and using this
clarifying statement (Ambrish's proposal) instead.
- In email discussions Walter said we should approve BIRD 166, but I'm not
sure which version he was referring to.
- It's decision time as far as I'm concerned.
- Mike L.: Hopefully Walter can be back next week.
- Bob: I thought Walter suggested passing BIRD 166, and including Ambrish's
comments, and including Walter's additional statements about proxy Init()
or GetWave() being problematic?
- I think we could also just accept Ambrish's BIRD and reject BIRD 166.
- If we limit this to Ambrish's BIRD is that satisfactory?
- Arpad: I thought accepting Ambrish's BIRD would remove the need for BIRD 166.
- Fangyi: Yes, that's actually Ambrish's purpose.
- Ambrish: Yes. Saying BIRD 166 solves the redriver flow problem is not true.
- It changes the flow and that has repercussions everywhere.
- That basic optimization problem in Init() exists in the single-channel case
as well, and there's nothing really special about the redriver case.
- I don't believe it's a problem at all because we don't see many models with
optimization in Init(). The warning message is sufficient.
- Fangyi: I agree, the problem already existed in the single-channel flow.
- It's just more prominent in the redriver case.
- That's why my proposal is trying to solve the normal flow, not just the
redriver flow.
- Bob: Just want to note that BIRD 166 is currently tabled.
- Does Keysight support Ambrish's BIRD?
- Fangyi: Yes, this is just a clarification of the redriver section.
- Bob: So it doesn't solve everything, but it doesn't break anything?
- If Fangyi's proposal is adopted in the future, we can adjust this text
if necessary?
- Fangyi: Yes.
- Arpad: Later on, if we adopt Fangyi's proposal, then we can remove this new
warning and the corresponding version in the single-channel flow,
right?
- Fangyi: We would probably rephrase this clarification.
- I also agree with Arpad's observation that documenting certain scenarios
is just another way to disallow other combinations.
- Bob: It doesn't make it illegal, it just cautions that it's at your own risk.
- Fangyi: Also (referring back to Arpad's "AMI Flow Problem Summary" from the
May 30th meeting), you had a bullet point in your presentation about
crosstalk.
- There are indeed problems with crosstalk.
- Arpad: Thanks for confirming. We added "?" to the crosstalk items during the
meeting when Walter said there was no problem.
- Fangyi: One is implementation.
- Using the "self IR" terminology from Arpad's presentation, the fact that
BIRD 166 deprives the EDA tool of the self IR is forcing the EDA tool to
to present the IR of every possible aggressor path in the Impulse Matrix
at once.
- You have to figure out all the possible paths from point A to point B and
include them all in the crosstalk IR portion of the Impulse Matrix.
- In a cascaded redriver simulation with crosstalk, the combinations can
explode exponentially and that matrix size explodes.
- Mike L.: Is there a better approach?
- Fangyi: You allow the self IR, and then it's up to the EDA tool to handle
all the combinations.
- You only have to put the individual channel's crosstalk IRs in the matrix.
- That's also what Ambrish is concerned about, from a slightly different
point of view. He's worried about the signal passing all the way through
all the channels even if you have 100 redrivers. You'd need to get a
cumulative impulse matrix that has everything.
- There's another problem that is more minor.
- Each Init() can only apply its equalization filter to the IR once.
- Imagine if you have a loop where the signal goes through the same device
twice. Then you're doomed if you don't have the self IR. If you force
these cumulative IRs then you can't represent a loop.
- Arpad: It's becoming clear that the only way to handle crosstalk and some of
these other combinations we are facing is to have a solution with both
the self and cumulative IRs.
- Fangyi: Yes, we must have both self and cumulative IRs.
- Discussion of the text of Ambrish's BIRD Draft:
Mike L. asked that Ambrish create the BIRD draft using the latest template
(v 1.3). Ambrish agreed. Radek suggested that it wasn't entirely clear which
Rx the text was referring to, and he suggested using the Rx2 terminology to
make it clearer to a new reader. Ambrish said it was general and applied to
all the Rx models. Radek and Fangyi suggested something like "in particular
Rx2". Curtis said he understood that Ambrish's text was meant to be general
and apply to Rx1 and Rx2. But he noted that in a redriver simulation, given
the current flow, the Rx2 Init() function "will not" see any upstream
effects. Curtis asked if we should somehow highlight this fact, because the
proposed text "it is not guaranteed that the impulse...will always contain..."
could be misleading. For an Rx2 in a redriver, the IR passed to Init()
is guaranteed not to contain the upstream effects (given the current redriver
flow). Ambrish said the goal had been to keep the comment general and that
the flow defined in the spec was not necessarily mandatory. The warning was a
general reminder. Curtis said he was okay with this, and imagined the less
specific language would allow for tools that might follow a BIRD 166 approach
(and convolve in the output of Rx1 Init() prior to calling Rx2 Init()) in some
particular scenarios. Arpad, however, said the point Curtis had raised was
important, and the text should be strengthened to reflect the defined flow
and the fact that the Rx2 Init() would not see any upstream effects. The
group worked on modifying the text in this direction, and arrived at:
Note: The Rx2 executable model file writer for the downstream channels with
Redrivers should keep in mind that the impulse response that is presented to
the Rx AMI_Init function does not include the effects of the upstream
equalization. Therefore, the Rx AMI_Init function will not be able to
perform accurate optimization in the absence of the upstream channel
characteristics and/or equalization effects. For this reason, the
parameters of the Rx AMI_Init function should always default to valid values
or have a mechanism to accept user-defined coefficients and allow the user
to turn off any automatic optimization routines to ensure successful
simulations.
- Arpad: Ambrish, could you take the AR to submit this proposal, with the
modified language, to the Open Forum and the ATM for posting?
- Ambrish: Yes.
Agenda Item #9: New BIRDs from Editorial Task Group
- Arpad: This item has been around for a long time.
- Any updates? Should I remove it?
- Bob: Keep it on the agenda.
- I have no updates. Radek and I have set it aside for now.
- Radek: Motion to adjourn.
- Ambrish: Second.
- Arpad: Thank you all for joining.
AR: Ambrish submit his proposal, with the modified language, to the Open Forum
as BIRD 190 and to the ATM for posting.
-------------
Next meeting: 20 June 2017 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
