RE: namespace, index, and selector.

Scott,

I like your proposal. It would definitely solve a lot of
problems and make it easy for tools to track the information
users really need to manage their models.

Al, do you agree?

Thanks,

Chris

-----Original Message-----
From: Scott McMorrow [mailto:scott@vasthorizons.com]
Sent: Tuesday, July 17, 2001 3:24 PM
To: Reid, Chris; ibis@eda.org
Subject: Re: namespace, index, and selector.

Chris,

I think that a name space of
manufacturer.componentFamily.Component.Model.revision works.

The block structure would be something like this:

Manufacturer
    ComponentFamily
        Component
            Model
            End Model
        End Component
    End Component Family
End Manufacturer

Things like REVISION, DATE, INFORMATION ... etc, may then
appear anywhere within any of these blocks. For example, in this
case Date, Revision and Information fields apply to all the sub-blocks:

Manufacturer
    Date
    Revision
    Information
    ComponentFamily
        Component
            Model
            End Model
        End Component
    End Component Family
End Manufacturer

But in the next case, an override for a component has been
made at a lower level, indicating that the second component
in the list has been revised:

Manufacturer
    Date
    Revision 2.0
    Information
    ComponentFamily
        Component1
            Model
            End Model
        End Component1
        Component2
            Revision 2.1
            Model
            End Model
        End Component2
   End Component Family
End Manufacturer

This structure moves the "[Header]" information where it is
often useless, down to the appropriate levels where things
like Date and Revision number can be tracked. A Header is
no longer needed if the information in the header is placed
at the appropriate levels.

Manufacturer allows us to group all Component Families by
a name which is unique.

Component Family allows us to group like things
together, such as package options, and even pinout options,
or large logic families.

For IBIS-X, I can see that an awful large number of things
can and will be thrown into one file. Since IBIS-X is a
modeling language in it's own right, and supports general
modeling of interconnect structures, it is possible to place
everything needed for a simulation run into one file, much
as one does today with Spice. It can be sort of a super EBD.

Right now, things like Date and Revision are at the wrong level.
They are global to a file, not local to a particular Component.
This poses a problem when one component in a file is changed,
(i.e. new package parasitics, or pin list), but the remainder of
the Components have not changed. This can be the case when
there are a number of alternate package or bond-out options
for the same silicon.

I'd like to see a much better and logical structuring of the information
in IBIS-X models, so that we can have information that is more
useful and helpful in tracking the state of models in a simulation
environment or even in a directory. I believe that we should not
only come up with a reasonable nameSpace for models, but also
we should restructure the modeling blocks so that information is
applied at the right levels.

regards,

scott

--
Scott McMorrow
Principal Engineer
SiQual, Signal Quality Engineering
18735 SW Boones Ferry Road
Tualatin, OR  97062-3090
(503) 885-1231
http://www.siqual.com
"Reid, Chris" wrote:
> Al,
>
> The ICX tool (maybe this was already stated on this thread) scopes
> [model] names by the [component] they are in and [component] names
> by the EBD they are in.  In other words, the EBD name defines a
> name-space for the [component]s it uses, and the [component] name
> defines a name-space for the [model]s it uses.  This may result it
> more [model]s than are actually needed (when two different [component]s
> use the same [model]) but it does keep the necessary uniqueness.
>
> This is at variance with the IBIS specification which implies that the
> file should define a name-space implicitly.
>
> The problem really gets messy when users obtain models from many
> sources and name conflicts occur.  An explicit name-space will not
> solve this problem by itself.
>
> The Java model may be a good one to adopt.  Each model provider could
> adopt a top-level name-space, like MyCompany.com, and then define
> sub-spaces as necessary.  It would be good to make this name-space
> definition explicit.  It may make it easier for users to manage their
> models.
>
> Thanks,
>
> Chris
>
> -----Original Message-----
> From: Al Davis [mailto:aldavis@ieee.org]
> Sent: Tuesday, July 17, 2001 2:28 AM
> To: Lynne Green; 'John Angulo'; aldavis@ieee.org; bob_ross; chris_reid;
> ibis@lumbercartel.com; gerald.bannert@icn.siemens.de;
> gedlund@us.ibm.com; apanella@molex.com; mhaque@ti.com;
> angulo@hyperlynx.com; lgreen@cadence.com; Peters, Stephen;
> scott@vasthorizons.com; Steve Kaufer; arpad.muranyi@intel.com
> Subject: namespace, index, and selector.
>
> Recent discussion on the IBIS reflector leads me to believe we need
> some kind of namespace specifier.
>
> The (component, model) tuple doesn't work.
>
> 1. The model is not in component scope.
>
> 2. model and component are not keywords.
>
> Connector has a namespace specifier, [Begin_Cn_model_family] or
> something like that.
>
> We should be consistent.
>
> =========================
> Also ....
>
> COnnector has an index section.  Do we want one in IBIS-X??
>
> 1. I think we should.
> 2. At least we should be consistent.
> ============================
> We have (old IBIS) [Model Selector].
>
> How about [Component Selector], [Cn_Model Selector], [Submodel
> Selector] ....
>
> I think we must.  [Model] is not a keyword, so how can we have [Model
> Selector].  We need to have a selector for anything that can be
> defined.
>
> Syntax must be identical.