[ibis-macro] Re: BIRD116: ISS for External Model (S-params with AMI in conjunction with i-v, v-t tables)

  • From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
  • To: "IBIS-ATM" <ibis-macro@xxxxxxxxxxxxx>
  • Date: Tue, 18 Jan 2011 00:56:52 -0800

Kukal,

 

I understand now better what you are asking.

 

What you need basically is an [External Circuit] between the

legacy [Model] and the pad (or bump) of the die.  The problem

is that ever since we added the external languages to IBIS,

we did not allow this combination.  If you looked at Figure 12

on pg. 136 you will see that [Model] or [External Model] cannot

have anything between itself and the pad.  Only External

Circuit can be cascaded like that.  There were reasons for

doing it this way, but I don't remember them all right now.

 

Making changes to these rules would be a bugger undertaking,

and I didn't want to get into that with BIRDs 116-118.  My goal

was to find a solution similar to the Opal approach with the

least amount of changes to IBIS, but eliminating the assumed

buffer model netlist, and also to fix some of the age old

deficiencies in IBIS, namely the package modeling and C_comp.

 

Your request can be addressed, but I would suggest to do that

with a separate BIRD, because in many ways it is a topic of

its own.

 

Thanks,

 

Arpad

==============================================================

 

From: Taranjit Kukal [mailto:kukal@xxxxxxxxxxx] 
Sent: Monday, January 17, 2011 8:20 AM
To: Muranyi, Arpad; IBIS-ATM
Subject: RE: [ibis-macro] Re: BIRD116: ISS for External Model (S-params
with AMI in conjunction with i-v, v-t tables)

 

Hi Arpad, Walter,

Thanks for detailed explanations.

 

Some clarifications:

 

1. RDL - Re-distribution layer on silicon used to bring IO-out to bump
of the flipchip package/

2. S-parameters in AMI - Yes, I am referring to OPAL doc

 

I understand that [external model] is a replacement, and there is where
I am putting my suggestion to not LIMIT it to replacement of i-v/v-t.

 

We should rather allow [External Model] to work in conjunction with i-v,
v-t data. A keyword ('type' or something) could always be used to
specify if the model needs to

    a) Replace the i-v/v-t model: All Spice IO models would fall into
this category 

    b) Augment the i-v/v-t model: All parasitic models (onchip RDL for
example) would fall into this category 

        There could even be cases where IO model is i-v/v-t and
[External Model] is Behavioral Spice for DSP portion. 

 

Cadence tools can do b) as by using macro-modeling; but why not scale-up
the use of [External Model] especially when we would have a common
practise of using onchip s-params in conjunction with i-v/v-t

 

rgds

..kukal

 

         

________________________________

        From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
        Sent: Thursday, January 13, 2011 10:27 PM
        To: IBIS-ATM
        Subject: [ibis-macro] Re: BIRD116: ISS for External Model
(S-params with AMI in conjunction with i-v, v-t tables)

        Kukal,

         

        First, Walter is correct.  [External Model] is a replacement for
the

        "guts" of [Model].  According to the IBIS specification, you can
have

        I-V and V-t tables in a [Model] and an [External Model] keyword
in

        the same [Model] but if a tool can interpret and use the content
of

        [External Model], it must ignore the I-V and V-t tables.  The
reason

        it was done this way was to allow simulators to still be able to
run

        if they didn't have the *-AMS languages in their engine, but if
they

        did, they could make use of the "better" models in [External
Model].

         

        To answer your questions:

         

        1)  BIRD 116 really doesn't have anything to do with full
transistor

        level models (SPICE), although it doesn't prevent them from
being

        used.  Whether the analog model that is used for the channel

        characterization step of the AMI simulations is IBIS, SPICE,

        VHDL-AMS, or Verilog-AMS is up to the EDA vendor's capabilities.

        (Our tool can do all of the above).  The IBIS perspective of AMI

        simulations is that we start from an IBIS file which has a
normal

        analog [Model], which points to the AMI model files with the

        [Algorithmic Model] keyword in [Model].  This provides
everything

        you need to set things up automatically (to find the AMI files

        which belong with the analog buffer [Model]).  If you have a non

        IBIS analog model, you will not have the convenience of the

        [Algorithmic Model] keyword to find the AMI files automatically.

        This is not a big deal if the tool provides a dialog for the
