Minutes from the 07 November ibis-atm meeting are attached.
The following document, which was discussed during the meeting, has been
posted to the ATM work archives.
*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
08-NOV-2017 Arpad Muranyi Mentor, A Siemens Business BIRD 165.1 draft 1 (zip
<http://ibis.org/atm_wip/archive/20171108/arpadmuranyi/BIRD_165_1_draft_1.zip>
)(docx
<http://ibis.org/atm_wip/archive/20171108/arpadmuranyi/BIRD%20165.1%20draft%201/BIRD165_1_draft1.docx>
)
IBIS Macromodel Task Group
Meeting date: 07 November 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:
- Arpad asked if we should consider cancelling next week's meeting because of
the IBIS Summits in Asia. Bob noted that he thought Mike LaBonte was the only
regular attendee who would be at the Summits. Arpad decided we should hold
next week's ATM meeting as usual.
-------------
Review of ARs:
- Bob and Radek to produce a new draft of BIRD189.5 containing the two-column
format for Unused_port_terminations.
- Done.
- Discussion: Arpad noted that this had been done, but he asked if it had been
rolled into a new draft. Bob noted that at a subsequent meeting
(Interconnect meeting last Friday) a vote had been taken to roll back the
two column solution and get rid of per port impedance. Radek said it had
been voted out without further technical discussions, and that he felt we
should discuss it in the ATM meeting since it had been discussed here too.
Arpad said we could continue to discuss it in ATM. Walter suggested that
the decision had been made in the Interconnect meeting, that there was no
reason to discuss it further here, and that it could be taken off the ATM
agenda. Walter suggested someone could reopen the discussion in the future
if they wanted to do so.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
- Arpad: Does anyone have any comments or corrections? [none]
- Radek: Motion to approve the minutes.
- Walter: Second.
- Arpad: Anyone opposed? [none]
-------------
New Discussion:
BIRD165.1:
- Arpad: [sharing BIRD165.1 draft 1]
- BIRD165 was introduced in 2014.
- I've made significant changes to the "Statement of the Issue" section, but
these are non-technical improvements in the wording.
- The "Any Other Background Information" section lists the changes made to
create this draft. It also defines the color scheme:
- green - differences between this and the IBIS spec.
- change tracking (in red) indicates differences between this draft and the
original BIRD165.
- Original BIRD165 was written relative to IBIS 6.0. This version updates the
page number references relative to IBIS 6.1. The text being changed is no
different in 6.1 than it was in 6.0.
- [Circuit Call] keyword section is modified. It gets text duplicating the
parameter passing stuff from [External Circuit].
- Parameters and Converter_Parameters are added as Sub-Params.
- New (duplicated) sections describe what they do.
- Rules for using them are the same as for [External Circuit], except that if
they exist in [Circuit Call] then they override any values in the [External
Circuit].
- Only other change is the modification of the Figure 29 example to include
an example of the use of Parameters (change on pg. 134) in [Circuit Call].
- Walter asked me the purpose of the Parameter "C1_value" that has nothing
following it.
- This is what we had before parameterization was added in in 6.0. This is
the old syntax, where the value wasn't given and it was presumed the tool
would allow the user to enter values for the parameters. Having it in the
example just shows this old syntax is still available, though it doesn't
seem very useful.
- Radek: My only issue is the "C1_value" example Walter brought up, but I
understand your explanation.
- The logic behind this proposal is good. It's good to differentiate between
different instantiations.
- I'm not sure the "will be in effect" (override) is necessary or not, but
when you instantiate a subcircuit you don't have to specify values for all
the parameters in the subcircuit.
- Arpad: With regard to the "C1_value" example:
- I agree with you and Walter that this doesn't make a lot of sense.
- But this was the only thing we had before IBIS 6.0. The idea was that
listing the parameter names would allow the tool to create some GUI listing
the parameters so the user could provide values.
- The reason we added parameter values is that the IBIS file was at least a
place to consolidate and maintain all the values, so the user didn't have
to look up values from all different sources (data sheets, etc.).
- I wondered if we should deprecate that old syntax, but that makes things
more complicated. I felt it was simplest to leave the old syntax, add the
new syntax, and assume people won't use the old syntax if it's not useful.
- Walter: I can conceive of one reason for the old way.
- You may have a subcircuit which has a parameter, but the subcircuit
declaration has a default value.
- The old syntax might be a way to let the user know the parameter exists,
but the default value in the subcircuit should be used.
- Bob: We should just keep the old syntax. If nobody uses it that's fine.
- Arpad: Agreed.
- I will get this draft to Mike for posting to the ATM archives.
BIRD189 - File_TS0 restrictions.
- Arpad: [sharing Radek's email to ATM from earlier in the day]
- Radek: We started discussing this topic at the Friday Interconnect meeting.
- This is a serious issue. The File_TS0 was added for convenience, but it
hasn't been completely thought out.
- BIRD189 allows IBIS-ISS or Touchstone data.
- For Touchstone data, the Sub-param was File_TS.
- For File_TS, the Number_of_terminals must be N+1. N ports are defined
between terminals 1 through N and the N+1 reference terminal.
- IBIS-ISS, and HSPICE and others allow other forms of S-element component
that may have N, N+1, or 2N terminals.
- The N and N+1 forms differ only in what the N+1 terminal is. When only
N terminals are specified, it's implicit that the N+1 terminal is global
node 0. That's the only difference. The user could take an N+1 version
and connect the N+1 terminal to node 0 and get the same thing.
- Now we've introduced the File_TS0 (N terminals).
- What are the consequences of that? Connectivity.
- The problem is that the implicit node 0 is not required to be present
throughout the entire span of the interconnect modeling.
- We have a type of modeling with a number of nodes, which are spanned by
the interconnect models, and then suddenly we could have a component
(File_TS0) which is implicitly connected to a completely different node
outside the set of nodes in the modeled area.
- So this draft is fundamentally flawed.
- The only way this might work in its current form, if we want to keep it,
is the requirement that the data inside the Touchstone file supports the
possibility of that terminal being connected to anything. That really
means that no current is flowing through that implicit terminal into the
internal part of the component.
- I added a statement of this requirement for the Touchstone file used in a
File_TS0 in the third paragraph of my email:
If the same Touchstone file is used for an S-element with N+1 nodes,
then for any loading conditions (the external circuitry outside of the
S-element) and at all frequencies present in the file the current
entering (or leaving) the N+1st node is zero.
- That's the general requirement. This is equivalent to saying that N+1st
terminal of the component is isolated from the rest of the component
internally.
- We don't have that requirement in the current draft. I'm not sure the
parser is capable of checking for it. If the data is not restricted, we
have a problem knowing what any EDA tools will do with it.
- Arpad: The original idea behind adding File_TS0 was addressing the case in
which there are no pins under the [Pin] keyword that are suitable as
a reference terminal.
- We discussed the option of using node 0 in that case, and I suggested the
A_gnd syntax to specify that, but people didn't like that.
- We couldn't come up with a way of specifying node 0 that everyone liked,
so the idea of using the special File_TS0 and stating in the rules that
it is implicitly connected to node 0 was proposed.
- Isn't it always true that the sum of the currents has to be zero, even
if this reference node were connected to a pin on the [Pin] list?
- Wouldn't your restriction be true for File_TS, too?
- Radek: No, in the File_TS case, the N+1st terminal is one of the accessible
terminals connected in the model.
- If you had the N+1 version (File_TS) and didn't connect the N+1st terminal
to anything, then you'd have a problem. But the model maker uses all
N+1st terminals.
- In fact, to address this problem we need to explicitly state that for
File_TS the N+1st terminal is not allowed to be one of the unspecified ones.
- There are consequences to the requirement (specified above for TS0) that
the N+1st terminal is isolated internally from the rest of the terminals
in that S-element. There are very strict and necessary conditions that
lead to the statement I made about the restrictions.
- The fact that the terminal is isolated leads to the non-existence of
the Z matrix, which in turn implies the singularity of the Y matrix.
- Most of the Touchstone files that are out there do not actually meet
this restriction, but that's only a necessary condition.
- Bob: I disagree with the statement that no current would flow through node 0.
- Consider a one port case. Current could flow into terminal 1 and out
through the implicit reference node (node 0).
- Radek: You disagree with something completely different. You disagree that
the Touchstone data for a one port would result in no current flowing
if you connect it to node zero. But if you connect it to a different
node, or change the topology so a different node is your node 0, you
get completely different results.
- Discussion: Radek said that if File_TS0 involved an implicit connection to a
node that might not be available to the rest of the interconnect models, then
the only way to avoid ambiguity and be certain of the results would be the
"no current flowing through the reference terminal" (reference terminal
internally isolated) restriction. Bob thought the other interconnect models
would have access to the same implicit reference node if necessary. Bob said
that he would support adding text explaining that File_TS and File_TS0
models could not be intermingled without risking dire consequences. Radek
said another possible solution was to explicitly add the N+1 terminal in
the File_TS0 case, so that whatever reference it was connected to was made
available to the rest of the interconnect models. Bob noted that BIRD158
models assumed a File_TS0 style common reference. Radek agreed that in
BIRD158 the implied N+1st node is the implicit reference that's used for the
entire channel.
Arpad asked Randy about his experience developing S-parameters for on-die
decap models. Randy said they had tried some one-port modeling approaches,
but generally had better correlation results using a two port model with a
reference to zero.
Bob noted that the spec already contains a statement about possible issues
with power-aware simulations using global node 0. He suggested that we add
more specific guidance about possible issues mixing File_TS and File_TS0.
Bob noted that example 4 in BIRD189.5-draft10 actually contains a mix of
File_TS and File_TS0, and he suggested that the example should be fixed
because model makers should not do that. Walter said he thought model makers
knew enough not to create model configurations that wouldn't work, and that we
needn't spell out any more rules for them. Bob said that if we couldn't
spell out the rules, how could a model maker be expected to do things
correctly?
Arpad again asked what we would do in the case when no pin in the [Pin] list
could serve as the reference, and he again noted that File_TS0 was created for
this situation. He said there should be no need for mixed use of File_TS and
File_TS0, because if a suitable reference pin existed it would be available to
all of the Touchstone models. Bob noted that this was not the only reason for
File_TS0, and he and Walter noted that many model makers distribute Touchstone
models based on the implicit node 0.
- Walter: Motion to adjourn.
- Bob: Second.
- Arpad: Thank you all for joining.
AR: Arpad to send the draft of BIRD165.1 to Mike L. for posting to the ATM
archives.
-------------
Next meeting: 14 November 2017 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
