Minutes from the 16 June 2015 ibis-atm meeting are attached.
IBIS Macromodel Task Group
Meeting date: 16 June 2015
Members (asterisk for those attending):
ANSYS: * Dan Dvorscak
* Curtis Clark
Avago (LSI) Xingdong Dai
Bob Miller
Cadence Design Systems: * Ambrish Varma
Brad Brim
Kumar Keshavan
Ken Willis
eASIC * David Banas
Marc Kowalski
Ericsson: Anders Ekholm
IBM Steve Parker
Intel: * Michael Mirmak
Keysight Technologies: * Fangyi Rao
* Radek Biernacki
* Nicholas Tzou
Maxim Integrated Products: Hassan Rafat
Mentor Graphics: John Angulo
* Arpad Muranyi
Micron Technology: * Randy Wolff
Justin Butterfield
QLogic Corp. James Zhou
Andy Joy
SiSoft: * Walter Katz
Todd Westerhoff
* Mike LaBonte
Synopsys Rita Horner
Teraspeed Consulting Group: Scott McMorrow
Teraspeed Labs: * Bob Ross
TI: Alfred Chong
(Note: Agilent has changed to Keysight)
The meeting was led by Arpad Muranyi.
------------------------------------------------------------------------
Opens:
- None
--------------------------
Call for patent disclosure:
- None
-------------
Review of ARs:
- Mike LaBonte to post Walter's "C_comp in IBIS" presentation.
- Done.
-------------
New Discussion:
- Arpad: I anticipate a motion to untable the optimization topics.
- Ambrish, are you prepared to discuss Walter's proposal?
- Ambrish: We have not yet had a chance to discuss it.
- Many people on vacation.
- Will probably have to wait until after our July 4th shutdown.
- Arpad: I'm eagerly awaiting feedback.
- Arpad: Next topic, Redriver Flow?
- Walter: No update on Redriver Flow.
- Discussion point is that it gets complicated.
- My rules work in special cases, but can't be generalized.
- Is the section normative or informative?
- Two flows:
- One is in the approved spec.
- One I revised for a specific set of conditions.
- Either way, the [Model] does the exact same thing.
- Up to the tool vendor to tell customers which flow it follows.
- Fangyi, your opinion?
- Fangyi: I'd prefer to work out a flow that works for all the complex cases.
- I have an idea, but haven't yet had a chance to discuss it with others.
- We've been working on PAM4, but can come back to this now.
- See if we can find a more general solution.
- Walter: I think we're saying neither Keysight nor SiSoft is in a rush.
- We can keep it on the table for now.
- Arpad: Just to be clear, it is not currently tabled.
- Walter: Motion to table the Redriver Flow topic.
- Fangyi: Second.
- Arpad: Anyone opposed to tabling the topic? [none opposed]
- Arpad: No other topics are currently on the agenda.
- Anyone have a motion to untable another topic?
- Walter: I have an interesting new topic to discuss.
- Arpad: Okay.
- Walter: For the AMI Flow:
- What analog model do I use to generate the impulse response of the channel?
- We have the words "leverage the IBIS constructs" in the AMI section [10.1].
- Difficulty is that an IBIS [Model] is not necessarily linear.
- AMI wants a linear [Model].
- There is some interest in having a requirement that if a [Model] has an
[Algorithmic Model] then the analog portion of the [Model] must be LTI.
- Another point brought up was that it should reflect the actual analog
properties of the buffer, not only impedance but return loss.
- Accurately represent what the buffer is doing, and have tools interpret it
consistently.
- Ambrish: I want to make it a bit more general.
- We had a lively discussion on the reflector.
- Should we come up with a running list of things to address?
- Walter: Exactly so.
- Here is something that's been requested.
- Want to open the discussion of the analog portion of the [Model] and LTI.
- I will put together a presentation or list of items.
- Ambrish, and others, if you could think about how you'd like to constrain
the analog model so it's LTI.
- Input would be appreciated.
- Arpad: I have some general questions.
- How do we deal with this? I see two ways.
- 1. Don't modify existing IBIS keywords.
- Simply use a straight line I/V curve, for example.
- How do we enforce it? Parser flags an error if I/V curve not straight?
- 2. New IBIS keywords for the analog portion of an AMI model.
- Could be made so that they could only represent an LTI model.
- One attempt at such an approach was Walter's idea to have an RC circuit
or touchstone file as the buffer model.
- Michael M: There is a third way. It may be more controversial.
- Come up with a set of recommendations or best practices for linearization
assumptions EDA tools should use given non-LTI data.
- Arpad: That idea was brought up by Scott, but viewed as wishful thinking.
- Michael L: Even if we do an "LTI cookbook," we might still want to consider
Arpad's first suggestion.
- Parser could check for non-LTI information, like the presence of waveforms.
- Fangyi: Do we really want to enforce LTI for the analog model in AMI?
- From a system designer point of view these are all hidden for them.
- If I run an AMI simulation with a dummy .dll that is just a pass through,
and I run it at a low data rate then naturally I would expect the AMI
simulation waveform to match the transient simulation waveform.
- Enforcing LTI in the analog model will introduce discrepancies between the
two waveforms.
- What's wrong with a non-LTI analog model?
- It doesn't scale with increased voltage, but we don't double or triple the
supply voltage in AMI anyway.
- Only issue with non-LTI analog model is the superposition AMI employs.
- When you have highly non-linear IV curves, the interference between
neighboring transitions don't add up linearly.
- Arpad: Another one is that the time variant rising and falling edges would
have to be symmetric.
- Fangyi: Yes, that's another issue, but it's a problem even for LTI models.
- Arpad: If the AMI model's algorithms are mathematically valid only if the
system is LTI, then results could be questioned if the IR was
generated from a non-LTI system.
- Fangyi: LTI has two implications, scaling and superposition.
- AMI only relies on superposition.
- You can still have a non-linear I/V curve, as long as superposition holds.
- Linearizing the I/V curve will make the scaling work, but it's not needed.
- David: We may not want to take out the information that is there now.
- Model makers can look at where they expect the common mode voltage to be on
average and take the impedance of the driver based on that.
- Impedance of a real CMOS driver, of course, is not constant.
- If we force linearized curves we take away that information that might be
being used right now to the proper effect.
- Fangyi: Yes.
- Walter: We are kind of in agreement.
- Issue the end user is having is that for any one simulation you have to
somehow represent that driver as LTI to the AMI model. The approximations
may be good or bad depending on how well superposition and scaling work.
- Each EDA tool will make a different linearizing interpretation.
- Tools could give different results.
- I think that's just the way it is.
- Tell model makers that EDA tools' results might be different if the model
is non-LTI.
- It would be nice to have a test to say this model is LTI or non-LTI.
- Arpad: Another method would be to extend AMI itself to deal with non-LTI.
- Vladimir gave a presentation here in the ATM about six years ago.
- Showed a few ways to include driver non-linearities.
- Posted on ATM website.
- As opposed to enforcing the analog model being LTI, we could address it on
the AMI side by adding non-linear capabilities.
- Fangyi: I think I remember the idea was to have another function call that
allowed the model to capture the non-linear impedance of the circuit
inside the .dll.
- My interpretation is this was like hiding a SPICE simulator in the .dll.
- Not sure placing all the non-linear behavior in the .dll is feasible because
to capture the non-linear impedance you would have to simulate in the SPICE
domain.
- Just like David just mentioned, the model maker can put lots of non-linear
impedance in the analog model.
- Michael M: This may not be common now, but I suspect it will be.
- There are circumstances where you might not want to use the AMI portion of
an AMI capable model for all your simulations.
- You have the analog portion and the AMI portion, and the AMI portion might
not be used in all circumstances.
- Fangyi: Yes.
- We keep calling for LTI with AMI. I think it's misleading.
- As I said before, AMI doesn't rely on all the properties of an LTI system.
- It doesn't need scaling, all it needs is superposition.
- Walter: Isn't scaling just superposition?
- Fangyi: No, not really.
- Walter: Scaling is like adding two of the exact same waveforms.
- Fangyi: Here's a simple example.
- If you have a really low data rate, you can superimpose non-linear rising
and falling edges because they're so far apart they don't interfere.
- In that sense you can have a non-linear analog model and apply superposition
in your waveform.
- David: Aren't we applying scaling when we convolve the channel IR through the
Tx pre-emphasis filter?
- Fangyi: That has some scaling.
- But that is not a ridiculous scaling like 2x or 3x.
- Radek: I see your point about superposition having a sort of limited meaning.
- You can do scaling by a superposition of two identical inputs, but that's
not the point.
- You're talking about bit by bit is the issue that's important for AMI.
- Fangyi: Right, we never put two bits on top of each other in AMI.
- That's when you'd need scaling.
- Arpad: Aren't the tap coefficients actually scaling.
- Fangyi: That's a totally different topic. Analog behavior of the actual
equalization circuit is not even time invariant.
- Walter: I think to summarize:
- It's clear from many people that we can't just require a linear model.
- Need to have a non-linear model to characterize lots of features.
- Each EDA tool can choose how to represent a linear part of that model.
- Will or should IBIS generate a warning if the model is non-linear?
- Arpad: I want to clarify Scott's goals a little.
- Not looking to solve all the problems with non-linearity in IBIS and AMI.
- If he gets a model with non-linearities or some weird C_comp techniques
he gets different results in different tools because they handle this
differently.
- He would like to standardize to achieve the promise of interoperability
and portability.
- He would like an interim solution to limit analog models to be LTI so
this can happen.
- Walter: That interim solution already exists.
- The model maker can generate linear I/V curves.
- Arpad: Scott's argument is that it's not enforceable.
- I'm not sure it would help even if the parser checked.
- Not sure how many model makers run it through the parser and would react if
it failed.
- Walter: The discussion showed that people want to deliver non-linear models.
- So it's not enforceable.
- Michael M: Per Arpad's suggestion:
- We produce two models for every buffer, one linear, one not.
- Or we recommend linearization assumptions all tools should make available.
- Or we give the model author options to specify how it should be linearized.
- Bob: I think we should use the [Model Selector]
- Provide one for non-linear and one for the AMI model.
- Ambrish: But the non-linear vs. linear issue still remains.
- Walter: Model maker can provide an LTI model if they want all tools to agree.
- Ambrish: But is this just an AMI issue or an IBIS issue?
- Fangyi: I don't think the IBIS parser should give warnings about linearity.
- Implies AMI only works with these special LTI analog models.
- Bob: The spec says that in 10.1, the first paragraph.
- Fangyi: We should clarify that.
- AMI doesn't need LTI, only superposition.
- Walter: Actually, all AMI cares about is an impulse response.
- How does the simulator generate the impulse response from the analog model?
- Fangyi: Yes, just describe how you excite the channel for the step response.
- Ambrish: These are just the time domain versions of how to come up with an
impulse response?
- How would you tackle the non-linearities in the frequency domain?
- Fangyi: This is just a general mathematical description of impulse response.
- We use time domain language, but the EDA vendor can choose how to replicate
it in time domain or frequency domain.
- That's the job of the EDA tool, not the standard.
- Walter: What is a job for the standard is that the model should represent the
buffer. Not only its linear impedance, but its return loss.
- Having the correct capacitance affects the impulse response of the channel.
- How do you put into the IBIS standard that this model really represents
what is happening?
- If you have a very short rise time and small capacitance, then some
simulators have trouble.
- If the buffer does reflect the actual return loss, then everything should
be okay, but you can otherwise get extreme rise times that cause trouble
for some simulators.
- But how do you check for quality of models?
- Arpad: Would we even want to do this?
- Even if we want the parser to check this, in the past we've had the parser
avoid checking content and only check syntax.
- Fangyi: I'm against it for the reason you just mentioned.
- Also because it implies AMI requires a linear I/V curve, which is not true.
- Walter: Someone could write a best practices document.
- Write the model this way, and you ensure it is LTI and tools will give the
same results.
- Fangyi: That's not the best practice.
- Michael L.: Circling back to Arpad's second suggestion:
- Have a separate LTI representation of the model.
- Parameterized circuit or a touchstone.
- What if we had a regular non-LTI analog model, plus an LTI representation
that could be used to create the channel response? Would that be okay?
- Fangyi: That gives you the impression you need an LTI I/V curve.
- Michael L: Are you also saying that even if an LTI version is needed, the tool
should be generating it, not a single one being provided by the
model maker?
- Fangyi: I don't think we should be encouraging linearization.
- Arpad: You've said a few times that we don't need a linear I/V curve.
- Scott made a few statements in his emails that a buffer's impedance should
be the same whether it's in the high state or the low state.
- Bob responded saying that in certain buffer types the impedance could be
different in different states.
- Scott seemed to indicate that the buffer impedance should be the same
whatever state it's in because the reflection coefficients will be
different.
- Why would you think a non-linear I/V curve would still work under these
conditions?
- Fangyi: If your device has a constant impedance at high and low state,
then why do we need a non-linear I/V curve?
- What is Scott asking for?
- Arpad: Scott is asking for a constant impedance regardless of what high
or low state or what voltage it's at.
- Fangyi: In the analog model?
- Then why does the IBIS buffer have an I/V curve in the first place?
- Arpad: How would you describe the impedance of the buffer without an I/V
curve?
- Fangyi: Why did IBIS go with an I/V curve instead of constant impedance
value?
- Bob: Because that's the way the buffer looks.
- Fangyi: Yes, exactly, the impedance is not a constant.
- So what Scott's saying is not true, right?
- Arpad: Scott is saying that for AMI purposes the I/V curve should be a
straight line.
- You're saying a non-linear I/V curve is still okay for AMI purposes.
- I'm trying to figure out the difference of opinion.
- Walter: It depends on the length and loss of the channel.
- I'm sure I can pick a test case where linearity is very important.
- Arpad: Scott made the point that we usually focus on long lossy channels where
lots of these effects get washed out.
- He's working with short channels with small losses where there's a lot of
of ISI bouncing back and forth, especially if terminations aren't perfect.
- In those situations it's extremely important.
- Fangyi: In that case, superposition doesn't apply.
- You shouldn't run AMI, you should run transient.
- Walter: Fangyi is absolutely right, you should run time domain.
- Arpad: Walter, since you brought up this conversation, where should we go?
- Walter: There has just been a lot of conversation about quality of models.
- Different results from different simulators?
- Models that are non-compliant.
- General topics to talk about today and think about.
- Arpad: Do we need to do anything, BIRDs, etc.?
- Fangyi: One thing we discussed was clarifying the impulse response section.
- Arpad: You would want to clarify the AMI intro section?
- Walter: Maybe a guide on how to deliver buffer models that are linear.
- Would work consistently across simulators.
- That's not a standard, just a cook book.
- Arpad: Okay, approaching the end of the hour.
- Any other questions or comments?
- Walter: We talked about some group looking at cleaning up GND in IBIS.
- Maybe we can look at that next week.
- Arpad: That's a good suggestion. Let's plan on talking about ground.
- Walter, we could use your draft for the discussion.
- Thanks everyone for joining.
-------------
Next meeting: 23 June 2015 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
