[ibis-macro] Re: Conclusions regarding unterminated ports from today's meeting

  • From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
  • To: "IBIS-Interconnect (ibis-interconn@xxxxxxxxxxxxx)" <ibis-interconn@xxxxxxxxxxxxx>, "IBIS-ATM (ibis-macro@xxxxxxxxxxxxx)" <ibis-macro@xxxxxxxxxxxxx>
  • Date: Wed, 4 Oct 2017 04:46:01 +0000

We could consider making the Unused_port_termination parameter required
only when the terminal lines don't list each port from the Touchstone file, and
forbidden when all ports are listed in the terminal lines...  Doesn't make sense
to have it when all ports are listed, and it might be even confusing to allow 
it in
that case.

Thanks

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

From: ibis-interconn-bounce@xxxxxxxxxxxxx 
[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of Mirmak, Michael
Sent: Tuesday, October 3, 2017 11:40 PM
To: IBIS-Interconnect (ibis-interconn@xxxxxxxxxxxxx) 
<ibis-interconn@xxxxxxxxxxxxx>; IBIS-ATM (ibis-macro@xxxxxxxxxxxxx) 
<ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-interconn] Conclusions regarding unterminated ports from today's 
meeting

Based on the discussion in today's IBIS-ATM meeting, is the following summary 
of our next steps for Interconnect termination treatments correct?

Only two options for unused port termination treatments should be permitted in 
the Interconnect model specification:
1) Keep unterminated ports open; this allows brute-force termination of ports, 
or more elegant mathematical reductions in the matrix data before use
2) Terminate the ports before simulation with their corresponding reference 
impedances from the Touchstone file

To ensure the model-maker has nominal control of the termination treatment, 
Unused_Port_Termination should be reintroduced as a parameter, but as a 
required one.  It should also have a different structure, with only two 
possible arguments:

              Unused_port_termination = <open | reference>

If supported, this is parse-able and checkable, but as with many other 
parameters, an EDA tool could allow the user to override the setting; this 
would violate the spirit of the specification but would not result in a 
checkable violation of the syntax.


-          MM


Other related posts: