Arpad,
Thank you for reviewing my comments on BIRD 30. Here is my response to
your response to my comments on your BIRD. Whew . . .
I am aware that my comments on BIRD 30 would add complexity to the
models as well as possibly providing opportunity for errors to creep
in. Engineering is in many respects the art of balance and compromise
and I feel that the added functionality and flexibility that my
comments would also provide produces a net positive.
I was perhaps not sufficiently clear in my statement of my overall
purpose. I will therefore try to provide some additional
clarification.
I will begin by stating what my purpose is not. It is NOT to merely
provide the user with another set of data when he looks at a
particular I/O buffer model. Information that in all likely hood is
redundant (as you mentioned) to what is already stated in the I/O
buffer model name.
My purpose is to provide information for the various simulation tools
to enable them to help automate the selection of appropriate and valid
buffer models for signals with programmable pads. As a user I wish to
avoid having to make model assignments for a chip on a pin by pin
basis.
As a simple example (and one that I mentioned previously) take an ASIC
that has been designed for either 5volt or 3.3volt use. Let us assume
that each buffer on the chip can be programmed to operate at either
5volts or at 3.3volts. Note that the operation voltage is the measure
of commonality here; there are a number of different types of buffers
present with possibly different drive strengths and slew rates. Assume
that the chip is to be programmed for 3.3volt operation. We wish to
provide the means to select all of the 3.3volt buffers for the chip
irrespective of the fact that some of them are bi-directional and
others are output and some are input, as well as the existence of
differences in drive strength and slew rate (this becomes the problem
of allowing selection across multiple [Model selector]s based upon
some instance(s) of commonality).
I have defined the sub-parameter "Classes" to provide for the
specification of characteristics of commonality. As you mentioned this
information is generally present in the model name itself but that
there is no standard naming convention followed from vendor to vendor.
These names are therefore of little use to the tool vendors who might
wish to extract the information contained in that name. The
specification of the programmable characteristics of a buffer can most
often be represented as something akin to 5V or 3.3V, high or low,
fast or slow. For selection purposes more detail than this is really
not required.
The chip example that I mentioned above is somewhat simplistic and it
may not showcase sufficiently well the desirability of automating the
programmable buffer selection process (more than just automating, this
provides a mechanism for the programmable configurations of a chip to
be specified in the IBIS model; this will reduce the need for the
engineer to attempt to find and transfer this data from the data-book
to the IBIS model manually; from personal experience this can be an error
prone process). If we take the example from above and break the chip
into a non-programmable section, and a section programmable by voltage
and drive strength or only drive strength as allowed by the model, we
then have a somewhat more realistic situation. Given the following pin
list let us say that the following signal is programmable by voltage
and drive strength: RAS0#. The signals D[2:0] are programmable only by
voltage and the signals EN1#, A0, RD# are not programmable.
[Pin] signal_name model_name R_pin L_pin C_pin
|
1 RAS0# Progbuffer1 200.0m 5.0nH 2.0pF
2 EN1# Input NA 6.3nH NA
3 A0 Input
4 D0 Progbuffer2
5 D1 Progbuffer2 320.0m 3.1nH 2.2pF
6 D2 Progbuffer2
7 RD# Input 310.0m 3.0nH 2.0pF
| .
| .
| .
18 Vcc3 POWER
Let us show these models as the following:
[Model] ABCD0123456789ABCDE0
Model_type I/O
Classes voltage=3V;drive=H | optional parameter
Polarity Non-Inverting
Enable Active-Low
| .
| .
| .
|
[Model] ABCD0123456789ABCDE1
Model_type I/O
Classes voltage=3V;drive=L | optional parameter
Polarity Non-Inverting
Enable Active-Low
| .
| .
| .
|
[Model] ABCD0123456789ABCDE2
Model_type I/O
Classes voltage=5V;drive=H | optional parameter
Polarity Non-Inverting
Enable Active-Low
| .
| .
| .
|
[Model] ABCD0123456789ABCDE3
Model_type I/O
Classes voltage=5V;drive=L | optional parameter
Polarity Non-Inverting
Enable Active-Low
| .
| .
| .
|
[Model] WXYZ9876543210WXYZE0
Model_type I/O
Classes voltage=3V | optional parameter
Polarity Non-Inverting
Enable Active-Low
| .
| .
| .
|
[Model] WXYZ9876543210WXYZE1
Model_type I/O
Classes voltage=5V | optional parameter
Polarity Non-Inverting
Enable Active-Low
| .
| .
| .
|
[Model] Input
Model_type Input
| .
| .
| .
|
The sub-parameter "Classes" provides easily parsable information on
the programmable state of a particular model. We have the following
types of programmable buffers and use [Model selector] to group
them:
[Model selector] Progbuffer1 | voltage drive
Default ABCD0123456789ABCDE0 | 3V H
ABCD0123456789ABCDE1 | 3V L
ABCD0123456789ABCDE2 | 5V H
ABCD0123456789ABCDE3 | 5V L
|
[Model selector] Progbuffer2
WXYZ9876543210WXYZE0 | 3V
Default WXYZ9876543210WXYZE1 | 5V
The [Signal selector] keyword is used to group those nets that are
part of a common program group together. This will allow models to be
selected for them as a group EVEN THOUGH different buffer types
represented by different [Model selector]s exist in the same
group. For example the [Model selector] Progbuffer1 is obviously not
the same beast as [Model Selector] Progbuffer2. All the same we can
group them together:
[Signal selector] ProgSection1 Default:voltage=3V;drive=H
RAS0#,D0,D1,D2
Note that RAS0# is of type Progbuffer1 while D[2:0] is of type
Progbuffer2 (look at pin list).
Hopefully at this point we have provided sufficient information in an
easy to use format for the designer of a simulation tool to allow us
to view the program groupings of a given chip model. From there we
would highlight the selection criteria that we wish to use for model
selection for this particular program group. I choose 3V and H
(for high drive). The tool will then go and select the [3V H] model
from Progbuffer1 and the [3V] buffer from Progbuffer2 and these will
be used everywhere that their respective [Model selector]s are
assigned in the specified [Signal selector] grouping.
In brief my principle concern is not that of selection by model
characteristic versus selection by model name. Rather it is that of
manual selection by the user (pin by pin) versus automatic selection
by the tool (programmable chip section by programmable chip section)
based upon user input.
I hope that I have removed some of the fog from what I wrote earlier
rather that mearly adding to it.
regards,
Malan Rampton
Signal Integrity Group
Compaq Computer Corporation
phone: (713)374-6800
email: rampton@twisto.compaq.com
>
> Malan and all other BIRD watchers,
>
> Thank you for your comments on BIRD 30, Malan. Here is my response
> to your comments.
>
> If I am not mistaken, your comments revolve mainly around the
> selection by characteristics problem vs. selection by [Model] name,
> which I proposed in the BIRD. I agree with you, I personally would
> also like to know the [Model] characteristics when I am prompted to
> make a choice between the various [Model]s.
>
> However, this issue didn't occur to me at the time I wrote the BIRD,
> because our 20-digit [Model] naming convention is designed to describe
> the characteristics of the buffer in a fairly unique way across all of
> our products. Providing a selection mechanism by the [Model] name
> seemed to be the right thing to do, since our [Model] names are
> meaningful in terms of the [Model]'s characteristics. The only
> extension to the existing naming convention I had to make with BIRD 30
> was to say that one [Model] represents only one mode of a programmable
> buffer and each of the modes of a buffer must have a different [Model]
> with a unique name. With this principle I did not see any need for
> inventing more keywords and sub-parameters to describe the
> characteristics of the buffer modes or [Model]s.
>
> The only problem I see here is that not all of the vendors use the
> same [Model] naming convention. To solve this problem we might ask
> the question: would it be a good idea to standardize a [Model] naming
> convention to reflect the characteristics of a [Model]? I see some
> problems with that. An engineer might simulate with models from
> various vendors. In order to make his work easier, the buffer
> characterization has to be meaningful across all of the models he is
> using. For example, the famous mA numbers which describe the buffer
> strength come to my mind. One vendor calls the PCI buffer 6/12 mA
> another calls it 12/21 mA. Yet the I-V curves of these two buffers
> are about the same! I don't see that we could influence all vendors
> (or IBIS model makers) to use the same kind of characterization
> technique.
>
> Until then, we might as well call our [Model]s "blue", "square",
> "liquid", "garble" etc... The engineer will have to associate these
> names with what he knows about the buffer, just like I have to know
> today that a 6/12 is the same thing as a 12/21 mA buffer, a PCI
> buffer. He might know that "blue" is a 5 volt buffer, "square" is a
> 3.3 volt buffer, "garble" is twice as strong as "square" and "liquid"
> is faster than "blue". If he doesn't know this, he can look up the
> keyword [Voltage Range] in the [Model] to find out which [Model] is a
> 3.3 volt model, look at the I-V curves to find out which one is
> stronger than the other, or look at the [Ramp] keyword to find out
> which one is the fastest.
>
> However, a user always wants quick information with the least amount
> of work. You are right, the "Classes" sub-parameter would provide
> that. My main problem is that most of the time it would merely
> duplicate the information which is already present in the data,
> therefore it is redundant. Redundancies make things more error prone.
> (What would you do as a user, if the [Voltage Range] keyword said it
> was a 5.0 volt buffer, but the "Class" sub-parameter would say it was
> a 3.3 volt buffer? These kind of mistakes might happen very easily.)
> Also, in some cases the IBIS model maker might want to describe the
> model in non-engineering terms, such as "use this [Model] for XX
> MBytes of DRAMs". In my mind, the best way to give the user quick
> information (without redundancy) on [Model] names under the [Model
> selector] keyword is to use comments. The user interface of a
> simulation tool can display these comments for the convenience of the
> user. I know, comments are usually ignored by the simulators and
> parsers. This could be an exception which makes sense logically.
> Every comment after the [Model] name inside the [Model selector]
> keyword could be treated as a "meaningful comment" to be used in a
> user interface dialog box.
>
> I don't understand the benefit of the additional [Signal selector]
> keyword you suggested. I stated it clearly (I thought), that all pins
> using the same Progbuffer name will be grouped by that name automatically.
> This is the same as what you are saying:
>
> > In addition to the [Model selector] keyword I have added a [Signal
> > selector] keyword. This has syntax that is similar to that of [Model
> > selector] but provides a listing of nets that are programmed as a
> > set. A name for the net grouping also needs to be provided and a
> > default set of characteristics can be specified.
>
> The additional rules you described in the "miscellaneous notes" are
> only necessary because of the redundant nature of the additional
> [Signal selector] keyword. If there is no redundancy, there is no
> need for these rules.
>
> > Some miscellaneous notes: membership in more than one [Signal selector]
> > group for a net should be prohibited; also the selection
> > specifications MUST yield a unique model selection from each involved
> > [Model selector]; I have used signal names for the [Signal selector]
> > listing rather than pin names to provide for an easier conversion
> > among package types.
>
> There is no need for the sub-parameter "Classes", as I see it. All of
> the information is already present in the various sections of the
> [Model]. There is no need for duplicate descriptions (redundancy).
> An IBIS model is simple enough and human readable, so that an engineer
> can easily get this kind of information out of it.
>
> These are my comments. Please let me know if I misunderstood some of
> your writings. Sincerely,
>
> Arpad Muranyi
> Intel Corporation
> ***********************************************************************
> > An optional sub-parameter "Classes" has also been added to
> > [Model]. This allows the specification of the programmable state of a
> > given model. A set of program classes are listed, i.e., voltage and
> > drive strength, and selection criteria values are assigned to them,
> > i.e., 5V or 3V and H or L. An open-ended number of classes may be
> > specified.
> >
> > In the example I have intentionally provided that the models of
> > Progbuffer1 are programmable for voltage and drive while the models of
> > Progbuffer2 are programmable only for voltage. In-spite of this they
> > have been grouped into the same [Signal selector] grouping. In a case
> > such as this, model selection should occur based upon what information
> > is present. If it is specified that 3volt high drive models are to be
> > selected for Progsection1 then the 3V H model from Progbuffer1 will be
> > used in conjunction with the 3V buffer from Progbuffer2.
> >
> > I believe that the additional functionality that this would provide is
> > probably worth the slightly greater complexity. I will brace myself to
> > hear otherwise, however.
> **************************Begin Example*****************************
> ==============================================================================
> | Keyword: [Model selector]
> | Required: No.
> | Description: Used to pick a [Model] from a list of [Model]s for a pin which
> | uses a programmable buffer.
> | Sub-Params: Default (?required if keyword used?)
> | Usage Rules: A programmable buffer must have an individual [Model] section
> | for each one of its modes used in the .ibs file. The names of
> | these [Models] must be unique and can be listed under the
> | [Model selector] keyword and/or pin list. The name of the
> | [Model selector] keyword must match the corresponding model
> | name listed under the [Pin] keyword and must not contain more
> | than 20 characters. A .ibs file must contain enough [Model
> | selector] keywords to cover all of the model selector names
> | specified under the [Pin] keyword.
> |
> | The sub-parameter Default is used to point to a default [Model]
> | to be used on the pin(s) calling this [Model selector].
> |
> | The operation of this selection mechanism implies that a group
> | of pins which use the same programmable buffer (i.e. model
> | selector name) will be switched together from one [Model] to
> | another. Therefore, if two groups of pins, for example an
> | address bus and a data bus, use the same programmable buffer,
> | the user must have the capability to configure them
> | independently. One can use two [Model selector] keywords
> | with unique names and the same list of [Model] keywords;
> | however, the usage of the [Model selector] is not limited to
> | these examples. Many other combinations are possible.
> |
> |
> [Pin] signal_name model_name R_pin L_pin C_pin
> |
> 1 RAS0# Progbuffer1 200.0m 5.0nH 2.0pF
> 2 EN1# Input NA 6.3nH NA
> 3 A0 Input
> 4 D0 Progbuffer2
> 5 D1 Progbuffer2 320.0m 3.1nH 2.2pF
> 6 D2 Progbuffer2
> 7 RD# Input 310.0m 3.0nH 2.0pF
> | .
> | .
> | .
> 18 Vcc3 POWER
> |
> |
> [Model selector] Progbuffer1 | voltage drive
> Default ABCD0123456789ABCDE0 | 3V H
> ABCD0123456789ABCDE1 | 3V L
> ABCD0123456789ABCDE2 | 5V H
> ABCD0123456789ABCDE3 | 5V L
> |
> [Model selector] Progbuffer2
> WXYZ9876543210WXYZE0 | 3V
> Default WXYZ9876543210WXYZE1 | 5V
> |
> [Signal selector] ProgSection1 Default:voltage=3V;drive=H
> RAS0#,D0,D1,D2
> |
> |
> |
> [Model] ABCD0123456789ABCDE0
> Model_type I/O
> Classes voltage=3V;drive=H | optional parameter
> Polarity Non-Inverting
> Enable Active-Low
> | .
> | .
> | .
> |
> [Model] ABCD0123456789ABCDE1
> Model_type I/O
> Classes voltage=3V;drive=L | optional parameter
> Polarity Non-Inverting
> Enable Active-Low
> | .
> | .
> | .
> |
> [Model] ABCD0123456789ABCDE2
> Model_type I/O
> Classes voltage=5V;drive=H | optional parameter
> Polarity Non-Inverting
> Enable Active-Low
> | .
> | .
> | .
> |
> [Model] ABCD0123456789ABCDE3
> Model_type I/O
> Classes voltage=5V;drive=L | optional parameter
> Polarity Non-Inverting
> Enable Active-Low
> | .
> | .
> | .
> |
> [Model] WXYZ9876543210WXYZE0
> Model_type I/O
> Classes voltage=3V | optional parameter
> Polarity Non-Inverting
> Enable Active-Low
> | .
> | .
> | .
> |
> [Model] WXYZ9876543210WXYZE1
> Model_type I/O
> Classes voltage=5V | optional parameter
> Polarity Non-Inverting
> Enable Active-Low
> | .
> | .
> | .
> |
>
> ******************************************************************************
>
>
> regards,
>
> Malan Rampton
> Signal Integrity Group
> Compaq Computer Corporation
> phone: (713)374-6800
> email: rampton@twisto.compaq.com
>
>
>
Received on Tue Aug 15 15:11:12 1995
This archive was generated by hypermail 2.1.8 : Fri Jun 03 2011 - 09:52:28 PDT