The new Ibis???? First cut at the language reference manual. ==================================================================== History Ibis began as a way to model particular types of devices, for interconnect simulators, in such a way as to allow the interconnect to be analyzed and simulated without disclosing much about the drivers and loads. It assumed a circuit topology, and supplied parameters for it. In time, we have outgrown it, and it seems we are constantly adding to the model. Each change requires committee approval, implementation in several simulators. Meanwhile, the chip vendor waits. Also, by doing it once, we have all learned how to do it better, but we are stuck with a lot because of backward compatibility. ==================================================================== Summary This proposal is for a macro language that hopes to provide a way for vendors to make new topologies as needed, while at the same time providing backward compatibility by defining the old spec in the new macro language. The macro language describes a circuit, Spice like, with parameters and a little program logic. The parameters refer to tables, values, or formulas in a separate section, whose syntax matches the existing Ibis "Model" and "Submodel" sections. The language can be pre-processed to produce a netlist type description suitable for simulation in a nodal simulator with limited nonlinear capability. A standard library of macro models is considered to be part of the language, in the same sense that "printf" is part of C. This standard library provides the functionality we now have, and is a base for customization. Most devices will use the standard library, which provides the functionality of IBIS-3. In time, more will be added as the need arises for other basic model types. Then a modified [Model] section will fill in the values. All of the currently pending "Birds" that apply to the Model or Submodel sections can be represented in this format, thus would require no committee action to use. ==================================================================== Definition of the language A new section is added [Define Something], where Something is probably Model or Submodel, ending with [End Define Something]. The contents is a list of elements and pseudo elements that could make a Spice style netlist, with parameters. The header line contains [Define Something] followed by a name of the something to be defined, and its connection node list in parenthesis. Example: [Define Model] series (pin1 pin2) starts a definition of a model with model type of "series", which has 2 connections: pin1 and pin2. Elements to provide: Spice compatible: Resistor (R) (defines v = f(i) or i = f(v)) Capacitor (C) (defines q = f(v)) Inductor (L) (defines flux = f(i)) VCVS (E) (defines Vout = f(Vin)) VCCS (G) (defines Iout = f(Vin)) Isource (I) (defines fixed I) Vsource (V) (defines fixed V) Subckt (X) (used for submodel, driver schedule) Extended, Spice like (available in some Spice's): Voltage controlled Resistance (VCR) (defines R = f(v)) Voltage controlled Admittance (VCG) (defines Y = f(v)) Voltage controlled Capacitance (VCCAP) (defines C = f(v)) Extended, beyond Spice: Trigger (activates anything time dependent) Alarm (sends a notice when something happens) Driver (a complex device for backward compatibility) Reshape (generates a digital pulse, reshaped from its input) Note: all values can also be functions of time and temperature Extended elements are specified by a "dot" line, which is optional for the basic lines, and allowed to provide a consistent syntax. Basic syntax for simple elements: