[ibis-interconn] Re: Non-sampled representation of S/Y/Z etc. parameters

  • From: "Dmitriev-Zdorov, Vladimir" <vladimir_dmitriev-zdorov@xxxxxxxxxx>
  • To: <ibis-interconn@xxxxxxxxxxxxx>
  • Date: Wed, 15 Jul 2009 13:17:30 -0600

Hi Brad,

To decide about standard, we need a document describing your format.
Then, we can put several proposals side by side and make them discussed.
Can you provide such formal description?

BTW, what about portability of your binary format between
Windows/non-Windows platforms?

Vladimir

-----Original Message-----
From: Brad Brim [mailto:bradb@xxxxxxxxxxx] 
Sent: Tuesday, July 14, 2009 7:12 PM
To: 'Bob Ross'; Dmitriev-Zdorov, Vladimir
Subject: RE: [ibis-interconn] Re: Non-sampled representation of S/Y/Z
etc. parameters

hi Bob and Vladimir,

excellent idea!
Sigrity already has such file format we call BNP. We write it, and read
it.
HSPICE reads it also. We went one step further and made it binary to
save
even more disk space, thus the 'B' for Binary Network Parameters.

I have seen several different pole/zero and rational function syntaxes.
Issue will be gaining consensus on which of the many forms to define as
the
standard

let's assure we actively involve as many EDA companies as possible and
do so
as early as possible, even those that don't come out to play very often,
or
there will likely be complainers late in the game.

cheers,
 -Brad
 

