Minutes from the 28 February ibis-atm meeting are attached.
The following document, which was discussed during the meeting, has been
posted to the work archive.
*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
28-FEB-2017 Radek Biernacki Keysight Technologies BIRD 158.4 AMI
Touchstonefile Analog Buffer Models draft 2 (zip
<http://ibis.org/atm_wip/archive/20170228/radekbiernacki/BIRD_158_4_AMI_Touchstonefile_Analog_Buffer_Models_draft_2.zip>
)(docx
<http://ibis.org/atm_wip/archive/20170228/radekbiernacki/BIRD%20158.4%20AMI%20Touchstonefile%20Analog%20Buffer%20Models%20draft%202/bird158.4_draft2.docx>
)
IBIS Macromodel Task Group
Meeting date: 28 February 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
Cisco: Seungyong (Brian) Baek
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 Graphics: John Angulo
* Arpad Muranyi
Vladimir Dmitriev-Zdorov
Micron Technology: * Randy Wolff
Justin Butterfield
QLogic Corp.: James Zhou
Andy Joy
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:
- Radek to email Michael Mirmak and ATM regarding BIRD 187.2.
- Done.
- Radek to send out the modified draft of BIRD 158.4.
- 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.
- Radek: Second.
- Arpad: Anyone opposed? [none]
-------------
New Discussion:
Single ended applications of algorithmic modeling:
- Arpad: Fangyi, the group was wondering if you could elaborate on your comments
from the DesignCon Summit. You mentioned that the current AMI
methodology would not handle single ended applications.
- Fangyi: I can summarize two main concerns about the current approach.
- The first issue is common mode.
- The current AMI approach for modeling Tx equalization does not apply to
common mode and does not apply to single-ended signals.
- Arpad: Could you elaborate? So far there has been some consensus that
even though the spec says that for differential models the waveform
must be a difference waveform, there is no fundamental issue with
single-ended waveforms.
- Fangyi: You can't take the same FIR from differential mode and apply it to
common mode.
- That only applies to differential mode.
- The Tx equalizer could affect the common mode signal.
- In addition, depending on the topology, it's possible that not all of the
common mode is affected by the Tx equalization.
- Arpad: How does the equalizer know whether it's processing a single-ended or
differential signal?
- Fangyi: That's the problem. The model doesn't know.
- That's how the current approach breaks down.
- Arpad: Do we need a new parameter to tell the model whether it's getting a
single-ended or differential signal?
- Fangyi: Even that wouldn't be enough, because in some situations the Tx
equalization may only affect a portion of the common mode.
- The current mathematical approach for modeling the filter breaks down.
- Walter: Let's talk about DQ on a memory system.
- That's why all this is being done.
- DQ is a single ended line going between roughly 0V and 1V.
- There is a Vref DQ, so when your DQ is operating it operates around a
voltage.
- DDR3 says there are fixed transition voltages.
- In DDR4 they are floating. These create an eye and the Rx in DDR4 operates
on that eye. In differential the reference voltage is zero. In DDR4 it's
Vref DQ (among other names).
- As long as your Tx equalization is symmetric around that Vref, then AMI
modeling works properly.
- Fangyi: The problem is that the model's equalization could potentially affect
Vref.
- Walter: The silicon could affect Vref during the equalization.
- You're right. If the silicon affects Vref DQ based on equalization then the
AMI approximation is not valid.
- If the silicon is well designed, and does not affect Vref during
equalization, and is symmetric about the final Vref then AMI works fine.
- Fangyi: It's not just about the silicon.
- The Tx model's method of simulating the equalization could potentially
affect the Vref.
- That's certainly the case for the way some of the AMI SERDES models are
written.
- The way we have so much flexibility in the GetWave() flow, the model has to
be written properly or it could affect Vref.
- Walter: Agreed. The model maker has to be very careful. The model maker
knows the situation.
- Fangyi: And also there's the possibility that less than 100% of the Vref is
affected by equalization.
- Arpad: Walter suggested we don't need to do anything because the model maker
will know what they're doing for the situation. I think I heard Fangyi
say something to the contrary, that we do need to tell the Tx model
what it is doing.
- My question is do we need a spec. change for a parameter to tell the .dll
whether it is doing single-ended or differential?
- Fangyi: A parameter is not enough.
- You need more than that. You probably need to change the function
signatures in the AMI specification.
- The second issue is the different rise and fall slew rates.
- It's a well-known issue for single ended signals.
- The pullup and pulldown transistors have different time constants.
- As long as your spec. says there's only one impulse response, then you're
limited to symmetric rise/fall.
- Radek: Basically our LTI assumption.
- Walter: The people doing DQ buffers, on the controller side or the memory
side, understand that.
- They try very hard to make the rising and falling slew rates very close.
- Is that AMI assumption perfect, no.
- Is it good enough to make engineering decisions, yes.
- Fangyi: I disagree.
- So far asymmetry between rise and fall is much more prominent than in
differential I/O, and people are concerned about this.
- Arpad: How could we address this?
- Fangyi: There are many ways to go.
- I think it's too early to talk about how we address it.
- Walter: Fangyi is correct.
- A large asymmetry makes the AMI methodology suspect.
- If the equalization implementation in the silicon or the model affects the
Vref, then he's also correct.
- The assumptions being made today by some IC vendors are that rise/fall
symmetry is close enough and equalization's effect on Vref is small.
- People haven't built silicon yet, so maybe these issues will be too large
and will make AMI analysis suspect.
- Maybe we will need additional things like an IR for the falling edge.
- I'm not sure yet if we will need to worry about it.
- Fangyi: I expect rise/fall asymmetry to get worse at higher data rates.
- Randy: We probably match within 10% on current Si across corners.
- There's at least that kind of variation.
- Fangyi: Quick estimate is that a 10% slew rate difference might lead to a
10% shift in Vref.
- Arpad: I'm trying to decide if we need to address this in the spec.?
- Fangyi: My opinion is yes.
- Walter: I have a comment on AMI Modeling.
- We did not invent AMI modeling. Adge Hawes invented it. SERDES vendors
invented it. If we are going to make changes to AMI to support this, it
should reflect how IC model the simulation in their tools. We should see
I/C vendors driving the process and saying that rise/fall symmetry isn't
valid and we handle it this way.
- Fangyi: Feedback from our IC vendors says we will need to address it.
- Walter: They should drive it.
- They should come to us for a solution if they run into something they can't
solve with the current tools.
- GetWave() only relies on the channel being LTI, and we know that's true.
- GetWave() processing should handle anything Fangyi's been discussing.
- Arpad: I disagree in some sense because, as Fangyi pointed out, the GetWave()
footprint is built on assumptions such as the number of impulse
responses we need. It can handle some non-linearities, but maybe
not everything we might need.
- Walter: GetWave() has nothing to do with LTI. It only says I'm putting this
signal down the channel.
- Fangyi: The issue is that the asymmetric rise/fall information is contained
in the analog model.
- Walter: Yes, that's correct.
- Fangyi: [Fangyi had to leave the call at this point]
- Arpad: Could I ask Bob Miller for his thoughts?
- Bob M.: There was some talk of "poor silicon."
- I think pushing the boundaries the way we are all silicon is starting to
look pretty crummy.
- We are getting close to the place where the original LTI assumptions are
starting to fail.
- With regard to AMI_GetWave(). I'm not quite sure you can precisely do
everything you might want to do in AMI_GetWave() when our channel model
only effectively models the differential propagation through the channel.
The Tx output and Rx input are differential, there's no common mode noise.
- I could almost see lobbying for the ability to enhance GetWave() to do a
full 4 port channel model. Even though the channel was LTI it would model
both the common mode and differential propagation.
BIRD 158.4:
- Radek: [sharing his BIRD 158.4 draft]
- There are a few changes based on last week's meeting:
- Use "4-port parameters" instead of S-parameters.
- Use Ts4file instead of Tstonefile, per Bob Ross's suggestion.
- Arpad: My issue with Ts4file is that I've never seen it anywhere before.
- I can associate it with s4p, but I'm hesitant to introduce another
nomenclature without good reason.
- Radek: I'm not attached to that particular name.
- We can leave that issue and fix it later.
- [continuing review of changes]
- We have the explicit reference to S-parameters only for the mention of the
reference impedance. Otherwise we use "4-port parameters."
- Added the triangular symbols for the local reference nodes.
- Terminals 2 and 4 labeled as "buffer terminals" per Arpad's suggestion.
- I'm not sure this is quite clear enough yet.
- It's not clear if it's pad, pin, buffer, etc. We can think about it.
- Rx diagram - the correct one is on the bottom. The top one still appears
but that's an editorial issue.
- I added one more diagram that shows the full end-to-end flow with packages
external to the 4-port Ts4file.
- It shows the approach that the Tx and Rx packages are included with the
channel.
- I still don't like that completely, so I left a comment that we may want
to address how the model maker may specify that the Ts4file does or does
not include the package.
- As it is now, we sort of leave it to the user, and they may be clueless
about these details.
- That's the summary of the changes.
- Arpad: Given the information here, we might want to reference the on-die
interconnect proposal.
- Radek: It depends on whether we want to use the information inside the IBIS
file. The idea of this BIRD is to have self-contained information
completely present in the .ami file.
- Arpad: Yes, but if you make a special point with the central box in the
figure, "User Setup", that the package may be separate from the 4-port
file, then you might want to indicate on-die interconnects as well.
- If I only look at this picture my next question is, "Where should I put my
on-die interconnect, into the analog model or the package model?"
- Radek: The original intent was for on-die interconnect to be in the Ts4file.
- Arpad: That's true for legacy IBIS models, but with the interconnect proposal
maybe that won't be true anymore.
- Radek: We can think about how we make the connection in the future.
- We have to make it clear because the current solution was that we left it
to the user entirely to figure out if they wanted to use package information
that was in the IBIS file or external to it.
- I think this is still a current weak point of this BIRD, whether we talk
about existing IBIS file information or the future interconnect proposal.
- Arpad: Is this BIRD targeted for the same version of the spec as the on-die
interconnect proposal?
- If so, I would like us to write this BIRD with that new interconnect
proposal in mind. Both are geared toward broadband models.
- Radek: This BIRD is already about on-die interconnect.
- So the new BIRD 189 interconnect models in the IBIS file may go beyond what
you need for this BIRD.
- With this BIRD you would only need the pad-to-pin portion of the package
modeling from the IBIS file. The new BIRD 189 package modeling can have
buffer to pin, buffer to pad, pad to pin, etc., so it might not be
straightforward to specify which part of a BIRD 189 package model to use
with this BIRD.
- Walter: If you have this Ts4file, or if you used [External Model] to specify
the Touchstone file, the terminals shown (2 and 4 for the Tx, 1 and
3 for the Rx) are the buffer terminals. In the existing package models, that
would be where the package hooks up to the buffer. In the new package
modeling it's either where the pin-to-buffer model hooks up to the buffer or
for the on-die modeling it's where it hooks up the buffer.
- We may want an editorial note in either this BIRD or BIRD 189 to state that
terminals 2 and 4 of the Tx, or 1 and 3 of the Rx are the buffer terminals.
- Arpad: Agreed, that's why I asked for "buffer terminals" in the last meeting.
- I'm not suggesting any other technical changes.
- I'm just suggesting the boxes labeled "Package" in the "User Setup" part
of the figure should perhaps say "package or on-die-interconnect".
- Walter: Yes, we could say "Package/Interconnect" and package would imply the
legacy package modeling and interconnect would imply the new BIRD 189
style.
- Radek: Isn't the 4-port data supposed to describe the on-die interconnect?
- Walter: Not necessarily.
- Bob M.: As an IC vendor and model maker:
- We tend to adopt the view that the boundary defined by 2,4 (Tx) or 1,3 (Rx)
is basically the edge of the die.
- The bump capacitance, the top level interconnect, and anything else has
tended to get rolled into the Tstonefile.
- When you're designing ASICs, you're designing the die slice.
- You may not have precise control over the package the model will go into.
- But everything up to the bump is fixed and can be characterized once.
- That die may go into several different package models, even within one
package. For example, if you have 100 slices in one package and each slice
has a different effective physical package model.
- It has been convenient for us to call the die-bumps the boundary between the
Tstonefile and the package model, and to keep the package model as something
separate that can be swapped in at will.
- Arpad: If you have a buffer at different distances from the edge of the die,
wouldn't you sometimes want to make a common buffer model and have a
separate interconnect model that might change buffer to buffer because
the distances are different?
- Bob: For us the slice has the bumps physically on top of it, so all of the
interconnect from the bumps into the actual Tx or Rx is identical from
slice to slice.
- Walter: So, you would ask your package modeler to generate a package model
from the pin to the die pad, but in our new packaging scheme you would
say that was from the pin to the buffer because your buffer is at the
die pad.
- Bob M.: Yes, I think we'd be doing something slightly different than what
you're suggesting would be written into the spec.
- Walter: The spec says you can have a package model that goes from pin to
buffer, or you can split it into pin to die pad and die pad to buffer.
- In your case you would want to package models to be from pin to buffer.
- The models would be done to the die pad boundary, but the terminals would
be pins and buffers.
- Radek: That's what I wanted this drawing to convey.
- Walter: Yes. I think Bob is saying people who do the silicon put their
buffers near their die pads
- Bob M.: Yes, basically you put the die pads on top of the buffers and every
buffer looks like every other buffer.
- Walter: What Arpad described with different distance from buffer to die pad
may not be reality, but if it is there's nothing that prevents them
from having on-die interconnect in addition to this Tstonefile.
- Arpad: I'm not sure we can jump to conclusions that all the silicon vendors
do it the same way that Bob M. described.
- Bob M.: Agreed.
- Walter: I think if you say "Package/Interconnect" in that package box in the
figure it would cover it.
- Radek: That gives additional flexibility if needed.
- Bob M.: I think the part that goes in the Tstonefile is the part that doesn't
change from application to application or from channel analysis to
channel analysis.
- The part that is in the package model and goes into the channel model, which
is what you burden the user with, is because different applications may have
different packages. So you have to have the flexibility to concatenate lots
of things into the user's channel analysis.
- I tend to think that everything you sweep into the algorithmic model and the
Tstonefile are the parts that don't change from application to application.
- The IC vendor wraps up everything that is invariant for every channel
analysis done with that particular buffer.
- Arpad: Do we need to ask Radek to make any changes?
- Radek: I think we post it as is.
- I think we need to decide if we want to go with this proposal.
- I hope we do, but we need to hear from Ambrish and others.
- We can worry about the details then.
- Let's post it and let everyone look at it.
- Arpad: Okay, let's review it.
- Mike L.: I will post it as BIRD 158.4 draft2.
- Radek: Motion to adjourn.
- Walter: Second.
- Arpad: Thank you all for the discussion.
AR: Mike LaBonte to post Radek's BIRD 158.4 draft 2.
-------------
Next meeting: 07 March 2017 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
