IBIS-ISS is a very substantially reduced version of full HSPICE. Even if there was a need for a translation module, it would be a fairly simple one compared with a full (H)SPICE parser... Thanks, Arpad ================================================================ From: Feras Al-Hawari [mailto:feras@xxxxxxxxxxx] Sent: Monday, January 23, 2012 2:38 PM To: Muranyi, Arpad; 'IBIS-ATM' Subject: RE: [ibis-macro] Re: Analog Buffer model - the User's viewpoint 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<mailto: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]<mailto:[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