Why? -- Ibis problems (History) -- Birds This need for change is evident by the "Birds", 66 so far, making small changes to this assumed circuit topology. Lately, these have focussed on receiver modeling. It would be nice if the vendors could do this themselves. -- We like Ibis. For all this, Ibis still provides a way to specify a part, based mostly on external measurements. ======================================================================= Review -- a macro language that allows extensions to IBIS -- backward compatible -- can express all of IBIS 3.2 in it. -- User defined extensions ======================================================================= How? -- Define the circuit topology using Spice like constructs, with a few programming language-like extensions. This is familiar to those developing the top level models, and fits well to the way a circuit designer sees the problem. -- Parameterize it as we do now. The only change from the existing IBIS is to generalize it. With the correct topology description, all of the existing IBIS constructs work as they have, and new ones can be added by the model developer. -- Provide a library of compatibility models. Use them for all our existing IBIS files, and as a starting point for new ones. A simple change to an existing model may be all you need. ======================================================================= Example 1 -- A simple terminator, with clamps. (schematic 1) ======================================================================= Example 1 [Define Model] Simple_Terminator (pin gnd power_clamp_ref gnd_clamp_ref) Rpc (power_clamp_ref pin) I = Clamp[V] Rgc (pin gnd_clamp_ref) I = Clamp[V] Rterm (pin gnd) R = Rterm || open [End Define Model] It looks a lot like Spice to me. What's different? First, the frame [Define Model]..... This defines a new "Model_type" called "Simple_Terminator". It has 4 connections ... (pin gnd power_clamp_ref gnd_clamp_ref). I am assuming the power comes from outside somewhere. Let's look at the [Model] section. The connections, on the define model line, are bound by name. Pin is "the pin", gnd is, well ... "power_clamp_ref" is connected to what is specified under "Pin Mapping". ======================================================================= Example 1 [Model] term_1 Model_type Simple_Terminator [Rterm] 50 45 60 [Clamp] -5 900m 800m 1100m -4 700m 600m 802m -3 500m 400m 580m -2 300m 200m 480m -1 100m 90m 170m -.8 60m 50m 90m -.7 39m 28m 44m -.6 22m 11m 27m -.5 10m 0 15m -.4 0 0 4m -.3 0 0 0 0 0 0 0 This looks almost like the model section of an IBIS file that we are all used to. "Almost" is because of the new names, which I have defined on the last slide. See the "Model_type"? ======================================================================= Going back to the previous slide .... "I = Clamp[V]" says that there will be a table called [Clamp]. "V", the voltage across this "resistor" is the independent variable, and it returns the entry from the table as "I". with interpolation as expected. So, it defines the V-I characteristic of this "resistor". To keep it short, I used the same table for the ground clamp as power clamp. For this type of model, it is a "required keyword". "R = Rterm" without the [V] says that Rterm is a scalar value, which is used as the value of the resistor. The "|| open" part of the line says that this keyword is optional. If it isn't there, just leave this resistor out. (open). No other keywords are allowed for this model type. To use this model, you need to make all 4 of these connections. What if we don't have the clamp_ref's supplied from outside. Perhaps there isn't a [Pin Mapping] section. We need to supply the voltage internally, but only when we need it. ======================================================================= Example 1a [Define Model] Simple_Terminator (pin gnd power_clamp_ref gnd_clamp_ref) .if (!power_clamp_ref) .local power_clamp_ref Vpcr (power_clamp_ref gnd) V = POWER_Clamp_Reference || Voltage_Range .endif .if (!gnd_clamp_ref) .local gnd_clamp_ref Vgcr (gnd_clamp_ref gnd) V = GND_Clamp_Reference || short .endif Rpc (power_clamp_ref pin) I = Clamp[V] Rgc (pin gnd_clamp_ref) I = Clamp[V] Rterm (pin gnd) R = Rterm || open [End Define Model] We can add the voltage sources, but only when they are not supplied to us. (if (!.....)) We declare the node as local, then supply the voltage. Things that can't be identified by their first letter, like commands, start with a dot, like Spice. I suppose I could have just used the node, but having the .local declaration guards against errors. With this model, pin and gnd are required connections. The clamp_ref's are optional. ======================================================================= ======================================================================= ======================================================================= ======================================================================= ======================================================================= ======================================================================= ======================================================================= Why? -- Ibis problems (History) -- Birds This need for change is evident by the "Birds", 65 so far, making small changed to this assumed circuit topology. It would be nice if the vendors could do this themselves. -- We like Ibis. For all this, Ibis still provides a way to specify a part, based mostly on external measurements. ======================================================================= Why not? -- Spice format is good when you want to describe a circuit. That's what we are doing, isn't it? Not really. We want a specification language, based on a model. This approach provides the benefit of a Spice format, while maintaining the ability to present it as a spec list. -- IMEC is really just a variant on the Spice format. We want a specification language........... -- VHDL/Verilog-AMS is a specification language, isn't it? Too general. We want to give specs based on measured data..... ======================================================================= Example 2 -- A simple driver (schematic 2) This one is just a voltage source with a series resistor, sort of. It has this open circuit waveform, and this output resistance, varying with time. We all know the output resistance is higher during the transition. ======================================================================= Example 2 [Define Model] Simple_Driver (pin gnd control) .local t1 Vsource (t1 gnd) V = Rise[T-TR] || Fall[T-TF] Rsource (pin t1) R = Rsource[T-TR] || Rsource[T-TF] .trigger TR (Logic(control) == 1) .trigger TF (Logic(control) == 0) [End Define Model] This one is not as powerful as we have now, but it sure is simple. You characterize Vsource into an open circuit, with rising and falling waveforms, then measure it with a load and ohms law will give you the dynamic series resistance. There is a new "component" called a trigger. It remembers the time when some condition becomes true. In this case, TR is when I tell it to start rising, and TF is when I tell it to start falling. So, the voltage source is determined by the two tables "Rise" and "Fall" depending on the triggers. ======================================================================= Example 2 [Model] driver_1 Model_type Simple_Driver [Rise] 0 0 1n .5 2n 1 3n 2 4n 3 5n 4 6n 4.5 7n 5 [Fall] 0 5 1n 4.5 2n 4 3n 3 4n 2 5n 1 6n .5 7n 0 [Rsource] 0 10 1n 100 2n 1k 3n 10k 4n 10k 5n 1k 6n 100 7n 10 Here is the [Model] part of the IBIS file. Again, the form is familiar, but the keywords are new. ======================================================================= Example 3 [Define Model] Clamped_Driver_with_Ccomp .inherit Simple_Terminator .inherit Simple_Driver Ccomp (pin gnd) C = C_comp || open Cpc (pin power_clamp_ref) C = C_comp_pcl || open Cgc (pin gnd_clamp_ref) C = C_comp_gcl || open [End Define Model] To save needless repitition, a new model type can inherit from another. In this case, I have made a clamped driver by combining the two models I have already defined. It is as if I had retyped both of them here. Of course, I can add regular components, too. The extra C's are for Arpad. ======================================================================= Compatibility -- Waveform, pullup, pulldown interactions -- Series Switch [On] [Off] -- Correlation (typ, min, max) -- Attachments (Add Submodel, Driver Schedule) It's a nice driver, but not compatible with what we now have in IBIS. This proposal addresses all of these compatibility issues, allowing us to define the entire IBIS 3.2 [Model] and [Submodel] sections in this language, for backward compatibility. Several files could exist, so we can have all of the previous. For correlation, we have a ".correlate" statement, that lets us say what "fast", "slow", "strong" and "weak" (and any new ones we might need) really mean. The attachments are easy as subcircuits, but for compatibility we need some text processing, language tricks that I won't show here. The series switch needs a run time conditional, that I won't show here but it is in the handout. The waveform requires a special part, that really exists primarily for compatibility. See the next slide. ======================================================================= Example 4 [Define Model] 3-state .inherit model_base | Some parts left out for clarity .driver Udrv (pin gnd pullup_ref pulldown_ref tr tf en) ( S1 = Pullup[-V], S0 = Pulldown[V], T10 = Falling_Waveform[T-TF,*] || [Ramp]dv/dt_f, T01 = Rising_Waveform[T-TR,*] || [Ramp]dv/dt_r, V1 = Pullup_Reference || Voltage_Range, V0 = Pulldown_Reference || 0 ) .trigger TR (Logic(control) == 1) .trigger TF (Logic(control) == 0) .correlate strong/weak=max/min Pull* .correlate fast/slow=max/min *Waveform, [Ramp]* [End Define Model] Here is the actual code to do our existing 3-state model, with some parts left out to minimize the clutter. There is a new part called a "driver", that looks up those tables. The form of the tables is defined by the driver. The names are given when we use it, as I did here. This way, we have some flexibility in how to use it. The same part is also used in the Bus Hold. I don't have to show you what the [Model] looks like for this one. ======================================================================= What components? -- Spice R, L, C, V, I, E, G -- Some-Spice extras vcr, vcg, vccap -- No-Spice driver, trigger, alarm -- Programming assert, define, export, if, inherit, local, select ======================================================================= So, What have I done? -- A new section [Define Model] that could be in an IBIS file, but more likely it would be included or referenced somehow. -- describe topology of a [Model] or [Submodel] In it is a description of the topology of a [Model] or [Submodel], using elements like the simple ones in Spice, plus a few, plus some logic constructs. ======================================================================= =======================================================================