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

  • From: Feras Al-Hawari <feras@xxxxxxxxxxx>
  • To: "Arpad_Muranyi@xxxxxxxxxx" <Arpad_Muranyi@xxxxxxxxxx>, "'IBIS-ATM'" <ibis-macro@xxxxxxxxxxxxx>
  • Date: Mon, 23 Jan 2012 12:38:20 -0800

Yes HSPICE is the most well-known simulator, but not all simulators can 
directly consume the HSPICE syntax. Hence, in such cases a translation module 
will come into play in the middle.

Feras

________________________________
From: ibis-macro-bounce@xxxxxxxxxxxxx [ibis-macro-bounce@xxxxxxxxxxxxx] On 
Behalf Of Muranyi, Arpad [Arpad_Muranyi@xxxxxxxxxx]
Sent: Monday, January 23, 2012 3:37 PM
To: 'IBIS-ATM'
Subject: [ibis-macro] Re: Analog Buffer model - the User's viewpoint

But that’s why we picked HSPICE as the bases for
IBIS-ISS, since it is the most well-known and most
widely used flavor of all SPICE languages…  Some
tools have HSPICE compatibility modes of varying
degree built in already…

Thanks,

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

From: Feras Al-Hawari [mailto:feras@xxxxxxxxxxx]
Sent: Monday, January 23, 2012 2:29 PM
To: Muranyi, Arpad; 'IBIS-ATM'
Subject: RE: [ibis-macro] Re: Analog Buffer model - the User's viewpoint

But, there are multiple flavours of SPICE. Hence, not all simulators directly 
support the IBIS-ISS syntax and in such cases a translator from IBIS-ISS to the 
native SPICE syntax must be used. The later scenario might slow-down the 
adoption of IBIS-ISS in some tools.

Feras

________________________________
From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> 
[ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad 
[Arpad_Muranyi@xxxxxxxxxx]
Sent: Monday, January 23, 2012 3:26 PM
To: 'IBIS-ATM'
Subject: [ibis-macro] Re: Analog Buffer model - the User's viewpoint
Feras,

My understanding is that IBIS-ISS is a low threshold
entry point for most EDA vendors, since most already
know/have SPICE (in addition to S-parameter models…

Thanks,

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

From: Feras Al-Hawari 
[mailto:feras@xxxxxxxxxxx]<mailto:[mailto:feras@xxxxxxxxxxx]>
Sent: Monday, January 23, 2012 2:22 PM
To: Muranyi, Arpad; 'IBIS-ATM'
Subject: RE: [ibis-macro] Re: Analog Buffer model - the User's viewpoint

Supporting IBIS-ISS (when ratified) by various simulators might take a while 
(may be years in some cases). On the other hand, most simulators have their own 
ways to consume Touchstone files. So referencing a Touchstone file 
independently from the IBIS-ISS wrapper would eliminate that language barrier 
as Touchstone is fully supported by both model and tool makers.

Feras

________________________________
From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> 
[ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad 
[Arpad_Muranyi@xxxxxxxxxx]
Sent: Monday, January 23, 2012 12:15 PM
To: 'IBIS-ATM'
Subject: [ibis-macro] Re: Analog Buffer model - the User's viewpoint
I have a little problem with the words “BIRD 144 (that COMPLEMENTS BIRD 116)”.
As far as I can tell, aside from the user defined corner idea, BIRD 144
is a SUBSET and not a COMPLEMENT of BIRD 116.  That also goes for the
“intrinsic model” ideas in BIRD 122.

I fully understand the benefits of shorthand and similar simplifications,
but as Todd pointed out, these come with a price.  The spec gets more
complicated, the parser and tool implementations get more expensive.
Is it worth doing this if the end result is the same, i.e. no benefit
in the model’s accuracy, or the simulation results?

By the way, while it is true that such a shorthand notation might
make the model maker’s life simpler in some ways, isn’t the more
complicated specification going to achieve the opposite?  Is the
model maker going to understand clearly how they should write their
models when there are multiple ways to write otherwise identical
models?  Are they perhaps going to make more mistakes because they
have no clue why there are two ways to the same thing?

Thanks,

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

From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> 
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]<mailto:[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]>
 On Behalf Of Feras Al-Hawari
Sent: Saturday, January 21, 2012 3:38 AM
To: wkatz@xxxxxxxxxx<mailto:wkatz@xxxxxxxxxx>; Ambrish Varma; 'IBIS-ATM'
Subject: [ibis-macro] Re: Analog Buffer model - the User's viewpoint

Todd and Walter,

We all seem to agree that S-parameters is the way to go to model proprietary 
and more generic circuits. Therefore, we proposed BIRD 144 (that COMPLEMENTS 
BIRD 116) to:

-          Make referencing Tstone files much easier (i.e., without the need 
for circuit wrapping). So why wrap it if it standard and it can be used 
directly. As Ambrish said if you need to wrap your model, then you can use BIRD 
116.

-          Allow using Tstone with/without the AMI block as we allow 
referencing it from either an External Model (if it represents an LTI  Tx or 
Rx) and/or External Circuit (if it represents RDL, ODT, package, etc)

-          Allow referencing many Tstone files that correspond to many user 
defined corners. This will allow the user to control  the output swing and EQ 
settings, for example, as suggested below

We are aware that user defined corners apply to other IBIS blocks, so our plan 
was to introduce it in a simple way with respect to Tstone files. And then if 
the IBIS committee likes the idea, our plan is to extend it to cover all the 
applicable IBIS blocks in a separate BIRD.

Feras Al-Hawari
Cadence Design Systems

Other related posts: