Transcript ppt
User defined measurements and test loads in IBIS IBIS Cookbook / Futures Committee May 6, 2004 Arpad Muranyi Signal Integrity Engineering Intel Corporation [email protected] Outline Concept Implementation List of existing keywords 6/23/2003 *Other brands and names are the property of their respective owners Page 2 Concept Measurements associated with driver and / or receiver models can only measure localized quantities for example, driver to receiver flight times can only be done by tool however, the definition for what triggers the flight time’s starting and ending points can / must be defined “locally” for the driver / receiver model “Local” measurement types: threshold or Vmeas crossing in a receiver or driver, resulting in a simple event flag time value (of event) rise/fall/(either) which level was crossed (if multiple levels defined) serial number of event (1st, 2nd, 3rd, etc…) “find when” when does the waveform have a certain value (min., max., avg., any given value), slope, integral, etc… within a window what is the waveform doing at a given voltage / current / time / frequency, etc… within a window these are not buffer specific measurements and could also be done by the simulator, so should we leave them out? 6/23/2003 *Other brands and names are the property of their respective owners Page 3 Implementation Have “probe model(s)” and “load model(s)” written in *-AMS Call it (them) from the same level as [External Circuit] makes reusability more flexible if nothing is passed down, use internal defaults Parameters should be overridable by tool GUI this provides reusability and efficiency these models could also be written inside the buffer model(?!?) Pass parameters into it (them) when called using *-AMS provides flexibility attach to one or more nodes to obtain voltages and/or currents allow usage of simulator variables (time, frequency, etc…) define type of simulation that activates the model (DC, TD, FD) a load model would automatically invoke a duplicate of driver model in case user wants something else that is written on the calling statement (or inside the model as default) Results are picked up by tool and post processed if necessary this is the most difficult part… should we have a set of predefined, required results? can we leave this up to the probe model writer? 6/23/2003 *Other brands and names are the property of their respective owners Page 4 Existing measurement and test load keywords Keyword: Sub-Params: [Component] Si_location, Timing_location Keyword: Sub-Params: [Diff Pin] inv_pin, vdiff, tdelay_typ, tdelay_min, tdelay_max Keyword: Sub-Params: [Model] Model_type, Polarity, Enable, Vinl, Vinh, C_comp, C_comp_pullup, C_comp_pulldown, C_comp_power_clamp, C_comp_gnd_clamp, Vmeas, Cref, Rref, Vref Keyword: Sub-Params: [Model Spec] Vinh, Vinl, Vinh+, Vinh-, Vinl+, Vinl-, S_overshoot_high, S_overshoot_low, D_overshoot_high, D_overshoot_low, D_overshoot_time, Pulse_high, Pulse_low, Pulse_time, Vmeas, Vref, Cref, Rref, Cref_rising, Cref_falling, Rref_rising, Rref_falling, Vref_rising, Vref_falling, Vmeas_rising, Vmeas_falling, Rref_diff, Cref_diff Keyword: Sub-Params: [Receiver Thresholds] Vth, Vth_min, Vth_max, Vinh_ac, Vinh_dc, Vinl_ac, Vinl_dc, Threshold_sensitivity, Reference_supply, Vcross_low, Vcross_high, Vdiff_ac, Vdiff_dc, Tslew_ac, Tdiffslew_ac Keyword: Sub-Params: [Test Data] Test_data_type, Driver_model, Driver_model_inv, Test_load Keyword: Sub-Params: [Test Load] Test_load_type, C1_near, Rs_near, Ls_near, C2_near, Rp1_near, Rp2_near, Td, Zo, Rp1_far, Rp2_far, C2_far, Ls_far, Rs_far, C1_far, V_term1, V_term2, Receiver_model, Receiver_model_inv, R_diff_near, R_diff_far Keyword: Sub-Params: [Submodel Spec] V_trigger_r, V_trigger_f, Off_delay 6/23/2003 *Other brands and names are the property of their respective owners Page 5