> -----Original Message-----
> From: ibis-interconn-bounce@xxxxxxxxxxxxx 
> [mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of Bob Ross
> Sent: Tuesday, July 14, 2009 5:05 PM
> To: Dmitriev-Zdorov, Vladimir
> Cc: ibis-interconn@xxxxxxxxxxxxx
> Subject: [ibis-interconn] Re: Non-sampled representation of 
> S/Y/Z etc. parameters
> 
> Hi Vladimir:
> 
> I think this is a useful format to consider.  This could be 
> put in a separate document, or if we reuse much of the 
> Touchstone 2 for format generality that surrounds your 
> format.  For example, we could consider this as a [PLS 
> Network] block with the exclusionary rule that only [Network] 
> or [PLS Network] must exist, but not both.
> A few other keywords might need to be excluded or added.
> 
> Anyway, this is good material to consider in the near future.
> 
> Bob
> 
> Dmitriev-Zdorov, Vladimir wrote:
> > Hello, All,
> > 
> > Along with our current work on Touchstone format, I'd like to 
> > separately consider another - analytical, alternative - 
> representation 
> > of frequency-dependent parameters, or at least to plan such 
> > consideration for the nearest future, when we finish with 
> Touchstone specifications.
> > 
> > First of all, let me say that we have two different ways of 
> > frequency-domain representation for S/Y/Z (etc.) matrices: 
> sampled and 
> > analytical.
> > 
> > 1. Sampled representation is basically our Touchstone-like formats, 
> > where dependence is given by a collection of its matrix values at 
> > several frequency points. Besides Touchstone, there are some other 
> > less popular ways of sampled representation. In all cases: there 
> > dependence is given on a finite number of points and has 
> lower/upper 
> > frequency bounds. Such dependences may pose problems if we need to 
> > evaluate the function at any given frequency, since then we 
> may need 
> > interpolation or extrapolation, if the desired frequency 
> lies outside 
> > given bounds. With sampled dependences, we may have 
> intrinsic problems 
> > with "causality" and "passivity".
> > 
> > 2. Analytical representation however always assumes that our 
> > dependence can be given by some kind of analytical 
> expression or formula. Examples:
> > pole/zero representation, partial fraction expansion, 
> representation 
> > by means of polynomials, by Laplace elements, and ultimately, by 
> > linear equivalent circuits, that could be unambiguously 
> converted into 
> > analytical expressions, or at least evaluated at any given 
> frequency, 
> > without lower/upper bound and with no interpolation. Such 
> > representations, if consistent, are causal by design. 
> Still, they do 
> > not guarantee 'passivity'. Also, analytical representations almost 
> > always are very concise if compared to sampled ones. 
> (Typically, the 
> > file size ratio is between 1 to 3 orders.) Another advantage: 
> > analytical representations are more suited for frequency and 
> > time-domain analysis because they do not require 
> interpolation and in 
> > part of time domain analysis unambiguously provide time domain 
> > responses, that allows either direct numerical integration 
> (as in case 
> > of equivalent circuit) or very efficient recursive convolution, 
> > semi-analytical procedure that is by orders more efficient than 
> > convolution with IFFT'ed sampled dependence and also is way 
> more accurate.
> > 
> > 3. Comparing sampled and analytical representations, we can 
> easily see 
> > their advantages and weaknesses. Sampled dependence is 
> represented by 
> > mere tables of numbers that makes reading/parsing extremely 
> fast and 
> > simple. The tables can be generated from simulation or 
> measurements, 
> > no 'tricky' transformations are involved. Analytically defined 
> > dependences sometimes require some extra language 
> constructs of even 
> > circuit description. Some efforts are needed to create 'analytical'
> > representation from sampled dependence. Because of that, 
> once created, 
> > such analytical model should be re-used (and hence we need 
> to find a 
> > way of storing it).
> > 
> > 4. I oppose the idea of combining sampled and analytical 
> dependences 
> > into a single data set. For example, it does not look 
> appealing to me 
> > to combine S11 and S22 given by samples with S12 and S21 defined by 
> > any type of analytical representation. This could be a valid 
> > intermediate step in model creation, but it does not work 
> well as a final standard.
> > Main reason: by allowing so, we rather add up together 
> disadvantages 
> > from both sampled and analytical world and multiply complexity and 
> > confusion.
> > 
> > 5. Hence, it seems reasonable that we need a separate format to 
> > represent analytical dependences. It also seems reasonable that the 
> > way we choose for analytical representation should be identical for 
> > all matrix components (e.g. we should not mix equivalent 
> circuits for
> > S11/S22 with tables of poles/residues for S12 and S21 or 
> other similar 
> > way). We simply don't need using many ways of analytical 
> > representations because they are easily mutually 
> convertible. I also 
> > think that ideally, we should avoid using linguistic (e.g. 
> HSPICE or 
> > others') constructs, to completely avoid language specifics 
> and their 
> > limitations (e.g. on largest allowed complexity of Laplace 
> construct) 
> > and also to avoid introducing any concept of 'nodes' and 
> 'branches'. 
> > We don't need to introduce the 'structure' or 'topology' to 
> the matter 
> > that is purely
> > numerical: we are dealing with frequency-dependent matrix.
> > 
> > 6. I'd like to propose one format we can use for analytical 
> > representation of any causal frequency dependences. (See attached 
> > document). The advantages are:
> > - all we need is table of numbers, with as many lines (per matrix
> > component) as we need. Each line always contains 4 numbers 
> sufficient 
> > to represent a summand in partial fraction expansion (see 
> formula 1). 
> > If the pole in the fraction is real, two of four numbers are zero.
> > - there is an easy and unambiguous way to construct analytical 
> > dependences from those numbers.
> > - analytical dependence is given as a sum of primitive components, 
> > making it extremely easy to operate in time domain analysis. Or, if 
> > needed, convert it into equivalent circuit or other 
> analytical form, 
> > or simply re-sample in any desirable way.
> > - no simulator-specific constructs are used. To construct the 
> > dependence, we need only a simple code that reads numbers from such 
> > PLS tables.
> > - this format was extensively tested during at least 6 
> years in many 
> > S/Y/Z parameter applications. We found it very convenient, 
> concise and 
> > suitable for representation of matrices with very large number of 
> > ports (e.g. 226x226) where it allowed huge disk space and 
> simulation 
> > time reduction when compared to conventional simulators (compare: 8 
> > hours and
> > 5 minutes single simulation run time for equivalent circuit 
> and this 
> > type of representation, same complexity). The reason: we 
> avoid parsing 
> > time and many extra nodes/ branches needed when using equivalent 
> > circuit. More details in: DesignCon 2006, 
> > http://www.altera.com.cn/literature/cp/cp-ftdsimltn.pdf.
> > - there were no attempts made to support sparsity with this format, 
> > but this is easy to add. I think it's almost evident how we can add 
> > sparsity. Some of ideas we have for Touchstone format in 
> that respect, 
> > can be completely reused.
> > - similarly, we can borrow much of our constructs for mixed 
> mode and 
> > combined single and mixed mode representation as introduced in 
> > Touchstone 2.0 format. Interestingly enough, even matrix 
> > transformations needed between mixed-standard mode representations, 
> > are fully applicable to proposed analytical representation 
> (see again 
> > expression (1) in attached document), since all we need is 
> > multiplication and summing up such components. However, note that 
> > these transformations are NOT directly applicable in case of 
> > pole-zero, Laplace of equivalent circuit representation.
> > 
> > Please review the documents and share your thoughts.
> > 
> > Thanks,
> > 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



Other related posts: