[ibis-interconn] Re: Touchstone 3 draft1

  • From: Walter Katz <wkatz@xxxxxxxxxxxxx>
  • To: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>, 'IBIS-Interconnect' <ibis-interconn@xxxxxxxxxxxxx>
  • Date: Tue, 11 Jan 2022 13:59:02 +0000

Arpad,

Except for [Matrix Format] one can remove all of the Touchstone 2 sections and 
keywords and the file is a legal Touchstone 1 file if it is renamed sNp where 
N=[Number of Ports].

Again ignoring Noise data (which I have never seen in an interconnect model), 
the only important information for using this Touchstone file is [Reference]. 
Only tools that will support reference per port need to modify their Touchstone 
reader to parse the [Reference] keyword. This would be a much simpler change to 
Touchstone readers then to require them to ignore all of the other Touchstone 2 
stuff.

As for [Two-Port Data Order], making it optional in Touchstone 3 leaves it back 
to the way it was in Touchstone 1: If the tool wants it to be unambiguous it 
will need to update its Touchstone parser.

The [Two-Port Data Order] keyword is used to signify the column ordering 
convention. The Version 1.0 convention for 2-port network data is N11, N21, 
N12, N22, where N11, N12, etc., represent pairs of data entries. However, some 
tools and users have adopted the convention N11, N12, N21, N22 (a more natural 
order consistent with all the other n-port ordering conventions). Using the 
keyword (required in Version 2.0, optional in 3.0) makes the ordering of 2-port 
network data explicit and unambiguous.

I go back to Radek's point he made many moons ago. Touchstone is just a format 
containing a matrix of imaginary numbers for a list of frequencies. Other than 
[Matrix Data] (and the future Sparse format), everything in Touchstone 2 is how 
to use the data. The ultimate question is how does the Touchstone file get 
delivered to the customer so that Touchstone X will be adapted. I see the 
following options:

  1.  My propose for Touchstone 3 that makes most Touchstone 2 keywords 
optional.
  2.  Put the Touchstone 2 stuff in a second file.
     *   Everyone hates have the data in two files.
  3.  Put the Touchstone 2 stuff in a contained section at the beginning of the 
Touchstone X file
     *   Should be easy to modify Touchstone reads to skip the section
     *   The Touchstone X file can be distributed this way. Recipients can easy 
us a text editor or script to strip off the Touchstone x section and create a 
Touchstone 1 file for their tool.

Walter

Walter Katz
Work  508.647-7633
Cell      720.417-3762
[Description: Description: Visit MathWorks.com]

From: ibis-interconn-bounce@xxxxxxxxxxxxx <ibis-interconn-bounce@xxxxxxxxxxxxx> 
On Behalf Of Muranyi, Arpad
Sent: Monday, January 10, 2022 7:15 PM
To: 'IBIS-Interconnect' <ibis-interconn@xxxxxxxxxxxxx>
Subject: [ibis-interconn] Re: Touchstone 3 draft1

Walter,

Thanks for the explanation and example.  In some ways it makes sense, but the 
problem
I have with this story is that in the past I heard you say that there are 
gazillion ancient
scripts and tools around which are still being used, but their developers may 
not even
be around anymore and no-one wants to touch the source code, while they are 
still using
the executables happily.

In the email you just wrote, you mentioned at least two things that need source 
code
changes in your Touchstone tool:  Add support for the [Version] keyword (or 
ignore it)
and add support for the [Reference] keyword).  If you start doing that, you 
might as
well add support for the rest of the keywords in your tool's parser.  This is 
ONLY a
file I/O (parsing/writing) problem, the rest of your data processing algorithms
wouldn't need to be touched at all...

In addition, do you want to reinstate the number ordering problem of Touchstone 
1
in Touchstone 3 with .s2p files?  How do you propose to solve the problem you
highlighted in red letters in your Touchstone 3 draft?:

[cid:image002.png@01D806C5.5BF115C0]

Anyway, I am not trying to argue with you, majority will rule, but I don't see a
clean solution to your desire to continue in the Touchstone 1 path.  Even if we
did what you are proposing in your Touchstone 3 draft, we will eventually end
up having to add new keywords to its successor(s).  I don't see how we can
continue adding new features and capabilities indefinitely without switching
to keyword style.  You will end up having to continually change your tool's 
parser
anyway (even if you don't want to use any of those new features in the models
you write) just so that it won't crash on the new keywords.  Going back to
Touchstone 1 style files might buy you a little time now, but ultimately I don't
see a way around the need to have to change your tool's source code...  Also,
there are times when making a change sooner is easier than later.  The longer
we wait, the more baggage we will have to deal with in the specification as
well as in the tools...

Thanks,

Arpad
===================================================================

From: 
ibis-interconn-bounce@xxxxxxxxxxxxx<mailto:ibis-interconn-bounce@xxxxxxxxxxxxx> 
<ibis-interconn-bounce@xxxxxxxxxxxxx<mailto:ibis-interconn-bounce@xxxxxxxxxxxxx>>
 On Behalf Of Walter Katz
Sent: Monday, January 10, 2022 8:38 AM
To: 'IBIS-Interconnect' 
<ibis-interconn@xxxxxxxxxxxxx<mailto:ibis-interconn@xxxxxxxxxxxxx>>
Subject: [ibis-interconn] Re: Touchstone 3 draft1

Arpad,

Here is an example. I have tools that read and write Touchstone I files. All I 
want to do is create and read Touchstone file that have the Impedance per port 
record. I and just add the following two lines:

[Version] 3.0
[Reference] ...

All I need to do is modify my Touchstone reader to ignore the "[Version] 3.0" 
line and parse the "[Reference] ..." line.
There is no need to add the [Number of Ports] because it is in the sNp file 
extent.
There is no need to add the [Number of Frequencies] since my parser already 
knows how to parse it.
There is no need to add [Network Data], since my parser already knows how to 
parse it.

If, and when we add [Begin Port Data] and [End Port Data], it will be easy to 
modify parsers to just skip that section, or the user can chose to delete those 
lines from the file to use in their tool.

The whole idea is make it easy for people to add the additional information 
that we know is desired today, which is keep sNp, add [Reference] and add 
machine parsable Port information.

I personally would like to eliminate Touchstone 2 altogether, and come up with 
a Touchstone Interconnect standard based on Touchstone 1.
Remove the following keywords

  *   [Number of Ports]
  *   [Number of Frequencies]
  *   [Number of Noise Frequencies] (No support for Noise Data)
  *   [Mixed-Mode Order]
Optional keywords (Sorted by most important first)

  *   [Reference]
  *   [Begin Port Data]/[End Port Data]
  *   [Begin Sparse Data]/[End Sparse Data]
  *   [Begin Information]/[End Information] (optional)
  *   [Two-Port Order]
  *   [Matrix Format]

This is what the user community wants

  *   They require the sNp format, so why have [Number of Ports]
  *   The already know how to figure out  [Number of Frequencies]
  *   Interconnect does not use Noise Data
  *   No need for Mixed-Mode Order, mixed mode s-params can always be generated 
from normal single ended order and [Port Data]
  *   The most important things that are needed over Touchstone I are:

o   [Reference]

o   Computer parsable Port Data

o   Sparse Data

Bottom lines is we have the following options:

  1.  Create a Touchstone 3 based on Touchstone 2 without the upward 
compatibility clause
  2.  Create a Touchstone 3 based on Touchstone 2 with the upward compatibility 
clause
  3.  Throw away Touchstone 2 and create a Touchstone Interconnect as suggested 
above.

Walter


Walter Katz
Work  508.647-7633
Cell      720.417-3762
[Description: Description: Visit MathWorks.com]

GIF image

PNG image

Other related posts:

  1. Home
  2. ibis-interconn
  3. Archive
  4. 01-2022