Minutes from the 02 June 2015 ibis-atm meeting are attached.
IBIS Macromodel Task Group
Meeting date: 2 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:
- Curtis Clark to take the minutes.
--------------------------
Call for patent disclosure:
- None
-------------
Review of ARs:
- Walter to send AMI directionality recommendations from previous meeting to
the list.
- Done.
-------------
New Discussion:
- Arpad: Michael M., would you like to discuss the directionality BIRD?
- Michael M: Yes.
- I would like to request that the document I sent out be available on the
work archive site.
- AR: Mike LaBonte to post it.
- Thank you everyone for all the feedback.
- Big changes in this version.
- Added the Executable_Tx and Executable_Rx.
- Removed the direction parameter.
- Reintroduced the one [Algorithmic Model] keyword per [Model] restriction.
- Changed the Title to better reflect the final proposal.
- Changed the Statement of Issue based on Bob Miller's comments.
- This version adds Executable_Tx and Executable_Rx to [Algorithmic Model].
- Requirement: I/O type models must have at least one Executable_Tx and at
least one Executable_Rx Sub-Params.
- Their fields are identical to the existing Executable Sub-Param.
- Revised the tables re: reserved parameters and their directionality.
- Examples changed.
- Should we allow Executable_Tx for 3-State [Model] types?
- It could be clear from context if we just keep the existing Executable.
- Bob: I prefer using Executable only.
- If you have Executable_Tx, then this 3-State type becomes an exception
in that it has no Executable_Rx.
- Would simplify the parser's job.
- Michael M: No problem, I understand. I'm happy either way.
- Walter: Implication here is that if you have an I/O you need a Tx and an Rx?
- Michael M: Correct, you need at least one Executable_Tx and Executable_Rx.
- Walter: Say I have a DDR4 DQ on a controller.
- It might have Tx equalization, and it might not.
- It might have Rx equalization, and it might not.
- So it could have just Tx or just Rx equalization.
- That was the impression I got from some statements you [Michael M.] made
about the application of this to DDR4 controller buffers.
- Did I understand that correctly?
- Michael M: Yes, it is possible to just have one.
- Walter: In that case, I think we should allow either one or both.
- Michael M: In that case, we are setting up a situation where:
- If Executable_Tx exists, but Executable_Rx does not exist then we are only
using the analog portion of the buffer in the simulation for Rx simulation.
- Walter: For a controller example:
- Reads might have equalization if you have a CTLE or DFE.
- Writes may not if it did not have an FFE.
- Writes would be analyzed the traditional IBIS way.
- Michael M: Okay. That's a fairly easy change to make.
- Walter: One other comment:
- I thought last week we agreed to use Executable underscore Tx [these minutes
have used this form - Executable_Tx, Executable_Rx].
- Arpad: Walter is correct.
- Michael M: [will change BIRD to add the underscore]
- Bob: I hear Walter's point.
- But what would be the problem of having Executable_Tx and Executable_Rx if
one is a straight-through no equalization?
- Walter: If you have an AMI model, the implication is AMI processing.
- In the example I gave the Tx may not have an FFE.
- So in that direction you don't want to do writes statistically with AMI.
- Want traditional modeling in that case.
- Radek: Question is does the flow for AMI processing need to be addressed?
- Does AMI flow need to be augmented to support such a situation?
- Michael M: Yes.
- Because the request here is to ensure the language supports it.
- Arpad: Isn't that a tool vendor decision?
- Radek: We have a clearly defined flow that doesn't address this situation.
- Yes, tool can handle it. But we have a flow.
- Bob: The flow question is a relevant question.
- Arpad: Flow outlines the order things are executed and things pass in and out.
- I don't think it is this BIRD's issue.
- You could set up a simulation with AMI on one side and regular IBIS on the
other without this BIRD.
- Bob: It's relevant to whether we should force Executable_Tx and Executable_Rx.
- It's within the AMI flow.
- Michael M: Would resolving that be a block to approving this BIRD?
- Arpad: That was my point.
- It seems an open question with or without this BIRD.
- We shouldn't force an I/O to have both if it doesn't have the functionality.
- I don't see an issue with correcting that so both are not required.
- Let's make sure this rule wouldn't be misinterpreted for the flow.
- Radek: If we don't require both, it is still okay.
- We are only using one flow direction at a time.
- I think relaxing this requirement is okay.
- Michael M: I have 3 changes to make to the draft.
- Introduce the "_" characters.
- Allow Executable_Tx or Executable_Rx or both.
- 3-State models can't use Executable_Tx (only Executable).
- Arpad: Motion to submit with those changes and recommend approval.
- Mike L: Second.
- Arpad: Anyone opposed? [none opposed]
Enhanced C_comp modeling:
- Arpad: Randy, would you like to discuss the C_comp proposal?
- Randy: Would be nice if people could read it again and give me more feedback.
- Arpad: Let's recap.
- Randy: I think I'm at draft 6 [which is currently posted].
- Idea is to replace C_comp with improved modeling capability.
- IBIS-ISS or touchstone files to describe the capacitance.
- Ability to pass in some values to the model.
- Single values or corner values.
- Several types of models in terms of terminals.
- C_comp hangs off A_signal terminal and connects to various voltage rails.
- Another example allows an extra terminal to be brought out for an analog
receive terminal.
- Series filtering between die pad and input buffer - extra signal
could be brought out.
- C_comp in this case is series, perhaps a series resistance for example.
- Also, two pseudo-differential buffers with a diff C_comp.
- Pos and Neg signal terminals.
- Arpad: You don't need the series aspect to do a differential approach, right?
- Randy: Yes.
- Arpad: Would another picture be good for that case?
- Randy: Yes, I'd like to add that picture.
- [back to reviewing draft]
- Note about the fact that you have to provide the "N+1" reference terminal
when using a touchstone file.
- Required by the BIRD so it doesn't get referenced to node zero or something.
- Arpad: Is it submitted?
- Randy: No.
- Bob: [referring to differential pair series C_comp picture]
- This implies the receiver is true differential, which means [External
Model].
- I think this figure is wrong.
- We don't define I-V and K-T, we define I-V and v(t).
- Randy: In the original discussions v(t) came up.
- v(t) isn't used directly.
- EDA tools have to figure out a way of de-embedding the C_comp model.
- Originally did have the buffers labelled as v(t).
- Bob: Do you use K-T in other pictures? I have concerns about that.
- Arpad: Does the text mention K-T?
- It doesn't, so in that regard we should just change the drawings.
- Randy: We could use the figures as they are and add a statement regarding K-T.
- Or we could remove K-T.
- Arpad: I prefer to remove it.
- Walter: [referring to differential picture again]
- Bob is implying that this applies only to differential [External Model]?
- Arpad: Bob is just objecting to this little true differential triangle shown.
- Walter: I agree the picture is wrong.
- Why can't this C_comp model work with legacy differentials?
- Do we want to support a pseudo-differential, two single ended drivers and
receivers?
- Randy: What I meant to show was more of a pseudo-differential setup.
- That's why the second buffer is shown as an inverted buffer associated
through the diff_pin statement.
- Sort of an implied buffer. Do we need a dashed line around it?
- Arpad: That is not the issue.
- I think Bob was commenting on the receiver symbol being only one triangle.
- Randy: You can have that under receiver thresholds if you put in the
differential receiver threshold keywords.
- Bob: Thresholds, but, we can even do differential timing loads.
- We added Rdiff and Cdiff.
- For this figure, we would still apply this as two pseudo-differential
buffers.
- Arpad: If the triangle represents the I-V and clamp curve based receiver
model, then I agree it has to be two triangles.
- Bob: There are some syntactical changes relative to the interconnect proposal.
- May need to update with that stuff.
- Randy: Yes, it's a bit different.
- I've started to incorporate those changes.
- Do you think we need to finish the interconnect BIRD before finishing this?
- Bob: Yes, or we will be out of sync.
- No urgency for this BIRD since it's scheduled for the release after next.
- Randy: Yes.
- Arpad: How different is this from interconnect?
- Interconnect allows the exact same thing except the new black box would not
be part of the compensation algorithm.
- Bob: C_comp model can work independent of the interconnect modeling proposal.
- Arpad: Wouldn't it be easier to add this to the interconnect proposal?
- If we have a box between the pad and the buffer terminal, and the only
difference is whether the box is part of the compensation algorithm or not?
- Bob: I see your point.
- I'd prefer to keep them separate so the interconnect BIRD doesn't grow more.
- Arpad: If we keep them separate, we should be careful to keep the same syntax.
- Walter: You're absolutely right.
- We could take this C_comp circuit and put it into the package model, and you
could use the optional model name on the terminals, so it would be C_comp
for
a [Model].
- Inside the [Model] your C_comp keyword would be zero, and your v(t) curves
then become the K(t) curves.
- That's a relatively straight forward recommendation.
- One could generate K(t) curves and then put the C_comp circuit in the
package
model. It is one way to do it.
- Randy: That's an important point that you'd have K(t) not v(t) in the [Model].
- Arpad: If we're leaning toward waiting until the interconnect is finished,
should we table this for the time being?
- Randy: I'm okay with that.
- Walter: Motion to table.
- Bob: Second.
- Arpad: Anyone opposed? [none opposed]
- Arpad: I'm hoping next week to get motion on the back channel BIRD.
- I have two entries for optimization and backchannel topics.
- Walter: My proposal for optimization is a different approach.
- I believe it is a superset of BIRD147.1.
- The ball is in Cadence's court.
- If they're okay with it, then BIRD147.1 gets tabled.
- If they're not then we have to adjudicate which direction to take.
- Arpad: I'd like to encourage everyone to take it seriously.
- I'd like to make some progress next week.
- Walter - It's been lingering.
- No one out there was clamoring for it.
- That is about to change shortly, so it is timely now.
- Arpad: Thank you all for joining.
-------------
Next meeting: 9 June 2015 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
