Let me clarify my last email. I completely agree with the solution you
proposed below and as you know I have been an advocate of using SPICE syntax
instead of the current IBIS syntax to document the gate characteristics. I
just don't know how successful we will be in convincing the IBIS pundits to
change the syntax at this late stage in its development.
If SPICE tools could be extended to read IBIS specs without translation,
then SPICE users could benefit from the large number of IBIS models that are
being released, now and in the future. Another solution would be to offer
the IC vendors a translation tool so that they may publish gate behavioral
characteristic in both IBIS and SPICE syntax. The only criteria are that the
SPICE syntax used should be as universal as possible and be supported by
SPICE from multiple vendors and the translator is updated to the current
IBIS specification. Andrew Ingraham's solution would ensure one model could
be used by IBIS simulators as well as SPICE users.
On reflection, the problem I see with Andrews suggestion is the IBIS
standard is continuing to evolve and so it would be difficult for the SPICE
vendors to keep current with these changes. The beauty about SPICE is that
engineers can make changes to their models as the IBIS adopts new
specifications. Engineers won't have to wait for an update to their IBIS
extensions or wait for an updated IBIS translator.
Regards
John Synesiou [email protected]
U.S. Power, Inc Phone (612)826-1111
6497 City West Parkway Fax (612)826-1003
Eden Prairie Date: 04/03/98
MN, 55344 Time: 3:16 PM
I'm not sure what are IBIS extentions? IBIS is just a data sheet that
gives electrical information useful for SI work. Every vendor Spice or
other must then take that data sheet and convert it into a model. Now
some simulators take in table data like that produced by IBIS. And
believe it or not some of those vendors are Spice vendors. But actually
what your'e looking for is an SI solution. As I mentioned before there
is a proposal from EIA in Japan that essentially attempts to standardize
a table spice format. That format is very compatible with IBIS. In fact
IBIS would do well to adapt it. Many of the "birds" and issues of
flexibility, capability and accuracy would go away with this standard.
The standard describes the transistor in table format. No propietary
data is included. The difference between that spec and IBIS is that
this spec is general since its at the transitor level. For IBIS lovers
the data for the I/V is still retained so in essense IBIS becomes a
subset at least for the technical part. Then everybody would be happy
since Spice guys can still use the topologies allowed by Spice and the
transistor data would be there. The data shows nothing of process so
IC vendors would be happy. Current IBIS users should be happy because
the data they want would still be there and non spice vendors who do
not care for transistor level data could make use of the information
that's already in the spec. As those guys become more sophisticated in
their modeling technique they could start incorporating information
about the Gate for example. Which is a BIG problem in IBIS at the
moment.
Now what's wrong with this. Can anybody please explain to me why this
should not be implimented? Certainly from a technical standpoint this
would be a great standard. Lets here from both the IBIS and Spice fans
on this one.
Best Regards,
-- Fred Balistreri [email protected]