user

        to find these files in this case.

         

        The bottom line is that this depends more on the tool than the
spec.,

        but the spec doesn't prevent it from happening.

         

        The only relationship between this and BIRD 116 is that the
*-AMS

        languages I mentioned above are available in IBIS through the

        [External Model] keyword, which is what I used for bringing in

        the ISS language for analog buffer modeling.  The limitation in
this

        sense is that IBIS only has a few languages defined for the
[External

        ***] keywords.  But strictly speaking, you do not need IBIS in a
tool

        to make use of an analog buffer model (with AMI) if the tool is
not

        strictly an IBIS simulator.

         

        2)  As Walter already said, in IBIS we can't have I-V, V-t based
[Model]

        together with [External Model].  In addition, we can't have an
[External

        Circuit] between the pad and an I-V, V-t based [Model] either.
But,

        you can make an I-V, V-t based behavioral model of your own, put
it

        into the [External Model] and add more stuff to it.  You can
check out

        the VHDL-AMS and Verilog-A macro libraries I made, which include
such

        behavioral buffer models.

         

        
http://www.vhdl.org/pub/ibis/macromodel_wip/element_lib/VHDL-AMS_element
_library_SMASH_test.zip

        
http://www.vhdl.org/pub/ibis/macromodel_wip/element_lib/Verilog-A_elemen
t_library_HSPICE_test.zip

         

        This work is actually not completely finished.  The models all
work, but

        the comments are not clean, especially in the Verilog-A version,
so they

        can be misleading.  But they have all been tested and they are
all working.

         

        3)  I think you need to clarify our terminology here because
they way you

        wrote it doesn't make sense to me.  The AMI model is an
algorithmic model,

        and does not contain any analog models, therefore there can't be
any

        S-parameter models in the AMI model.  Are you referring to the
Opal style

        analog parameters in the .ami file?  If so, yet, the analog
parameters are

        in the .ami file (they come with the AMI model), but the analog
model is

        still not in the AMI model.  It is in the simulator engine
somewhere.

         

        This is where we have a difference between Opal (BIRD 122) and
my BIRDs

        (116-118).  BIRD 122 assumes a hard coded circuit in the
simulator somewhere

        while BIRDs 116-118 allow this circuit to be described in an
[External Model]

        using the ISS language.

         

        I am still not sure what you mean by SPICE/RDL, please explain
on more detail.

         

        I hope this answered your questions and comments.

         

        Thanks,

         

        Arpad

        
========================================================================
============

         

         

         

        From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
        Sent: Thursday, January 13, 2011 8:59 AM
        To: kukal@xxxxxxxxxxx; 'IBIS-ATM'
        Subject: [ibis-macro] Re: BIRD116: ISS for External Model
(S-params with AMI in conjunction with i-v, v-t tables)

         

        Kukai,

         

        I believe that IBIS iv-vt curves are specifically mutually
exclusive with External Model. You can have only one or the other, not
both in one model.

         

        Walter

         

        From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Taranjit Kukal
        Sent: Thursday, January 13, 2011 2:01 AM
        To: IBIS-ATM
        Subject: [ibis-macro] BIRD116: ISS for External Model (S-params
with AMI in conjunction with i-v, v-t tables)

         

        Hi Arpad,

        Apologies for late feedback as I made entry into this forum
recently. 

         

        We have cases where AMI model (c-code) is supposed to work with
s-parameters for the buffer (say RDL of the buffer)

         

        Can we extend the scope of this BIRD (or introduce New one) that
covers all cases:

         

        1)  AMI model + Analog buffer represented as Spice-IO

            ### Current BIRD116 would allow this

        
        2) AMI model + VI-VT Analog buffer + RDL (etc) as parasitics in
[External Model]

           ###  Here the External Model needs to work in conjunction
with IBIS v-i, v-t data

         

        3)  AMI model (contains Analog-IO buffer coded in AMI itself) +
S-parameter/Spice RDL 

            ### Here the External Model needs to work w/o IBIS i-v, v-t
data

         

        Let me know if I missed fine points of the BIRD and that the
cases 2) and 3) are already covered

         

        rgds

        ..kukal

         

          

        Taranjit Kukal | Product Engineering Architect

        P: 91 120 3984000   www.cadence.com <http://www.cadence.com/> 

         

         

         

         

Other related posts: