Re: IBIS BIRD41.2 Modelling Series Switchable Devices

John:

Thank you for reviewing BIRD41.2. As a consequence of your comments,
I am issuing BIRD41.3 seperately.

Some detailed feedback is embedded in your comments.

To summarize here:

1. I plan to keep the voltages ranges as defined. It is expected
that extrapolation of data will be done when physical (or even
simulation) current limits are reached. There is some justification
for keeping the [Series MOSFET] as defined - given below.

2. The intent was to allow any of the defined parallel elements
through the existing [Pin] keyword model allocation. It is necessary
to allow defining INDEPENDENTLY parallel elements on EACH side of a
series device. [Series MOSFET] switches have capacitance on each
side and may have Schottky diodes on each side. A note will be made
in the [Series Pin Mapping] keyword rules.

3. I have changed the [Series Pin Table] (and [Series Function Table])
keywords to [Series Switch Groups] as you suggested.

4. I have added clarification concerning certain series resitive and
inductive elements are considered shorted, if not entered.

5. You made a suggestion regarding Series_switch models having a
provision for common keywords such as [C_series] positioned above
the [On] and [Off] keywords. I disagree and believe this should be
flagged as an error. I would rather force the keyword to be
repeated. That avoids the confusion of, for example, [C_series]
appearing both above [On] and below [On]. A whole set of rules
which no-one would remember would have to be developed as to which
prevails, or how they are added, etc.

In addition, I have added statements that C_comp is ignored for the
Series models. C_comp is documented as a capacitance two ground, I
prefer not to introduce a dual meaning.

Best Regards,
Bob Ross
Interconnectix

> Date: Thu, 15 May 1997 11:11:29 +0200
> From: John V Fitzpatrick <John.Fitzpatrick@ln.cit.alcatel.fr>
> Organization: Alcatel Telecom, Lannion, France
> To: Bob Ross <bob@icx.com>
> Cc: ibis@vhdl.org
> Subject: Re: IBIS BIRD41.2 Modelling Series Switchable Devices

> Bob,

> Excellent work! The new Bird seems to cover all important issues,
> especially how to model those infamous FET switches.

> I'm not competent enough to give detailed comment on your
> HSpice model: just happy that the model is derived from simple
> tables. (Bench measurements of a FET device will be trickier
> than for simple I/V measurements with a fixed load, but I can live
> with that).

> I hope that, before voting tales place, at least one other
> simulator company will confirm to the reflector that they will
> use this model.

> Comments on some minor points are included below.

> Once again, thanks agin for pushing though this Bird.

> All the best,
> John

> _________________________________________________________________

> Comments:

> 1) Voltage ranges

> | [Series Current] GND - POWER GND + POWER
> | [Series MOSFET] GND GND + POWER

> Ok for [Series Current]. This is exactly as for [GND Clamp], with
> the same problems of excessively large current values.
> (Would it be useful in IBIS 3 to introduce the notion of a maximum
> current, possibly set by the model creator?)

Good idea. However, I believe that if data is not measurable or
simulated, it still can be extrapolated. So I have not added
any current limit statement at this time.

> However, for [Series MOSFET], the limits should be from
> GND-POWER to POWER+POWER. The upper range is important,
> because a series MOSFET is often used to clip signals
> e.g. in 5V to 3.3V conversion.

For On state Series MOSFET models, when the source voltage (Vs) reaches
the POWER rail, the switch is in a very high impedance state. Extending
the table beyond the POWER rail will not significantly increase the accuracy.
The drain side actually extends beyond the POWER real by a large
amount because the table is not used directly. It is used to generate
an equation relating any Vds value to any Ids. So the table is used
to generate data that really goes further than POWER.

Regarding the GND limit, the Series MOSFET switch is in the lowest
impedance state. There may be cases where undershoots may exist on
both sides of the switch. Even if the equation for Vds and Ids is not
based on extrapolated data, the accuracy will still be very good at
the low state.

These limits represent minimum range limits. Based on specific situations,
the model supplier is allowed to provide data beyond the limits. One
practical issue, however, is that some of the clamping actions may
prevent getting good data beyond the limits.

> 2) Parallel elements

> The Bird does not explain how to treat parallel elements e.g.
> C_comp, GND and POWER clamps, RC terminations. In fact, it would
> appear to disallow the combination of series and parallel elements
> (with the exception of C_comp?).

> I think that parallel elements should be allowed, and be defined
> to exist at Pin 1:

> -+- POWER
> |
> +-+-+
> | | clamp or RC termination
> | |
> | |
> +-+-+
> Pin 1 | +-----------+ Pin 2
> ------+---------------+--+ Series +---------
> +-+-+ | +-----------+
> | | Clamp or |
> | | RC term- --+--
> | | ination --+-- C_comp
> +-+-+ |
> | |
> -+- GND -+- GND
>

> Aside:
> I think it would be complicated to allow parallel elements on
> both sides of the series element. There would be however one
> potential application for this: the simple connector model we
> all use:

> +--------+
> ------+--+ L, R +-----+-------
> | +--------+ |
> | |
> --+-- --+--
> --+-- C --+--
> | |
> | |
> -+- GND -+- GND
>

The intention is to allow all of the parallel elements you suggest, an
more to be assigned on EACH pin using the existing [Pin] keyword
list of pins simutaneouly with the [Series Pin Mapping] keyword.
This represents a real situation associated with [Series MOSFET]
devices with capacitances on both pins and also clamps on both pins.

A note is made in the [Series Pin Mapping] keyword t state this.

> 3) Function table

> Two names are used for the function table:
> [Series Function Table] and [Series Pin Table]

> I think the first name is the better, but because the defined
> states are ON or OFF, the name should include the word "switch"
> e.g. [Series Switch Groups]

I have made the change to [Series Switch Groups] per your suggestion.

> 4) RLC model

> In the example, it is clear that, if not defined, R_c_series,
> L_c_series and R_l_series are short-circuits. Perhaps this should
> also be explained in the text?

I have added notes, per your suggestion.

> 5) [On] and [Off]
>
> State that keywords common to both [On] and [Off] should
> appear before the keywords [On] and [Off].

> Example:
> If a switch has a constant [C_series] part, must it appear twice
> (after each of the [On] and [Off] keywords) or once (before the
> [On] and [Off] keywords)?

I disagree with this interpretation and suggestion because it can
cause confusion and complication if the same keyword is defined both
above and below [On] or [Off]. It is easier to require [On] or [Off]
to be first. I have added a statement in the [On], [Off] keyword
preventing certain keyword to be above [On] and [Off]. [C_series]
will be required twice, if needed, but it can contain different
values for the On and Off states.

>

>

> --
> John Fitzpatrick <John.Fitzpatrick@ln.cit.alcatel.fr>
> Alcatel Telecom, 4 rue de Broglie, 22304 Lannion, France
> Tel: +33(0)2.96.04.79.33 Fax: +33(0)2.96.04.85.09

 
Received on Thu May 15 18:06:46 1997