[ibis-macro] Re: Analog Buffer model - the User's viewpoint

  • From: "Walter Katz" <wkatz@xxxxxxxxxx>
  • To: <ambrishv@xxxxxxxxxxx>, "'IBIS-ATM'" <ibis-macro@xxxxxxxxxxxxx>
  • Date: Fri, 20 Jan 2012 17:57:46 -0500 (EST)

Ambrish,

 

BIRD 116 fully support Tstonefile as well, just limited to three corners.

 

Walter

 

From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Ambrish Varma
Sent: Friday, January 20, 2012 4:56 PM
To: 'IBIS-ATM'
Subject: [ibis-macro] Re: Analog Buffer model - the User's viewpoint

 

Todd,

We have discussed and compared BIRD 144 and Walter's approach multiple
times already. By your own opinion that you expressed in an earlier email
(produced below) 

 

"For what it's worth, my personal opinion is that we'll end up with a
standard subcircuit that instantiates S-parameters in the long term.  I
suspect that most device vendors won't be willing to describe their
termination networks with a clear text netlist, as it could expose details
of their ESD and compensation circuits they don't want to reveal.
S-parameter blocks hide the internal details, and I expect we'll see a
standard template instantiating TX/RX s-parameter data before too long." 

 

you seem to understand the advantage of S-parameters. So in short, the
advantages of BIRD 144 (besides user defined corners) are that it supports
non IBIS-AMI simulations and easily allow S-Parameters to be instantiated
(without wrapping them in subcircuits). If there is a need for a
subcircuit - then BIRD 116 should satisfy that.

 

Thanks,

Ambrish.

 







 


Ambrish Varma   |  Member of Consulting Staff


P: 978.262.6431    <http://www.cadence.com> www.cadence.com


 





 

 

 

  _____  

From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Todd Westerhoff
Sent: Friday, January 20, 2012 4:24 PM
To: 'IBIS-ATM'
Subject: [ibis-macro] Re: Analog Buffer model - the User's viewpoint

 

That doesn't make sense to me.  

 

If we want to bypass the need to have a subcircuit (i.e. have a
pre-defined template) *AND* we want to have the ability to define the
subcircuit where needed, then we should just pursue BIRD 116 and
pre-define a few templates.  That's exactly what Walter was suggesting.
The only new thing I see in BIRD 144 is User Defined Corners, which are
limited to Touchstone files only.

 

What's the added value here?

 

Todd.


-- 

Todd Westerhoff
VP, Software Products
SiSoft
6 Clock Tower Place, Suite 250
Maynard, MA 01754
(978) 461-0449 x24
twesterh@xxxxxxxxxx
www.sisoft.com <http://www.sisoft.com/> 

 

 

"It doesn't matter what you've heard
  Impossible is not a word
  It's just a reason
  For someone not to try"

                                                     -Kutless

 

 

From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Ambrish Varma
Sent: Friday, January 20, 2012 4:17 PM
To: IBIS-ATM
Subject: [ibis-macro] Re: Analog Buffer model - the User's viewpoint

 

Todd,

We are not suggesting that BIRD 144 will replace BIRD 116. So if BIRD 116
& dependency tables can fulfill your requirement, then great. Look at BIRD
144 as a quick way of bypassing the requirement of having a subcct for the
case when the user wants to refer to a tstone file. 

Hope I read your issue correctly.

Regards,

Ambrish.

 







 


Ambrish Varma   |  Member of Consulting Staff


P: 978.262.6431    <http://www.cadence.com> www.cadence.com


 





 

 

 

  _____  

From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]
<mailto:%5bmailto:ibis-macro-bounce@xxxxxxxxxxxxx%5d>  On Behalf Of Todd
Westerhoff
Sent: Friday, January 20, 2012 4:03 PM
To: IBIS-ATM
Subject: [ibis-macro] Analog Buffer model - the User's viewpoint

 

All,

 

One of my colleagues here brought up a good point today - how the end-user
interacts with the model.

 

How do we expect that the user wants to interact with an IBIS-AMI model?
Specifically, how would they want to set up and run simulations?  The
answer, in SiSoft's opinion, is to specify values for control parameters
that correspond as closely to the actual hardware as possible.  Obviously
a deep and broad subject, of which I want to comment only on one small
slice: how it relates to analog modeling.

 

Let's assume we have a model where the output impedance (static impedance,
as Scott defined it) varies considerably depending on the TX output swing
setting.  We expect that the user wants controls that lets them set the
output swing and EQ settings in a way where the mapping to hardware
settings is obvious, with the model/simulator figuring out to configure
the details of the model.  Chances are, the analog model to be used will
change as a function of the output swing and EQ settings selected.  If
we're using subcircuit (as proposed by BIRD 116) or Touchstone (as
proposed by BIRD 144) methods, either the equivalent circuit parameters
(BIRD 116), or the Touchstone file selection (BIRD 144) will have to
change, depending on how the user sets the input controls.  I believe BIRD
116 & dependency tables can fulfill this requirement, but I'm not sure
that BIRD 144 (as currently proposed) can do this.

 

Todd.


-- 

Todd Westerhoff
VP, Software Products
SiSoft
6 Clock Tower Place, Suite 250
Maynard, MA 01754
(978) 461-0449 x24
twesterh@xxxxxxxxxx
www.sisoft.com <http://www.sisoft.com/> 

 

 

"It doesn't matter what you've heard
  Impossible is not a word
  It's just a reason
  For someone not to try"

                                                     -Kutless

 

 

GIF image

GIF image

Other related posts: