Re: BIRD41.1 Comments

John and IBIS Committee:

John, thanks for going over the commments in detail. You raise
some questions which I do not have a answers for yet, and I am
still thinking about some various alternatives - and learning
more about the switch operation.

I also think that a good, tested FET switch model is necessary
for accurate simulation. I would accept a less than "perfect"
model that would be suitable at a "reasonable" level of accuracy
in a transmission line simulation enviroment.

I will put my specific comments or questions in your comments.
As you will see, I feel many issues are still open.

Best Regards,
Bob Ross
Interconnectix

> Date: Mon, 07 Apr 1997 18:05:47 +0200
> From: John V Fitzpatrick <John.Fitzpatrick@ln.cit.alcatel.fr>
> To: ibis@vhdl.org
> Cc: bob@icx.com
> Subject: Re: BIRD41.1 Comments

> To Bob Ross and IBIS Forum:

> Thanks to everyone (especially Bob) who contributed to the
> 41.1 debate in my absence.

> Below are my views on the different comments received.

> But first, a question:
> Will this Bird allow sufficient information be
> included in IBIS to build a good behavioural
> model for a FET switch?

> I've tried to build a model using PSpice, but have not
> fully succeeded (yet).

> In my opinion, no vote should be taken on 41.1 until at
> least one company (preferably a simulator company)
> confirms that it can build a model, and then publishes some
> simulation results on the reflector.

> I'll submit an up-to-date version of Bird 41 later in the week
> taking into account the comments received so far.

> Regards,
> John

> My comments on comments:
>
> > Keyword: [Series Pin Table]

> I like Bob's proposal (except for the trailing slashes - could
> they not be made optional?).

I also do not like the trailing slashes, but the reason for them was
to allow multiple lines, if necessary, to conform with the 80
characters/column limit.

> Although I agree with Arpad that we risk putting too much "logic"
> into IBIS, might that not be a necessary risk? If buffers can
> be programmed by external pins, then why not say so in the
> IBIS model?

> example:

> [Buffer Modes]
> |Fnl_Group Mode control_pins
> 1 On 1 2 | by default, is Off for other combinations
> 2 On 1# 2
> 3 On 1 2#
> 4 On 1# 2#

> Hey, this looks like a truth table!
> But its scope is very limited - only buffers whose mode
> can be set by external pins.
> This would be a more compact solution than Bob's, and
> might be extendable to improve Bird 30.2.

I have to think about your alternative "truth table" IBIS does not
explicitly identify the control pins for any buffer, so the information
could be any text string. One test is to try the syntax on a variety
of switch parts. The objective of the table is to give one of
several choices for switch settings of the complete part so that
the choice can be selected via a simulator interface. The idea
of letting all other settings by default be Off (or On if Off is
defined) is good and makes the notation clearer.

>
> > 1. Is non-symmetrical operation really needed? It will lead to
> > problems in other areas.

> No, but what problems?

The problems I was thinking of was with respect to decide which
model direction you are going. Does a falling signal require
a different model than a rising signal? I do not think this
complication is necessary - especially if there is ringing at
the switch. I think this all can be worked out with one model
with bi-directional operation.

> It's important to define which side of the buffer is used to
> make the measurements. I'll drop the reference to
> non-symmetric devices.
>
>
> > 1. Just [Rseries], [Lseries], and [Cseries] are needed. The
> > proposed [R_c_series], [L_c_series] and [R_l_series] additions
> > are unnecessary.
> > All series elements should be allowed to be connected in
> > series,

> This is not sufficient. For example, there may be a parasitic
> capacitance in parallel with Rseries.

I was thinking of a simpler approach without the generalized set
of parallel/series constructs available with your proposal. Your
more generalized set of elements actually looks attractive. However,
I do not know if that is too much of a complication for many simulators.
The [L_c_series]-requires-an-[L_series] rule initially looked
like an unnecessary complication to me, but I now see the logic of what
you did and your intentions.

> (An alternative solution would be to adopt a Bird36-like notation).

Probably not as good a solution.

>
> > 2. The [Series Impedance] table can also be connected in series.

> I disagree.

> The only element that could be put in series with [Series Impedance]
> is [Lseries]. With [Cseries], no DC measurements can be made.
> With [Rseries], there would be a risk of double counting.
> And what about a parallel parasitic capacitance?

There are two ways to view the [Series Impedance] table. The
proposed way is a VI curve. If both the I and V are defined
as ACROSS the device (such as with a series diode) then most anything
could be put in series - even a capacitor. (The DC bias conditions
would be handled on each side of the capacitor.)

For a series FET, the "resistance" (or the VI table) is a
function of the minimum of the input or output voltage with respect
to the control Gate. So a new "[Series FET Impedance]" could be a
resistance as a function of a calculate minimum voltage (calculation
may be done by iteration). One complication with this approach is
that if [Rseries] is defined, it is important which side of the
switch the [Rseries] is put. The same would theoretically apply
for an [Lseries]. So perhaps, no other Series element should be
allowed for a "[Series FET Impedance]", as you suggested.

>
> > 3. The [Series Impedance] table could be defined with a voltage
> > range of -Vcc to Vcc for closed switch operation or low
> > impedance, it could
> > also have a range from -2Vcc to 2Vcc for open operation.
> > So its range needs to be defined.

> I agree that the ranges need to be defined. -2Vcc to 2Vcc seems
> OK to me for the OFF state. However -Vcc to Vcc might be
> too much for the ON state. This is the same debate as for
> clamping diodes.
> Could we not limit the "measurements" to reasonable current values?
>

Here I am thinking of voltage across the switch. I do not know
if this is the correct way to look at the switch. The extremes
of the range could be satisfied by linear extrapolation. I still
do not know the best answer.

>
> > 4. R_load is not needed.

> I disagree.

> R_load is needed to properly characterize a FET switch.
> An interesting feature of these switches is that the
> series impedance increases as the "input" signal
> approaches the gate voltage level. I suggest that you
> need a Rload of at least 10 X "on-resistance" to be
> able to measure this.

> I'm open to alternative suggestions. But this is the
> only way I can see to reproduce the nice Vin. vs. Vout
> curves given in the bus-switch databooks.

> Perhaps we should explicitely define a series model
> called FET_switch?

The R_load issue relate to the previously mentioned problem
that the switch characteristics from input to output relate
to the Gate-to-minimum-(Drain or Source)-voltage. The R_load
may be one way of parameterizing this relationship, but I
do not know how to use it for actual simulation. I think there
are better ways to describe this. I was thinking of just
R as a function of input voltage as one way for the purposes
of providing an adequate model. Maybe a set of IV tables is
necessary where V is the voltage across the device (both
directions), and the set is a function of minimum fixed
Source or Drain voltage.

>
> > 5. Also the Mode subparameter could be dropped. This could be
> > handled another way for actual switches.

> OK, I'll change the Bird to include the new suggestion.
>

>
> > 1. What does C_comp mean in a series model?
> > 3. Should the Series Pins be used for Differential terminations?

> The definitions of all existing passive elements remain unchanged.
> In the case of C_comp, it is a capacitance to ground, seen at the
> pin through which the measurements are made.

> Perhaps we should redine these passive (and parallel) elements,
> (except for R_pkg, C_pkg, L_pkg),
> to say that they are split 50-50 on each side of the series
> element.
> This would be better for differential terminations.

Since the package elements would apply fully to each pin of
a two-pin device, they should not be split, in my opinion.

> > 2. Should a Series Pin be used to connect to a supply or
> > ground, as proposed above?

> I don't understand the question.

This is only a possibility (and possible complication). There is
no reason why either the input or output pin of a series element
cannot be attached to a supply. This voltage could be identified.
An R-pack consisting of, say, a set of 50 ohm resistors could have any
resistor attached in series to a net or as part of a pullup or
pulldown termination. So I just raised the question.

One sample (the CBT6800Precharge) model used the switch capability
of a switch attacted to a bias voltage pin 13, as an example of
an extension for a minor precharge path that switches in when the
signal switch path switches out.

Another configuration of a series switch would be to connect pins of
different networks for differental operation. This is another
practical possibility.

>
> > 4. Can several different series pin models be connected to the
> > same pin?

> Yes, if the series element is a switch.

This is what I assumed in Cross-over and precharge cases.

>
> > Arpad Muranyi raised the issue whether BIRD41.1 should capture
> > the dynamic turn-on and turn-off characteristics of a switch.
> > Bob suggested that there
> > was sufficient complication already without this addition.

> It should be possible to reuse the rising and falling waveforms.
> But I agree there is no need for such an addition.
>

I have not ruled this out, especially if there is a simple
practical application for a dynamic adjustment. However, there
are some more fundamental questions to address.

> --
> 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 Tue Apr 8 18:55:08 1997