Minutes from the 17 October ibis-atm meeting are attached.
IBIS Macromodel Task Group
Meeting date: 17 October 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. Curtis Clark took the minutes.
--------------------------------------------------------------------------------
Opens:
- None.
-------------
Review of ARs:
- Bob Ross to send out his proposed no-pin-duplication rules for BIRD189.
- 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.
- Arpad: Second.
- Arpad: Anyone opposed? [none]
-------------
New Discussion:
BIRD158 Ts4file (Touchstone) file contents (email question from Michael Mirmak):
- Arpad: Michael asked if other types (G, H, Y, or Z parameters) are also
allowed?
- Walter: It can be anything. Anything can be converted to S-parameters. It's
simply a Touchstone file, it's not restricted to S-parameter data.
- The answer to Michael's other question is:
- It must be an s4p (exactly 4 ports).
- Arpad: Yes, if you allowed more than 4 then you'd have to deal with
terminating the extra ports, etc.
- Walter: Agreed, why complicate it?
- Walter: I also commented in my reply that we haven't traditionally had ibischk
verify the correct number of terminals or ports elsewhere. For
example, I don't think ibischk verifies the terminal count of an
IBIS-ISS subcircuit, etc., included in an [External Model].
- We haven't done it before, but it's a fair question to ask if we should.
- Mike L: I think the rule we've used before is that we only write checkers for
files whose format we specify.
- Walter: We specify the contents of Touchstone and IBIS-ISS files.
- A Ts4file is a Touchstone file with 4 ports.
- We could check and make sure it has 4 ports. Is it worth it?
- Arpad: It might be a convenience feature, but seems unnecessary.
- Walter: Agreed. If we did it would it complicate ibischk, and would it be
worth the cost to develop it?
- Mike L: Someone mentioned that Brian Anderson, who wrote the tschk2 parser,
is no longer at Keysight (Agilent). He's not available to work on it
anymore. We got one code dump from him and have never really changed
it.
- Radek pointed out that various EDA vendors have their own parsers already.
- So it's unlikely any new tschk would be adopted the way ibischk is as a
front end for some tools.
- So getting people to voluntarily pay for the tschk is unlikely.
- If we did want ibischk to do some checking on the Ts4file, it should be
minimal port checking but not actually parse it.
- Walter: side note:
- I think Touchstone 2.0 was a major mistake.
- What the industry wanted was Touchstone 1.0 plus per port impedance.
That's it.
- As long as you didn't have the new keyword, then all the existing parsers
out there would still have worked.
- Problem with Touchstone 2.0 is that it was a major rewrite of the parser
you already had, even if you only wanted per port impedance.
- I recommend we say 2.0 was a dead end. Go back and create a 1.1 or
something that only adds per port impedance. Abandon mixed mode
representations, and perhaps consider adding sparse file support and binary
support (but done differently than 2.0).
- Arpad: As for Michael Mirmak's questions about BIRD158:
- We have answers to his questions.
- Since we have a vote scheduled for the next Open Forum meeting, on the 26th,
do we need to scrub BIRD158.6 and make another version BIRD158.7?
- Mike L: [Sharing BIRD158.6 - searching for relevant text]
- The reference to S-parameter, as opposed to Touchstone, only appears in the
Background Information section, as Michael M. had mentioned in his email.
- Arpad: Technically in s4p, the s is for scattering parameters.
- Do people actually change the s in the filename extension if they have
another type of data other than S-parameters?
- Walter: I haven't seen many with anything other than S-parameters, but I've
only seen s in the filename extension. It's one of the data records
in the file that says what the format is.
- Mike L./Arpad: "Touchstone" only appears in a few places in the BIRD, and
always in the context of a file.
- Arpad: Should we add a sentence saying that the Touchstone file can contain
any type of data?
- Mike L: It would probably only be necessary if we were excluding some type,
but we aren't.
- Since the "S-parameter" reference is only in the Background Information,
we can probably just note the change during the vote. Someone may insist
on creating a BIRD158.7.
- Arpad: I would like to correct the Background Information section for the sake
of history.
- Walter: We could do it at the Open Forum meeting and introduce it at the vote.
- I think it will just pass.
- Randy: We haven't received any email pre-votes that would object to this
change.
- Arpad: Can Mike L. take the AR to respond to Michael M.'s question and explain
our course of action? Could you also notify the Open Forum of the
slight changes?
- Mike L: Yes.
C_comp improvements:
- Mike L: These improvements are for the circuit inside the buffer. Is that why
they can't be resolved simply with IBIS-ISS?
- Randy: Yes, it's supposed to be a direct replacement for the C_comp element,
which is in the buffer [Model].
- Mike L: Did you also potentially need an extra node, for Input buffer?
- Could that be an extension of BIRD189?
- Randy: It would create a node where you might have to specify it if you had
changes to the Si_location or Timing_location.
- Mike L: Okay, maybe there's more to it, but I was thinking we have a
location Buffer_I/O in BIRD189, and maybe there could be a Buffer_I
and a Buffer_O.
- Arpad: That's an interesting question. With the C_comp improvement circuits,
would the compensation include this or not?
- If the compensation is not including these, then they could be included
in the on-die portion of a BIRD189 model.
- Walter: We decided that the model would still contain a legacy C_comp. This
"effective" C_comp would be used by the tool to generate the K(t)
tables, but then at simulation time it uses the full improved C_comp
subcircuit.
- Randy: Yes, that's how it's written in the BIRD draft. It may require the
use
of C_comp_corner to provide the effective C_comp.
- Arpad: Then do we need the C_comp subcircuit if a BIRD189 model could put it
in the same place? Couldn't we just put it in the BIRD189 model.
- Walter: No, the V(t) curves are based on everything in the [Model] without the
on-die interconnect. The [Model] has to have everything you need to
generate the data.
BIRD189:
- Walter: We currently have two fundamental issues:
- 1. If you have a pin to pad model, you don't need to also have a pad to
buffer model. Bob Ross disagrees with me on this.
- 2. This no-repeat rule should be limited to victim pins.
- You can't have two models in the same Group that have the same I/O pin
as a victim.
- Arpad: I want to revisit my question about pins that are specified multiple
times, but only as aggressors.
- If I have 10 pins. Say 1 and 10 are aggressor only. Pins 2 through 9 are
victims.
- Say I have two different models for this scenario.
- If the user then wants to do a single channel simulation simulating only
pin 1 or pin 10, they have two choices. They have two models that list
those pins as aggressors, and none that list them as victims.
- Walter: If the person making the model does that and wants to make sure pins
1 and 10 are covered, then they should make another model with those
as victims.
- If you are simulating a particular net, maybe it should be one that's a
victim.
- If that net never appears as a victim, then the model maker understands
there may be an ambiguity.
- Discussion: Arpad suggested that we need some language in the spec to explain,
clarify, or disallow this ambiguity. He noted that the point of the original
discussion was to try to limit any required user selections to those made with
respect to the Group keyword. We want to avoid any other ambiguity that might
result in a selection. Walter said we could add language to the spec stating:
- If a pin appears as a victim, then that model should be used.
- If a pin only appears as an aggressor, and it appears multiple times, then
there is an ambiguity if you want to simulate that pin. The model maker
should not do that if they want that pin simulated without ambiguity.
Arpad reiterated that this is only an issue if the user wants to perform an
uncoupled single-channel simulation on a pin that has only been specified as
an aggressor and has been specified in multiple models.
- Arpad: We also had the questions about signal models vs PDN models.
- Can we have a PDN only model with no signals?
- Walter: Yes.
- Randy, when you do PDN and signaling models for DIMMs, do you have coupling
between them?
- Micron delivers advanced power aware models to customers.
- Randy: For our internal analysis at a DIMM level we use some tools that
provide signal and PDN in the same model. It's not that common.
- Walter: Would you deliver such models to your customers via IBIS?
- Randy: I'll have to investigate and think about that.
- Walter: We allow it in the BIRD189 scheme.
- Arpad: This PDN vs. signal came up in the context of Bob's rules.
- Walter: Say you have a package with coupling between signal and power.
- You generate a big S-parameter from pin to pad with your package extraction
tool, and it has coupling between I/O and power.
- Then you may have a separate PDN only model from pad to buffer.
- You can use them together. I think that works. You end up just having
shorts between all the I/O pad and buffer terminals.
- Randy: I agree. I could see myself delivering just such a model.
- This is a case where you're assuming the on-die interconnect for the
signals is handled with C_comp.
- Walter: You couldn't have the package model go from pin to buffer in that case
because you need the additional on-die PDN model to go from pad to
buffer. So the package model has to go from pin to pad.
-Discussion: Arpad and Walter discussed how models might be grouped in this
type of scenario. Arpad asked how the model maker would organize things if
the goal was to allow the user to independently choose the on-die (buffer to
pad) model and the package model (pad to pin). He asked if you'd have one
group to specify on-die and another to specify the package. Walter said no.
Walter said the model maker would make individual Groups each containing one
of the on-die models and one of the package models. Arpad said he was
concerned about the number of permutations, for example 3 package options and
4 on-die PDN options would yield 12 Groups, but that he actually agreed with
this approach.
- Mike L.: Motion to adjourn.
- Walter: Second.
- Arpad: Thank you all for joining.
AR: Mike LaBonte to notify the Open Forum about the minor edits to BIRD158.6
Background Information.
-------------
Next meeting: 24 October 2017 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
