Minutes from the 09 May ibis-atm meeting are attached.
The following documents, which were discussed during the meeting, have been
posted to the ATM work archives.
09-MAY-2017 Fangyi Rao Keysight Technologies Problems in BIRD166 Flow (zip
<http://ibis.org/atm_wip/archive/20170509/fangyirao/Problems_in_BIRD166_Flow.zip>
)(pptx
<http://ibis.org/atm_wip/archive/20170509/fangyirao/Problems%20in%20BIRD166%20Flow/Problem_in_BIRD166_Flow.pptx>
)
09-MAY-2017 Walter Katz SiSoft BIRD 166 Now - Effects on Keysight Proposed
AMI_Init IR Outputs (zip
<http://ibis.org/atm_wip/archive/20170509/walterkatz/BIRD_166_Now_-_Effects_on_Keysight_Proposed_AMI_Init_IR_Outputs.zip>
)(pptx
<http://ibis.org/atm_wip/archive/20170509/walterkatz/BIRD%20166%20Now%20-%20Effects%20on%20Keysight%20Proposed%20AMI_Init%20IR%20Outputs/BIRD166.pptx>
)
IBIS Macromodel Task Group
Meeting date: 09 May 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:
- None.
-------------
Review of ARs:
- Walter and Fangyi to prepare a few slides for the continued discussion of
whether BIRD 166 and the future improvements can be done incrementally.
- Done.
--------------------------
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.
- Dan: Second.
- Arpad: Anyone opposed? [none]
-------------
New Discussion:
BIRD 166.2 Redriver Flow:
- Walter: [sharing his "BIRD 166 Now - Effects on Keysight Proposed AMI_Init IR
Outputs" presentation]
- I think this presentation will just set up Fangyi's.
- [Slides 1 - 6] simply set up the problem BIRD 166 is solving.
- [Slide 7]
- IBIS 6.1 Redriver flow
- 4 devices by 3 choices each: (Init Only, GetWave Only, Dual) = 81 flows.
- New Keysight proposal (assuming Tx will also return an additional IR)
- 4 devices by 5 choices each.
- Additional choices: Init Only with extra IRs, Dual with Extra IRs.
- 4 devices by 5 choices each = 625 flows.
- [Slide 8] Conclusion
- If we don't adopt BIRD 166 for IBIS 7.0, the basic redriver flows will be
broken for the foreseeable future.
- The 81 flows in IBIS 6.1 are a subset of the 625 in the new proposal.
- I don't believe the new proposal would modify that subset of 81 flows, so
we have to fix them anyway.
- The flows with the new proposal will be better, but we still have to deal
with the existing 81.
- Bob M.: Perhaps the only way for the new proposal to solve the issue with the
problematic Init Only models is to require that Init Only models
return the additional IRs.
- Walter: The problem with that approach is the fundamental backward
compatibility rule IBIS tries to maintain.
- If you have an IBIS model of version X, you should be able to change its
version to something greater than X and still have it work.
- The Keysight BIRD explicitly states that we would continue to support legacy
models.
- Fangyi: The case where all the models are Init Only isn't that important.
- If all the models are Init Only, and the channel is linear, then there
wouldn't really be a need for a redriver in the middle.
- Arpad: Is it more common for the redriver to have an Init Only Tx and an Rx
that has GetWave?
- Fangyi: Yes.
- In these more common scenarios BIRD 166 makes things worse.
- Walter: Your proposal doesn't alter those 81 flows, so how is it in conflict
with mine?
- Radek: The difference is that the subset of 81 IBIS 6.1 flows is not changed
in
Fangyi's new proposal and is changed in Walter's.
- When we move forward with the new proposal (625 flows), those 81 flows are
either changed (Walter's BIRD 166) or not changed (we don't adopt BIRD 166).
Fangyi's presentation shows that some of those 81 flows are made worse with
Walter's change.
- Walter: I didn't think that was the case when I reviewed the presentation.
- Arpad: Fangyi is saying Walter's proposal makes some of the 81 flows worse
than if we don't do anything?
- It doesn't make all of them worse.
- Walter's goal was to fix another major problem that yields improper results
and has nothing to do with deconvolution.
- Walter is trying to fix an existing flow problem that causes certain
upstream information not to be considered properly.
- Wouldn't it still be a step in the right direction to adopt his flow?
- Fangyi: Some of the flows addressed by Walter's proposal are not that common,
particularly the all Init Only case.
- It makes the results in some more common cases much worse.
- This entire discussion originated from a downstream model that didn't have
GetWave.
- Because some of the terminal Rx models don't have GetWave, it's quite
common to have a mix of GetWave upstream and Init Only at the terminal
Rx. In this case, the deconvolution problem is made much worse by the
BIRD 166 proposal.
- Ken: Talk of 81 or 625 combinations could get very confusing to people.
- Is it too late, or could we consider down scoping things to only consider
some of the combinations?
- Perhaps we could standardize on some subset of flows
- Fangyi: That's another possibility.
- Arpad: We had a conversation that touched on that question.
- The question was whether we wanted to support Init Only and GetWave Only
models, or only support Dual models.
- I recall there was a clear difference of opinion between Cadence and SiSoft.
- Most people were leaning toward having only Dual models, because that
simplified some combinations, and they were more elegant in certain ways,
but
Ambrish was outspoken about needing Init Only and GetWave Only models, too.
- If we wanted to reduce the combinations, that might be the first thing to
revisit.
- Ken: We might start by saying that it has to be homogenous. All the models in
a path must have Init Only operation or all must have GetWave.
- Radek: But models come from different vendors and we want interoperability so
we have to deal with that.
- Fangyi: Ideally, I would like to see only dual models exist in the world.
- Arpad: That was generally the consensus but Ambrish was quite opposed, so we
didn't continue with that discussion.
- Bob M.: I understand Walter's earlier comments about it being very hard to
disallow things that you allowed in previous versions.
- That being said, I have only built and will only build dual models, even
if my GetWave is nothing more than a simple time convolution of my IR from
Init.
- Fangyi: I agree with Bob.
- The reason we have this discussion is because we have legacy Init Only
models out there.
- Radek: Unfortunately, with AMI developments from 5.1 to 6.0 we already had to
abandon the backward compatibility.
- We discussed options of handling convolution differently, but it didn't
materialize.
- Maybe it's time we make use of the version parameter we have in AMI files
and abandon the idea that you can just take a 6.1 model, change its version
to 7.0, and it should work? Maybe that's an option to resolve this.
- Fangyi: We have a big IC vendor that will only provide Init Only models, and
that's unfortunate.
- It's not easy to convince them to add GetWave.
- Fangyi: [sharing "Problems in BIRD 166 Flow" presentation]
- Discussion: Fangyi's presentation detailed a common scenario in which BIRD 166
changes could cause problems. Consider the case where the downstream Rx2 is
Init Only (noted as often the case for one large IC vendor), and the
redriver's Rx1 has a GetWave() and Tx2 is Init Only (also common). In this
case
the entire downstream portion is Init Only. In such a scenario, a
bit-by-bit GetWave simulation requires an IR that contains only the effects of
the downstream channel (Tx2, channel2, Rx2). This is the IR that is needed
to propagate the output of Rx1's GetWave function to the end of the channel.
With the BIRD 166 flow changes, this IR is no longer directly available to the
EDA tool because the input to Rx2's Init function was changed so that
it also contained the effects of the upstream channel. Attempting to use
deconvolution in this case to extract the right IR makes things worse.
For simplicity assume Rx2 only has DFE. Because the DFE's effect is included
in Rx2 Init's output IR by adding it to the input IR (not convolving with it),
using deconvolution to try to extract the IR for the downstream channel itself
(Tx2, channel2, Rx2) leaves an extra term in it. This term results in
redriver
nonlinearities, noise, and crosstalk effects being improperly amplified by an
amount equal to the upstream channel loss.
- Walter: I understand your example.
- My BIRD 166 flow language is okay if:
- All models are Init Only.
- All models have GetWave.
- Things are broken if they are mixed.
- Fangyi: Yes. The current flow is broken.
- My proposal won't change the legacy flows.
- It won't fix the problems yours fixed, but it won't introduce the jitter
amplification that yours would.
- Walter: Maybe we need to resolve this.
- Ken: Could we define a couple of flows that are solid for now?
- Walter: BIRD 166.2 does that.
- It handles the all Init Only and all GetWave cases.
- Arpad: Could the EDA tool call the Init function two different times if it had
to and solve both problems?
- Walter: That could be one way to do it.
- Ken: Isn't it a practical case to have multiple repeaters in a path, and some
of those channels might have crosstalk aggressors too?
- It's not practical to handle all combinations.
- Fangyi: Yes, when we design the flow we have to consider scalability.
- You can have cascaded repeaters, more aggressors, etc., and combinations
explode exponentially.
- The flow in my proposal is designed to be scalable.
- Once you take care of the four basic combinations, everything else follows.
- Arpad: That's true, but you're not addressing the situation Bob M. described
where the Init() is doing the optimizations even though the model has
GetWave().
- Fangyi: That case is handled by the extra IRs in the new flow.
- Walter: We all agree that if you have an Init Only model it should be trivial
for the model maker to add a GetWave.
- Just take the same IR from the Init and convolve it with the input signal.
- Fangyi: I agree to a point.
- Model developers complain about having to enhance their internal tools if
they
have to validate a GetWave model instead of just an Init Only model.
- There could be some additional work for them to add GetWave.
- My proposal makes minimal changes on the model side.
- Walter: I think Fangyi and Vladimir's proposal for the two additional IRs from
Rx Init() is great, and I want an additional IR from the Tx Init().
- Then the EDA tool can do everything itself.
- I totally support that capability, but it will be years before we can see a
model that uses it.
- It takes a year or two for models to appear once it's approved.
- What do we do for the next year or two?
- Arpad: Thank you all for joining.
-------------
Next meeting: 16 May 2017 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
