Chris,
Thanks for the clarification. I reread the section you pointed out to me
(several more times) and I believe I am starting to understand the problem.
It seems to me that the problem is not that I am using the series model
together
with a terminator model, but that these were "coupled" as a differential
pair.
You made a statement that "the Diff Pins had to be NON-terminators" (I guess
Input, I/O, etc...). Looking at the [Diff Pin] section of the spec,
however, I
could not find anything that suggests that differential pins had to be a
certain
type of a model. Also, I don't see anything in the [Diff Pin] section that
calls a [Model](s) for the pins it defines as differential. The [Model]
keywords are still referenced only by the pin list section (some times
through
the [Model Selector] keyword) even if we have a [Diff Pin] definition for
them.
In my opinion then, it would be perfectly legal (even if it makes no sense)
to
have two pins in the pin list defined as "NC" while defining them as
differential pairs in the [Diff Pin] section. If this is legal then calling
Terminator type models in the pin list and defining them as differential
pairs
should also be legal.
Using this argument I would summarize that the model we made is NOT
violating
the spec. because
1) The pin list calls a model that is type Terminator
2) Terminator model types are legal with Series models
3) Applying the [Diff Pin] keyword does not change the model type
already defined on the pin list to anything else
3) Applying the [Diff Pin] keyword does not add models of any type
to the models already defined on the pin list
4) There are no restrictions for what model types can be associated
as differential pair in the [Diff Pin] section
Please let me know whether this argument is acceptable or not.
Sincerely,
Arpad
============================================================================
====
Arpad,
> 1) Could you please point it out to me where the spec says that it is NOT
> allowed to have anything, except terminators on either side of the series
> device? I don't recall reading that, but might have missed it.
Yes, from ver3_2.a.ibs, see 2nd paragraph under Other Notes, sentence #2
below.
<snip>
| Keyword: [Series Pin Mapping]
<snip>
| Other Notes: If the model_name is for a non-symmetrical series model,
| then the order of the pins is important. The [Series
Pin
| Mapping] and pin_2 entries must be in the columns that
| correspond with Pin 1 and Pin 2 of the referenced model.
|
| This mapping covers only the series paths between pins.
The
| package parasitics and any other elements such as
additional
| capacitance or clamping circuitry are defined by the
| model_name that is referenced in the [Pin] keyword. The
| model_names under the [Pin] keyword that are also
referenced
| by the [Series Pin Mapping] keyword must be either 'NC'
or
| reference a [Model] whose Model_type is 'Terminator'.
Thus.
| for example, a Series_switch model may contain
Terminator
| models on EACH of the pins to describe both the
capacitance
| on each pin and some clamping circuitry that may exist
on
| each pin.
<snip>
> 2) Our device which has this situation actually does sense the signal
> differentially, but since it never drives and the clamps are so far out
from
> the
> signal swing, we didn't include a receiver model (even though I was
> considering
> to do it).
We've never had to model "paths through active devices" so that is where
the problem comes in where a single pin is defined as both a recevier
(customarily terminating the signal) and defined as a passive series
device to another pin.
However using only the [Series mapping] only will work A.O.K for us as
you state in #3 below assuming another component on the board joins
these two nets differentially.
> 3) It may be sufficient to define [Series mapping] only if we didn't have
a
>
> receiver in the device.
>
> Since we just made an IBIS model like that, you got my curiosity up, is it
> really illegal to do this? By the way, it passed the parser, so if it is
> illegal, should the parser check for that?
The part I thought was illegal was the tying of a single pin together
with other pins using BOTH [Series Mapping] and [Diff Pin] since the
Series pins could only be terminators but the Diff Pins had to be
NON-terminators.
The parser should check.
It sounds like you may wish to propose a BIRD to allow this type of
thing in the future in which case we will enhance the capabilities of
our software to handle. Its just never come up before. There's always
been a buffer between Input and Output allowing us to decoupling the two
sides of the analysis.
Chris
Received on Fri Oct 9 09:38:30 1998
This archive was generated by hypermail 2.1.8 : Fri Jun 03 2011 - 09:52:30 PDT