Correction: where I wrote "A two terminal subckt probably would have
Aggressor on both terminals ." I meant a four terminal subckt and both
buffer terminals.
Mike
From: ibis-interconn-bounce@xxxxxxxxxxxxx
[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of Mike LaBonte
Sent: Wednesday, June 01, 2016 2:51 PM
To: IBIS-Interconnect
Subject: [ibis-interconn] Re: Clarification of "Aggressor"
I spoke with Walter, who gave me a refresher on the original intent of
Aggressors. It sort of means "don't use me as a victim because I lack one
or more nearby coupled terminals that could be significant aggressors".
With that in mind maybe AggressorOnly would be slightly more helpful.
But the BIRD lacks any way to express what kind of coupling if any is
present . A ten terminal subckt providing connectivity for five signals
may or may not model coupling between the five signals usable for
crosstalk, we don't know unless we look inside the model. A four terminal
subckt providing connectivity for two signals may or may not model
coupling between the two signals, and although you wouldn't use that for
crosstalk it's still coupling that might be useful for a diff pair. In
both cases the only hint that there is coupling might be the presence of
Aggressor, which ironically means coupling is partially missing! A two
terminal subckt probably would have Aggressor on both terminals, hinting
that there might be coupling that is usable for diff pair simulations,
but don't use this for crosstalk at all. That's fair, but not a great way
to say that model has coupling.
How about if we instead mark the terminals that do have coupling to
neighbors, considered by the model maker to be complete enough to use the
terminal as a victim? And how about a way to mark terminals that have
coupling appropriate for a diff pair? Since the Aggressors field is
positional we could call it Coupling and its possible values could be
XtalkVictim, XtalkAggressor, DiffPair, or None (default if empty).
Examples:
File_TS DQ_single_xtalk.s6p
Number_of_terminals = 6
1 Pin_I/O pin_name A1
2 Buf_I/O pin_name A1 XtalkAggressor
3 Pin_I/O pin_name A2
4 Buf_I/O pin_name A2 XtalkVictim
5 Pin_I/O pin_name A3
6 Buf_I/O pin_name A3 XtalkAggressor
[End Interconnect Model]
File_TS Diff.s4p
Number_of_terminals = 4
1 Pin_I/O pin_name A1
2 Buf_I/O pin_name A1 DiffPair
3 Pin_I/O pin_name A2
4 Buf_I/O pin_name A2 DiffPair
[End Interconnect Model]
File_IBIS-ISS uncoupled_Tlines.iss
Number_of_terminals = 6
1 Pin_I/O pin_name A1
2 Buf_I/O pin_name A1 None
3 Pin_I/O pin_name A2
4 Buf_I/O pin_name A2 None
5 Pin_I/O pin_name A3
6 Buf_I/O pin_name A3 None
[End Interconnect Model]
By the way, in our examples only the buffer terminals are tagged with
Aggressor, and I see no rules about this in the text. The most flexible
approach might be to allow the field on any and all terminal lines, with a
rule that there must be no inconsistency across the buf/pad/pin of a
signal, to be checked by IBISCHK.
Mike
From: ibis-interconn-bounce@xxxxxxxxxxxxx
[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of Mike LaBonte
Sent: Wednesday, June 01, 2016 1:24 PM
To: IBIS-Interconnect
Subject: [ibis-interconn] Re: Clarification of "Aggressor"
Interpreting the draft 23 text, the sentence I am looking for is something
like this:
The presence of the optional Aggressor field on a terminal line signifies
that ...
But before determining what it signifies let's look at the sentence that
comes closest to defining that:
If the terminal is an I/O terminal, then the interconnect to that I/O
terminal may be missing coupling to interconnections that are not included
in this interconnect model
My questions are:
1. How is it not obvious that there can be no coupling to something
that is not in the model?
2. Do we really want the word "Aggressor" used in a negative way? In
other words shouldn't it be used where there is coupling?
3. If we really want to allow Aggressor on any terminal shouldn't
the descriptive text include information about what it means for non-I/O
terminals?
Maybe an image is needed to explain this one. I'm still in the dark.
Mike
From: ibis-interconn-bounce@xxxxxxxxxxxxx
[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Wednesday, June 01, 2016 12:10 PM
To: 'IBIS-Interconnect'
Subject: [ibis-interconn] Clarification of "Aggressor"
All,
The intent is to replace the paragraph in Draft 32, with what was in Draft
23 with additional editorial changes.
In Draft 32
The optional Aggressor field is only allowed on Buffer_I/O Terminal_types
whose [Model] keyword Model_type subparameter entry is one of the Output*,
Open*, I/O_* or 3-state* arguments, to allow driver operation. Connections
to Buffer_I/O terminals may be missing coupling to interconnects that are
not included in this Interconnect Model.
In draft 23 (with editorial changes discussed in the meeting)
The optional Aggressor field is allowed on all terminals. If the terminal
is an I/O terminal, then the interconnect to that I/O terminal may be
missing coupling to interconnections that are not included in this
interconnect model. If a terminal is an I/O terminal and is not an
Aggressor, then the interconnect to that I/O terminal will include
coupling to all (most ?) of its aggressor interconnections.
Walter
Walter Katz
<mailto:wkatz@xxxxxxxxxx> wkatz@xxxxxxxxxx
Phone 303.449-2308
Mobile 303.335-6156
