Hi Bob, Thanks. I agree with your points. One note - that is not of immediate practical importance though - is about specifying RANDOM ORDER (as compared to diagonal order). The former is where the incident and reflected vectors (or any other relevant pair of input and output) have different internal ordering, as indicates the matrix in Ken Wong's example. I think that even if we decide to specify the ordering for such matrix, if would be enough to specify the order for only two vectors: input and output. Each one can be done in a same way we use now in DIAGONAL ORDERING. This would require one more column in your table. Vladimir -----Original Message----- From: ibis-interconn-bounce@xxxxxxxxxxxxx [mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of Bob Ross Sent: Sunday, May 11, 2008 10:44 PM To: ibis-interconn@xxxxxxxxxxxxx Subject: [ibis-interconn] Re: Mixed mode matrix definition Hi Vladimir: You are asking the right questions, and I have given some responses in your text (and probably I am just confirming your assumptions). In fact, I was worried about some of the issues and whether to make some format choices more rigid for clarity. I think we have nearly general capability available through a set of independent, sequential conversions. As you pointed out, SE to SE only n-port transformations are supported for just data reference impedanc and/or re-ordering conversions. Below are some conversions most implementors would consider. Each of the conversions would go through the entire set of n-port data at each frequency. With a sequence of these conversions, the transformation from one format to another should be quite general: RANDOM ORDER <---> DIAGONAL ORDERING (Not supported) The "random order" was shown in Ken Wong's example appears logical, but it requires up to the n^2 explicit data position specification inefficiency compard to "diagonal" port-order formatting below. It also looses the simple vector relationships, as Vladimir has shown. So while this would be a format limitation choice (versus a technical limitation), this RANDOM ORDER conversion would support complete generality and flexability for storing the n-port data. So Ken Wong's example format using an n-port row-by-row sequencing of all Sdd, then Sdc, then Scd, and then Scc data could be supported. However, we propose NOT allowing this. ARBITRARY {S | Y | Z | H | G} <--> {S | Y | Z | H | G} (Not Supported) The conversion would be part of any system, but the # command line requires all the data to be in the same n-port format. DIAGONAL PORT ORDER 1 <--> DIAGONAL PORT ORDER 2 This is just a complete row/column interchange, re-ordering conversion. That is why SE data can be formatted in MM and Generalized MM in any order, using the explicit associations to the orignal SE data ports for both MM and SE descriptions. Note, special cases such as standardized input/output port order groupings (such as for (near-end,far-end) ports could be supported by re-ordered data within the format in a prescribed arrangement. For example, the (near-end,far-end) convention could be by reordered (1,2), (3,4), etc. using the rearranged n-port SE data format. FULL <--> {LOWER | UPPER) This applies only for symmetrical data where SE Xij = Xji for file size reductions and also for computational efficiency. [Matrix Format] {Full | Upper | Lower) supports the final format for the SE data and all transformed n-ports consisting of S, Y or Z data. REFERENCE 1 <--> REFERENCE 2 This converts the data into a new reference impedance. This would apply to SE, MM and any combination within the n-port data. This would also support the (unlikely) pathelogical case where two ports (say 1 and 2) could have different reference impedances, but still need to be expressed in a MM format. Per your questions below, this could be a pre- or post-processing step or both. SE <--> MM This assumes each SE port-pair that is converted to MM have the same reference impedance. The conversion could with the constraint Ri = Rj = 2Rc = Rd/2. SPECIAL CASE CONSIDERATIONS 1-port MM: this would be for SE conversions only?? I do not understand the meaning of "MM" representation for 1-port data or whether it is needed. 2-port ordering: Covered by [Two-Port Order] {21_12 | 12_21} This would be consistent for SE to SE transformations, but have no impact on a MM representation. ---- I do not know if I missed anything. But the proposed syntax actually is quite general for even some unlikely pathelogical cases. In practice most data should be in a well-conditioned form and should not need the reference conversions. Bob Dmitriev-Zdorov, Vladimir wrote: > Hi Bob/ Radek, > > I like your proposal especially putting the (optional) reference > impedance for mixed mode together with port mapping. This makes > interpretation clear. > > Minor questions: > - Do we really need the Port_pos column in this table, or this column > also assumes that the order in which we show the SE_MM_Map may differ > from the actual order of components in the incident/reflected vectors? The Port_pos column is NOT needed, but I added it for format clarity. As we start adding references to SE ports in the SE_MM_Map, it is nice to give the SE port as a data position reference. We could just go through the data sequentially and rely on an separate display tool for this information. This is a convention deviation from the n-port data itself or a keyword like [Reference]. I even would consider adding an optional SE_reference column if needed for clarity (and [Reference] would then not be used) if there are distinct references so that the port associated with each reference is clearly visible rather than extracted from sequence data. > > - If there is no optional impedances given [for certain D/C pairs] but > the numbers in the [Reference] line for those ports are different, does > that mean the error? For example, let everything be the same except for: > [Reference] .1 .1 40 40 50 60 Yes, for this example. The specific reason is that no D/C references are specified and each SE port reference would imply a different pair of D/C default reference values. I am thinking that if a single port requires a specified "Optonal_New_Ref", all entries must be listed. While in practice, the "default" values might be listed redundantly, this eliminates the portential error situation. I would still issue a "Warning" or "Note" for SE port-pairs with different references that are converted to MM format. While technically legal, it is probably unlikely in practice and more likely represents a data entry/editing error. Many pathelogical cases are supported using the REFERENCE 1 <--> REFERENCE 2 converson. However, if the New_Ref column is missing (implying "default" values), then the example you gave should generate an Error. > > - Inversely, if there are optional reference values given for D/C pair, > but the ratio is not 4. Then this means re-normalization is required > before converting into standard. Yes. I believe that by using the REFERENCE 1 <--> REFERENCE 2 transformation as a pre-processing step on the SE data and then as a post-processing step on the generalized data, a set of arbitrary references can be supported. While we are considering the SE representation as initially the n-port reference (and probably most useful for actual simulations), we could apply the Inverse thinking internally to convert a general format with MM data and arbitray references back to a SE format with arbitrary references. > > - If all the Optional_New_Refs are given, do we really need the > [Reference] line then? We could create a set of "inverse default rules" which would eliminate the need for [Reference] under certain conditions. I am leaning toward over-specifying the information to provide some additional cross-checking. That means that all SE [References] (or a new optional Reference column) and all New_Ref information be given unless: (1) Only # R <ref> or 50 ohms default applies for all SE ports (no need for [Reference], or (2) all New_Ref values are the default values with or without [Refenence]. So the inverse of default values would still require [Reference] if the SE impedances are not the same and even if this is redundant. > > - It looks as anyone can define entirely standard matrix in the same > way, as shown below? In this case we indicate that the data is given for > the standard but permuted matrix, possibly renormalized. > > [Mixed Mode Mapping] > ! Port_pos SE_MM_Map Optonal_New_Ref > 1 3 100 ! the default Rd would be 80 > 2 5 ! default is 100 > 3 4 25 ! the default Rc would be 20 > 4 6 ! default is 25 > 5 1 1.0 ! change reference to 1 > 6 2 ! defaults to .1 > Yes, this is an unintended but potentially useful SE re-ordering or re-normialzation capability arising from the format rules. > > - Syntax suggestion: for single ended ports in SE_MM_Map column, shall > we use e.g. SE(1), SE(2) or E(1), E(2) instead just '1' or '2'? This > would make it looking nicer, not to mix with the column Port_pos. I support your suggestion. Also X(1), X(2), .. could be considered where X symbolically just stands for S, Y or Z). > > > - Obvious check for data consistency is to make sure that each pair > D(i,j), C(i,j) presents only once or does not present. If presents, then > ports i and j cannot be used anywhere else including the standard mode. > The numbers in parentheses should cover the range from 1 to N without > gaps and repetitions (except for pairs), where N is the number of ports. Also D(i,j) and C(j,i) could be supported with Warning (the D(i,j) order would be assumed) since a human might manually make an index ordering mistake leaving the intended D(i,j) ordering ambigous. > > Vladimir > > > > -----Original Message----- > From: ibis-interconn-bounce@xxxxxxxxxxxxx on behalf of Bob Ross > Sent: Fri 5/9/2008 11:01 PM > To: ibis-interconn@xxxxxxxxxxxxx > Subject: [ibis-interconn] Re: Mixed mode matrix definition > > Hi Radek: > > I believe the same ordering of incident and reflected waves are preserved. > > A challenge is choosing a format for designating this representations. The > problem is that we are combining some original Touchstone concepts, some > minimal IBIS concepts without trying for consistency throughout. Here is > a conceptual format with an IBIS-like column representation. Consider > a 6-port example: > > [Reference] .1 .1 40 40 50 50 > > [Mixed Mode Mapping] > ! Port_pos SE_MM_Map Optonal_New_Ref > 1 D(3,4) 100 ! the default Rd would be 80 > 2 D(5,6) ! default is 100 > 3 C(3,4) 25 ! the default Rc would be 20 > 4 C(5,6) ! default is 25 > 5 1 1.0 ! change reference to 1 > 6 2 ! defaults to .1 > > Here I have (1) specified port position explicitly as a required > column, and (2) the SE or MM re-mapped location of MM and SE data > where the Map number is the SE port position. Optionally, I have > entered a New_ref. If blank, the default values are assumed. > > So the new locations 1 and 3 contain the MM data of ports 3 and 4, > but with respect to references 100, 25. The SE references were 40, 40 > for the original data. > > For SE data in locations 5, 6, the new MM data uses the default > references and are located in postions 2 and 4. > > The SE port 1 is moved to position 5 and expressed with respect > to a reference of 1 instead of 0.1 > > We may want to insert NA for missing data where the default is > assumed as we do in IBIS, or require filling in all the entries > if the column is needed. > > So this is a general concept of the MM extension that supports > designating the SE ports and also supports re-expressing both > the SE and MM data in terms of different references. > > Bob > > > > radek_biernacki@xxxxxxxxxxx wrote: > > Hi Bob, > > > > I agree with your position. I assume that the diagonal format means > the same ordering of incident and reflected waves in the respective vectors. > > > > I'd support an additional set of MM port reference impedances under a > separate keyword. The default scenario should apply if one is specified > and the other is not. This will also imply specific requirements for the > data (Ri = Rj for the SE case, or Rd = 4*Rc for the MM case). The > default should extend to the case where no [Reference] keyword is > specified - then the option line R should be treated as SE. > > > > The default scenario is relevant if both MM and SE matrices are > present in the file. I think we may re-evaluate our position on whether > to allow MM only data in one file. > > > > Vladimir, > > > > Sorry I overlooked your request for the re-normalization formulas. > They are the same as for the SE parameters. One simple way to express > them is via the S -> Z -> S transformations. Given the S1 matrix and the > R1 vector we express the matrix S2, renormalized with respect to the > vector R2, as: > > > > Z = diag(sqrt(R1j))*(1-S1)^(-1)*(1+S1)*diag(sqrt(R1j)) > > > > S2 = diag(sqrt(1/R2j))*(Z-diag(R2j))*(Z+diag(R2j))^(-1)*diag(sqrt(R2j)) > > > > Here the Z matrix is in terms of the MM voltage and current quantities. > > > > Radek > > > > > > -----Original Message----- > > From: ibis-interconn-bounce@xxxxxxxxxxxxx > [mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of Bob Ross > > Sent: Tuesday, May 06, 2008 2:25 PM > > To: ibis-interconn@xxxxxxxxxxxxx > > Subject: [ibis-interconn] Re: Mixed mode matrix definition > > > > Hi All: > > > > Thank you Vladimir and Radek for technical discussion, and others for > > the technical contributions. This has been very helpful. > > > > My position is > > - Support adding MM or generalized MM/SE syntax > > - Restrict ourselves to a "diagonal" format that we have been > discussing > > with explicit association of D and C entries to the SE ports and > > with arbitrary re-mapped positions > > - Assume the SE set of reference impedances and the Rdiff = 2R and > > Rcomm = R/2 as the default relationships. Also, whether stated > > explicitly or not, this appears to be the common assumption. > > - [Matrix Format] would apply for both SE and generalized formats > > if they are in the same file. > > > > - Possibly consider supporting an independent set of generalized MM > > reference impedances that are different from the default above > > - The MM vector relationships might be more complicated > > - However, the data could also be converted from/to an arbitrary > > MM referece impedance set to/from a set with the default > > reference impedances. > > > > We are open to more discussion and technical consdierations.. We > > also have some choices regarding the exact syntax of this addition. > > > > Bob > > > > Dmitriev-Zdorov, Vladimir wrote: > > > >>Hi Radek, > >> > >> > All I am saying is that we may allow Rd to be different from 4*Rc > >> > >>I have no objections about allowing more general situations as long as > >>it does not considerably complicates the syntax and the > >>parsing/transforming tools. > >> > >> > One possible way: given your Smm data for Zref_mm=[1,2,3,4] you can > >>renormalize the matrix to (Smm)' defined for Zref_mm=[1,4,2,8], for > >>example. The mathematics for such a renormalization is the same as for > >>single-ended S parameters. > >> > >>Although I believe I know the relations, we need to explicitly specify > >>them in the accompanying document (white paper). Can you provide these? > >> > >>Thanks, > >>Vladimir > >> > >> > >>-----Original Message----- > >>From: ibis-interconn-bounce@xxxxxxxxxxxxx on behalf of > >>radek_biernacki@xxxxxxxxxxx > >>Sent: Fri 5/2/2008 3:36 PM > >>To: ibis-interconn@xxxxxxxxxxxxx > >>Subject: [ibis-interconn] Re: Mixed mode matrix definition > >> > >>Hi Vladimir, > >> > >>We should differentiate between the reference impedances and the actual > >>terminations (loadings). > >> > >>Yes, I refer to (1) as the starting point definition. The other is the > >>corresponding definition of the incident and the reflected waves with > >>the respective reference impedances. All I am saying is that we may > >>allow Rd to be different from 4*Rc, similarly to allowing the > >>corresponding port reference impedances in the SE format to be different > >>from one another. Of course, when Rd=4*Rc we get all the nice > >>interpretation that you are talking about. > >> > >>Radek > >> > >> > >>-----Original Message----- > >>From: ibis-interconn-bounce@xxxxxxxxxxxxx > >>[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of > >>Dmitriev-Zdorov, Vladimir > >>Sent: Friday, May 02, 2008 1:55 PM > >>To: ibis-interconn@xxxxxxxxxxxxx > >>Subject: [ibis-interconn] Re: Mixed mode matrix definition > >> > >>Hi Radek, > >> > >>Yes, such transformations are theoretically possible, but isn't the > >>overall issue then too complicated? > >> > >>Another thing. In your previous mail you said: > >> > It looks like all we should to stick to are the mixed mode current and > >>voltage definitions with respect to those for the single-ended ports. > >> > >>Such voltage/current relations are: > >> > >>Vd = V1 - V2 (1) > >>Vc = 0.5*(V1 + V2) > >> > >>Id = 0.5*(I1 - I2) > >>Ic = I1 + I2 > >> > >>Now, assume that the ports are terminated with their normalizing > >>impedances. Then, we can define the differential normalizing impedance > >>as: > >> > >>Rd = -Vd/Id = -2*(V1 - V2)/(I1 - I2). (2) > >> > >>If the SE ports 1 and 2 have identical normalizing impedances R0 then Rd > >>becomes 2 * R0 since V1 = -R0*I1 and V2 = -R0*I2. Similar, with common > >>mode for which we'll get Rc = 0.5 * R0. > >> > >>However, if SE port impedances are different, then the very relations > >>(1) make no sense. Trying to apply the same approach we'll get the ratio > >>in (2) that depends on currents and voltages. > >> > >>That's why I think that if we agree with (1) as basic relations, we > >>inevitably have > >> > >>Rd = 2*R0 and Rc = 0.5*R0. (3) > >> > >>Therefore my opinion is that we should either stick to both (1) and (3) > >>or use more general extensions of both. I don't see how we can always > >>follow (1) but not (3). At least, this could be confusing. > >> > >>Vladimir > >> > >> > >> > >> > >>-----Original Message----- > >>From: ibis-interconn-bounce@xxxxxxxxxxxxx > >>[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of > >>radek_biernacki@xxxxxxxxxxx > >>Sent: Friday, May 02, 2008 1:16 PM > >>To: ibis-interconn@xxxxxxxxxxxxx > >>Subject: [ibis-interconn] Re: Mixed mode matrix definition > >> > >>Hi Vladimir, > >> > >>One possible way: given your Smm data for Zref_mm=[1,2,3,4] you can > >>renormalize the matrix to (Smm)' defined for Zref_mm=[1,4,2,8], for > >>example. The mathematics for such a renormalization is the same as for > >>single-ended S parameters. Then, following the "standard" manipulation > >>you get (Sse)' for Zref[2,2,4,4]. Then, if you like it, you may generate > >>(Sse)'' for Zref=[0.1, 1, 50, 100). > >> > >>Radek > >> > >>-----Original Message----- > >>From: ibis-interconn-bounce@xxxxxxxxxxxxx > >>[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of > >>Dmitriev-Zdorov, Vladimir > >>Sent: Friday, May 02, 2008 11:56 AM > >>To: ibis-interconn@xxxxxxxxxxxxx > >>Subject: [ibis-interconn] Re: Mixed mode matrix definition > >> > >>Hi Radek, > >> > >>Can you show the example of using arbitrary normalizing values? > >>Let us have 4x4 MM matrix and vector components ordered as > >> > >>[D1,2 C1,2 D3,4 C3,4]. > >> > >>The reference impedances are: > >> > >>Rc1,2 = 1 > >>Rd1,2 = 2 > >>Rc3,4 = 3 > >>Rd3,4 = 4 > >> > >>How then you will find the standard S-parameter matrix? > >>I.e. the one that corresponds to vectors [X1 X2 X3 X4]. > >> > >>[My preference would be always using similar values for the same pair] > >> > >>Vladimir > >> > >> > >>-----Original Message----- > >>From: ibis-interconn-bounce@xxxxxxxxxxxxx > >>[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of > >>radek_biernacki@xxxxxxxxxxx > >>Sent: Friday, May 02, 2008 12:00 PM > >>To: ibis-interconn@xxxxxxxxxxxxx > >>Subject: [ibis-interconn] Re: Mixed mode matrix definition > >> > >>Hi Bob, > >> > >>It looks like all we should to stick to are the mixed mode current and > >>voltage definitions with respect to those for the single-ended ports. > >> > >>Thus, as we allow _any_ reference (real) impedances for the single-ended > >>ports we should also allow _any_ reference impedances for the mixed mode > >>waves, without requiring Rc=Rd/4. As for the standard S parameters which > >>can be recalculated to a different set of reference impedances > >>(including those with equal reference impedances for specified pairs of > >>ports), the same applies to the mixed mode parameters - they can be > >>recalculated to those with the ratio of 4 for the paired quantities. It > >>is likely that the prevailing data will preserve this relationship > >>(because of the measurement setups), but it seems unnecessary to > >>restrict this. > >> > >>Radek > >> > >>-----Original Message----- > >>From: ibis-interconn-bounce@xxxxxxxxxxxxx > >>[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of Bob Ross > >>Sent: Friday, May 02, 2008 10:17 AM > >>To: ibis-interconn@xxxxxxxxxxxxx > >>Subject: [ibis-interconn] Re: Mixed mode matrix definition > >> > >>Hi All: > >> > >>I agree with the comments below and with making the Ci,j index > >>ordering the same as Di,j. But we could flag that as a Warning > >>in case it is different and still process it. The reason for > >>the Warning it that the user may have intended to specify Dj,i. > >> > >>Furthermore I am assuming that the normalized S-parameter MM data > >>is represented with the (real only) reference impedance constraint: > >> > >> Ri = Rj, Rdi,j = 2Ri, Rci,j = Ri/2. (1) > >> > >>This leads to the complete set of vector relationships: > >> > >> Aci,j = 1/sqrt(2) * ( Ai + Aj) > >> Adi,j = 1/sqrt(2) * ( Ai - Aj) > >> Bci,j = 1/sqrt(2) * ( Bi + Bj) > >> Bdi,j = 1/sqrt(2) * ( Bi - Bj) > >> > >>A different normalizaton assumption might be: > >> > >> Ri = Rj = Rdi,j = Rci,j (2) > >> > >>This is described in the Ferrero and Pirola paper that Vladimir > >>referenced and this changes the vector relationships to > >>(their eq. 20): > >> > >> Aci,j = (3Ai + Bi - 3Aj - Bj) / 4, etc. > >> > >>Should we require the contraints in (1) to document MM and generalized > >>data in Touchstone? > >> > >>What is the minimal set of reference impedance constraints needed > >>for normalized S-parameter MM pairs? > >> > >>------ > >> > >>Symmetry: > >>Assume for SE data is symmetrical (Xi,j = Xj,i). Assume the > >>reference impedances satisfy (1) for S-parameter normalization. > >> > >>Is the MM and generalized format also be symmetrical about the > >>diagonal? > >> > >>I assume yes. > >> > >>In other words, if [Matrix Format] <Upper | Lower> is used for > >>SE data, it would also be used for the MM or generalized format. > >> > >>For a 6-port example: > >> > >> D2,4 fixed, sequential re-mapping in a fixed D, C, X > >>order > >> D5,6 > >> C2,4 > >> C5,6 > >> X1 > >> X3 > >> > >>the generalized matrix is this > >> > >> Xd2d4,d2d4 Xd2d4,d5d6 . Xd2d4,c2c4 Xd2d4,c5c6 . Xd2d4,1 Xd2d4,2 > >> Xd5d6,d2d4 Xd5d6,d5d6 . Xd5d6,c2c4 Xd5d6,c5c6 . Xd5d6,1 Xd5d6,2 > >> .................................................................... > >> Xc2c4,d2d4 Xc2c4,d5d6 . Xc2c4,c2c4 Xc2c4,c5c6 . Xc2c4,1 Xc2c4,2 > >> Xc5c6,d2d4 Xc5c6,d5d6 . Xd5c6,c2c4 Xc5c6,c5c6 . Xc5c6,1 Xc5c6,2 > >> .................................................................... > >> X1,d2d4 X1,d5d6 . X1,c2c4 X1,c5c6 . X1,1 X1,2 > >> X2,d2d4 X2,d5d6 . X2,c2c4 X2,c5c6 . X2,1 X2,2 > >> > >>Symmetry about the diagonal implies some non-intuitive (at least to me) > >>relationships exist. > >> > >>For example > >> > >> X2,c5c6 = Xc5c6,2 > >> > >> Xc2c4,d5d6 = Xd5d6,c2c4. etc. > >> > >>Does the symmetry relationship still exist with a different reference > >>impedance assumption, such as with (2)? > >> > >>What is the minimal set of reference impedance constraints needed > >>for SE and MM pairs for normalized S-parameter to preserve generalized > >>symmetry? > >> > >>Bob > >> > >> > >>radek_biernacki@xxxxxxxxxxx wrote: > >> > Hi Bob/Vladimir/All, > >> > > >> > While there are some advantages of grouping all SE ports either at the > >>beginning or at the end of the list, and have DD, DC, CD and CC > >>structure for the MM ports (like case 5), I am for the second case of > >>fully arbitrary arrangement (subject to Vladimir's comments) of the > >>MM/SE ports. > >> > > >> > As the common mode quantities do not depend on which node in the pair > >>is "+" and which is "-", the meaning of C5,6 and C6,5 is the same. Yet, > >>I agree, for clarity we may restrict this order to be the same as for > >>the corresponding Dx,y. > >> > > >> > Radek > >> > > >> > > >> > -----Original Message----- > >> > From: ibis-interconn-bounce@xxxxxxxxxxxxx > >>[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of > >>Dmitriev-Zdorov, Vladimir > >> > Sent: Thursday, May 01, 2008 2:19 PM > >> > To: ibis-interconn@xxxxxxxxxxxxx > >> > Subject: [ibis-interconn] Re: Mixed mode matrix definition > >> > > >> > Hi Bob, > >> > > >> > You put very important questions. I think all the ordering types > >>listed > >> > below should be definitely allowed. I don't see why we need any > >>further > >> > restriction on that. The only requirements are: > >> > > >> > - Input and output vectors (like A and B) are similarly ordered > >> > - Each SE component in the vector appears only once, each C/D pair of > >>MM > >> > components appears once and each port may participate in only one MM > >> > pair or not participate at all > >> > - Indexes are built from port numbers use in standard mode > >> > > >> > As a result, the standard mode matrix can be uniquely restored from > >>the > >> > given matrix and given mapping > >> > > >> > It seems as all 5 examples satisfy these requirement. > >> > > >> > > >> > > >> > > >> > Regarding your second question: > >> > > >> > >Would C5,6 and C6,5 be considered equivalent? > >> > > >> > Since mixed mode pair is produced by the relations: > >> > > >> > Ac5,6 = 1/sqrt(2) * ( A5 + A6) > >> > Ad5,6 = 1/sqrt(2) * ( A5 - A6) > >> > > >> > It follows that at least D5,6 and D6,5 are not equivalent. > >> > > >> > Therefore, the order of indexes in each pair matters. I think we > >>should > >> > not allow - for clarity - the modes C5,6 and D6,5 present at the same > >> > time. Of course, they are still convertible, because D5,6 = -D6,5, but > >> > still, the data should be consistent. The first index stands for the > >> > 'positive' and the second for 'negative' in defining the differential > >> > pair. > >> > > >> > Vladimir > >> > > >> > > >> > -----Original Message----- > >> > From: ibis-interconn-bounce@xxxxxxxxxxxxx > >> > [mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of Bob Ross > >> > Sent: Thursday, May 01, 2008 11:57 AM > >> > To: ibis-interconn@xxxxxxxxxxxxx > >> > Subject: [ibis-interconn] Re: Mixed mode matrix definition > >> > > >> > Hi Vladimir and All: > >> > > >> > I agree with your position to constrain the format per your > >> > arguments and also per your other comments in item 8 that you > >> > sent out earlier. This also appears consistent with Tao Su's > >> > proposal. > >> > > >> > Also this conforms to practice in application notes and also allows > >> > easily supporting generalized formats with both mixed-mode (MM) > >> > and single-ended (SE) formulations. Any other MM ordering > >> > should be done outside of the Touchstone format, such shown the > >> > one shown in your Agilent example below. > >> > > >> > ---- > >> > > >> > As a practical matter, can we allow some arbitrary ordering? > >> > For example using your mapping notation for a 6-port ... > >> > > >> > 1. Arbitrary mixing of SE and MM data for generalized formats: > >> > > >> > X1 keeps SE locations fixed > >> > D2,4 symmetrical DD and CC blocks > >> > D3,5 > >> > C2,4 > >> > C3,5 > >> > X6 > >> > > >> > X6 arbitrary repositioning of SE data > >> > X1 and different port association definitions > >> > D4,3 > >> > C4,3 > >> > D2,5 > >> > C2,5 > >> > > >> > X1 keeps SE locations fixed > >> > D2,3 moves MM ports into corresponding SE locations > >> > C2,3 with arbitrary D, C sequencing and possible > >>in-place > >> > X4 teble entry calculations > >> > C5,6 > >> > D5,6 > >> > > >> > X1 keeps SE locations fixed > >> > D2,4 moves MM ports into corresponding SE locations > >> > X3 > >> > C2,4 > >> > D5,6 > >> > C5,6 > >> > > >> > D2,4 fixed, sequential re-mapping in a fixed D, C, X > >>order > >> > D5,6 > >> > C2,4 > >> > C5,6 > >> > X1 > >> > X3 > >> > > >> > 2. C index ordering convention: > >> > > >> > Would C5,6 and C6,5 be considered equivalent? > >> > > >> > I assume the D entry depends on the stated order. > >> > > >> > ---- > >> > > >> > I would prefer allowing arbitrary ordering since the table itself > >> > has the necessary information to identify the stored entries and > >>locate > >> > the position of the associated data within the Touchstone set of data. > >> > > >> > E.g., Sd2,4_x1 or Sx1_c2,4 only exits in some of the above formats and > >> > its > >> > corresponding complex data at each frequency can be extracted from the > >> > file > >> > with a mapping to position program. > >> > > >> > Bob > >> > > >> > Dmitriev-Zdorov, Vladimir wrote: > >> > > >> >>Hello, > >> >> > >> >>I noticed that there have been several proposals - mostly in example > >> >>touchstone form - that assumed the S-matrix as being asymmetrical, > >> > > >> > even > >> > > >> >>for reciprocal multiports. > >> >> > >> >>For example, here is the definition of matrix components from Agilent: > >> >> > >> >>! S11 = SDD11 > >> >>! S12 = SDD12 > >> >>! S13 = SDD21 > >> >>! S14 = SDD22 > >> >>! S21 = SDC11 > >> >>! S22 = SDC12 > >> >>! S23 = SDC21 > >> >>! S24 = SDC22 > >> >>! S31 = SCD11 > >> >>! S32 = SCD12 > >> >>! S33 = SCD21 > >> >>! S34 = SCD22 > >> >>! S41 = SCC11 > >> >>! S42 = SCC12 > >> >>! S43 = SCC21 > >> >>! S44 = SCC22 > >> >>! > >> >> > >> >> > >> >>As we see, the diagonal matrix components, such as S22 and S33 are > >> >>allowed to define conversion from differential to common mode that > >> >>assumes the incident and reflected wave vectors are permuted in a > >> >>different way. Also, the matrix is non-symmetrical. For example, S13 = > >> >>SDD21 but S31 = SCD11. > >> >> > >> >>In brief, the matrix specified above (Sx) does not satisfy definition > >> > > >> > of > >> > > >> >>the S-parameter matrix. It can be thought as a 'true' S-parameter > >> > > >> > matrix > >> > > >> >>multiplied on the permutation matrix from right or left only: Sx = > >> > > >> > S*P. > >> > > >> >>The matrix S is symmetrical for all realistic interconnects but Sx is > >> >>not. > >> >> > >> >>It would be logical not to allow such permuted matrix in the > >> > > >> > Touchstone > >> > > >> >>file. It is a way easier to define and properly use the matrix S than > >> >>matrix Sx. In general, there is no other way of defining Sx are > >> > > >> > listing > >> > > >> >>all its components that total to NxN. For large matrices, counting > >> >>hundreds of ports, such definition becomes impractical. > >> >> > >> >>Even in case of extreme need for allowing such matrices, there is a > >> >>better way to define the ordering, that requires only 2*N instead of > >> > > >> > NxN > >> > > >> >>components. But of course, it would be much better to work with > >> > > >> > standard > >> > > >> >>ones only. > >> >> > >> >>Vladimir > >> >> > >> >> > >> > > >> > > >> > >> > >>-- > >>Bob Ross > >>Teraspeed Consulting Group LLC Teraspeed Labs > >>121 North River Drive 13610 SW Harness Lane > >>Narragansett, RI 02882 Beaverton, OR 97008 > >>401-284-1827 503-430-1065 > >>http://www.teraspeed.com 503-246-8048 Direct > >>bob@xxxxxxxxxxxxx > >> > >>Teraspeed is a registered service mark of Teraspeed Consulting Group LLC > >> > >>------------------------------------------------------------------ > >> The IBIS Ad Hoc Interconnect Task Group Mailing List > >> > >>Archives are available at: > >> //www.freelists.org/archives/ibis-interconn > >> > >>TO UNSUBSCRIBE: > >> Send a message to "ibis-interconn-request@xxxxxxxxxxxxx" > >> with a subject of "unsubscribe" > >> > >>To administer your subscription status from the web, visit: > >> //www.freelists.org/list/ibis-interconn > >> > >> > >> > >> > >> > >>------------------------------------------------------------------ > >> The IBIS Ad Hoc Interconnect Task Group Mailing List > >> > >>Archives are available at: > >> //www.freelists.org/archives/ibis-interconn > >> > >>TO UNSUBSCRIBE: > >> Send a message to "ibis-interconn-request@xxxxxxxxxxxxx" > >> with a subject of "unsubscribe" > >> > >>To administer your subscription status from the web, visit: > >> //www.freelists.org/list/ibis-interconn > >> > >> > >> > >>------------------------------------------------------------------ > >> The IBIS Ad Hoc Interconnect Task Group Mailing List > >> > >>Archives are available at: > >> //www.freelists.org/archives/ibis-interconn > >> > >>TO UNSUBSCRIBE: > >> Send a message to "ibis-interconn-request@xxxxxxxxxxxxx" > >> with a subject of "unsubscribe" > >> > >>To administer your subscription status from the web, visit: > >> //www.freelists.org/list/ibis-interconn > >> > >> > >> > >> > >> > >>------------------------------------------------------------------ > >> The IBIS Ad Hoc Interconnect Task Group Mailing List > >> > >>Archives are available at: > >> //www.freelists.org/archives/ibis-interconn > >> > >>TO UNSUBSCRIBE: > >> Send a message to "ibis-interconn-request@xxxxxxxxxxxxx" > >> with a subject of "unsubscribe" > >> > >>To administer your subscription status from the web, visit: > >> //www.freelists.org/list/ibis-interconn > >> > >> > >> > >>------------------------------------------------------------------ > >> The IBIS Ad Hoc Interconnect Task Group Mailing List > >> > >>Archives are available at: > >> //www.freelists.org/archives/ibis-interconn > >> > >>TO UNSUBSCRIBE: > >> Send a message to "ibis-interconn-request@xxxxxxxxxxxxx" > >> with a subject of "unsubscribe" > >> > >>To administer your subscription status from the web, visit: > >> //www.freelists.org/list/ibis-interconn > >> > >> > >> > >> > >> > >>------------------------------------------------------------------ > >> The IBIS Ad Hoc Interconnect Task Group Mailing List > >> > >>Archives are available at: > >> //www.freelists.org/archives/ibis-interconn > >> > >>TO UNSUBSCRIBE: > >> Send a message to "ibis-interconn-request@xxxxxxxxxxxxx" > >> with a subject of "unsubscribe" > >> > >>To administer your subscription status from the web, visit: > >> //www.freelists.org/list/ibis-interconn > >> > >> > >> > >> > > > > > > > > > -- > Bob Ross > Teraspeed Consulting Group LLC Teraspeed Labs > 121 North River Drive 13610 SW Harness Lane > Narragansett, RI 02882 Beaverton, OR 97008 > 401-284-1827 503-430-1065 > http://www.teraspeed.com 503-246-8048 Direct > bob@xxxxxxxxxxxxx > > Teraspeed is a registered service mark of Teraspeed Consulting Group LLC > > ------------------------------------------------------------------ > The IBIS Ad Hoc Interconnect Task Group Mailing List > > Archives are available at: > //www.freelists.org/archives/ibis-interconn > > TO UNSUBSCRIBE: > Send a message to "ibis-interconn-request@xxxxxxxxxxxxx" > with a subject of "unsubscribe" > > To administer your subscription status from the web, visit: > //www.freelists.org/list/ibis-interconn > > > > -- Bob Ross Teraspeed Consulting Group LLC Teraspeed Labs 121 North River Drive 13610 SW Harness Lane Narragansett, RI 02882 Beaverton, OR 97008 401-284-1827 503-430-1065 http://www.teraspeed.com 503-246-8048 Direct bob@xxxxxxxxxxxxx Teraspeed is a registered service mark of Teraspeed Consulting Group LLC ------------------------------------------------------------------ The IBIS Ad Hoc Interconnect Task Group Mailing List Archives are available at: //www.freelists.org/archives/ibis-interconn TO UNSUBSCRIBE: Send a message to "ibis-interconn-request@xxxxxxxxxxxxx" with a subject of "unsubscribe" To administer your subscription status from the web, visit: //www.freelists.org/list/ibis-interconn ------------------------------------------------------------------ The IBIS Ad Hoc Interconnect Task Group Mailing List Archives are available at: //www.freelists.org/archives/ibis-interconn TO UNSUBSCRIBE: Send a message to "ibis-interconn-request@xxxxxxxxxxxxx" with a subject of "unsubscribe" To administer your subscription status from the web, visit: //www.freelists.org/list/ibis-interconn