[ibis-interconn] Re: Mixed Mode, understanding the simple case
- From: <radek_biernacki@xxxxxxxxxxx>
- To: <ibis-interconn@xxxxxxxxxxxxx>
- Date: Fri, 20 Jun 2008 15:10:33 -0600
Hi Walter and all,
I fundamentally disagree with the Touchstone file imposing any restrictions, or
changes w.r.t. the existing usage, on any external connectivity of the
components for which the Touchstone files are just providing data.
The Touchstone files provide the data, and just the data. Any information on
the actual inclusion of that data is (and should be) specified elsewhere (ICM,
Spice netlists, schematic descriptions of various EDA vendors, etc.). This does
not prohibit the data providers from inclusion of usage-oriented info as
comments right in the file, if they feel it necessary. I cannot imagine that an
existing Hspice netlist would have to be differently interpreted because we add
the [Interconnect Port Groups] to the file. The latter is in contrast to our MM
specification where we want to uniquely calculate the corresponding SE data.
All we are concerned with is that the data is unambiguous. In other words, if
we allow various formats (Z, H, S, MM) we need to make sure the conversion
between the formats is unique.
Radek
________________________________
From: ibis-interconn-bounce@xxxxxxxxxxxxx
[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Friday, June 20, 2008 1:16 PM
To: ibis-interconn@xxxxxxxxxxxxx
Subject: [ibis-interconn] Re: Mixed Mode, understanding the simple case
Vladimir,
No. I think there are three fundamental applications of Touchstone data. They
include active devices, interconnect, and everything else. If interconnect,
then any one port is either a signal port or supply port. Note that a port is
really two ports, one that refers to a row in the Touchstone Matrix, and a
reference node. The reference node is either "0" (a nail buried 6 feet in the
ground), or possibly one of the other "ports" in the matrix. If one generates
the Touchstone file then one knows how to connect the Touchstone file in a
netlist, which ports are at the end of each "connection", which are the
differential ports, .... If one is given a Touchstone file, then one needs to
determine the how to use it. All I am asking for is some standard methods of
describing the ports so that tools can use the Touchstone data programmatically.
So yes, if a transmission line port is measured referenced to a certain plane,
and that plane is a port in the Touchstone file, then I think it would be
extremely useful to know this fact programmatically in the Touchstone file.
Every Touchstone file has some sort of documentation indicating what the ports
are. Why not have a standard way of indicating this in the Touchstone file?
Why do we bother putting signal names in the [Component] section of an IBIS
file? The pin number is all that is required to use the IBIS models.
Why do we put [Diff Pin] records in the IBIS file? A user could read the vendor
spec for the part and figure out which pins are differential, or could look for
comments in the IBIS file.
Walter
-----Original Message-----
From: ibis-interconn-bounce@xxxxxxxxxxxxx
[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx]On Behalf Of Dmitriev-Zdorov,
Vladimir
Sent: Friday, June 20, 2008 3:26 PM
To: ibis-interconn@xxxxxxxxxxxxx
Subject: [ibis-interconn] Re: Mixed Mode, understanding the simple case
Walter,
Do you think the Touchstone format should evolve into something that will
contain ICM and maybe IBIS-type info?
There are many other examples other than coupled transmission lines that may
require some additional definitions. For instance, the groups of ports defined
for a particular pair of planes in the multilayer system (in power integrity
problems) or the system of mutual inductances for which we may want to indicate
co- or counter- oriented coils or something else. Does the touchstone format
have to be extended each time we apply it to something different?
Vladimir
-----Original Message-----
From: ibis-interconn-bounce@xxxxxxxxxxxxx
[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Thursday, June 19, 2008 11:33 AM
To: ibis-interconn@xxxxxxxxxxxxx
Subject: [ibis-interconn] Re: Mixed Mode, understanding the simple case
Vladimir,
This is a fundamental issue that needs to be addressed. When one delivers an
RLGC model its usage is clear. If N=2, then there are two coupled transmission
lines, and the matrix rows and columns correspond to the data for an ordered
list of transmission lines. It is not necessary to deliver a model instance
definition because it is so straightforward.
If someone delivers an s8p (and says it represents two coupled near/far end
differential pair), one does not have the slightest idea of the mapping of the
ports of the s8p with the near end and far end lines and which lines are meant
to be differential. The near/far end association of individual lines is
addressed by "[Interconnect Port Groups]", but the differential pairing is not.
Should the differential paired be indicated, so that tools could intelligently
pair the lines to generate differential and common mode views of the s
parameter data?
If the same s8p was delivered in mixed mode form, how are we going to specify
near/far end. Each EDA tool can generate the s8p and the instance their own
way. How can the same s8p be used in multiple tools. Either the user needs to
read the documentation that comes along with an s8p to determine how to use it
in that tools instance, the person generating the s8p includes an instance that
describes programmatically how the s8p is used, or we add records to the s8p
that allows the tool to programmatically use the s8p.
ICM addresses this by having its own instance format for an sNp, but ignores
reference information.
Regarding:
Again, I do not object placing the ruling topological info into Touchstone but
it seems to me that this may create a serious impact on the way we use
S-parameters in our simulators and will require extra development, not limited
to the Touchstone parser as we initially hoped.
I cannot disagree more. If you generate the sNp, and the instances, then you
can just ignore the additional records. If you get an sNp from someone else
that has these records, you can continue to ignore them and generate the
instance records as you currently do (at least you have a format way to
visually reading these records to help you generate the instance). I suspect
that some tools would use this information programmatically.
Walter
-----Original Message-----
From: ibis-interconn-bounce@xxxxxxxxxxxxx
[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx]On Behalf Of Dmitriev-Zdorov,
Vladimir
Sent: Thursday, June 19, 2008 12:25 PM
To: ibis-interconn@xxxxxxxxxxxxx
Subject: [ibis-interconn] Re: Mixed Mode, understanding the simple case
Walter,
I agree that we can add more smart definitions outlining the usage of the
S-parameter (Y/Z...) data.
However, with such options, we'll need to reconsider some basics about how we
use S-parameters. Historically, the touchstone format was just a way to define
a matrix (frequency-dependent, complex valued, sampled). Matrix is one of the
most universal elements of the parameters description: by itself, it does not
impose any restrictions on its usage. Also, it is a 'uniform' thing and as such
does not possess of any type of 'topology'. When we add mixed mode capability,
we do not alter this approach: by defining the meaning of the vector components
(differential or common mode, or single ended info), we do not restrain the
topology in any way but only tell how to convert this mixed mode or hybrid
definition back into its entirely non-structurized single ended equivalent.
So far it was solely the responsibility of the model instance definition, not
the model itself, to determine the connectivity of the S-parameter block to the
external circuit. By putting some topological definitions into S-model
(touchstone file) we restrict the way it can be connected to the outside. The
conflicts become possible between such model definition and the instance
definition.
The instance definitions can be different from simulator to simulator.
For example, in HSPICE we would use:
Smodel1 N1 N2 N3 N4 gnd smodel = 'name'
to include the 4-port model. Here, N1...N4 are 'upper' pins of each port and
'gnd' is the common ground ('lower' pin).
In ELDO, the same model could be included as:
y4port FBLOCK param: string: touch_file_name.s4p
+ pin: N1p N1n N2p N2n N3p N3n N4p N4n
Here, we have 4 pairs of pins, each one determines the port. Such definition
provides more flexibility because it allows us to assign different reference
pins for different pairs.
Now, if we assume that the ports are somehow grouped in the touchstone file,
this implies that they have to share a common reference and perhaps have some
other specific. If this requirement is a mandatory, we need to verify that the
way the model instance is defined 'properly'. In case of conflict, who will
prevail? Another thing if we consider the info similar to [interconnect port
groups] as purely informative, i.e. for the user, not the software. This of
course can be done informally by using the comment lines.
Again, I do not object placing the ruling topological info into Touchstone but
it seems to me that this may create a serious impact on the way we use
S-parameters in our simulators and will require extra development, not limited
to the Touchstone parser as we initially hoped.
Vladimir
-----Original Message-----
From: ibis-interconn-bounce@xxxxxxxxxxxxx
[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Wednesday, June 18, 2008 4:35 PM
To: ibis-interconn@xxxxxxxxxxxxx
Subject: [ibis-interconn] Re: Mixed Mode, understanding the simple case
Vladimir,
The following syntax:
[Interconnect Port Groups] S(1,2) S(3,4)
Enables a tool to convert single ended data to mixed mode data. This addresses
a channel being measured singled ended, but there are differential rules. Or
are you proposing that if one wants the mixed modes, then the model must be
delivered with mixed mode, and that mixed mode will not be derivable from
single ended mode?
There is nothing that constrains the ordering of the ports.
Port # Port Name
1 D(N+,N-)
2 s(F-)
3 S(F+)
4 C(N+,N-)
Note, that in this scheme. The single ended "ports" are named, and the mixed
mode ports are numbered.
I am not trying to define my scheme, I just want you to be able to demonstrate
that your scheme is equivalent, that one can derive the single ended from mixed
mode, and that we will be able to use these mixed mode touchstone files in an
EMD netlist. Note that a spice netlist has nodes N+, N-, F+ and F-. In order to
have an instance of a mixed mode model, one would need to know what the order
of the nodes in the S element call need to be.
Walter
-----Original Message-----
From: ibis-interconn-bounce@xxxxxxxxxxxxx
[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx]On Behalf Of Dmitriev-Zdorov,
Vladimir
Sent: Wednesday, June 18, 2008 5:26 PM
To: ibis-interconn@xxxxxxxxxxxxx
Subject: [ibis-interconn] Re: Mixed Mode, understanding the simple case
Hi Walter,
The definitions you propose:
Single ended:
[Interconnect Port Groups] S(1,2) S(3,4)
Mixed mode:
[Interconnect Port Groups] DC(1,2) DC(3,4)
Hybrid
[Interconnect Port Groups] DC(1,2) S(3) S(4)
[Interconnect Port Groups] (DC(1,2):S(3),S(4))
are somewhat equivalent to those we considered (up to the syntax) but with the
following difference. First, we do not group single ports in pairs for the
purpose of single ended matrix representation, because this is not necessary.
Second, although we make pairs to define differential and common mode, we do
not require that the order has to be rigidly predefined (in your case as:
D(1,2) C(1,2) S(3) and S(4)). We may also order them as e.g. D(1,2) S(4) S(3)
C(1,2).
Then, the three (or more) port 'differential' components need further
elaboration. The underlying transformations between single-ended and
'mixed-mode' are not precisely defined, at least they did not mature to the
point of becoming conventional knowledge. We know 'how' to convert single to
mixed mode and back for the pairs but not for the groups of more ports. It
looks also that we need to preserve the total number of unknowns when we do the
transformation. How can we replace 3 single ended equations with 4 (3
differential and one common mode)? I think that perhaps we only need 2
differential relations, not 3, because any of them can be expressed through the
other two, but then the question becomes how to choose the redundant
differential component.
Is the mixed mode definition for groups N>2 wide spread?
Vladimir
-----Original Message-----
From: ibis-interconn-bounce@xxxxxxxxxxxxx
[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Wednesday, June 18, 2008 2:55 PM
To: ibis-interconn@xxxxxxxxxxxxx
Subject: [ibis-interconn] Mixed Mode, understanding the simple case
All,
Consider a simple differential line consisting of near end ports N+ and N-, and
far end ports F+ and F-. A singled ended s4p model might have the following
port assignments:
Port # Port Name
1 S(N+)
2 S(N-)
3 S(F+)
4 S(F-)
[Interconnect Port Groups] (S(1):S(3)) (S(2): S(4))
I do understand that mixed mode representation goes beyond near/far end
interconnect, but I will assume this for the purpose of this discussion.
I had earlier proposed the following enhancement to [Interconnect Port Groups]
to allow description of near/far end differential interconnect
[Interconnect Port Groups] (S(1,2):S(3,4))
(S(1,2):S(3,4))is interpreted as Single Ended
port 1 is near end active high
port 2 is near end active low
port 3 is far end active high
port 4 is far end active low
It would be straightforward to convert this single ended s4p to a mixed mode
s4p:
Port # Port Name
1 D(N+,N-)
2 C(N+,N-)
3 D(F+,F-)
4 C(F+,F-)
[Interconnect Port Groups] (DC(1,2):DC(3,4))
(DC(1,2):DC(3,4))is interpreted as
port 1 is near end differential mode
port 2 is near end common mode
port 3 is far end differential mode
port 4 is far end common mode
There is no need to assume near and far end in this context. The following is a
valid representation of both the single ended and mixed mode data:
Single ended:
[Interconnect Port Groups] S(1,2) S(3,4)
Mixed mode:
[Interconnect Port Groups] DC(1,2) DC(3,4)
Hybrid
[Interconnect Port Groups] DC(1,2) S(3) S(4)
[Interconnect Port Groups] (DC(1,2):S(3),S(4))
And three port "differential" is just as easy
Single Ended
[Interconnect Port Groups] S(1,2,3)
Mixed mode:
[Interconnect Port Groups] D12D13C(1,2,3)
[Interconnect Port Groups] D12D13D23(1,2,3)
D12 is differential 1,2
D13 is differential 1,3
D13 is differential 2,3
C is common mode 1,2,3
Why does this not address all of the issues that we have been discussing?
Walter
Other related posts:
- » [ibis-interconn] Mixed Mode, understanding the simple case
- » [ibis-interconn] Re: Mixed Mode, understanding the simple case
- » [ibis-interconn] Re: Mixed Mode, understanding the simple case
- » [ibis-interconn] Re: Mixed Mode, understanding the simple case
- » [ibis-interconn] Re: Mixed Mode, understanding the simple case
- » [ibis-interconn] Re: Mixed Mode, understanding the simple case
- » [ibis-interconn] Re: Mixed Mode, understanding the simple case
- » [ibis-interconn] Re: Mixed Mode, understanding the simple case
- » [ibis-interconn] Re: Mixed Mode, understanding the simple case
- » [ibis-interconn] Re: Mixed Mode, understanding the simple case
- » [ibis-interconn] Re: Mixed Mode, understanding the simple case
- » [ibis-interconn] Re: Mixed Mode, understanding the simple case
- » [ibis-interconn] Re: Mixed Mode, understanding the simple case
- » [ibis-interconn] Re: Mixed Mode, understanding the simple case
