Minutes from the 28 July 2015 ibis-atm meeting are attached.
IBIS Macromodel Task Group
Meeting date: 28 July 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:
- Arpad to report to the Open Forum that ATM recommends BIRD 178 be approved in
in the next meeting, and that it be included in IBIS 6.1.
- Done.
- Mike L. to email the Open Forum to schedule the vote for BIRD 178 at the
July 31, 2015 meeting.
- Done.
-------------------------
Review of Meeting Minutes:
- Arpad: Does anyone have any comments or corrections? [none]
- Curtis: I received no feedback via email for last week's minutes.
- Michael M: Motion to approve the minutes.
- Mike L: Second.
- Arpad: Anyone opposed? [none]
-------------
New Discussion:
- Arpad: We currently have only one active topic:
- 7: "How to handle missing min/max data?"
- I have no updates on that topic.
- Arpad: Does anyone want to motion to untable any of the other topics?
- Michael M: Could we get a status update on each of the tabled topics?
- Arpad: We can go through the list.
Item 8: Enforcing LTI-ness of analog models for AMI simulations.
- Arpad: I haven't heard from Scott in several weeks now.
- I'm not sure of his intentions for this.
Item 9: Discuss language corrections regarding "ground".
- Arpad: We decided to table this until IBIS 6.1 is finished and approved.
Item 10: Back Channel and Optimization proposal (SiSoft).
- Arpad: This is waiting for feedback from Cadence.
- Ambrish communicated that he was unable to attend today and hadn't yet made
any progress on gathering the feedback.
Item 11: BIRD 147.1 and co-optimization (Cadence).
- Arpad: I separated this from item 10 because we have an official BIRD 147
from Cadence and Walter had given an independent proposal.
Item 12: New Redriver flow BIRD.
- Walter: I have no new progress to report.
- I'm not sure if we need that BIRD and will await Fangyi and others.
- I found a clear error in the flow in the spec under certain circumstances.
- I came up with a new flow.
- Do we need it as a BIRD? I don't know.
- Arpad: If there's a new flow, shouldn't the spec say something about it?
- Walter: Not if we just consider it a reference flow.
- Arpad: I'm concerned about that if all EDA vendors can do whatever they wish.
- Walter: The people writing these models make them based on the flow I defined
in the BIRD. Model makers are doing it that way.
- Arpad: There's a flow in the spec and a flow in the BIRD.
- The flow in the BIRD needs to be approved or rejected.
- Walter: The BIRD is there now.
- If it gets approved, that's fine.
- I don't want to put more effort into pursuing that approval.
- Radek: The BIRD doesn't solve all the issues, particularly if you have a chain
of repeaters.
- The question is whether there should be some guidelines related to some of
the specific cases, so people understand them and know how to write models,
as Walter said.
- Bob: We need to discuss this further.
- If the flow in the spec is wrong, then we have a problem.
- Walter: To answer Arpad's original question:
- SiSoft is prepared to have those discussions, but I'm not going to actively
pursue the BIRD's approval.
- Someone else may want to pursue it with modifications like Radek suggested.
- Arpad: I believe that when we left it Walter and Fangyi were supposed to have
a discussion on what should be in the BIRD.
- Walter: We did not have those final discussions.
- We got involved in other important things.
- This wasn't my highest priority.
- SiSoft is happy, but if others want it in the spec that's fine.
- Radek wants more in the BIRD, so I'll defer.
- Arpad: I would like to bring it to a close.
- What's the next step?
- Should Radek and Fangyi come back with more suggestions?
- Radek: Yes, we can try to look at it. People are busy.
- The issue is likely that things get too complex in certain scenarios.
- Arpad: To answer Michael's original question, this BIRD is indefinitely
tabled until people free up.
Item 13: C_comp improvements.
- Randy: This is waiting until the interconnect proposal is finished.
- Much of this depends on the language in the interconnect proposal.
Item 14: BIRD 128.
- Radek: I was against the idea of BIRD 128.
- I've often said I would rather have a separate API rather than hacking the
existing GetWave() functionality.
- I would be happy to fold a separate API into BIRD 147 or SiSoft's proposal.
- I don't see a future for BIRD 128.
- Walter: I worked very hard to make the backchannel proposals I did compatible
with BIRD 128.
- BIRD 128 was what Cadence and SiSoft did when we started this years ago.
- I'd be willing to accept your proposal to drop BIRD 128.
- Then we could just move ahead with my proposal.
- We already have an API for a new Init() and we can add one for GetWave().
- It would be easy to update my proposals with a new API for GetWave().
- We could adopt my proposal for replacing BIRD 147. It does everything
Cadence wants and everything everyone else wants.
- Arpad: Will you formalize a BIRD?
- Walter: I made the presentation.
- If this group wants to move forward, I'd be happy to write up a BIRD.
- Giving up being compatible with BIRD 147 would simplify it.
- Radek: I think the idea was that Ambrish was supposed to come back with
some feedback, but we haven't seen it yet.
- Walter: Ambrish said their IC people aren't pushing them.
- Doesn't sound like that feedback is going to happen.
- Arpad: It has been over six months now.
- How long do people feel we should wait for the feedback?
- I don't want this wait period to stall progress.
Item 15: Info, Out, InOut BIRD.
- Arpad: This is ancient. I think we've had two new revisions of the spec
since this topic came up.
- I will take the AR: to see if it's even valid anymore.
Item 16: DLL error trapping and return codes.
- Arpad: Greg's proposal is also ancient.
- Michael M: Is this in part being addressed by the quality task group and
some .dll checking they were discussing?
- Radek: It was partially addressed by some other BIRDs.
- Arpad: A similar topic was on the reflector a few months ago.
- Mike L: Greg was talking about the generic finger pointing problem.
- Michael M. was referring to efforts to come up with a tool that does a
little bit of inspection.
- It has come up in the Open forum recently, too.
- Hard to see us making too much progress.
- It would involve a fair amount of code development.
- Michael M: Someone on this call [David] has developed a free probing utility.
- .dlls aren't totally opaque.
- Are certain functions present?
- Are they at least minimally conforming to expectations?
- Does the existence of this tool address Greg's problems?
- Do we need to put that in the official parser?
- Arpad: We have had discussions in the past about the parser checking the .dll.
- Should I send an email to Greg?
- Michael M: I motion that Arpad email Greg.
- David: Second.
- Arpad: Anyone opposed? [none]
- Mike L: In one of the quality meetings we presented a list of checks that
could be done.
- We could schedule to look at that in one of the ATM meetings.
- Arpad: I was thinking the opposite. Perhaps quality could take this?
- Mike L: Quality usually consists of Bob and Lance and myself.
- Even if we were to do this in the parser, or python, etc., it helps to
start with a spec for what we want to do.
- Arpad: When do you want me to schedule it in this group?
- Mike L: Next week would work.
- Arpad: I'll email Greg and we can decide depending on his response.
Item 17: Macro models for power delivery.
- Walter: I was saying you can represent the time dependence of a power supply
with spectral density.
- Therefore, handle power variations either statistically or that spectral
content can generate a power waveform.
- No one has gotten excited about it, so we can remove this from the list.
- Arpad: Is this useable for AMI purposes?
- Walter: It could be used for AMI purposes. Rail voltage has direct frequency
content on amplitude noise of the generated signal.
- Arpad: I ask because that time varying waveform would violate LTI.
- Walter: For statistical processing you'd do things like adding sinusoidal
jitter.
- For example, if you knew there was a lot of energy around 50MHz, then you'd
put in sinusoidal jitter at 50MHz.
- Arpad: Could this statistical approach for describing power supplies be
translated into modifying the impulse response itself?
- Walter: You could just modify the input waveform passed into Tx GetWave() and
document that it's now really an analog signal not a digital signal.
- Arpad: Should this topic be left on the list?
- Walter: Unless someone says they have a problem to solve, let's remove it.
- Arpad: I will take this off the list.
New PAM4 Parameters Question:
- Arpad: There are two PAM4 parameters, thresholds and offsets, that are In,
Out,
or InOut.
- So the model could return new values for these from GetWave().
- If the model can return those values, are they supposed to be used real-time
as the EDA tool generates the eye?
- Do we have rules on when the values can be changed or returned?
- Does it make sense for the models to return those values instead of having
them in the AMI file?
- Walter: Yes.
- In practice, after a certain number of ignore bits are processed, the timing
offsets and thresholds settle out and those are the ones that you use. They
might change from call to call.
- The EDA tool can accumulate that information as it sees fit.
- Arpad: So should the EDA tool process the eye using the values from one
GetWave() call to the next?
- Walter: EDA tools can do creative things and differentiate themselves.
- IBIS should just describe a model and what it returns.
- Arpad: So the answer to my question is, "yes, it makes sense for the model to
return the values."
- Arpad: Any other discussions for today's meeting? [none]
- Thank you all for joining.
AR: Arpad to investigate the current relevance of tabled item 15.
AR: Arpad to email Greg Edlund to ask about his current thoughts on his DLL
error
trapping topic (item 16).
-------------
Next meeting: 4 August 2015 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
