Subject: Re: Model Selector

From: [email-masked] (Bob Ross)
Date: Tue, 3 Feb 98 15:20:57 PST

Atul:

You have a valid point.  I change my position.  [Model Selector]
should exist at the file scope to be consistent with the fact that
[Model]s exist at the file scope.  If we had restricted the
[Model Selector] to be constrained to a [Component] scope, then
we could have allowed two [Model Selector]s with the same name to
exist under different [Component]s.  This could be very confusing.
So like [Model]s, only unique names for [Model Selector] can
exist in a .ibs file.  Thank you for pushing back on this point.
This is being copied to the IBIS reflector for information.

Best Regards,
Bob

> Date: Tue, 3 Feb 1998 12:06:33 +0000 (GMT)
> From: "APT SOFTWARE AVENUES PVT.LTD" <[email-masked]>
> To: Bob Ross <bobr>
> Subject: Model Selector

> Hello Bob

>     Just to argue further, every model selector has a unique
> name associated with it.  So there is nothing to prevent multiple
> model selectors from being defined at the file scope. If we make
> model selectors component scope, then we preclude the possibility
> of sharing the same model selector among multiple components( as
> we do with models).

>     I must confess that my vehement arguments for making the model
> selector file scope are biased by the fact that I have already 
> implemented them such, but it would not be very difficult
> to make them component scope should you remain unconvinced :-)

> Regards

> atul

> > 
> > > 1) In the IBIS Tree diagram for Version 3.0 (which you had
> > > given me), the [Model Selector] keyword is indicated within
> > > the [Component] scope. Now, a model selector is nothing
> > > but a "stand-in" for a model and models are defined at file
> > > scope. By this logic, shouldn't a [Model Selector] be at the
> > > file scope also ?
> > 
> > In my opinion the scope of [Model Selector] should remain under
> > [Component], just as shown in the Tree diagram.  This allows a
> > different [Component] in the same file which will access similar
> > models to have a different default model and different configurations.
> > For example, a different component may not offer a reduced set of
> > selections since one of the pins controling the selection may be NC.
> >