[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: Thu, 13 Jan 2011 08:56:55 -0800

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: